Segurança

Este documento apresenta uma visão geral que abrange os principais conceitos, camadas e papéis operacionais para manter a segurança no Google Distributed Cloud (GDC) com isolamento físico. O GDC foi projetado para ambientes desconectados altamente seguros e para compliance com requisitos rigorosos de soberania de dados.

Este documento é destinado a públicos-alvo do grupo de operadores de infraestrutura, do grupo de administradores de plataforma e do grupo de operadores de aplicativos que gerenciam a segurança da organização. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

Este documento ajuda você a entender os principais atributos de segurança nas seguintes categorias:

• Compliance
• Operações de segurança
• Operações de confiabilidade
• Criptografia
• Gerenciamento de identidade e acesso (IAM)
• Segurança de rede
• Segurança para aplicativos
• Segurança de host e nó
• Segurança de hardware
• Segurança das instalações

Estratégia de segurança

O GDC adota uma abordagem que prioriza a segurança com várias camadas para oferecer o máximo de controle, manter a conformidade com as regulamentações legais e proteger dados confidenciais. Ele foi projetado para ser executado em hardware dedicado e seguro em um data center local para fornecer isolamento estrito de locatários.

As camadas de segurança fornecidas pelo GDC incluem segurança de hardware, segurança de host e nó, segurança para aplicativos, segurança de rede, criptografia, Identity and Access Management (IAM), operações de segurança e confiabilidade, compliance e ofertas de segurança.

O GDC tem um modelo de segurança compartilhada para proteger toda a pilha de aplicativos. O GDC oferece infraestrutura como serviço (IaaS), plataforma como serviço (PaaS) e software como serviço (SaaS). Em todas as configurações do GDC, o Google e o operador são responsáveis por proteger as camadas da infraestrutura. O cliente é responsável por proteger a configuração do projeto e a camada do aplicativo, incluindo os contêineres de aplicativos, as imagens de base e as dependências.

Do ponto de vista da segurança, os seguintes grupos de público-alvo operam o GDC:

• Grupo de operadores de infraestrutura: gerencia as operações diárias da infraestrutura do sistema e não tem acesso aos dados do cliente. Essa persona é o administrador de nível mais alto do sistema e pode ser o Google, um terceiro contratado ou o cliente, dependendo da natureza das restrições de soberania.

• Grupo de administradores da plataforma: um perfil de cliente que gerencia recursos e permissões para projetos. Esse é o nível mais alto de privilégios de administrador concedido ao cliente e é o único nível administrativo que pode conceder acesso aos dados do cliente.

• Grupo de operadores de aplicativos: desenvolve aplicativos para implantação e execução, além de configurar recursos e permissões granulares no GDC. Essa persona trabalha de acordo com as políticas estabelecidas pelo administrador da plataforma (PA) para garantir que os sistemas estejam alinhados aos requisitos de segurança e compliance do cliente.

Para mais informações, consulte Públicos-alvo da documentação.

Segurança das instalações

É possível implantar o GDC em data centers com isolamento físico designados pelo cliente. A segurança física específica do local varia de acordo com os requisitos individuais do cliente. Para obedecer às regulamentações locais, os data centers podem precisar de uma certificação, como a ISO 27001. O data center precisa ter várias medidas de segurança, como sistemas de defesa de perímetro seguros para impedir o acesso não autorizado ao data center, cobertura abrangente de câmeras para monitorar todas as atividades no data center, autenticação física para garantir que apenas pessoal autorizado possa acessar o data center, equipe de segurança para patrulhar o data center 24 horas por dia e todos os sete dias e responder a quaisquer incidentes de segurança, políticas rígidas de acesso e segurança para regular como o pessoal acessa e usa o data center. Essas medidas de segurança são uma camada inicial importante de proteção para proteger os dados armazenados no repositório de dados contra acesso, uso, divulgação, interrupção, modificação ou destruição não autorizados.

Segurança de hardware

O Google tem um processo rigoroso para garantir a segurança do hardware. Todo o hardware do GDC é comprado e montado por parceiros verificados e certificados para atender aos requisitos de soberania e cadeia de suprimentos específicos do cliente. O hardware é testado e aprovado para atender aos rigorosos padrões internos do Google e às necessidades da maioria dos clientes que se preocupam com a segurança. Todos os subcomponentes no hardware do GDC vêm de fornecedores confiáveis que são avaliados e conhecidos por serem confiáveis. A integração de hardware aos racks do GDC é feita em centros regionais certificados, que são instalações aprovadas pelo Google para lidar com hardware sensível. Todos os funcionários que lidam com o hardware do GDC passam por uma investigação de histórico para contratação, o que garante que apenas pessoas autorizadas tenham acesso ao hardware. Além disso, a implementação real de determinados componentes de hardware e firmware de alto risco é revisada por uma equipe dedicada. Essas análises consideram ameaças como: ataques à cadeia de suprimentos, ataques físicos e ataques de execução local em componentes de hardware e firmware, incluindo ameaças persistentes. Essas análises geram conhecimento que informa diretamente nossos requisitos de segurança de hardware, incluindo firmware seguro e atualizações de firmware, integridade de firmware, inicialização segura, gerenciamento e manutenção seguros. O Google mantém relações próximas com todos os fornecedores e equipes que usam o hardware para garantir que os recursos de segurança de nível superior sejam fornecidos. Isso significa que o Google trabalha constantemente com os parceiros para garantir que o hardware seja o mais seguro possível. O Google eleva o nível ao melhorar os requisitos de hardware e segurança, realizar análises de segurança interativas e trabalhar com as equipes de produtos para implementar novos recursos de segurança criados especificamente para o GDC e profundamente integrados não apenas ao hardware e firmware reais, mas também a outros recursos do produto.

Segurança de host e nó

O GDC garante que apenas nosso sistema operacional (SO) de nó seguro personalizado possa ser carregado nos sistemas por padrão. As imagens e configurações reforçadas reduzem bastante as superfícies de ataque. Os módulos criptográficos que protegem dados em repouso e em trânsito são validados pelo FIPS 140-2/3, o que significa que foram rigorosamente testados quanto à segurança e aprovados por um laboratório independente e credenciado. O GDC oferece software antimalware para o sistema operacional em execução nos nós bare metal e uma solução para verificar os sistemas de armazenamento. O Google empacota atualizações para esses scanners, que são incluídas nas atualizações regulares do sistema que o IO aplica usando o processo de upgrade do GDC. Os alertas de detecção são enviados para o IO. O GDC também oferece ferramentas de monitoramento de integridade e detecção de violações para proteger o sistema contra mudanças não intencionais. No geral, essas medidas de segurança ajudam a proteger o sistema contra uma variedade de ataques. As medidas de segurança dificultam o acesso de invasores ao sistema, a exploração de vulnerabilidades e a instalação de malware.

Locação

O GDC é uma plataforma de nuvem gerenciada multilocatária semelhante à Google Cloud Platform. A arquitetura foi projetada para oferecer um isolamento forte entre locatários, fornecendo uma camada de proteção forte entre os usuários da nuvem e permitindo que os usuários atendam a padrões rigorosos de credenciamento de carga de trabalho. O GDC oferece dois níveis de isolamento de locatário. O primeiro nível, chamado de Organizações, oferece um forte isolamento físico de computação, e o segundo nível, Projetos, oferece opções de alocação de recursos mais refinadas por meio de separação lógica.

Nenhum servidor de computação físico é compartilhado entre as organizações, e as camadas do operador também mantêm a locação. As IOs não têm permissão para acessar as camadas da API Protected Audience. Da mesma forma, os AOs também não podem acessar as camadas de PA.

Segurança para aplicativos

Para proteger contra ataques à cadeia de suprimentos de software, todo o software do GDC é desenvolvido de acordo com os níveis da cadeia de suprimentos para artefatos de software (SLSA, na sigla em inglês), um framework de segurança da cadeia de suprimentos que o Google desenvolveu em parceria com organizações, incluindo o CNCF e a Linux Foundation.

O SLSA é uma lista de verificação de padrões e controles para evitar adulterações, melhorar a integridade e proteger pacotes na cadeia de suprimentos de software. Essa lista de verificação foi projetada para evitar exploits que atacam repositórios de código-fonte, sistemas de build e pacotes de dependências de terceiros.

Todo o código-fonte e as dependências do GDC são armazenados em um sistema de controle de versões do Google que é isolado e criptografado em data centers seguros do Google. Todo o código tem um histórico verificado e requer uma segunda pessoa para revisar as alterações de código antes que elas sejam aceitas no sistema de controle de versões.

As versões são entregues usando um sistema de orquestração de versões do Google que aproveita as ferramentas de teste automatizadas doGoogle Cloud Build e do Google para uma criação, teste e lançamento totalmente automatizados de imagens de contêiner e binários. Todos os builds são isolados, herméticos e definidos usando o princípio de build como código, e nenhum indivíduo tem acesso unilateral no processo de entrega de software.

Todas as imagens são verificadas em busca de vulnerabilidades usando vários scanners de segurança para aplicativos e são validadas em vários pontos usando uma combinação de assinaturas criptográficas e checksums SHA256. Cada versão contém uma lista de materiais de software (SBOM, na sigla em inglês) que inclui detalhes sobre os componentes de software, as dependências e as bibliotecas, além dos dados fornecidos.

Segurança de rede

Nesta seção, apresentamos uma visão geral da segurança de rede do GDC.

Rede física

Embora o GDC tenha sido projetado para ser usado em ambientes desconectados, na prática, é provável que os sistemas do GDC sejam conectados a um ambiente protegido mais amplo, conectado por uma rede privada interna do cliente, mas que permaneça desconectado da Internet pública.

Todo o tráfego de rede entre a rede privada do cliente e os sistemas do GDC passa por firewalls e sistemas de detecção e prevenção de intrusões (SDI/IPS). O firewall é a primeira linha de defesa para controlar o acesso ao sistema. O firewall e o SDI/IPS controlam o tráfego de entrada e saída com base em políticas de segurança configuráveis e usam o aprendizado de máquina para analisar automaticamente o tráfego e bloquear entradas não autorizadas. Por padrão, o sistema IDS/IPS inspeciona todas as comunicações de entrada e saída da infraestrutura. Os administradores de projetos também podem usar o sistema SDI/IPS para a própria inspeção de tráfego de carga de trabalho. Os firewalls e o SDI/IPS também são integrados à pilha de observabilidade da organização para cargas de trabalho de clientes e à pilha de SIEM da IO para a infraestrutura, permitindo análises de segurança e perícia adicionais.

Os firewalls aplicam regras de negação padrão como a postura de segurança inicial para evitar acessos não intencionais e vazamentos de dados. O IO e o PA têm métodos para definir outras regras de acesso, conforme necessário. No GDC, há duas redes fisicamente separadas para isolar as funções de administração e controle dos dados de carga de trabalho do cliente.

A rede de gerenciamento fora de banda (OOB, na sigla em inglês) é usada apenas para funções administrativas, como alterações de configuração dos dispositivos de rede, dispositivos de armazenamento e outros componentes de hardware. Somente o IO tem acesso à rede OOB, e apenas em casos excepcionais. As ACLs de rede são configuradas de modo que apenas os servidores que estão no cluster de admin raiz que o IO controla tenham acesso a essa rede. A rede do plano de dados conecta os servidores de carga de trabalho e pode ser acessada pelo PA e pelos AOs.

Rede definida por software

A rede do plano de dados é uma rede de sobreposição baseada em roteamento e encaminhamento virtual (VRF, na sigla em inglês) para isolamento de tráfego de locatários. Cada organização de locatário tem uma rede VRF externa e interna. Os serviços voltados para o exterior, por exemplo, o balanceador de carga externo e o NAT de saída, estariam no domínio externo. As cargas de trabalho do cliente residem na VRF interna.

A rede interna é usada para comunicação dentro do locatário, como tráfego de carga de trabalho entre nós e para armazenamento de arquivos e armazenamento em blocos dentro da organização. A rede externa é usada para comunicação fora de uma organização. O tráfego de gerenciamento de locatários para funções de controle de acesso ou o tráfego de clientes para acessar projetos precisam passar pela rede externa. Cada carga de trabalho do cliente tem balanceadores de carga e gateways NAT para configurar o tráfego de entrada e saída.

Rede virtual

A rede GDC Virtual é uma camada de rede no nível da organização criada sobre a rede de sobreposição. Ele é alimentado pelo driver de interface de rede de contêiner (CNI) gerenciado pelo GDC: plano de dados de rede do Anthos.

A camada de rede virtual no GDC fornece um isolamento flexível dentro da organização, que é chamado de "projeto". Essa camada oferece os seguintes recursos de segurança de rede:

• Política de rede do projeto: para proteção de limites do projeto.
• Política de rede da organização: para proteção de limites da organização.

As políticas de rede do projeto e da organização têm uma configuração de negação padrão como ponto de partida para proteger contra acesso não intencional e vazamento de dados.

Proteção contra negação de serviço

Todo o tráfego para o GDC passa pelo SDI/IPS e por um conjunto de balanceadores de carga. O IDS/IPS detecta e descarta o tráfego não autorizado e protege os recursos contra sobrecargas de sessão. Os balanceadores de carga podem limitar o tráfego adequadamente para evitar a perda de serviço. Como qualquer conectividade externa é processada pela rede privada do cliente, ele pode fornecer uma camada extra de proteção contra ataques distribuídos de negação de serviço.

Criptografia

Nesta seção, apresentamos uma visão geral da criptografia do GDC.

PKI

O GDC fornece uma infraestrutura de chave pública (PKI, na sigla em inglês) para o gerenciamento centralizado de AC X.509 para serviços de infraestrutura. Por padrão, o GDC tem CAs raiz particulares por instalação e intermediários e folhas distribuídos a partir delas. Além disso, o GDC pode oferecer suporte à instalação de certificados emitidos pelo cliente em endpoints voltados para o cliente, o que aumenta a flexibilidade no uso de certificados. O GDC coordena de forma centralizada a distribuição de repositórios de confiança, o que facilita a autenticação e a criptografia do tráfego de aplicativos por cargas de trabalho e serviços do sistema. No geral, o GDC oferece uma solução de PKI eficiente para proteger uma variedade de serviços de infraestrutura para um gerenciamento de confiança conveniente, mas rigorosamente controlado.

Serviço de gerenciamento de chaves

O GDC fornece um serviço de gerenciamento de chaves (KMS) apoiado por módulos de segurança de hardware (HSMs). O KMS é um serviço próprio. O material da chave permanece no KMS, que, por sua vez, é protegido por HSMs. As definições de recursos personalizados (CRDs) contêm material de chave criptografado. Somente o KMS tem acesso ao material de chave bruta na memória. Há um KMS por organização. Todos os dados em repouso são criptografados por padrão usando chaves com suporte de HSM. Os clientes também podem gerenciar as próprias chaves criptográficas. O KMS é compatível com algoritmos aprovados pelo FIPS e módulos validados pelo FIPS. O KMS é compatível com a importação e exportação de chaves de maneira segura para casos de uso de chave em garantia, exclusão ou recuperação de desastres. Esses recursos tornam o KMS uma maneira segura e confiável de gerenciar chaves criptográficas.

O GDC também oferece chaves de criptografia gerenciadas pelo cliente (CMEK). A CMEK dá aos clientes controle sobre as chaves que protegem os dados em repouso no GDC. Uma das principais motivações para a adoção de CMEK é a exclusão criptográfica, um método de destruição de dados de alta garantia para correção de vazamento de dados e desativação. As chaves podem ser excluídas fora de banda dos dados que protegem. Todos os dados da sua organização são protegidos por um conjunto de CMEKs que os operadores de plataforma podem monitorar, auditar e excluir conforme necessário. As chaves CMEK são chaves de criptografia que podem ser gerenciadas usando APIs do HSM. A CMEK pode ser usada para criptografar os dados de armazenamento em blocos, discos de máquina virtual, serviço de banco de dados e cargas de trabalho de contêiner do usuário.

Criptografia

Nesta seção, apresentamos uma visão geral da criptografia do GDC.

Dados em repouso

Todos os dados do GDC armazenados em arquivos, blocos e repositórios de objetos são criptografados em repouso usando vários níveis de criptografia. Em ambientes multilocatários, os dados de cada locatário são criptografados com uma chave específica antes de serem gravados no armazenamento de arquivos, blocos e repositório de objetos:

• O armazenamento em blocos (volumes de aplicativos, discos de VM, armazenamento de banco de dados) é criptografado em três níveis:
  • Camada de software: criptografia do Linux Unified Key Setup (LUKS) realizada em hardware de computação dedicado ao locatário com chaves por volume com suporte de HSM, gerenciadas pelo cliente.
  • Camada do dispositivo: criptografia no nível do agregado de volume (NVE/NAE) realizada no dispositivo de armazenamento com chaves por locatário, com suporte de HSM, gerenciadas pelo cliente.
  • Camada de disco: unidades de disco com criptografia automática (SEDs, na sigla em inglês) com chaves por unidade de disco, com suporte de HSM, gerenciadas pela IO.
• O repositório de objetos é criptografado em duas camadas
  • Camada de bucket: criptografia de dados de objetos coordenada no hardware de computação dedicado ao locatário com chaves por bucket, apoiadas por HSM, gerenciadas pelo cliente.
  • Camada de disco: SEDs com chaves por unidade, apoiadas por HSM, gerenciadas pela E/S.
• O armazenamento em disco do servidor, os dados de configuração do sistema para um único locatário, é criptografado em uma camada:
  • Camada de disco: SEDs com chaves por unidade, com suporte de HSM, gerenciadas pelo cliente.

Dados em trânsito

Todo o tráfego do GDC é criptografado por padrão usando módulos criptográficos certificados pelo FIPS 140-2 e protocolos padrão do setor, como TLS 1.2+, HTTPS e túneis IPSec. Os clientes também precisam usar algoritmos de criptografia na camada do aplicativo, com base no modelo de responsabilidade compartilhada, para garantir que os requisitos de criptografia sejam atendidos para todos os aplicativos implantados no GDC.

Identity and Access Management (IAM)

O acesso ao sistema é baseado no princípio de privilégio mínimo. Os usuários só têm acesso aos recursos de que precisam. Esse processo protege o sistema contra acesso não autorizado e uso indevido. Além disso, o sistema aplica a segregação de funções, como nenhum acesso unilateral. Ninguém tem controle total sobre um sistema ou processo. Esse processo ajuda a evitar fraudes e erros. O GDC pode ser integrado ao provedor de identidade atual dos clientes. O sistema é compatível com SAML 2.0 e OIDC para federação de IdP. Esse suporte permite que os usuários autentiquem os usuários no sistema usando o provedor de identidade atual para gerenciar usuários em um só local. Todos os usuários e cargas de trabalho são autenticados antes de acessar o sistema. O RBAC e o ABAC são usados para autorizar todo o plano de controle e o acesso aos dados. Os usuários só podem acessar os recursos e realizar ações se forem autenticados e autorizados. Todos os acessos são registrados em auditoria, o que permite que os administradores acompanhem quem acessou um recurso e quando. Esse processo ajuda a identificar acessos não autorizados e uso indevido.

Operações de segurança

As operações de segurança (SecOps) do GDC oferecem garantia de informações para entidades com requisitos rigorosos de segurança, compliance e soberania para oferecer o máximo de confidencialidade, integridade e disponibilidade operacional de cargas de trabalho regulamentadas com isolamento físico do cliente. Essa arquitetura de segurança tem como objetivo atender aos seguintes objetivos:

• Correlacionar os registros da plataforma do GDC para análise e resposta de segurança.
• Identifique, relate e rastreie vulnerabilidades de segurança de forma rápida.
• Defenda todos os recursos do OIC e do GDC com a detecção e resposta de endpoints (EDR, na sigla em inglês).
• Fornecer ferramentas, processos e runbooks para permitir que o centro de operações de SecOps monitore continuamente a identificação, contenção, erradicação e recuperação de incidentes de cibersegurança.

Recurso	Descrição
Gerenciamento de eventos e informações de segurança	O Elastic Security é uma plataforma de gerenciamento de eventos e informações de segurança (SIEM) que coleta, indexa e analisa dados de segurança de várias fontes para ajudar as organizações a detectar e responder a ameaças.
Gestão de vulnerabilidades	O Tenable Security Center é uma plataforma de gestão de vulnerabilidades que ajuda as organizações a identificar e corrigir vulnerabilidades de segurança.
Detecção e resposta de endpoints	Elastic Security, Windows Defender e ClamAV. Plataformas de segurança unificadas que oferecem às organizações uma visão abrangente da postura de segurança para detectar e responder a ameaças de forma mais eficaz.
Gerenciamento seguro de casos	Uma solução de software que permite que as organizações gerenciem o ciclo de vida de incidentes de segurança.

O GDC SecOps permite que os IOs ofereçam funções de operações de segurança. A equipe de SecOps do GDC oferece processos orientados por pessoas, incluindo resposta a incidentes, gestão de vulnerabilidades, engenharia de segurança e gestão de riscos da cadeia de suprimentos. O GDC SecOps permite que uma central de operações de segurança (SOC) faça o seguinte:

Capacidade	Descrição
Detecção	Nossa infraestrutura de segurança monitora constantemente possíveis ameaças e vulnerabilidades. Quando uma ameaça ou vulnerabilidade é detectada, a equipe de operações de segurança recebe um relatório imediatamente.
Triagem	A equipe de operações de segurança faz a triagem de cada incidente para determinar a gravidade da ameaça e a resposta adequada.
Contenção	A equipe de operações de segurança toma medidas para conter a ameaça e impedir que ela se espalhe.
Investigação	A equipe de operações de segurança investiga o incidente para determinar a causa raiz e identificar quaisquer pontos fracos em nossa postura de segurança.
Resposta	A equipe de operações de segurança toma medidas para responder ao incidente e mitigar os danos causados.
Recuperação	A equipe de operações de segurança toma medidas para se recuperar do incidente e restaurar nossos sistemas e redes ao estado normal.

Gestão de vulnerabilidades

O GDC executa vários processos de identificação de vulnerabilidades no ambiente de pré-produção antes de qualquer lançamento para ficar por dentro de possíveis vulnerabilidades e exposições comuns (CVEs, na sigla em inglês). O GDC também oferece verificação de vulnerabilidades no ambiente de produção para fins de monitoramento e relatórios de rotina. Todas as descobertas no ambiente de produção são integradas aos processos de operações de segurança para rastrear e mitigar as finalidades de busca de ameaças.

Resposta a incidentes de segurança

Quando vulnerabilidades são descobertas no código implantado no GDC ou ocorre um incidente no sistema, um conjunto de processos de resposta a incidentes está disponível e é executado pelo IO e pela equipe de segurança do GDC para mitigar, criar e aplicar patches de segurança e se comunicar com as partes afetadas. Esse processo de gerenciamento de incidentes é semelhante ao processo padrão do Google, com modificações para a natureza desconectada do GDC.

Para cada CVE ou incidente descoberto, um comandante de incidente (IC, na sigla em inglês) é atribuído para executar o processo de resposta. O IC é responsável por gerenciar o processo, o que inclui verificar e validar o incidente, atribuir à vulnerabilidade uma pontuação do Sistema de Pontuação de Vulnerabilidade Comum (CVSS), gerenciar o processo de criar um patch e prepará-lo para entrega, além de criar as comunicações adequadas.

Operações de confiabilidade

Nesta seção, apresentamos uma visão geral das operações de confiabilidade do GDC.

Registrar e monitorar

O GDC é fornecido com uma plataforma de observabilidade que oferece funcionalidades de monitoramento, geração de registros, rastreamento e relatórios para a plataforma, os serviços e as cargas de trabalho do GDC.

O subsistema de geração de registros ingere e agrega registros de todas as plataformas e serviços principais do GDC e de cargas de trabalho do cliente em um banco de dados de série temporal e disponibiliza esses dados por meio de uma interface do usuário (UI) interativa e de APIs.

Os eventos críticos do registro de auditoria incluem as seguintes áreas:

• Solicitações de autenticação e autorização de usuários.
• Geração e revogação de tokens de autenticação.
• Todos os acessos e mudanças administrativas.
• Todas as ações da API do plano de controle.
• Todas as ocorrências de segurança, incluindo SDI, IPS, firewall e antivírus.

Acesso de implantação forçada

O IO não tem acesso aos dados do cliente. No entanto, em situações de emergência, pode haver casos em que o IO precisa de acesso aos dados do cliente. Nesses casos, o GDC tem um conjunto de procedimentos de acesso de emergência que um PA usa para conceder explicitamente acesso ao IO para solução de problemas.

Todas as credenciais de implantação forçada são armazenadas off-line em um cofre ou criptografadas com chaves com raiz no HSM. O acesso a essas credenciais é um evento auditável que pode acionar alertas.

Por exemplo, em um caso em que a configuração do IAM foi corrompida e impede o acesso do usuário, o IO usa uma autenticação com base no certificado SSH por meio de estações de trabalho protegidas e exige aprovação de várias partes para estabelecer o acesso. Todas as ações realizadas são rastreadas e auditáveis. As chaves SSH mudam após um incidente de acesso emergencial.

Recuperação de desastres

O GDC vem com um sistema de backup que permite que os PAs criem e gerenciem políticas de backup para clusters, namespaces ou VMs. O sistema de backup contém os sistemas típicos para programação, execução de backups, restauração de dados e geração de relatórios.

Fazer upgrade e atualizar o sistema

Como o GDC é um ambiente com isolamento físico, o operador de infraestrutura processa todas as atualizações nos sistemas do cliente. O Google assina e publica atualizações binárias em um local seguro para o IO fazer o download. O IO valida os binários e os move para o GDC para distribuição e implantação.

Esse sistema inclui todas as atualizações de software e firmware, incluindo atualizações para o software do GDC, o SO no nível do nó, definições e assinaturas de antivírus e malware, dispositivo de armazenamento e rede, atualizações de dispositivos e quaisquer outras atualizações binárias.

Gerenciamento de mudanças: infraestrutura como código

O GDC usa a infraestrutura como código (IaC) para automatizar o provisionamento e a implantação de configurações do GDC. A IaC separa as responsabilidades entre a equipe de operações de infraestrutura. Por exemplo, propor uma alteração de configuração em vez de autorizá-la, para tornar todo o processo mais seguro. Com a IaC do GDC, todas as mudanças de configuração são validadas por processos de revisão e aprovação de várias partes para garantir que apenas configurações autorizadas sejam implantadas. Essas revisões criam um processo transparente e auditável, melhoram a consistência das mudanças e reduzem o desvio de configuração.

Processos de compliance

O GDC está em conformidade com regimes comuns, como NIST 800-53, SOC 2, e ajuda em certificações como FIPS 140-2 e 3. O GDC também passa por vários processos de certificação e atende aos padrões de segurança do Google. A conformidade é um processo contínuo. Para ajudar clientes e operadores nessa jornada, o GDC oferece monitoramento e testes contínuos. Como parte das práticas de segurança para o processo de monitoramento contínuo, o GDC rastreia mudanças no inventário, como software e hardware desconhecidos ou a adição de novos softwares ou hardwares. O GDC realiza testes de penetração regulares simulando ataques de usuários maliciosos. O GDC verifica periodicamente os sistemas em busca de malware e alerta o GDC sobre qualquer infecção. O processo de teste de recuperação de desastres testa a capacidade do GDC de se recuperar de uma situação que envolve um desastre. Esses processos garantem que os dados e sistemas do GDC estejam seguros.

Conformidade com o Guia de Implementação Técnica de Segurança (STIG, na sigla em inglês)

De acordo com a regra STIG RHEL-08-040320, o pacote xorg-x11-server-common é uma dependência de sistema aprovada necessária para drivers de GPU NVIDIA e bibliotecas de aceleração de hardware (como Vulkan e Mesa). O serviço do gerenciador de exibição gráfica está desativado e inativo nas imagens do sistema operacional do nó.