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.

O formato do rack conectado do Distributed Cloud tem os seguintes recursos de segurança:

  • O acesso ao hardware instalado no rack só é possível pelas portas dianteira e traseira.
  • O rack não pode ser desmontado com facilidade. Não há fixadores estruturais acessíveis externamente, como parafusos, porcas, fechos ou rebites.
  • As portas do rack são equipadas com fechaduras com chave. O Google fornece uma cópia da chave e retém outra para proteção.
  • Em instalações com vários racks, todas as fechaduras são iguais.
  • As portas do rack têm malha metálica perfurada à prova de violação para ventilação.
  • Durante a instalação, o rack é parafusado com segurança ao piso do local de instalação usando os suportes e braçadeiras de transporte.

O formato do servidor conectado do Distributed Cloud tem os seguintes recursos de segurança:

  • Um sensor de intrusão. 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.

Se você tiver mais dúvidas sobre a segurança do rack físico, entre em contato com seu representante de vendas Google Cloud .

Segurança da plataforma

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

  • 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 do Distributed Cloud Connected é enviado com unidades de disco autoencriptadas (SEDs, na sigla em inglês). Os racks do Distributed Cloud conectado enviados antes de outubro de 2023 foram enviados com unidades de disco de estado sólido (SSD).

O Distributed Cloud Connected usa o Linux Unified Key Setup (LUKS) para criptografar os volumes lógicos em cada nó do Distributed Cloud Connected. 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, versão 1.10.0, 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.

Para implantações em vários racks, o Distributed Cloud Connected oferece suporte à segurança de controle de acesso à mídia (MAC) da camada 2 (L2 MACsec) no nível do frame Ethernet entre os switches agregadores no rack de base e os switches ToR nos racks autônomos.

Você precisa solicitar esse recurso ao pedir o hardware conectado do Distributed Cloud. Não é possível ativar depois que o Distributed Cloud Connected é implantado nas suas instalações.

O Distributed Cloud Connected usa MACsec para autenticar dispositivos Ethernet, verificar a integridade de cada frame Ethernet transmitido e criptografar cada frame transmitido.

Isso envolve o estabelecimento de um conjunto de chaves que são verificadas entre todos os dispositivos envolvidos em uma sessão de transporte Ethernet antes que o tráfego Ethernet possa fluir. Depois que o acordo de chaves é verificado, o remetente começa a marcar cada frame Ethernet transmitido com tags de segurança e valores de verificação de integridade que o destinatário verifica ao receber cada frame.

Cada dispositivo configurado com MACsec precisa ser autenticado e associado a uma associação de conectividade (CA, na sigla em inglês). Os membros da CA usam chaves de CA de longa duração (CAKs) para se identificar na rede. Ela é usada para gerar chaves de criptografia de sessão sempre que um membro da CA precisa trocar dados com outro membro na rede.

Políticas de MACsec do Distributed Cloud conectado

O Distributed Cloud Connected aplica as seguintes políticas de MACsec em todos os links Ethernet entre os switches agregadores de rack de base e os switches ToR de rack independente. Essas políticas não podem ser modificadas nem desativadas.

Configuração do MACsec

Toda a configuração do MACsec conectado ao Distributed Cloud, incluindo chaves de criptografia, é gerenciada pelo Google.

O Distributed Cloud Connected não permite pacotes não criptografados em todos os links Ethernet internos. Se uma sessão MACsec não puder ser negociada com êxito, o link Ethernet afetado será desativado automaticamente.

Chaveiro MACsec

Um keychain MACsec é o keystore que contém todas as chaves necessárias para um link Ethernet específico. Um keychain exclusivo é criado para uma interface de pacote. Cada keychain tem quatro chaves principais e uma chave alternativa. Cada chave primária tem 25% de validade.

Substituição do MACsec

O Distributed Cloud Connected configura uma chave de fallback do MACsec, além de quatro chaves principais para cada link Ethernet interno. Se o Distributed Cloud Connected não puder negociar uma sessão MACsec usando as chaves primárias, ele tentará negociar uma sessão substituta usando a chave substituta. A chave substituta não expira.

Rotação de chaves MACsec

O agregador conectado do Distributed Cloud e os switches ToR alternam as chaves MACsec principais imediatamente quando elas expiram. Para garantir uma rotação de chaves segura, cada chave anterior e seguinte em rotação tem uma sobreposição de ciclo de vida de cinco dias.

Chave de associação segura MACsec

O Distributed Cloud Connected usa uma chave de associação segura (SAK) MACsec gerada aleatoriamente para criptografar todos os frames Ethernet transmitidos por links Ethernet internos. O Distributed Cloud Connected realiza a nova geração de chaves com base no volume usando a numeração de pacotes estendida (XPN). A SAK é regenerada a cada 6 horas.

Use o seguinte comando para verificar o status do MACsec de um link Ethernet específico entre um switch agregador de rack de base e um switch ToR em um rack independente:

gcloud edge-cloud networking networks get-status default --location=REGION --zone=us-ZONE_NAME

Substitua:

  • REGION: a região do Google Cloud em que o projeto Google Cloud de destino foi criado.
  • ZONE_NAME: o nome da zona conectada de destino do Distributed Cloud.

O comando retorna uma saída semelhante a esta:

result:
  macsecStatusInternalLinks: SECURE

Os possíveis valores de status de vinculação são:

  • SECURE: a sessão MACsec está ativa no link de destino.
  • UNSECURE: a sessão do MACsec está inativa no link de destino.

A seguir