Utiliser IAM en toute sécurité

Cette page recommande de bonnes pratiques de sécurité que vous devez garder à l'esprit lorsque vous utilisez Cloud IAM.

Cette page est conçue pour les utilisateurs maîtrisant Cloud IAM. Si vous débutez avec Cloud IAM, ces instructions ne vous apprendront pas à l'utiliser. Les nouveaux utilisateurs doivent commencer par le guide de démarrage rapide Cloud IAM.

Moindre privilège

❑   Les rôles de base incluent des milliers d'autorisations pour tous les services Google Cloud. Dans les environnements de production, n'accordez pas de rôles de base, sauf s'il n'existe pas d'autre solution. Accordez plutôt les rôles prédéfinis ou les rôles personnalisés les plus limités qui répondent à vos besoins. Si vous devez remplacer un rôle de base, vous pouvez utiliser les recommandations de rôles pour déterminer les rôles à attribuer à la place. Vous pouvez également vous servir de Policy Simulator pour vous assurer que la modification du rôle n'affecte pas l'accès du compte principal. Il peut s'avérer judicieux d'accorder des rôles de base dans les cas suivants : Lorsque le service Google Cloud ne fournit pas de rôle prédéfini. Consultez la table des rôles prédéfinis pour obtenir la liste de tous les rôles prédéfinis disponibles. Lorsque vous souhaitez accorder des autorisations plus larges pour un projet. Cela se produit souvent lorsque vous accordez des autorisations dans des environnements de développement ou de test. Lorsque vous travaillez dans une petite équipe dont les membres n'ont pas besoin d'autorisations précises.

❑   Traitez chaque composant de votre application comme une limite de confiance distincte. Si plusieurs services nécessitent des autorisations différentes, créez un compte de service distinct pour chacun de ces services, puis accordez uniquement les autorisations requises à chaque compte de service.

❑   N'oubliez pas que les stratégies d'autorisation des ressources enfants héritent des stratégies d'autorisation de leurs ressources parentes. Par exemple, si la stratégie d'autorisation d'un projet autorise un utilisateur à administrer des instances de machine virtuelle (VM) Compute Engine, il peut administrer n'importe quelle VM Compute Engine de ce projet, quelle que soit la stratégie d'autorisation définie sur chaque VM.

❑   Accordez des rôles au plus petit champ d'application requis. Par exemple, si un utilisateur n'a besoin que d'un accès lui permettant de publier un sujet Pub/Sub, attribuez-lui le rôle Éditeur pour ce sujet.

❑   Spécifiez les comptes principaux pouvant agir en tant que comptes de service. Les utilisateurs auxquels le rôle Utilisateur du compte de service est attribué pour un compte de service peuvent accéder à toutes les ressources auxquelles le compte de service a accès. Par conséquent, soyez prudent lorsque vous attribuez le rôle Utilisateur du compte de service à un utilisateur.

❑   Spécifiez les utilisateurs autorisés à créer et gérer des comptes de service dans votre projet.

❑   L'attribution des rôles prédéfinis Administrateur IAM de projets et Administrateur IAM de dossiers permet de modifier les stratégies d'autorisation sans pour autant autoriser la lecture, l'écriture et l'accès administrateur à toutes les ressources. L'attribution du rôle Propriétaire (roles/owner) à un compte principal lui permet d'accéder à presque toutes les ressources et de les modifier, y compris les stratégies d'autorisation. Ce niveau élevé de privilèges est potentiellement risqué. N'attribuez le rôle de propriétaire que lorsqu'un accès (presque) universel est requis.

❑   Utilisez des liaisons de rôles conditionnelles pour permettre l'expiration automatique des accès et envisagez d'accorder un accès avec privilèges élevés temporaire.

Comptes de service

❑   Suivez les bonnes pratiques d'utilisation des comptes de service. Assurez-vous que les comptes de service disposent de privilèges limités et protégez-vous contre les menaces de sécurité potentielles.

❑   Ne supprimez pas les comptes de service utilisés par les instances en cours d'exécution. Cela pourrait entraîner l'échec de tout ou partie de votre application si vous n'avez pas déjà basculé vers un autre compte de service.

❑   Utilisez le nom à afficher d'un compte de service pour savoir à quoi sert le compte de service et quelles sont les autorisations dont il a besoin.

Clés de compte de service

❑   Évitez d'utiliser des clés de compte de service si une autre option est disponible. Les clés de compte de service constituent un risque pour la sécurité si elles ne sont pas gérées correctement. Dans la mesure du possible, vous devez choisir une alternative plus sécurisée aux clés de compte de service. Si vous devez vous authentifier avec une clé de compte de service, vous êtes responsable de la sécurité de la clé privée et des autres opérations décrites sur la page Bonnes pratiques pour gérer les clés de compte de service. Si vous ne parvenez pas à créer une clé de compte de service, la création de clé de compte de service peut être désactivée pour votre organisation. Pour en savoir plus, consultez la page Gérer les ressources d'organisation sécurisées par défaut.

❑   Gérez la rotation de vos clés de compte de service à l'aide de l'API IAM service account. Pour effectuer une rotation, vous devez créer une nouvelle clé, associer les applications à cette nouvelle clé, désactiver l'ancienne clé, puis supprimer l'ancienne clé lorsque vous êtes sûr qu'elle n'est plus nécessaire.

❑   Implémentez des processus pour gérer les clés de compte de service gérées par l'utilisateur.

❑   Veillez à ne pas confondre les clés de chiffrement avec les clés de compte de service. Les clés de chiffrement sont généralement utilisées pour chiffrer les données, et les clés de compte de service pour un accès sécurisé aux API Google Cloud.

❑   N'enregistrez pas les clés du compte de service dans le code source et ne les laissez pas dans le répertoire Téléchargements.

Audits

❑   Utilisez les journaux d'audit Cloud pour auditer régulièrement les modifications apportées à votre stratégie d'autorisation.

❑   Exportez vos journaux d'audit vers Cloud Storage pour stocker vos journaux pendant de longues périodes.

❑   Réalisez des audits afin de déterminer qui est autorisé à modifier les stratégies d'autorisation sur vos projets.

❑   Limitez l'accès aux journaux à l'aide des rôles Logging.

❑   Appliquez à la ressource Google Cloud les mêmes stratégies d'accès que celles que vous utilisez pour acheminer les journaux, comme avec l'explorateur de journaux.

❑   Utilisez les journaux d'audit Cloud pour contrôler régulièrement l'accès aux clés de compte de service.

Gestion des stratégies

❑   Si un compte principal a besoin d'accéder à tous les projets de votre organisation, attribuez-lui des rôles au niveau de l'organisation.

❑   Attribuez des rôles à des groupes plutôt qu'à des utilisateurs individuels lorsque cela est possible. Il est plus facile de mettre à jour les membres d'un groupe que de mettre à jour les principaux dans vos stratégies d'autorisation.