Configurer l'accès contextuel avec Identity-Aware Proxy

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 délimitées n'est pas compatible avec 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 page 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, procédez comme suit:

Accédez à la page d'administration d'IAP.
Accéder à 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, choisissez le rôle Utilisateur de l'application Web sécurisée par IAP et indiquez les conditions de niveau d'accès que les comptes principaux doivent remplir pour accéder à la ressource.
- 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.
Si vous souhaitez ajouter d'autres rôles aux comptes principaux, 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.
Accéder à la page d'administration d'IAP
Cochez la case à 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 compte principal sur la ressource sélectionnée, cochez la case 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_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 d'effectuer les étapes d'API spécifiques à l'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ête curl 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ôle iap.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éthode setIamPolicy.

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 et setIamPolicy 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ête curl 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ôle iap.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éthode setIamPolicy.

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é en foo.com.
café.fr est normalisé en xn--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 types 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 Cloud Audit Logs 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.
Affichez les niveaux d'accès atteints par le demandeur en cliquant pour développer les sections jusqu'à atteindre 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 sur Cloud Audit Logs.