Bonnes pratiques concernant Secret Manager

Ce guide présente quelques bonnes pratiques lors de l'utilisation de Secret Manager. Ce guide n'est pas une liste exhaustive de recommandations. Nous vous recommandons de consulter les présentation de la plate-forme. de l'environnement Google Cloud global et Présentation de Secret Manager avant de lire ce guide.

Contrôle des accès

L'accès à l'API Secret Manager est protégé par IAM. Respectez le principe du moindre privilège lorsque vous accordez des autorisations aux secrets.

• Limitez la propriété de l'organisation à un compte super-administrateur sécurisé.

• Segmentez les applications et les environnements (préproduction ou production) en projets distincts, comme décrit dans la section Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud. Cela peut aider à isoler les environnements avec une liaison IAM au niveau du projet et à garantir l'application indépendante des quotas.

• Choisir un rôle sélectionné disposant des autorisations minimales nécessaires, ou créez un rôle personnalisé si nécessaire.

• Lorsque les secrets de nombreux services se trouvent dans un seul projet, utilisez niveau secret Liaisons IAM, ou IAM Conditions pour limiter l'accès au sous-ensemble de secrets nécessaire.

• Outil de recommandation IAM peut vous aider à identifier plus facilement les liaisons IAM privilégiées.

Ces identifiants sont requis pour s'authentifier auprès de l'API Secret Manager. La Les bibliothèques clientes utilisent toutes une stratégie similaire pour rechercher les identifiants Application Default Credentials (Identifiants par défaut de l'application).

• Lorsque vous développez en local, utilisez gcloud auth application-default login. Cela crée un fichier avec des identifiants automatiquement récupérées par les bibliothèques clientes.

• Sur Compute Engine et d'autres plates-formes de calcul Google Cloud telles que fonctions Cloud Run, les bibliothèques clientes obtiennent des identifiants via la serveur de métadonnées d'instance.

• Sur GKE, Workload Identity fournit également des identifiants via un service de métadonnées.

• Sur d'autres plates-formes comme Amazon Web Services ou Microsoft Azure, envisagez configurer la fédération d'identité de charge de travail ; qui s'authentifie auprès des API Google Cloud à l'aide de mécanismes d'identité existants.

Toutes ces méthodes sont préférables à l'exportation des identifiants de compte de service, car elles ne nécessitent pas de stocker ni d'accéder en toute sécurité à un secret supplémentaire en dehors de l'API Secret Manager.

Bonnes pratiques de codage

Évitez de transmettre des secrets à votre application via le système de fichiers ou l'environnement. variables. Voici quelques raisons d'utiliser d'autres méthodes de gestion des secrets :

• Lorsqu'un secret est accessible sur le système de fichiers, les failles des applications telles que les attaques de balayage de répertoire peuvent devenir plus graves, car le pirate informatique peut obtenir la possibilité de lire le matériel du secret.

• Lorsqu'un secret est utilisé via des variables d'environnement, des erreurs de configuration telles que l'activation des points de terminaison de débogage ou l'inclusion de dépendances qui consignent les détails de l'environnement peuvent entraîner des fuites de secrets.

• Lors de la synchronisation du contenu du secret vers un autre datastore (tel que Kubernetes les secrets), évaluez les contrôles d'accès fournis par ce data store. Réfléchissez aux éléments suivants :

  • Le datastore étend-il l'accès au secret ?

  • Est-il possible de vérifier l'accès au secret ?

  • Le datastore respecte-t-il les exigences de chiffrement et de régionalisation des données au repos ?

Nous vous recommandons d'utiliser directement l'API Secret Manager à l'aide de l'une des bibliothèques clientes fournies ou en suivant la documentation REST ou GRPC.

Administration

Référencer les secrets par leur numéro de version au lieu d'utiliser le dernier alias. Déployez les mises à jour vers les numéros de version à l'aide de vos processus de publication existants. En règle générale, cela signifie que vous devez configurer votre application avec une version de secret spécifique qui est lue au démarrage. Bien que l'utilisation du dernier alias puisse être pratique, en cas de problème avec la nouvelle version du secret, votre charge de travail peut ne pas être en mesure de l'utiliser. En épinglant un numéro de version, la configuration peut être validée et annulée et un rollback peut être effectué à l'aide de vos processus de version existants.

Désactiver les versions de secrets avant le de les détruire ou de les supprimer. Cela permet d'éviter les pannes en plaçant le secret dans un état qui ressemble à la destruction, mais qui est réversible. En d'autres termes, vous pouvez désactiver et attendre une semaine afin de vous assurer qu'il n'y a pas de dépendances persistantes avant de supprimer définitivement les données.

Ne définissez pas de délai d'expiration sur les secrets de production, sauf si vous êtes certain qu'ils doivent être supprimés de manière irréversible. La fonctionnalité d'expiration est particulièrement adaptée au nettoyage automatisé des environnements temporaires. Envisagez d'utiliser Conditions IAM temporelles comme alternative aux secrets arrivant à expiration.

Effectuez régulièrement une rotation de vos secrets pour :

• Limiter l'impact en cas de fuite d'un secret.

• Assurez-vous que les personnes qui n'ont plus besoin d'accéder à un secret ne peuvent pas continuer pour utiliser un secret déjà consulté.

• Réduire la probabilité d'une panne.

Surveiller les secrets de votre organisation à l'aide de l'inventaire des éléments cloud pour les raisons suivantes:

• Identifier les secrets au sein de votre organisation.

• Identifier la non-conformité aux exigences de l'organisation telles que la rotation, la configuration du chiffrement et l'emplacement.

Activez les journaux d'accès aux données pour obtenir et analyser les informations de requête AccessSecretVersion. Activez cette option au niveau du dossier ou au niveau de l'organisation pour appliquer la journalisation sans avoir à la configurer sur chaque secret ou projet.

En plus des contrôles IAM, vous pouvez limiter l'accès à l'API Secret Manager à l'aide de contrôles basés sur le réseau en configurant un périmètre VPC Service Controls pour votre organisation.

La règle d'administration constraints/iam.allowedPolicyMemberDomains peut être utilisée pour limiter les identités pouvant être ajoutées aux stratégies IAM pour les secrets.

Estimez votre utilisation maximale de secret (en considérant un problème de réveil superflu) de requêtes en raison de déploiements simultanés d'applications ou de l'autoscaling de votre service) et assurez-vous que votre projet dispose de quota suffisant pour gérer un tel événement. Si vous avez besoin d'augmenter votre quota, demandez une augmentation.

Conformité avec la résidence des données

Choisissez des secrets régionaux si vous avez des exigences strictes en matière de résidence et de souveraineté des données. Les secrets régionaux vous permettent de stocker des données sensibles dans un emplacement géographique spécifique, ce qui vous garantit une protection complète des données au repos, en cours d'utilisation et en transit. Vous pouvez ainsi respecter les exigences légales, réglementaires ou organisationnelles concernant la résidence des données.