Ao projetar e integrar identidades na nuvem, hierarquia de recursos e redes de zonas de destino, considere as recomendações de design no Design da zona de destino no Google Cloud e as práticas recomendadas de segurança do Google Cloud abordadas no Blueprint de bases empresariais. Valide o design selecionado com base nos seguintes documentos:
- Práticas recomendadas e arquiteturas de referência para o design da VPC
- Projetar sua infraestrutura de rede
- Estrutura de arquitetura do Google Cloud: segurança, privacidade e conformidade
Considere também as seguintes práticas gerais recomendadas:
Ao escolher uma conectividade de rede híbrida ou multicloud, considere os requisitos de negócios e aplicativos, como SLAs, desempenho, segurança, custo, confiabilidade e largura de banda. Para mais informações, consulte Como escolher um produto de Conectividade de rede e Padrões para conectar outros provedores de serviços de nuvem ao Google Cloud.
Use VPCs compartilhadas no Google Cloud em vez de várias VPCs quando apropriadas e alinhadas com os requisitos de design da hierarquia de recursos. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
Siga as práticas recomendadas para o planejamento de contas e organizações.
Quando aplicável, estabeleça uma identidade comum entre os ambientes para que a autenticação dos sistemas possa ser feita com segurança nos limites do ambiente.
Para expor aplicativos com segurança a usuários corporativos em uma configuração híbrida e escolher a abordagem que melhor se adapta às suas necessidades, siga as maneiras recomendadas de integrar o Google Cloud ao seu sistema de gerenciamento de identidade.
- Além disso, consulte Padrões para autenticação de usuários da força de trabalho em um ambiente híbrido.
Ao projetar ambientes no local e na nuvem, considere o endereçamento IPv6 desde o início e saiba por quais serviços ele é aceito. Para mais informações, consulte Uma introdução ao IPv6 no Google Cloud. O texto resume os serviços que eram compatíveis quando o blog foi criado.
Ao projetar, implantar e gerenciar as regras de firewall da VPC, é possível:
- Usar a filtragem baseada na conta de serviço em vez da filtragem baseada em tag de rede se for necessário um controle rigoroso sobre como as regras de firewall são aplicadas às VMs.
- Usar as políticas de firewall ao agrupar várias regras de firewall, para atualizar todas elas de uma só vez. Também é possível tornar a política hierárquica. Veja detalhes e especificações da política de firewall hierárquica em Políticas de firewall hierárquicas.
- Usar os objetos de geolocalização na política de firewall para filtrar o tráfego IPv4 e IPv6 externos com base em regiões ou localizações geográficas específicas.
- Usar Inteligência contra ameaças para regras de políticas de firewall se for necessário proteger sua rede, permitindo ou bloqueando o tráfego com base nos dados da Inteligência contra ameaças, como endereços IP maliciosos conhecidos ou com base em intervalos de endereços IP de nuvem pública. Por exemplo, é possível permitir o tráfego de intervalos específicos de endereços IP de nuvem pública se os serviços precisarem se comunicar apenas com essa nuvem pública. Para mais informações, consulte Práticas recomendadas para regras de firewall.
Você deve sempre projetar a segurança da rede e da nuvem usando uma abordagem de segurança multicamadas considerando outras camadas de segurança, como estas:
- Google Cloud Armor
- Sistema de detecção de intrusões do Cloud
- IPS do Cloud Next Generation Firewall
- Inteligência contra ameaças para regras de política de firewall
Essas camadas adicionais ajudam a filtrar, inspecionar e monitorar uma grande variedade de ameaças nas camadas do aplicativo e da rede para análise e prevenção.
Ao decidir onde a resolução de DNS deve ser executada em uma configuração híbrida, recomendamos usar dois sistemas DNS autoritativos para o ambiente privado do Google Cloud e para os recursos locais hospedados por servidores DNS existentes no local. Para mais informações, consulte Escolha onde a resolução de DNS será realizada.
Sempre que possível, exponha os aplicativos em APIs usando um gateway de API ou balanceador de carga. Recomendamos considerar uma plataforma de API, como a Apigee. A Apigee atua como uma abstração ou uma fachada para as APIs de serviço de back-end, combinadas com recursos de segurança, limitação de taxa, cotas e análises.
A plataforma de API (gateway ou proxy) e o balanceador de carga de aplicativo não são mutuamente exclusivos. Às vezes, usar gateways de API e balanceadores de carga podem oferecer uma solução mais robusta e segura para gerenciar e distribuir o tráfego de APIs em grande escala. Usar os gateways da API Cloud Load Balancing permite realizar o seguinte:
Entregar APIs de alto desempenho com a Apigee e o Cloud CDN para:
- Reduzir a latência
- Hospedar APIs globalmente
Aumentar a disponibilidade em momentos de pico de tráfego
Para mais informações, assista no YouTube: Como entregar APIs de alto desempenho com a Apigee e o Cloud CDN.
Implementar o gerenciamento de tráfego avançado.
Usar o Google Cloud Armor como uma proteção contra DDoS, WAF e segurança de rede para proteger as APIs.
Gerenciar eficientemente o balanceamento de carga entre gateways em várias regiões. Para mais informações, assista Como proteger as APIs e implementar o failover multirregional com a PSC e a Apigee.
Para determinar qual produto do Cloud Load Balancing deve ser usado, primeiro você precisa determinar que tipo de tráfego seus balanceadores de carga devem gerenciar. Para mais informações, consulte Escolher um balanceador de carga.
Quando o Cloud Load Balancing é usado, é preciso usar as habilidades de otimização da capacidade de aplicativo que ele oferece, quando aplicável. Isso pode ajudar a lidar com parte dos desafios da capacidade que podem ocorrer em aplicativos distribuídos globalmente.
- Para mais detalhes sobre latência, consulte Como otimizar a latência do aplicativo com balanceamento de carga.
Enquanto o Cloud VPN criptografa o tráfego entre ambientes, no Cloud Interconnect será necessário usar o MACsec ou uma VPN de alta disponibilidade para criptografar o tráfego em trânsito da camada de conectividade. Para mais informações, consulte Como criptografar o tráfego no Cloud Interconnect.
- Também é possível considerar a criptografia da camada de serviço usando a TLS. Para mais informações, veja Decida como atender aos requisitos de compliance para a criptografia em trânsito.
Se precisar de mais volume de tráfego em uma conectividade VPN híbrida do que um só túnel VPN pode suportar, use a opção roteamento de VPN de alta disponibilidade ativo/ativo.
- Para configurações de longo prazo híbridas ou multicloud com altos volumes de transferência de dados de saída, use o Cloud Interconnect ou o Cross-Cloud Interconnect. Essas opções ajudam a otimizar o desempenho da conectividade e podem reduzir os custos de transferência de dados de saída para o tráfego que atenda a determinadas condições. Para saber mais, consulte os preços do Cloud Interconnect.
Ao se conectar aos recursos do Google Cloud e escolher entre o Cloud Interconnect, o peering direto ou peering por operadora, recomendamos usar o Cloud Interconnect, a menos que seja necessário acessar os aplicativos do Google Workspace. Para mais informações, compare os recursos de peering direto com o Cloud Interconnect e de peering por operadora com o Cloud Interconnect.
Reserve espaço suficiente do intervalo de endereços IP RFC 1918 existente para acomodar todos os sistemas hospedados em nuvem.
Se houver restrições técnicas que exijam manter o intervalo de endereços IP, você pode:
Usar os mesmos endereços IP internos para cargas de trabalho no local durante a migração para o Google Cloud, usando as sub-redes híbridas.
Provisionar e usar seus endereços IPv4 públicos para recursos do Google Cloud usando "Traga seu próprio IP" (BYOIP, na sigla em inglês) no Google.
Se o design da solução exigir a exposição de um aplicativo baseado no Google Cloud na Internet pública, considere as recomendações de design discutidas em Rede para entrega de aplicativos voltados para a Internet.
Quando aplicável, use os Endpoints do Private Service Connect para permitir cargas de trabalho no Google Cloud, no local ou em outro ambiente de nuvem com conectividade híbrida, para acesso privado a APIs do Google ou serviços publicados, usando endereços IP internos de maneira refinada.
Ao usar o Private Service Connect, é preciso controlar o seguinte:
- Quem pode implantar recursos do Private Service Connect.
- Se é possível estabelecer conexões entre consumidores e produtores.
- Qual tráfego de rede tem permissão para acessar essas conexões.
Para mais informações, consulte Segurança do Private Service Connect.
Para atingir uma configuração de nuvem robusta no contexto de arquitetura híbrida e multicloud:
- Realize uma avaliação abrangente dos níveis exigidos de confiabilidade dos aplicativos em diferentes ambientes. Isso pode ajudar a atingir os objetivos de disponibilidade e resiliência.
- Entenda os recursos de confiabilidade e os princípios de design do seu provedor de nuvem. Para mais informações, acesse Confiabilidade da infraestrutura do Google Cloud.
A visibilidade e o monitoramento da rede em nuvem são essenciais para manter as comunicações confiáveis. O Network Intelligence Center oferece um console único para gerenciar a visibilidade, o monitoramento e a solução de problemas da rede.