Este documento fornece detalhes sobre a encriptação de trânsito com isolamento de ar do Google Distributed Cloud (GDC).
Resumo ao nível de CIO
- O GDC usa várias medidas de segurança para ajudar a garantir a autenticidade, a integridade e a confidencialidade dos dados em trânsito.
- Consoante a ligação que está a ser feita, o GDC aplica proteções predefinidas aos dados em trânsito para os componentes do GDC. Por exemplo, protegemos as comunicações entre o utilizador e o gateway de entrada da malha de serviços na nuvem do GDC através do TLS.
Introdução
A segurança é muitas vezes um fator decisivo na escolha de um fornecedor de nuvem. Na Google, a segurança é extremamente importante. Trabalhamos incansavelmente para proteger os seus dados, quer estejam a viajar pela sua rede, a mover-se na infraestrutura da Google ou a ser armazenados nos nossos servidores.
A autenticação, a integridade e a encriptação são fundamentais para a estratégia de segurança da Google, tanto para os dados em repouso como em trânsito. Este documento descreve a nossa abordagem à encriptação em trânsito para o Google Distributed Cloud air-gapped (GDC).
Para dados em repouso, consulte o artigo Encriptação em repouso. Para uma vista geral de toda a segurança da Google, consulte o documento Vista geral do design de segurança da infraestrutura da Google.
Público-alvo: este documento destina-se a CISOs e equipas de operações de segurança que usam ou consideram usar o GDC.
Pré-requisitos: além desta introdução, pressupomos uma compreensão básica da encriptação e das primitivas criptográficas.
Autenticação, integridade e encriptação
O GDC usa várias medidas de segurança para ajudar a 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 pela AIS gerida pelo GDC.
- Integridade: garantimos que os dados que envia chegam ao destino sem alterações, ou seja, estão protegidos contra alterações não autorizadas.
- Encriptação: tornamos os seus dados ilegíveis durante a transmissão para os manter confidenciais. A encriptação é o processo através do qual os dados legíveis (texto simples) são tornados ilegíveis (texto cifrado) com o objetivo de garantir que o texto simples só é acessível por partes autorizadas pelo proprietário dos dados. Os algoritmos usados no processo de encriptação são públicos, mas a chave necessária para desencriptar o texto cifrado é privada. A encriptação em trânsito usa frequentemente a troca de chaves assimétricas, como o Diffie-Hellman baseado em curva elíptica, para estabelecer uma chave simétrica partilhada que é usada para a encriptação de dados. Para mais informações sobre a encriptação, consulte o artigo Introdução à criptografia moderna.
A encriptação pode ser usada para proteger dados em vários estados:
- A encriptação em repouso protege os seus dados contra uma violação do sistema ou a exfiltração de dados através da encriptação dos dados durante o armazenamento. A norma Advanced Encryption Standard (AES) é frequentemente usada para encriptar dados em repouso.
- Encriptação em trânsito: protege os seus dados se as comunicações forem intercetadas enquanto os dados se movem entre o seu site e o fornecedor de nuvem ou entre dois serviços. Esta proteção é alcançada através da encriptação dos dados antes da transmissão, da autenticação dos pontos finais e, à chegada, da desencriptação e da verificação de que os dados não foram modificados. Por exemplo, o Transport Layer Security (TLS) é frequentemente usado para encriptar dados em trânsito para segurança de transporte, e o Secure/Multipurpose Internet Mail Extensions (S/MIME) é frequentemente usado para encriptação de mensagens de email.
A encriptação é um componente de uma estratégia de segurança mais ampla. A encriptação em trânsito defende os seus dados, após o estabelecimento e a autenticação de uma ligação, contra potenciais atacantes através do seguinte:
- Eliminar a necessidade de confiar nas camadas inferiores da rede, que são normalmente fornecidas por terceiros
- Reduzir a potencial superfície de ataque
- Impedir que os atacantes acedam aos dados se as comunicações forem intercetadas
Com a autenticação, a integridade e a encriptação adequadas, os dados que circulam entre utilizadores, dispositivos ou processos podem ser protegidos num ambiente hostil. O resto deste documento explica a abordagem da GDC à encriptação de dados em trânsito e onde é aplicada.
Infraestrutura de rede da GDC
Limites físicos
Um limite físico é a barreira a um espaço físico que é controlado por ou em coordenação com a Google, onde podemos garantir que estão em vigor medidas de segurança rigorosas. O acesso físico a estas localizações é restrito, fortemente monitorizado e auditado. Apenas um pequeno conjunto de pessoal aprovado tem acesso ao hardware. Geralmente, os dados em trânsito dentro destes limites físicos são autenticados e encriptados.
Para a comunicação que atravessa os limites físicos do GDC, usamos uma autenticação e uma encriptação fortes para proteger os dados em trânsito.
Como o tráfego é encaminhado
Para compreender como funciona a encriptação em trânsito no GDC, é necessário explicar como o tráfego é encaminhado para o GDC e através deste. Esta secção descreve como os pedidos chegam de um utilizador final ao serviço GDC ou à aplicação do cliente adequados e como o tráfego é encaminhado entre serviços de vários sites.
Um serviço gerido pela GDC é um serviço de nuvem privada modular. Estes serviços incluem computação, armazenamento e aprendizagem automática. Por exemplo, o armazenamento de objetos do GDC é um serviço gerido pelo GDC. Uma aplicação do cliente é uma aplicação alojada no GDC que, como cliente do GDC, pode criar e implementar através dos serviços do GDC. As aplicações do cliente ou as soluções de parceiros alojadas no GDC não são consideradas serviços geridos pelo GDC. Por exemplo, uma aplicação que cria com VMs do GDC, o serviço de base de dados e a Vertex AI é uma aplicação do cliente.
A Figura 1 mostra diferentes tipos de pedidos de encaminhamento. A Figura 1 mostra as interações entre os vários componentes da rede e a segurança implementada para cada ligação.
Figura 1: infraestrutura de conetividade entre sites
Utilizador final (rede do cliente) para a API GDC e o serviço gerido
Para os serviços geridos alojados em gateways de entrada da malha de serviços na nuvem, estes aceitam pedidos da rede do cliente através do gateway de entrada da malha de serviços na nuvem. O gateway de entrada da Cloud Service Mesh encaminha o tráfego para HTTP(S) recebido e encaminha e equilibra a carga do tráfego para os próprios serviços geridos pela GDC. Outra camada de firewall oferece contramedidas contra ataques DDoS com deteção e prevenção de intrusões. Esta ligação é autenticada e encriptada a partir do gateway de entrada do Cloud Service Mesh para o front-end do serviço gerido pelo GDC. A Figura 1 mostra esta interação como associação A.
A maioria das APIs e dos serviços geridos do GDC estão alojados em gateways de entrada da malha de serviços na nuvem. No entanto, alguns serviços são alojados diretamente no equilibrador de carga da camada 4 gerido pelo GDC. Por exemplo, as bases de dados DBS estão alojadas num balanceador de carga externo do GDC. Estes serviços estão configurados para autenticar e encriptar ligações na camada de aplicação através do TLS. A Figura 1 mostra esta interação como ligação B.
Utilizador final (rede do cliente) a uma aplicação do cliente alojada no GDC
Existem várias formas de encaminhar tráfego da rede do cliente para uma aplicação do cliente alojada no GDC. A forma como o seu tráfego é encaminhado depende da sua configuração.
Exponha aplicações de clientes através do gateway da API de clientes
O GDC suporta a exposição de aplicações de clientes através do gateway de API de clientes. O serviço de gateway da API do cliente permite aos utilizadores desenvolver, implementar, proteger, gerir e dimensionar a API conforme necessário. A Figura 1 mostra esta interação como ligação C.
Exponha cargas de trabalho de clientes em contentores através do balanceador de carga externo do cliente
O GDC suporta a exposição de cargas de trabalho em contentores geridas pelo cliente através de um balanceador de carga externo. O GDC oferece a capacidade de configurar políticas de entrada e saída para o pessoal correspondente. A Figura 1 mostra esta interação como ligação E.
Exponha cargas de trabalho de máquinas virtuais
O GDC suporta a exposição de máquinas virtuais criadas pelo cliente aos utilizadores finais. O GDC oferece a capacidade de configurar políticas de entrada e saída para o pessoal correspondente. A Figura 1 mostra esta interação como ligação F.
Serviço de interligação entre sites da GDC
Normalmente, o encaminhamento de um serviço gerido para outro ocorre inteiramente dentro do limite físico do GDC. Em alguns casos, como a cópia de segurança entre sites, os dados são encaminhados para fora do limite físico do GDC. Nesse caso, os dados são encriptados na camada de aplicação, por exemplo, TLS, e também podem ser encriptados na camada de rede. A Figura 1 mostra esta interação como ligação G.
Máquina virtual para máquina virtual
As ligações de VM para VM no GDC não estão encriptadas ao nível da rede. Os clientes são responsáveis pela encriptação de dados através de protocolos encriptados adequados ou tecnologias específicas, como túneis IPSecs.
Encriptação em trânsito por predefinição
O GDC usa vários métodos de encriptação, predefinidos e configuráveis pelo utilizador, para os dados em trânsito. O tipo de encriptação usado depende da camada OSI, do tipo de serviço e do componente físico da infraestrutura. Esta secção descreve as proteções predefinidas que a Google usa para proteger os dados em trânsito.
O resto desta secção descreve as proteções predefinidas que a Google usa para proteger os dados em trânsito.
Encriptação do gateway de entrada do Cloud Service Mesh de utilizador para utilizador
Atualmente, muitos sistemas usam HTTPS para comunicar através da Internet. O HTTPS oferece segurança através de uma ligação TLS, que garante a autenticidade, a integridade e a confidencialidade dos pedidos e das respostas. Para aceitar pedidos HTTPS, o recetor requer um par de chaves pública/privada e um certificado X.509 para autenticação do servidor de uma autoridade de certificação (AC). O par de chaves e o certificado ajudam a autenticar os pedidos de um utilizador na camada de aplicação (camada 7), comprovando que o destinatário é proprietário do nome de domínio para o qual os pedidos se destinam. As subsecções seguintes abordam os componentes da encriptação do utilizador para o gateway de entrada do Cloud Service Mesh, nomeadamente: TLS, BoringSSL e autoridade de certificação configurável da GDC.
Transport Layer Security (TLS)
Quando envia um pedido a um serviço da GDC, protegemos os dados em trânsito, fornecendo autenticação, integridade e encriptação através de HTTPS com um certificado de uma autoridade de certificação fidedigna. Todos os dados que o utilizador envia para o gateway de entrada do Cloud Service Mesh para o serviço gerido pela GDC são encriptados em trânsito com o Transport Layer Security (TLS). O gateway de entrada do Cloud Service Mesh negoceia um protocolo de encriptação específico com o cliente, consoante o que o cliente pode suportar. O gateway de entrada da malha de serviços na nuvem da GDC aplica apenas algoritmos aprovados pela FIPS para oferecer uma segurança mais forte.
BoringSSL
O BoringSSL é uma implementação de código aberto do protocolo TLS, mantida pela Google, derivada do OpenSSL, que é maioritariamente compatível com a interface do OpenSSL. A Google criou uma ramificação do BoringSSL a partir do OpenSSL para simplificar o OpenSSL, tanto para utilização interna como para suportar melhor os projetos open source do Chromium e Android. O BoringCrypto, o núcleo do BoringSSL, foi validado para o nível 1 da FIPS 140-2.
O TLS no gateway de entrada da malha de serviços na nuvem é implementado com o BoringSSL. A Tabela 1 mostra os protocolos de encriptação que o GDC suporta quando comunica com os clientes.
| Protocolos | Autenticação | Troca de chaves | Encriptação | Funções 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: encriptação implementada no gateway de entrada da malha de serviços na nuvem para serviços GDC e implementada na biblioteca criptográfica BoringSSL
Autoridade de certificação configurável da GDC
Como parte do TLS, um servidor tem de provar a sua identidade ao utilizador quando recebe um pedido de ligação. Esta validação de identidade é alcançada no protocolo TLS através da apresentação de um certificado pelo servidor que contém a sua identidade reivindicada. O certificado contém o nome de anfitrião DNS do servidor e a respetiva chave pública. Uma vez apresentado, o certificado é assinado por uma autoridade de certificação (CA) emissora que é fidedigna para o utilizador que pede a ligação. Como resultado, os utilizadores que pedem ligações ao servidor só precisam de confiar na AC raiz. Se o servidor quiser ser acedido de forma ubíqua, a AC raiz tem de ser conhecida por qualquer potencial dispositivo cliente. Os navegadores e os dispositivos cliente são configurados com um conjunto de ACs de raiz em que confiam, com base no ambiente em que o cliente está a operar.
A AC raiz do GDC depende do ambiente no qual é implementado e dos requisitos dos clientes nesse ambiente.
Gateway de entrada do Cloud Service Mesh para front-ends de aplicações
Dois casos:
- O gateway de entrada do Cloud Service Mesh termina o TLS e volta a encriptar o mTLS através de certificados do Cloud Service Mesh Istio
- mTLS do gateway de entrada para a interface da aplicação Istio Sidecar
- O Cloud Service Mesh Ingress Gateway termina o TLS, volta a encriptar o TLS para outro servidor com a AC configurada.
Encriptação de rede do tráfego de armazenamento
No sistema de armazenamento de blocos e ficheiros do GDC, o tráfego é encaminhado entre a aplicação que usa o armazenamento e o serviço de armazenamento. Esses dados são autenticados e encriptados em trânsito através do IPSec. A encriptação por parte do cliente para o tráfego de armazenamento vai estar disponível em breve. O modo de transporte IPSec é usado entre o tráfego de ficheiros e blocos para o anfitrião que precisa de aceder ao armazenamento. A autenticação é feita através de uma chave pré-partilhada gerada no voo e armazenada de forma segura no GDC. Assim que as SAs IPSec estiverem estabelecidas, as informações são trocadas através do túnel IPSec. Os pacotes são encriptados e desencriptados através da criptografia compatível com FIPS especificada na SA IPSec.
Autenticação, integridade e encriptação de serviço a serviço
Na infraestrutura do GDC, na camada de aplicação (camada 7), usamos mTLS ou TLS para a autenticação, a integridade e a encriptação de chamadas RPC do gateway de entrada da Cloud Service Mesh para um serviço e de um serviço do GDC para outro serviço do GDC. Cada serviço executado no GDC é executado como uma identidade de conta de serviço com credenciais criptográficas associadas. Quando comunicam através do mTLS através da Cloud Service Mesh, os serviços da GDC usam certificados de cliente para fazer a autenticação noutros serviços. O Cloud Service Mesh valida estes certificados através de uma autoridade de certificação interna. Quando comunicam através de TLS, por exemplo, com um servidor da API Kubernetes do GDC, os serviços do GDC usam tokens de contas de serviço do Kubernetes para autenticar os serviços. Os tokens de contas de serviço do Kubernetes são validados através das chaves públicas do emissor de tokens do servidor da API Kubernetes.