Controles de infraestrutura

• under:organizations/ORGANIZATION_ID
• under:folders/FOLDER_ID
• under:projects/PROJECT_ID
• projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME.

A menos que seja necessário, evite a criação de instâncias do Compute Engine com endereços IP públicos. A restrição de lista compute.vmExternalIpAccess define o conjunto de instâncias de VM do Compute Engine que podem ter endereços IP externo.

Impeça que as instâncias do Compute Engine tenham endereços IP externo para reduzir drasticamente a exposição delas à Internet. Qualquer instância com um endereço IP externo pode ser descoberta imediatamente e se torna um alvo direto para verificações automatizadas, ataques de força bruta e tentativas de exploração de vulnerabilidades. Em vez disso, exija que as instâncias usem endereços IP particulares e gerencie o acesso por caminhos controlados, autenticados e registrados, como o túnel do Identity-Aware Proxy (IAP) ou um Bastion Host.

Adotar essa postura de negação por padrão é uma prática recomendada de segurança fundamental que ajuda a minimizar a superfície de ataque e impõe uma abordagem de confiança zero à sua rede. Essa restrição não é retroativa.

Com a restrição de lista compute.vmExternalIpAccess, é possível restringir o acesso externo às máquinas virtuais não atribuindo endereços IP externo. Configure essa restrição de lista para negar todos os endereços IP externo às máquinas virtuais.

Desative o acesso à porta serial definindo a restrição da política da organização compute.disableSerialPortAccess. Desative o acesso à porta serial nas VMs do Compute Engine para eliminar um canal de acesso que ignora as regras de firewall e outros controles de segurança de rede. O console serial interativo é destinado principalmente à solução de problemas de emergência, mas, quando você o deixa ativado, é possível criar uma porta dos fundos persistente que pode ser alvo de invasores.

Desativar o acesso à porta serial ajuda a reforçar uma postura de segurança de defesa em profundidade, forçando todo o acesso administrativo por caminhos padrão auditados, como o SSH, que pode ser protegido ativando o Identity and Access Management (IAM) e o Identity-Aware Proxy (IAP).

A restrição booleana cloudfunctions.requireVPCConnector exige que os administradores especifiquem um conector de acesso VPC sem servidor ao implantar uma função do Cloud Run. Quando aplicada, as funções precisam especificar um conector.

Ative o módulo de plataforma confiável virtual (vTPM) e os atributos de monitoramento de integridade da VM protegida para suas instâncias. O vTPM e os atributos de monitoramento de integridade fazem parte do processo padrão de criação de instâncias de VM. Use os atributos de vTPM e monitoramento de integridade da VM protegida para garantir que as VMs sejam inicializadas apenas com código confiável e não modificado.

O vTPM fornece um criptoprocessador virtual seguro que gera e armazena medições criptográficas de toda a sequência de inicialização, desde o firmware UEFI até os drivers de kernel. Em seguida, o monitoramento de integridade compara continuamente essas medições de tempo de execução com um valor de referência conhecido e válido estabelecido quando a VM foi criada.

Esses recursos oferecem uma cadeia de confiança verificável e alertam você ou tomam medidas automaticamente se detectarem modificações maliciosas, como as de um bootkit ou rootkit. Os recursos de VM protegida ajudam a manter a integridade da sua carga de trabalho desde o momento em que a instância é ligada.

Se você permitir que os desenvolvedores acessem os recursos do Compute Engine usando SSH, configure o Login do SO com a verificação em duas etapas. Use o Login do SO para gerenciar chaves SSH com políticas do Identity and Access Management (IAM) definindo a restrição de política da organização compute.requireOsLogin. O Login do SO centraliza o acesso à VM vinculando as permissões SSH à identidade do Google e aos papéis do IAM de um usuário, eliminando a necessidade de gerenciar chaves SSH individuais em cada máquina.

Vincular as permissões SSH à identidade de um usuário é fundamental para a segurança. Isso porque a remoção da função do IAM de um usuário revoga instantaneamente o acesso dele em todas as instâncias, protegendo contra entradas não autorizadas de contas inativas. O sistema simplifica o gerenciamento de chaves para evitar a proliferação delas e oferece uma trilha de auditoria clara e centralizada para todos os eventos de login nos Registros de auditoria do Cloud. O Login do SO também permite aplicar a autenticação de dois fatores, adicionando uma camada importante de proteção contra chaves e credenciais SSH roubadas. Um invasor com tokens OAuth comprometidos, mas sem uma senha ou chave de segurança, está bloqueado por esse recurso.

O acesso do Remote Desktop Protocol (RDP) a instâncias do Windows no Compute Engine não é compatível com o serviço de Login do SO. Por isso, a verificação em duas etapas não pode ser aplicada de maneira granular para sessões RDP. Ao usar o IAP para computadores ou plug-ins RDP baseados no Google Chrome, defina controles gerais, como duração da sessão para serviços do Google e configurações da verificação em duas etapas para as sessões da Web do usuário. Desative a configuração Permitir que o usuário confie no dispositivo na verificação em duas etapas.

• Defina uma política de armazenamento de mensagens usando a restrição de política da organização de restrição de local do recurso (gcp.resourceLocations).
• Configure uma política de armazenamento de mensagens ao criar um tópico. Exemplo:

  gcloud pubsub topics create TOPIC_ID \--message-storage-policy-allowed-regions=REGION1, REGION2

Desative os endereços IP externo para tarefas administrativas e de monitoramento relacionadas a jobs do Dataflow. Em vez disso, configure o acesso às VMs de worker do Dataflow usando SSH.

Ative o Acesso privado do Google e especifique uma das seguintes opções no seu job do Dataflow:

• --usePublicIps=false e --network=NETWORK-NAME
• --subnetwork=SUBNETWORK-NAME

Em que:

• NETWORK-NAME: o nome da sua rede do Compute Engine.
• SUBNETWORK-NAME: o nome da sub-rede do Compute Engine.

As tags de rede são atributos de texto anexados às VMs do Compute Engine, como as VMs de worker do Dataflow. Com as tags de rede, é possível tornar regras de firewall de rede VPC e algumas rotas estáticas personalizadas aplicáveis a instâncias de VM específicas. O Dataflow é compatível com a adição de tags de rede a todas as VMs de worker que executam um job específico do Dataflow.

Por padrão, os nós e o plano de controle do cluster do Google Kubernetes Engine (GKE) têm endereços de Internet roteáveis que podem ser acessados de qualquer endereço IP. Restrinja o acesso à rede ao plano de controle usando um endpoint baseado em DNS e criando clusters particulares. O plano de controle é o centro de gerenciamento de um cluster do Kubernetes, e expô-lo à Internet o torna um alvo principal para invasores. Essa configuração torna o plano de controle particular e o remove da Internet.

Restringir o acesso ao plano de controle ajuda a garantir que apenas dispositivos de confiança na rede particular da sua organização possam gerenciar o cluster, reduzindo drasticamente o risco de um ataque externo.

Ao criar regras de firewall, use o princípio de privilégio mínimo para fornecer acesso apenas à finalidade necessária. Verifique, quando possível, se as regras de firewall não entram em conflito com as regras padrão do GKE.

Use os Grupos do Google para controle de acesso baseado em função (RBAC, na sigla em inglês), que também permite a integração com suas práticas de gerenciamento de contas de usuário atuais, como a revogação do acesso quando alguém sai da sua organização. Os Grupos do Google para RBAC ajudam a gerenciar o acesso ao cluster de maneira eficiente usando Identity and Access Management (IAM) e os Grupos do Google, o que é adequado para a maioria das organizações que usam os Grupos do Google.

Ative os nós protegidos do GKE para verificação criptográfica dos nós no cluster. Os nós protegidos do GKE oferecem integridade e identidade de nó forte e verificável. Ative os nós protegidos do GKE ao criar ou atualizar clusters. Sempre que possível, use Nós protegidos do GKE com inicialização segura para autenticar também os componentes de inicialização das VMs de nó durante o processo de inicialização. Não use a inicialização segura se você precisar de módulos de kernel não assinados de terceiros.

Os nós protegidos do GKE são ativados por padrão quando você cria um cluster.

Use o Container-Optimized OS para implementar um sistema operacional de contêiner reforçado e gerenciado. Os sistemas operacionais de uso geral incluem muitos programas extras que não são necessários para executar contêineres e, portanto, criam um alvo maior e desnecessário para os invasores. O Container-Optimized OS é um sistema operacional minimalista e bloqueado que reduz significativamente essa superfície de ataque, incluindo apenas o necessário. Como um SO gerenciado, o Container-Optimized OS também tem patches de segurança aplicados automaticamente pelo Google, o que ajuda a corrigir vulnerabilidades críticas e reduz sua carga de trabalho operacional.

Uma imagem que inclui o Container-Optimized OS com containerd (cos_containerd) tem o containerd como o ambiente de execução principal do contêiner diretamente integrado ao Kubernetes. O containerd é o componente principal de execução do Docker e foi projetado para oferecer funcionalidade básica de contêiner para a interface de ambiente de execução de contêineres (CRI, na sigla em inglês) do Kubernetes. Ele é significativamente menos complexo que o daemon Docker completo e, por isso, tem uma superfície de ataque menor.

Use a Federação de Identidade da Carga de Trabalho para GKE para autenticar com segurança as APIs do Cloud de Confiance by S3NS nas cargas de trabalho do Google Kubernetes Engine (GKE). A federação de identidade da carga de trabalho para GKE oferece uma alternativa mais simples e segura ao uso de chaves de conta de serviço.

Use o GKE Sandbox para fornecer uma camada extra de segurança e evitar que códigos não confiáveis afetem o kernel do host nos nós do cluster do Google Kubernetes Engine (GKE). O GKE Sandbox aumenta o isolamento de cargas de trabalho não confiáveis ou sensíveis, fornecendo uma camada extra de proteção contra ataques de escape de contêiner.

Desative a porta somente leitura do kubelet 10255 e use a porta 10250, que é mais segura. O Kubernetes não realiza nenhuma verificação de autenticação ou autorização nessa porta. O kubelet disponibiliza os mesmos endpoints na porta 10250 mais segura e autenticada.

Só é possível desativar a porta somente leitura do kubelet não segura no GKE versão 1.26.4-gke.500 ou mais recente.

Crie namespaces ou clusters separados para cada equipe e ambiente para implementar o acesso de privilégio mínimo ao Kubernetes. Atribua centros de custo e rótulos apropriados a cada namespace para fins de responsabilização e estorno. Forneça aos desenvolvedores o nível de acesso ao namespace necessário para implantar e gerenciar o aplicativo, especialmente na produção. Mapeie as tarefas que os usuários precisam executar no cluster e defina as permissões necessárias para executar cada tarefa.

Atribua os papéis apropriados do Identity and Access Management (IAM) para o Google Kubernetes Engine (GKE) a grupos e usuários para conceder permissões no nível do projeto e use o RBAC para dar permissões nos níveis de cluster e de namespace.

Por padrão, todos os pods em um cluster podem se comunicar entre si. Controle a comunicação entre pods conforme necessário para suas cargas de trabalho. Restringir o acesso de rede aos serviços dificulta muito a migração lateral dos invasores dentro de um cluster, além de dar aos serviços formas de se proteger contra negações de serviço acidentais ou deliberadas.

Há duas maneiras de controlar o tráfego:

• Use o Cloud Service Mesh ou o Istio para balanceamento de carga, autorização de serviço, limitação, cota, métricas e muito mais.
• Use políticas de rede do Kubernetes. Escolha essa opção se estiver procurando a funcionalidade básica de controle de acesso exposta pelo Kubernetes.

Os controladores de admissão são plug-ins que regem e impõem o modo como o cluster é usado. Ative-os para usar alguns dos recursos de segurança mais avançados do Kubernetes, porque eles são uma parte importante da abordagem de defesa em profundidade para reforço da proteção do seu cluster. Por padrão, os pods no Kubernetes podem operar com recursos além do que eles exigem. Use controles de admissão para restringir os recursos do pod apenas àqueles necessários para essa carga de trabalho.

O GKE oferece suporte a vários controles para restringir a execução de pods com recursos explicitamente concedidos. Por exemplo, o Controlador de Políticas está disponível para clusters em frotas. O Kubernetes também tem o controlador de admissão do PodSecurity integrado, que permite aplicar os padrões de segurança do pod em clusters individuais. O Controlador de Políticas é um recurso do GKE que permite aplicar e validar a segurança em clusters do GKE em escala usando políticas declarativas.

Algumas cargas de trabalho do Kubernetes, principalmente as do sistema, têm permissão para se automodificar. Por exemplo, algumas cargas de trabalho escalonam automaticamente na vertical. Embora seja conveniente, a automodificação pode permitir que um invasor que já tenha comprometido um nó escalone ainda mais no cluster. Por exemplo, um invasor pode fazer com que uma carga de trabalho do nó se automodifique para ser executada como uma conta de serviço com mais privilégios que existe no mesmo namespace.

Não conceda às cargas de trabalho permissão para se modificar por padrão. Quando a automodificação for necessária, limite as permissões aplicando restrições do Gatekeeper ou do Controlador de Políticas, como NoUpdateServiceAccount da biblioteca de código aberto do Gatekeeper, que fornece várias políticas de segurança úteis.

Ao implantar políticas, permita que os controladores que gerenciam o ciclo de vida do cluster ignorem as políticas. Os controladores precisam fazer mudanças no cluster, como aplicar upgrades. Por exemplo, se você implantar a política "NoUpdateServiceAccount" no GKE, defina os seguintes parâmetros na restrição:

Audite as configurações do cluster para desvios das configurações definidas. As configurações abordadas nessas práticas recomendadas, bem como outras configurações incorretas comuns, podem ser verificadas automaticamente usando o Security Command Center.

Use a autorização binária para garantir que imagens confiáveis sejam implantadas no Google Kubernetes Engine (GKE) e no Cloud Run. A autorização binária ajuda a garantir que apenas imagens de contêiner verificadas e confiáveis possam ser implantadas nos seus clusters, reforçando a segurança da cadeia de suprimentos de software.

Use clusters do Autopilot do Google Kubernetes Engine (GKE). Os clusters do Autopilot oferecem medidas de segurança robustas, com muitas práticas recomendadas de segurança para contêineres ou GKE ativadas por padrão.

Use contas de serviço do Identity and Access Management (IAM) com privilégios mínimos para clusters e nós do Google Kubernetes Engine (GKE). O acesso ao plano de controle do GKE é restrito a um único endpoint baseado em DNS. A implementação do princípio de privilégio mínimo reduz significativamente a superfície de ataque sem a necessidade de regras de firewall ou hosts bastion adicionais.

Crie nós particulares para reduzir a exposição à Internet. Os nós particulares do Google Kubernetes Engine (GKE) ajudam a reduzir a exposição à Internet, garantindo que os nós do GKE não tenham um endereço IP público.

Use os nós confidenciais do GKE para aplicar a criptografia de dados em uso nos seus nós e cargas de trabalho. Os nós confidenciais do GKE ajudam a proteger cargas de trabalho altamente sensíveis criptografando dados em uso com a computação confidencial.

Execute suas próprias autoridades certificadoras para gerenciar chaves no Google Kubernetes Engine (GKE). Usar suas próprias autoridades certificadoras oferece mais controle sobre as operações criptográficas. Para solicitar acesso a esse recurso, entre em contato com a sua equipe de conta Cloud de Confiance by S3NS .

Criptografar secrets do Kubernetes em repouso usando chaves gerenciadas do Cloud Key Management Service (Cloud KMS). O Cloud KMS oferece uma camada extra de segurança para dados do etcd, permitindo que você criptografe secrets do Kubernetes com uma chave que você tem e gerencia.

Use chaves de criptografia gerenciadas pelo cliente (CMEK) para criptografia de disco de inicialização do nó. Com a CMEK, é possível criptografar o disco de inicialização de um nó do Kubernetes com uma chave que você possui e gerencia.

Conceda papéis de administrador apenas às contas de serviço que implantam e configuram nuvens privadas do Google Cloud VMware Engine e a um número limitado de administradores. Normalmente, a adição ou exclusão manual de clusters e nós é uma ação que não acontece com frequência e pode ter um alto impacto no faturamento ou na disponibilidade do cluster.

Faça auditorias regulares de quem recebeu o papel de Administrador de serviço do VMware Engine, seja diretamente no projeto usado para o VMware Engine ou em um dos níveis pais da hierarquia de recursos. Essa auditoria precisa incluir outros papéis, como os papéis básicos de Editor e Proprietário, que incluem permissões críticas relacionadas ao VMware Engine. É possível usar serviços como o recomendador de papéis do IAM para ajudar a identificar papéis com privilégios em excesso.

Conceda o papel de Leitor de serviços do VMware Engine aos usuários por padrão e somente se necessário. A função de leitor do serviço do VMware Engine oferece acesso somente leitura ao Google Cloud VMware Engine em Cloud de Confiance by S3NS e foi projetada para ser suficiente para a maioria das tarefas.

Ao conceder papéis no nível do VMware no vCenter Server Appliance, use controles de acesso baseados em função (RBAC) e o princípio de privilégio mínimo.

Manter uma única solução de identidade em que é possível provisionar e gerenciar contas de usuário. Essa prática recomendada permite centralizar atividades como gerenciamento do ciclo de vida de identidades, gerenciamento de grupos e gerenciamento de senhas. Evite criar uma estratégia de identidade fragmentada.

Ao conceder papéis no nível do VMware no vCenter Server Appliance, conceda papéis aos grupos criados no provedor de identidade. Não crie uma estratégia de identidade fragmentada.

Ao criar grupos de usuários no vSphere, não atribua a função de proprietário da nuvem. Essa função concede controle administrativo sobre o ambiente vCenter da sua nuvem privada, restringindo algumas permissões da infraestrutura global subjacente. Os grupos de usuários com permissões maiores que a função de proprietário do Cloud são automaticamente redefinidos para essa função.

Exceto no processo de configuração inicial e em procedimentos de emergência, não use a conta de serviço padrão do vCenter (CloudOwner@gve.local) e o administrador da conta de serviço padrão do NSX-T (admin). Essas contas de serviço padrão incluem permissões avançadas, como Cloud-Proprietário-Role e Enterprise Admin. Salve as credenciais dessas contas de serviço no Secret Manager.

Para evitar e reduzir a divulgação não autorizada das credenciais da conta de serviço padrão do vCenter (CloudOwner@gve.local) e do administrador da conta de serviço padrão do NSX-T (admin), altere as senhas a cada 90 dias.

Controle o tráfego de rede norte-sul que entra e sai das nuvens privadas usando o firewall de gateway do NSX. Os firewalls de gateway do NSX são firewalls norte-sul que ajudam a proteger os perímetros.

Controle o tráfego de rede leste-oeste na nuvem privada usando o firewall distribuído (DFW) do NSX. Por padrão, todas as sub-redes podem se comunicar entre si. Use o DFW para definir o tráfego permitido entre aplicativos e serviços dentro do aplicativo.

Se você executar cargas de trabalho com requisitos de segurança ou classificações de dados diferentes, crie sub-redes de carga de trabalho para separá-las. As sub-redes permitem reduzir o raio de impacto potencial ao não misturar cargas de trabalho de diferentes requisitos e posturas de segurança.

Use um coletor de registros para armazenar os registros de auditoria da API Google Cloud VMware Engine. É possível encaminhar registros de auditoria para destinos diferentes, conforme necessário.

Para coletar registros da plataforma no nível do VMware (por exemplo, mensagens syslog do vCenter e do NSX-T), configure as nuvens privadas do Google Cloud VMware Engine para encaminhar registros syslog a um agregador de registros centralizado. Esses registros não são coletados nos registros de auditoria do VMware Engine e precisam ser coletados separadamente.

Instale o agente independente para ativar o Cloud Logging e o Cloud Monitoring na plataforma VMware vSphere. Com o agente independente, é possível coletar registros no nível da carga de trabalho e enviá-los ao Logging e ao Monitoring para análise e armazenamento.

Crie nuvens privadas do Google Cloud VMware Engine em regiões que atendam aos requisitos de residência de dados da sua organização. As nuvens privadas são recursos provisionados de longa duração que não são triviais de implantar e realocar.

Implemente o serviço de backup e DR ou uma solução de backup de terceiros para cargas de trabalho. Por padrão, o Google Cloud VMware Engine faz backup automático apenas da configuração do vCenter e do NSX. O Backup e DR facilita o backup e a recuperação de VMs.

Verifique se os aplicativos executados no Google Cloud VMware Engine criptografam o tráfego. O VMware Engine não criptografa o tráfego de carga de trabalho em trânsito.

Ative a criptografia de dados em trânsito nos clusters vSAN do VMware para criptografar dados, metadados e tráfego de serviços de arquivos.

Se exigido pelo seu ambiente regulatório, configure a criptografia de dados em repouso do vSAN para usar chaves de criptografia gerenciadas pelo cliente (CMEKs).

Gerencie o ciclo de vida das chaves de criptografia de chaves (KEKs) usadas para criptografia de dados em repouso do vSan. Implemente um procedimento de rotação de chaves que esteja alinhado aos requisitos da sua organização.