Résoudre les problèmes liés aux stratégies et aux accès

Ce document offre un aperçu des contrôles d'application des règles d'accès Google Cloud et des outils disponibles pour vous aider à résoudre les problèmes d'accès. Ce document est destiné aux équipes d'assistance qui souhaitent aider les clients de leur organisation à résoudre les problèmes liés à l'accès à leurs ressources Google Cloud.

Contrôles d'application des stratégies d'accès Google Cloud

Cette section décrit les stratégies que vous ou l'administrateur de votre organisation pouvez mettre en œuvre et qui affectent l'accès à vos ressources Google Cloud. Pour mettre en œuvre des stratégies d'accès, vous pouvez utiliser tout ou partie des produits et outils suivants.

Libellés, tags et tags réseau

Google Cloud propose plusieurs méthodes pour ajouter des libellés à des ressources et les regrouper. Vous pouvez utiliser des libellés, des tags et des tags réseau pour faciliter l'application des règles.

Les étiquettes sont des paires clé/valeur qui vous aident à organiser vos ressources Google Cloud. De nombreux services Google Cloud sont compatibles avec les étiquettes. Vous pouvez également utiliser des libellés pour filtrer et regrouper les ressources pour d'autres cas d'utilisation, par exemple pour identifier toutes les ressources qui sont dans un environnement de test par opposition aux ressources qui sont en production. Dans le contexte de l'application de la stratégie, les libellés peuvent identifier où les ressources doivent être situées. Par exemple, les stratégies d'accès que vous appliquez aux ressources désignées comme des ressources de test sont différentes de celles que vous appliquez aux ressources désignées comme des ressources de production.

Les tags sont des paires clé/valeur qui fournissent un mécanisme permettant d'identifier les ressources et d'appliquer la règle. Vous pouvez associer des tags à une organisation, un dossier ou un projet. Un tag s'applique à toutes les ressources au niveau de la hiérarchie auquel il est appliqué. Vous pouvez utiliser des tags pour autoriser ou refuser de manière conditionnelle les règles d'accès selon qu'une ressource dispose ou non d'un tag spécifique. Vous pouvez également utiliser des tags avec des stratégies de pare-feu pour contrôler le trafic dans un réseau cloud privé virtuel (VPC). Il est important de comprendre comment les tags sont hérités et combinés avec les stratégies d'accès et de pare-feu pour résoudre des problèmes.

Les tags réseau sont différents des tags du gestionnaire de ressources précédents. Les tags réseau s'appliquent aux instances de VM et permettent de contrôler le trafic réseau vers et depuis une VM. Sur les réseaux Google Cloud, les tags réseau identifient les VM soumises à des règles de pare-feu et à des routes réseau. Vous pouvez utiliser des tags réseau en tant que valeurs de source et de destination dans des règles de pare-feu. Vous pouvez également utiliser des tags réseau pour identifier les VM auxquelles une route spécifique s'applique. Comprendre les tags réseau peut vous aider à résoudre les problèmes d'accès, car les tags réseau sont utilisés pour définir des règles de réseau et de routage.

Règles de pare-feu VPC

Vous pouvez configurer des règles de pare-feu VPC pour autoriser ou refuser le trafic vers et depuis vos instances de machines virtuelles (VM) ou vos produits basés sur des VM. Chaque réseau privé virtuel (VPC) fonctionne comme un pare-feu distribué. Bien que les règles de pare-feu VPC soient définies au niveau du réseau, les connexions sont autorisées ou interdites pour chaque instance spécifiquement. Vous pouvez appliquer des règles de pare-feu VPC au réseau VPC, aux VM regroupées par tags et aux VM regroupées par compte de service.

VPC Service Controls

VPC Service Controls fournit une solution de sécurité périmétrique qui permet d'atténuer l'exfiltration de données des services Google Cloud tels que Cloud Storage et BigQuery. Vous créez un périmètre de service qui crée une limite de sécurité autour de vos ressources Google Cloud et vous pouvez gérer ce qui est autorisé à entrer et sortir de ce périmètre. VPC Service Controls fournit également des contrôles d'accès contextuels en mettant en œuvre des stratégies basées sur des attributs contextuels tels que l'adresse IP et l'identité.

Resource Manager

Vous utilisez Resource Manager pour configurer une ressource d'organisation. Resource Manager fournit des outils qui vous permettent de mapper votre organisation et la manière dont vous développez vos applications dans une hiérarchie de ressources. En plus de vous aider à regrouper les ressources de manière logique, Resource Manager fournit des points de liaison et un mécanisme d'héritage pour le contrôle d'accès et les règles d'administration.

Identity and Access Management

Identity and Access Management (IAM, ou Gestion de l'authentification et des accès) vous permet de définir qui (identité) a quel accès (rôle) à quelle ressource. Une stratégie IAM est un ensemble d'instructions définissant qui dispose de quel type d'accès, par exemple un accès en lecture ou en écriture. La stratégie IAM est associée à une ressource et applique le contrôle des accès chaque fois qu'un utilisateur tente d'accéder à la ressource.

Les conditions IAM sont une fonctionnalité d'IAM. Lorsque vous implémentez des conditions IAM dans la définition de votre stratégie, vous pouvez choisir de n'autoriser des identités (comptes principaux) à accéder aux ressources que si les conditions configurées sont satisfaites. Par exemple, vous pouvez utiliser les conditions IAM afin de restreindre l'accès aux ressources exclusivement aux employés qui effectuent des requêtes depuis les bureaux de votre entreprise.

Service de règles d'administration

Le service de règles d'administration vous permet d'appliquer des contraintes sur les ressources compatibles dans toute votre hiérarchie d'organisation. Chaque ressource compatible avec la règle d'administration bénéficie d'un ensemble de contraintes qui décrivent comment la ressource peut être limitée. Vous définissez une stratégie qui définit des règles spécifiques limitant la configuration des ressources.

Le service de règles d'administration vous permet, en tant qu'administrateur autorisé, de remplacer les règles d'administration par défaut au niveau du dossier ou du projet, si nécessaire. Les règles d'administration se concentrent sur la manière dont vous configurez les ressources, tandis que les politiques d'IAM se concentrent sur les autorisations que vos identités ont reçues pour ces ressources.

Quotas

Google Cloud impose des quotas sur les ressources afin de limiter la quantité d'une ressource Google Cloud spécifique que votre projet peut utiliser. Le nombre de projets dont vous disposez est également soumis à un quota. Les types d'utilisation de ressources suivants sont limités par des quotas :

• Le quota de débit, comme le nombre de requêtes API par jour. Ce quota est réinitialisé après un délai spécifié, tel qu'une minute ou un jour.
• Le quota d'allocation, comme le nombre de machines virtuelles ou d'équilibreurs de charge utilisés par votre projet. Ce quota n'est pas réinitialisé au fil du temps. Un quota d'allocation doit être explicitement libéré lorsque vous ne souhaitez plus utiliser la ressource, par exemple en supprimant un cluster Google Kubernetes Engine (GKE).

Si vous atteignez une limite de quota d'allocation, vous ne pouvez plus démarrer de nouvelles ressources. Si vous atteignez le quota de débit, vous ne pouvez plus effectuer de requêtes API. Ces deux problèmes peuvent ressembler à un problème d'accès.

Chrome Enterprise Premium

BeyondCorp Enterprise utilise divers produits Google Cloud pour appliquer un contrôle d'accès précis en fonction de l'identité de l'utilisateur et du contexte de la requête. Vous pouvez configurer Chrome Enterprise Premium pour restreindre l'accès à la console Google Cloud et aux API Google Cloud.

La protection des accès Chrome Enterprise Premium fonctionne avec les services Google Cloud suivants :

• Identity-Aware Proxy (IAP) : service qui vérifie l'identité de l'utilisateur et utilise le contexte pour déterminer si un utilisateur doit être autorisé à accéder à une ressource.
• IAM : service de gestion des identités et des autorisations pour Google Cloud.
• Access Context Manager : moteur de règles permettant un contrôle d'accès précis.
• Validation des points de terminaison : extension Google Chrome qui collecte des informations sur les appareils des utilisateurs.

Outil de recommandation IAM

IAM inclut des outils Policy Intelligence qui vous fournissent un ensemble complet de conseils proactifs pour vous aider à être plus efficace et plus sécurisé dans votre utilisation de Google Cloud. Les actions recommandées vous sont fournies via des notifications dans la console, que vous pouvez appliquer directement ou à l'aide d'un événement envoyé à un sujet Pub/Sub.

L'outil de recommandation IAM fait partie de la suite Policy Intelligence. Vous pouvez l'utiliser pour appliquer le principe du moindre privilège. L'outil de recommandation compare les attributions de rôles au niveau du projet avec les autorisations utilisées par chaque compte principal au cours des 90 derniers jours. Si vous attribuez un rôle au niveau du projet à un compte principal et qu'il n'utilise pas toutes les autorisations de ce rôle, l'outil de recommandation peut vous recommander de révoquer le rôle. Si nécessaire, l'outil de recommandation recommande également des rôles moins permissifs en remplacement.

Si vous appliquez automatiquement une recommandation, vous pouvez involontairement refuser à un utilisateur ou à un compte de service l'accès à une ressource. Si vous décidez d'utiliser les automatisations, suivez les bonnes pratiques de l'outil de recommandation IAM pour vous aider à déterminer le degré d'automatisation qui vous convient.

Espaces de noms Kubernetes et RBAC

Kubernetes est exploité en tant que service géré sur Google Cloud, sous la forme de Google Kubernetes Engine (GKE). GKE peut appliquer des règles cohérentes quel que soit l'emplacement d'exécution de votre cluster GKE. Les stratégies qui affectent l'accès aux ressources combinent des contrôles Kubernetes intégrés et des contrôles spécifiques à Google Cloud.

Outre les pare-feu VPC et VPC Service Controls, GKE utilise des espaces de noms, le contrôle des accès basé sur les rôles (RBAC, Role-Based Access Control) et les identités de charge de travail pour gérer les stratégies qui affectent l'accès aux ressources.

Espaces de noms

Les espaces de noms sont des clusters virtuels qui s'appuient sur un même cluster physique et fournissent un champ d'application pour les noms. Les noms des ressources doivent être uniques au sein d'un espace de noms, mais vous pouvez utiliser le même nom dans différents espaces de noms. Les espaces de noms vous permettent d'utiliser des quotas de ressources pour répartir les ressources de cluster entre plusieurs utilisateurs.

RBAC

RBAC inclut les fonctionnalités suivantes :

• Contrôle ultraprécis sur la manière dont les utilisateurs accèdent aux ressources d'API exécutées sur votre cluster.
  • Permet de créer des stratégies détaillées qui définissent les opérations et les ressources auxquelles les utilisateurs et les comptes de service peuvent accéder.
  • Permet de contrôler l'accès pour les comptes Google, les comptes de service Google Cloud et les comptes de service Kubernetes.
• Permet de créer des autorisations RBAC qui s'appliquent à l'ensemble de votre cluster ou à des espaces de noms spécifiques dans votre cluster.
  • Les autorisations à l'échelle du cluster sont utiles pour limiter l'accès à des ressources d'API spécifiques pour certains utilisateurs. Ces ressources d'API incluent des règles de sécurité et des secrets.
  • Les autorisations propres à un espace de noms sont utiles si, par exemple, vous disposez de plusieurs groupes d'utilisateurs opérant dans leurs propres espaces de noms respectifs. Le contrôle RBAC peut vous aider à vous garantir que les utilisateurs n'ont accès qu'aux ressources de cluster dans leur propre espace de noms.
• Un rôle qui ne peut être utilisé que pour accorder l'accès aux ressources dans un espace de noms unique.
• Un rôle contenant des règles qui représentent un ensemble d'autorisations. Les autorisations sont purement additives et il n'y a pas de règles de refus.

IAM et Kubernetes RBAC sont intégrés de sorte que les utilisateurs sont autorisés à effectuer des actions s'ils disposent des autorisations suffisantes selon chaque outil.

La figure 1 montre comment implémenter des stratégies à l'aide d'IAM en utilisant le contrôle RBAC et des espaces de noms.

Figure 1. IAM et Kubernetes RBAC fonctionnent conjointement pour contrôler l'accès à un cluster GKE.

La figure 1 illustre les implémentations de stratégies suivantes :

1. Au niveau du projet, IAM définit les rôles permettant aux administrateurs de cluster de gérer les clusters et permettant aux développeurs de conteneurs d'accéder aux API des clusters.
2. Au niveau du cluster, le contrôle RBAC définit des autorisations sur des clusters individuels.
3. Au niveau de l'espace de noms, le contrôle RBAC définit les autorisations sur les espaces de noms.

Workload Identity

Outre le contrôle RBAC et IAM, vous devez également comprendre l'impact des identités de charge de travail. Workload Identity vous permet de configurer un compte de service Kubernetes qui agira en tant que compte de service Google. Toute application s'exécutant en tant que compte de service Kubernetes s'authentifie automatiquement en tant que compte de service Google lorsqu'elle accède aux API Google Cloud. Cette authentification vous permet d'attribuer une identité et des autorisations précises pour les applications de votre cluster.

Workload Identity s'appuie sur les autorisations IAM pour contrôler les API Google Cloud auxquelles votre application GKE peut accéder. Par exemple, si les autorisations IAM changent, une application GKE peut perdre ses droits d'écriture Cloud Storage.

Outils de dépannage

Cette section décrit les outils disponibles pour vous aider à résoudre les problèmes liés à vos stratégies. Vous pouvez utiliser différents produits et fonctionnalités pour appliquer une combinaison de règles. Par exemple, vous pouvez utiliser des pare-feu et des sous-réseaux pour gérer la communication entre les ressources de votre environnement et au sein des zones de sécurité que vous avez définies. Vous pouvez également utiliser IAM pour restreindre l'accès à ce qui se trouve dans la zone de sécurité ou dans toute autre zone de VPC Service Controls que vous avez définie.

Journaux

En cas de problème, les journaux sont la principale source d'indices pour le dépannage. Les journaux Google Cloud qui fournissent des informations sur les problèmes d'accès sont les journaux Cloud Audit Logs, les journaux des règles de pare-feu et les journaux de flux VPC.

Cloud Audit Logs

Les journaux d'audit Cloud comprennent les flux de journaux d'audit suivants pour chaque projet, dossier et organisation : activité d'administration, accès aux données et événement système. Les services Google Cloud génèrent des entrées dans ces journaux d'audit pour vous aider à identifier l'utilisateur qui a effectué une action dans vos projets Google Cloud, à quel endroit et à quel moment.

• Les journaux de type Activités d'administration contiennent des entrées relatives aux appels d'API et aux autres opérations d'administration qui modifient la configuration ou les métadonnées des ressources. Les journaux d'activité d'administration sont toujours activés. Pour en savoir plus sur la tarification et les quotas des journaux pour les activités d'administration, consultez la présentation des journaux Cloud Audit.
• Les journaux d'accès aux données enregistrent les appels d'API qui créent, modifient ou lisent des données fournies par l'utilisateur. Les journaux d'audit d'accès aux données sont désactivés par défaut, à l'exception de BigQuery. Les journaux d'accès aux données peuvent être volumineux et entraîner des coûts. Pour en savoir plus sur les limites d'utilisation des journaux d'accès aux données, consultez la page Quotas et limites. Pour en savoir plus sur les coûts éventuels, consultez la page Tarifs.
• Les journaux des événements système contiennent des entrées associées aux événements système de Compute Engine. Par exemple, chaque migration à chaud est enregistrée en tant qu'événement système. Pour plus d'informations sur la tarification et les quotas des journaux des événements système, consultez la présentation des journaux d'audit Cloud.

Dans Cloud Logging, le champ protoPayload contient un objet AuditLog qui stocke les données de journal d'audit. Pour obtenir un exemple d'entrée de journal d'audit, consultez l'exemple d'entrée de journal d'audit.

Pour afficher les journaux d'audit relatifs aux activités d'administration, vous devez disposer du rôle de lecteur de journaux (roles/logging.viewer) ou du rôle Lecteur de base (roles/viewer). Dans la mesure du possible, sélectionnez le rôle avec le moins de privilèges requis pour effectuer la tâche.

Les entrées individuelles des journaux d'audit sont stockées pendant une durée spécifiée. Pour une conservation plus longue, vous pouvez exporter les entrées de journal vers Cloud Storage, BigQuery ou Pub/Sub. Pour exporter des entrées de journal à partir de tous les projets, dossiers et comptes de facturation de votre organisation, vous pouvez utiliser les exportations agrégées. Les exportations agrégées constituent un moyen centralisé de passer en revue les journaux pour toute l'organisation.

Pour utiliser vos journaux d'audit afin de vous aider à résoudre les problèmes, procédez comme suit :

• Vérifiez que vous disposez des rôles IAM requis pour afficher les journaux. Si vous exportez les journaux, vous devez également disposer d'autorisations pour afficher les journaux exportés dans le récepteur.
• Suivez les bonnes pratiques d'utilisation des journaux d'audit pour répondre à votre stratégie d'audit.
• Sélectionnez une stratégie d'équipe pour afficher les journaux. Il existe plusieurs façons d'afficher les journaux dans Cloud Audit Logging et chaque membre de votre équipe de dépannage doit utiliser la même méthode.
• Accédez à la page Activité de la console Google Cloud pour obtenir une vue d'ensemble de vos journaux d'activité.
• Affichez les journaux exportés à partir du récepteur vers lequel ils ont été exportés. Les journaux hors de la période de conservation ne sont visibles que dans le récepteur. Vous pouvez également utiliser des journaux exportés pour effectuer une analyse comparative, par exemple avec un moment où tout a fonctionné comme prévu.

Journalisation des règles de pare-feu

La journalisation des règles de pare-feu vous permet de réaliser des audits, des vérifications et des analyses sur les effets de ces règles. Par exemple, vous pouvez déterminer si une règle de pare-feu conçue pour refuser le trafic fonctionne comme prévu.

Vous activez la journalisation des règles de pare-feu individuellement pour chaque règle de pare-feu dont vous souhaitez journaliser les connexions. Cette option est disponible pour toute règle de pare-feu, indépendamment de l'action de la règle (autorisation ou refus) et de la direction du trafic visé (entrée ou sortie). La journalisation des règles de pare-feu peut générer une grande quantité de données. La journalisation des règles de pare-feu est un service facturé. Vous devez donc planifier soigneusement les connexions que vous souhaitez consigner.

Déterminez l'emplacement où vous souhaitez stocker vos journaux de pare-feu. Si vous souhaitez afficher une vue de vos journaux à l'échelle de l'organisation, exportez les journaux de pare-feu vers le même récepteur que vos journaux d'audit. Utilisez des filtres pour rechercher des événements de pare-feu spécifiques.

Firewall Insights

La page Firewall Insights fournit des rapports sur l'utilisation du pare-feu et sur l'impact des différentes règles de pare-feu sur votre réseau VPC. Cet outil vous permet de vérifier que les règles de pare-feu autorisent ou bloquent les connexions comme prévu.

Vous pouvez également utiliser Firewall Insights pour détecter les règles de pare-feu qui sont bloquées par d'autres règles. Une règle bloquée est une règle de pare-feu dont tous les attributs pertinents, comme par exemple la plage d'adresses IP et les ports, chevauchent les attributs d'une ou plusieurs autres règles de pare-feu de priorité supérieure ou égale. Les règles bloquées sont calculées dans les 24 heures suivant l'activation de la journalisation des règles de pare-feu.

Lorsque vous activez la journalisation des règles de pare-feu, Firewall Insights analyse les journaux pour afficher les insights associés à toute règle de refus utilisée au cours de la période d'observation spécifiée (par défaut, les dernières 24 heures). Les insights sur les règles de refus vous fournissent des signaux de suppression de paquets de pare-feu. Vous pouvez utiliser les signaux de suppression de paquets pour vérifier que les paquets supprimés sont attendus en raison de protections de sécurité ou inattendus en raison, par exemple, de configurations incorrectes du réseau.

Journaux de flux VPC

Les journaux de flux VPC enregistrent un échantillon des flux réseau envoyés et reçus par les instances de VM. Les journaux de flux VPC couvrent le trafic qui affecte une VM. Tout le trafic sortant est journalisé, même si une règle de pare-feu bloque le trafic sortant. Le trafic entrant est journalisé si une règle de pare-feu autorise le trafic entrant. Le trafic entrant n'est pas journalisé si une règle de pare-feu bloque le trafic entrant.

Les journaux de flux sont collectés pour chaque connexion à une VM à des intervalles spécifiques. Tous les paquets échantillonnés pour un intervalle et une connexion donnés sont agrégés pendant une certaine période (intervalle d'agrégation) en une seule entrée de journal de flux. L'entrée de journal de flux est ensuite envoyée à Cloud Logging.

Les journaux de flux VPC sont activés ou désactivés pour chaque sous-réseau VPC. Le fait d'activer les journaux de flux VPC génère beaucoup de données. Nous vous recommandons de gérer soigneusement les sous-réseaux sur lesquels vous activez les journaux de flux VPC. Par exemple, nous vous recommandons de ne pas activer les journaux de flux pendant une période prolongée sur les sous-réseaux utilisés par les projets de développement. Vous pouvez interroger les journaux de flux VPC directement dans Cloud Logging ou en utilisant le récepteur exporté. Lorsque vous dépannez des problèmes de trafic constatés, vous pouvez utiliser les journaux de flux VPC pour voir si le trafic quitte ou entre bien dans la VM via le port prévu.

Alertes

Les alertes vous permettent de recevoir des notifications en cas d'événements de non-respect des règles susceptibles d'affecter l'accès à vos ressources Google Cloud.

Notifications en temps réel

Cloud Asset Inventory conserve un historique de cinq semaines des métadonnées des éléments Google Cloud. Un élément est une ressource Google Cloud compatible. Les ressources compatibles incluent IAM, Compute Engine avec des fonctionnalités réseau telles que les règles de pare-feu, les espaces de noms GKE ou les liaisons de rôle et de rôle de cluster. Toutes les ressources précédentes affectent l'accès aux ressources Google Cloud.

Pour surveiller les écarts par rapport à vos configurations de ressources telles que les règles de pare-feu et les règles de transfert, vous pouvez vous abonner aux notifications en temps réel. Si vos configurations de ressources changent, les notifications en temps réel vous en avertissent immédiatement via Pub/Sub. Les notifications peuvent vous avertir rapidement en cas de problème, avant que l'équipe d'assistance n'ait à vous appeler.

Journaux d'audit cloud et Cloud Functions

Pour compléter l'utilisation des notifications en temps réel, vous pouvez surveiller Cloud Logging et envoyer des alertes en cas d'appel à des actions sensibles. Par exemple, vous pouvez créer un récepteur Cloud Logging qui filtre les appels à SetIamPolicy au niveau de l'organisation. Le récepteur envoie des journaux à un sujet Pub/Sub que vous pouvez utiliser pour déclencher une fonction Cloud.

Tests de connectivité

Pour déterminer si un problème d'accès est lié au réseau ou aux autorisations, utilisez l'outil Tests de connectivité de Network Intelligence Center. Tests de connectivité est un outil d'analyse et de diagnostic de configuration statique qui vous permet de vérifier la connectivité entre un point de terminaison source et de point de terminaison de destination. Il vous aident à identifier la cause première des problèmes d'accès liés au réseau qui sont associés à la configuration de votre réseau Google Cloud.

Les tests de connectivité incluent votre réseau VPC, l'appairage de réseaux VPC et vos tunnels VPN vers votre réseau sur site. Par exemple, les tests de connectivité peuvent détecter qu'une règle de pare-feu bloque la connectivité. Pour en savoir plus, consultez la section Cas d'utilisation courants.

Policy Troubleshooter

De nombreuses tâches dans Google Cloud nécessitent un rôle IAM et des autorisations associées. Nous vous recommandons de vérifier les autorisations contenues dans un rôle et de vérifier chacune des autorisations requises pour effectuer une tâche. Par exemple, pour créer une instance à l'aide d'images Compute Engine, un utilisateur a besoin du rôle compute.imageUser qui inclut neuf autorisations. Par conséquent, l'utilisateur doit bénéficier d'une combinaison de rôles et d'autorisations incluant ces neuf autorisations.

Policy Troubleshooter est un outil de la console Google Cloud qui vous aide à déterminer pourquoi un utilisateur ou un compte de service n'est pas autorisé à accéder à une ressource. Pour résoudre les problèmes d'accès, vous utilisez la partie IAM de Policy Troubleshooter.

Par exemple, vous pouvez vérifier pourquoi un utilisateur donné peut créer des objets dans des buckets d'un projet, alors qu'un autre utilisateur ne peut pas le faire. Policy Troubleshooter peut vous aider à voir quelles sont les autorisations dont dispose le premier utilisateur et celles dont ne dispose pas le second.

Policy Troubleshooter nécessite les entrées suivantes :

• Compte principal (utilisateur individuel, compte de service ou groupes)
• Autorisation (notez qu'il s'agit des autorisations sous-jacentes et non des rôles IAM)
• Ressource

Outil de recommandation IAM

Bien que l'outil de recommandation IAM soit un contrôle d'application des stratégies, comme décrit dans la section précédente dédiée à l'outil de recommandation, vous pouvez également l'utiliser comme outil de dépannage. L'outil de recommandation exécute une tâche quotidienne qui analyse les données du journal d'accès IAM et les autorisations accordées au cours des 60 derniers jours. L'outil de recommandation vous permet de vérifier si une recommandation approuvée et appliquée récemment peut avoir affecté l'accès d'un utilisateur à une ressource précédemment autorisée. Dans ce cas, vous pouvez redonner les autorisations qui ont été supprimées.

Transmission au service client

Lorsque vous résolvez des problèmes d'accès, il est important de disposer d'un processus d'assistance interne efficace et d'un processus bien défini pour transmettre le problème au service Cloud Customer Care. Cette section donne un exemple de configuration de l'assistance et explique comment vous pouvez communiquer avec le service client pour l'aider à résoudre rapidement vos problèmes.

Si vous ne parvenez pas à résoudre un problème à l'aide des outils décrits dans ce document, un processus d'assistance clairement défini aidera le service client à résoudre les problèmes rencontrés. Nous vous recommandons d'adopter une approche systématique pour le dépannage, comme décrit dans le chapitre Dépannage efficace du manuel Ingénierie en fiabilité des sites (SRE) de Google.

Nous vous recommandons de procéder comme suit avec votre processus d'assistance interne :

• Détaillez les procédures à suivre en cas de problème.
• Adoptez une voie de remontée clairement définie.
• Mettez en place une procédure de garde.
• Créez un plan de réponse aux incidents.
• Configurez un système de suivi des bugs ou un système d'assistance.
• Assurez-vous que votre personnel d'assistance a été autorisé à communiquer avec le service client et qu'il s'agit de contacts nommés.
• Communiquez les processus d'assistance au personnel interne, y compris la procédure à suivre pour contacter les contacts nommés de Google Cloud.
• Analysez régulièrement les problèmes rencontrés par les équipes d'assistance, puis procédez à des itérations et à des améliorations sur la base des enseignements tirés.
• Utilisez un formulaire rétrospectif standardisé.

Si vous devez faire remonter un problème au service client, ayez à votre disposition les informations suivantes, que vous pourrez partager avec le service client pour résoudre les problèmes d'accès :

• L'identité du demandeur d'accès (courrier électronique de l'utilisateur ou du compte de service).
  • Indiquez si ce problème concerne toutes les identités ou certaines seulement.
  • Si seules certaines identités sont affectées, fournissez un exemple d'identité qui fonctionne et un exemple d'identité qui échoue.
• Indiquez si l'identité a été recréée récemment.
• Indiquez la ressource à laquelle l'utilisateur tente d'accéder (incluez l'ID du projet).
• Précisez la requête ou la méthode appelée.
  • Fournissez une copie de la requête et de la réponse.
• Indiquez les autorisations accordées à l'identité pour cet accès.
  • Fournissez une copie de la stratégie IAM.
• Spécifiez la source (l'emplacement) à partir de laquelle l'identité tente d'accéder aux ressources. Par exemple, indiquez si la personne tente d'accéder à partir d'une ressource Google Cloud (telle qu'une instance Compute Engine), de la console Google Cloud, de Google Cloud CLI, de Cloud Shell, ou d'une source externe comme un environnement sur site ou l'Internet public.
  • Si la source provient d'un autre projet, indiquez l'ID du projet source.
• Indiquez l'heure (horodatage) à laquelle l'erreur s'est produite pour la première fois et si le problème persiste.
• Indiquez l'heure de la dernière fois où l'identité a réussi à accéder à la ressource (en fournissant des horodatages).
• Précisez toute modification apportée avant le début du problème (en fournissant des horodatages).
• Apportez toute erreur enregistrée dans Cloud Logging. Avant de partager ces informations avec le service client, assurez-vous de masquer les données sensibles telles que les jetons d'accès, les identifiants et les numéros de carte de crédit.

Étape suivante

Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.