OCI Identity Domains : quand les frontières d’autorisation laissent passer des clés d’API

Analyse technique de la vulnérabilité publiée par NetSPI le 13 octobre 2026 — mise à jour au 5 novembre 2026.

Un utilisateur disposant du rôle User Manager dans Oracle Cloud Infrastructure (OCI) pouvait créer une clé API pour le compte d'un Identity Domain Administrator. Cette opération lui permettait ensuite de s'authentifier auprès des API OCI sous l'identité de cet administrateur, sans connaître son mot de passe ni disposer de ses facteurs MFA.

La vulnérabilité, découverte par Scott Weston, chercheur chez NetSPI, a été corrigée par Oracle en juin 2026, avant sa divulgation publique le 13 octobre.

L'intérêt technique de cette découverte dépasse le produit concerné. Elle montre comment deux modèles d'autorisation, individuellement cohérents, peuvent laisser apparaître un chemin d'élévation de privilèges lorsqu'ils contrôlent des opérations équivalentes.

1. OCI IAM et Identity Domains : deux modèles d'autorisation qui coexistent

Pour comprendre la vulnérabilité, il faut distinguer deux mécanismes d'autorisation d'Oracle Cloud Infrastructure.

Le premier est le modèle classique OCI IAM, fondé sur des politiques qui associent des groupes, des actions et des ressources. Une politique peut, par exemple, autoriser un groupe à administrer les utilisateurs d'un compartiment :

Allow group MyGroup to manage users in MyCompartment

Le second est celui des Identity Domains, qui organisent les utilisateurs, groupes, applications, configurations d'authentification et rôles administratifs dans des domaines d'identité. Ces domaines disposent de rôles prédéfinis, notamment Identity Domain Administrator, User Administrator et User Manager.

Cette distinction n'implique pas une séparation absolue des API : les permissions issues des politiques OCI IAM peuvent également intervenir sur des opérations de l'API Identity Domains.

Le domaine Default possède notamment une particularité importante. Les opérations classiques de l'API OCI IAM fonctionnent avec les utilisateurs de ce domaine, tandis que les domaines non-Default nécessitent l'API Identity Domains basée sur SCIM pour les opérations concernées.

Oracle documente cette architecture dans Oracle documente cette architecture dansManaging Identity Domains et AppRole Permissions.

2. Le scénario NetSPI : d'un User Manager à un Identity Domain Administrator

Le rôle Identity Domain Administrator dispose des privilèges d'administration les plus élevés à l'intérieur de son domaine d'identité. Le rôle User Manager, lui, permet de gérer tout ou partie des utilisateurs, notamment leurs états, leurs mots de passe et certains mécanismes d'authentification, sous réserve des restrictions applicables.
Cette délégation ne devrait pas autoriser un gestionnaire d'utilisateurs à prendre le contrôle d'un administrateur du domaine.

NetSPI a commencé par vérifier cette frontière. Les tentatives de modification d'un compte Identity Domain Administrator, notamment de son adresse électronique ou de son mot de passe, étaient bloquées. Le modèle d'autorisation protégeait donc certaines opérations sensibles.

Le chercheur s'est ensuite intéressé à un autre élément rattaché à l'utilisateur : ses identifiants techniques, et plus précisément ses clés de signature API.

Une clé API n'est pas un simple attribut utilisateur

Les API OCI utilisent notamment des signatures cryptographiques RSA. Le titulaire possède une clé privée et enregistre la clé publique correspondante auprès d'OCI. Une requête signée peut ensuite être authentifiée à l'aide de la clé enregistrée, du fingerprint et des identifiants OCI associés.

Si un tiers est autorisé à rattacher sa propre clé publique au compte d'un administrateur, il peut signer des requêtes avec sa clé privée et les faire authentifier comme provenant de cet administrateur.

L'opération problématique utilisait la ressource SCIM suivante :

POST /admin/v1/ApiKeys

L'API permet de gérer les clés associées aux utilisateurs du domaine. Dans le scénario identifié, le User Manager pouvait créer une clé en désignant le compte de l'Identity Domain Administrator comme propriétaire, alors qu'il ne pouvait pas modifier directement les attributs protégés de cet administrateur.

La chaîne d'élévation de privilèges

Compte A
Rôle : User Manager
|
| AppRole Identity Domain
v
Identity Domains SCIM API
/admin/v1/ApiKeys
|
| Création d'une clé associée au compte B
v
Compte B
Rôle : Identity Domain Administrator
|
| Authentification API par signature
v
Requêtes exécutées sous l'identité du compte B

Le chercheur précise que le compte de moindre privilège ne bénéficiait pas de politiques OCI IAM classiques lui accordant cette administration. Le chemin reposait sur les permissions du rôle Identity Domain.

NetSPI a également observé des possibilités de création d'autres types d'identifiants, notamment des Auth Tokens et des identifiants SMTP. Ces observations soulignent l'intérêt d'examiner toutes les formes d'authentification associées à une identité, sans présumer qu'elles ont toutes été affectées ou corrigées de manière identique.

La vulnérabilité ne nécessitait donc ni accès anonyme ni compromission préalable du compte administrateur : elle exploitait une délégation existante, dont le périmètre de sécurité était insuffisamment respecté.

3. Pourquoi cette élévation de privilèges est particulièrement intéressante

Le problème ne se résume pas à un rôle excessivement permissif. Il apparaît dans la manière dont une opération sur les credentials peut modifier les possibilités d'action d'une autre identité.

Trois contrôles doivent être distingués.

L'autorisation d'administrer un utilisateur détermine qui peut modifier son profil, son état ou certains facteurs d'authentification.

L'autorisation de gérer ses identifiants techniques détermine qui peut créer, consulter ou supprimer des mécanismes permettant de s'authentifier sous cette identité.

L'autorisation des actions ultérieures détermine les ressources auxquelles les requêtes authentifiées peuvent accéder.

Dans le cas documenté, la protection du premier contrôle ne suffisait pas à garantir celle du deuxième. Le troisième héritait ensuite des permissions de l'identité cible.

Il faut toutefois distinguer un Identity Domain Administrator d'un administrateur global de tenancy. Le premier possède des droits étendus dans son domaine, mais pas nécessairement tous les privilèges sur les ressources de l'infrastructure OCI. L'impact réel dépend des autres politiques et permissions attachées au compte compromis.

Une persistance indépendante de la connexion interactive

Une clé de signature API peut rester utilisable indépendamment d'une session web et de son expiration. Le renouvellement du mot de passe ou l'existence d'un MFA pour la console ne révoquent pas automatiquement une clé API déjà enregistrée.

Le scénario illustre la technique MITRE ATT&CK T1098.001 — Additional Cloud Credentials, qui consiste à ajouter des identifiants contrôlés par un acteur à un compte cloud existant. Cela peut permettre une persistance et, lorsque le compte cible dispose de permissions supérieures, une élévation de privilèges.

L'enseignement est important : sécuriser l'authentification interactive d'un administrateur ne garantit pas que toutes les autres méthodes d'authentification associées à son compte sont correctement protégées.

4. La correction Oracle et les limites de ce qu'elle garantit

NetSPI a transmis sa découverte à Oracle le 9 mars 2026. Après plusieurs échanges, Oracle a indiqué qu'un correctif avait été déployé le 4 juin. Le chercheur a toutefois reproduit le problème le 7 juin, avant qu'Oracle applique une correction supplémentaire le 8 juin. Le 10 juin, la vulnérabilité n'était plus reproductible dans son environnement.

Le point essentiel est la portée de cette correction.

D'après NetSPI, Oracle a corrigé le chemin d'élévation fondé uniquement sur les permissions AppRole. Cela ne signifie pas qu'il est désormais impossible de créer une clé API pour un autre utilisateur dans toutes les circonstances.

Une identité disposant de permissions OCI IAM suffisantes peut toujours légitimement administrer les credentials d'autres utilisateurs, conformément aux règles du service. La correction vise la traversée non autorisée de la frontière entre rôles d'Identity Domains et permissions d'administration.

Au 5 novembre 2026, l'analyse publique de NetSPI permet d'établir cette chronologie, mais aucun identifiant CVE ni avis Oracle spécifique détaillant une version de correctif n'a pu être confirmé indépendamment. Il ne faut donc pas assimiler cette correction côté service cloud à un correctif logiciel que chaque client devrait nécessairement installer.

5. Que vérifier dans un environnement OCI ?

La documentation officielle Oracle fournit plusieurs mécanismes utilisables pour contrôler l'exposition des comptes et examiner les opérations sensibles.

Vérifier les rôles et les politiques. Examiner les attributions User Manager, User Administrator et Identity Domain Administrator, ainsi que les politiques OCI IAM autorisant la gestion des utilisateurs. Le périmètre doit inclure les domaines d'identité et les permissions héritées des groupes.

Inventorier les clés API des comptes privilégiés. Oracle permet de consulter les clés d'un utilisateur depuis son domaine d'identité, dans la rubrique Users > API keys. Les fingerprints présents doivent correspondre à des usages identifiés et approuvés.

Examiner les événements d'administration. Le service OCI Audit enregistre les appels aux API publiques prises en charge, notamment leur date, leur origine, l'action et la réponse. Il faut rechercher les créations de credentials et rapprocher l'identité à l'origine de l'action du compte auquel la clé a été associée.

Révoquer les clés non autorisées. Oracle documente la suppression d'une clé de signature API depuis le compte utilisateur. Une fois supprimée, elle ne peut plus servir à authentifier des requêtes API. Cette opération doit être coordonnée avec les équipes responsables des intégrations afin d'éviter toute interruption involontaire.

Les procédures officielles sont disponibles Les procédures officielles sont disponibles dans Listing API Keys,Deleting an API Signing Key et Overview of Audit.

Oracle précise également que les anciens endpoints AuditEvents des Identity Domains ne reçoivent plus de nouvelles données depuis décembre 2024. Les vérifications contemporaines doivent s'appuyer sur OCI Audit, conformément à la documentation du fournisseur.

6. La véritable frontière d'autorisation est au niveau de l'action

L'analyse de NetSPI met en évidence une difficulté classique de l'architecture IAM : les droits administratifs sont souvent étudiés à travers des rôles, des groupes ou des catégories d'opérations, alors que l'impact de sécurité dépend de l'action concrète, de sa cible et de ses effets.

Une opération de création de clé devrait notamment être évaluée à partir de plusieurs informations :

Subject : identité initiant l'opération
Action : création d'un identifiant API
Resource : compte cible
Target role : privilèges du compte cible
Credential : type de mécanisme créé
Authority : source de la permission invoquée
Domain : frontière administrative concernée
Decision : permit / deny

Ce modèle est une grille d'analyse architecturale, pas une description du moteur interne d'Oracle.

Il permet d'exprimer une règle de sécurité que le seul nom de rôle ne suffit pas à garantir : un utilisateur autorisé à gérer certains comptes ne doit pas pouvoir leur ajouter un moyen d'authentification si cette opération lui permet d'hériter de privilèges qu'il ne possède pas.

Une décision cohérente doit également être appliquée sur toutes les interfaces exposant une même capacité sensible. Une restriction présente dans la console ou sur l'endpoint de modification d'un utilisateur ne doit pas disparaître lorsqu'une autre API intervient sur ses credentials.

C'est précisément l'intérêt d'une approche d'autorisation fine, capable de distinguer le sujet, l'action, la ressource et le contexte. Elle peut s'appuyer sur des modèles RBAC, ABAC ou sur des politiques explicites, à condition que les contrôles soient réellement appliqués au bon endroit.

La multiplication des moteurs d'autorisation, des API historiques et des mécanismes de délégation rend cette cohérence plus difficile à démontrer. Elle impose de raisonner sur les chemins d'accès complets, et pas seulement sur la liste des privilèges déclarés.

Ce que cette vulnérabilité nous apprend sur l'IAM

La recherche publiée par NetSPI montre qu'une séparation administrative peut sembler correctement implémentée tant que l'on teste les opérations les plus visibles : modifier un utilisateur, réinitialiser son mot de passe ou lui attribuer un rôle. Pourtant, la création d'un nouvel identifiant technique peut produire un résultat équivalent à une prise de contrôle sans passer par ces opérations.

Les clés API, tokens et autres credentials ne sont pas de simples propriétés de l'utilisateur. Ils représentent des capacités d'authentification et doivent être protégés avec une rigueur proportionnelle aux privilèges qu'ils permettent d'exercer.

Le bon périmètre d'un audit IAM ne se limite donc ni aux rôles attribués ni aux écrans d'administration. Il doit comprendre les opérations sensibles, les API qui les exposent, les sources de permission acceptées et les conséquences réelles de chaque décision.

Pour prolonger cette réflexion sur les contrôles d'accès, nous avons détaillé nos approches en matière d'autorisation fine et dynamique ainsi que de sécurité des identités et des annuaires. Ces domaines de sécurité sont complémentaires, même si leurs contrôles techniques diffèrent selon les plateformes.

Source principale : Scott Weston, NetSPI, Administrating the Administrator, An OCI Identity Domains Permission Bypass, 13 octobre 2026. Les constats relatifs à la vulnérabilité proviennent de cette recherche ; les recommandations opérationnelles sont rapprochées de la documentation officielle Oracle citée dans l'article.