Controlo de Segurança: Proteção de dados

  • Artigo

A Proteção de Dados abrange o controlo da proteção de dados inativos, em trânsito e através de mecanismos de acesso autorizado, incluindo detetar, classificar, proteger e monitorizar recursos de dados confidenciais através do controlo de acesso, encriptação, gestão de chaves e gestão de certificados.|

DP-1: Detetar, classificar e etiquetar dados confidenciais

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) 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 âmbito de dados confidenciais definido. Utilize ferramentas para detetar, classificar e etiquetar os dados confidenciais no âmbito.

Orientação do Azure: utilize ferramentas como o Microsoft Purview, que combina as soluções de conformidade do Azure Purview e do Microsoft 365 anteriores, e SQL do Azure a Deteção e Classificação de Dados para analisar, classificar e etiquetar centralmente os dados confidenciais que residem no Azure, no local, no Microsoft 365 e noutras localizações.

Implementação do Azure e contexto adicional:

Orientação do AWS: replique os seus dados de várias origens para um registo de armazenamento S3 e utilize o Macie do AWS para digitalizar, classificar e etiquetar os dados confidenciais armazenados no registo. O Macie do AWS 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.

Também pode utilizar o conector de análise de várias clouds do Azure Purview para analisar, classificar e etiquetar os dados confidenciais que residem num registo de armazenamento S3.

Nota: também pode utilizar soluções empresariais de terceiros do AWS Marketplace para efeitos de classificação e etiquetagem de deteção de dados.

Implementação do AWS e contexto adicional:

Orientação do GCP: utilize ferramentas como a Prevenção de Perda de Dados do Google Cloud para analisar, classificar e etiquetar centralmente os dados confidenciais que residem no GCP e nos ambientes no local.

Além disso, utilize o Google Cloud Catálogo de Dados para utilizar os resultados de uma análise de Prevenção de Perda de Dados na Cloud (DLP) para identificar dados confidenciais com modelos de etiqueta 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

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

Princípio de segurança: monitorize anomalias em torno de dados confidenciais, como a transferência não autorizada de dados para localizações fora da visibilidade e controlo empresariais. 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: utilize o Azure Information Protection (AIP) para monitorizar os dados que foram classificados e etiquetados.

Utilize Microsoft Defender para Armazenamento, Microsoft Defender para SQL, Microsoft Defender para bases de dados relacionais open-source e Microsoft Defender do Cosmos DB para alertar sobre transferências anómalos de informações que possam indicar transferências não autorizadas de dados confidenciais informações.

Nota: se for necessário para a conformidade da prevenção de perda de dados (DLP), pode utilizar uma solução DLP baseada no anfitrião do Azure Marketplace ou uma solução DLP do Microsoft 365 para impor controlos de investigação e/ou prevenção para impedir a transferência de dados não autorizada.

Implementação do Azure e contexto adicional:

Orientação do AWS: utilize o Macie do AWS para monitorizar os dados que foram classificados e etiquetados e utilize GuardDuty para detetar atividades anómalas em alguns recursos (recursos S3, EC2 ou Kubernetes ou IAM). Os resultados e alertas podem ser triagem, analisados e controlados com EventBridge e reencaminhados para o Microsoft Sentinel ou o Hub de Segurança para agregação e controlo de incidentes.

Também pode ligar as suas contas do AWS ao Microsoft Defender para a Cloud para verificações de compatibilidade, segurança de contentores e capacidades de segurança de pontos finais.

Nota: se for necessário para a conformidade da prevenção de perda de dados (DLP), pode utilizar uma solução DLP baseada no anfitrião a partir do AWS Marketplace.

Implementação do AWS e contexto adicional:

Documentação de orientação do GCP: utilize o Centro de Comandos de Segurança do Google Cloud/Deteção de Ameaças de Eventos/Deteção de Anomalias para alertar sobre transferências anómalos de informações que possam indicar transferências não autorizadas de informações de dados confidenciais.

Também pode ligar as suas contas GCP ao Microsoft Defender para a Cloud para verificações de conformidade, segurança de contentores e capacidades de segurança de pontos finais.

Implementação do GCP e contexto adicional:

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

DP-3: Encriptar dados confidenciais em trânsito

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) 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 a captura de tráfego) através da encriptação para garantir que os atacantes não conseguem ler ou modificar facilmente os dados.

Defina o limite de rede e o âmbito do serviço em que os dados na encriptação de trânsito são obrigatórios dentro e fora da rede. Embora isto seja opcional para o tráfego em redes privadas, isto é fundamental para o tráfego em redes externas e públicas.

Orientação do Azure: impor a transferência segura em serviços como o Armazenamento do Azure, onde está incorporada uma funcionalidade de encriptação de dados nativos em trânsito.

Imponha HTTPS para cargas de trabalho e serviços de aplicações Web ao garantir que os clientes que se ligam aos seus recursos do Azure utilizam o transport layer security (TLS) v1.2 ou posterior. Para a gestão remota de VMs, utilize SSH (para Linux) ou RDP/TLS (para Windows) em vez de um protocolo não encriptado.

Para a gestão remota de máquinas virtuais do Azure, utilize SSH (para Linux) ou RDP/TLS (para Windows) em vez de um protocolo não encriptado. Para a transferência segura de ficheiros, utilize o serviço SFTP/FTPS no Blob de Armazenamento do Azure, Serviço de Aplicações aplicações e aplicações de Funções, em vez de utilizar o serviço de FTP normal.

Nota: os dados na encriptação de trânsito estão ativados para todo o tráfego do Azure que viaja entre datacenters do Azure. O TLS v1.2 ou posterior está ativado na maioria dos serviços do Azure por predefinição. Além disso, alguns serviços, como o Armazenamento do Azure e Gateway de Aplicação podem impor o TLS v1.2 ou posterior no lado do servidor.

Implementação do Azure e contexto adicional:

Orientação do AWS: impor a transferência segura em serviços como o Amazon S3, RDS e CloudFront, onde está incorporada uma funcionalidade de encriptação de dados nativos em trânsito.

Impor HTTPS (como no AWS Elastic Balanceador de Carga) para a aplicação Web e serviços de carga de trabalho (do lado do servidor ou do cliente, ou em ambos) ao garantir que os clientes que se ligam aos seus recursos do AWS utilizam o TLS v1.2 ou posterior.

Para a gestão remota de instâncias EC2, utilize SSH (para Linux) ou RDP/TLS (para Windows) em vez de um protocolo não encriptado. Para a transferência segura de ficheiros, utilize o serviço SFTP ou FTPS de Transferência do AWS em vez de um serviço de FTP normal.

Nota: todo o tráfego de rede entre datacenters do AWS é encriptado de forma transparente na camada física. Todo o tráfego dentro de um VPC e entre VPCs em modo de peering entre regiões é encriptado de forma transparente na camada de rede ao utilizar tipos de instância do Amazon EC2 suportados. O TLS v1.2 ou posterior está ativado na maioria dos serviços do AWS por predefinição. Além disso, alguns serviços, como o AWS Balanceador de Carga, podem impor o TLS v1.2 ou posterior no lado do servidor.

Implementação do AWS e contexto adicional:

Orientação do GCP: imponha a transferência segura em serviços como o Google Cloud Storage, onde está incorporada uma funcionalidade de encriptação de dados nativos em trânsito.

Impor HTTPS para cargas de trabalho e serviços de aplicações Web, garantindo que todos os clientes que se liguem aos seus recursos GCP utilizem o transport layer security (TLS) v1.2 ou posterior.

Para gestão remota, o Google Cloud Compute Engine utiliza SSH (para Linux) ou RDP/TLS (para Windows) em vez de um protocolo não encriptado. 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 de 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

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

Princípio de segurança: para complementar os controlos de acesso, os dados inativos devem ser protegidos contra ataques "fora de banda" (como aceder ao armazenamento subjacente) através da encriptação. Isto ajuda a garantir que os atacantes não conseguem ler ou modificar facilmente os dados.

Orientação do Azure: muitos serviços do Azure têm a encriptação de dados inativos ativada por predefinição na camada de infraestrutura com uma chave gerida pelo serviço. Estas chaves geridas pelo serviço são geradas em nome do cliente e rodadas automaticamente de dois em dois anos.

Quando tecnicamente viável e não ativado por predefinição, pode ativar a encriptação de dados inativos nos serviços do Azure ou nas suas VMs ao nível do armazenamento, ao nível do ficheiro ou da base de dados.

Implementação do Azure e contexto adicional:

Orientação do AWS: muitos serviços do AWS têm a encriptação de dados inativos ativada por predefinição na camada de infraestrutura/plataforma com uma chave mestra do cliente gerida pelo AWS. Estas chaves mestras do cliente geridas pelo AWS são geradas em nome do cliente e rodadas automaticamente a cada três anos.

Quando tecnicamente viável e não ativado por predefinição, pode ativar a encriptação de dados inativos nos serviços do AWS ou nas suas VMs ao nível do armazenamento, ao nível do ficheiro ou da base de dados.

Implementação do AWS e contexto adicional:

Orientação do GCP: muitos produtos e serviços do Google Cloud têm a encriptação de dados inativos ativada por predefinição na camada de infraestrutura com uma chave gerida pelo serviço. Estas chaves geridas do serviço são geradas em nome do cliente e rodadas automaticamente.

Quando tecnicamente viável e não ativado por predefinição, pode ativar a encriptação de dados inativos nos serviços GCP ou nas suas VMs ao nível do armazenamento, ao nível do ficheiro ou da base de dados.

Nota: consulte o documento "Granularidade da encriptação para serviços 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

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

Princípio de segurança: se necessário para a conformidade regulamentar, defina o caso de utilização e o âmbito do serviço em que é necessária a opção de chave gerida pelo cliente. Ative e implemente a encriptação de dados inativos com chaves geridas pelo cliente nos serviços.

Orientação do Azure: o Azure também fornece uma opção de encriptação através de chaves geridas por si (chaves geridas pelo cliente) para a maioria dos serviços.

O Azure Key Vault Standard, Premium e HSM Gerido estão integrados nativamente em muitos serviços do Azure para casos de utilização de chaves geridas pelo cliente. Pode utilizar o Azure Key Vault para gerar a sua chave ou trazer as suas próprias chaves.

No entanto, utilizar a opção chave gerida pelo cliente requer um esforço operacional adicional para gerir o ciclo de vida da chave. Isto pode incluir geração de chaves de encriptação, rotação, revogação e controlo de acesso, etc.

Implementação do Azure e contexto adicional:

Orientação do AWS: o AWS também fornece uma opção de encriptação através de chaves geridas por si (chave mestra do cliente gerida pelo cliente armazenada no Serviço de Gestão de Chaves do AWS) para determinados serviços.

O AWS Key Management Service (KMS) está integrado nativamente em muitos serviços do AWS para casos de utilização da chave mestra do cliente gerida pelo cliente. Pode utilizar o AWS Key Management Service (KMS) para gerar as chaves mestras ou trazer as suas próprias chaves.

No entanto, a utilização da opção de chave gerida pelo cliente requer esforços operacionais adicionais para gerir o ciclo de vida da chave. Isto pode incluir geração de chaves de encriptação, rotação, revogação e controlo de acesso, etc.

Implementação do AWS e contexto adicional:

Orientação do GCP: o Google Cloud fornece uma opção de encriptação através de chaves geridas por si (chaves geridas pelo cliente) para a maioria dos serviços.

O Google Cloud Key Management Service (CLOUD KMS) está integrado nativamente em muitos serviços GCP para chaves de encriptação geridas pelo cliente. Estas chaves podem ser criadas e geridas através do KMS da Cloud e o utilizador armazena as chaves como chaves de software, num cluster do HSM ou externamente. Pode utilizar o KMS da Cloud para gerar a sua chave ou fornecer as suas próprias chaves (chaves de encriptação fornecidas pelo cliente).

No entanto, a utilização da opção de chave gerida pelo cliente requer esforços operacionais adicionais para gerir o ciclo de vida da chave. Isto pode incluir geração de chaves de encriptação, rotação, revogação e controlo 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

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) 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 gestão de chaves criptográficas empresariais para controlar o ciclo de vida da sua chave. Quando for necessário utilizar a chave gerida pelo cliente nos serviços, utilize um serviço de cofre de chaves seguro para geração, distribuição e armazenamento de chaves. Rode e revogue as chaves com base na agenda definida e quando existe uma descontinuação ou comprometimento chave.

Orientação do Azure: utilize o Azure Key Vault para criar e controlar o ciclo de vida das chaves de encriptação, incluindo a geração de chaves, a distribuição e o armazenamento. Rode e revogue as chaves no Azure Key Vault e no seu serviço com base na agenda definida e quando existe uma descontinuação ou comprometimento chave. Exigir um determinado tipo criptográfico e o tamanho mínimo da chave ao gerar chaves.

Quando for necessário utilizar a chave gerida pelo cliente (CMK) nos serviços ou aplicações de carga de trabalho, certifique-se de que segue as melhores práticas:

  • Utilize uma hierarquia de chaves para gerar uma chave de encriptação de dados (DEK) separada com a chave de encriptação de chaves (KEK) no cofre de chaves.
  • Confirme 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 a duração e portabilidade dos materiais principais, traga a sua própria chave (BYOK) para os serviços (ou seja, importar chaves protegidas por HSM dos HSMs no local para o Azure Key Vault). Siga a orientação recomendada para efetuar a geração de chaves e a transferência de chaves.

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

  • 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 no HSM Gerido: FIPS 140-2 Nível 3

O Azure Key Vault Premium utiliza uma infraestrutura HSM partilhada no back-end. O Azure Key Vault HSM Gerido utiliza pontos finais de serviço dedicados e confidenciais com um HSM dedicado para quando precisa de um nível mais elevado de segurança de chave.

Implementação do Azure e contexto adicional:

Orientação do AWS: utilize o Serviço de Gestão de Chaves (KMS) do AWS para criar e controlar o ciclo de vida das chaves de encriptação, incluindo a geração de chaves, a distribuição e o armazenamento. Rode e revogue as chaves no KMS e no seu serviço com base na agenda definida e quando existe uma descontinuação ou comprometimento fundamental.

Quando for necessário utilizar a chave mestra do cliente gerida pelo cliente nos serviços ou aplicações de carga de trabalho, certifique-se de que segue as melhores práticas:

  • Utilize uma hierarquia de chaves para gerar uma chave de encriptação de dados (DEK) separada com a chave de encriptação de chave (KEK) no KMS.
  • Confirme que as chaves estão registadas no KMS e implementam através de políticas de IAM em cada serviço ou aplicação.

Para maximizar a duração e portabilidade dos materiais principais, traga a sua própria chave (BYOK) para os serviços (ou seja, importar chaves protegidas por HSM dos HSMs no local para KMS ou HSM na Cloud). Siga a orientação recomendada para efetuar a geração de chaves e a transferência de chaves.

Nota: o KMS do AWS utiliza a infraestrutura HSM partilhada no back-end. Utilize o Arquivo de Chaves Personalizadas KMS do AWS apoiado pelo AWS CloudHSM quando precisar de gerir o seu próprio arquivo de chaves e HSMs dedicados (por exemplo, requisitos de conformidade regulamentar para um nível mais elevado de segurança de chaves) para gerar e armazenar as chaves de encriptação.

Nota: veja o nível FIPS 140-2 para o nível de conformidade FIPS no KMS do AWS e cloudHSM:

  • AWS KMS predefinido: FIPS 140-2 Nível 2 validado
  • KMS do AWS com CloudHSM: FIPS 140-2 Nível 3 (para determinados serviços) validado
  • CloudHSM do AWS: FIPS 140-2 Nível 3 validado

Nota: para a gestão de segredos (credenciais, palavra-passe, chaves de API, etc.), utilize o Gestor de Segredos do AWS.

Implementação do AWS e contexto adicional:

Orientação do GCP: utilize o Cloud Key Management Service (CLOUD KMS) para criar e gerir ciclos de vida de chaves de encriptação em serviços Google Cloud compatíveis e nas suas aplicações de carga de trabalho. Rode e revogue as chaves no KMS da Cloud e no seu serviço com base na agenda definida e quando existe uma descontinuação ou comprometimento fundamental.

Utilize o serviço HSM da Cloud da Google para fornecer chaves suportadas por hardware ao KMS da Cloud (Serviço de Gestão de Chaves) Permite-lhe gerir e utilizar as suas próprias chaves criptográficas enquanto está protegido por Módulos de Segurança de Hardware (HSM) totalmente geridos.

O serviço HSM da Cloud utiliza HSMs, que são validados por FIPS 140-2 de 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 utilizados pelos HSMs.

Implementação do GCP e contexto adicional:

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

DP-7: Utilizar um processo de gestão de certificados seguro

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

Princípio de segurança: documente e implemente uma norma de gestão de certificados empresariais, processos e procedimentos que incluam o controlo de ciclo de vida do certificado e políticas de certificados (se for necessária uma infraestrutura de chave pública).

Certifique-se de que os certificados utilizados pelos serviços críticos na sua organização são inventariados, controlados, monitorizados e renovados em tempo útil através de um mecanismo automatizado para evitar a interrupção do serviço.

Orientação do Azure: utilize 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 remoção do certificado. Certifique-se de que a geração de certificados segue o padrão definido sem utilizar propriedades inseguras, como tamanho de chave insuficiente, período de validade demasiado longo, criptografia insegura, etc. Configure a rotação automática do certificado no Azure Key Vault e os serviços suportados do Azure com base na agenda definida e quando um certificado expira. Se a rotação automática não for suportada na aplicação de front-end, utilize uma rotação manual no Azure Key Vault.

Evite utilizar um certificado autoassinado e um certificado de caráter universal nos seus serviços críticos devido à garantia de segurança limitada. Em vez disso, pode criar certificados assinados públicos no Azure Key Vault. As seguintes Autoridades de Certificação (ACs) são os fornecedores parceiros que estão atualmente integrados no Azure Key Vault.

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

Nota: utilize apenas a AC aprovada e certifique-se de que os certificados de raiz/intermediários incorretos conhecidos emitidos por estas ACs estão desativados.

Implementação do Azure e contexto adicional:

Orientação do AWS: utilize o Gestor de Certificados do AWS (ACM) para criar e controlar o ciclo de vida do certificado, incluindo a criação/importação, rotação, revogação, armazenamento e remoção do certificado. Certifique-se de que a geração de certificados segue o padrão definido sem utilizar propriedades inseguras, como tamanho de chave insuficiente, período de validade demasiado longo, criptografia insegura, etc. Configure a rotação automática do certificado no ACM e os serviços do AWS suportados com base na agenda definida e quando um certificado expira. Se a rotação automática não for suportada na aplicação de front-end, utilize a rotação manual no ACM. Entretanto, deve controlar sempre o estado de renovação do certificado para garantir a validade do certificado.

Evite utilizar um certificado autoassinado e um certificado de caráter universal nos 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 implemente-os programaticamente em serviços como CloudFront, Balanceadores de Carga, Gateway de API, etc. Também pode utilizar o ACM para estabelecer a sua autoridade de certificação privada (AC) para assinar os certificados privados.

Nota: utilize apenas uma AC aprovada e certifique-se de que os certificados de raiz/intermediários de AC incorretos conhecidos emitidos por estas ACs estão desativados.

Implementação do AWS e contexto adicional:

Orientação do GCP: utilize o Google Cloud Certificate Manager para criar e controlar o ciclo de vida do certificado, incluindo a criação/importação, rotação, revogação, armazenamento e remoção do certificado. Certifique-se de que a geração de certificados segue o padrão definido sem utilizar propriedades inseguras, como tamanho de chave insuficiente, período de validade demasiado longo, criptografia insegura, etc. Configure a rotação automática do certificado no Gestor de Certificados e os serviços GCP suportados com base na agenda definida e quando um certificado expira. Se a rotação automática não for suportada na aplicação de front-end, utilize a rotação manual no Gestor de Certificados. Entretanto, deve controlar sempre o estado de renovação do certificado para garantir a validade do certificado.

Evite utilizar um certificado autoassinado e um certificado de caráter universal nos seus serviços críticos devido à garantia de segurança limitada. Em vez disso, pode criar certificados públicos assinados no Gestor de Certificados e implementá-lo programaticamente em serviços como o Balanceador de Carga e o Cloud DNS, etc. Também pode utilizar o Serviço de Autoridade de Certificação para estabelecer a sua autoridade de certificação privada (AC) para assinar os certificados privados.

Nota: também pode utilizar 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 da chave e do repositório de certificados

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) 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 do cofre de chaves utilizado para a gestão do ciclo de vida da chave criptográfica e do certificado. Proteja o serviço do cofre de chaves através do controlo de acesso, segurança de rede, registo e monitorização e cópia de segurança para garantir que as chaves e certificados estão sempre protegidos com a segurança máxima.

Orientação do Azure: proteja as chaves criptográficas e os certificados ao proteger o serviço de Key Vault do Azure através dos seguintes controlos:

  • Implemente o controlo de acesso com políticas RBAC no Azure Key Vault HSM Gerido ao nível-chave para garantir que são seguidos os princípios de menor privilégio e separação de deveres. Por exemplo, certifique-se de que a separação de deveres está em vigor para os utilizadores que gerem chaves de encriptação para que não tenham a capacidade de aceder a dados encriptados e vice-versa. Para o Azure Key Vault Standard e Premium, crie cofres exclusivos para diferentes aplicações para garantir que são seguidos os princípios de menor privilégio e separação de deveres.
  • Ative o registo de Key Vault do Azure para garantir que as atividades críticas do plano de gestão e do plano de dados são registadas.
  • Proteger a Key Vault do Azure com Private Link e Azure Firewall para garantir uma exposição mínima do serviço
  • Utilize a identidade gerida para aceder a chaves armazenadas no Azure Key Vault nas aplicações de carga de trabalho.
  • Ao remover dados, certifique-se de que as chaves não são eliminadas antes de os dados reais, as cópias de segurança e os arquivos serem removidos.
  • Faça uma cópia de segurança das chaves e certificados com o Azure Key Vault. Ative a eliminação recuperável e a proteção contra remoção para evitar a eliminação acidental de chaves. Quando as chaves precisarem de ser eliminadas, considere desativar as chaves em vez de as eliminar para evitar a eliminação acidental de chaves e a eliminação criptográfica de dados.
  • Para casos de utilização byok (bring your own key), gere chaves num HSM no local e importe-as para maximizar a duração e portabilidade das chaves.
  • Nunca armazene chaves em formato de texto simples fora do Key Vault do Azure. As chaves em todos os serviços do cofre de chaves não são exportáveis por predefinição.
  • Utilize tipos de chaves com suporte HSM (RSA-HSM) no Azure Key Vault Premium e no Azure Managed HSM para 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 do AWS: para segurança de chaves criptográficas, proteja as chaves ao proteger o serviço KMS (Key Management Service) do AWS através dos seguintes controlos:

  • Implemente o controlo de acesso através de políticas-chave (controlo de acesso ao nível da chave) em conjunto com as políticas de IAM (controlo de acesso baseado em identidade) para garantir que são seguidos os princípios de menor privilégio e separação de deveres. Por exemplo, certifique-se de que a separação de deveres está em vigor para os utilizadores que gerem chaves de encriptação para que não tenham a capacidade de aceder a dados encriptados e vice-versa.
  • Utilize controlos de detective, como o CloudTrails, para registar e controlar a utilização 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 de ser eliminadas, considere desativar as chaves no KMS em vez de as eliminar para evitar a eliminação acidental de chaves e a eliminação criptográfica de dados.
  • Ao remover dados, certifique-se de que as chaves não são eliminadas antes de os dados reais, as cópias de segurança e os arquivos serem removidos.
  • Para casos de utilização da sua própria chave (BYOK), gere chaves num HSM no local e importe-as para maximizar a duração e portabilidade das chaves.

Para segurança de certificados, proteja os certificados ao proteger o serviço AWS Certificate Manager (ACM) através dos seguintes controlos:

  • Implemente o controlo de acesso através de políticas ao nível dos recursos em conjunto com as políticas de IAM (controlo de acesso baseado em identidade) para garantir que são seguidos os princípios de menor privilégio e separação de deveres. Por exemplo, certifique-se de que a separação de deveres está em vigor para contas de utilizador: as contas de utilizador que geram certificados são separadas das contas de utilizador que apenas necessitam de acesso só de leitura aos certificados.
  • Utilize controlos de detective, como o CloudTrails, para registar e controlar a utilização dos certificados no ACM e alertá-lo sobre ações críticas.
  • Siga a documentação de orientação de segurança KMS para proteger a chave privada (gerada para pedido de certificado) utilizada para a integração de certificados de serviço.

Implementação do AWS e contexto adicional:

Orientação do GCP: para segurança de chaves criptográficas, proteja as chaves ao proteger o Seu Serviço de Gestão de Chaves através dos seguintes controlos:

  • Implemente o controlo de acesso com funções de IAM para garantir que são seguidos os princípios de menor privilégio e separação de deveres. Por exemplo, certifique-se de que a separação de deveres está em vigor para os utilizadores que gerem chaves de encriptação para que não tenham a capacidade de aceder a dados encriptados e vice-versa.
  • Crie uma cadência de chave separada para cada projeto que lhe permita gerir e controlar facilmente o acesso às chaves, seguindo a melhor prática de privilégios mínimos. Também facilita a auditoria de quem tem acesso a que chaves em quando.
  • Ative a rotação automática de chaves para garantir que as chaves são atualizadas e atualizadas regularmente. Isto ajuda a proteger-se contra potenciais ameaças de segurança, como ataques de força bruta ou atores maliciosos que tentam obter acesso a informações confidenciais.
  • Configure um sink de registo de auditoria para controlar todas as atividades que ocorrem no ambiente KMS do GCP.

Para a segurança dos certificados, proteja os certificados ao proteger o Gestor de Certificados do GCP e o Serviço de Autoridade de Certificação através dos seguintes controlos:

  • Implemente o controlo de acesso através de políticas ao nível dos recursos em conjunto com as políticas de IAM (controlo de acesso baseado em identidade) para garantir que são seguidos os princípios de menor privilégio e separação de deveres. Por exemplo, certifique-se de que a separação de deveres está em vigor para contas de utilizador: as contas de utilizador que geram certificados são separadas das contas de utilizador que apenas necessitam de acesso só de leitura aos certificados.
  • Utilize controlos de detective, como os Registos de Auditoria da Cloud, para registar e controlar a utilização dos certificados no Gestor de Certificados e alertá-lo sobre ações críticas.
  • O Gestor de Segredos também suporta o armazenamento do certificado TLS. Tem de seguir a prática de segurança semelhante para implementar os controlos de segurança no Gestor de Segredos.

Implementação do GCP e contexto adicional:

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