La séparation des tâches est un principe d'organisation permettant de s'assurer qu'un compte principal ne sera pas en mesure d'obtenir toutes les autorisations nécessaires à la réalisation d'une action malveillante. Dans Cloud Key Management Service, il peut s'agir d'une action telle que l'utilisation d'une clé pour accéder et déchiffrer des données auxquelles l'utilisateur n'a aucune raison légitime d'accéder.
La séparation des tâches est une solution de contrôle d'entreprise généralement utilisée dans les grandes organisations, dans l'optique d'éviter les incidents et les erreurs compromettant la sécurité ou la confidentialité des données. Cette approche est considérée comme une bonne pratique.
Dans Cloud KMS, la séparation des tâches nécessite une distinction stricte entre les rôles suivants :
- Gestionnaires de clés : principaux autorisés à gérer le cycle de vie des clés, y compris leur création, leur suppression, leur rotation et les changements d'état (par exemple, les utilisateurs disposant du rôle Administrateur Cloud KMS).
- Utilisateurs clés : principaux autorisés à utiliser des clés, y compris pour le chiffrement, le déchiffrement, la signature ou la validation de signature. Par exemple, les utilisateurs disposant du rôle Chiffreur/Déchiffreur de CryptoKeys Cloud KMS.
Lorsque vous utilisez des clés Cloud KMS pour les clés de chiffrement gérées par le client, nous vous recommandons que le compte de service soit le seul principal autorisé à utiliser la clé pour le chiffrement et le déchiffrement. Pour en savoir plus sur la façon dont les intégrations CMEK gèrent l'accès aux ressources, consultez Gestion de l'accès aux ressources par les services intégrés à CMEK.
Si vous souhaitez créer un garde-fou pour appliquer cette recommandation, vous pouvez utiliser des stratégies de refus IAM pour supprimer les autorisations de chiffrement et de déchiffrement des comptes principaux autres que les comptes de service. Pour en savoir plus sur l'utilisation sécurisée des rôles IAM, consultez Utiliser IAM en toute sécurité.
Gouvernance des clés
La gouvernance des clés décrit les personnes responsables de la gestion du cycle de vie de vos ressources Cloud KMS et du maintien des mesures de protection pour contrôler l'utilisation de Cloud KMS dans une organisation. Il existe des approches de gouvernance clés qui s'étendent du centralisé au délégué :
- Gouvernance centralisée : une équipe de sécurité ou de plate-forme dédiée est chargée de gérer le cycle de vie de toutes les clés cryptographiques de l'organisation. Ce modèle est souvent choisi par les entreprises très réglementées qui doivent respecter des exigences de conformité strictes.
- Gouvernance déléguée : une équipe de sécurité centrale utilise des garde-fous pour imposer des normes de chiffrement, mais délègue la responsabilité des opérations liées au cycle de vie des clés aux propriétaires d'applications dans leurs projets. Ces garde-fous peuvent inclure des règles d'administration utilisant des contraintes gérées et des contraintes personnalisées, ainsi que des stratégies IAM d'autorisation et de refus. Cela élimine les goulots d'étranglement opérationnels centraux.
Le stockage des clés
Le stockage de clés décrit l'emplacement où les ressources Cloud KMS sont créées dans une organisation. Il existe deux approches principales pour le stockage des clés : le stockage des clés dans un projet dédié et le stockage des clés dans le même projet.
Stockage des clés dans un projet dédié : un projet de clés dédié contient des clés utilisées pour plusieurs applications. En général, chaque dossier d'environnement possède son propre projet de clés. Vous pouvez utiliser Autokey avec le stockage des clés dans un projet dédié.
Stockage des clés dans le même projet : les clés sont stockées dans le même projetCloud de Confiance que les ressources qu'elles protègent. On parle parfois de "la clé suit les données". Vous pouvez utiliser Autokey avec le stockage des clés dans le même projet.
Aligner la gouvernance et le stockage
La matrice suivante fournit des exemples de combinaisons de ces modèles de gouvernance et de stockage pour répondre aux différents besoins des organisations :
| Modèle de gouvernance | Stockage des clés dans un projet dédié | Stockage des clés dans le même projet |
|---|---|---|
| Gouvernance centralisée | Approche entièrement centralisée Utilisation recommandée : organisations soumises à des exigences réglementaires strictes qui imposent l'isolation des limites de projet. Impact opérationnel : complexité de configuration élevée. Nécessite une automatisation robuste (comme une "usine à projets") pour éviter les retards opérationnels pour les équipes de développement. |
Propriété régie Utilisation recommandée : organisations qui ont besoin d'une supervision centralisée de la sécurité, mais qui souhaitent maximiser la vélocité des développeurs. Impact opérationnel : complexité de configuration faible. La sécurité centralisée applique les règles à l'aide de garde-fous, tandis que les clés sont colocalisées avec les ressources qu'elles protègent pour faciliter la gestion. |
| Gouvernance déléguée | Déconseillé L'introduction d'une complexité IAM interprojets va à l'encontre de l'objectif de délégation de la gestion des clés aux équipes d'application. |
DevOps autonome Utilisation recommandée : organisations décentralisées à grande vitesse avec une forte culture DevOps. Impact opérationnel : complexité de configuration minimale. Les équipes chargées des applications disposent d'une autonomie totale sur les ressources et les clés dans les limites de leur projet. |
Stockage des clés dans le même projet
Pour appliquer la séparation des tâches dans la gestion des clés d'un même projet, vous devez veiller à ce que les rôles IAM soient strictement séparés. Par exemple, vous pouvez utiliser des stratégies de refus IAM pour supprimer les autorisations de chiffrement et de déchiffrement de vos responsables des clés.
Vous pouvez activer Autokey avec le stockage des clés dans le même projet au niveau d'un projet ou d'un dossier pour autoriser la création automatique de clés dans le même projet que la ressource qu'elles protègent. Pour en savoir plus, consultez Activer Autokey avec le stockage des clés dans le même projet.
Stockage des clés dans un projet dédié
Dans le modèle de stockage de clés dans un projet dédié, les projets de clés dédiés sont gérés par une équipe de sécurité centrale, qui dispose d'autorisations d'administration des clés dans le projet de clés, mais n'a pas accès aux projets contenant les ressources protégées par ces clés.
Vous pouvez activer Autokey avec le stockage des clés dans un projet dédié sur un dossier pour autoriser la création automatique de clés à l'aide du modèle de stockage centralisé des clés. Pour en savoir plus, consultez Configurer Autokey avec un stockage de clés de projet dédié.
Automatiser et surveiller la conformité
Cloud de Confiance fournit les outils suivants pour automatiser et surveiller vos limites de sécurité :
- Cloud KMS Autokey : Autokey est compatible avec le stockage des clés dans un projet dédié et dans le même projet. Dans les deux cas, il automatise la séparation des tâches en attribuant automatiquement le rôle d'utilisation de la clé à l'agent de service requis, et non à la personne qui demande la clé. Autokey est conçu pour prendre en charge les pipelines d'infrastructure en tant que code qui n'ont pas besoin de privilèges élevés pour la création de clés.
- Security Command Center : surveillez les résultats de la séparation des rôles KMS pour détecter tout principal, y compris un Propriétaire du projet ou un compte de service Google, qui possède à la fois des autorisations administratives et cryptographiques sur une même clé.
- Métriques de chiffrement CMEK : utilisez le tableau de bord Métriques de chiffrement pour vérifier l'alignement avec les pratiques de séparation des tâches dans l'ensemble de l'organisation.