Ce guide explique comment étendre les stratégies d'accès d'Identity-Aware Proxy (IAP) à l'aide de niveaux d'accès et du framework des conditions Identity and AccessManagement (IAM). Les niveaux d'accès permettent de restreindre l'accès aux ressources en fonction de l'adresse IP et des attributs de l'appareil de l'utilisateur final. Les conditions IAM permettent, quant à elles, de restreindre l'accès en fonction des hôtes d'URL, des chemins d'URL, de la date et de l'heure.
Par exemple, selon la configuration des stratégies, votre application sensible peut :
- accorder l'accès à tous les employés qui utilisent un appareil d'entreprise approuvé sur le réseau d'entreprise ;
- accorder l'accès aux employés du groupe Accès à distance qui utilisent un appareil d'entreprise approuvé avec un mot de passe sécurisé et un niveau de correctif à jour, sur n'importe quel réseau ;
- accorder l'accès seulement aux employés du groupe Accès privilégié si le chemin de l'URL commence par
/admin
.
Avant de commencer
Avant de commencer, vous aurez besoin des éléments suivants :
- Une application sécurisée par IAP à laquelle vous souhaitez ajouter un accès individuel ou de groupe
- Des noms d'utilisateurs ou de groupes auxquels vous souhaitez accorder l'accès.
Configurer un niveau d'accès
Pour limiter l'accès en fonction de l'adresse IP ou des attributs de l'appareil de l'utilisateur final, vous devez créer un niveau d'accès. Pour savoir comment créer un niveau d'accès, consultez le guide d'Access Context Manager. IAP se sert du nom du niveau d'accès pour l'associer à une application qu'il sécurise.
L'utilisation de règles de portée n'est pas prise en charge par l'API IAP. Les niveaux d'accès doivent être définis dans la règle d'accès de l'organisation. Pour en savoir plus, consultez la section Créer une règle d'accès.
Modifier la stratégie IAM
Une application sécurisée par IAP dispose d'une stratégie IAM qui lie le rôle IAP à l'application.
L'ajout d'une liaison conditionnelle IAM à la stratégie IAM permet de restreindre davantage l'accès à vos ressources en fonction des attributs de requête. Ces derniers incluent :
- Niveaux d'accès
- Nom d'hôte/Chemin d'URL
- Date/Heure
Notez que les valeurs de requête qui sont comparées à request.host
et request.path
, et qui sont spécifiées dans une liaison conditionnelle IAM, doivent être exactes. Par exemple, si vous limitez l'accès aux chemins commençant par /internal admin
, il est possible de contourner la restriction en accédant à /internal%20admin
. Pour en savoir plus sur les conditions applicables aux noms d'hôte et aux chemins d'accès, consultez la section Utiliser des conditions applicables aux noms d'hôte et aux chemins d'accès.
Si vous souhaitez ajouter et modifier des liaisons conditionnelles pour votre stratégie IAM, suivez la procédure ci-dessous.
Console
Pour ajouter une liaison conditionnelle à l'aide de la console Google Cloud:
Accédez à la page d'administration d'IAP.
Cochez la case située à côté des ressources pour lesquelles vous souhaitez mettre à jour les autorisations IAM.
Dans le panneau d'informations situé à droite, cliquez sur Ajouter un compte principal.
Dans le champ Nouveau compte principal, saisissez les comptes principaux auxquels vous souhaitez attribuer un rôle.
Dans la liste déroulante Sélectionner un rôle, sélectionnez le rôle Utilisateur de l'application Web sécurisée par IAP et indiquez les conditions de niveau d'accès à la ressource pour les principaux.
- Pour spécifier des niveaux d'accès existants, sélectionnez-les dans la liste déroulante Niveaux d'accès. Vous devez choisir le rôle Utilisateur de l'application Web sécurisée par IAP et disposer des autorisations au niveau de l'organisation pour afficher les niveaux d'accès existants. Vous devez disposer de l'un des rôles suivants :
- Administrateur Access Context Manager
- Éditeur Access Context Manager
- Lecteur Access Context Manager
- Pour créer et gérer des niveaux d'accès, servez-vous de la fonctionnalité Access Context Manager.
- Pour spécifier des niveaux d'accès existants, sélectionnez-les dans la liste déroulante Niveaux d'accès. Vous devez choisir le rôle Utilisateur de l'application Web sécurisée par IAP et disposer des autorisations au niveau de l'organisation pour afficher les niveaux d'accès existants. Vous devez disposer de l'un des rôles suivants :
Si vous souhaitez ajouter d'autres rôles aux membres, cliquez sur Ajouter un autre rôle.
Une fois les rôles ajoutés, cliquez sur Enregistrer.
Vous venez d'ajouter une liaison conditionnelle à votre ressource.
Pour supprimer une liaison conditionnelle, procédez comme suit :
Accédez à la page d'administration d'IAP.
Cochez la case située à côté de la ressource pour laquelle vous souhaitez supprimer le rôle IAM d'un compte principal.
Dans le panneau d'informations situé à droite, sous Rôle / Compte principal, cliquez sur le rôle que vous souhaitez supprimer du compte principal.
Cliquez sur Supprimer à côté du compte principal.
Dans la boîte de dialogue Supprimer le rôle pour le compte principal qui s'affiche, cliquez sur Supprimer. Pour supprimer tous les rôles non hérités du principal sur la ressource sélectionnée, cochez la case correspondante avant de cliquer sur Supprimer.
gcloud
Pour le moment, vous ne pouvez utiliser l'outil gcloud que pour définir des liaisons conditionnelles au niveau du projet.
Pour définir des liaisons conditionnelles, modifiez le fichier policy.yaml
de votre projet en procédant comme suit :
Ouvrez la stratégie IAM de l'application à l'aide de la commande gcloud suivante :
gcloud iap web get-iam-policy --project=PROJECT_ID > policy.yaml
Modifiez le fichier
policy.yaml
de façon à spécifier les éléments suivants :- Les utilisateurs et groupes auxquels vous souhaitez appliquer la condition IAM
- Le rôle
iap.httpsResourceAccessor
pour leur accorder l'accès aux ressources La condition IAM
L'extrait suivant montre une condition IAM avec un seul attribut spécifié. Cette condition accorde l'accès à l'utilisateur et au groupe si les exigences du niveau d'accès ACCESS_LEVEL_NAME sont remplies et si le chemin de l'URL de la ressource commence par
/
.
bindings: ... - members: - group:EXAMPLE_GROUP@GOOGLE.COM - user:EXAMPLE_USER@GOOGLE.COM role: roles/iap.httpsResourceAccessor condition: expression: "accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/") title: CONDITION_TITLE ...
Liez la stratégie à l'application à l'aide de la commande
set-iam-policy
.gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
Votre stratégie IAM inclut désormais une liaison conditionnelle.
API
Pour modifier le fichier policy.json
de votre application, suivez la procédure ci-dessous pour votre type d'application.
Consultez la section Gérer l'accès aux ressources sécurisées par IAP pour plus d'informations sur l'utilisation de l'API IAM pour gérer les stratégies d'accès.
Avant de suivre la procédure de l'API spécifique à chaque application ci-dessous, exportez les variables suivantes:
export PROJECT_NUM=PROJECT_NUMBER export IAP_BASE_URL=https://iap.googleapis.com/v1/projects/${PROJECT_NUM}/iap_web # Replace POLICY_FILE.JSON with the name of JSON file to use for setIamPolicy export JSON_NEW_POLICY=POLICY_FILE.JSON
App Engine
Exportez les variables App Engine suivantes :
# The APP_ID is usually the project ID export GAE_APP_ID=APP_ID export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}
Obtenez la stratégie IAM pour l'application App Engine à l'aide de la méthode
getIamPolicy
. Le bit de données vide à la fin transforme la requêtecurl
en POST au lieu de GET.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${GAE_BASE_URL}/:getIamPolicy -d ''
Ajoutez votre liaison conditionnelle IAM au fichier JSON de stratégie IAM. L'exemple suivant présente un fichier
policy.json
modifié qui lie le rôleiap.httpsResourceAccessor
à deux utilisateurs, en leur accordant l'accès aux ressources sécurisées par IAP. Une condition IAM a été ajoutée pour leur permettre de n'accéder aux ressources que si les exigences du niveau d'accès ACCESS_LEVEL_NAME sont remplies et si le chemin de l'URL de la ressource commence par/
. Il ne peut y avoir qu'une seule condition par liaison.
Exemple de fichier policy.json{ "policy": { "bindings": [ { "role": "roles/iap.httpsResourceAccessor", "members": [ "group:EXAMPLE_GROUP@GOOGLE.COM", "user:EXAMPLE_USER@GOOGLE.COM" ], "condition": { "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")", "title": "CONDITION_NAME" } } ] } }
Définissez votre nouveau fichier
policy.json
à l'aide de la méthodesetIamPolicy
.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${GAE_BASE_URL}:setIamPolicy -d @${JSON_NEW_POLICY}
Services et versions App Engine
Vous pouvez également mettre à jour la stratégie IAM d'un service App Engine, de toutes les versions ou d'une version spécifique d'un service. Pour mettre à jour la stratégie Cloud IAM d'une version spécifique d'un service, procédez comme suit :
- Exportez les variables supplémentaires suivantes :
export GAE_SERVICE=SERVICE_NAME export GAE_VERSION=VERSION_NAME
- Mettez à jour la variable GAE_BASE_URL exportée.
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}
- Obtenez et définissez la stratégie IAM de la version à l'aide des commandes
getIamPolicy
etsetIamPolicy
indiquées ci-dessus.
GKE et Compute Engine
Exportez l'ID du projet de votre service de backend.
export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
Obtenez la stratégie IAM de l'application App Engine à l'aide de la méthode
getIamPolicy
. Le bit de données vide à la fin transforme la requêtecurl
en POST au lieu de GET.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \ -d ''
Ajoutez votre liaison conditionnelle IAM au fichier JSON de stratégie IAM. L'exemple suivant présente un fichier
policy.json
modifié qui lie le rôleiap.httpsResourceAccessor
à deux utilisateurs, en leur accordant l'accès aux ressources sécurisées par IAP. Une condition IAM a été ajoutée pour leur permettre de n'accéder aux ressources que si les exigences du niveau d'accès ACCESS_LEVEL_NAME sont remplies et si le chemin de l'URL de la ressource commence par/
. Il ne peut y avoir qu'une seule condition par liaison.
Exemple de fichier policy.json{ "policy": { "bindings": [ { "role": "roles/iap.httpsResourceAccessor", "members": [ "group":EXAMPLE_GROUP@GOOGLE.COM, "user:EXAMPLE_USER@GOOGLE.COM" ], "condition": { "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")", "title": "CONDITION_NAME" } } ] } }
Définissez votre nouveau fichier
policy.json
à l'aide de la méthodesetIamPolicy
.curl -i -H "Content-Type:application/json" \ -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:setIamPolicy \ -d @${JSON_NEW_POLICY}
Utiliser des conditions applicables aux noms d'hôte et aux chemins d'accès
L'accès à votre application peut être sécurisé à l'aide du nom d'hôte et du chemin d'une URL de requête.
Par exemple, la condition IAM request.path.startsWith
peut être utilisée pour n'accorder l'accès aux employés du groupe Accès privilégié que si le chemin de l'URL commence par /admin
.
Pour en savoir plus sur l'utilisation des conditions applicables aux noms d'hôte et aux chemins d'accès, consultez la section Attributs de requête.
Normalisation des chaînes
Une URL est associée à un nom d'hôte et un chemin d'accès. Par exemple, l'URL https://sheets.google.com/create?query=param
est associée au nom d'hôte sheets.google.com
et au chemin d'accès /create
.
Les backends peuvent interpréter les noms d'hôtes et les chemins d'accès de différentes manières. Pour éliminer toute ambiguïté, IAP normalise les chaînes de noms d'hôte et de chemins d'accès lors de la vérification des stratégies.
IAP procède à deux vérifications des stratégies lorsqu'une requête est associée à un chemin d'accès non normalisé. Si la vérification des stratégies réussit pour le chemin d'accès non normalisé, IAP le normalise. Une deuxième vérification des stratégies est effectuée. L'accès est accordé si la vérification réussit pour les chemins d'accès non normalisé et normalisé.
Par exemple, si une requête est associée au chemin d'accès /internal;some_param/admin
, IAP commence par effectuer une vérification des stratégies pour le chemin d'accès non normalisé (/internal
). Si celle-ci réussit, IAP effectue une deuxième vérification pour le chemin d'accès normalisé (/internal/admin
).
Noms d'hôte
Vous pouvez normaliser les noms d'hôte en effectuant les opérations suivantes :
- Suppression des points finaux
- Mise en minuscules des caractères
- Conversion au format ASCII
Les noms d'hôte qui incluent des caractères non ASCII sont ensuite normalisés à l'aide de la syntaxe Punycode. Vous devez appliquer cette syntaxe à la chaîne de votre nom d'hôte pour obtenir une correspondance.
Pour appliquer la syntaxe Punycode à la chaîne de votre nom d'hôte, utilisez un convertisseur tel que Punycoder.
Voici des exemples de noms d'hôte normalisés :
FOO.com
est normalisé enfoo.com
.café.fr
est normalisé enxn--caf-dma.fr
.
Chemins d'accès
Vous pouvez normaliser les chemins d'accès en effectuant les opérations suivantes :
- Suppression des paramètres de chemin
- Conversion des chemins relatifs en leur équivalent absolu
Un paramètre de chemin inclut tous les caractères compris entre un point-virgule (;
) et la barre oblique (/
) suivante ou la fin du chemin.
Les requêtes comportant ..;
au début d'une section de chemin sont considérées comme non valides.
Par exemple, /..;bar/
et /bar/..;/
renvoient l'erreur HTTP 400: Bad Request
.
Voici des exemples de chemins d'accès normalisés :
/internal;some_param/admin
est normalisé en/internal/admin
./a/../b
est normalisé en/b
./bar;param1/baz;baz;param2
est normalisé en/bar/baz
.
Terminaisons des sous-domaines
Une stratégie définie avec request.host.endsWith("google.com")
correspond à sub_domain.google.com
et testgoogle.com
. Si vous souhaitez limiter votre stratégie à tous les sous-domaines qui se terminent par google.com
, définissez-la sur request.host.endsWith(".google.com")
.
Notez qu'une stratégie définie sur request.host.endsWith(".google.com")
correspond à sub_domain.google.com
, mais pas à google.com
en raison de la présence d'un point supplémentaire (.
).
Cloud Audit Logging et niveaux d'accès
L'activation des journaux d'audit Cloud pour votre projet sécurisé par IAP vous permet de voir les requêtes d'accès autorisées et non autorisées. Pour consulter les requêtes et tous les niveaux d'accès qu'un demandeur a atteints, procédez comme suit :
-
Accédez à l'
explorateur de journaux de la console Google Cloud pour votre projet.
Accédez à la page Journaux. - Dans la liste déroulante de sélection des ressources, choisissez une ressource. Les ressources HTTPS sécurisées par IAP se trouvent sous Application GAE et Service de backend GCE. Les ressources SSH et TCP sécurisées par IAP sont situées sous Instance de VM GCE.
- Dans la liste déroulante Type de journaux, sélectionnez data_access.
- Le type de journal data_access ne s'affiche que s'il y a eu du trafic vers votre ressource après l'activation des journaux d'audit Cloud pour IAP.
- Cliquez pour afficher la date et l'heure de l'accès que vous souhaitez consulter.
- Un accès autorisé est représenté par une icône
i
bleue. - Un accès non autorisé est représenté par une icône
!!
orange.
- Un accès autorisé est représenté par une icône
- Affichez les niveaux d'accès atteints par le demandeur en cliquant pour développer les sections jusqu'à accéder à
protoPayload
>requestMetadata
>requestAttributes
>auth
>accessLevels
.
Notez que tous les niveaux d'accès atteints par un utilisateur sont visibles lors de l'affichage d'une requête, y compris les niveaux d'accès qui n'étaient pas requis pour y accéder. L'affichage d'une requête non autorisée n'indique pas les niveaux d'accès qui n'ont pas été atteints. Il est possible d'obtenir cette information en comparant les conditions de la ressource aux niveaux d'accès visibles sur la requête.
Pour en savoir plus sur les journaux, consultez le guide Journaux d'audit Cloud.