O Google Distributed Cloud (GDC) com isolamento físico ajuda a proteger racks de hardware, sistemas operacionais host, limites multilocatários, cadeias de suprimentos de software e tráfego de rede implantados em instalações de data center credenciadas.
Segurança das instalações
O hardware do GDC é implantado em instalações de data center credenciadas e controladas por você ou pelo operador designado. Sua organização e o operador de infraestrutura são responsáveis por aplicar controles de acesso físico, proteções ambientais e procedimentos de manuseio de mídia para a instalação que hospeda os racks do GDC.
Os controles de segurança física recomendados incluem:
- Controles de acesso ao perímetro e ao rack: restrinja a entrada física ao data center e aos racks do GDC usando leitores de crachás, autenticação biométrica, registros de acompanhamento de visitantes, patrulhas de segurança 24 horas e portas de rack trancadas.
- Vigilância e detecção de adulterações: monitoramento dos corredores de racks com circuito fechado de televisão (CFTV) contínuo e alarmes de intrusão física.
- Isolamento de energia, resfriamento e cabeamento: forneça fontes de energia redundantes, monitoramento ambiental e caminhos de cabeamento protegidos que atendam aos requisitos regulatórios e de credenciamento (como ISO/IEC 27001 ou ICD 705).
Segurança de hardware
O GDC é executado em racks de hardware modulares pré-integrados fabricados com componentes comerciais prontos para uso (COTS, na sigla em inglês) de fabricantes de equipamento original (OEMs, na sigla em inglês) aprovados. As instalações regionais certificadas com equipe que passou por investigação de histórico para contratação integram os racks de hardware. Os componentes de hardware e firmware de alto risco também passam por análises de segurança dedicadas contra ameaças de adulteração física e da cadeia de suprimentos.
Os principais controles de segurança de hardware incluem:
- Servidores de computação: os servidores bare metal usam raízes de confiança de hardware, módulos de plataforma confiável (TPM 2.0) e firmware de controlador de gerenciamento de placa-base (BMC, na sigla em inglês) assinado para verificar a integridade do hardware e da inicialização antes de carregar o sistema operacional.
- Trocas de rede e firewalls de perímetro: as trocas de gerenciamento e de topo de rack aplicam controles de acesso no nível da porta e criptografia MACsec. Os firewalls de perímetro redundantes fornecem inspeção com estado de taxa de linha e prevenção de intrusões no limite da zona.
- Dispositivos de armazenamento: os dispositivos de armazenamento de objetos, arquivos e blocos corporativos aplicam a criptografia AES-256 acelerada por hardware em repouso em unidades de criptografia automática (SEDs, na sigla em inglês) e isolamento lógico de locatários por meio de máquinas virtuais de armazenamento (SVMs, na sigla em inglês) dedicadas.
- Módulos de segurança de hardware (HSMs): dispositivos HSM dedicados conectados à rede (validados pelo FIPS 140-2 nível 3 e FIPS 140-3) geram, armazenam e protegem chaves criptográficas raiz em hardware inviolável.
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| Gerenciamento de hardware e HSM | Controlar chaves HSM e Máquinas de nó do cluster |
Segurança de host e nó
Cada host bare metal e nó de cluster do Kubernetes no GDC executa uma imagem de sistema operacional reforçada configurada para minimizar a superfície de ataque e evitar o escalonamento de privilégios não autorizado.
- Sistema operacional reforçado com STIG: os nós executam o Linux reforçado contra os guias de implementação técnica de segurança (STIGs, na sigla em inglês) da Agência de Sistemas de Informações de Defesa (DISA, na sigla em inglês) e os comparativos de mercado do Center for Internet Security (CIS). Pacotes, compiladores e serviços de rede desnecessários são removidos da imagem de base.
- Inicialização segura UEFI: os hosts bare metal e as máquinas virtuais (VMs) do usuário são compatíveis com a inicialização segura UEFI para verificar se apenas carregadores de inicialização e imagens de kernel assinados criptograficamente são executados durante a inicialização.
- Kernel e controles de acesso obrigatórios: os nós aplicam o SELinux no modo de aplicação, filtragem de chamadas do sistema seccomp, namespaces do Linux e limites de recursos de cgroups para isolar contêineres do kernel do host subjacente.
- Integridade do host e proteção de endpoints: o monitoramento de integridade de arquivos (FIM, na sigla em inglês) verifica se há alterações não autorizadas em arquivos críticos do sistema, e os controles de detecção e resposta de endpoints (EDR, na sigla em inglês) e antimalware monitoram a execução de processos e a telemetria do host.
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| Isolamento de nós e comparativos de mercado | Visão geral do isolamento de nós e comparativo de mercado CIS do Kubernetes |
| Inicialização segura de VM e gerenciamento de SO | Inicialização segura de uma VM e Gerenciar pacotes do SO |
Locação
O GDC oferece multilocação hierárquica com isolamento físico e de rede rígido entre organizações e isolamento de namespace lógico entre projetos dentro de uma organização.
Isolamento lógico entre organizações, clusters e projetos
O diagrama a seguir mostra como o cluster de admin raiz, os clusters de infraestrutura da organização e os clusters de carga de trabalho são isolados nos limites de gerenciamento e locatário:
- Cluster de admin raiz: dedicado a inicializar organizações, gerenciar o inventário de hardware e executar serviços de segurança e observabilidade de infraestrutura.
- Organização: o limite de locatário de nível superior. Cada organização tem o próprio cluster de infraestrutura dedicado, configuração do provedor de identidade, hierarquia do sistema de gerenciamento de chaves (KMS) e instância de roteamento e encaminhamento virtual (VRF).
- Clusters do Kubernetes: é possível provisionar clusters compartilhados com escopo de organização (que hospedam vários projetos) ou clusters padrão com escopo de projeto (dedicados a um único projeto para uma separação mais forte de cargas de trabalho).
- Projeto: uma unidade de locação lógica em uma organização em que você implanta VMs, contêineres, bancos de dados e recursos de armazenamento. Os projetos aplicam a igualdade de namespace do Kubernetes, os limites de controle de acesso baseado em papéis (RBAC) e as políticas de rede do projeto em todos os clusters.
Isolamento físico e de VRF entre racks
Em racks físicos de 42U, o GDC isola as organizações em servidores de computação, máquinas virtuais de armazenamento (SVMs) e VRFs de rede separados, para que nenhum servidor de computação físico seja compartilhado entre as organizações:
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| Hierarquia de recursos e projetos | Hierarquia de recursos e Gerenciar projetos |
| Clusters do Kubernetes | Clusters do Kubernetes no GDC e Configurações de cluster |
| Design de limites e cargas de trabalho | Projetar limites de acesso e Projetar separação de cargas de trabalho |
Segurança para aplicativos
O GDC protege o software da plataforma entregue pelo isolamento físico e os aplicativos do cliente implantados na sua organização.
Cadeia de suprimentos de software e validação de SLSA
Todos os componentes da plataforma do GDC, serviços próprios e serviços gerenciados de terceiros são criados em ambientes de build isolados e herméticos e verificados em busca de vulnerabilidades. Os artefatos são assinados no lado conectado ("lado de baixo") em conformidade com os requisitos dos níveis da cadeia de suprimentos para artefatos de software (SLSA, na sigla em inglês) antes da transferência pelo isolamento físico ("lado de cima").
Cada versão inclui uma lista de materiais de software (SBOM, na sigla em inglês) que detalha os componentes, as dependências e as bibliotecas de software, e os artefatos são verificados usando assinaturas criptográficas e checksums SHA-256 antes da implantação.
Artifact Registry e aplicação de políticas
O GDC aplica controles de política e imagem de contêiner antes da implantação:
- Artifact Registry local (Harbor): as imagens do contêiner e os gráficos do Helm são armazenados em um registro local do Harbor dentro do ambiente com isolamento físico, permitindo a assinatura de imagens e a verificação de vulnerabilidades sem acesso à internet externo.
- Controle de admissão e políticas da organização: o Open Policy Agent (OPA) Gatekeeper aplica políticas da organização em clusters do Kubernetes, impedindo que os pods sejam executados com escalonamento de privilégios, acesso à rede do host ou imagens do contêiner não confiáveis.
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| Políticas e Artifact Registry | Configurar políticas da organização e Criar e gerenciar recursos do Harbor |
| Cargas de trabalho e serviços | Cargas de trabalho de contêiner no GDC e Implantar serviços do Marketplace |
Segurança de rede
O GDC aplica a segmentação de rede em várias camadas, desde portas de switch físico até políticas de malha de serviço da camada 7.
Segmentação de VRF e VXLAN do plano de dados
A malha do plano de dados usa a VPN Ethernet (EVPN) do BGP multiprotocolo (MP-BGP) com encapsulamento de LAN virtual extensível (VXLAN) para isolar o tráfego entre o cluster de admin raiz e cada organização de locatário.
- Rede de gerenciamento fora de banda (OOB, na sigla em inglês): as interfaces de gerenciamento de hardware operam em uma rede de gerenciamento fisicamente separada, isolada do tráfego do locatário e acessível apenas pelo cluster de admin raiz.
- Isolamento de VRF e VXLAN: cada organização recebe identificadores de rede virtual (VNIs, na sigla em inglês) de camada 3 dedicados, VRFs externos e internos e máquinas virtuais de armazenamento (SVMs, na sigla em inglês) isoladas para que o tráfego do locatário não possa cruzar os limites da organização sem uma travessia explícita de firewall.
- Firewall de última geração, IDPS e proteção contra negação de serviço (DoS): os firewalls de perímetro e os sistemas de detecção e prevenção de intrusões (IDPS) aplicam uma postura de negação padrão, inspecionam o tráfego de entrada e saída em busca de assinaturas de ameaças e trabalham com balanceadores de carga para limitar as inundações de sessão. Os registros de firewall e IDPS se integram à pilha de observabilidade da organização e ao monitoramento de segurança da infraestrutura.
- Políticas de rede do projeto e do Kubernetes: em uma organização, é possível
aplicar a microssegmentação de negação padrão entre projetos e pods usando
os recursos
ProjectNetworkPolicy,OrganizationNetworkPolicyeNetworkPolicydo Kubernetes com suporte do Cilium.
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| Prevenção de ameaças e perímetro | Visão geral da rede, Solicitar prevenção de ameaças e Controle de saída |
| Políticas de rede e registros de fluxo | Políticas de rede da organização, políticas de rede do projeto, configurar políticas de rede do Kubernetes e gerenciar registros de fluxo |
| Conectividade externa | Configurar a VPN do GDC e estabelecer conectividade com interconexões |