Bonnes pratiques pour Cloud HSM pour Google Workspace

Ce document décrit les bonnes pratiques de configuration de Cloud HSM pour Google Workspace. Il vous aidera à protéger votre matériel de clé contre toute destruction et suppression accidentelles ou non autorisées, à garantir une haute disponibilité et une durabilité pour les clés de chiffrement critiques, et à répondre aux exigences réglementaires et de conformité.

Ce document est destiné aux architectes cloud, aux équipes de sécurité et aux administrateurs Google Workspace responsables de la sécurité et de la résilience opérationnelle des clés de chiffrement utilisées dans le chiffrement côté client (CSE) pour Google Workspace. Il part du principe que vous connaissez déjà Cloud HSM pour Google Workspace et que vous avez terminé le processus d'intégration.

Atténuer la perte de matériel de clé

Des risques de sécurité peuvent survenir lorsqu'un compte principal dispose d'un rôle qui lui accorde l'autorisation d'effectuer des actions destructrices, en particulier celles qui ne relèvent pas de son champ d'activité habituel. Par exemple, un utilisateur disposant d'un rôle de Propriétaire du projet (roles/owner) trop large peut détruire le matériel de clé utilisé pour le CSE Google Workspace, ce qui rend les données chiffrées définitivement inaccessibles.

Les sections suivantes décrivent les pratiques qui permettent d'atténuer le risque de destruction et de suppression accidentelles et malveillantes de clés en supprimant les autorisations de destruction ou de suppression du matériel de clé Cloud KMS utilisé par le chiffrement côté client (CSE) de Google Workspace et en limitant la destruction des clés.

Appliquer des stratégies de refus IAM au niveau du dossier

Les stratégies de refus IAM vous permettent de refuser des autorisations à des comptes principaux, même si l'autorisation est accordée par un rôle dont dispose le compte principal. Par exemple, même si un utilisateur dispose du rôle de Propriétaire du projet (roles/owner), une stratégie de refus IAM au niveau du dossier peut l'empêcher de détruire ou de supprimer des clés. En plaçant votre projet Cloud HSM dans un dossier et en appliquant une stratégie de refus au niveau du dossier, vous créez une barrière de protection qui empêche la destruction et la suppression des clés tant que la stratégie est appliquée. Les stratégies de refus appliquées ne peuvent pas être annulées sans un rôle tel qu'administrateur de refus (roles/iam.denyAdmin) sur le dossier.

Assurez-vous que les rôles d'administration de dossiers tels qu'Administrateur de dossier (roles/resourcemanager.folderAdmin) et administrateur de refus (roles/iam.denyAdmin) ne sont accordés qu'aux comptes principaux qui ne disposent pas également du rôle d'administrateur Cloud KMS (roles/cloudkms.admin) sur le projet où résident vos clés Cloud HSM. Cette séparation des tâches garantit qu'aucun compte principal ne peut à la fois gérer et détruire des clés.

Définissez une stratégie de refus basée sur l'exemple de configuration suivant :

displayName: Deny KMS key destruction and deletion
rules:
- description: "Denies destroy and delete permissions on Cloud KMS keys for all principals."
  denyRule:
    deniedPrincipals:
    - "principalSet://goog/public:all"
    deniedPermissions:
    - "cloudkms.googleapis.com/cryptoKeyVersions.destroy"
    - "cloudkms.googleapis.com/cryptoKeys.delete"

Pour en savoir plus sur les stratégies de refus IAM, consultez la présentation des stratégies de refus IAM.

Appliquer des contraintes de règles d'administration pour la destruction des clés

Au-delà d'IAM, vous pouvez appliquer des barrières de protection au niveau de l'organisation ou du dossier à l'aide de contraintes de règles d'administration. Ces contraintes agissent comme des exigences strictes qui limitent les types de ressources pouvant être créés et leur mode de configuration. Les contraintes de règles d'administration appliquées ne peuvent pas être contournées, même par les comptes principaux disposant des autorisations requises pour effectuer l'action interdite. Les contraintes de règles d'administration appliquées ne peuvent pas être annulées sans un rôle tel qu'administrateur des règles d'administration (roles/orgpolicy.policyAdmin) dans l'organisation.

  • Durée minimale de destruction (constraints/cloudkms.minimumDestroyScheduledDuration) : impose une durée minimale programmée pour la destruction (par exemple, 90 ou 120 jours) pour toutes les clés de l'organisation ou de la ressource où la règle est activée. Cette contrainte empêche tout utilisateur de réduire la fenêtre de récupération en dessous de la valeur minimale configurée.
  • Désactiver avant de détruire (constraints/cloudkms.disableBeforeDestroy) : exige qu'une version de clé soit à l'état DISABLED avant de pouvoir être programmée pour destruction. Cette contrainte ajoute une étape obligatoire au workflow de destruction, ce qui augmente la visibilité de l'action dans les journaux d'audit.

Pour en savoir plus, consultez la page Contrôler la destruction d'une version de clé.

Maximiser la fenêtre de destruction des clés

Lorsqu'une version de clé est programmée pour destruction, elle entre dans une période de "suppression réversible". Tant qu'une version de clé est à l'état destruction programmée, vous pouvez restaurer la clé pour annuler sa destruction. Définir cette période configurable sur la durée maximale de 120 jours vous permet de disposer d'un délai suffisant pour restaurer une version de clé qui a été programmée pour destruction accidentellement ou de manière malveillante. Vous ne pouvez définir cette valeur que lorsque vous créez la clé.

Lorsque vous restaurez une version de clé qui a été programmée pour destruction, son état est défini sur DISABLED. Vous devez ensuite réactiver la version de clé pour restaurer l'accès à vos données Google Workspace chiffrées.

La commande suivante de gcloud CLI crée une clé basée sur HSM avec une durée de destruction programmée de 120 jours :

gcloud kms keys create KEY_NAME \
    --location LOCATION \
    --keyring KEY_RING \
    --purpose encryption \
    --protection-level hsm \
    --destroy-scheduled-duration 120d

Remplacez les éléments suivants :

  • KEY_NAME : nom de la clé.
  • LOCATION : emplacement Cloud KMS du trousseau de clés.
  • KEY_RING : nom du trousseau de clés qui inclut la clé.

Pour appliquer cette durée à toutes les clés de votre organisation plutôt que de la définir sur chaque clé, vous pouvez définir et appliquer une contrainte de règles d'administration personnalisée. L'exemple de contrainte suivant permet uniquement aux utilisateurs de créer une clé si la durée de destruction programmée est comprise entre 90 et 120 jours :

name: organizations/ORGANIZATION_ID/customConstraints/custom.limitScheduledDestruction
resourceTypes:
- cloudkms.googleapis.com/CryptoKey
methodTypes:
- CREATE
condition: "resource.destroyScheduledDuration >= duration('7776000s') && resource.destroyScheduledDuration <= duration('10368000s')"
actionType: ALLOW
displayName: Require scheduled destruction duration between 90 and 120 days
description: Allows key creation only if the destroyScheduledDuration is between 90 and 120 days.

Remplacez ORGANIZATION_ID par l'ID numérique de votre organisation.

Pour en savoir plus sur la configuration de la durée de destruction programmée, consultez la page Détruire et restaurer des versions de clé. Pour en savoir plus sur l'utilisation de contraintes de règles d'administration personnalisées avec Cloud KMS, consultez la page Créer des contraintes de règles d'administration personnalisées pour Cloud KMS.

Protéger votre infrastructure et votre projet

Les barrières de protection abordées précédemment dans ce document visent à empêcher la destruction et la suppression des clés. Toutefois, vous avez également besoin de barrières de protection pour empêcher la suppression du projet de clé. Utilisez les barrières de protection suivantes pour sécuriser l'environnement de projet qui héberge vos clés Google Workspace.

Appliquer des privilèges de projet

Un privilège de projet empêche la suppression d'un projet. Même un utilisateur disposant du rôle de Propriétaire du projet (roles/owner) ne peut pas arrêter le projet tant qu'un privilège est actif. Il s'agit du moyen le plus efficace d'empêcher la suppression accidentelle ou non autorisée du projet où résident vos clés Google Workspace.

Pour en savoir plus sur les privilèges de projet, consultez la page Protéger les projets à l'aide de privilèges.

Comprendre la fenêtre de récupération du projet

Si un projet est supprimé, par exemple après la suppression d'un privilège de projet (aperçu), il entre dans la fenêtre de récupération de 30 jours. Pendant cette période, un utilisateur disposant du rôle de Propriétaire du projet (roles/owner) ou d'administrateur de l'organisation (roles/resourcemanager.organizationAdmin) peut restaurer le projet. Après 30 jours, le projet et toutes les clés qu'il contient sont définitivement supprimés.

Nous vous recommandons de laisser les privilèges de projet en place et de ne compter sur la fenêtre de récupération qu'en dernier recours.

Pour en savoir plus sur la récupération de projet, consultez la page Restaurer un projet supprimé.

Utiliser VPC Service Controls

VPC Service Controls vous permet de définir un périmètre de sécurité autour de votre projet Cloud HSM. Cela permet de s'assurer que l'API Cloud KMS n'est accessible qu'à partir de réseaux approuvés ou d'identités spécifiques, ce qui réduit le risque d'actions administratives non autorisées en dehors de votre environnement d'entreprise.

Garantir la souveraineté du matériel de clé avec les clés importées (BYOK)

Pour la plupart des organisations, nous vous recommandons de laisser Cloud HSM générer et gérer le matériel de clé pour vous.

Toutefois, si vous avez besoin de fonctionnalités "apportez votre propre clé" (BYOK), vous pouvez générer votre matériel de clé sur site et l'importer dans Cloud HSM. Cette approche BYOK vous permet de répondre à des exigences telles que la conservation d'une copie indépendante et sur site de votre matériel de clé, par exemple pour répondre aux exigences de souveraineté des données ou pour vous remettre d'une perte catastrophique de matériel de clé. Cette approche vous offre une copie indépendante du matériel de clé que vous pouvez réimporter si la version de clé dans Cloud KMS est détruite.

Réimporter dans la même version

Cloud KMS vous permet de réimporter un matériel de clé identique dans la version de clé détruite, de sorte que l'identifiant de ressource et l'URI soient identiques à ceux de la version de clé importée d'origine. Vous pouvez ainsi continuer à utiliser les mêmes configurations Google Workspace. Lorsque vous réimportez une version de clé utilisée dans une configuration Google Workspace, l'accès aux données est rétabli dès que l'importation de la version de clé est terminée.

Pour en savoir plus sur la réimportation d'une version de clé détruite, consultez la page Réimporter une version de clé détruite.

Protection avancée avec Cloud HSM à locataire unique

Pour les clients qui exigent le plus haut niveau d'isolation, Cloud HSM à locataire unique fournit des partitions HSM dédiées. Votre instance Cloud HSM à locataire unique est créée et gérée à l'aide de l'authentification par quorum, qui nécessite l'approbation d'un nombre minimal configuré de membres du quorum avant les opérations critiques, telles que la suppression de l'instance Cloud HSM à locataire unique. Cela permet d'empêcher un seul compte compromis de détruire votre instance Cloud HSM à locataire unique. Les pratiques suivantes s'appliquent lorsque vous utilisez Cloud HSM à locataire unique. Pour en savoir plus, consultez la section Authentification basée sur le quorum.

Séparer l'infrastructure et les clés entre les projets

Créez l'instance Cloud HSM à locataire unique et vos clés Google Workspace dans des projets distincts. La séparation des projets de ressources permet de s'assurer qu'un utilisateur disposant de rôles d'administrateur sur le projet de clé n'a aucune autorité sur l'instance Cloud HSM à locataire unique sous-jacente. Cette séparation des tâches entre la gestion de l'infrastructure et la gestion des clés réduit le risque d'actions non autorisées au niveau de l'infrastructure.

Pour en savoir plus sur Cloud HSM à locataire unique, consultez la présentation de Cloud HSM à locataire unique.

Récapitulatif des bonnes pratiques

Le tableau suivant récapitule les bonnes pratiques recommandées dans ce document :

Sujet Tâche
Stratégies de refus IAM Appliquez des stratégies de refus au niveau du dossier pour bloquer la destruction et la suppression des clés, même pour les utilisateurs disposant de droits élevés.
Contraintes liées aux règles d'administration Appliquez des contraintes pour imposer une période de récupération minimale et exiger que les clés soient désactivées avant de pouvoir être détruites.
Période de destruction programmée
  • Créez votre clé avec la valeur destruction programmée définie sur le maximum de 120 jours. Vous pouvez également choisir une durée plus courte, mais assurez-vous qu'elle est suffisamment longue pour que les clés puissent être récupérées si elles sont programmées pour destruction.
  • Vous pouvez utiliser une contrainte de règles d'administration personnalisée pour vous assurer que toutes les clés sont créées avec une durée adaptée à vos besoins.
Privilèges de projet Appliquez des privilèges de projet pour empêcher la suppression du projet hébergeant vos clés de chiffrement.
Périmètre VPC Service Controls Définissez un périmètre VPC Service Controls pour limiter l'accès à l'API Cloud KMS aux réseaux et identités approuvés.
Réimportation BYOK Générez du matériel de clé sur site et utilisez la réimportation pour récupérer les versions de clé détruites sans modifier les noms de ressources.
Architecture inter-projets Si vous utilisez Cloud HSM à locataire unique, séparez l'instance Cloud HSM à locataire unique et les clés entre différents projets pour appliquer la séparation des tâches.

Étape suivante