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 descobrir, classificar, proteger e monitorar 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 SQL do Azure Descoberta e Classificação de Dados para examinar, classificar e rotular centralmente os dados confidenciais que residem no Azure, local, Microsoft 365 e outros locais.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: replique seus dados de várias fontes para um bucket de armazenamento S3 e use o Macie do AWS para examinar, classificar e rotular os dados confidenciais armazenados no bucket. O Macie do AWS pode detectar dados confidenciais, como credenciais de segurança, informações financeiras, dados 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 examinar, classificar e rotular os dados confidenciais que residem em um bucket de armazenamento S3.

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

Implementação do AWS e contexto adicional:

Diretrizes do GCP: use ferramentas como a Prevenção contra Perda de Dados do Google Cloud para examinar, classificar e rotular centralmente os dados confidenciais que residem nos ambientes GCP e locais.

Além disso, use o Google Cloud Catálogo de Dados para utilizar os resultados de uma verificação de DLP (Prevenção contra Perda de Dados na Nuvem) para identificar dados confidenciais com modelos de marca definidos.

Implementação do GCP e contexto adicional:

Stakeholders de 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 a 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 o Cosmos DB para alertar sobre a transferência anormal de informações que podem indicar transferências não autorizadas de dados confidenciais Informações.

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 de Azure Marketplace ou uma solução DLP do Microsoft 365 para impor controles detetive e/ou preventivos para evitar a exfiltração de dados.

Implementação do Azure e contexto adicional:

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

Você também pode conectar suas contas do 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 DLP (prevenção contra perda de dados), você pode usar uma solução DLP baseada em host do AWS Marketplace.

Implementação do AWS e contexto adicional:

Diretrizes do GCP: use o Centro de Comandos do Google Cloud Security/Detecção de Ameaças de Eventos/Detecção de Anomalias para alertar sobre a transferência anormal de informações que podem indicar transferências não autorizadas de informações de dados 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:

Stakeholders de 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 nativos em trânsito é integrado.

Imponha HTTPS para cargas de trabalho e serviços de aplicativo Web, garantindo que todos os clientes que se conectam aos recursos do Azure usem a TLS (segurança da camada de transporte) 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 o 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, Serviço de Aplicativo aplicativos 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 Gateway de Aplicativo podem impor o TLS v1.2 ou posterior no lado do servidor.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: imponha a transferência segura em serviços como Amazon S3, RDS e CloudFront, em que um recurso de criptografia de dados nativos em trânsito é integrado.

Imponha HTTPS (como no AWS Elastic Load Balancer) para serviços e aplicativos 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 recursos da AWS usem o TLS v1.2 ou posterior.

Para o gerenciamento remoto de instâncias 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 SFTP ou FTPS de transferência do AWS em vez de um serviço FTP regular.

Observação: todo o tráfego de rede entre data centers da AWS é criptografado de forma transparente na camada física. Todo o tráfego dentro de um 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 com suporte. 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 impor o TLS v1.2 ou posterior no lado do servidor.

Implementação da AWS e contexto adicional:

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

Imponha HTTPS para cargas de trabalho e serviços de aplicativo Web, garantindo que todos os clientes que se conectam aos recursos do GCP usem o protocolo 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 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:

Stakeholders de 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 inativos 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 inativos 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 giradas automaticamente a cada dois anos.

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

Implementação do Azure e contexto adicional:

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

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

Implementação da AWS e contexto adicional:

Diretrizes do GCP: muitos produtos e serviços do Google Cloud têm a criptografia de dados inativos 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 giradas automaticamente.

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

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

Implementação do GCP e contexto adicional:

Stakeholders de 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 inativos usando chaves gerenciadas pelo cliente em serviços.

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

O Azure Key Vault HSM Standard, Premium e Gerenciado são integrados nativamente a muitos Serviços do Azure para casos de uso de chave gerenciada 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:

Diretrizes da AWS: a AWS também fornece uma opção de criptografia usando chaves gerenciadas por você mesmo (chave de master do cliente gerenciada pelo cliente armazenada no Serviço de Gerenciamento de Chaves do AWS) para determinados serviços.

O KMS (Serviço de Gerenciamento de Chaves) da AWS é integrado nativamente a muitos serviços da AWS para clientes gerenciados pelo cliente master casos de uso de chave. Você pode usar o KMS (Serviço de Gerenciamento de Chaves) da AWS para gerar suas chaves de master 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:

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

O KMS (Serviço de Gerenciamento de Chaves do Google Cloud) é integrado nativamente a muitos serviços GCP para chaves de criptografia gerenciadas pelo cliente. Essas chaves podem ser criadas e gerenciadas usando o KMS de nuvem e você armazena as chaves como chaves de software, em um cluster HSM ou externamente. Você pode usar o KMS da Nuvem 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:

Stakeholders de 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 de gerenciamento de chaves criptográficas corporativas, processos e procedimentos 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 um 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 principal, 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 as diretrizes recomendadas para executar a geração de chaves e a transferência de chave.

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

  • Chaves protegidas por software em cofres (SKUs Premium & 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ê precisar de um nível mais alto de segurança de chave.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: use o KMS (Serviço de Gerenciamento de Chaves) da AWS 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 KMS e no serviço com base no agendamento definido e quando houver uma desativação ou comprometimento importante.

Quando houver a necessidade de usar a chave de master do cliente gerenciada pelo cliente nos serviços ou aplicativos de carga de trabalho, siga as práticas recomendadas:

  • Use uma hierarquia de chaves para gerar uma DEK (chave de criptografia de dados) separada com sua KEK (chave de criptografia de chave) no KMS.
  • Verifique se as chaves estão registradas com KMS e implementem por meio de políticas de IAM em cada serviço ou aplicativo.

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

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

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

  • AWS KMS padrão: FIPS 140-2 Nível 2 validado
  • AWS KMS usando CloudHSM: FIPS 140-2 Nível 3 (para determinados serviços) validado
  • AWS CloudHSM: FIPS 140-2 Nível 3 validado

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

Implementação da AWS e contexto adicional:

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

Use o serviço HSM de Nuvem do Google para fornecer chaves com suporte de hardware para o KMS de Nuvem (Serviço de Gerenciamento de Chaves) Ele oferece a capacidade de gerenciar e usar suas próprias chaves criptográficas enquanto está protegido por HSMs (Módulos de Segurança de Hardware) totalmente gerenciados.

O serviço HSM de Nuvem usa HSMs, que são validados pelo FIPS 140-2 Nível 3 e estão sempre em execução no modo FIPS. FIPS 140-2 Nível 3 validado 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:

Stakeholders de 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 de gerenciamento de certificados corporativos, processos e procedimentos que incluem o controle do ciclo de vida do certificado e as 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 os serviços do Azure com suporte com base no agendamento definido e quando um certificado expira. Se não houver suporte para rotação automática no aplicativo de 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 públicos assinados no Azure Key Vault. As ACs (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 AC aprovada e verifique se os certificados raiz/intermediários inválidos conhecidos emitidos por essas ACs estão desabilitados.

Implementação do Azure e contexto adicional:

Diretrizes da AWS: use o ACM (Gerenciador de Certificados) da AWS 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 ACM e os serviços AWS com suporte com base no agendamento definido e quando um certificado expira. Se não houver suporte para rotação automática no aplicativo de front-end, use a rotação manual no ACM. Enquanto isso, você sempre deve acompanhar a renovação do certificado status 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 Amazon Certificate Authority) no ACM e implante-os programaticamente em serviços como CloudFront, Load Balancers, Gateway de API etc. Você também pode usar o ACM para estabelecer sua AC (autoridade de certificação) privada para assinar os certificados privados.

Observação: use apenas uma AC aprovada e verifique se os certificados raiz/intermediários de AC inválidos conhecidos emitidos por essas ACs estão desabilitados.

Implementação da AWS e contexto adicional:

Diretrizes 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 os serviços GCP com suporte com base na agenda definida e quando um certificado expira. Se não houver suporte para rotação automática no aplicativo de front-end, use a rotação manual no Gerenciador de Certificados. Enquanto isso, você sempre deve acompanhar a renovação do certificado status 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 DNS na nuvem etc. Você também pode usar o Serviço de Autoridade de Certificação para estabelecer sua AC (autoridade de certificação) privada 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:

Stakeholders de 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: verifique a segurança do serviço do cofre de chaves usado para o gerenciamento de ciclo de vida de certificado e chave criptográfica. 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 de Key Vault do Azure por meio dos seguintes controles:

  • Implemente o controle de acesso usando políticas RBAC no Azure Key Vault HSM Gerenciado no nível de chave para garantir que o privilégio mínimo e a separação de princípios de tarefas sejam seguidos. Por exemplo, verifique se a separação de tarefas está em vigor para os 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 o privilégio mínimo e a separação de princípios de tarefas sejam seguidos.
  • Ative o log de Key Vault do Azure para garantir que as atividades críticas do plano de gerenciamento e do plano de dados sejam registradas.
  • Proteger a Key Vault do Azure usando Link Privado e Firewall do Azure para garantir a 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 Key Vault do Azure. 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 chaves em vez de excluí-las para evitar a exclusão acidental de chaves e a eliminação criptográfica de dados.
  • Para casos de uso 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 sem formatação fora do Key Vault do Azure. As chaves em todos os serviços do cofre de chaves não são exportáveis por padrão.
  • Use os 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:

Diretrizes da AWS: para segurança de chaves criptográficas, proteja suas chaves protegendo seu serviço KMS (Serviço de Gerenciamento de Chaves) do AWS por meio dos seguintes controles:

  • Implemente o controle de acesso usando políticas de chave (controle de acesso de nível de chave) em conjunto com as políticas de IAM (controle de acesso baseado em identidade) para garantir que o privilégio mínimo e a separação dos princípios de tarefas sejam seguidos. Por exemplo, verifique se a separação de tarefas está em vigor para os 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 detetive como o CloudTrails para registrar e acompanhar o uso de chaves no KMS e alertá-lo sobre ações críticas.
  • Nunca armazene chaves em formato de texto sem formatação fora do KMS.
  • Quando as chaves precisarem ser excluídas, considere desabilitar chaves no KMS em vez de excluí-las para evitar a exclusão acidental de chaves e a eliminação criptográfica 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 (bring your own key), gere chaves em um HSM local e importe-as para maximizar o tempo de vida e a portabilidade das chaves.

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

  • Implemente o controle de acesso usando políticas de nível de recurso em conjunto com políticas de IAM (controle de acesso baseado em identidade) para garantir que o privilégio mínimo e a separação de princípios 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 detetive como o CloudTrails para registrar e acompanhar o uso dos certificados no ACM e alertá-lo sobre ações críticas.
  • Siga as diretrizes de segurança kms para proteger sua chave privada (gerada para solicitação de certificado) usada para integração de certificado de serviço.

Implementação do AWS e contexto adicional:

Diretrizes 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 IAM para garantir que o privilégio mínimo e a separação de princípios de tarefas sejam seguidos. Por exemplo, verifique se a separação de tarefas está em vigor para os usuários que gerenciam chaves de criptografia para que eles não tenham a capacidade de acessar dados criptografados e vice-versa.
  • Crie um anel de chave separado para cada projeto que permita gerenciar e controlar facilmente o acesso às chaves seguindo as práticas recomendadas de privilégios mínimos. Também facilita a auditoria de quem tem acesso a quais chaves quando.
  • Habilite 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 atores mal-intencionados que tentam obter acesso a informações confidenciais.
  • Configure um coletor de log de auditoria para acompanhar todas as atividades que ocorrem dentro do ambiente KMS do GCP.

Para segurança de certificados, proteja seus certificados protegendo 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 de nível de recurso em conjunto com políticas de IAM (controle de acesso baseado em identidade) para garantir que o privilégio mínimo e a separação de princípios 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 detetive, como Logs de Auditoria na Nuvem, para registrar e acompanhar o uso dos certificados no Gerenciador de Certificados e alertá-lo sobre ações críticas.
  • O Gerenciador de Segredos também dá suporte ao armazenamento do certificado TLS. Você precisa seguir a prática de segurança semelhante para implementar os controles de segurança no Gerenciador de Segredos.

Implementação do GCP e contexto adicional:

Stakeholders de segurança do cliente (Saiba mais):