Ao criar e integrar identidades da nuvem, a hierarquia de recursos e as redes da zona de destino, considere as recomendações de criação em Criação da zona de destino no Google Cloud e as Google Cloud práticas recomendadas de segurança abordadas no projeto de base empresarial. Valide o design selecionado com base nos seguintes documentos:
- Práticas recomendadas e arquiteturas de referência para a conceção de VPCs
- Decida uma hierarquia de recursos para a sua Google Cloud zona de destino
- Google Cloud Well-Architected Framework: segurança, privacidade e conformidade
Além disso, considere as seguintes práticas recomendadas gerais:
Quando escolher uma opção de conetividade de rede híbrida ou multinuvem, tenha em consideração os requisitos empresariais e de aplicação, como SLAs, desempenho, segurança, custo, fiabilidade e largura de banda. Para mais informações, consulte os artigos Escolher um produto de conetividade de rede e Padrões para estabelecer ligação a outros fornecedores de serviços na nuvem com Google Cloud.
Use VPCs partilhadas em vez de várias VPCs quando for adequado e estiver alinhado com os requisitos do design da hierarquia de recursos. Google Cloud Para mais informações, consulte o artigo Decidir se deve criar várias redes VPC.
Siga as práticas recomendadas para planear contas e organizações.
Quando aplicável, estabeleça uma identidade comum entre ambientes para que os sistemas possam autenticar-se em segurança em limites de ambientes.
Para expor aplicações de forma segura a utilizadores empresariais numa configuração híbrida, e para escolher a abordagem que melhor se adapta aos seus requisitos, deve seguir as formas recomendadas de integração Google Cloud com o seu sistema de gestão de identidades.
- Consulte também os padrões para autenticar utilizadores da força de trabalho num ambiente híbrido.
Ao criar os seus ambientes no local e na nuvem, considere a utilização de endereços IPv6 desde o início e tenha em conta os serviços que o suportam. Para mais informações, consulte Uma introdução ao IPv6 no Google Cloud. Resume os serviços que eram suportados quando o blogue foi escrito.
Ao conceber, implementar e gerir as regras de firewall da VPC, pode:
- Use a filtragem baseada em contas de serviço em vez da filtragem baseada em etiquetas de rede se precisar de um controlo rigoroso sobre a forma como as regras de firewall são aplicadas às VMs.
- Use políticas de firewall quando agrupa várias regras de firewall, para que possa atualizá-las todas em simultâneo. Também pode tornar a política hierárquica. Para ver especificações e detalhes da política de firewall hierárquica, consulte o artigo Políticas de firewall hierárquicas.
- Use objetos de geolocalização na política de firewall quando precisar de filtrar o tráfego IPv4 externo e IPv6 externo com base em localizações ou regiões geográficas específicas.
- Use a inteligência contra ameaças para regras de políticas de firewall se precisar de proteger a sua rede permitindo ou bloqueando o tráfego com base em dados de inteligência contra ameaças, como endereços IP maliciosos conhecidos ou com base em intervalos de endereços IP da nuvem pública. Por exemplo, pode permitir o tráfego de intervalos de endereços IP de nuvem pública específicos se os seus serviços precisarem de comunicar apenas com essa nuvem pública. Para mais informações, consulte as práticas recomendadas para regras de firewall.
Deve sempre criar a segurança da nuvem e da rede com uma abordagem de segurança de várias camadas, considerando camadas de segurança adicionais, como as seguintes:
- Google Cloud Armor
- Sistema de deteção de intrusos do Cloud
- IPS de firewall de próxima geração da nuvem
- Informações sobre ameaças para regras de políticas de firewall
Estas camadas adicionais podem ajudar a filtrar, inspecionar e monitorizar uma grande variedade de ameaças nas camadas de rede e de aplicação para análise e prevenção.
Ao decidir onde a resolução de DNS deve ser realizada numa configuração híbrida, recomendamos a utilização de dois sistemas de DNS autoritativos para o seu ambiente privado e para os seus recursos no local alojados por servidores DNS existentes no seu ambiente no local.Google Cloud Para mais informações, consulte o artigo Escolha onde a resolução de DNS é realizada.
Sempre que possível, exponha as aplicações através de APIs com um gateway de API ou um equilibrador de carga. Recomendamos que considere uma plataforma de API, como o Apigee. O Apigee funciona como uma abstração ou uma fachada para as APIs de serviços de back-end, combinadas com capacidades de segurança, limitação de taxas, quotas e estatísticas.
Uma plataforma de API (gateway ou proxy) e o Application Load Balancer não são mutuamente exclusivos. Por vezes, a utilização conjunta de gateways de API e balanceadores de carga pode oferecer uma solução mais robusta e segura para gerir e distribuir o tráfego de API em grande escala. A utilização de gateways de API do Cloud Load Balancing permite-lhe realizar o seguinte:
Ofereça APIs de alto desempenho com o Apigee e a Cloud CDN para:
- Reduza a latência
- Alojamento de APIs a nível global
Aumente a disponibilidade para as temporadas de pico de tráfego
Para mais informações, veja o vídeo Fornecer APIs de elevado desempenho com o Apigee e o Cloud CDN no YouTube.
Implemente a gestão avançada de tráfego.
Use o Cloud Armor como proteção contra DDoS, WAF e serviço de segurança de rede para proteger as suas APIs.
Faça a gestão do equilíbrio de carga eficiente em vários gateways em várias regiões. Para mais informações, veja o vídeo Proteger APIs e implementar a comutação por falha em várias regiões com o PSC e o Apigee.
Para determinar que produto do Cloud Load Balancing usar, primeiro tem de determinar que tipo de tráfego os equilibradores de carga têm de processar. Para mais informações, consulte Escolha um balanceador de carga.
Quando usar o Cloud Load Balancing, deve usar as respetivas capacidades de otimização da capacidade da aplicação, quando aplicável. Isto pode ajudar a resolver alguns dos desafios de capacidade que podem ocorrer em aplicações distribuídas globalmente.
- Para uma análise detalhada da latência, consulte o artigo Otimize a latência da aplicação com o equilíbrio de carga.
Embora a Cloud VPN encripte o tráfego entre ambientes, com o Cloud Interconnect, tem de usar o MACsec ou a VPN de alta disponibilidade através do Cloud Interconnect para encriptar o tráfego em trânsito na camada de conetividade. Para mais informações, consulte o artigo Como posso encriptar o meu tráfego através da Cloud Interconnect.
- Também pode considerar a encriptação da camada de serviço através do TLS. Para mais informações, consulte o artigo Decida como cumprir os requisitos de conformidade para a encriptação em trânsito.
Se precisar de um volume de tráfego superior numa conetividade híbrida de VPN do que um único túnel de VPN pode suportar, pode considerar usar a opção de encaminhamento de VPN de HA ativo/ativo.
- Para configurações híbridas ou multinuvem a longo prazo com volumes elevados de transferência de dados de saída, considere o Cloud Interconnect ou o Cross-Cloud Interconnect. Essas opções de conetividade ajudam a otimizar o desempenho da conetividade e podem reduzir os custos de transferência de dados de saída para o tráfego que cumpre determinadas condições. Para mais informações, consulte os preços do Cloud Interconnect.
Quando estabelecer ligação a Google Cloud recursos e tentar escolher entre a Interligação na nuvem, o peering direto ou o peering de operadora, recomendamos que use a Interligação na nuvem, a menos que precise de aceder às aplicações do Google Workspace. Para mais informações, pode comparar as funcionalidades do Direct Peering com o Cloud Interconnect e do Carrier Peering com o Cloud Interconnect.
Permita espaço de endereço IP suficiente do seu espaço de endereço IP RFC 1918 existente para acomodar os seus sistemas alojados na nuvem.
Se tiver restrições técnicas que exijam que mantenha o seu intervalo de endereços IP, pode:
Use os mesmos endereços IP internos para as suas cargas de trabalho no local enquanto os migra para o Google Cloud, usando sub-redes híbridas.
Aprovisione e use os seus próprios endereços IPv4 públicos para Google Cloud recursos que usam traga o seu próprio IP (BYOIP) para o Google.
Se a conceção da sua solução exigir a exposição de uma aplicação baseada emGoogle Cloudà Internet pública, considere as recomendações de conceção abordadas no artigo Redes para a entrega de aplicações viradas para a Internet.
Quando aplicável, use os pontos finais do Private Service Connect para permitir que as cargas de trabalho no Google Cloud, no local ou noutro ambiente de nuvem com conetividade híbrida acedam de forma privada às APIs Google ou aos serviços publicados, usando endereços IP internos de forma detalhada.
Quando usar o Private Service Connect, tem de controlar o seguinte:
- Quem pode implementar recursos do Private Service Connect.
- Se é possível estabelecer ligações entre consumidores e produtores.
- Que tráfego de rede tem autorização para aceder a essas ligações.
Para mais informações, consulte o artigo Segurança do Private Service Connect.
Para alcançar uma configuração na nuvem robusta no contexto da arquitetura híbrida e multinuvem:
- Realizar uma avaliação abrangente dos níveis necessários de fiabilidade das diferentes aplicações em todos os ambientes. Ao fazê-lo, pode ajudar a atingir os seus objetivos de disponibilidade e resiliência.
- Compreenda as capacidades de fiabilidade e os princípios de conceção do seu fornecedor de nuvem. Para mais informações, consulte a secção sobre a Google Cloud fiabilidade da infraestrutura.
A visibilidade e a monitorização da rede na nuvem são essenciais para manter comunicações fiáveis. O Network Intelligence Center oferece uma única consola para gerir a visibilidade, a monitorização e a resolução de problemas da rede.