Partilhar via

Controlo 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: Detetar, classificar e etiquetar dados confidenciais

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

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

Orientação 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, no 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 detetar 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 varredura multinuvem 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 classificação e rotulagem de descoberta de dados.

Implementação da AWS e contexto adicional:

Orientação 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 em ambientes locais.

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

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

DP-2: Monitorizar anomalias e ameaças que visam dados confidenciais

Controles CIS v8 ID(s) NIST SP 800-53 r4 ID(s) ID 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 controle da empresa. Tipicamente, esta orientação envolve a monitorização de atividades anómalas (transferências grandes ou incomuns) que podem indicar a exfiltração não autorizada de dados.

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

Use o Microsoft Defender for Storage, o Microsoft Defender for SQL, o Microsoft Defender para bancos de dados relacionais de código aberto e o Microsoft Defender for Cosmos DB para alertar sobre a transferência anômala de informações que podem indicar transferências não autorizadas de informações confidenciais.

Nota: Se necessário para a conformidade da prevenção contra perda de dados (DLP), pode utilizar uma solução DLP baseada em anfitrião do Azure Marketplace ou uma solução DLP do Microsoft 365 para impor controlos detetives 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 detetar atividades anômalas em alguns recursos (recursos do S3, EC2 ou Kubernetes ou do IAM). As descobertas e 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 for Cloud para verificações de conformidade, segurança de contêiner e recursos de segurança de endpoint.

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/Anomaly Detection para alertar sobre a transferência anômala de informações que possam indicar transferências não autorizadas de informações confidenciais.

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

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

DP-3: Encriptar dados confidenciais em trânsito

Controles CIS v8 ID(s) NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
3,10 SC-8 3.5, 3.6, 4.1

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

Defina o limite da rede e o escopo do serviço onde a criptografia de dados em trânsito é obrigatória dentro e fora da rede. Embora isso seja opcional para o tráfego em redes privadas, isso é crítico para o tráfego em redes externas e públicas.

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

Imponha HTTPS para cargas de trabalho e serviços de aplicativos Web garantindo que todos os clientes que se conectam aos seus recursos do Azure usem 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ção, em vez de usar o serviço FTP regular.

Observação: a criptografia de dados em trânsito está habilitada para todo o tráfego do Azure que viaja 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 Aplicativos, podem impor o TLS v1.2 ou posterior no lado do servidor.

Implementação do Azure e contexto adicional:

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

Imponha HTTPS (como no AWS Elastic Load Balancer) para aplicativos e serviços da web de carga de trabalho (no lado do servidor ou 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 o 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 uma transferência segura de arquivos, use o serviço AWS Transfer SFTP ou FTPS em vez de um serviço FTP normal.

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 uma VPC e entre VPCs emparelhadas entre regiões é criptografado de forma transparente na camada de rede ao usar tipos de instância compatíveis do Amazon EC2. 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:

Orientação do GCP: imponha a transferência segura em serviços como o Google Cloud Storage, onde um recurso nativo de criptografia de dados em trânsito está incorporado.

Imponha HTTPS para cargas de trabalho e serviços de aplicativos Web, garantindo que todos os clientes que se conectam aos seus recursos GCP usem TLS (Transport Layer Security) 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 ficheiros, utilize 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 normal.

Implementação do GCP e contexto adicional:

Intervenientes na segurança do cliente (Saiba mais):

DP-4: Ativar a encriptação de dados inativos por predefinição

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

Princípio de segurança: Para complementar os controlos de acesso, os dados em repouso devem ser protegidos contra ataques «fora da banda» (como o acesso ao armazenamento subjacente) utilizando encriptação. Isso ajuda a garantir que os invasores não possam ler ou modificar facilmente os dados.

Orientação 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 por 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, nível de arquivo ou nível de banco de dados.

Implementação do Azure e contexto adicional:

Orientação da AWS: muitos serviços da AWS têm a criptografia de dados em repouso habilitada por padrão na camada de infraestrutura/plataforma usando uma chave mestra do cliente gerenciada pela AWS. Essas chaves mestras do 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 de arquivo ou no nível de banco de dados.

Implementação da AWS e contexto adicional:

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

Quando tecnicamente viável e não habilitado por padrão, você pode habilitar a criptografia de dados em repouso nos serviços GCP ou em suas VMs no nível de armazenamento, no nível de arquivo ou no nível de 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:

Intervenientes na segurança do cliente (Saiba mais):

DP-5: Utilize a opção chave gerida pelo cliente na encriptação de dados inativos quando necessário

Controles CIS v8 ID(s) NIST SP 800-53 r4 ID(s) ID 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 regulamentar, defina o caso de uso e o escopo do serviço onde a opção de chave gerenciada pelo cliente é necessária. Habilite e implemente a criptografia de dados em repouso usando chaves gerenciadas pelo cliente em serviços.

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

O Azure Key Vault Standard, Premium e Managed HSM são integrados nativamente com 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ê mesmo (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 chaves mestras gerenciadas 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 fornece uma opção de criptografia usando chaves gerenciadas por você mesmo (chaves gerenciadas pelo cliente) para a maioria dos serviços.

O Google Cloud Key Management Service (Cloud KMS) é integrado nativamente com muitos serviços 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:

Intervenientes na segurança do cliente (Saiba mais):

DP-6: Utilizar um processo de gestão de chaves segura

Controles CIS v8 ID(s) NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
N/A 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 houver necessidade de usar a chave gerenciada pelo cliente nos serviços, use um serviço de cofre de chaves seguro para geração, distribuição e armazenamento de chaves. Gire e revogue suas chaves com base no cronograma definido e quando houver uma desativação ou comprometimento da chave.

Orientação do Azure: use o Cofre da Chave do Azure 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 Cofre de Chaves do Azure e em seu serviço com base no cronograma definido e quando houver uma desativação ou comprometimento de chaves. Exija um determinado tipo criptográfico e tamanho mínimo de chave ao gerar chaves.

Quando houver necessidade de usar a chave gerenciada pelo cliente (CMK) 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 chave de criptografia de dados (DEK) separada com sua chave de criptografia de chave (KEK) no cofre de chaves.
  • Certifique-se de que as chaves estão registadas no Azure Key Vault e implementadas através de IDs de chave em cada serviço ou aplicação.

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

Nota: Consulte abaixo o nível FIPS 140-2 para tipos de Cofre de Chaves do Azure e nível de conformidade/validação FIPS.

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

O Azure Key Vault Premium usa uma infraestrutura HSM compartilhada no back-end. O Azure Key Vault Managed HSM 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:

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. Gire e revogue suas chaves no KMS e seu serviço com base no cronograma definido e quando houver uma desativação ou comprometimento de chaves.

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 chave de criptografia de dados (DEK) separada com sua chave de criptografia de chave (KEK) no KMS.
  • Certifique-se de que as chaves sejam registradas no KMS e implementadas por meio de políticas do IAM em cada serviço ou aplicativo.

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

Observação: o AWS KMS usa infraestrutura HSM compartilhada no back-end. Use o AWS KMS Custom Key Store apoiado pelo AWS CloudHSM quando precisar gerenciar seu próprio armazenamento de chaves e HSMs dedicados (por exemplo, requisitos de conformidade regulamentar para um nível mais alto de segurança de chaves) para gerar e armazenar suas chaves de criptografia.

Nota: Consulte abaixo o nível FIPS 140-2 para o nível de conformidade FIPS no AWS KMS e CloudHSM:

  • Padrão do AWS KMS: 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 o gerenciamento de segredos (credenciais, senha, chaves de API, etc.), use o AWS Secrets Manager.

Implementação da AWS e contexto adicional:

Orientação 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. Gire e revogue suas chaves no Cloud KMS e seu serviço com base no cronograma definido e quando houver uma desativação ou comprometimento de chaves.

Use o serviço Cloud HSM do Google para fornecer chaves com suporte de hardware para o Cloud KMS (Serviço de Gerenciamento de Chaves) Ele oferece a capacidade de gerenciar e usar suas próprias chaves criptográficas enquanto está protegido por módulos de segurança de hardware (HSM) 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. 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:

Intervenientes na segurança do cliente (Saiba mais):

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

Controles CIS v8 ID(s) NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
N/A IA-5, SC-12, SC-17 3.6

Princípio de segurança: documentar e implementar 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).

Certifique-se de que os certificados usados pelos serviços críticos em sua organização sejam inventariados, rastreados, monitorados e renovados oportunamente usando o mecanismo automatizado para evitar a interrupção do serviço.

Orientação 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 de certificados siga o padrão definido sem usar propriedades inseguras, como tamanho insuficiente da chave, período de validade excessivamente longo, criptografia insegura e assim por diante. Configure a rotação automática do certificado no Cofre da Chave do Azure e os serviços do Azure com suporte com base na agenda definida e quando um certificado expirar. Se a rotação automática não for suportada no aplicativo front-end, use uma rotação manual no Cofre da Chave do Azure.

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 Cofre da Chave do Azure. As seguintes Autoridades de Certificação (CAs) são os provedores parceiros que estão atualmente integrados ao Cofre de Chaves do Azure.

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

Nota: Use apenas a autoridade de certificação aprovada e certifique-se de que os certificados root/intermediários incorretos conhecidos emitidos por essas autoridades de certificação 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 de certificados siga o padrão definido sem usar propriedades inseguras, como tamanho insuficiente da chave, período de validade excessivamente longo, criptografia insegura e assim por diante. Configure a rotação automática do certificado no ACM e nos serviços da AWS suportados com base no cronograma definido e quando um certificado expirar. Se a rotação automática não for suportada no aplicativo frontend, 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 Amazon Certificate Authority) 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.

Nota: Use apenas uma autoridade de certificação aprovada e certifique-se de que os certificados root/intermediários de CA incorretos conhecidos emitidos por essas autoridades de certificação estejam desabilitados.

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 de certificados siga o padrão definido sem usar propriedades inseguras, como tamanho insuficiente da chave, 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 suportados com base no cronograma definido e quando um certificado expirar. Se a rotação automática não for suportada no aplicativo frontend, 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 (CA) 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:

Intervenientes na segurança do cliente (Saiba mais):

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

Controles CIS v8 ID(s) NIST SP 800-53 r4 ID(s) ID PCI-DSS v3.2.1
N/A 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 através de controle de acesso, segurança de rede, registro e monitoramento e backup para garantir que as chaves e certificados estejam sempre protegidos usando a máxima segurança.

Orientação 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 Azure Key Vault Managed HSM no nível de chave para garantir que os princípios de menor privilégio e separação de tarefas sejam seguidos. Por exemplo, certifique-se de que 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 os princípios de menor privilégio e separação de tarefas sejam seguidos.
  • Ative o log do Cofre da Chave do Azure para garantir que as atividades críticas do plano de gerenciamento e do plano de dados sejam registradas.
  • Proteja o Cofre da Chave do Azure usando o Private Link e o Firewall do Azure para garantir uma exposição mínima do serviço
  • Use a identidade gerenciada para acessar chaves armazenadas no Cofre de Chaves do Azure em seus aplicativos de carga de trabalho.
  • Ao limpar dados, certifique-se de que suas 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 proteção de exclusão suave e 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 a eliminação criptográfica de dados.
  • Para trazer seus próprios casos de uso de chave (BYOK), gere chaves em um HSM local e importe-as para maximizar a vida útil e a portabilidade das chaves.
  • Nunca armazene chaves em formato de texto simples fora do Cofre de Chaves do Azure. As chaves em todos os serviços do cofre de chaves não são exportáveis por padrão.
  • Use tipos de chave apoiados por HSM (RSA-HSM) no Azure Key Vault Premium e no Azure Managed HSM para obter a proteção de hardware e os níveis FIPS mais fortes.

Ative o Microsoft Defender para o Key Vault, para obter proteção avançada nativa do Azure contra ameaças para o Azure Key Vault, o que fornece uma camada adicional de informações 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 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 menor privilégio e separação de tarefas sejam seguidos. Por exemplo, certifique-se de que 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 rastrear 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 as 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 suas 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 protegendo seu serviço AWS Certificate Manager (ACM) por meio dos seguintes controles:

  • Implemente o controle de acesso usando políticas de nível de recursos em conjunto com políticas do IAM (controle de acesso baseado em identidade) para garantir que os princípios de menor privilégio e separação de tarefas sejam seguidos. Por exemplo, certifique-se de que a separação de tarefas esteja 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 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 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 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 menor privilégio e separação de tarefas sejam seguidos. Por exemplo, certifique-se de que 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 porta-chaves separado para cada projeto, o que permite 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 no momento.
  • Habilite a rotação automática de chaves para garantir que elas 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 controlar todas as atividades que ocorrem em seu ambiente KMS do GCP.

Para segurança de certificados, proteja seus certificados protegendo o Gerenciador de Certificados 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 recursos em conjunto com políticas do IAM (controle de acesso baseado em identidade) para garantir que os princípios de menor privilégio e separação de tarefas sejam seguidos. Por exemplo, certifique-se de que a separação de tarefas esteja 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 Secret Manager também suporta o armazenamento de certificados 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:

Intervenientes na segurança do cliente (Saiba mais):