Controles de base empresarial segura

Use a restrição booleana automaticIamGrantsForDefaultServiceAccounts para desativar as concessões automáticas de papéis quando os serviços do Cloud de Confiance by S3NS criam automaticamente contas de serviço padrão com papéis excessivamente permissivos.

Por padrão, alguns sistemas concedem permissões muito amplas a contas automatizadas, o que é um possível risco à segurança. Por exemplo, se você não aplicar essa restrição e criar uma conta de serviço padrão, ela vai receber automaticamente o papel de editor (roles/editor) no projeto. Se um invasor comprometer uma única parte do sistema, ele poderá assumir o controle de todo o projeto. Essa restrição desativa as permissões automáticas de alto nível, forçando uma abordagem mais segura e deliberada em que apenas as permissões mínimas necessárias são concedidas.

Use a restrição booleana iam.disableServiceAccountKeyCreation para desativar a criação de chaves de conta de serviço externas. Com essa restrição, é possível controlar o uso de credenciais de longo prazo não gerenciadas para contas de serviço. Quando essa restrição é definida, não é possível criar credenciais gerenciadas pelo usuário para contas de serviço em projetos afetados por ela.

Use a restrição booleana iam.disableServiceAccountKeyUpload para desativar o upload de chaves públicas externas para contas de serviço. Quando essa restrição é definida, os usuários não podem fazer upload de chaves públicas para contas de serviço em projetos afetados pela restrição.

O Google recomenda as chaves de segurança Titan para a verificação em duas etapas (2SV) em contas de superadministrador. No entanto, para casos de uso em que isso não é possível, recomendamos usar outra chave de segurança como alternativa.

Aplique a verificação em duas etapas (2SV) a uma unidade organizacional (UO) específica ou a toda a organização. Recomendamos que você crie uma UO para superadministradores e aplique a verificação em duas etapas nessa UO.

Não ter um único superadministrador ou administrador da organização. Crie uma ou mais contas de administrador de backup (até 20). Um único superadministrador ou administrador da organização pode resultar em cenários de bloqueio. Essa situação também acarreta um risco maior, já que uma pessoa pode fazer mudanças que alteram a plataforma, possivelmente sem supervisão.

Use o Privileged Access Manager para gerenciar o acesso privilegiado. Para todo o restante, use grupos de acesso, deixe as associações a grupos expirarem automaticamente e implemente um fluxo de trabalho de aprovação para associações a grupos.

Com o modelo de privilégio mínimo, você só concede acesso quando necessário e aos recursos necessários. O uso de papéis predefinidos simplifica o uso e reduz a expansão causada por papéis personalizados, para que você não precise se preocupar em gerenciar o ciclo de vida deles.

Decida qual será a fonte de verdade para provisionar identidades de usuário gerenciadas. Os padrões incluem a criação de identidades de usuário no Cloud Identity, a sincronização de identidades de um provedor de identidade atual ou o uso da Federação de identidade de colaboradores.

Aplique senhas fortes e exclusivas para todas as contas de usuário. Considere usar um gerenciador de senhas. Credenciais fracas ou inexistentes são um padrão comum que usuários maliciosos podem explorar facilmente.

Use papéis do Identity and Access Management (IAM) com base nas funções de trabalho para atribuir permissões aos usuários. As funções de trabalho são papéis predefinidos que permitem aos administradores fornecer um conjunto de permissões limitado a uma função de trabalho, melhorando a produtividade e reduzindo a necessidade de pedir permissões. Para se alinhar melhor aos requisitos da sua organização, crie papéis personalizados com base em papéis predefinidos.

Defina políticas para toda a organização e impeça a adição de membros externos aos Grupos do Google.

Por padrão, as contas de usuário externas podem ser adicionadas a grupos no Cloud Identity. Recomendamos que você defina configurações de compartilhamento para que os proprietários dos grupos não possam adicionar membros externos.

Essa restrição não se aplica à conta de superadministrador ou a outros administradores delegados com permissões de administrador do Google Grupos. Como a federação do seu provedor de identidade é executada com privilégios de administrador, as configurações de compartilhamento de grupo não se aplicam a essa sincronização de grupo. Recomendamos que você revise os controles no provedor de identidade e no mecanismo de sincronização para garantir que participantes que não sejam do domínio não sejam adicionados a grupos ou que você aplique restrições de grupo.

Defina a duração da sessão para os serviços Cloud de Confiance by S3NS para que ela expire pelo menos uma vez por dia. Manter uma conta conectada por um longo período é um risco de segurança. A imposição de uma duração máxima da sessão encerra automaticamente a sessão após um período definido, forçando um novo login seguro.

Essa prática reduz a oportunidade de um usuário malicioso usar uma senha roubada e garante que o acesso seja verificado regularmente.

Para novos clientes, uma duração de sessão padrão de 16 horas é aplicada automaticamente. Os clientes que criaram a organização Cloud de Confiance by S3NS antes de 2023 podem ter uma configuração padrão para nunca exigir a autenticação novamente. Revise essa configuração para garantir que você tenha uma política de reautenticação com uma duração de sessão de 1 a 24 horas. A política de reautenticação invalida o token de atualização e força o usuário a reautenticar regularmente a CLI gcloud com a senha ou a chave de segurança.

A duração da sessão dos serviços do Cloud de Confiance by S3NS é uma configuração diferente da duração da sessão dos Serviços do Google, que controla as sessões da Web para login em serviços do Google Workspace, mas não controla a reautenticação do Cloud de Confiance by S3NS. Se você usa os serviços do Google Workspace, defina a duração da sessão para ambos.

Não permita contas pessoais não gerenciadas. Consolide todas as contas pessoais não gerenciadas e considere uma solução para impedir a criação de mais contas pessoais não gerenciadas com seu domínio.

As contas pessoais não gerenciadas não são regidas pelos processos de admissão, movimentação e desligamento (JML, na sigla em inglês). Por isso, elas apresentam o risco de que um funcionário ainda tenha acesso aos seus recursos depois de sair do emprego. Essas contas também são tratadas como externas em relação a controles como o compartilhamento restrito de domínio.

Verifique se as contas de superadministrador estão separadas das contas de usuário do dia a dia. As contas de superadministrador precisam ser dedicadas e usadas apenas para fazer mudanças importantes. Para aumentar a segurança, ative a aprovação de outra parte para ações de administrador. Ao ativar a aprovação de outra parte, as ações sensíveis são aprovadas por dois administradores, o que ajuda a evitar que invasores comprometam uma conta de administrador e bloqueiem outros usuários administradores.

Ative a autenticação multifator (MFA), também conhecida como verificação em duas etapas (2SV), para todas as Contas do Google e usuários do Cloud Identity, não apenas para superadministradores. A MFA para superadministradores é ativada por padrão. A MFA adiciona outra camada de defesa porque as senhas sozinhas geralmente não são uma medida de segurança forte o suficiente.

Remova os papéis de Criador de projetos e Criador da conta de faturamento em todo o domínio, que são concedidos por padrão a todos os membros de uma nova organização.

As novas organizações concedem os papéis de criador de projetos e criador da conta de faturamento a todas as identidades de usuário gerenciadas no domínio. Embora essas funções sejam úteis para começar, essa configuração não é destinada a ambientes de produção. Permitir que as contas de faturamento se multipliquem aumenta a sobrecarga administrativa e tem consequências técnicas ao dividir serviços em várias contas de faturamento. Permitir a criação de projetos de forma livre pode levar a projetos que não seguem suas convenções de governança.

Em vez disso, remova essas funções e estabeleça um processo de criação de projetos para solicitar novos projetos e associá-los ao faturamento.

Se você precisar usar chaves de conta de serviço, troque-as pelo menos uma vez a cada 90 dias.

Um intervalo de rotação limita o tempo que um invasor pode ter acesso ao sistema. Sem um intervalo de rotação, o invasor tem acesso para sempre. Quando possível, use a federação de identidade da carga de trabalho em vez de chaves de conta de serviço.

Use a federação de identidade da carga de trabalho para permitir que sistemas de CI/CD e cargas de trabalho executadas em outras nuvens se autentiquem no Cloud de Confiance by S3NS. Com a federação de identidade da carga de trabalho, as cargas de trabalho executadas fora do Cloud de Confiance podem ser autenticadas sem precisar de uma chave da conta de serviço. Ao evitar chaves de conta de serviço e outras credenciais de longa duração, a federação de identidade da carga de trabalho pode ajudar a reduzir o risco de vazamento de credenciais.

Por padrão, a recuperação automática da conta de superadministrador fica desativada para novos clientes. No entanto, os clientes atuais podem ter essa configuração ativada. Desativar essa configuração ajuda a reduzir o risco de que um telefone ou e-mail comprometido ou um ataque de engenharia social possa permitir que um invasor receba privilégios de superadministrador sobre seu ambiente.

Planeje um processo interno para que um superadministrador entre em contato com outro superadministrador da organização se perder o acesso à conta e garanta que todos os superadministradores conheçam o processo de recuperação assistida por suporte.

Para desativar o recurso, acesse as configurações de recuperação de conta no Google Admin Console.

Defina o tempo limite da sessão inativa como 15 minutos para casos de uso sensíveis. Sessões inativas podem ser usadas por invasores para roubo de credenciais.

Se possível, forneça chaves de segurança de hardware para superadministradores ou administradores da organização como um segundo fator. As contas de superadministrador são os alvos de maior valor para ataques sofisticados. As chaves de segurança de hardware oferecem um alto nível de proteção porque são resistentes a phishing. As chaves de segurança de hardware são a defesa mais forte possível contra o sequestro de contas para seus administradores mais importantes e se baseiam na sua política padrão de MFA.

Se você estiver usando um provedor de identidade externo, configure a verificação pós-SSO.

Ative uma camada adicional de controle com base na análise de risco de login do Google. Depois que você aplicar essa configuração, os usuários poderão ver outros desafios de login com base em riscos no login se o Google determinar que um login de usuário é suspeito.

Ative as políticas de limite de acesso de principal (PAB) para limitar o acesso de principal e ajudar a proteger contra phishing e exfiltração de dados. Ative uma política de PAB para a organização e evite ataques de phishing externos. Os PABs melhoram a segurança ao reduzir a extensão de um ataque com uma identidade comprometida e também ajudam a evitar ataques de phishing externos e outros ataques de exfiltração.

As tags fornecem uma maneira de criar anotações para recursos e, em alguns casos, permitir ou negar políticas condicionalmente com base em um recurso ter uma tag específica. Use tags e aplicação condicional de políticas para ter um controle refinado em toda a hierarquia de recursos.

Use os Registros de auditoria do Cloud para monitorar atividades de alto risco, como contas que recebem papéis de alto risco, como administrador da organização e superadministrador. Configure alertas para esse tipo de atividade.

Para evitar conceder acesso excessivo a Cloud de Confiance by S3NS, bloqueie o acesso ao Cloud Shell para contas de usuário gerenciadas pelo Cloud Identity.

Com o acesso baseado no contexto, é possível criar políticas de segurança de controle de acesso granulares para aplicativos com base em atributos como identidade do usuário, local, status de segurança do dispositivo e endereço IP. Recomendamos que você use o Acesso baseado no contexto para restringir o acesso ao console Cloud de Confiance (https://console.cloud.google.com/) e ao Google Admin Console (https://admin.cloud.google.com).

OCloud de Confiance é compatível com várias versões do protocolo TLS. Para atender aos requisitos de compliance, talvez seja necessário negar solicitações de handshake de clientes que usam versões mais antigas do TLS.

Para configurar esse controle, use a restrição da política da organização Restringir versões TLS (gcp.restrictTLSVersion). É possível aplicar essa restrição a organizações, pastas ou projetos na hierarquia de recursos. A restrição Restringir versões do TLS usa uma lista de bloqueio, que nega valores explícitos e permite todos os outros. Um erro vai ocorrer se você tentar usar uma lista de permissão.

Devido ao comportamento da avaliação da hierarquia de políticas da organização, a restrição de versão do TLS se aplica ao nó de recurso especificado e a todas as pastas e projetos (filhos) dele. Por exemplo, se você negar o TLS 1.0 para uma organização, ele também será negado para todos os filhos que descendem dela.

É possível substituir a restrição de versão do TLS herdada atualizando a política da organização em um recurso filho. Por exemplo, se a política da organização negar o TLS 1.0 no nível da organização, você poderá remover a restrição de uma pasta filha definindo uma política separada nessa pasta. Se a pasta tiver filhos, a política dela também será aplicada a cada recurso filho devido à herança de política.

Para restringir ainda mais a versão do TLS apenas ao TLS 1.3, defina essa política para também restringir a versão 1.2 do TLS. É preciso implementar esse controle em aplicativos hospedados no Cloud de Confiance by S3NS. Por exemplo, no nível da organização, defina:

["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"]

Verifique se apenas as identidades da sua organização são permitidas no ambiente Cloud de Confiance by S3NS . Use a restrição de política da organização Compartilhamento restrito de domínio (iam.allowedPolicyMemberDomains) ou iam.managed.allowedPolicyMembers para definir um ou mais IDs de cliente do Cloud Identity ou do Google Workspace com principais que podem ser adicionados às políticas do Identity and Access Management (IAM).

Essas restrições ajudam a impedir que os funcionários concedam acesso a contas externas fora do controle da organização que não seguem as políticas de segurança para autenticação multifator (MFA) ou gerenciamento de senhas. Esse controle é fundamental para evitar o acesso não autorizado e garantir que apenas identidades corporativas gerenciadas e confiáveis possam ser usadas.

A restrição gcp.restrictServiceUsage garante que apenas os serviços aprovados Cloud de Confiance by S3NS sejam usados nos lugares certos. Por exemplo, uma pasta de produção ou altamente sensível tem uma pequena lista de serviços Cloud de Confiance aprovados para armazenar dados. Uma pasta de sandbox pode ter uma lista maior de serviços e controles de segurança de dados para ajudar a evitar a exfiltração de dados. O valor é específico para seus sistemas e corresponde à sua lista aprovada de serviços e dependências para pastas e projetos específicos.

Com essa restrição, sua organização pode criar uma lista de permissões de serviços aprovados, o que ajuda a impedir que os funcionários usem serviços não testados.

A restrição de local do recurso (gcp.resourceLocations) garante que apenas as regiões Cloud de Confiance by S3NS aprovadas sejam usadas para armazenar dados. O valor é específico para seus sistemas e corresponde à lista aprovada de regiões da sua organização para residência de dados.

Com essa restrição, sua organização pode garantir que os recursos e dados sejam criados e salvos apenas em regiões geográficas específicas e aprovadas.

A restrição booleana compute.skipDefaultNetworkCreation pula a criação da rede padrão e dos recursos relacionados ao criar projetos Cloud de Confiance by S3NS .

A rede padrão é uma rede de nuvem privada virtual (VPC) de modo automático com regras de firewall IPv4 já preenchidas para permitir caminhos de comunicação internos. Em geral, essa configuração não é uma postura de segurança recomendada para ambientes de produção.

As extensões de segurança do Sistema de Nomes de Domínio (DNSSEC) são um recurso do Sistema de Nome de Domínio (DNS) que autentica respostas a pesquisas de nome de domínio. Ela não fornece proteções de privacidade para as pesquisas, mas impede que invasores manipulem ou envenenem as respostas a solicitações de DNS.

No Cloud DNS, ative o DNSSEC nos seguintes locais:

• Zona de DNS
• Domínio de nível superior (TLD)
• Resolução DNS

Ative o Acesso privado do Google em todas as sub-redes.

Ative o acesso a serviços particulares para criar uma rede particular entre serviços do Cloud de Confiance by S3NS , como redes legadas do Google Cloud VMware Engine e produtores de serviços, como o Cloud SQL. O acesso a serviços particulares ajuda a evitar a exposição desnecessária das conexões de rede de carga de trabalho à Internet.

Desative a criação de sub-redes externas IPv6, a menos que seja especificamente necessário. Para reduzir a superfície de ataque, desative o IPv6 em sistemas e redes em que ele não é gerenciado ou necessário. Muitas organizações têm controles de segurança e monitoramento avançados para IPv4, mas as ferramentas e políticas podem não se estender totalmente ao IPv6, o que pode criar um ponto cego significativo para ameaças. Executar uma rede de pilha dupla também introduz complexidade operacional, exigindo configurações e experiência específicas para gerenciar e solucionar problemas de maneira eficaz. Portanto, se você não tiver um direcionador de negócios claro para o IPv6, desativá-lo poderá simplificar seu ambiente e garantir que todo o tráfego seja filtrado de forma consistente pela sua postura de segurança IPv4 estabelecida.

Limite o acesso a fontes externas porque, por padrão, todo o acesso é permitido. Defina regras de firewall específicas para padrões de tráfego de saída pretendidos.

Por padrão, os sistemas geralmente podem fazer conexões de saída com a Internet, o que pode ser considerado um risco de segurança. Uma política de negação por padrão bloqueia o tráfego de saída e exige a criação de regras específicas apenas para os destinos conhecidos e necessários.

Sempre que possível, restrinja o acesso de entrada apenas a recursos e intervalos de recursos específicos. Se o Identity-Aware Proxy (IAP) estiver configurado, defina as regras de firewall de entrada do SSH e do Remote Desktop Protocol (RDP) como intervalos de IP do IAP como fontes.

Regras de firewall permissivas de SSH e RDP permitem ataques de força bruta. Em vez disso, use proxies com reconhecimento de identidade Cloud de Confiance by S3NS (como o IAP) para SSH e RDP.

Ative o VPC Service Controls como uma camada extra de proteção para evitar a perda de dados.

O VPC Service Controls ajuda a evitar a exfiltração de dados criando perímetros de isolamento em torno dos recursos da nuvem, dos dados sensíveis e das redes.

O perímetro de serviço limita a utilidade das credenciais comprometidas porque bloqueia as solicitações para serviços restritos originadas de endpoints controlados por invasores que estão fora do seu ambiente.

Para aplicativos expostos por trás do Cloud Load Balancing, use as políticas padrão do Google Cloud Armor ou configure suas próprias políticas para adicionar proteção de rede da camada 3 à camada 7 para aplicativos ou serviços externos. As políticas de segurança do Cloud Armor ajudam a proteger seu aplicativo fornecendo filtragem da camada 7. Essas políticas também analisam solicitações recebidas para ataques comuns da Web ou outros atributos da Camada 7 para bloquear o tráfego antes que ele alcance os serviços ou buckets de back-end com carga balanceada. Cada política de segurança consiste em um conjunto de regras que incluem atributos da camada 3 à camada 7.

Para cada perímetro de serviço, confirme no console Cloud de Confiance se o tipo de perímetro está definido como "regular".

Para cada perímetro de serviço, use o Access Context Manager para confirmar se ele está protegendo a API.

A restrição booleana compute.setNewProjectDefaultToZonalDNSOnly permite definir a configuração de DNS interno para que novos projetos usem apenas o DNS zonal. Use o DNS zonal porque ele oferece mais confiabilidade em comparação com zonas individuais, já que isola falhas no registro de DNS .

Se você usa o Cloud Identity, compartilhe os registros de auditoria do Cloud Identity com Cloud de Confiance by S3NS.

Os registros de auditoria de atividade de administrador do Google Workspace ou do Cloud Identity geralmente são gerenciados e visualizados no Google Admin Console, separadamente dos registros no seu ambiente Cloud de Confiance . Esses registros contêm informações relevantes para seu ambiente do Cloud de Confiance , como eventos de login do usuário.

Recomendamos que você compartilhe os registros de auditoria do Cloud Identity com seu ambiente Cloud de Confiance para gerenciar de maneira centralizada registros de todas as fontes.

Os serviços doCloud de Confiance gravam entradas de registro de auditoria para responder quem fez o quê, onde e quando com os recursos do Cloud de Confiance .

Ative os registros de auditoria no nível da organização. É possível configurar o registro em log usando o pipeline que você usa para configurar a organização Cloud de Confiance .

Os registros de fluxo de VPC registram uma amostra de fluxos de rede enviados e recebidos por instâncias de VM, incluindo aquelas usadas como nós do Google Kubernetes Engine (GKE). A amostra geralmente é de 50% ou menos dos fluxos de rede VPC.

Quando ativados, os registros funcionam em todas as VMs de uma sub-rede. No entanto, é possível reduzir a quantidade de informações gravadas na geração de registros.

Ative os registros de fluxo de VPC para cada sub-rede de VPC. É possível configurar o registro em registros usando um pipeline que você usa para criar um projeto.

Por padrão, as regras de firewall não gravam registros automaticamente.A geração de registros de regras de firewall permite auditar, verificar e analisar os efeitos das suas regras de firewall. Por exemplo, é possível determinar se uma regra de firewall criada para negar tráfego está funcionando conforme o esperado. A geração de registros também é útil quando é preciso determinar quantas conexões são afetadas por uma determinada regra de firewall.

Ative a geração de registros para cada regra de firewall. É possível configurar a geração de registros usando um pipeline que você usa para criar um firewall.

Por padrão,o Cloud de Confiance ativa e não permite que ninguém desative a auditoria da atividade principal do administrador para contas privilegiadas.

Os registros de auditoria da atividade do administrador contêm entradas de registros para chamadas de API ou de outras ações que modificam a configuração ou os metadados de recursos. Por exemplo, esses registros são gravados quando os usuários criam instâncias de VM ou mudam permissões do IAM.

Os registros de auditoria de atividade do administrador contêm entradas de registro para criar, modificar e excluir restrições de política da organização em nível de organização, pasta e projeto.

Os registros de auditoria da atividade do administrador são sempre gravados. Não é possível configurá-los, exclui-los ou desativá-los. Mesmo que você desative a API Cloud Logging, os registros de auditoria da atividade do administrador ainda serão gerados.

Recomendamos que sua organização configure políticas e procedimentos para monitorar esses alertas e gerar ações ou alertas de acordo com as políticas de acesso empresarial para monitorar as atividades do administrador.

Inscreva-se nas notificações do boletim de segurança dos serviços do Cloud de Confiance by S3NS para receber alertas sobre vulnerabilidades e medidas de mitigação.

Quando os boletins de segurança estão disponíveis e são relevantes para o serviço Cloud de Confiance by S3NS (como o GKE), o serviço pode publicar notificações sobre esses eventos como mensagens para tópicos do Pub/Sub que você configura. Você pode receber essas notificações em uma assinatura do Pub/Sub, fazer a integração com serviços de terceiros e filtrar os tipos de notificação que quer receber.

Configure os Contatos essenciais para garantir que um alias ou uma lista de e-mails de grupo monitorado receba notificações importantes.

Usar um endereço de e-mail de grupo monitorado ajuda a garantir que esses alertas urgentes sejam entregues a uma equipe ativa que possa responder rapidamente.

Use o recurso de anomalia de faturamento no Cloud Billing para rastrear picos ou desvios nos gastos esperados.

Um aumento repentino e inesperado em uma fatura da nuvem é um indicador principal de uma violação de segurança. Às vezes, picos inesperados de faturamento são causados por invasores que ganharam acesso e estão usando recursos para atividades não autorizadas.

Ativar a detecção de anomalias de faturamento oferece um sistema essencial de alerta antecipado para que você possa sinalizar automaticamente essa atividade suspeita.

Crie um coletor de registros para exportar registros da sua solução de monitoramento de segurança e defina o período de armazenamento de acordo com seus requisitos.

Os períodos padrão de retenção de registros geralmente não são longos o suficiente para atender aos requisitos de 1 a 7 anos exigidos por regulamentações de compliance como PCI ou HIPAA.

Criar um coletor de registros para exportar registros para um local de armazenamento de longo prazo é essencial para atender a determinadas obrigações legais e regulatórias. Os coletores de registros também permitem enviar registros a um sistema centralizado de monitoramento de segurança para detecção avançada de ameaças.

Para rastrear quem acessou dados no seu ambiente Cloud de Confiance by S3NS , ative os registros de auditoria de acesso a dados. Esses registros gravam chamadas de API que leem, criam ou modificam dados do usuário, bem como chamadas de API que leem configurações de recursos.

Recomendamos ativar os registros de auditoria de acesso a dados para modelos de IA generativa e dados sensíveis para garantir que você possa auditar quem leu as informações. Para usar os registros de auditoria de acesso a dados, configure sua própria lógica de detecção personalizada para atividades específicas, como logins de superadministrador.

O volume de registros de auditoria de acesso a dados pode ser grande. Ativar os registros de acesso a dados pode resultar em uma cobrança no projeto Cloud de Confiance referente ao uso de registros adicionais.

Evite surpresas na sua fatura criando orçamentos do Cloud Billing para monitorar todas as suas Cloud de Confiance by S3NS cobranças em um só lugar. Depois de definir um valor de orçamento, defina regras de limite de alerta de orçamento por projeto para acionar notificações por e-mail. Essas notificações ajudam você a acompanhar os gastos em relação ao orçamento. Também é possível usar os orçamentos do Cloud Billing para automatizar as respostas de controle de custos.

Os registros padrão mostram o que os usuários da sua organização estão fazendo, mas os registros de Transparência no acesso mostram o que a equipe de suporte do Google faz ao acessar a conta. Esse acesso geralmente só acontece em resposta a uma solicitação de suporte. Os registros da Transparência no acesso fornecem uma trilha de auditoria completa e verificável de todos os acessos, o que é essencial para atender a requisitos rigorosos de compliance e governança de dados.

É possível ativar a Transparência no acesso no nível da organização.

Para mais análises de faturamento, exporte Cloud de Confiance by S3NS dados de faturamento para o BigQuery ou um arquivo JSON. Por exemplo, você pode exportar automaticamente dados detalhados, como uso, estimativas de custo e preços, ao longo do dia para um conjunto de dados do BigQuery especificado. Em seguida, é possível acessar os dados do Cloud Billing pelo BigQuery para análise detalhada ou usar uma ferramenta como o Data Studio para visualizar seus dados.

Todos os dados no Cloud de Confiance são criptografados em repouso por padrão usando algoritmos aprovados pelo NIST.

Verifique se o Cloud Key Management Service (Cloud KMS) usa apenas algoritmos aprovados pelo NIST para armazenar chaves sensíveis no ambiente. Esse controle garante o uso seguro de chaves apenas por algoritmos e segurança aprovados pelo NIST. O campo CryptoKeyVersionAlgorithm é uma lista de permissões fornecida.

Remova algoritmos que não estejam em conformidade com as políticas da sua organização.

Defina a finalidade das chaves do Cloud KMS como ENCRYPT_DECRYPT para que elas sejam usadas apenas para criptografar e descriptografar dados. Esse controle bloqueia outras funções, como a assinatura, e garante que as chaves sejam usadas apenas para a finalidade pretendida. Se você usa chaves para outras funções, valide esses casos de uso e considere criar chaves adicionais.

O nível de proteção indica como as operações criptográficas são realizadas. Depois de criar uma chave de criptografia gerenciada pelo cliente (CMEK), não é possível mudar o nível de proteção. Os níveis de proteção compatíveis são os seguintes:

• SOFTWARE:as operações criptográficas são realizadas em software.
• HSM:as operações criptográficas são realizadas em um módulo de segurança de hardware (HSM).
• EXTERNO:as operações criptográficas são realizadas com uma chave armazenada em um gerenciador de chaves externo conectado ao Cloud de Confiance pela Internet. Limitado à criptografia simétrica e à assinatura assimétrica.
• EXTERNAL_VPC::as operações criptográficas são realizadas com uma chave armazenada em um gerenciador de chaves externo conectado a Cloud de Confiance por uma rede de nuvem privada virtual (VPC). Limitado à criptografia simétrica e à assinatura assimétrica.

Verifique se o período de rotação das chaves do Cloud KMS está definido como 90 dias. Uma prática recomendada geral é alternar as chaves de segurança em intervalos regulares. Esse controle exige a rotação de chaves criadas com serviços de HSM.

Ao criar esse período de rotação, também crie políticas e procedimentos adequados para lidar com segurança com a criação, exclusão e modificação de material de chaves. Assim, você ajuda a proteger suas informações e garante a disponibilidade. Verifique se esse período obedece às políticas corporativas de rotação de chaves.

Crie uma estratégia de gerenciamento de criptografia usando o Cloud Key Management Service (Cloud KMS) com o Autokey, o Cloud External Key Manager (Cloud EKM) ou ambos. Com essa estratégia, sua organização pode usar e gerenciar as próprias chaves de criptografia para atender aos requisitos específicos. Usar suas próprias chaves de criptografia oferece controle granular e auditável sobre o acesso aos dados, incluindo a capacidade de bloquear imediatamente o acesso aos dados desativando a chave.

Use a restrição da política da organização Restringir quais projetos podem fornecer CryptoKeys do KMS para CMEK (gcp.restrictCmekCryptoKeyProjects) para definir quais projetos podem armazenar chaves de criptografia gerenciadas pelo cliente (CMEKs). Com essa restrição, é possível centralizar a governança e o gerenciamento das chaves de criptografia. Quando uma chave selecionada não atende a essa restrição, a criação do recurso falha.

Para modificar essa restrição, os administradores precisam do papel do IAM de Administrador da política da organização (roles/orgpolicy.policyAdmin).

Se você quiser adicionar uma segunda camada de proteção, como trazer sua própria chave, mude essa restrição para representar os nomes das chaves da CMEK ativada.

Especificações do produto:

• Na Gemini Enterprise Agent Platform, você armazena as chaves no projeto KEY PROJECTS.

Se você precisar de mais controle sobre as operações de chaves do que o permitido por Google Cloud-powered encryption keys , use as chaves de criptografia gerenciadas pelo cliente (CMEKs). Essas chaves são criadas e gerenciadas usando o Cloud KMS. Armazene as chaves como chaves de software, em um cluster do HSM ou em um sistema externo de gerenciamento de chaves.

As taxas de criptografia e descriptografia do Cloud KMS estão sujeitas a cotas.

Especificidades do Cloud Storage

No Cloud Storage, use CMEKs em objetos individuais ou configure os buckets do Cloud Storage para usar uma CMEK por padrão em todos os novos objetos adicionados a um bucket. Ao usar uma CMEK, um objeto é criptografado com a chave pelo Cloud Storage no momento em que é armazenado em um bucket, e o objeto é descriptografado automaticamente pelo Cloud Storage quando o objeto é veiculado aos solicitantes.

As seguintes restrições se aplicam ao usar CMEKs com o Cloud Storage:

• Não é possível atualizar os metadados de um objeto com uma CMEK. Inclua a chave como parte da regravação do objeto.
• O Cloud Storage usa o comando de atualização de objetos para definir chaves de criptografia em objetos, mas o comando reescreve o objeto como parte da solicitação.
• Você precisa criar o keyring do Cloud KMS no mesmo local dos dados que pretende criptografar. Por exemplo, se o bucket estiver localizado em us-east1, qualquer keyring usado para criptografar objetos nesse bucket também precisará ser criado em us-east1.
• Para a maioria das birregiões, você precisa criar o keyring do Cloud KMS na multirregião associada. Por exemplo, se o bucket estiver localizado no par us-east1, us-west1, qualquer keyring usado para criptografar objetos nesse bucket precisará ser criado na multirregião dos EUA.
• Para as regiões birregionais predefinidas asia1, eur4 e nam4, é necessário criar o keyring na mesma região dupla predefinida.
• A soma de verificação CRC32C e o hash MD5 de objetos criptografados com CMEKs não são retornados ao listar objetos com a API JSON.
• Usar ferramentas como o Cloud Storage para realizar solicitações GET de metadados adicionais em cada objeto de criptografia para recuperar as informações CRC32C e MD5 pode reduzir bastante a listagem. O Cloud Storage não pode usar a parte de descriptografia de chaves assimétricas armazenadas no Cloud KMS para descriptografar automaticamente objetos relevantes da mesma maneira que as CMEKs.