Présentation d'Identity-Aware Proxy

Cette page décrit les concepts de base d'Identity-Aware Proxy (IAP), un service mondial Google Cloud.

IAP vous permet d'établir une couche d'autorisation centrale pour les applications accessibles via HTTPS. Vous pouvez donc adopter un modèle de contrôle des accès au niveau des applications au lieu d'utiliser des pare-feu au niveau du réseau.

Les stratégies IAP concernent l'ensemble de votre organisation. Vous pouvez définir des stratégies d'accès de manière centralisée, et les appliquer à toutes vos applications et ressources. Lorsque vous créez une équipe dédiée à la création et à l'application de stratégies, vous protégez votre projet contre la définition ou la mise en œuvre incorrectes de stratégies dans n'importe quelle application.

Quand utiliser IAP ?

Utilisez IAP lorsque vous souhaitez appliquer des stratégies de contrôle des accès aux applications et aux ressources. Ce service sécurise votre application grâce à des en-têtes signés ou à l'API Users de l'environnement standard App Engine. IAP vous permet de configurer l'accès aux applications de manière groupée : une ressource peut être accessible aux employés et inaccessible aux sous-traitants, ou accessible à un service spécifique uniquement.

Fonctionnement d'IAP

Lorsqu'une application ou une ressource est protégée par IAP, seuls les comptes principaux, également appelés utilisateurs, disposant du rôle Identity and Access Management (IAM) approprié, ne peuvent y accéder via le proxy. Lorsque vous autorisez un utilisateur à accéder à une application ou à une ressource via IAP, il est soumis aux contrôles ultraprécis des accès mis en œuvre par le produit en cours d'utilisation, sans qu'un VPN ne soit requis. Lorsqu'un utilisateur tente d'accéder à une ressource sécurisée par IAP, des vérifications d'authentification et d'autorisation sont effectuées.

App Engine
Diagramme du chemin de requête vers App Engine lors de l'utilisation de Cloud IAP
Cloud Run
Diagramme du chemin de requête vers Cloud Run lors de l'utilisation de Cloud IAP
Compute Engine
Diagramme du chemin de requête vers Compute Engine et Kubernetes Engine lors de l'utilisation de Cloud IAP
GKE
Diagramme du chemin de requête vers Compute Engine et Kubernetes Engine lors de l'utilisation de Cloud IAP
Sur site
Diagramme du chemin de requête vers une application sur site lors de l'utilisation de Cloud IAP

Authentification

Les requêtes adressées à vos ressources Google Cloud passent par App Engine et Cloud Load Balancing (équilibrage de charge HTTP(S) externe et interne). Le code d'infrastructure de diffusion pour ces produits vérifie si IAP est activé pour l'application ou le service de backend. Si c'est le cas, des informations sur la ressource protégée sont envoyées au serveur d'authentification IAP. Ces informations comprennent le numéro du projet Google Cloud, l'URL de la requête et les identifiants IAP figurant dans les cookies ou les en-têtes de requête.

Ensuite, IAP vérifie les identifiants du navigateur de l'utilisateur. S'il n'en existe pas, l'utilisateur est redirigé vers un flux de connexion au compte Google OAuth 2.0 qui conserve un jeton dans un cookie du navigateur pour les connexions futures. Si vous avez besoin de créer des comptes Google pour vos utilisateurs existants, vous pouvez activer Google Cloud Directory Sync pour synchroniser les données avec votre serveur Active Directory ou LDAP.

Si les identifiants de la requête sont valides, le serveur d'authentification s'en sert pour obtenir l'identité de l'utilisateur (adresse e-mail et ID utilisateur). Le serveur d'authentification utilise ensuite l'identité pour vérifier le rôle IAM de l'utilisateur et contrôler si l'utilisateur est autorisé à accéder à la ressource.

Si vous utilisez Compute Engine ou Google Kubernetes Engine, les utilisateurs disposant d'un accès au port de diffusion des applications de la machine virtuelle (VM, Virtual Machine) peuvent contourner l'authentification IAP. Les règles de pare-feu Compute Engine et GKE ne peuvent pas empêcher l'accès depuis le code en cours d'exécution sur la même VM que l'application sécurisée par IAP. Les règles de pare-feu peuvent protéger contre les accès provenant d'une autre VM, mais uniquement si elles sont correctement configurées. Renseignez-vous sur vos responsabilités en matière de sécurité.

Si vous utilisez Cloud Run, les utilisateurs ayant accès à l'URL attribuée automatiquement peuvent contourner l'authentification IAP. Les contrôles d&#Ingress peuvent limiter l'accès à l'équilibrage de charge, mais uniquement s'ils sont correctement configurés. Apprenez-en plus sur vos responsabilités en termes de sécurité.

Autorisation

Après l'authentification, IAP applique la stratégie IAM appropriée pour vérifier si l'utilisateur est autorisé à accéder à la ressource demandée. S'il dispose du rôle Utilisateur de l'application Web sécurisée par IAP dans le projet de la console Google Cloud contenant la ressource, il est autorisé à accéder à l'application. Pour gérer la liste des rôles Utilisateur de l'application Web sécurisée par IAP, accédez au panneau IAP de la console Google Cloud.

Lorsque vous activez IAP pour une ressource, un code secret et un ID client OAuth 2.0 sont automatiquement créés. Si vous supprimez les identifiants OAuth 2.0 générés automatiquement, IAP ne fonctionnera pas correctement. Vous pouvez afficher et gérer les identifiants OAuth 2.0 dans les API et services de la console Google Cloud.

Vos responsabilités

IAP sécurise l'authentification et l'autorisation de toutes les requêtes adressées à App Engine, à Cloud Load Balancing (HTTPS) ou à l'équilibrage de charge HTTP interne. IAP ne protège pas contre les activités au sein d'un projet, comme une autre VM dans le projet.

Pour plus de sécurité, vous devez prendre les précautions suivantes :

  • Configurez votre pare-feu et votre équilibreur de charge pour vous protéger du trafic extérieur à l'infrastructure de diffusion.
    • Si vous utilisez Cloud Run, vous pouvez également restreindre l'accès à l'aide de contrôles d'entrée.
  • Utilisez des en-têtes signés ou l'API Users de l'environnement standard App Engine.

Étapes suivantes