O Google Distributed Cloud (GDC) com isolamento físico usa uma arquitetura de confiança zero para proteger sua infraestrutura, serviços de plataforma e cargas de trabalho de aplicativos em ambientes desconectados sem exigir conectividade com o Google Cloud público ou com a Internet.
A documentação de segurança no GDC é organizada nesta visão geral e em dois documentos dedicados:
- Visão geral da segurança: abrange a estratégia de segurança (pilares de Zero Trust e responsabilidade compartilhada), criptografia, Identity and Access Management (IAM) e conformidade.
- Segurança de infraestrutura, rede e carga de trabalho: abrange a segurança das instalações, do hardware, do host e do nó, o isolamento de multilocatários, a segurança da cadeia de suprimentos de aplicativos e a segmentação de rede.
- Operações de segurança: abrange o monitoramento de segurança da infraestrutura e do locatário, a gestão de vulnerabilidades, a resposta a incidentes, a exportação de registros de gerenciamento de eventos e informações de segurança (SIEM) externos, a geração de registros de auditoria, o acesso de emergência, a recuperação de desastres e os upgrades graduais.
Estratégia de segurança
O GDC é baseado em uma arquitetura de confiança zero que não pressupõe confiança implícita com base na localização da rede, na propriedade do dispositivo ou na identidade do usuário. Todas as solicitações nas camadas de hardware, plano de controle e carga de trabalho precisam ser autenticadas, autorizadas e criptografadas. Para detalhes arquitetônicos sobre como os princípios de confiança zero se aplicam a implantações desconectadas, consulte o Whitepaper sobre a estratégia de confiança zero do GDC e Abordagem com isolamento físico do Google Distributed Cloud para confiança zero.
O modelo de segurança do GDC está alinhado com os sete pilares de confiança zero a seguir:
- Identidade e usuários: autentica identidades humanas e de serviço por meio do seu provedor de identidade (IdP) empresarial e aplica o acesso de privilégio mínimo em organizações e projetos.
- Dispositivos e endpoints: verifica a integridade do hardware e da inicialização, reforça os sistemas operacionais de host e nó em relação aos comparativos de defesa e monitora continuamente os hosts em busca de mudanças não autorizadas.
- Aplicativos e cargas de trabalho: protege a integridade do software, do build ao ambiente de execução, usando cadeias de suprimentos de software verificadas, Container Registry locais com verificação de vulnerabilidades e políticas de admissão de cluster.
- Dados e criptografia: protege dados em repouso e em trânsito por padrão usando chaves criptográficas com suporte de hardware, chaves de criptografia gerenciadas pelo cliente (CMEK) e infraestrutura de chave pública (PKI) automatizada.
- Rede e ambiente: isola planos de gerenciamento, organizações de locatários e cargas de trabalho de projetos usando segmentação de rede em várias camadas, inspeção de perímetro e políticas de rede de negação padrão.
- Automação e orquestração: aplica uma configuração consistente, upgrades graduais sem interrupções e acesso de emergência auditado com o gerenciamento de mudanças declarativo.
- Visibilidade e análise: coleta e correlaciona telemetria de auditoria, operacional e de segurança em toda a plataforma e oferece suporte à exportação de registros de locatários para sistemas externos de monitoramento de segurança.
Modelo de responsabilidade compartilhada
A segurança no GDC é uma responsabilidade compartilhada entre as camadas de infraestrutura, plataforma e carga de trabalho. Dependendo de você consumir infraestrutura como serviço (IaaS), plataforma como serviço (PaaS) ou software como serviço (SaaS), as responsabilidades operacionais são divididas conforme mostrado no diagrama a seguir:
- Camada de infraestrutura: abrange a infraestrutura do sistema, incluindo dispositivos de hardware, switches, matrizes de armazenamento, o cluster de admin raiz e o monitoramento de segurança da infraestrutura. As atualizações do sistema, o gerenciamento do ciclo de vida do hardware e as operações de segurança da infraestrutura são realizadas sem acessar dados confidenciais de carga de trabalho do cliente.
- Camada de organização e plataforma: abrange a administração da organização do locatário, incluindo conexões de IdP no nível da organização, vinculações de papéis, chaves do sistema de gerenciamento de chaves (KMS), certificados de ICP, políticas de rede do projeto, clusters compartilhados do Kubernetes e observabilidade e exportação de registros da organização.
- Camada de carga de trabalho e aplicativo: abrange o desenvolvimento, a implantação e o monitoramento de cargas de trabalho em contêineres e máquina virtual (VMs) em namespaces de projeto isolados de acordo com as políticas de segurança da organização.
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| Arquitetura e públicos-alvo | Públicos-alvo da documentação e Hierarquia de recursos |
| Isolamento e responsabilidade compartilhada | Projetar limites de acesso, Projetar separação de cargas de trabalho e Modelo de responsabilidade compartilhada do Marketplace |
Criptografia
O GDC oferece um sistema de gerenciamento de chaves (KMS, na sigla em inglês), um Certificate Authority Service (CAS, na sigla em inglês) e uma infraestrutura de chave pública (PKI, na sigla em inglês) integrados, com suporte de módulos de segurança de hardware (HSMs, na sigla em inglês) validados pelo FIPS para proteger dados em repouso e em trânsito:
- PKI e CAS: automatiza a emissão, a renovação e a distribuição de pacotes de confiança de certificados em planos de controle e endpoints de entrada, com suporte para autoridades certificadoras raiz internas, CAs intermediárias externas, certificados TLS da Web personalizados e CAs de carga de trabalho.
- KMS e HSM: usa uma hierarquia de criptografia de envelope com suporte de HSM por organização que permite gerenciar chaves de criptografia simétricas e chaves de assinatura assimétricas, além de usar chaves de criptografia gerenciadas pelo cliente (CMEK) para exclusão criptográfica.
- Criptografia padrão em repouso e em trânsito: criptografa todo o armazenamento em disco de blocos, arquivos, objetos e servidores em repouso por padrão usando criptografia AES-256 multicamadas validada pelo FIPS e protege todo o tráfego em trânsito usando TLS, TLS mútuo (mTLS), IPsec ou MACsec.
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| ICP e certificados | Buscar pacotes de confiança, configurações de certificado TLS da Web, modos de transição de PKI e Certificate Authority Service |
| Gerenciamento de chaves (KMS, CMEK e HSM) | Sistema de gerenciamento de chaves, chaves de criptografia gerenciadas pelo cliente e chaves de controle do HSM |
| Criptografia de dados e armazenamento | Criptografia em repouso, criptografia em trânsito, gerenciar buckets de armazenamento criptografados e criptografar métricas |
Identity and Access Management
O Identity and Access Management (IAM) no GDC autentica
usuários humanos e identidades de serviço de carga de trabalho (ProjectServiceAccount) e
aplica o acesso de privilégio mínimo e a segregação de funções em recursos globais e
zonais. Conecte o GDC ao seu provedor de identidade (IdP) empresarial usando o OpenID Connect (OIDC) ou o SAML 2.0 com autenticação multifator (MFA). Em seguida, conceda acesso vinculando usuários ou grupos a papéis predefinidos ou personalizados com escopo para sua organização, projeto ou cluster do Kubernetes.
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| Provedores de identidade e autenticação | Autorização e controle de acesso, Conectar-se a um provedor de identidade e Identidades de serviço |
| Vinculações de papéis e controle de acesso | Conceder e revogar acesso, Gerenciar o acesso a clusters padrão e Permissões de papéis predefinidos |
Compliance
O GDC foi projetado para ajudar clientes soberanos a atender a requisitos rigorosos de compliance por meio de rastreamento contínuo de inventário, verificação de vulnerabilidades, testes de penetração e validação de recuperação de desastres. Como o GDC opera na sua instalação credenciada, a conquista da credencial final do sistema (como uma autoridade para operar) segue o modelo de responsabilidade compartilhada.
Conformidade com o Guia de Implementação Técnica de Segurança (STIG, na sigla em inglês)
De acordo com a regra STIG RHEL-08-040320, o pacote xorg-x11-server-common é uma
dependência de sistema aprovada necessária para drivers de GPU NVIDIA e bibliotecas de aceleração
de hardware (como Vulkan e Mesa). O serviço do gerenciador de exibição gráfica
está desativado e inativo nas imagens do sistema operacional do nó.
Para mais informações, consulte a seguinte documentação:
| Tópico | Documentação e guias de configuração |
|---|---|
| Comparativos de mercado e políticas | Comparativo de mercado CIS do Kubernetes e Configurar políticas da organização |
| Registro de auditoria e retenção | Visão geral dos registros de auditoria, Proteger e restaurar registros de auditoria e Criar buckets WORM |