Este documento fornece detalhes sobre o trânsito de criptografia isolado do Google Distributed Cloud (GDC).
Resumo para CIOs
- O 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 Cloud Service Mesh do GDC 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 rede, passando 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:diretores de segurança da informação e equipes de operações de segurança que já utilizam ou querem utilizar 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 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, ou seja, 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 utilizados 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:
- 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, na sigla em inglês) 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 é alcançada criptografando os dados antes da transmissão, autenticando os endpoints e, na chegada, descriptografando e verificando se 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 do GDC quanto à criptografia de dados em trânsito e onde a aplicamos.
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 pessoal aprovado tem acesso ao hardware. Os dados em trânsito dentro desses limites físicos geralmente são autenticados e criptografados.
Para comunicação que cruza ou sai 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 é 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 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 armazenamento de objetos do GDC é um serviço gerenciado pelo GDC. Um aplicativo do cliente é um aplicativo hospedado no GDC que você, como nosso cliente, 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, quando você cria um aplicativo usando VMs do GDC, o Database Service e a Vertex AI, ele é considerado um aplicativo do cliente.
A Figura 1 mostra diferentes tipos de solicitações de roteamento. 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 e o serviço gerenciado do GDC
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 encaminha o tráfego de solicitações HTTP(S) recebidas e encaminha e balanceia a carga de tráfego para os próprios serviços gerenciados pelo GDC. Outra camada de firewall fornece contramedidas de ataque DDoS com detecção e prevenção de intrusão. 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 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 encaminhar o tráfego da rede do cliente para um aplicativo do cliente hospedado no GDC. A maneira como o tráfego é encaminhado depende da sua configuração.
Expor aplicativos do cliente pelo gateway de API do cliente
O GDC oferece suporte à exposição de 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 de clientes em contêineres pelo balanceador de carga externo do cliente
O GDC oferece suporte à exposição de cargas de trabalho em contêineres gerenciadas pelo cliente por meio 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 essa interação como conexão E.
Expor cargas de trabalho máquina virtual
O GDC oferece suporte à exposição de máquinas virtuais criadas pelo cliente para usuários finais. O GDC oferece a capacidade de 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 totalmente dentro do limite físico do GDC. Em alguns casos, como 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 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.
Máquina virtual para máquina virtual
As conexões entre VMs 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. Esta seção descreve 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 usuário para 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, na sigla em inglês) autentique o servidor. O par de chaves e o certificado ajudam a autenticar as solicitações de um usuário na camada do aplicativo (camada 7), comprovando que o receptor é o proprietário do nome de domínio de destino das solicitações. Nas subseções a seguir, discutimos os componentes do usuário na criptografia do gateway de entrada do Cloud Service Mesh: TLS, BoringSSL e a autoridade de certificação configurável do GDC.
Transport layer security (TLS)
Quando você envia uma solicitação para um serviço do GDC, nós 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 determinado protocolo de criptografia com o cliente, dependendo do que ele aceita. O gateway de entrada do Cloud Service Mesh do GDC aplica apenas algoritmos aprovados pelo FIPS para fornecer maior segurança.
BoringSSL
BoringSSL (em inglês) é uma ferramenta usada na implementação de código aberto do protocolo TLS. Ela foi 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. 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 os serviços do GDC na BoringSSL Cryptographic Library
Autoridade de certificação 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, na sigla em inglês) 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 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 criptografa novamente o TLS para algum 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 é 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 em tempo real 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
Dentro da infraestrutura do GDC, na camada do aplicativo (camada 7), usamos mTLS ou TLS para a 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 serviço do GDC. Cada serviço 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 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 token do servidor de API do Kubernetes.