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 valable 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 : comptes principaux autorisés à gérer le cycle de vie des clés, y compris la création, la suppression, la rotation et les changements d'état. Par exemple, les utilisateurs disposant du rôle Administrateur Cloud KMS.
- Utilisateurs de clés : comptes principaux autorisés à utiliser des clés, y compris pour le chiffrement, le déchiffrement, la signature ou la vérification 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 de faire en sorte que le compte de service soit le seul compte 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 la section Les services intégrés à CMEK gèrent l'accès aux ressources.
Si vous souhaitez créer une barrière de protection 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 la section Utiliser IAM en toute sécurité.
Gouvernance des clés
La gouvernance des clés décrit qui, dans une organisation, est responsable de la gestion du cycle de vie de vos ressources Cloud KMS et du maintien des barrières de protection pour contrôler l'utilisation de Cloud KMS. Les approches de gouvernance des clés se situent sur un spectre allant de la gouvernance centralisée à la gouvernance déléguée :
- Gouvernance centralisée : une équipe de sécurité ou de plate-forme dédiée est responsable de la gestion du cycle de vie de toutes les clés de chiffrement de l' organisation. Ce modèle est souvent choisi par les entreprises fortement réglementées qui doivent respecter des exigences de conformité strictes.
- Gouvernance déléguée : une équipe de sécurité centrale utilise des barrières de protection pour imposer des normes de chiffrement, mais délègue la responsabilité des opérations du cycle de vie des clés aux propriétaires d'applications au sein de leurs projets. Ces barrières de protection peuvent inclure des règles d'administration utilisant des contraintes gérées et des contraintes personnalisées, ainsi que des autorisations et des stratégies de refus IAM. Cela élimine les goulots d'étranglement opérationnels centraux.
Stockage des clés
Le stockage des clés décrit l'endroit où les ressources Cloud KMS sont créées au sein d'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 règle générale, 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 Google Cloud projet 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 la manière dont ces modèles de gouvernance et de stockage peuvent être combinés pour répondre aux différents besoins de l'organisation :
| 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 (telle qu'une "usine de projets") pour éviter les retards opérationnels pour les équipes de développement. |
Propriété régie Utilisation recommandée : organisations qui nécessitent une supervision centralisée de la sécurité mais qui souhaitent maximiser la vitesse de développement. Impact opérationnel : faible complexité de configuration. La sécurité centrale applique la règle à l'aide de barrières de protection, 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 inter-projets va à l'encontre de l'objectif de déléguer la gestion des clés aux équipes d'application. |
DevOps autonome Utilisation recommandée : organisations décentralisées à haute vitesse avec une forte culture DevOps. Impact opérationnel : complexité de configuration minimale. Les équipes d'application 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
L'application de la séparation des tâches dans la gestion des clés dans le même projet nécessite de maintenir les rôles IAM 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 gestionnaires de clés.
Vous pouvez activer Autokey avec le stockage des clés dans le même projet sur un projet ou un dossier pour autoriser la création automatisée de clés dans le même projet que la ressource que la clé protège. Pour en savoir plus, consultez la section 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 des 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 qui 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 automatisée de clés à l'aide du modèle de stockage des clés centralisé. Pour en savoir plus, consultez la section Configurer Autokey avec le stockage des clés dans un projet dédié.
Automatiser et surveiller la conformité
Google Cloud 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 le stockage des clés dans le même projet. Dans les deux cas, il automatise la séparation des tâches en accordant 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 as 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 Séparation des rôles KMS pour détecter tout compte 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 seule clé.
- Métriques de chiffrement CMEK : utilisez le tableau de bord Métriques de chiffrement pour vérifier l'alignement sur les pratiques de séparation des tâches dans l'ensemble de l' organisation.