Partager via

Contrôle de sécurité : Protection des données

  • Article

La protection des données couvre le contrôle de la protection des données au repos, en transit et par le biais de mécanismes d’accès autorisés, notamment la découverte, la classification, la protection et la surveillance des ressources de données sensibles à l’aide du contrôle d’accès, du chiffrement, de la gestion des clés et de la gestion des certificats.|

DP-1 : Découvrir, classer et étiqueter des données sensibles

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
3.2, 3.7, 3.13 RA-2, SC-28 A3.2

Principe de sécurité : Établissez et gérez un inventaire des données sensibles, en fonction de l’étendue des données sensibles définie. Utilisez les outils pour découvrir, classer et étiqueter les données sensibles dans l’étendue.

Conseils Azure : Utilisez des outils tels que Microsoft Purview, qui combine les anciennes solutions de conformité Azure Purview et Microsoft 365, et Azure SQL découverte et classification des données pour analyser, classer et étiqueter de manière centralisée les données sensibles qui résident dans Azure, en local, dans Microsoft 365 et dans d’autres emplacements.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Répliquez vos données de différentes sources dans un compartiment de stockage S3 et utilisez AWS Macie pour analyser, classer et étiqueter les données sensibles stockées dans le compartiment. AWS Macie peut détecter des données sensibles telles que des informations d’identification de sécurité, des informations financières, des données PHI et PII, ou d’autres modèles de données en fonction des règles d’identificateur de données personnalisées.

Vous pouvez également utiliser le connecteur d’analyse multicloud Azure Purview pour analyser, classer et étiqueter les données sensibles résidant dans un compartiment de stockage S3.

Remarque : Vous pouvez également utiliser des solutions d’entreprise tierces de la Place de marché AWS à des fins de classification et d’étiquetage de la découverte des données.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : utilisez des outils tels que Google Cloud Data Loss Prevention pour analyser, classer et étiqueter de manière centralisée les données sensibles qui résident dans les environnements GCP et locaux.

En outre, utilisez Google Cloud Data Catalog pour utiliser les résultats d’une analyse de protection contre la perte de données cloud (DLP) afin d’identifier les données sensibles avec des modèles d’étiquette définis.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DP-2 : surveiller les anomalies et les menaces ciblant les données sensibles

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
3.13 AC-4, SI-4 A3.2

Principe de sécurité : Surveillez les anomalies relatives aux données sensibles, telles que le transfert non autorisé de données vers des emplacements en dehors de la visibilité et du contrôle de l’entreprise. Cela implique généralement de surveiller des activités anormales (transferts volumineux ou inhabituels) qui pourraient être le signe d’une exfiltration de données non autorisée.

Conseils Azure : Utilisez Azure Information Protection (AIP) pour surveiller les données qui ont été classifiées et étiquetées.

Utiliser Microsoft Defender pour le stockage, Microsoft Defender pour SQL, Microsoft Defender pour les bases de données relationnelles open source et Microsoft Defender pour Cosmos DB pour alerter en cas de transfert anormal d’informations susceptibles d’indiquer des transferts non autorisés de données sensibles Informations.

Remarque : si nécessaire pour la conformité de la protection contre la perte de données (DLP), vous pouvez utiliser une solution DLP basée sur l’hôte de Place de marché Azure ou une solution DLP Microsoft 365 pour appliquer des contrôles détectives et/ou préventifs afin d’empêcher l’exfiltration des données.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez AWS Macie pour surveiller les données qui ont été classifiées et étiquetées, et utilisez GuardDuty pour détecter les activités anormales sur certaines ressources (ressources S3, EC2 ou Kubernetes ou IAM). Les résultats et les alertes peuvent être triés, analysés et suivis à l’aide d’EventBridge et transférés à Microsoft Sentinel ou à Security Hub pour l’agrégation et le suivi des incidents.

Vous pouvez également connecter vos comptes AWS à Microsoft Defender pour le cloud pour les vérifications de conformité, la sécurité des conteneurs et les fonctionnalités de sécurité des points de terminaison.

Remarque : si nécessaire pour la conformité de la protection contre la perte de données (DLP), vous pouvez utiliser une solution DLP basée sur l’hôte à partir de la Place de marché AWS.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez Google Cloud Security Command Center/Event Threat Detection/Detection d’anomalie pour alerter en cas de transfert anormal d’informations susceptibles d’indiquer des transferts non autorisés d’informations sensibles.

Vous pouvez également connecter vos comptes GCP à Microsoft Defender pour le cloud pour les vérifications de conformité, la sécurité des conteneurs et les fonctionnalités de sécurité des points de terminaison.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DP-3 : chiffrer les données sensibles en transit

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
3.10 SC-8 3.5, 3.6, 4.1

Principe de sécurité : protégez les données en transit contre les attaques « hors bande » (telles que la capture du trafic) à l’aide du chiffrement pour garantir que les attaquants ne peuvent pas facilement lire ou modifier les données.

Définissez la limite de réseau et l’étendue de service dans lesquelles le chiffrement des données en transit est obligatoire à l’intérieur et à l’extérieur du réseau. C’est certes facultatif pour le trafic sur les réseaux privés, mais essentiel pour le trafic sur les réseaux externes et publics.

Conseils Azure : Appliquez un transfert sécurisé dans des services tels que Stockage Azure, où une fonctionnalité de chiffrement des données natives en transit est intégrée.

Appliquez HTTPS pour les charges de travail et les services d’application web en veillant à ce que tous les clients qui se connectent à vos ressources Azure utilisent la sécurité de la couche de transport (TLS) v1.2 ou version ultérieure. Pour la gestion à distance de machines virtuelles, utilisez SSH (pour Linux) ou RDP/TLS (pour Windows) plutôt qu’un protocole non chiffré.

Pour la gestion à distance des machines virtuelles Azure, utilisez SSH (pour Linux) ou RDP/TLS (pour Windows) au lieu d’un protocole non chiffré. Pour sécuriser le transfert de fichiers, utilisez le service SFTP/FTPS dans Stockage Blob Azure, les applications App Service et les applications de fonction, au lieu d’utiliser le service FTP standard.

Remarque : le chiffrement de données en transit est activé pour l’ensemble du trafic Azure s’effectuant entre les centres de données Azure. TLS v1.2 ou version ultérieure est activé sur la plupart des services Azure par défaut. Certains services tels que Stockage Azure et Application Gateway peuvent appliquer TLS v1.2 ou version ultérieure côté serveur.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Appliquez un transfert sécurisé dans des services tels qu’Amazon S3, RDS et CloudFront, où une fonctionnalité de chiffrement des données natives en transit est intégrée.

Appliquez HTTPS (par exemple, dans AWS Elastic Load Balancer) pour les services et applications web de charge de travail (côté serveur ou côté client, ou sur les deux) en veillant à ce que tous les clients qui se connectent à vos ressources AWS utilisent TLS v1.2 ou version ultérieure.

Pour la gestion à distance des instances EC2, utilisez SSH (pour Linux) ou RDP/TLS (pour Windows) au lieu d’un protocole non chiffré. Pour un transfert de fichiers sécurisé, utilisez le service AWS Transfer SFTP ou FTPS au lieu d’un service FTP standard.

Remarque : tout le trafic réseau entre les centres de données AWS est chiffré de manière transparente au niveau de la couche physique. Tout le trafic au sein d’un VPC et entre les VPN appairés entre les régions est chiffré de manière transparente au niveau de la couche réseau lors de l’utilisation des types de instance Amazon EC2 pris en charge. TLS v1.2 ou version ultérieure est activé sur la plupart des services AWS par défaut. Certains services tels qu’AWS Load Balancer peuvent appliquer TLS v1.2 ou version ultérieure côté serveur.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Appliquez un transfert sécurisé dans des services tels que Google Cloud Storage, où une fonctionnalité native de chiffrement des données en transit est intégrée.

Appliquez le protocole HTTPS pour les charges de travail et les services d’application web en veillant à ce que tous les clients qui se connectent à vos ressources GCP utilisent le protocole TLS (Transport Layer Security) v1.2 ou version ultérieure.

Pour la gestion à distance, Google Cloud Compute Engine utilise SSH (pour Linux) ou RDP/TLS (pour Windows) au lieu d’un protocole non chiffré. Pour un transfert de fichiers sécurisé, utilisez le service SFTP/FTPS dans des services tels que Google Cloud Big Query ou Cloud App Engine au lieu d’un service FTP standard.

Implémentation gcp et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DP-4 : activer le chiffrement des données au repos par défaut

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
3.11 SC-28 3.4, 3.5

Principe de sécurité : pour compléter les contrôles d’accès, les données au repos doivent être protégées contre les attaques « hors bande » (telles que l’accès au stockage sous-jacent) à l’aide du chiffrement. Cela vise à empêcher que les attaquants puissent facilement lire ou modifier les données.

Conseils Azure : De nombreux services Azure ont le chiffrement des données au repos activé par défaut au niveau de la couche d’infrastructure à l’aide d’une clé gérée par le service. Ces clés gérées par le service sont générées pour le compte du client et pivotées automatiquement tous les deux ans.

Lorsque cela est techniquement possible et non activé par défaut, vous pouvez activer le chiffrement des données au repos dans les services Azure ou dans vos machines virtuelles au niveau du stockage, du fichier ou de la base de données.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : De nombreux services AWS ont le chiffrement des données au repos activé par défaut au niveau de la couche infrastructure/plateforme à l’aide d’une clé de master client gérée par AWS. Ces clés de master client gérées par AWS sont générées pour le compte du client et pivotées automatiquement tous les trois ans.

Lorsque cela est techniquement possible et non activé par défaut, vous pouvez activer le chiffrement des données au repos dans les services AWS ou dans vos machines virtuelles au niveau du stockage, du fichier ou de la base de données.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : De nombreux produits et services Google Cloud ont le chiffrement des données au repos activé par défaut au niveau de la couche d’infrastructure à l’aide d’une clé gérée par le service. Ces clés gérées par le service sont générées pour le compte du client et automatiquement pivotées.

Lorsque cela est techniquement possible et non activé par défaut, vous pouvez activer le chiffrement des données au repos dans les services GCP ou dans vos machines virtuelles au niveau du stockage, du fichier ou de la base de données.

Remarque : Pour plus d’informations, reportez-vous au document « Granularité du chiffrement pour les services Google Cloud ».

Implémentation gcp et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DP-5 : utiliser l’option de clé gérée par le client dans le chiffrement des données au repos si nécessaire

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
3.11 SC-12, SC-28 3.4, 3.5, 3.6

Principe de sécurité : si nécessaire pour la conformité réglementaire, définissez le cas d’usage et l’étendue du service où l’option clé gérée par le client est nécessaire. Activez et implémentez le chiffrement des données au repos à l’aide de clés gérées par le client dans les services.

Conseils Azure : Azure fournit également une option de chiffrement à l’aide de clés gérées par vous-même (clés gérées par le client) pour la plupart des services.

Azure Key Vault HSM standard, Premium et managé sont intégrés en mode natif à de nombreux services Azure pour les cas d’utilisation de clés gérées par le client. Vous pouvez utiliser Azure Key Vault pour générer votre clé ou apporter vos propres clés.

Toutefois, l’utilisation de l’option de clé gérée par le client nécessite un effort opérationnel supplémentaire pour gérer le cycle de vie de la clé. Cela peut inclure la génération de clé de chiffrement, la rotation, la révocation et le contrôle d’accès, etc.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : AWS fournit également une option de chiffrement à l’aide de clés gérées par vous-même (clé gérée par le client master stockée dans AWS Key Management Service) pour certains services.

AWS Key Management Service (KMS) est intégré en mode natif à de nombreux services AWS pour les cas d’utilisation clés master client gérés par le client. Vous pouvez utiliser AWS Key Management Service (KMS) pour générer vos clés master ou apporter vos propres clés.

Toutefois, l’utilisation de l’option de clé gérée par le client nécessite des efforts opérationnels supplémentaires pour gérer le cycle de vie de la clé. Cela peut inclure la génération de clé de chiffrement, la rotation, la révocation et le contrôle d’accès, etc.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Google Cloud fournit une option de chiffrement à l’aide de clés gérées par vous-même (clés gérées par le client) pour la plupart des services.

Google Cloud Key Management Service (Cloud KMS) est intégré en mode natif à de nombreux services GCP pour les clés de chiffrement gérées par le client. Ces clés peuvent être créées et gérées à l’aide de KmS cloud, et vous stockez les clés en tant que clés logicielles, dans un cluster HSM ou en externe. Vous pouvez utiliser Cloud KMS pour générer votre clé ou fournir vos propres clés (clés de chiffrement fournies par le client).

Toutefois, l’utilisation de l’option de clé gérée par le client nécessite des efforts opérationnels supplémentaires pour gérer le cycle de vie de la clé. Cela peut inclure la génération de clé de chiffrement, la rotation, la révocation et le contrôle d’accès, etc.

Implémentation gcp et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DP-6 : Utiliser un processus sécurisé de gestion de clés

ID des contrôles CIS v8 ID NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
N/A IA-5, SC-12, SC-28 3.6

Principe de sécurité : documentez et implémentez une norme, des processus et des procédures de gestion des clés de chiffrement d’entreprise pour contrôler votre cycle de vie de clé. Lorsqu’il est nécessaire d’utiliser une clé gérée par le client dans les services, utilisez un service de coffre de clés sécurisé pour la génération, la distribution et le stockage de clés. Faites pivoter et révoquez vos clés suivant la planification définie et en cas de suppression ou de compromission d’une clé.

Conseils Azure : Utilisez Azure Key Vault pour créer et contrôler le cycle de vie de vos clés de chiffrement, y compris la génération, la distribution et le stockage des clés. Faites pivoter et révoquez vos clés dans Azure Key Vault et votre service en fonction de la planification définie et en cas de suppression ou de compromission d’une clé. Exiger un certain type de chiffrement et une taille de clé minimale lors de la génération de clés.

Lorsqu’il est nécessaire d’utiliser la clé gérée par le client dans les services de charge de travail ou les applications, veillez à respecter les meilleures pratiques :

  • Utilisez une hiérarchie de clés pour générer une clé de chiffrement de données distincte avec votre clé de chiffrement principale dans votre coffre de clés.
  • Vérifiez que les clés sont inscrites auprès d’Azure Key Vault et implémentées via des ID de clé dans chaque service ou application.

Pour optimiser la durée de vie matérielle et la portabilité des clés, apportez votre propre clé (BYOK) aux services (c’est-à-dire l’importation de clés protégées par HSM à partir de vos HSM locaux dans Azure Key Vault). Suivez les recommandations recommandées pour effectuer la génération et le transfert de clé.

Remarque : Reportez-vous à ce qui suit pour connaître le niveau FIPS 140-2 pour les types Azure Key Vault et le niveau de conformité/validation FIPS.

  • Clés protégées par logiciel dans les coffres (références SKU Premium & Standard) : FIPS 140-2 Niveau 1
  • Clés protégées par HSM dans des coffres (SKU Premium) : FIPS 140-2 niveau 2
  • Clés protégées par HSM dans un HSM managé : FIPS 140-2 niveau 3

Azure Key Vault Premium utilise une infrastructure HSM partagée dans le back-end. Azure Key Vault Managed HSM utilise des points de terminaison de service dédiés et confidentiels avec un HSM dédié lorsque vous avez besoin d’un niveau de sécurité de clé plus élevé.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez AWS Key Management Service (KMS) pour créer et contrôler le cycle de vie de vos clés de chiffrement, notamment la génération, la distribution et le stockage de clés. Faire pivoter et révoquer vos clés dans KMS et votre service en fonction de la planification définie et en cas de retrait ou de compromission de clé.

Lorsqu’il est nécessaire d’utiliser des master client gérés par le client dans les services ou applications de charge de travail, veillez à suivre les meilleures pratiques :

  • Utilisez une hiérarchie de clés pour générer une clé de chiffrement de données distincte (DEK) avec votre clé de chiffrement de clé (KEK) dans votre KMS.
  • Vérifiez que les clés sont inscrites auprès de KMS et implémentent via des stratégies IAM dans chaque service ou application.

Pour optimiser la durée de vie matérielle et la portabilité des clés, apportez votre propre clé (BYOK) aux services (par exemple, l’importation de clés protégées par HSM à partir de vos HSM locaux dans KMS ou HSM cloud). Suivez les recommandations recommandées pour effectuer la génération et le transfert de clé.

Remarque : AWS KMS utilise l’infrastructure HSM partagée dans le back-end. Utilisez le magasin de clés personnalisé AWS KMS soutenu par AWS CloudHSM lorsque vous devez gérer votre propre magasin de clés et vos HSM dédiés (par exemple, exigences de conformité réglementaire pour un niveau de sécurité de clé plus élevé) pour générer et stocker vos clés de chiffrement.

Remarque : reportez-vous à ce qui suit pour le niveau FIPS 140-2 pour le niveau de conformité FIPS dans AWS KMS et CloudHSM :

  • Aws KMS par défaut : FIPS 140-2 Niveau 2 validé
  • AWS KMS à l’aide de CloudHSM : FIPS 140-2 Niveau 3 (pour certains services) validé
  • AWS CloudHSM : FIPS 140-2 Niveau 3 validé

Remarque : Pour la gestion des secrets (informations d’identification, mot de passe, clés API, etc.), utilisez AWS Secrets Manager.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez le service de gestion des clés cloud (CLOUD KMS) pour créer et gérer les cycles de vie des clés de chiffrement dans les services Google Cloud compatibles et dans vos applications de charge de travail. Faire pivoter et révoquer vos clés dans le cloud KMS et votre service en fonction de la planification définie et en cas de retrait ou de compromission de clé.

Utilisez le service Cloud HSM de Google pour fournir des clés matérielles à Cloud KMS (Key Management Service) Il vous permet de gérer et d’utiliser vos propres clés de chiffrement tout en étant protégé par des modules de sécurité matériels (HSM) entièrement managés.

Le service HSM cloud utilise des HSM, qui sont validés FIPS 140-2 Niveau 3 et qui s’exécutent toujours en mode FIPS. FIPS 140-2 Niveau 3 validé et toujours en mode FIPS. La norme FIPS spécifie les algorithmes de chiffrement et la génération de nombres aléatoires utilisés par les HSM.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DP-7 : utiliser un processus de gestion des certificats sécurisé

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

Principe de sécurité : Documentez et implémentez une norme de gestion des certificats d’entreprise, des processus et des procédures qui incluent le contrôle du cycle de vie des certificats et les stratégies de certificat (si une infrastructure à clé publique est nécessaire).

Assurez-vous que les certificats utilisés par les services critiques de votre organisation sont inventoriés, suivis, surveillés et renouvelés en temps voulu à l’aide d’un mécanisme automatisé afin d’éviter toute interruption de service.

Conseils Azure : Utilisez Azure Key Vault pour créer et contrôler le cycle de vie des certificats, y compris la création/importation, la rotation, la révocation, le stockage et la purge du certificat. Assurez-vous que générer des certificats respecte la norme définie sans utiliser de propriétés non sécurisées, telles que ’une taille de clé insuffisante, une période de validité trop longue, un chiffrement non sécurisé, etc. Configurez la rotation automatique du certificat dans Azure Key Vault et les services Azure pris en charge en fonction de la planification définie et de l’expiration d’un certificat. Si la rotation automatique n’est pas prise en charge dans l’application frontale, utilisez une rotation manuelle dans Azure Key Vault.

Évitez d’utiliser un certificat auto-signé et un certificat générique dans vos services critiques en raison de l’assurance de sécurité limitée. Au lieu de cela, vous pouvez créer des certificats signés publics dans Azure Key Vault. Les autorités de certification suivantes sont les fournisseurs partenaires actuellement intégrés à Azure Key Vault.

  • DigiCert : Azure Key Vault propose des certificats OV TSL/SSL avec DigiCert.
  • GlobalSign : Azure Key Vault propose des certificats OV TSL/SSL avec GlobalSign.

Remarque : Utilisez uniquement l’autorité de certification approuvée et assurez-vous que les certificats racine/intermédiaires connus émis par ces autorités de certification sont désactivés.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez AWS Certificate Manager (ACM) pour créer et contrôler le cycle de vie du certificat, y compris la création/importation, la rotation, la révocation, le stockage et la purge du certificat. Assurez-vous que générer des certificats respecte la norme définie sans utiliser de propriétés non sécurisées, telles que ’une taille de clé insuffisante, une période de validité trop longue, un chiffrement non sécurisé, etc. Configurez la rotation automatique du certificat dans ACM et les services AWS pris en charge en fonction de la planification définie et de l’expiration d’un certificat. Si la rotation automatique n’est pas prise en charge dans l’application frontale, utilisez la rotation manuelle dans ACM. En attendant, vous devez toujours suivre le renouvellement de votre certificat status pour vous assurer de la validité du certificat.

Évitez d’utiliser un certificat auto-signé et un certificat générique dans vos services critiques en raison de l’assurance de sécurité limitée. Au lieu de cela, créez des certificats signés publiquement (signés par l’autorité de certification Amazon) dans ACM et déployez-les par programmation dans des services tels que CloudFront, Load Balancers, API Gateway, etc. Vous pouvez également utiliser ACM pour établir votre autorité de certification privée afin de signer les certificats privés.

Remarque : Utilisez uniquement une autorité de certification approuvée et assurez-vous que les certificats racine/intermédiaires d’autorité de certification incorrects connus émis par ces autorités de certification sont désactivés.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez Google Cloud Certificate Manager pour créer et contrôler le cycle de vie des certificats, y compris la création/importation, la rotation, la révocation, le stockage et la purge du certificat. Assurez-vous que générer des certificats respecte la norme définie sans utiliser de propriétés non sécurisées, telles que ’une taille de clé insuffisante, une période de validité trop longue, un chiffrement non sécurisé, etc. Configurez la rotation automatique du certificat dans le Gestionnaire de certificats et les services GCP pris en charge en fonction de la planification définie et de l’expiration d’un certificat. Si la rotation automatique n’est pas prise en charge dans l’application front-end, utilisez la rotation manuelle dans Le Gestionnaire de certificats. En attendant, vous devez toujours suivre le renouvellement de votre certificat status pour vous assurer de la validité du certificat.

Évitez d’utiliser un certificat auto-signé et un certificat générique dans vos services critiques en raison de l’assurance de sécurité limitée. Au lieu de cela, vous pouvez créer des certificats publics signés dans le Gestionnaire de certificats et les déployer par programmation dans des services tels que Load Balancer et DNS cloud, etc. Vous pouvez également utiliser le service d’autorité de certification pour établir votre autorité de certification privée afin de signer les certificats privés.

Remarque : Vous pouvez également utiliser Google Cloud Secret Manager pour stocker des certificats TLS.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DP-8 : garantir la sécurité du référentiel de clés et de certificats

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

Principe de sécurité : assurez la sécurité du service de coffre de clés utilisé pour la gestion du cycle de vie des clés de chiffrement et des certificats. Renforcez votre service de coffre de clés à l’aide du contrôle d’accès, de la sécurité réseau, de la journalisation, de la surveillance et de la sauvegarde, pour garantir la protection de sécurité maximale constante des clés et des certificats.

Conseils Azure : Sécurisez vos clés de chiffrement et certificats en améliorant votre service Azure Key Vault via les contrôles suivants :

  • Implémentez le contrôle d’accès à l’aide de stratégies RBAC dans Azure Key Vault HSM managé au niveau de la clé pour garantir le respect des principes de privilèges minimum et de séparation des tâches. Par exemple, assurez-vous que la séparation des tâches est en place pour les utilisateurs qui gèrent les clés de chiffrement afin qu’ils n’aient pas la possibilité d’accéder aux données chiffrées, et vice versa. Pour Azure Key Vault Standard et Premium, créez des coffres uniques pour différentes applications afin de garantir le respect des principes de privilège minimum et de séparation des tâches.
  • Activez la journalisation azure Key Vault pour vous assurer que les activités du plan de gestion et du plan de données critiques sont journalisées.
  • Sécuriser les Key Vault Azure à l’aide de Private Link et de Pare-feu Azure pour garantir une exposition minimale du service
  • Utilisez une identité managée pour accéder aux clés stockées dans Azure Key Vault dans vos applications de charge de travail.
  • Lors de la suppression définitive des données, assurez-vous que vos clés ne soient pas supprimées avant que les réelles données, les sauvegardes et les archives soient définitivement supprimées.
  • Sauvegardez vos clés et certificats à l’aide d’Azure Key Vault. Activez la suppression réversible et la protection contre le vidage pour éviter la suppression accidentelle de clés. Lorsque des clés doivent être supprimées, envisagez de désactiver les clés au lieu de les supprimer pour éviter la suppression accidentelle de clés et l’effacement par chiffrement des données.
  • Pour les cas d’usage BYOK (bring your own key), générez des clés dans un HSM local et importez-les pour optimiser la durée de vie et la portabilité des clés.
  • Ne stockez jamais les clés au format texte clair en dehors de l’Key Vault Azure. Les clés de tous les services de coffre de clés ne sont pas exportables par défaut.
  • Utilisez des types de clés adossées à HSM (RSA-HSM) dans Azure Key Vault Premium et Azure Managed HSM pour la protection matérielle et les niveaux FIPS les plus forts.

Activez Microsoft Defender pour Key Vault afin de bénéficier d’une protection avancée native Azure contre les menaces pour Azure Key Vault, qui fournit une couche supplémentaire de veille de sécurité.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Pour la sécurité des clés de chiffrement, sécurisez vos clés en durcissant votre service KMS (AWS Key Management Service) via les contrôles suivants :

  • Implémentez le contrôle d’accès à l’aide de stratégies clés (contrôle d’accès au niveau de la clé) conjointement avec les stratégies IAM (contrôle d’accès basé sur l’identité) pour garantir le respect des principes de privilèges minimum et de séparation des tâches. Par exemple, assurez-vous que la séparation des tâches est en place pour les utilisateurs qui gèrent les clés de chiffrement afin qu’ils n’aient pas la possibilité d’accéder aux données chiffrées, et vice versa.
  • Utilisez des contrôles de détection tels que CloudTrails pour journaliser et suivre l’utilisation des clés dans KMS et vous avertir des actions critiques.
  • Ne stockez jamais de clés au format texte clair en dehors de KMS.
  • Lorsque des clés doivent être supprimées, envisagez de désactiver les clés dans KMS au lieu de les supprimer pour éviter la suppression accidentelle des clés et l’effacement par chiffrement des données.
  • Lors de la suppression définitive des données, assurez-vous que vos clés ne soient pas supprimées avant que les réelles données, les sauvegardes et les archives soient définitivement supprimées.
  • Pour les cas d’utilisation byOK (bring your own key), générez des clés dans un HSM local et importez-les pour optimiser la durée de vie et la portabilité des clés.

Pour la sécurité des certificats, sécurisez vos certificats en durcissant votre service AWS Certificate Manager (ACM) via les contrôles suivants :

  • Implémentez le contrôle d’accès à l’aide de stratégies au niveau des ressources conjointement avec les stratégies IAM (contrôle d’accès basé sur l’identité) pour garantir le respect des principes de privilèges minimum et de séparation des tâches. Par exemple, assurez-vous que la séparation des tâches est en place pour les comptes d’utilisateur : les comptes d’utilisateur qui génèrent des certificats sont distincts des comptes d’utilisateur qui nécessitent uniquement un accès en lecture seule aux certificats.
  • Utilisez des contrôles de détection tels que CloudTrails pour journaliser et suivre l’utilisation des certificats dans ACM, et vous avertir des actions critiques.
  • Suivez les instructions de sécurité KMS pour sécuriser votre clé privée (générée pour la demande de certificat) utilisée pour l’intégration du certificat de service.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Pour la sécurité des clés de chiffrement, sécurisez vos clés en durcissant votre service de gestion des clés via les contrôles suivants :

  • Implémentez le contrôle d’accès à l’aide de rôles IAM pour garantir le respect des principes de privilège minimum et de séparation des tâches. Par exemple, assurez-vous que la séparation des tâches est en place pour les utilisateurs qui gèrent les clés de chiffrement afin qu’ils n’aient pas la possibilité d’accéder aux données chiffrées, et vice versa.
  • Créez un anneau de clés distinct pour chaque projet, ce qui vous permet de gérer et de contrôler facilement l’accès aux clés en suivant les meilleures pratiques en matière de privilèges minimum. Il est également plus facile d’auditer qui a accès à quelles clés à quel moment.
  • Activez la rotation automatique des clés pour vous assurer que les clés sont régulièrement mises à jour et actualisées. Cela permet de se protéger contre les menaces de sécurité potentielles telles que les attaques par force brute ou les acteurs malveillants qui tentent d’accéder à des informations sensibles.
  • Configurez un récepteur de journal d’audit pour suivre toutes les activités qui se produisent dans votre environnement GCP KMS.

Pour la sécurité des certificats, sécurisez vos certificats en durcissant votre gestionnaire de certificats GCP et votre service d’autorité de certification via les contrôles suivants :

  • Implémentez le contrôle d’accès à l’aide de stratégies au niveau des ressources conjointement avec les stratégies IAM (contrôle d’accès basé sur l’identité) pour garantir le respect des principes de privilèges minimum et de séparation des tâches. Par exemple, assurez-vous que la séparation des tâches est en place pour les comptes d’utilisateur : les comptes d’utilisateur qui génèrent des certificats sont distincts des comptes d’utilisateur qui nécessitent uniquement un accès en lecture seule aux certificats.
  • Utilisez des contrôles de détection tels que les journaux d’audit cloud pour journaliser et suivre l’utilisation des certificats dans le Gestionnaire de certificats, et vous avertir des actions critiques.
  • Secret Manager prend également en charge le stockage du certificat TLS. Vous devez suivre la pratique de sécurité similaire pour implémenter les contrôles de sécurité dans Secret Manager.

Implémentation gcp et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :