Neste documento, apresentamos detalhes sobre o trânsito de criptografia com isolamento físico do Google Distributed Cloud (GDC).
Resumo para CIOs
- O GDC emprega várias medidas de segurança para ajudar a garantir a autenticidade, integridade e 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 os componentes do GDC. Por exemplo, protegemos as comunicações entre o usuário e o gateway de entrada do Cloud Service Mesh do GDC usando TLS.
Introdução
A segurança costuma ser um fator decisivo na escolha de um provedor de nuvem. No Google, a segurança é nossa maior prioridade. Trabalhamos incansavelmente para proteger seus dados, seja durante o tráfego pela rede, a movimentação na infraestrutura do Google ou o armazenamento nos nossos servidores.
A estratégia de segurança do Google tem como pilares a autenticação, a integridade e a criptografia, tanto para dados em repouso quanto em trânsito. Neste documento, descrevemos nossa abordagem de criptografia em trânsito para o 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 estão considerando 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
O GDC emprega várias medidas de segurança para ajudar a garantir a autenticidade, integridade e 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, ou seja, se estão protegidos contra alterações 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 respectivo proprietário. Os algoritmos usados no processo de criptografia são públicos, mas a chave necessária para descriptografar o texto criptografado é privada. A criptografia em trânsito geralmente usa a troca de chaves assimétricas, como o algoritmo de Diffie-Hellman baseado em curva elíptica, para estabelecer uma chave simétrica compartilhada que é usada para criptografar 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 por meio da criptografia durante o armazenamento, para que não sejam exfiltrados ou exfiltração de dados em caso de comprometimento do sistema. Frequentemente, usa-se o padrão de criptografia avançada (AES) 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 se dá com a criptografia dos dados antes da transmissão, na autenticação dos endpoints e, na chegada, com a descriptografia e a verificação para garantir que eles 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 protege seus dados, depois que uma conexão é estabelecida e autenticada, contra possíveis invasores:
- Eliminar a necessidade de confiar nas camadas inferiores da rede, que geralmente 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.
Com autenticação, integridade e criptografia adequadas, os dados que trafegam entre usuários, dispositivos ou processos podem ser protegidos em um ambiente hostil. O restante deste documento explica a abordagem do GDC para a 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 por ou em coordenação com o Google, 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 funcionários aprovados tem acesso ao hardware. Os dados em trânsito dentro desses limites físicos geralmente são autenticados e criptografados.
Para comunicações que entram ou saem do limite físico 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 é roteado para e pelo GDC. Nesta seção, descrevemos como as solicitações chegam de um usuário final ao serviço do GDC ou aplicativo do cliente apropriado e como o tráfego é roteado entre serviços de vários sites.
Um serviço gerenciado pelo GDC é um serviço de nuvem privada modular. Esses serviços incluem computação, armazenamento e machine learning. Por exemplo, o repositório 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 classificados como 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 a segurança em vigor para cada conexão.
Figura 1: infraestrutura de conectividade entre sites
Do usuário final (rede do cliente) para a API do 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 o proxy do tráfego HTTP(S) de entrada, além de rotear e balancear 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 é hospedada em gateways de entrada do Cloud Service Mesh. No entanto, alguns serviços são hospedados diretamente no balanceador de carga de 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 do 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 rotear 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 do cliente 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 em contêineres do cliente por meio do balanceador de carga externo do cliente
O GDC permite expor cargas de trabalho conteinerizadas gerenciadas pelo cliente usando um balanceador de carga externo. A 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 de máquina virtual
O GDC permite expor máquinas virtuais criadas pelo cliente para 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 roteamento de um serviço gerenciado para outro geralmente ocorre inteiramente dentro do limite físico do GDC. Em alguns casos, como backup entre sites, os dados são roteados para fora do limite físico do GDC. Nesse caso, os dados são criptografados na camada do aplicativo, por exemplo, TLS, e também podem ser criptografados 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 apropriados ou tecnologias específicas, como túneis IPSec.
Criptografia em trânsito por padrão
O GDC usa vários métodos de criptografia, tanto padrão quanto configuráveis pelo usuário, para dados em trânsito. O tipo de criptografia usado 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, que garante a autenticidade, integridade e confidencialidade das solicitações e respostas. Para aceitar solicitações HTTPS, o receptor precisa de um par de chaves pública/privada e um certificado X.509 para autenticação de servidor de uma autoridade de certificação (AC). O par de chaves e o certificado ajudam a autenticar as solicitações de um usuário na camada do aplicativo (camada 7), provando que o destinatário é o proprietário do nome de domínio para o qual as solicitações são destinadas. As subseções a seguir discutem os componentes da criptografia do usuário para o gateway de entrada do Cloud Service Mesh, ou seja: TLS, BoringSSL e autoridade certificadora 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, fornecendo 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 ao gateway de entrada do Cloud Service Mesh para o serviço gerenciado pelo GDC são criptografados em trânsito com o 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 aceitar. O gateway de entrada do Cloud Service Mesh do GDC aplica apenas algoritmos aprovados pelo FIPS para fornecer uma segurança mais forte.
BoringSSL
O BoringSSL é uma implementação de código aberto do protocolo TLS mantida pelo Google, bifurcada do OpenSSL, que é, em grande parte, compatível com a interface do OpenSSL. O Google bifurcou o BoringSSL do OpenSSL para simplificar o OpenSSL, tanto para uso interno quanto para oferecer melhor suporte aos projetos de código aberto do Chromium e do Android. O BoringCrypto, o núcleo do BoringSSL, foi validado para o nível 1 do FIPS 140-2.
O TLS no gateway de entrada do Cloud Service Mesh é implementado com o BoringSSL. A Tabela 1 mostra os protocolos de criptografia compatíveis com o GDC ao se comunicar com os clientes.
| Protocolos | Autenticação | Troca de chaves | Criptografia | 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: criptografia implementada no gateway de entrada do Cloud Service Mesh para serviços do GDC na biblioteca criptográfica da BoringSSL
Autoridade certificadora configurável do GDC
Como parte do TLS, um servidor precisa provar a identidade ao usuário quando recebe uma solicitação de conexão. Essa confirmação de identidade é feita no protocolo TLS, em que o servidor apresenta um certificado que contém 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. Se o servidor quiser ser acessado de qualquer lugar, a CA raiz precisa ser conhecida por qualquer dispositivo cliente em potencial. Os navegadores e dispositivos do cliente são configurados com um conjunto de CAs raiz em que confiam, 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 criptografa novamente 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 e o criptografa novamente para outro servidor, com a CA configurada.
Criptografia de rede do tráfego de armazenamento
No sistema de armazenamento de arquivos e armazenamento em blocos do GDC, o tráfego é roteado 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 que é gerada em tempo real e armazenada com segurança no GDC. Depois que as SAs do 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 do IPSec.
Autenticação, integridade e criptografia de serviço a serviço
Na infraestrutura do GDC, na camada do 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 é executado como uma identidade de conta de serviço com credenciais criptográficas associadas. Ao se comunicar por mTLS pelo Cloud Service Mesh, os serviços do GDC usam certificados do cliente para se autenticar em 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 se autenticar nos serviços. Os tokens da conta de serviço do Kubernetes são verificados usando as chaves públicas do emissor de tokens do servidor de API do Kubernetes.