Cloud Identity comme IdP : domaine, cycle de vie, 2SV, SSO et Secure LDAP

Avant les applications et avant les données, il y a une question qui décide du reste : qui entre, avec quelles identifiants, et depuis où. Cloud Identity est le produit et le fournisseur d'identité (IdP) de Google, et « Introduction to Cloud Identity », de Google Skills, parcourt sa configuration complète, depuis l'instance fraîchement créée jusqu'au SSO des apps cloud et du LDAP legacy unifié. Le parcours qui suit couvre la création, le cycle de vie des utilisateurs, la sécurité, la gestion mobile, les domaines, les rapports et les deux cas d'affaires qui ferment le matériel.

La création : instance, domaine et source unique de vérité

Le départ a deux temps : créer l'instance Cloud Identity (les exercices utilisent une trial avec information de paiement, avec instructions pour annuler le compte à la fin de la formation) et personnaliser le profil de l'entreprise.

Et une décision de support qu'il vaut mieux adopter dès le début : le matériel déclare le Help Center de Cloud Identity comme source unique de vérité, et le propose comme premier niveau de support après la formation. Dans un produit d'identité, où chaque réglage affecte qui peut entrer, qu'il existe un seul endroit où ce qui est permis est écrit est plus précieux que n'importe quel raccourci.

Utilisateurs : licences, phases et cycle complet

Chaque utilisateur ajouté requiert une licence, ce qui fait du déploiement une décision par phases et pas un versement en vrac. La première phase ajoute les utilisateurs techniques d'IT, pour aligner les réglages sur les politiques du département avant d'élargir. Dans les exercices, l'administrateur contrôle les mots de passe initiaux : un mot de passe par défaut avec invitation à le changer à la première connexion, ou un mot de passe temporaire autogénéré.

Le cycle de vie complet d'un compte, tel que le parcourt le matériel, inclut les ajouts individuels et en masse, la synchronisation du répertoire avec Google Cloud Directory Sync (GCDS), les rôles d'administration et privilèges personnalisés, et les opérations courantes : réinitialiser le mot de passe, renommer, suspendre, supprimer et restaurer un utilisateur récemment supprimé. Autour des comptes vivent les unités organisationnelles (OU) et les groupes gérés, qui sont la structure sur laquelle s'accrochent ensuite les politiques.

GCDS : synchroniser sans toucher le répertoire cible

Pour migrer de grands volumes d'utilisateurs, Google Cloud Directory Sync synchronise le domaine Google avec les répertoires Microsoft Active Directory ou LDAP existants. Il déplace les utilisateurs existants, les utilisateurs partagés, les contacts, les groupes et les licences, et une garantie qui compte quand on planifie la migration : les données du répertoire cible ne sont jamais modifiées.

2SV : trois niveaux et une méthode préférée

Le matériel ouvre le chapitre sécurité avec le motif : les mots de passe compromis sont une source majeure de brèches, parce que l'attaquant qui les obtient garde les mêmes permissions que la victime. La vérification en deux étapes (2SV) combine quelque chose qu'on sait (le mot de passe) avec quelque chose qu'on a (une clé physique ou un code).

Les niveaux d'imposition sont trois : facultatif (l'employé décide), obligatoire avec la méthode choisie par l'employé et obligatoire avec clés de sécurité. En l'imposant pour le domaine ou une unité organisationnelle, on peut l'activer immédiatement ou à une date et heure précises, ce qui laisse du temps aux utilisateurs pour s'inscrire.

Sur les méthodes, le matériel est sans appel : les clés de sécurité sont la meilleure méthode, car elles reposent sur le standard ouvert FIDO développé par Google et ne requièrent qu'un navigateur compatible sur l'appareil. Google Prompt offre une meilleure expérience que la saisie d'un code, et les codes de secours imprimés servent aux zones à haute sécurité. Et un avertissement qui vaut pour toute l'industrie : le NIST a cessé de recommander la 2SV par SMS en raison du risque de SIM swap par des entités soutenues par des États.

La pratique qui accompagne l'imposition est aussi prête à copier : réviser la force des mots de passe, révoquer les mots de passe spécifiques aux applications si quelqu'un perd l'appareil et désactiver l'accès des applications peu sécurisées.

SSO avec trois routes, et LDAP unifié

Cloud Identity comme IdP supporte OpenID Connect (OIDC) et SAML 2.0, avec un grand catalogue d'apps SAML préintégrées. Les apps SAML personnalisées se configurent pour l'organisation qui les installe et n'entrent pas dans le catalogue général, et chaque app n'est assignée qu'aux organisations qui en ont besoin. Avec un IdP tiers, l'architecture se scinde : l'authentification de l'utilisateur se fait chez cet IdP, Cloud Identity administre les apps cloud du catalogue, et les utilisateurs ont besoin de comptes Cloud Identity pour utiliser le SSO.

flowchart TD
    U[Utilisateur] --> I{Où s'authentifie-t-il ?}
    I -->|Google comme IdP| G[Cloud Identity authentifie et administre]
    I -->|IdP tiers| T[L'IdP tiers authentifie ; Cloud Identity administre les apps]
    I -->|App SAML personnalisée| S[Configurée pour l'organisation installante]

Pour le côté legacy, Secure LDAP est « LDAP as a service » : un service géré par Google qui connecte les applications, services et infrastructures basés LDAP au répertoire Google. Le motif est toujours le même dans les entreprises avec historique : les apps legacy avec LDAP ou Active Directory coexistent des années avec le SaaS, et maintenir plusieurs répertoires ou serveurs de synchronisation duplique le travail, fragmente la sécurité, ajoute de la latence de synchronisation et fait monter le coût. Avec Secure LDAP, le répertoire Google devient la seule plateforme d'identité et d'accès, pour les apps SaaS (SAML/OpenID Connect) comme pour les LDAP, avec les mêmes identifiants Google pour entrer dans les applications on-prem et cloud ; et en tant que service géré, Google le configure et le maintient sous les mêmes SLA que les autres services.

Gestion mobile : basique par défaut, avancée par décision

La gestion mobile basique est activée par défaut et protège les données corporatives en exigeant le verrouillage de l'écran ou un passcode, avec effacement à distance des comptes corporatifs disponible. La gestion avancée donne plus de contrôle : mots de passe plus forts, restriction des réglages et fonctions de l'appareil, gestion des applications sur Android et iOS, et effacement de toutes les données de l'appareil.

Un détail qui évite les surprises : les données corporatives ne se synchronisent avec l'appareil que quand l'exigence de verrouillage de l'écran est remplie. Et la fonction qu'on apprécie en cas d'incident : la gestion avancée permet de localiser les appareils et d'exporter leurs détails sans agent installé. Les exercices du matériel couvrent la politique d'appareils, l'inscription d'un appareil dans le domaine et la gestion des appareils perdus et non conformes, justement pour éviter les accès non autorisés depuis un équipement égaré.

Domaines : 600, 20 alias et 599 séparés

Le domaine primaire se définit à l'inscription. Depuis la console, on peut ajouter jusqu'à 600 domaines au compte Google de l'organisation : jusqu'à 20 domain aliases, où les utilisateurs envoient du courrier avec l'adresse d'un autre domaine mais reçoivent sur le primaire, et jusqu'à 599 domaines séparés, chacun avec ses propres utilisateurs et adresses, collaborant en interne entre eux. Dans les deux cas, il faut être propriétaire du domaine et vérifier la propriété avec le domaine primaire. Et pour le SSO avec plusieurs domaines, la condition est que le système identifie l'utilisateur par adresse e-mail.

Rapports et alertes

La console de reporting organise l'information en trois blocques : Security (l'exposition du domaine aux brèches et quels utilisateurs posent risque), Account Activity (le rapport maître avec les données de pages de sécurité, d'usage et de highlights) et Audits (les logs d'activité).

Dedans, quatre rapports principaux : Highlights, un résumé d'activité (usage des apps, état des utilisateurs, quota de stockage, visibilité des documents et sécurité) ; Aggregate, avec tendances et données administratives (vérification, état du compte, administration et quotas) ; Security, avec les réglages de compte et l'exposition au risque, y compris comment les données sont partagées et accessibles ; et Account Activity, avec état du compte, activité et inscription à la vérification en deux étapes. Les auditeurs disponibles incluent l'admin audit log et le login audit log, et permettent de recevoir des alertes par e-mail à l'administrateur en cas d'activité suspecte.

Les deux cas d'affaires

Imposer le MFA. L'entreprise A, avec un IdP on-premises qui migre vers Cloud Identity comme IdP principal, applique les clés de sécurité obligatoires aux profils aux données les plus sensibles : les cadres, et les équipes d'ingénierie, de finances et de ressources humaines, ces dernières pour leur accès aux informations des employés. Pour le reste, 2SV obligatoire avec méthode libre, avec une date de conformité fixée par Infosec. Le critère est celui des profils, ni celui de l'ancienneté ni celui du titre nominatif.

SSO par unité organisationnelle. Le second cas démarre avec un inventaire d'apps cloud (collaboration, messagerie, conférence, CRM, RH et support), continue avec leur localisation dans le catalogue SAML, active le SSO une par une et se termine par l'assignation hiérarchique :

flowchart TD
    A[Inventaire d'apps cloud] --> C[Catalogue SAML préintégré]
    C --> D[Activation app par app]
    D --> E[Assignation par unité organisationnelle]
    E --> F[Niveau supérieur : messagerie, RH, collaboration]
    E --> G[Ventes : CRM]
    E --> H[Support : support]

Ce que le cadrage laisse et ce qui est resté non exécuté

Ce qui survit à l'interface, ce sont trois critères : l'identité comme plateforme unique (SaaS et legacy sous les mêmes identifiants), la 2SV différenciée par sensibilité du profil plutôt qu'une seule pancarte pour tous, et le SSO activé app par app et assigné par unité organisationnelle.

Ce qui est resté non exécuté dans cette documentation : les quatre quizzes du matériel n'ont ni été ouverts ni soumis, les exercices de la console n'ont pas été exécutés, une des dix vidéos ne publie ni transcription ni sous-titres sur sa page ni sur YouTube, et la description détaillée de l'unité de GCDS est restée partiellement en attente de vérification dans le matériel documenté (le contenu synchronisé et la garantie du répertoire cible sont bien vérifiés dans la transcription de la vidéo).

---

*Source : « Introduction to Cloud Identity », de Google Skills (cours google.cloud-identity).*