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 via des 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 combinent les anciennes solutions de conformité Azure Purview et Microsoft 365, ainsi qu’Azure SQL Data Discovery and Classification pour analyser, classifier et étiqueter de manière centralisée les données sensibles qui résident dans Azure, localement, Microsoft 365 et d’autres emplacements.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Répliquez vos données de différentes sources vers un compartiment de stockage S3 et utilisez AWS Macie pour analyser, classifier et étiqueter les données sensibles stockées dans le compartiment. AWS Macie peut détecter des données sensibles telles que les informations d’identification de sécurité, les informations financières, les 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, classifier et étiqueter les données sensibles résidant dans un compartiment de stockage S3.

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

Implémentation AWS et contexte supplémentaire :

Conseils GCP : utilisez des outils tels que Google Cloud Data Loss Prevention pour analyser, classifier 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 DLP (Cloud Data Loss Prevention) pour 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.

Utilisez 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 sur le transfert anormal d’informations susceptibles d’indiquer des transferts non autorisés d’informations sensibles.

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 Place de marché Azure ou d’une solution Microsoft 365 DLP pour appliquer des contrôles détectives et/ou préventifs pour 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 vers 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 un 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/Event Threat Detection pour alerter sur le 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 de trafic) à l’aide du chiffrement pour vous assurer que les attaquants ne peuvent pas lire ou modifier facilement 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 de données natives en transit est intégrée.

Appliquez HTTPS pour les charges de travail et services d’application web en veillant à ce que tous les clients qui se connectent à vos ressources Azure utilisent tls (Transport Layer Security) 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 un transfert de fichiers sécurisé, utilisez le service SFTP/FTPS dans Stockage Azure Blob, 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. Et 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 native des données 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 les deux) en vous assurant 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 d’instances Amazon EC2 pris en charge. TLS v1.2 ou version ultérieure est activé sur la plupart des services AWS par défaut. Et certains services tels que 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é de chiffrement de données natives en transit est intégrée.

Appliquez le protocole HTTPS pour les charges de travail et services d’application web afin que tous les clients qui se connectent à vos ressources GCP utilisent 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 disposent d’un chiffrement 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 au nom du client et pivotées automatiquement toutes les deux ans.

Si 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 niveau fichier ou de la base de données.

Implémentation Azure et contexte supplémentaire :

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

Si 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 niveau 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 des données au repos activées 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 au nom du client et pivotées automatiquement.

Si 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 niveau fichier ou de la base de données.

Remarque : reportez-vous au document « Granularité du chiffrement pour les services Google Cloud » pour plus de détails.

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 de clé gérée par le client est nécessaire. Activez et implémentez 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 Standard, Premium et Managed HSM sont intégrés en mode natif à de nombreux services Azure pour les cas d’utilisation de clés gérés 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 des clés. Cela peut inclure la génération de clés 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é principale client gérée par le client stockée dans AWS Service de gestion de clés) pour certains services.

AWS Service de gestion de clés (KMS) est intégré en mode natif à de nombreux services AWS pour les cas d’usage clés principales du client gérés par le client. Vous pouvez utiliser AWS Service de gestion de clés (KMS) pour générer vos clés principales 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 des clés. Cela peut inclure la génération de clés 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 Service de gestion de clés (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 KMS cloud 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 des clés. Cela peut inclure la génération de clés 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 ID du PCI-DSS v3.2.1
N/A IA-5, SC-12, SC-28 3.6

Principe de sécurité : Documentez et implémentez une norme de gestion des clés de chiffrement d’entreprise, des processus et des procédures 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 votre cycle de vie des clés de chiffrement, notamment la génération de clés, la distribution et le stockage. 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 et la portabilité des matériaux 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 modules HSM locaux dans Azure Key Vault). Suivez les instructions recommandées pour effectuer la génération de clés et le transfert de clé.

Remarque : reportez-vous à la section ci-dessous pour 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 et 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 supérieur de sécurité de clé.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez AWS Service de gestion de clés (KMS) pour créer et contrôler votre cycle de vie des clés de chiffrement, notamment la génération de clés, la distribution et le stockage. Faites pivoter et révoquer vos clés dans KMS et votre service en fonction de la planification définie et quand une clé est mise hors service ou compromise.

Lorsqu’il est nécessaire d’utiliser la clé principale client gérée par le client dans les services de charge de travail ou les applications, 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 service 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 et la portabilité des matériaux 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 KMS ou Cloud HSM). Suivez les instructions recommandées pour effectuer la génération de clés et le transfert de clé.

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

Remarque : Reportez-vous aux informations ci-dessous pour le niveau FIPS 140-2 pour le niveau de conformité FIPS dans AWS KMS et CloudHSM :

  • Par défaut AWS KMS : FIPS 140-2 Niveau 2 validé
  • AWS KMS à l’aide de CloudHSM : FIPS 140-2 Niveau 3 (pour certains services) validés
  • 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 Cloud Service de gestion de clés (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. Faites pivoter et révoquer vos clés dans le cloud KMS et votre service en fonction de la planification définie et lorsqu’il existe une mise hors service ou une compromission de clé.

Utilisez le service HSM cloud de Google pour fournir des clés matérielles sauvegardées à Cloud KMS (Service de gestion de clés) 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ériel (HSM) entièrement managés.

Le service HSM cloud utilise des modules HSM, qui sont validés fiPS 140-2 de niveau 3 et qui sont toujours en cours d’exécution en mode FIPS. FiPS 140-2 Niveau 3 validé et s’exécute 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 modules 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 ID du PCI-DSS 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, notamment la création/importation, la rotation, la révocation, le stockage et le vidage 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 qui sont 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 racines/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 des certificats, notamment la création/l’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 quand un certificat expire. 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 l’état de renouvellement de votre certificat pour garantir 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 publics (signés par l’Autorité de certification Amazon) dans ACM et déployez-le par programme dans des services tels que CloudFront, Load Balancers, API Gateway, etc. Vous pouvez également utiliser ACM pour établir votre autorité de certification privée pour signer les certificats privés.

Remarque : Utilisez uniquement une autorité de certification approuvée et assurez-vous que les certificats racines/intermédiaires d’autorité de certification 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, notamment la création/importation, la rotation, la révocation, le stockage et le vidage 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 Certificate Manager et les services GCP pris en charge en fonction de la planification définie et quand un certificat expire. Si la rotation automatique n’est pas prise en charge dans l’application frontale, utilisez la rotation manuelle dans Certificate Manager. En attendant, vous devez toujours suivre l’état de renouvellement de votre certificat pour garantir 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 Certificate Manager et le 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 pour 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 ID du PCI-DSS v3.2.1
N/A IA-5, SC-12, SC-17 3.6

Principe de sécurité : vérifiez la sécurité du service key vault 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 et certificats de chiffrement en renforcéssant 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 Managed HSM au niveau de la clé pour garantir le moindre privilège et la séparation des principes de 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 inversement. Pour Azure Key Vault Standard et Premium, créez des coffres uniques pour différentes applications afin de garantir le moindre privilège et la séparation des principes de tâches.
  • Activez la journalisation Azure Key Vault pour vous assurer que les activités de plan de gestion et de plan de données critiques sont journalisées.
  • Sécuriser Azure Key Vault à l’aide de Private Link et de Pare-feu Azure pour garantir une exposition minimale du service
  • Utilisez l’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 protection contre la suppression réversible et le vidage pour éviter la suppression accidentelle de clés. Lorsque les 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 de chiffrement des données.
  • Pour apporter vos propres cas d’utilisation de clé (BYOK), 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 de clés au format en texte clair en dehors d’Azure Key Vault. 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 soutenus par 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 renforcéssant votre service AWS Service de gestion de clés (KMS) 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 clé) conjointement avec les stratégies IAM (contrôle d’accès basé sur l’identité) pour garantir le moindre privilège et la séparation des principes de 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 inversement.
  • Utilisez des contrôles détectives tels que CloudTrails pour consigner et suivre l’utilisation des clés dans KMS et vous avertir des actions critiques.
  • Ne stockez jamais les clés au format en texte clair en dehors de KMS.
  • Lorsque les 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 de 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 apporter votre propre clé (BYOK) utilise des cas, 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 renforcéssant 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 moindre privilège et la séparation des principes de 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 détectives tels que CloudTrails pour consigner 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 des certificats 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 renforcez vos Service de gestion de clés via les contrôles suivants :

  • Implémentez le contrôle d’accès à l’aide de rôles IAM pour garantir le moindre privilège et la séparation des principes de 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 inversement.
  • 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 de privilège minimum. Il permet également d’auditer plus facilement qui a accès aux clés au moment où.
  • 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 KMS GCP.

Pour la sécurité des certificats, sécurisez vos certificats en renforcéssant votre gestionnaire de certificats GCP et le service d’autorité de certification par le biais des 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 moindre privilège et la séparation des principes de 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 détectives tels que les journaux d’audit cloud pour consigner et suivre l’utilisation des certificats dans Certificate Manager 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) :