Résoudre les problèmes à l'aide de Policy Troubleshooter pour BeyondCorp Enterprise

BeyondCorp Enterprise fournit un outil de dépannage que les administrateurs peuvent utiliser pour trier et analyser les accès d'utilisateurs finaux.

BeyondCorp Enterprise permet aux entreprises de créer des règles avancées qui fournissent un accès contextuel aux applications. Toutefois, lorsque vous appliquez plusieurs règles d'accès aux ressources, allant des restrictions d'emplacement aux règles relatives aux appareils, il peut être difficile de comprendre comment les stratégies sont évaluées et pourquoi un utilisateur final dispose ou non d'un accès à la ressource cible.

Policy Troubleshooter vous permet d'identifier les raisons de l'échec ou de la réussite de l'accès et, si nécessaire, de modifier la stratégie et de demander à l'utilisateur final de modifier son contexte afin d'autoriser l'accès ou de supprimer la liaison visant à refuser tout accès inattendu.

Policy Troubleshooter est un outil précieux pour les organisations qui doivent appliquer plusieurs règles à plusieurs ressources pour différents groupes d'utilisateurs.

Avant de commencer

Policy Troubleshooter est une fonctionnalité Premium qui nécessite une licence BeyondCorp Enterprise.

Pour optimiser l'efficacité de Policy Troubleshooter, assurez-vous de disposer du rôle d'examinateur de sécurité (roles/iam.securityReviewer). Il vous autorise à lire toutes les stratégies Cloud IAM applicables.

Pour résoudre les problèmes d'accès à un appareil, vous devez être autorisé à en afficher les détails. Si les règles associées à la ressource cible contiennent des règles relatives aux appareils, telles qu'un niveau d'accès nécessitant le chiffrement de l'appareil, vous risquez de ne pas obtenir de résultats précis, à moins que l'autorisation de récupérer les détails de l'appareil du compte principal cible soit validée. Les rôles de super-administrateur Google Workspace, d'administrateur des services et d'administrateur des appareils mobiles ont généralement accès aux informations concernant l'appareil. Pour permettre à un utilisateur autre que le super-administrateur, l'administrateur des services ou l'administrateur des appareils mobiles de résoudre les problèmes d'accès, procédez comme suit :

Créez un rôle d'administrateur Google Workspace personnalisé contenant le droit Services > Gestion des appareils mobiles > Gérer les appareils et les paramètres (situé sous Droits pour la console d'administration).
Attribuez le rôle aux utilisateurs à l'aide de la console d'administration.

Pour résoudre les problèmes d'accès à une ressource accordée par un groupe Google Cloud, vous devez être autorisé à afficher ses membres. Si les règles contiennent un groupe, vous devez être autorisé à afficher les détails de ce groupe avant de l'ouvrir. Les super-administrateurs Google Workspace et les administrateurs de groupe ont généralement accès à l'affichage des membres du groupe. Pour permettre à un utilisateur autre que le super-administrateur ou l'administrateur de groupe de résoudre les problèmes d'accès, procédez comme suit :

Créez un rôle d'administrateur Google Workspace personnalisé contenant le droit Groupes > Lecture (situé sous Droits pour l'API Admin).
Attribuez le rôle à l'utilisateur. Cela lui permet d'afficher les membres de tous les groupes de votre domaine et de résoudre plus efficacement les problèmes d'accès.

L'autorisation de rôle personnalisé est facultative. Si vous n'êtes pas autorisé à afficher un rôle personnalisé, vous ne pourrez peut-être pas déterminer si un compte principal y a accès à partir de liaisons avec des rôles personnalisés.

Présentation du workflow de dépannage

Résoudre les problèmes d'accès refusé

Pour résoudre les problèmes d'accès refusé, vous pouvez activer la fonctionnalité pour une ressource IAP dans les paramètres IAP. Pour ce faire, cliquez sur les trois points situés à droite de l'application protégée par IAP, puis sur Paramètres, puis sélectionnez Générer une URL de dépannage. Pour optimiser l'efficacité de Policy Troubleshooter, assurez-vous de disposer du rôle Administrateur des paramètres IAP (roles/iap.settingsAdmin). Cela vous permet de récupérer et de mettre à jour les paramètres IAP de toutes les ressources IAP.

Les URL de dépannage ne sont présentées que sur les pages d'erreur 403 par défaut, lorsqu'elles sont activées.

Policy Troubleshooter fournit une interface utilisateur dans laquelle vous pouvez afficher les résultats détaillés de l'évaluation de toutes les règles en vigueur pour la ressource IAP cible. Lorsque l'accès d'un utilisateur échoue, la page 403 affiche une URL de dépannage. Lorsqu'il est consulté, Policy Troubleshooter affiche les détails des liaisons ayant échoué et l'analyse des niveaux d'accès défaillants, s'ils existent dans les liaisons. Vous pouvez également utiliser l'outil de dépannage pour afficher une vue détaillée de l'accès d'un utilisateur à une ressource.

Accès utilisateur refusé

Lorsqu'un utilisateur ne dispose pas des autorisations ou ne remplit pas la condition requises pour accéder à une ressource IAP, il est redirigé vers une page d'erreur "403 Access Denied" (accès refusé). La page 403 inclut une URL de dépannage qui peut être copiée et envoyée manuellement au propriétaire de l'application ou à l'administrateur de sécurité. L'utilisateur peut aussi cliquer sur Envoyer un e-mail dans l'interface utilisateur.

Lorsqu'un utilisateur clique sur Envoyer un e-mail, un e-mail est envoyé à l'adresse e-mail d'assistance (supportEmail) configurée sur l'écran de consentement OAuth. Pour en savoir plus sur la configuration de l'écran de consentement OAuth, consultez la section Créer par programmation des clients OAuth pour IAP.

Résoudre les problèmes d'accès ayant échoué

Lorsque vous recevez le lien associé à une demande d'accès en échec d'un utilisateur final, vous pouvez cliquer sur l'URL, qui s'ouvre dans le navigateur par défaut. Si vous n'êtes pas connecté à Google Cloud Console dans votre navigateur par défaut, vous serez peut-être redirigé vers une autre page de connexion afin d'accéder à la page d'analyse de Policy Troubleshooter.

La page d'analyse de Policy Troubleshooter fournit une vue récapitulative, une vue des stratégies IAM et un tableau qui indiquent le contexte pour un utilisateur et l'appareil, tel que l'adresse principale, l'ID de l'appareil, la ressource IAP à laquelle l'utilisateur tente d'accéder, etc.

La vue récapitulative fournit une vue globale de tous les résultats pertinents concernant les stratégies et les adhésions. La vue des stratégies IAM fournit une liste des résultats de l'évaluation effective des liaisons IAM, accordées ou non, ainsi qu'une vue d'ensemble des emplacements où les échecs se sont produits, par exemple Principal not a member and does not meet conditions (Le compte principal n'est pas membre et ne remplit pas les conditions).

Pour analyser plus en détail l'accès ayant échoué, vous pouvez afficher les détails de la liaison. Dans la section Détails de la liaison, vous pouvez voir les composants de liaison, Rôle, Compte principal et Condition. Les composants disposant des autorisations suffisantes présentent la mention Aucune action requise. Pour les composants pour lesquels l'accès a échoué, les lacunes dans les autorisations sont explicitement détaillées, telles que Principal Category: Please add Principal to the below groups (Catégorie de compte principal : Veuillez ajouter le compte principal aux groupes ci-dessous).

Notez que dans l'interface utilisateur, la section Liaisons pertinentes est activée par défaut. Les liaisons répertoriées dans la section Liaisons pertinentes ne sont pas exhaustives. Il s'agit en fait des liaisons les plus pertinentes qui pourraient vous être utiles pour la résolution d'un problème d'accès spécifique. Les règles en vigueur associées à une ressource spécifique peuvent contenir de nombreuses liaisons non pertinentes pour votre ressource, comme une autorisation Cloud Storage accordée au niveau du projet. Les détails non pertinents sont filtrés.

Vous pouvez approfondir votre recherche sur une condition ayant conduit à un échec en examinant les explications des niveaux d'accès. Les détails du niveau d'accès indiquent où l'échec s'est produit et suggèrent des solutions pour le résoudre. Vous pouvez transmettre les actions requises àl'utilisateur ou corriger les règles, si nécessaire. Par exemple, vous pouvez renvoyer l'action suivante à l'utilisateur : Échec de la requête, car l'appareil n'est pas détenu par l'entreprise.

Activer l'URL de dépannage pour votre page d'erreur `Access Denied` personnalisée

Vous pouvez ajouter l'URL de Policy Troubleshooter à la page d'erreur Access Denied de votre client en procédant comme suit :

Rediriger vos utilisateurs vers votre page personnalisée plutôt que vers la page d'erreur IAP par défaut en définissant une page d'erreur "Accès refusé" personnalisée.
Activez la fonctionnalité d'URL de Policy Troubleshooter dans les paramètres IAP.

Une fois que vous avez configuré l'URL de la page access denied dans les paramètres IAP, l'URL Policy Troubleshooter est intégrée en tant que paramètre de requête échappé. Veillez à unescape le paramètre de requête avec échappement avant de l'ouvrir. La clé du paramètre de requête est troubleshooting-url.

Résoudre les problèmes d'accès des utilisateurs de manière proactive

Policy Troubleshooter, situé dans le panneau "Sécurité" de la page de destination de BeyondCorp Enterprise, vous permet de résoudre les problèmes liés aux événements hypothétiques, et d'obtenir des insights et une visibilité sur vos règles de sécurité. Par exemple, vous pouvez vérifier l'accès d'un utilisateur à une ressource protégée par IAP spécifique et déterminer si cela est vraiment nécessaire. Autre exemple : lorsque vous modifiez une règle sur une ressource protégée par IAP et que vous voulez vous assurer que le super-administrateur y a toujours accès. Vous pouvez accéder à la console d'administration Google pour obtenir l'ID de l'appareil appartenant au super-administrateur, puis vérifier l'accès à l'aide de l'ID de l'appareil dans l'outil de dépannage.

En résolvant les requêtes hypothétiques, vous pouvez vérifier qu'un utilisateur dispose des autorisations appropriées pour accéder à une ressource IAP avant qu'un événement de refus réel ne se produise. Pour ce faire, utilisez l'adresse e-mail de l'utilisateur, la ressource IAP cible et tous les contextes de requête facultatifs, y compris l'adresse IP, le code temporel, l'ID de l'appareil ou le contexte de l'appareil.

Lors de la résolution de problèmes liés à des demandes fictives à l'aide de l'ID de l'appareil, assurez-vous que celui-ci appartient à l'adresse e-mail du compte principal cible. Vous pouvez obtenir l'ID de l'appareil à partir du journal d'audit IAP ou en accédant à Console d'administration Google -> Appareils > Mobiles et points de terminaison > Appareils.

Lors du dépannage de requêtes hypothétiques à l'aide du contexte de l'appareil, les attributs suivants sont compatibles avec l'outil de dépannage :

is_secured_with_screenlock
encryption_status
os_type
os_version
verified_chrome_os
is_admin_approved_device
is_corp_owned_device

Scénarios de dépannage courants

Voici quelques scénarios courants que vous pouvez rencontrer lors de l'utilisation de Policy Troubleshooter :

Vous fournissez un élément exploitable à l'utilisateur final après le dépannage, par exemple en lui indiquant de passer à un appareil appartenant à l'entreprise ou de mettre à jour le système d'exploitation.
Vous découvrez que vous n'avez pas attribué l'autorisation appropriée à l'utilisateur final. Vous devez donc créer une liaison pour le compte principal cible dans l'interface IAP (roles/iap.httpsResourceAccessor).
Vous constatez que vous avez créé un niveau d'accès de manière incorrecte pour les exemples de raisons suivants :
- Vous avez créé des restrictions complexes d'attributs imbriqués, telles que des sous-réseaux d'entreprise, qui ne s'appliquent plus, car les employés travaillent désormais à domicile.
- Vous avez appliqué des paramètres de niveau d'accès incorrects. Vous avez par exemple spécifié que les utilisateurs peuvent créer un niveau personnalisé avec des restrictions de fournisseur, mais comparé des attributs ayant des types différents. Par exemple, device.vendors["vendorX"].data.["should_contain_boolean_value"] == "true". Notez que le côté gauche renvoie une valeur booléenne tandis que le côté droit renvoie une chaîne true. En raison de l'absence d'équivalence entre ces attributs, il est difficile de détecter l'erreur dans la construction de la règle. Policy Troubleshooter vous aide en expliquant que cette règle est évaluée comme erronée, avec des résultats d'évaluation partielle détaillés des deux côtés.

Comportement souhaité de l'outil de dépannage

Le dépannage s'effectue sur les accès restreints sur la base des règles actuelles et des informations sur l'appareil avec l'horodatage actuel. Par conséquent, si vous avez synchronisé votre appareil ou modifié les règles après l'échec de l'accès restreint, vous n'utilisez pas les anciens contextes et les anciennes données pour résoudre les problèmes. Vous effectuez le dépannage à l'aide des contextes et des données actuels.

Conseils pour résoudre les problèmes liés aux liaisons

Pour tout composant (Rôle, Compte principal, Condition) de toute liaison présentant des erreurs d'autorisation, accordez les autorisations nécessaires si vous souhaitez vérifier les résultats de dépannage de ces liaisons.

Si la vérification du rôle échoue dans une liaison, effectuez les actions suivantes :

Vérifiez les autres liaisons ou, si nécessaire, créez une liaison à l'aide de l'interface IAP pour accorder le rôle roles/iap.httpsResourceAccessor au compte principal auquel les niveaux d'accès s'appliquent.
S'il s'agit d'un rôle personnalisé, vous pouvez ajouter l'autorisation cible au rôle personnalisé afin d'accorder l'autorisation (après avoir corrigé tous les échecs liés au compte principal et à la condition, le cas échéant). Notez que l'ajout d'autorisations à un rôle personnalisé existant peut accorder d'autres liaisons avec ce rôle personnalisé, incluant davantage d'autorisations que nécessaire. Ne le faites que si vous connaissez le champ d'application du rôle personnalisé et les risques liés à votre opération.
S'il ne s'agit pas d'un rôle personnalisé, vérifiez les autres liaisons ou, si nécessaire, créez-en une via l'interface IAP afin d'accorder le rôle roles/iap.httpsResourceAccessor au compte principal auquel les niveaux d'accès s'appliquent.

Si la vérification du rôle réussit mais que la vérification du compte principal échoue, effectuez les actions suivantes :

Si les membres contiennent un groupe, vous pouvez ajouter le compte principal au groupe afin de lui accorder les autorisations (après avoir corrigé les échecs de condition, le cas échéant). Notez que l'ajout d'un compte principal à un groupe existant peut accorder au groupe davantage d'autorisations que nécessaire. Ne le faites que si vous connaissez le champ d'application du groupe et les risques liés à votre opération.
Si les membres ne contiennent pas de groupe, vérifiez les autres liaisons ou, si nécessaire, créez-en une nouvelle via l'interface IAP afin d'accorder le rôle roles/iap.httpsResourceAccessor au compte principal auquel les niveaux d'accès s'appliquent.

Si la vérification du rôle et du compte principal réussit, mais que la condition échoue, vérifiez les détails de dépannage de chaque niveau d'accès individuel répertorié sous la condition, si celle-ci n'est constituée que de niveaux d'accès connectés par des opérateurs logiques OR.