CICD-SEC-2 : gestion des identités et des accès inadéquate

Deuxième entrée du Top 10 OWASP CI/CD. Libellé officiel : Inadequate Identity and Access Management. Le risque ne vient pas d’un mécanisme d’authentification cassé mais d’un problème de nombre : une chaîne de livraison ordinaire contient des centaines d’identités, humaines et programmatiques, réparties sur des systèmes qui n’ont ni le même modèle d’autorisation, ni la même méthode d’approvisionnement, ni le même annuaire.

→ Lire l’explication complète de la marmotte

Le mécanisme : six façons de perdre le compte

Le référentiel part d’un fait de culture : le compte moyen d’un gestionnaire de code source ou d’un outil d’intégration continue est très permissif, ces systèmes n’ayant pas été historiquement un terrain des équipes de sécurité et servant des gens qui doivent modifier largement le code. Sur ce terrain, six familles.

Les identités trop permissives. Garantir que chaque identité n’a que les droits nécessaires, sur les seuls dépôts qu’elle doit atteindre, n’est pas trivial : c’est l’écart entre le moindre privilège théorique et le pratique, sur un système où le droit par défaut est large.

Les identités dormantes. Employés partis, systèmes décommissionnés, prestataires en fin de mission, dont les comptes humains et programmatiques n’ont jamais été retirés de tous les outils : les comptes orphelins, et le geste correspondant, auditer les comptes orphelins d’un annuaire.

Les identités locales. Un système non fédéré avec le fournisseur d’identité central crée des comptes gérés sur place, soustraits à la politique de mots de passe, au verrouillage, au second facteur et surtout au départ d’un salarié. Famille la plus dangereuse, parce qu’invisible depuis l’annuaire.

Les identités externes. Deux cas : le salarié enregistré avec une adresse d’un domaine que l’organisation ne possède pas, dont la sécurité dépend d’un compte personnel hors de sa prise ; et le collaborateur extérieur, qui fait dépendre le niveau de sécurité du système de celui de son propre poste, cas traité par l’accès des prestataires en modèle zéro confiance.

Les identités auto-enregistrées. Là où l’auto-inscription est ouverte, une adresse du bon domaine suffit souvent à entrer, et une permission de base différente de « aucune » élargit la surface d’un coup. Les précédents sont publics : le code source de Mercedes-Benz, parti d’un GitLab auto-hébergé exposé sur Internet et ouvert à l’auto-inscription ; un GitLab d’une administration de l’État de New York, exposé de même, qui stockait des secrets ; et le serveur TeamCity de Stack Overflow, où les comptes nouvellement enregistrés recevaient des privilèges d’administration.

Les identités partagées. Un compte employé par plusieurs personnes, plusieurs applications ou les deux multiplie l’empreinte de ses identifiants et supprime la responsabilité nominative : les comptes partagés et, côté humain, le mot de passe partagé entre pragmatisme et risque. À l’enquête, cette famille coûte le plus cher : on sait ce qui a été fait, pas par qui.

Un dernier facteur aggrave l’ensemble : la diversité des méthodes d’accès. Mot de passe, jeton personnel, application de place de marché, application OAuth, greffon, clé SSH, chacune avec son cycle de vie. Un inventaire qui ne couvre pas tous les accès programmatiques ne couvre rien, et l’héritage des permissions brouille encore le calcul.

Ce que l’attaquant obtient

Le référentiel formule l’impact sans précaution : dans cet état, compromettre presque n’importe quel compte sur presque n’importe quel système confère des capacités puissantes et sert de passage vers la production. L’attaque sur Gentoo Linux, où du code malveillant a été ajouté après compromission du mot de passe d’un mainteneur, en est l’illustration minimale : un compte, un mot de passe, une distribution.

Ce qui rend cette entrée structurante, c’est qu’elle fixe le coût de toutes les autres. Un droit d’écriture excédentaire sur un dépôt devient l’exécution de pipeline empoisonnée de CICD-SEC-4 ; un compte de service oublié devient le chemin sans deuxième relecture de CICD-SEC-1. L’inadéquation des accès n’est pas un risque parallèle aux neuf autres : c’est leur facteur multiplicateur.

Ce qu’on peut détecter, et par quoi

L’écart entre droits accordés et droits employés. La mesure la plus informative du domaine, et elle est calculable : pour chaque identité, son fournisseur, le niveau accordé, le niveau réellement exercé sur quelques mois. L’écart dit quoi retirer, et désigne au passage les identités dormantes sans qu’on ait eu à définir « dormante ».

Les adresses hors domaine et les comptes locaux. Deux requêtes périodiques sur l’ensemble des systèmes : les comptes dont l’adresse n’appartient pas à un domaine géré par l’organisation, et la différence entre la liste des utilisateurs de chaque outil et l’annuaire. Les détections sont simples ; le retrait est politique.

Les créations de comptes. Une création suivie aussitôt d’une permission d’administration est le motif exact de l’incident TeamCity : règle courte, volume faible. Et une authentification programmatique depuis un contexte nouveau reste un signal exploitable, du genre décrit dans la détection du voyage impossible.

Ce que le défenseur fait

Cartographier en continu, pas une fois. Le référentiel demande une analyse continue de toutes les identités de tous les systèmes, couvrant explicitement toutes les méthodes d’accès programmatique. Un inventaire annuel d’un parc qui change chaque semaine n’est pas un inventaire.

Fédérer, et refuser les comptes locaux. Mesure de plus fort rendement : elle règle d’un coup la politique de mots de passe, le second facteur et le départ d’un salarié. Les cas où elle est impossible s’assument comme des exceptions, avec un propriétaire nommé.

Interdire l’auto-inscription, et ne pas accorder de permission de base à tous les utilisateurs d’un système ni aux grands groupes d’affectation automatique : deux lignes de configuration qui ferment trois des incidents cités plus haut. Borner les accès extérieurs dans le temps, avec une date d’expiration et un compte désactivé en fin de mission : la logique de l’accès juste à temps transposée aux prestataires.

Un compte dédié par contexte, jamais partagé. Pour les identités de machines, majorité silencieuse de cette entrée : gouverner les comptes de service, le Top 10 OWASP des identités non humaines et, pour Git, les comptes de service à révoquer réellement.

Une revue d’accès qui aboutit à des retraits, pas à une attestation : mettre en place une revue d’accès périodique. Et pour les comptes à droits larges, FIDO2, le vol d’identifiants restant la tactique la plus rentable d’ATT&CK.

Sources

CICD-SEC-2: Inadequate Identity and Access Management, OWASP Top 10 CI/CD Security Risks, 2022 : définition, six familles, recommandations.
Références citées par le document : la compromission du serveur TeamCity de Stack Overflow, les fuites de code source de Mercedes-Benz et d’une administration de l’État de New York par auto-inscription, et l’ajout de code malveillant dans Gentoo Linux après compromission du compte d’un mainteneur.

🐝 Ce qui arrive si on s’en passe

Le premier coût est invisible et permanent : l’organisation ne sait pas répondre à « qui peut écrire dans ce dépôt ». Elle sait répondre pour les comptes nominatifs de l’annuaire, donc pour la partie du problème déjà sous contrôle ; les jetons personnels, les clés SSH déposées il y a trois ans, les applications OAuth installées un après-midi et les comptes locaux d’un outil auto-hébergé restent hors du tableau. Le second coût arrive avec l’incident : les identités étant partagées et les accès programmatiques mal attribués, l’enquête décrit une séquence sans désigner un compte, et la remédiation se fait à l’aveugle, avec ses deux issues classiques, renouveler tout et arrêter la production, ou renouveler ce qu’on connaît et laisser subsister l’accès de l’attaquant dans le reste. Quant au départ d’un salarié, il ne ferme rien : son compte d’annuaire est désactivé le jour même, son jeton d’accès au code source continue de fonctionner, faute d’avoir jamais été rattaché à lui.

🦫 Explication de la marmotte 🍫

Pour fabriquer un logiciel, une entreprise relie plusieurs outils : un dépôt de code, un système qui assemble et teste, un entrepôt pour les paquets, des machines de déploiement. Chacun a sa liste d’utilisateurs, et chacun accepte plusieurs façons de s’identifier : un mot de passe, mais aussi des jetons, des clés, des applications connectées.

Le défaut décrit ici n’est pas qu’une porte soit mal fermée : c’est qu’on ait perdu le compte des clés. Les cas se répètent d’une entreprise à l’autre. Des comptes de personnes parties restent actifs. Des outils installés en interne gardent leurs propres mots de passe, hors du système central, donc hors des règles communes et hors des départs. Des salariés se sont inscrits avec une adresse personnelle, si bien que la sécurité du compte professionnel dépend d’une boîte aux lettres que l’entreprise ne contrôle pas. Certains outils acceptent l’inscription libre. Et des comptes partagés rendent impossible de dire plus tard qui a fait quoi.

La conséquence est qu’il suffit de prendre le contrôle de presque n’importe quel compte, sur presque n’importe quel outil, pour disposer d’un chemin vers les serveurs qui servent les clients. Ce n’est donc pas un sujet à part : c’est ce qui décide du prix de toutes les autres faiblesses. Les mesures utiles sont peu nombreuses : rattacher tous les outils au système d’identité central, interdire l’inscription libre, borner dans le temps les accès extérieurs, un compte par usage, et compter les clés programmatiques aussi sérieusement que les comptes de personnes.

Pages voisines

La citent

CICD-SEC-2 : gestion des identités et des accès inadéquate

Elle cite

: les deux pages se citent l’une l’autre.

CICD-SEC-2 : gestion des identités et des accès inadéquate

CICD-SEC-2 : gestion des identités et des accès inadéquate

Le mécanisme : six façons de perdre le compte

Ce que l’attaquant obtient

Ce qu’on peut détecter, et par quoi

Ce que le défenseur fait

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines