Compartilhar via

Controle de segurança: proteção de dados

  • Artigo

A Proteção de Dados abrange o controle da proteção de dados em repouso, em trânsito e por meio de mecanismos de acesso autorizados, incluindo descoberta, classificação, proteção e monitoramento de ativos de dados confidenciais usando controle de acesso, criptografia, gerenciamento de chaves e gerenciamento de certificados.|

DP-1: descobrir, classificar e rotular dados confidenciais

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
3.2, 3.7, 3.13 RA-2, SC-28 A3.2

Princípio de segurança: Estabeleça e mantenha um inventário dos dados confidenciais, com base no escopo de dados confidenciais definido. Use ferramentas para descobrir, classificar e rotular os dados confidenciais no escopo.

Diretrizes do Azure: use ferramentas como o Microsoft Purview, que combina as antigas soluções de conformidade do Azure Purview e do Microsoft 365, e a Descoberta e Classificação de Dados SQL do Azure para verificar, classificar e rotular centralmente os dados confidenciais que residem no Azure, local, no Microsoft 365 e em outros locais.

Implementação do Azure e contexto adicional:

Orientação da AWS: replique seus dados de várias fontes para um bucket de armazenamento do S3 e use o AWS Macie para verificar, classificar e rotular os dados confidenciais armazenados no bucket. O AWS Macie pode detectar dados confidenciais, como credenciais de segurança, informações financeiras, dados de PHI e PII ou outro padrão de dados com base nas regras de identificador de dados personalizadas.

Você também pode usar o conector de verificação de várias nuvens do Azure Purview para verificar, classificar e rotular os dados confidenciais que residem em um bucket de armazenamento do S3.

Observação: você também pode usar soluções corporativas de terceiros do AWS Marketplace para fins de descoberta, classificação e rotulagem de dados.

Implementação da AWS e contexto adicional:

Diretrizes do GCP: use ferramentas como o Google Cloud Data Loss Prevention para verificar, classificar e rotular centralmente os dados confidenciais que residem no GCP e nos ambientes locais.

Além disso, use o Catálogo de dados do Google Cloud para utilizar os resultados de uma verificação do Cloud Data Loss Prevention (DLP) para identificar dados confidenciais com modelos de tag definidos.

Implementação do GCP e contexto adicional:

Partes interessadas em segurança do cliente (Saiba mais):

DP-2: monitorar anomalias e ameaças direcionadas a dados confidenciais

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
3.13 AC-4, SI-4 A3.2

Princípio de segurança: monitore anomalias em torno de dados confidenciais, como transferência não autorizada de dados para locais fora da visibilidade e do controle corporativos. Isso normalmente envolve o monitoramento de atividades anormais (transferências grandes ou incomuns) que podem indicar exfiltração não autorizada dos dados.

Diretrizes do Azure: use a AIP (Proteção de Informações do Azure) para monitorar os dados que foram classificados e rotulados.

Use Microsoft Defender para Armazenamento, Microsoft Defender para SQL, Microsoft Defender para bancos de dados relacionais de software livre e Microsoft Defender para Cosmos DB para alertar sobre transferência anômala de informações que podem indicar transferências não autorizadas de informações de dados confidenciais.

Observação: se necessário para a conformidade da DLP (prevenção contra perda de dados), você pode usar uma solução DLP baseada em host do Azure Marketplace ou uma solução DLP do Microsoft 365 para impor controles de detecção e/ou preventivos para evitar a exfiltração de dados.

Implementação do Azure e contexto adicional:

Orientação da AWS: use o AWS Macie para monitorar os dados que foram classificados e rotulados e use o GuardDuty para detectar atividades anômalas em alguns recursos (S3, EC2 ou recursos do Kubernetes ou do IAM). As descobertas e os alertas podem ser triados, analisados e rastreados usando o EventBridge e encaminhados para o Microsoft Sentinel ou o Security Hub para agregação e rastreamento de incidentes.

Você também pode conectar suas contas da AWS ao Microsoft Defender para Nuvem para verificações de conformidade, segurança de contêiner e recursos de segurança de ponto de extremidade.

Observação: se necessário para a conformidade da prevenção contra perda de dados (DLP), você pode usar uma solução DLP baseada em host do AWS Marketplace.

Implementação da AWS e contexto adicional:

Orientação do GCP: use o Google Cloud Security Command Center/Event Threat Detection/Detecção de anomalias para alertar sobre transferências anômalas de informações que possam indicar transferências não autorizadas de informações confidenciais.

Você também pode conectar suas contas do GCP ao Microsoft Defender para Nuvem para verificações de conformidade, segurança de contêiner e recursos de segurança de ponto de extremidade.

Implementação do GCP e contexto adicional:

Partes interessadas em segurança do cliente (Saiba mais):

DP-3: criptografar dados confidenciais ativos

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
3.10 SC-8 3.5, 3.6, 4.1

Princípio de segurança: proteja os dados em trânsito contra ataques "fora de banda" (como captura de tráfego) usando criptografia para garantir que os invasores não possam ler ou modificar facilmente os dados.

Defina o limite de rede e o escopo de serviço onde forem obrigatórios os dados na criptografia ativa dentro e fora da rede. Embora isso seja opcional para o tráfego em redes privadas, isso é essencial para o tráfego em redes externas e públicas.

Diretrizes do Azure: imponha a transferência segura em serviços como o Armazenamento do Azure, em que um recurso de criptografia de dados em trânsito nativo é interno.

Imponha o HTTPS para cargas de trabalho e serviços de aplicativos Web, garantindo que todos os clientes que se conectam aos recursos do Azure usem o TLS (Transport Layer Security) v1.2 ou posterior. Para gerenciamento remoto de VMs, use SSH (para Linux) ou RDP/TLS (para Windows) em vez de um protocolo não criptografado.

Para gerenciamento remoto de máquinas virtuais do Azure, use SSH (para Linux) ou RDP/TLS (para Windows) em vez de um protocolo não criptografado. Para transferência segura de arquivos, use o serviço SFTP/FTPS no Blob de Armazenamento do Azure, aplicativos do Serviço de Aplicativo e aplicativos de funções, em vez de usar o serviço FTP regular.

Observação: a criptografia de dados ativos está habilitada para todo o tráfego do Azure que flui entre datacenters do Azure. O TLS v1.2 ou posterior está habilitado na maioria dos serviços do Azure por padrão. E alguns serviços, como o Armazenamento do Azure e o Gateway de Aplicativo, podem impor o TLS v1.2 ou posterior no lado do servidor.

Implementação do Azure e contexto adicional:

Orientação da AWS: aplique a transferência segura em serviços como Amazon S3, RDS e CloudFront, em que um recurso nativo de criptografia de dados em trânsito é integrado.

Aplique o HTTPS (como no AWS Elastic Load Balancer) para aplicativos e serviços web de carga de trabalho (no lado do servidor ou no lado do cliente, ou em ambos), garantindo que todos os clientes que se conectam aos seus recursos da AWS usem o TLS v1.2 ou posterior.

Para gerenciamento remoto de instâncias do EC2, use SSH (para Linux) ou RDP/TLS (para Windows) em vez de um protocolo não criptografado. Para transferência segura de arquivos, use o serviço AWS Transfer SFTP ou FTPS em vez de um serviço FTP regular.

Observação: todo o tráfego de rede entre os datacenters da AWS é criptografado de forma transparente na camada física. Todo o tráfego dentro de uma VPC e entre VPCs emparelhadas entre regiões é criptografado de forma transparente na camada de rede ao usar tipos de instância do Amazon EC2 compatíveis. O TLS v1.2 ou posterior está habilitado na maioria dos serviços da AWS por padrão. E alguns serviços, como o AWS Load Balancer, podem aplicar o TLS v1.2 ou posterior no lado do servidor.

Implementação da AWS e contexto adicional:

Orientação do GCP: aplique a transferência segura em serviços como o Google Cloud Storage, em que um recurso nativo de criptografia de dados em trânsito é integrado.

Aplique o HTTPS para cargas de trabalho e serviços de aplicativos da Web, garantindo que todos os clientes que se conectam aos recursos do GCP usem o Transport Layer Security (TLS) v1.2 ou posterior.

Para gerenciamento remoto, o Google Cloud Compute Engine usa SSH (para Linux) ou RDP/TLS (para Windows) em vez de um protocolo não criptografado. Para uma transferência segura de arquivos, use o serviço SFTP/FTPS em serviços como o Google Cloud Big Query ou o Cloud App Engine em vez de um serviço FTP regular.

Implementação do GCP e contexto adicional:

Partes interessadas em segurança do cliente (Saiba mais):

DP-4: habilitar a criptografia de dados inativos por padrão

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
3.11 SC-28 3.4, 3.5

Princípio de segurança: para complementar os controles de acesso, os dados em repouso devem ser protegidos contra ataques "fora de banda" (como acessar o armazenamento subjacente) usando criptografia. Isso ajuda a garantir que os invasores não possam ler nem modificar os dados com facilidade.

Diretrizes do Azure: muitos serviços do Azure têm criptografia de dados em repouso habilitada por padrão na camada de infraestrutura usando uma chave gerenciada pelo serviço. Essas chaves gerenciadas pelo serviço são geradas em nome do cliente e alternadas automaticamente a cada dois anos.

Quando tecnicamente viável e não habilitado por padrão, você pode habilitar a criptografia de dados em repouso nos serviços do Azure ou em suas VMs no nível de armazenamento, no nível do arquivo ou no nível do banco de dados.

Implementação do Azure e contexto adicional:

Orientação da AWS: muitos serviços da AWS têm criptografia de dados em repouso habilitada por padrão na camada de infraestrutura/plataforma usando uma chave mestra de cliente gerenciada pela AWS. Essas chaves mestras de cliente gerenciadas pela AWS são geradas em nome do cliente e alternadas automaticamente a cada três anos.

Quando tecnicamente viável e não habilitado por padrão, você pode habilitar a criptografia de dados em repouso nos serviços da AWS ou em suas VMs no nível de armazenamento, no nível do arquivo ou no nível do banco de dados.

Implementação da AWS e contexto adicional:

Orientação do GCP: muitos produtos e serviços do Google Cloud têm criptografia de dados em repouso ativada por padrão na camada de infraestrutura usando uma chave gerenciada pelo serviço. Essas chaves gerenciadas pelo serviço são geradas em nome do cliente e giradas automaticamente.

Quando tecnicamente viável e não ativado por padrão, você pode ativar a criptografia de dados em repouso nos serviços do GCP ou nas VMs no nível do armazenamento, do arquivo ou do banco de dados.

Observação: consulte o documento ""Granularidade da criptografia para serviços do Google Cloud"" para obter mais detalhes.

Implementação do GCP e contexto adicional:

Partes interessadas em segurança do cliente (Saiba mais):

DP-5: usar a opção de chave gerenciada pelo cliente na criptografia de dados inativos quando necessário

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
3.11 SC-12, SC-28 3.4, 3.5, 3.6

Princípio de segurança: se necessário para conformidade regulatória, defina o caso de uso e o escopo do serviço em que a opção de chave gerenciada pelo cliente é necessária. Habilite e implemente a criptografia de dados em repouso usando chaves gerenciadas pelo cliente nos serviços.

Diretrizes do Azure: o Azure também fornece uma opção de criptografia usando chaves gerenciadas por você (chaves gerenciadas pelo cliente) para a maioria dos serviços.

O Azure Key Vault Standard, Premium e HSM Gerenciado são integrados nativamente a muitos Serviços do Azure para casos de uso de chaves gerenciadas pelo cliente. Você pode usar o Azure Key Vault para gerar sua chave ou trazer suas próprias chaves.

No entanto, o uso da opção de chave gerenciada pelo cliente requer esforço operacional adicional para gerenciar o ciclo de vida da chave. Isso pode incluir geração de chave de criptografia, rotação, revogação e controle de acesso, etc.

Implementação do Azure e contexto adicional:

Orientação da AWS: A AWS também fornece uma opção de criptografia usando chaves gerenciadas por você (chave mestra do cliente gerenciada pelo cliente armazenada no AWS Key Management Service) para determinados serviços.

O AWS Key Management Service (KMS) é integrado nativamente a muitos serviços da AWS para casos de uso de chave mestra de cliente gerenciada pelo cliente. Você pode usar o AWS Key Management Service (KMS) para gerar suas chaves mestras ou trazer suas próprias chaves.

No entanto, o uso da opção de chave gerenciada pelo cliente requer esforços operacionais adicionais para gerenciar o ciclo de vida da chave. Isso pode incluir geração de chave de criptografia, rotação, revogação e controle de acesso, etc.

Implementação da AWS e contexto adicional:

Orientação do GCP: o Google Cloud oferece uma opção de criptografia usando chaves gerenciadas por você (chaves gerenciadas pelo cliente) para a maioria dos serviços.

O Google Cloud Key Management Service (Cloud KMS) é integrado nativamente a muitos serviços do GCP para chaves de criptografia gerenciadas pelo cliente. Essas chaves podem ser criadas e gerenciadas usando o Cloud KMS, e você armazena as chaves como chaves de software, em um cluster HSM ou externamente. Você pode usar o Cloud KMS para gerar sua chave ou fornecer suas próprias chaves (chaves de criptografia fornecidas pelo cliente).

No entanto, o uso da opção de chave gerenciada pelo cliente requer esforços operacionais adicionais para gerenciar o ciclo de vida da chave. Isso pode incluir geração de chave de criptografia, rotação, revogação e controle de acesso, etc.

Implementação do GCP e contexto adicional:

Partes interessadas em segurança do cliente (Saiba mais):

DP-6: usar um processo de gerenciamento de chaves seguro

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-28 3,6

Princípio de segurança: documente e implemente um padrão, processos e procedimentos de gerenciamento de chaves criptográficas corporativas para controlar o ciclo de vida da chave. Quando for necessário usar a chave gerenciada pelo cliente nos serviços, use um serviço de cofre de chaves seguro para a geração, a distribuição e o armazenamento das chaves. Gire e revogue suas chaves com base em um cronograma definido e quando houver uma retirada ou um comprometimento de chave.

Diretrizes do Azure: use o Azure Key Vault para criar e controlar o ciclo de vida das chaves de criptografia, incluindo geração, distribuição e armazenamento de chaves. Gire e revogue suas chaves no Azure Key Vault e em seu serviço com base em um cronograma definido e quando houver uma retirada ou comprometimento de chave. Exigir um determinado tipo criptográfico e tamanho mínimo de chave ao gerar chaves.

Quando for necessário usar a CMK (chave gerenciada pelo cliente) nos serviços ou aplicativos de carga de trabalho, siga estas práticas recomendadas:

  • Use uma hierarquia de chave para gerar uma DEK (chave de criptografia de dados) separada com sua KEK (chave de criptografia de chave) no cofre de chaves.
  • Verifique se as chaves estão registradas no Azure Key Vault e implementadas por meio de IDs de chave em cada serviço ou aplicativo.

Para maximizar o tempo de vida e a portabilidade do material de chave, traga sua própria chave (BYOK) para os serviços (ou seja, importando chaves protegidas por HSM de seus HSMs locais para o Azure Key Vault). Siga a diretriz recomendada para executar a geração e a transferência de chaves.

Observação: consulte abaixo o nível FIPS 140-2 para tipos do Azure Key Vault e nível de conformidade/validação FIPS.

  • Chaves protegidas por software em cofres (SKUs Premium e Standard): FIPS 140-2 Nível 1
  • Chaves protegidas por HSM em cofres (SKU Premium): FIPS 140-2 Nível 2
  • Chaves protegidas por HSM em um HSM gerenciado: FIPS 140-2 Nível 3

O Azure Key Vault Premium usa uma infraestrutura HSM compartilhada no back-end. O HSM Gerenciado do Azure Key Vault usa pontos de extremidade de serviço dedicados e confidenciais com um HSM dedicado para quando você precisa de um nível mais alto de segurança de chave.

Implementação do Azure e contexto adicional:

Orientação da AWS: use o AWS Key Management Service (KMS) para criar e controlar o ciclo de vida das chaves de criptografia, incluindo geração, distribuição e armazenamento de chaves. Alterne e revogue suas chaves no KMS e no serviço com base na programação definida e quando houver uma desativação ou comprometimento da chave.

Quando houver necessidade de usar a chave mestra do cliente gerenciada pelo cliente nos serviços ou aplicativos de carga de trabalho, certifique-se de seguir as práticas recomendadas:

  • Use uma hierarquia de chaves para gerar uma DEK (chave de criptografia de dados) separada com sua chave de criptografia de chave (KEK) em seu KMS.
  • Certifique-se de que as chaves estejam registradas no KMS e implementadas por meio de políticas do IAM em cada serviço ou aplicativo.

Para maximizar o tempo de vida e a portabilidade do material de chave, traga sua própria chave (BYOK) para os serviços (ou seja, importando chaves protegidas por HSM de seus HSMs locais para KMS ou Cloud HSM). Siga a diretriz recomendada para executar a geração e a transferência de chaves.

Observação: o AWS KMS usa a infraestrutura de HSM compartilhada no back-end. Use o armazenamento de chaves personalizadas do AWS KMS com suporte do AWS CloudHSM quando precisar gerenciar seu próprio armazenamento de chaves e HSMs dedicados (por exemplo, requisito de conformidade regulatória para um nível mais alto de segurança de chaves) para gerar e armazenar suas chaves de criptografia.

Observação: consulte abaixo o nível FIPS 140-2 para o nível de conformidade FIPS no AWS KMS e no CloudHSM:

  • Padrão do AWS KMS: validado pelo FIPS 140-2 nível 2
  • AWS KMS usando CloudHSM: FIPS 140-2 nível 3 (para determinados serviços) validado
  • AWS CloudHSM: validado pelo FIPS 140-2 nível 3

Observação: para gerenciamento de segredos (credenciais, senha, chaves de API etc.), use o AWS Secrets Manager.

Implementação da AWS e contexto adicional:

Diretrizes do GCP: use o Cloud Key Management Service (Cloud KMS) para criar e gerenciar ciclos de vida de chaves de criptografia em serviços compatíveis do Google Cloud e em seus aplicativos de carga de trabalho. Alterne e revogue suas chaves no Cloud KMS e no serviço com base na programação definida e quando houver uma desativação ou comprometimento da chave.

Use o serviço Cloud HSM do Google para fornecer chaves com suporte de hardware para o Cloud KMS (Key Management Service) Ele permite que você gerencie e use suas próprias chaves criptográficas enquanto está protegido por módulos de segurança de hardware (HSM, na sigla em inglês) totalmente gerenciados.

O serviço Cloud HSM usa HSMs, que são validados pelo FIPS 140-2 Nível 3 e estão sempre em execução no modo FIPS. Validado pelo FIPS 140-2 Nível 3 e estão sempre em execução no modo FIPS. O padrão FIPS especifica os algoritmos criptográficos e a geração de números aleatórios usados pelos HSMs.

Implementação do GCP e contexto adicional:

Partes interessadas em segurança do cliente (Saiba mais):

DP-7: usar um processo seguro de gerenciamento de certificados

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-17 3,6

Princípio de segurança: documente e implemente um padrão, processos e procedimentos de gerenciamento de certificados corporativos que inclua o controle do ciclo de vida do certificado e políticas de certificado (se uma infraestrutura de chave pública for necessária).

Garanta que os certificados usados pelos serviços críticos em sua organização sejam inventariados, rastreados, monitorados e renovados em tempo hábil usando um mecanismo automatizado para evitar a interrupção do serviço.

Diretrizes do Azure: use o Azure Key Vault para criar e controlar o ciclo de vida do certificado, incluindo a criação/importação, rotação, revogação, armazenamento e limpeza do certificado. Certifique-se de que a geração do certificado siga o padrão definido sem usar nenhuma propriedade insegura, como tamanho de chave insuficiente, período de validade excessivamente longo, criptografia insegura e assim por diante. Configure a rotação automática do certificado no Azure Key Vault e nos serviços do Azure com suporte com base no agendamento definido e quando um certificado expirar. Se não houver suporte para a rotação automática no aplicativo front-end, use uma rotação manual no Azure Key Vault.

Evite usar um certificado autoassinado e um certificado curinga em seus serviços críticos devido à garantia de segurança limitada. Em vez disso, você pode criar certificados assinados públicos no Azure Key Vault. As CAs (Autoridades de Certificação) a seguir são os provedores parceiros que estão atualmente integrados ao Azure Key Vault.

  • DigiCert: o Azure Key Vault oferece certificados TLS/SSL OV com o DigiCert.
  • GlobalSign: o Azure Key Vault oferece certificados TLS/SSL OV com o GlobalSign.

Observação: use apenas a CA aprovada e certifique-se de que os certificados raiz/intermediários inválidos conhecidos emitidos por essas CAs estejam desabilitados.

Implementação do Azure e contexto adicional:

Orientação da AWS: use o AWS Certificate Manager (ACM) para criar e controlar o ciclo de vida do certificado, incluindo criação/importação, rotação, revogação, armazenamento e limpeza do certificado. Certifique-se de que a geração do certificado siga o padrão definido sem usar nenhuma propriedade insegura, como tamanho de chave insuficiente, período de validade excessivamente longo, criptografia insegura e assim por diante. Configure a alternância automática do certificado no ACM e nos serviços da AWS compatíveis com base na programação definida e quando um certificado expirar. Se a rotação automática não for compatível com o aplicativo de front-end, use a rotação manual no ACM. Enquanto isso, você deve sempre acompanhar o status de renovação do certificado para garantir a validade do certificado.

Evite usar um certificado autoassinado e um certificado curinga em seus serviços críticos devido à garantia de segurança limitada. Em vez disso, crie certificados assinados publicamente (assinados pela Autoridade de Certificação da Amazon) no ACM e implante-os programaticamente em serviços como CloudFront, Load Balancers, API Gateway etc. Você também pode usar o ACM para estabelecer sua autoridade de certificação (CA) privada para assinar os certificados privados.

Observação: use apenas uma autoridade de certificação aprovada e certifique-se de que os certificados raiz/intermediários de autoridade de certificação inválidos conhecidos emitidos por essas autoridades de certificação estejam desativados.

Implementação da AWS e contexto adicional:

Orientação do GCP: use o Google Cloud Certificate Manager para criar e controlar o ciclo de vida do certificado, incluindo criação/importação, rotação, revogação, armazenamento e limpeza do certificado. Certifique-se de que a geração do certificado siga o padrão definido sem usar nenhuma propriedade insegura, como tamanho de chave insuficiente, período de validade excessivamente longo, criptografia insegura e assim por diante. Configure a rotação automática do certificado no Gerenciador de certificados e nos serviços compatíveis do GCP com base na programação definida e quando um certificado expirar. Se a rotação automática não for suportada no aplicativo front-end, use a rotação manual no Gerenciador de Certificados. Enquanto isso, você deve sempre acompanhar o status de renovação do certificado para garantir a validade do certificado.

Evite usar um certificado autoassinado e um certificado curinga em seus serviços críticos devido à garantia de segurança limitada. Em vez disso, você pode criar certificados públicos assinados no Gerenciador de Certificados e implantá-los programaticamente em serviços como Load Balancer e Cloud DNS etc. Você também pode usar o Serviço de Autoridade de Certificação para estabelecer sua autoridade de certificação privada (CA) para assinar os certificados privados.

Observação: você também pode usar o Google Cloud Secret Manager para armazenar certificados TLS.

Implementação do GCP e contexto adicional:

Partes interessadas em segurança do cliente (Saiba mais):

DP-8: garantir a segurança do repositório de chaves e certificados

ID(s) do CIS Controls v8 ID(s) do NIST SP 800-53 r4 ID(s) do PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-17 3,6

Princípio de segurança: garanta a segurança do serviço de cofre de chaves usado para o gerenciamento do ciclo de vida da chave criptográfica e do certificado. Proteja seu serviço de cofre de chaves por meio do controle de acesso, da segurança de rede, do registro em log e do monitoramento e do backup para garantir que as chaves e os certificados estejam sempre protegidos com segurança máxima.

Diretrizes do Azure: proteja suas chaves criptográficas e certificados protegendo seu serviço Azure Key Vault por meio dos seguintes controles:

  • Implemente o controle de acesso usando políticas RBAC no HSM Gerenciado do Azure Key Vault no nível da chave para garantir que os princípios de privilégio mínimo e separação de tarefas sejam seguidos. Por exemplo, certifique-se de que a separação de tarefas esteja em vigor para usuários que gerenciam chaves de criptografia para que eles não tenham a capacidade de acessar dados criptografados e vice-versa. Para o Azure Key Vault Standard e Premium, crie cofres exclusivos para diferentes aplicativos para garantir que os princípios de privilégio mínimo e separação de tarefas sejam seguidos.
  • Ative o log do Azure Key Vault para garantir que as atividades críticas do plano de gerenciamento e do plano de dados sejam registradas.
  • Proteja o Azure Key Vault usando o Link Privado e o Firewall do Azure para garantir uma exposição mínima do serviço
  • Use a identidade gerenciada para acessar chaves armazenadas no Azure Key Vault em seus aplicativos de carga de trabalho.
  • Ao limpar dados, certifique-se de que as chaves não sejam excluídas antes que os dados, backups e arquivos reais sejam limpos.
  • Faça backup de suas chaves e certificados usando o Azure Key Vault. Habilite a exclusão reversível e a proteção contra limpeza para evitar a exclusão acidental de chaves. Quando as chaves precisarem ser excluídas, considere desabilitar as chaves em vez de excluí-las para evitar a exclusão acidental de chaves e o apagamento criptográfico de dados.
  • Para casos de uso de BYOK (traga sua própria chave), gere chaves em um HSM local e importe-as para maximizar o tempo de vida e a portabilidade das chaves.
  • Nunca armazene chaves em formato de texto não criptografado fora do Azure Key Vault. As chaves em todos os serviços do cofre de chaves não são exportáveis por padrão.
  • Use tipos de chave com suporte de HSM (RSA-HSM) no Azure Key Vault Premium e no HSM Gerenciado do Azure para a proteção de hardware e os níveis FIPS mais fortes.

Habilite o Microsoft Defender para Key Vault para proteção avançada contra ameaças nativas do Azure para o Azure Key Vault, fornecendo uma camada adicional de inteligência de segurança.

Implementação do Azure e contexto adicional:

Orientação da AWS: para segurança de chaves criptográficas, proteja suas chaves protegendo seu serviço AWS Key Management Service (KMS) por meio dos seguintes controles:

  • Implemente o controle de acesso usando políticas de chave (controle de acesso em nível de chave) em conjunto com políticas do IAM (controle de acesso baseado em identidade) para garantir que os princípios de privilégio mínimo e separação de tarefas sejam seguidos. Por exemplo, certifique-se de que a separação de tarefas esteja em vigor para usuários que gerenciam chaves de criptografia para que eles não tenham a capacidade de acessar dados criptografados e vice-versa.
  • Use controles de detecção, como o CloudTrails, para registrar e rastrear o uso de chaves no KMS e alertá-lo sobre ações críticas.
  • Nunca armazene chaves em formato de texto simples fora do KMS.
  • Quando as chaves precisarem ser excluídas, considere desabilitar as chaves no KMS em vez de excluí-las para evitar a exclusão acidental de chaves e o apagamento criptográfico de dados.
  • Ao limpar dados, certifique-se de que as chaves não sejam excluídas antes que os dados, backups e arquivos reais sejam limpos.
  • Para casos de uso de BYOK (traga sua própria chave), gere chaves em um HSM local e importe-as para maximizar a vida útil e a portabilidade das chaves.

Para segurança de certificados, proteja seus certificados fortalecendo seu serviço AWS Certificate Manager (ACM) por meio dos seguintes controles:

  • Implemente o controle de acesso usando políticas no nível do recurso em conjunto com as políticas do IAM (controle de acesso baseado em identidade) para garantir que os princípios de privilégio mínimo e separação de tarefas sejam seguidos. Por exemplo, verifique se a separação de tarefas está em vigor para contas de usuário: as contas de usuário que geram certificados são separadas das contas de usuário que exigem apenas acesso somente leitura aos certificados.
  • Use controles de detecção, como o CloudTrails, para registrar e rastrear o uso dos certificados no ACM e alertá-lo sobre ações críticas.
  • Siga as diretrizes de segurança do KMS para proteger sua chave privada (gerada para solicitação de certificado) usada para integração de certificado de serviço.

Implementação da AWS e contexto adicional:

Orientação do GCP: para segurança de chaves criptográficas, proteja suas chaves protegendo seu serviço de gerenciamento de chaves por meio dos seguintes controles:

  • Implemente o controle de acesso usando funções do IAM para garantir que os princípios de privilégio mínimo e separação de tarefas sejam seguidos. Por exemplo, certifique-se de que a separação de tarefas esteja em vigor para usuários que gerenciam chaves de criptografia para que eles não tenham a capacidade de acessar dados criptografados e vice-versa.
  • Crie um conjunto de chaves separado para cada projeto que permita gerenciar e controlar facilmente o acesso às chaves seguindo a prática recomendada de privilégios mínimos. Também facilita a auditoria de quem tem acesso a quais chaves e quando.
  • Ative a rotação automática de chaves para garantir que as chaves sejam atualizadas e atualizadas regularmente. Isso ajuda a proteger contra possíveis ameaças à segurança, como ataques de força bruta ou agentes mal-intencionados que tentam obter acesso a informações confidenciais.
  • Configure um coletor de log de auditoria para rastrear todas as atividades que ocorrem no ambiente do GCP KMS.

Para a segurança dos certificados, proteja-os fortalecendo o Gerenciador de certificados do GCP e o serviço de autoridade de certificação por meio dos seguintes controles:

  • Implemente o controle de acesso usando políticas no nível do recurso em conjunto com as políticas do IAM (controle de acesso baseado em identidade) para garantir que os princípios de privilégio mínimo e separação de tarefas sejam seguidos. Por exemplo, verifique se a separação de tarefas está em vigor para contas de usuário: as contas de usuário que geram certificados são separadas das contas de usuário que exigem apenas acesso somente leitura aos certificados.
  • Use controles de detecção, como os registros de auditoria do Cloud, para registrar e rastrear o uso dos certificados no Gerenciador de certificados e alertá-lo sobre ações críticas.
  • O Secret Manager também oferece suporte ao armazenamento do certificado TLS. Você precisa seguir a prática de segurança semelhante para implementar os controles de segurança no Secret Manager.

Implementação do GCP e contexto adicional:

Partes interessadas em segurança do cliente (Saiba mais):