Simulateur de règles pour les règles de refus

Policy Simulator pour les stratégies de refus vous permet de voir comment une modification d'une stratégie de refus IAM peut affecter l'accès d'un compte principal avant de procéder à la modification. Vous pouvez utiliser Policy Simulator pour vous assurer que les modifications que vous apportez n'empêchent pas un compte principal d'accéder aux ressources dont il a besoin.

Cette fonctionnalité n'évalue que les stratégies de refus. Pour savoir comment simuler d'autres types de stratégies, consultez les ressources suivantes :

Fonctionnement de Policy Simulator pour les stratégies de refus

Policy Simulator pour les stratégies de refus vous permet de déterminer si une modification d'une stratégie de refus bloquera l'accès utilisé par vos comptes principaux.

Lorsque vous exécutez une simulation pour une stratégie de refus, Policy Simulator effectue les opérations suivantes :

  1. Récupère les journaux d'accès de l'organisation générés pendant la période de relecture. La période de relecture est de 90 jours.

    Si l'organisation n'existe pas depuis plus de 90 jours, Policy Simulator récupère tous les journaux d'accès depuis sa création.

  2. Détermine les journaux d'accès pertinents pour la simulation. Les journaux d'accès pertinents sont tous les journaux d'accès qui représentent la tentative la plus récente d'un compte principal d'utiliser une autorisation pour accéder à une ressource.

  3. Pour chaque journal d'accès pertinent, détermine si les stratégies de refus actuelles, ainsi que les modifications proposées, autoriseraient la tentative d'accès. Ce processus est appelé relecture des tentatives d'accès.

  4. Pour chaque journal d'accès, compare l'état d'accès de la relecture avec l'état d'accès des journaux d'accès. Ensuite, Policy Simulator signale toutes les tentatives d'accès historiques qui n'ont pas été bloquées dans le journal d'accès, mais qui l'ont été dans la relecture. Ces différences, appelées modifications d'accès, indiquent les tentatives d'accès qui auraient été bloquées si la stratégie de refus simulée avait été en place au moment de la tentative.

Période de relecture

La période de relecture correspond à la période pendant laquelle Policy Simulator obtient les journaux d'accès lors de l'exécution d'une simulation. Les journaux d'accès qui se produisent avant le premier jour de la période de relecture ou après le dernier jour de la période de relecture ne sont pas inclus dans la simulation. La période de relecture est de 90 jours. Si la ressource d'organisation existe depuis moins de temps, Policy Simulator récupère toutes les tentatives d'accès depuis la création de l'organisation. La fenêtre de relecture est également cohérente à terme. Cela signifie que, lorsque vous exécutez une simulation, certaines données peuvent être plus récentes que d'autres. Toutefois, à terme, toutes les données auront la même fraîcheur. Avec la cohérence à terme, la période de relecture se termine généralement en quelques jours, mais peut se terminer jusqu'à 15 jours plus tôt. Les résultats de la simulation affichent la fenêtre de relecture exacte. Les journaux d'accès postérieurs à cette période ne sont pas inclus.

Résultats de Policy Simulator

Policy Simulator signale l'impact d'une modification de stratégie de refus proposée sous la forme d'une liste de modifications d'accès. Pour les stratégies de refus, le seul type de modification d'accès que Policy Simulator signale est la modification d'accès Accès révoqué.

Policy Simulator signale que l'accès est révoqué si les conditions suivantes sont remplies :

  • La tentative la plus récente du compte principal d'accéder à la ressource a réussi.
  • Les modifications proposées ou une autre stratégie de refus bloquent l'accès du compte principal à la ressource.

Pour chaque modification d'accès, Policy Simulator fournit également les informations suivantes :

  • Le compte principal, la ressource et l'autorisation impliqués dans la tentative d'accès.
  • Le nombre de jours pendant la période de relecture où le compte principal a tenté d'utiliser l'autorisation pour accéder à la ressource. Ce total n'inclut que les tentatives d'accès qui ont le même résultat que la tentative d'accès la plus récente.
  • La date de la tentative d'accès la plus récente.

Erreurs

Les erreurs suivantes peuvent entraîner l'échec d'une simulation :

  • Nombre maximal de simulations simultanées dépassé : l'utilisateur a déjà 50 simulations en cours, ce qui correspond au nombre maximal de simulations en cours qu'un utilisateur peut avoir. Pour résoudre ce problème, attendez qu'une des simulations en cours soit terminée, puis essayez d'exécuter à nouveau la simulation.
  • Délai expiré : l'exécution de la simulation a pris trop de temps et a expiré. Toute simulation qui dure plus de 24 heures expire automatiquement. Pour résoudre ce problème, essayez d'exécuter à nouveau la simulation ou de réduire sa taille.
  • Construction de simulation non valide : la stratégie de refus proposée n'est pas valide ou contient des règles de refus non compatibles. Une stratégie non valide est, par exemple, une stratégie qui contient une expression de condition non valide. Une règle de refus non compatible est, par exemple, une règle qui utilise des identifiants de compte principal de fédération d'identités des employés. Pour résoudre ce problème, corrigez la stratégie, puis réessayez.
  • Autorisation refusée : vous n'êtes pas autorisé à exécuter une simulation. Pour résoudre ce problème, assurez-vous de disposer des rôles requis, puis réessayez.

Types de comptes principaux compatibles

Policy Simulator pour les stratégies de refus n'examine que les journaux d'accès pour les types de comptes principaux suivants :

Lors de la simulation de stratégies de refus, Policy Simulator n'examine pas les journaux d'accès pour les autres types de comptes principaux, y compris ceux basés sur des identités fédérées dans un pool d'identités de charge de travail. Par conséquent, Policy Simulator n'indique pas si les modifications proposées de vos stratégies ou liaisons affectent l'accès de ces comptes principaux.

Simuler des limites d'accès aux identifiants

Vous pouvez utiliser des limites d'accès aux identifiants pour réduire le champ d'application ou restreindre les autorisations IAM qu'un identifiant éphémère peut utiliser pour accéder aux ressources Cloud Storage. Pour réduire le champ d'application des autorisations, un utilisateur ou un compte de service (le courtier de jetons) définit les autorisations disponibles sur un ensemble de ressources dans un jeton d'accès à champ d'application réduit, puis fournit le jeton d'accès à un autre utilisateur ou compte de service (le consommateur de jetons).

Le courtier de jetons doit disposer d'un rôle qui inclut les autorisations accordées au consommateur de jetons avec un jeton d'accès à champ d'application réduit. Le refus de ce rôle sur le courtier de jetons supprime également l'accès du consommateur de jetons. Toutefois, Policy Simulator n'évalue pas l'impact des modifications apportées aux autorisations du courtier de jetons sur l'accès du consommateur de jetons.

Prenons l'exemple d'un utilisateur qui s'est vu attribuer le rôle Lecteur de bucket hérité de l'espace de stockage (roles/storage.legacyBucketReader) sur une ressource à l'aide d'un jeton d'accès à champ d'application réduit créé avec une limite d'accès aux identifiants.

  • Si vous simulez le refus du rôle Lecteur de bucket hérité de l'espace de stockage sur cet utilisateur, Policy Simulator ne signale pas de perte d'accès.

  • Si vous simulez le refus du rôle Lecteur de bucket hérité de l'espace de stockage sur le courtier de jetons, Policy Simulator ne signale pas de perte d'accès pour l'utilisateur. De même, si l'accès du courtier de jetons n'est pas utilisé dans les 90 jours, son accès n'est pas inclus dans la simulation.

Pour en savoir plus, consultez la page Limites d'accès aux identifiants pour Cloud Storage.

Étape suivante