MOHAMEDFHAFAH

L'authentification unique (SSO) signifie que l'application (le fournisseur de service, SP) fait confiance à un fournisseur d'identité (IdP) pour authentifier les utilisateurs : elle ne manipule jamais leurs mots de passe. Entra ID peut jouer l'IdP de GitLab avec SAML 2.0 ou avec OpenID Connect (OIDC).

Ce qui les distingue

• SAML 2.0 échange des assertions XML signées via le navigateur. Il est installé de longue date dans les applications d'entreprise, et c'est celui que j'ai utilisé dans mon projet d'équipe.
• OIDC est une couche au-dessus d'OAuth 2.0 : l'application reçoit un jeton d'identité signé (un JWT) et appelle des points d'accès standard. Il est plus léger à mettre en œuvre et convient aux applications web modernes, mobiles et mono-page.

Ce qu'il faut réellement entretenir

• SAML : les certificats de signature (et leur renouvellement), le format du NameID, la correspondance des attributs et des groupes.
• OIDC : les secrets client (et leur renouvellement), les URI de redirection exactes, les portées et revendications demandées.

Le provisionnement est une autre question

Le SSO ne gère que la connexion. Créer, mettre à jour et désactiver les comptes relève de SCIM. Dans mon projet, le duo était SAML pour la connexion et SCIM pour le cycle joiner-mover-leaver. Les fonctions de provisionnement et de synchronisation des groupes disponibles dépendent de l'édition de GitLab : il faut consulter la documentation de l'édition utilisée.

Causes fréquentes d'échec

• Un certificat ou un secret expiré, ou renouvelé d'un seul côté.
• Un NameID ou un attribut e-mail qui ne correspond pas au compte existant.
• Un décalage d'horloge entre les deux systèmes, qui invalide les assertions de courte durée.
• Des groupes mappés dans un seul sens, ce qui fait dériver les rôles.

Comment je choisirais

OIDC pour une nouvelle application ou une pile moderne ; SAML quand l'application ne gère que lui ou qu'une fédération SAML existe déjà. Dans les deux cas : imposer le SSO, supprimer les mots de passe locaux quand c'est possible, et déprovisionner par SCIM pour que les départs perdent leurs accès.

Dans Active Directory, tout utilisateur authentifié peut demander au contrôleur de domaine un ticket de service Kerberos pour un compte qui possède un nom de principal de service (SPN). Une partie de ce ticket est chiffrée avec une clé dérivée du mot de passe du compte de service. L'attaquant emporte le ticket et tente de deviner le mot de passe hors ligne, sans autre trafic vers le domaine.

Pourquoi ça marche

• Aucun privilège particulier n'est nécessaire pour demander le ticket.
• Les comptes de service ont souvent des mots de passe faibles, anciens ou jamais renouvelés.
• Les tickets chiffrés en RC4 (type de chiffrement 0x17) sont les moins coûteux à casser.

Détection

• L'événement Windows 4769 (un ticket de service Kerberos a été demandé), filtré sur le type de chiffrement RC4 0x17.
• Un même compte qui demande des tickets pour de nombreux SPN différents en peu de temps.
• Un compte leurre avec un SPN qu'aucun vrai service n'utilise : toute demande le concernant est suspecte.

Durcissement

• Comptes de service gérés par groupe (gMSA) : mots de passe longs et aléatoires gérés et renouvelés par Active Directory.
• Mots de passe longs et aléatoires pour les comptes de service qui ne peuvent pas être des gMSA.
• N'autoriser qu'AES et désactiver RC4 pour Kerberos là où les applications le permettent.
• Aucun SPN sur les comptes privilégiés, et un modèle d'administration en tiers, pour qu'un compte de service cassé ne mène pas à l'administrateur du domaine.

Son proche cousin

L'AS-REP roasting vise les comptes dont la pré-authentification Kerberos est désactivée : l'attaquant n'a besoin que du nom du compte pour demander de quoi le casser, sans connaître aucun mot de passe. La correction consiste à repérer ces comptes et à réactiver la pré-authentification. Dans mon lab, j'ai pratiqué les deux attaques, puis remédié avec un modèle d'administration en tiers et des objets de stratégie de groupe.

L'ISO/IEC 27002:2022 regroupe les mesures technologiques au chapitre 8. Deux comptent surtout pour une plateforme Git comme GitLab : la 8.2 (droits d'accès privilégiés) et la 8.4 (accès au code source).

8.2, droits d'accès privilégiés

• Garder peu d'administrateurs et de propriétaires, chacun avec un compte d'administration distinct.
• Accorder les droits élevés pour une durée limitée et un motif, puis les retirer (l'idée de la gestion des accès à privilèges).
• Revoir les comptes privilégiés à intervalle régulier, et journaliser ce qu'ils font.

8.4, accès au code source

• Donner l'accès aux dépôts par rôle et par besoin, via des groupes plutôt qu'à titre individuel.
• Protéger les branches principales et exiger une relecture avant fusion.
• Gouverner les jetons et comptes de service qui lisent ou écrivent le code : ce sont aussi des identités.
• Imposer le SSO et déprovisionner automatiquement, pour que le départ de l'organisation supprime les accès.

Ce que j'en ai fait

Dans mon projet d'équipe, la politique d'accès pour une PME MedTech était alignée sur ces deux mesures, avec les exigences HDS et RGPD. Le PAM a été traité au niveau de la politique et d'un comparatif d'éditeurs (Entra ID, Okta, BeyondTrust, CyberArk), pas par un déploiement.