Este documento fornece detalhes sobre o trânsito de criptografia com isolamento físico do Google Distributed Cloud (GDC).
Resumo para CIOs
- A GDC emprega várias medidas de segurança para garantir a autenticidade, a integridade e a confidencialidade dos dados em trânsito.
- Dependendo da conexão que está sendo feita, o GDC aplica proteções padrão aos dados em trânsito para componentes do GDC. Por exemplo, protegemos as comunicações entre o usuário e o gateway de entrada do GDC Cloud Service Mesh usando TLS.
Introdução
A segurança é frequentemente um fator decisivo na escolha de um provedor de nuvem. No Google, a segurança é nossa maior prioridade. Trabalhamos incansavelmente para proteger seus dados, estejam eles viajando pela sua rede, movimentando-se pela infraestrutura do Google ou armazenados em nossos servidores.
A autenticação, a integridade e a criptografia, tanto para dados em repouso quanto em trânsito, estão no centro da estratégia de segurança do Google. Neste documento, descrevemos nossa abordagem para criptografia em trânsito no Google Distributed Cloud com isolamento físico (GDC).
Para dados em repouso, consulte Criptografia em repouso. Você também pode ter uma visão geral de toda a segurança do Google no artigo Visão geral do esquema de segurança da infraestrutura do Google.
Público-alvo:este documento é destinado a CISOs e equipes de operações de segurança que usam ou consideram usar o GDC.
Pré-requisitos: além desta introdução, supomos que o leitor tenha algum conhecimento sobre criptografia e primitivas criptográficas.
Autenticação, integridade e criptografia
A GDC emprega várias medidas de segurança para garantir a autenticidade, a integridade e a confidencialidade dos dados em trânsito.
- Autenticação:autenticamos o destino dos dados na camada de rede. A origem é autenticada pelo AIS gerenciado pelo GDC.
- Integridade:verificamos se os dados enviados chegam inalterados ao destino e se estão protegidos contra mudanças não autorizadas.
- Criptografia:tornamos os dados ilegíveis durante o trânsito, para mantê-los confidenciais. A criptografia é o processo em que dados legíveis (texto simples) ficam ilegíveis (texto criptografado) para serem acessados somente por pessoas autorizadas pelo proprietário. Os algoritmos usados no processo de criptografia são públicos, mas a chave necessária para descriptografar o texto criptografado é particular. Geralmente, a criptografia em trânsito faz uso da troca de chaves assimétricas, como de Diffie-Hellman, baseada em curva elíptica, para estabelecer uma chave simétrica compartilhada que será usada na criptografia dos dados. Para mais informações sobre criptografia, consulte Introdução à criptografia moderna.
A criptografia pode ser usada para proteger dados em vários estados:
- A criptografia em repouso protege os dados contra comprometimento do sistema ou exfiltração de dados criptografando os dados enquanto armazenados. O padrão de criptografia avançada (AES) é usado com frequência para criptografar dados em repouso.
- Criptografia em trânsito:protege os dados caso a comunicação seja interceptada durante a transmissão dos dados entre um site e um provedor de nuvem ou entre dois serviços. Essa proteção é feita pela criptografia dos dados antes da transmissão, autenticação dos endpoints e, na chegada, descriptografia e verificação de que os dados não foram modificados. Por exemplo, muitas vezes, usamos o protocolo Transport Layer Security (TLS) para criptografar dados em trânsito e garantir a segurança de transporte e as Secure/Multipurpose Internet Mail Extensions (S/MIME) para proteger mensagens de e-mail.
A criptografia é um componente de uma estratégia de segurança mais ampla. A criptografia em trânsito tem o propósito de proteger os dados contra ataques após o estabelecimento e a autenticação de uma conexão, ao:
- acabar com a necessidade de confiar nas camadas mais inferiores da rede que normalmente são fornecidas por terceiros;
- reduzir a superfície de ataques em potencial;
- impedir que invasores acessem os dados em caso de interceptação das comunicações.
Ao promover autenticação, integridade e criptografia adequadas, é possível proteger os dados transmitidos entre usuários, dispositivos ou processos em um ambiente perigoso. O restante deste documento explica a abordagem da GDC quanto à criptografia de dados em trânsito e onde ela é aplicada.
Infraestrutura de rede do GDC
Limites físicos
Um limite físico é a barreira de um espaço físico controlado pelo Google ou em coordenação com ele, em que podemos garantir a aplicação das nossas rigorosas medidas de segurança. O acesso físico a esses locais é restrito, rigorosamente monitorado e auditado. Apenas um pequeno grupo de pessoas aprovadas tem acesso ao hardware. Os dados em trânsito dentro desses limites físicos geralmente são autenticados e criptografados.
Para comunicações que cruzam os limites físicos do GDC, usamos autenticação e criptografia fortes para proteger os dados em trânsito.
Como o tráfego é encaminhado
Para entender como a criptografia em trânsito funciona no GDC, é necessário explicar como o tráfego é encaminhado para e pelo GDC. Nesta seção, descrevemos como as solicitações são enviadas de um usuário final e chegam ao serviço adequado do GDC ou ao aplicativo do cliente, além de explicar como o tráfego é encaminhado entre serviços de diferentes sites.
Um serviço gerenciado pelo GDC é um serviço de nuvem privada modular. Esses serviços incluem computação, armazenamento e aprendizado de máquina. Por exemplo, o armazenamento de objetos do GDC é um serviço gerenciado pelo GDC. Um aplicativo do cliente é um aplicativo hospedado no GDC que você, como cliente do GDC, pode criar e implantar usando os serviços do GDC. Aplicativos de clientes ou soluções de parceiros hospedados no GDC não são considerados serviços gerenciados pelo GDC. Por exemplo, um aplicativo criado usando VMs do GDC, o Database Service e a Vertex AI é um aplicativo do cliente.
A Figura 1 mostra diferentes tipos de solicitações de encaminhamento. A Figura 1 mostra as interações entre os vários componentes de rede e as medidas de segurança aplicadas em cada conexão.
Figura 1: infraestrutura de conectividade entre sites
Do usuário final (rede do cliente) para a API GDC e o serviço gerenciado
Para serviços gerenciados hospedados em gateways de entrada do Cloud Service Mesh, eles aceitam solicitações da rede do cliente usando o gateway de entrada do Cloud Service Mesh. O gateway de entrada do Cloud Service Mesh faz proxy do tráfego HTTP(S) de entrada e encaminha e balanceia a carga do tráfego para os próprios serviços gerenciados pelo GDC. Outra camada de firewall oferece medidas contra ataques DDoS com detecção e prevenção de intrusões. Essa conexão é autenticada e criptografada do gateway de entrada do Cloud Service Mesh para o front-end do serviço gerenciado pelo GDC. A Figura 1 mostra essa interação como conexão A.
A maioria das APIs e dos serviços gerenciados do GDC são hospedados em gateways de entrada do Cloud Service Mesh. No entanto, alguns serviços são hospedados diretamente no balanceador de carga da camada 4 gerenciado pelo GDC. Por exemplo, os bancos de dados do DBS são hospedados em um balanceador de carga externo do GDC. Esses serviços são configurados para autenticar e criptografar conexões na camada de aplicativo usando TLS. A Figura 1 mostra essa interação como conexão B.
Do usuário final (rede do cliente) para um aplicativo do cliente hospedado no GDC
Há várias maneiras de encaminhar o tráfego da rede do cliente para um aplicativo do cliente hospedado no GDC. A forma como isso acontece depende da configuração do cliente.
Expor aplicativos de clientes pelo gateway de API do cliente
O GDC permite expor aplicativos de clientes pelo gateway de API do cliente. O serviço de gateway de API do cliente permite que os usuários desenvolvam, implantem, protejam, gerenciem e escalonem a API conforme necessário. A Figura 1 mostra essa interação como conexão C.
Expor cargas de trabalho de clientes em contêineres por um balanceador de carga externo do cliente
O GDC permite expor cargas de trabalho em contêineres gerenciadas pelo cliente usando um balanceador de carga externo. O GDC permite configurar políticas de entrada e saída para o pessoal correspondente. A Figura 1 mostra essa interação como conexão E.
Expor cargas de trabalho máquina virtual
O GDC permite expor máquinas virtuais criadas pelo cliente aos usuários finais. O GDC permite configurar políticas de entrada e saída para o pessoal correspondente. A Figura 1 mostra essa interação como conexão F.
Serviço de interconexão entre sites do GDC
O encaminhamento de um serviço gerenciado para outro geralmente ocorre inteiramente dentro do limite físico do GDC. Em alguns casos, como o backup entre sites, os dados são encaminhados para fora do limite físico do GDC. Nesse caso, os dados são criptografados na camada de aplicativo, por exemplo, TLS, e também na camada de rede. A Figura 1 mostra essa interação como conexão G.
De máquina virtual para máquina virtual
As conexões de VM para VM no GDC não são criptografadas no nível da rede. Os clientes são responsáveis por criptografar dados usando protocolos criptografados adequados ou tecnologias específicas, como túneis IPSec.
Criptografia em trânsito por padrão
O GDC usa vários métodos de criptografia de dados em trânsito, tanto por padrão como configuráveis pelo usuário. O tipo de criptografia depende da camada OSI, do tipo de serviço e do componente físico da infraestrutura. Nesta seção, descrevemos as proteções padrão que o Google usa para proteger dados em trânsito.
O restante desta seção descreve as proteções padrão que o Google usa para proteger dados em trânsito.
Criptografia do tráfego entre o usuário e o gateway de entrada do Cloud Service Mesh
Atualmente, muitos sistemas usam HTTPS para se comunicarem pela Internet. O HTTPS oferece segurança usando uma conexão TLS, o que garante a autenticidade, a integridade e a confidencialidade de solicitações e respostas. Para aceitar solicitações HTTPS, o receptor requer um par de chaves pública/privada e um certificado X.509 para que uma autoridade de certificação (CA) autentique o servidor. Com o par de chaves e o certificado, as solicitações do usuário na camada 7 (do aplicativo) ficam mais protegidas porque esses dois elementos comprovam que o receptor é o proprietário do nome do domínio de destino das solicitações. Nas subseções a seguir, discutimos os componentes da criptografia do usuário para o gateway de entrada do Cloud Service Mesh: TLS, BoringSSL e autoridade de certificação configurável do GDC.
Transport Layer Security (TLS)
Quando você envia uma solicitação para um serviço do GDC, protegemos os dados em trânsito por meio de autenticação, integridade e criptografia, usando HTTPS com um certificado de uma autoridade de certificação confiável. Todos os dados que o usuário envia para o gateway de entrada do Cloud Service Mesh para o serviço gerenciado pelo GDC são criptografados em trânsito com Transport Layer Security (TLS). O gateway de entrada do Cloud Service Mesh negocia um protocolo de criptografia específico com o cliente, dependendo do que ele pode oferecer suporte. O gateway de entrada do Cloud Service Mesh do GDC aplica apenas algoritmos aprovados pelo FIPS para oferecer mais segurança.
BoringSSL
BoringSSL é uma implementação de código aberto do protocolo TLS, criada com base na OpenSSL, mantida pelo Google e compatível com essa interface. O Google criou a BoringSSL com base na OpenSSL para simplificar o uso interno e auxiliar essa biblioteca com os projetos do Chromium e do Android Open Source Project. O BoringCrypto, o núcleo da BoringSSL, foi validado quanto à conformidade com o FIPS 140-2 nível 1.
O TLS no gateway de entrada do Cloud Service Mesh é implementado com o BoringSSL. A Tabela 1 mostra os protocolos de criptografia que o GDC aceita para se comunicar com os clientes.
| Protocolos | Autenticação | Troca de chaves | Criptografia | Funções de hash |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
Tabela 1: criptografia implementada no gateway de entrada do Cloud Service Mesh para serviços do GDC e na biblioteca criptográfica BoringSSL
Autoridade certificadora configurável do GDC
Como parte do TLS, um servidor precisa provar a identidade dele ao usuário quando recebe uma solicitação de conexão. Essa verificação é realizada no protocolo TLS quando o servidor apresenta um certificado contendo a identidade declarada. O certificado contém tanto o nome de host DNS quanto a chave pública do servidor. Depois de apresentado, o certificado é assinado por uma autoridade de certificação (CA) emissora de confiança do usuário que solicitou a conexão. Como resultado, os usuários que solicitam conexões com o servidor precisam somente confiar na CA raiz. Caso o servidor precise ser acessado universalmente, a CA raiz precisa ser conhecida por qualquer dispositivo cliente em potencial. Os navegadores e dispositivos clientes são configurados com um conjunto de CAs raiz confiáveis, com base no ambiente em que o cliente está operando.
A CA raiz do GDC depende do ambiente em que é implantada e dos requisitos dos clientes nesse ambiente.
Gateway de entrada do Cloud Service Mesh para front-ends de aplicativos
Dois casos:
- O gateway de entrada do Cloud Service Mesh encerra o TLS e reencripta o mTLS usando certificados do Istio do Cloud Service Mesh.
- mTLS do gateway de entrada para o front-end do aplicativo sidecar do Istio
- O gateway de entrada do Cloud Service Mesh encerra o TLS, criptografa novamente o TLS para outro servidor com a CA configurada.
Criptografia de rede do tráfego de armazenamento
No sistema de armazenamento de arquivos e blocos do GDC, o tráfego é encaminhado entre o aplicativo que usa o armazenamento e o serviço de armazenamento. Esses dados são autenticados e criptografados em trânsito usando IPSec. A criptografia do lado do cliente para o tráfego de armazenamento estará disponível em breve. O modo de transporte IPSec é usado entre o tráfego de arquivos e blocos para o host que precisa acessar o armazenamento. A autenticação é feita por uma chave pré-compartilhada gerada durante o processo e armazenada com segurança no GDC. Depois que as SAs IPsec são estabelecidas, as informações são trocadas usando o túnel IPsec. Os pacotes são criptografados e descriptografados usando a criptografia compatível com FIPS especificada na SA IPsec.
Autenticação, integridade e criptografia de serviço a serviço
Na infraestrutura do GDC, na camada de aplicativo (camada 7), usamos mTLS ou TLS para autenticação, integridade e criptografia de chamadas RPC do gateway de entrada do Cloud Service Mesh para um serviço e de um serviço do GDC para outro. Cada serviço executado no GDC funciona como uma identidade de conta de serviço com credenciais criptográficas associadas. Ao se comunicar por mTLS usando o Cloud Service Mesh, os serviços do GDC usam certificados de cliente para autenticar outros serviços. O Cloud Service Mesh verifica esses certificados usando uma autoridade de certificação interna. Ao se comunicar por TLS, por exemplo, com um servidor de API do Kubernetes do GDC, os serviços do GDC usam tokens de conta de serviço do Kubernetes para autenticar serviços. Os tokens de conta de serviço do Kubernetes são verificados usando as chaves públicas do emissor de tokens do servidor da API Kubernetes.