Práticas recomendadas de segurança

Esta página descreve as práticas recomendadas para proteger sua instalação do Google Distributed Cloud.

Segurança física do hardware

Você é responsável pela segurança física do hardware conectado da Distributed Cloud, como limitar o acesso a pessoal autorizado.

Segurança da plataforma

A plataforma de hardware conectada do Distributed Cloud tem os seguintes recursos de segurança:

  • Sensor de intrusão física. Se uma parte não autorizada abrir fisicamente a máquina, você e o Google serão notificados imediatamente sobre a invasão física.

  • Trusted Platform Module (TPM). O TPM é a raiz de confiança que gera e armazena chaves de criptografia para todos os dados armazenados, recebidos e transmitidos pelo Distributed Cloud Connected.

  • Certificado da plataforma. O certificado da plataforma é um registro criptograficamente seguro da fabricação e da identidade do TPM. O certificado serve como prova de integridade da cadeia de suprimentos para hardware conectado do Google Distributed Cloud.

  • Bloqueio de portas. Todas as portas externas e internas, exceto as Ethernet, como USB e console RS-232, são desativadas no nível do firmware e ativadas apenas para manutenção.

Segurança do armazenamento local

O hardware conectado do Distributed Cloud é enviado com unidades de disco auto criptografadas (SED, na sigla em inglês) e usa a configuração unificada de chaves do Linux (LUKS, na sigla em inglês) para criptografar os volumes lógicos em cada nó conectado do Distributed Cloud. Você pode usar chaves de criptografia gerenciadas pelo cliente (CMEK) ou Google-owned and managed keys para encapsular a chave de criptografia de disco (DEK) do LUKS.

Quando você atribui um nó a um pool de nós, ele gera uma DEK LUKS e a encapsula em uma senha LUKS gerenciada pelo Google, também conhecida como chave de criptografia de chaves (KEK), ou em uma fornecida por você pelo Cloud KMS. Você pode escolher se quer usar o Cloud KMS ao criar um pool de nós. O Distributed Cloud Connected se integra ao Cloud KMS usando o modelo de criptografia de envelope.

O Distributed Cloud Connected alterna automaticamente as frases de senha do LUKS e do SED em uma programação regular.

Além disso, cada máquina do Distributed Cloud Connected faz o seguinte em cada inicialização a frio:

  • Se você não estiver usando o Cloud KMS, a máquina vai gerar uma nova KEK (senha do LUKS) e configurar o armazenamento criptografado do zero.

  • Se você estiver usando o Cloud KMS, a máquina vai buscar a KEK no Cloud KMS e desbloquear os volumes lógicos atuais que contêm seus dados.

Configurar o suporte para chaves de criptografia gerenciadas pelo cliente (CMEK) para armazenamento local

Por padrão, o Google Distributed Cloud Connected criptografa o conteúdo do cliente em repouso. O Distributed Cloud Connected lida com a criptografia e você não precisa fazer nada. Essa opção é chamada de criptografia padrão do Google.

Se você quiser controlar suas chaves de criptografia, use chaves de criptografia gerenciadas pelo cliente (CMEKs) no Cloud KMS com serviços integrados a CMEKs, incluindo o Distributed Cloud Connected. Ao usar chaves do Cloud KMS, é possível controlar o nível de proteção, o local, a programação de rotação, as permissões de uso e acesso e os limites criptográficos. Com o Cloud KMS, também é possível visualizar registros de auditoria e controlar ciclos de vida de chaves. Em vez de o Google ser proprietário e gerente de chaves de criptografia de chaves (KEKs) simétricas que protegem seus dados, você controla e gerencia essas chaves no Cloud KMS.

Depois de configurar os recursos com CMEKs, a experiência de acesso aos recursos conectados do Distributed Cloud é semelhante à criptografia padrão do Google. Para saber mais sobre suas opções de criptografia, consulte Chaves de criptografia gerenciadas pelo cliente (CMEK).

Para ativar a integração do Cloud KMS com o Distributed Cloud Connected, siga estas etapas:

  1. Crie um keyring, uma chave simétrica e uma ou mais versões de chave para usar com o Distributed Cloud Connected. Crie esses artefatos na mesma região Google Cloud da instalação conectada do Distributed Cloud. Para instruções, consulte Criar uma chave.

  2. Conceda o papel Criptografador/Descriptografador do Cloud KMS CryptoKey (roles/cloudkms.cryptoKeyEncrypterDecrypter) à conta de serviço conectada do Distributed Cloud no seu projetoGoogle Cloud . Faça isso para cada versão de chave que você quer usar com o Distributed Cloud Connected. Se você revogar essa função depois de integrar a instalação conectada do Distributed Cloud ao Cloud KMS, perderá o acesso aos dados armazenados nas máquinas conectadas do Distributed Cloud.

  3. Crie um pool de nós usando a flag --local-disk-kms-key e forneça o caminho completo para a versão da chave que você quer usar com esse pool de nós.

  4. Crie um cluster usando a flag --control-plane-kms-key e forneça o caminho completo para a versão da chave que você quer usar com o nó que executa o plano de controle do cluster.

  5. Se quiser, use a flag --offline-reboot-ttl ao criar o cluster para especificar um período em que os nós reinicializados podem entrar novamente no cluster enquanto ele está em execução no nó de capacidade de sobrevivência. Se você não especificar essa janela, os nós reinicializados não poderão entrar novamente no cluster até que ele saia do modo de capacidade de sobrevivência.

    ATENÇÃO: se você especificar uma janela de tempo limite de reinicialização, os nós que ficaram off-line poderão ser reinicializados e entrar novamente no cluster, mesmo que você desative ou exclua a chave de armazenamento pelo tempo especificado.

Para reverter um cluster ou um pool de nós para usar um Google-owned and Google-managed encryption key, use a flag --use-google-managed-key, conforme descrito em uma das seguintes opções:

Para mais informações, consulte Chaves de criptografia gerenciadas pelo cliente (CMEK) na documentação do Cloud KMS.

Recuperação e backups de dados

Você é responsável por manter backups redundantes de todos os dados que escolher armazenar no hardware conectado ao Distributed Cloud e exportar esses dados quando decidir devolver o hardware conectado ao Distributed Cloud ao Google ou ao integrador de sistemas (SI) certificado pelo Google que vendeu o hardware.

Se ocorrer uma falha no hardware do Distributed Cloud Connected e o Google ou um SI certificado pelo Google realizar reparos no local, todas as mídias de armazenamento serão removidas da máquina do Distributed Cloud Connected em manutenção e serão colocadas sob sua custódia durante o reparo ou serão apagadas com segurança e enviadas para destruição.

Se você comprou o hardware do Distributed Cloud de um SI certificado pelo Google e não está mais usando o Distributed Cloud, mas optou por manter e reutilizar o hardware, o SI vai limpar todo o software do Google e seus dados do hardware do Distributed Cloud durante o desativamento.

Segurança de rede

O tráfego de rede entre o hardware conectado do Distributed Cloud e Google Cloud é criptografado usando túneis MASQUE ou TLS que usam certificados por máquina. O Distributed Cloud Connected gira automaticamente esses certificados em uma programação regular.

Os requisitos da sua empresa e a política de segurança de rede da organização determinam as etapas necessárias para proteger o tráfego de rede que entra e sai da instalação conectada do Distributed Cloud. Além disso, recomendamos o seguinte:

  • Permita apenas conexões de entrada com pools de endereços IP virtuais expostos pelo balanceador de carga integrado do Distributed Cloud Connected e com sub-redes do Distributed Cloud.

  • Não permitir conexões de entrada de recursos de rede externos para sub-redes que atendem às camadas de gerenciamento do sistema e gerenciamento de serviços.

  • Não permitir conexões de entrada de recursos de rede externa para endereços IP de endpoints do plano de controle local. Para mais informações, consulte Modo de capacidade de sobrevivência.

Para mais informações sobre como preparar sua rede local para conectar hardware do Distributed Cloud, consulte Redes.

A seguir