Cette section explique comment utiliser Cloud Identity pour gérer les identités utilisées par vos employés pour accéder aux services Google Cloud.
Fournisseur d'identité externe comme source fiable
Nous vous recommandons de fédérer votre compte Cloud Identity avec votre fournisseur d'identité existant. La fédération vous aide à garantir que vos processus de gestion de comptes existants s'appliquent à Google Cloud et à d'autres services Google.
Si vous ne disposez d'aucun fournisseur d'identité, vous pouvez créer des comptes utilisateur directement dans Cloud Identity.
Le schéma suivant présente une vue d'ensemble de la fédération d'identité et de l'authentification unique (SSO). Microsoft Active Directory est utilisé comme exemple de fournisseur d'identité, dans l'environnement sur site.
Ce schéma décrit les bonnes pratiques suivantes:
- Les identités des utilisateurs sont gérées dans un domaine Active Directory situé dans l'environnement sur site et fédéré à Cloud Identity. Active Directory se sert de Google Cloud Directory Sync pour provisionner les identités dans Cloud Identity.
- Les utilisateurs qui tentent de se connecter aux services Google sont redirigés vers le fournisseur d'identité externe pour procéder à l'authentification unique SAML, en utilisant leurs identifiants existants pour s'authentifier. Aucun mot de passe n'est synchronisé avec Cloud Identity.
Le tableau suivant fournit des liens vers des conseils de configuration pour les fournisseurs d'identité.
| Fournisseur d'identité | Conseils |
|---|---|
| Active Directory | |
| ID Microsoft Entra (anciennement Azure AD) | |
| Autres fournisseurs d'identité externes (par exemple, Ping ou Okta) |
Nous vous recommandons vivement d'appliquer l'authentification multifacteur à votre fournisseur d'identité avec un mécanisme antihameçonnage, tel qu'une clé de sécurité Titan.
Les paramètres recommandés pour Cloud Identity ne sont pas automatisés via le code Terraform dans ce plan. Consultez la page Contrôles administratifs pour Cloud Identity pour connaître les paramètres de sécurité recommandés que vous devez configurer en plus du déploiement du code Terraform.
Groupes pour le contrôle des accès
Un compte principal est une identité qui peut se voir accorder l'accès à une ressource. Les comptes principaux incluent les comptes Google pour les utilisateurs, les groupes Google, les comptes Google Workspace, les domaines Cloud Identity et les comptes de service. Certains services vous permettent également d'accorder l'accès à tous les utilisateurs qui s'authentifient avec un compte Google ou à tous les internautes. Pour qu'un compte principal puisse interagir avec les services Google Cloud, vous devez lui attribuer des rôles dans Identity and Access Management (IAM).
Pour gérer les rôles IAM à grande échelle, nous vous recommandons d'attribuer des utilisateurs à des groupes en fonction de leurs fonctions de poste et des conditions d'accès requises, puis d'attribuer des rôles IAM à ces groupes. Vous devez ajouter des utilisateurs aux groupes à l'aide des processus de votre fournisseur d'identité existant pour la création et la souscription de groupes.
Nous vous déconseillons d'attribuer des rôles IAM à des utilisateurs individuels, car les attributions individuelles peuvent augmenter la complexité de la gestion et de l'audit des rôles.
Le plan configure les groupes et les rôles pour un accès en lecture seule aux ressources de base. Nous vous recommandons de déployer toutes les ressources du plan via le pipeline de base et de ne pas attribuer des rôles aux groupes pour modifier les ressources de base en dehors du pipeline.
Le tableau suivant présente les groupes configurés par le plan pour afficher les ressources de base.
| Nom | Description | Rôles | Définition du champ d'application |
|---|---|---|---|
grp-gcp-org-admin@example.com |
Administrateurs privilégiés pouvant attribuer des rôles IAM au niveau de l'organisation. Ils peuvent accéder à n'importe quel autre rôle. Ce privilège est déconseillé pour l'utilisation quotidienne. | Administrateur de l'organisation | organisation |
grp-gcp-billing-admin@example.com |
Administrateurs privilégiés pouvant modifier le compte de facturation Cloud. Ce privilège n'est pas recommandé pour une utilisation quotidienne. | Administrateur de compte de facturation | organisation |
grp-gcp-billing-viewer@example.com |
L'équipe chargée d'afficher et d'analyser les dépenses sur tous les projets. | Lecteur de compte de facturation | organisation |
| Utilisateur BigQuery | Projet de facturation | ||
grp-gcp-audit-viewer@example.com |
L'équipe chargée de l'audit des journaux de sécurité. | Projet Logging | |
grp-gcp-security-reviewer@example.com |
L'équipe chargée d'examiner la sécurité du cloud. | Examinateur de sécurité | organisation |
grp-gcp-network-viewer@example.com |
L'équipe chargée d'afficher et de gérer les configurations réseau. | Lecteur de réseau Compute | organisation |
grp-gcp-scc-admin@example.com |
Équipe chargée de la configuration de Security Command Center. | Éditeur administrateur du centre de sécurité | organisation |
grp-gcp-secrets-admin@example.com |
L'équipe chargée de la gestion, du stockage et de l'audit des identifiants et d'autres secrets utilisés par les applications. | Administrateur Secret Manager | projets secrets |
grp-gcp-kms-admin@example.com |
L'équipe chargée d'appliquer la gestion des clés de chiffrement pour répondre aux exigences de conformité. | Lecteur Cloud KMS | projets kms |
Lorsque vous créez vos propres charges de travail sur une base solide, vous créez des groupes supplémentaires et attribuez des rôles IAM basés sur les conditions d'accès pour chaque charge de travail.
Nous vous recommandons vivement d'éviter les rôles de base (par exemple, propriétaire, éditeur ou lecteur) et d'utiliser des rôles prédéfinis. Les rôles de base sont trop permissifs et constituent un risque de sécurité potentiel. Les rôles de propriétaire et d'éditeur peuvent entraîner une élévation des privilèges et un mouvement latéral, et le rôle Lecteur permet d'accéder en lecture à toutes les données. Pour connaître les bonnes pratiques concernant les rôles IAM, consultez la page Utiliser IAM en toute sécurité.
Comptes super-administrateur
Les utilisateurs Cloud Identity disposant du compte super-administrateur contournent les paramètres d'authentification unique de l'organisation et s'authentifient directement avec Cloud Identity. Cette exception est volontaire, de sorte que le super-administrateur peut toujours accéder à la console Cloud Identity en cas de mauvaise configuration ou de panne de l'authentification unique. Toutefois, cela signifie que vous devez envisager une protection supplémentaire pour les comptes super-administrateur.
Pour protéger vos comptes super-administrateur, nous vous recommandons de toujours appliquer la validation en deux étapes avec des clés de sécurité dans Cloud Identity. Pour en savoir plus, consultez Bonnes pratiques de sécurité relatives aux comptes administrateur.
Problèmes liés aux comptes utilisateur personnels
Si vous n'utilisiez pas Cloud Identity ou Google Workspace avant d'intégrer Google Cloud, il est possible que les employés de votre organisation utilisent déjà des comptes personnels associés à leurs identités de messagerie professionnelle pour accéder à d'autres services Google tels que Google Marketing Platform ou YouTube. Les comptes personnels sont des comptes entièrement détenus et gérés par leurs créateurs. Étant donné que ces comptes ne sont pas sous le contrôle de votre organisation et peuvent inclure à la fois des données personnelles et professionnelles, vous devez décider de comment les regrouper avec d'autres comptes d'entreprise.
Nous vous recommandons de regrouper les comptes utilisateur personnels existants dans le cadre de l'intégration à Google Cloud. Si vous n'utilisez pas encore Google Workspace pour tous vos comptes utilisateur, nous vous recommandons de bloquer la création de comptes personnels.
Commandes d'administration pour Cloud Identity
Cloud Identity comprend diverses commandes d'administration qui ne sont pas automatisées par le code Terraform dans le plan. Nous vous recommandons d'appliquer chacun de ces contrôles de sécurité basés sur les bonnes pratiques dès le début du processus de création de vos fondations.
| Contrôle | Description |
|---|---|
| Déployer la validation en deux étapes | Les comptes utilisateur peuvent être piratés par du hameçonnage, de l'ingénierie sociale, de la répétition des mots de passe ou d'autres menaces. La validation en deux étapes permet de limiter ces menaces. Nous vous recommandons d'appliquer la validation en deux étapes pour tous les comptes utilisateur de votre organisation à l'aide d'un mécanisme antihameçonnage, tel que les clés de sécurité Titan ou d'autres clés basées sur les normes FIDO U2F (CTAP1) antihameçonnage. |
| Définir la durée de session pour les services Google Cloud | Les jetons OAuth persistants sur les postes de travail des développeurs peuvent présenter un risque de sécurité s'ils sont exposés. Nous vous recommandons de définir une règle de réauthentification pour exiger une authentification toutes les 16 heures à l'aide d'une clé de sécurité. |
| Définir la durée de session pour les services Google | (clients Google Workspace uniquement)
Les sessions Web persistantes sur d'autres services Google peuvent présenter un risque de sécurité si elles sont exposées. Nous vous recommandons d'appliquer une durée maximale de session Web et de l'aligner sur les contrôles de durée de session de votre fournisseur SSO. |
| Partager des données depuis Cloud Identity avec les services Google Cloud | En règle générale, les journaux d'audit pour les activités d'administration de Google Workspace ou Cloud Identity sont affichés et gérés dans la console d'administration séparément de vos journaux dans votre environnement Google Cloud. Ces journaux contiennent des informations pertinentes pour votre environnement Google Cloud, telles que des événements de connexion utilisateur. Nous vous recommandons de partager les journaux d'audit Cloud Identity avec votre environnement Google Cloud pour gérer les journaux de manière centralisée à partir de toutes les sources. |
| Configurer la validation post-authentification unique | Le plan suppose que vous avez configuré l'authentification unique avec votre fournisseur d'identité externe. Nous vous recommandons d'activer un niveau de contrôle supplémentaire basé sur l'analyse des risques de connexion Google. Après l'application de ce paramètre, les utilisateurs peuvent voir des questions d'authentification en cas de risque de sécurité supplémentaires lors de la connexion, si Google estime qu'elle est suspecte. |
| Résoudre les problèmes liés aux comptes utilisateur personnels | Les utilisateurs disposant d'une adresse e-mail valide sur votre domaine, mais qui n'ont pas de compte Google, peuvent créer des comptes personnels non gérés. Ces comptes peuvent contenir des données d'entreprise, mais ne sont pas contrôlés par les processus de gestion du cycle de vie de vos comptes. Nous vous recommandons de prendre des mesures pour vous assurer que tous les comptes utilisateur sont des comptes gérés. |
| Désactiver la récupération de compte pour les comptes super-administrateur | L'autorécupération de compte super-administrateur est désactivée par défaut pour tous les nouveaux clients (ce paramètre peut être activé pour les clients existants). La désactivation de ce paramètre permet de limiter le risque qu'un téléphone compromis, une adresse e-mail compromise ou une attaque par ingénierie sociale puisse permettre à un pirate informatique d'obtenir des droits de super-administrateur sur votre environnement. Planifiez un processus interne pour un super-administrateur afin de contacter un autre super-administrateur de votre organisation s'il a perdu l'accès à son compte, et assurez-vous que tous les super-administrateurs sont familiarisés avec le processus de récupération assistée. |
| Appliquer et contrôler des règles de mots de passe pour les utilisateurs | Dans la plupart des cas, les mots de passe utilisateur sont gérés via votre fournisseur d'identité externe, mais les comptes super-administrateur contournent l'authentification unique et doivent utiliser un mot de passe pour se connecter à Cloud Identity. Désactivez la réutilisation des mots de passe et surveillez le niveau de sécurité des mots de passe pour les utilisateurs qui se connectent à Cloud Identity, en particulier les comptes super-administrateur. |
| Définir des règles à l'échelle de l'organisation pour l'utilisation des groupes | Par défaut, les comptes utilisateur externes peuvent être ajoutés aux groupes dans Cloud Identity. Nous vous recommandons de configurer les paramètres de partage afin que les propriétaires de groupe ne puissent pas ajouter de membres externes. Notez que cette restriction ne s'applique pas au compte super-administrateur ni aux autres administrateurs délégués disposant d'autorisations d'administrateur de Groupes. Étant donné que la fédération de votre fournisseur d'identité s'exécute avec des droits d'administrateur, les paramètres de partage de groupe ne s'appliquent pas à cette synchronisation de groupe. Nous vous recommandons de vérifier les contrôles du fournisseur d'identité et du mécanisme de synchronisation pour vous assurer que les membres externes au domaine ne sont pas ajoutés aux groupes ou pour appliquer des restrictions de groupe. |
Étapes suivantes
- Découvrez la structure de l'organisation (document suivant de cette série).