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, elle ne peut être accessible via le proxy que par des comptes principaux, également appelés utilisateurs, disposant du rôle IAM (Identity and Access Management) approprié. 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 Cloud Run, App Engine et Cloud Load Balancing (équilibrage de charge HTTP(S) externe et interne). Le code d'infrastructure de diffusion de 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 empêcher l'accès depuis 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, vous pouvez activer IAP de différentes manières :

  • Directement sur vos services Cloud Run. Cela permet à IAP de protéger tous les chemins d'accès à Cloud Run, y compris l'URL attribuée automatiquement et toute URL d'équilibreur de charge configurée. Cette configuration est utile lorsque vous n'avez qu'un seul service Cloud Run pour lequel activer IAP.
  • Via un équilibreur de charge avec un backend Cloud Run. Cette configuration est utile lorsque vous avez plusieurs services Cloud Run dans différentes régions derrière un seul équilibreur de charge global. Dans cette configuration, l'URL attribuée automatiquement n'est pas protégée par IAP et peut être directement accessible. Renseignez-vous sur vos responsabilités en matière de sécurité.

Si un service Cloud Run se trouve derrière un équilibreur de charge, n'activez pas IAP à la fois sur l'équilibreur de charge et sur le service Cloud Run.

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 consoleGoogle Cloud comportant 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 sur la page API et services de la consoleGoogle Cloud .

Accès contextuel

Lors de l'étape d'autorisation, vous pouvez utiliser l'accès contextuel pour fournir un accès sécurisé aux types de ressources suivants :

Console et APIGoogle Cloud
  • Première ligne de défense pour protéger l'accès à l'infrastructure de Google Cloud.
  • Accès contextuel avancé Google Cloud aux utilisateurs.
Machines virtuelles (VM)
  • Active l'accès administrateur SSH/RDP aux VM dans Google Cloud et dans d'autres clouds.
  • Vous permet d'implémenter des contrôles contextuels robustes pour limiter l'accès aux seuls administrateurs désignés.
Applications Web
  • Fournit l'autorisation et l'authentification pour les applications Web hébergées dansGoogle Cloud et d'autres clouds.
  • Fournit une autorisation continue pour empêcher tout accès non autorisé et toute perte de données.

Vos responsabilités

IAP sécurise l'authentification et l'autorisation de toutes les requêtes vers Cloud Run, App Engine, Cloud Load Balancing (HTTPS) et l'équilibrage de charge HTTP interne.

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

  • Si vous activez IAP sur un équilibreur de charge, vérifiez si les ressources de backend sont directement accessibles.
    • Si la ressource de backend est une VM, configurez vos règles de pare-feu pour vous protéger du trafic qui ne passe pas par l'équilibreur de charge. IAP ne protège pas contre les activités au sein d'un projet, comme une autre VM dans le projet.
    • Si la ressource de backend est un service Cloud Run, vous pouvez désactiver l'URL run.app pour vous assurer que tout le trafic entrant passe par l'équilibreur de charge. Si vous choisissez de laisser l'URL run.app activée, vous devez utiliser des contrôles d'entrée pour bloquer le trafic provenant de l'extérieur de votre réseau.
  • Mettez à jour votre application pour utiliser des en-têtes signés ou l'API Users de l'environnement standard App Engine.

Étapes suivantes