Vue d’ensemble de l’API Révisions d'accès

Les révisions d’accès Azure Active Directory (Azure AD) sont une fonctionnalité de la gouvernance des identités Azure AD qui permet de s’assurer que les identités (ou principaux) appropriées disposent de l’accès aux ressources appropriées dans l’organisation. Cette révision peut être implémentée par programme à l’aide de l’API d’avis d’accès dans Microsoft Graph.

Participants à une révision d’accès

Les révisions d’accès ont pour but d’attester ou de rectifier l’accès continu d’un principal à une ressource. Les principaux peuvent être des utilisateurs individuels, des groupes ou des applications.

Les ressources pour lesquelles l’accès peut être examiné incluent les groupes, les rôles privilégiés (y compris les rôles Azure AD et les rôles de ressources Azure), les packages d’accès et les applications.

Les relecteurs ou les attesteurs de la révision d’accès peuvent inclure les utilisateurs ou groupes d’utilisateurs suivants :

  • Un utilisateur (un utilisateur invité ou un membre) qui passe en revue son propre accès et confirme qu’il a besoin d’un accès continu.
  • Un autre utilisateur, par exemple, un administrateur dans un rôle d’administrateur de sécurité, en révision de l’accès pour d’autres principaux.
  • Le responsable d’un utilisateur attestant que ses rapports directs ont besoin d’un accès continu.
  • Membres d’un groupe.
  • Propriétaires de groupe, y compris les propriétaires qui peuvent répondre à des critères spécifiques.
  • Propriétaires d’applications.

Blocs de construction de l’API de révision d’accès

L’API révisions d’accès est structurée logiquement et se compose des blocs de construction suivants.

1. Définition de planification des révisions d’accès

Il s’agit du plan logique qui contient les paramètres d’une révision d’accès et ses instances. Ces paramètres sont les suivants :

  • Ressources accessibles.
  • Principaux qui accèdent à la ressource.
  • Relecteurs qui attestent de la nécessité pour les principaux de maintenir l’accès aux ressources.
  • Fréquence de la révision d’accès.
  • Étapes de la révision d’accès (pour une révision d’accès en plusieurs étapes).
  • Décisions par défaut à appliquer si les décisions ne sont pas enregistrées.

2. Instance de révision d’accès

Représente une activité de révision unique, ou occurrence, par rapport à laquelle les relecteurs prennent des décisions. Une définition de révision d’accès peut avoir plusieurs instances, comme c’est le cas dans les révisions périodiques. Les avis one-off ont exactement une instance. Pour une révision d’accès en plusieurs étapes, chaque instance contient jusqu’à trois étapes.

3. Élément de décision enregistré pour un avis

Représente une décision qu’un réviseur a prise sur une instance, y compris l’horodat et la justification de la décision. Chaque instance de révision a autant de décisions que le nombre de principaux à réviser. Si aucune décision n’est prise, c’est-à-dire que les relecteurs n’ont pas répondu à la révision, il n’y aura aucun objet de décision pour l’instance.

Les décisions recommandées générées par le système peuvent être fournies pour chaque élément de décision. Celles-ci sont basées sur la date de dernière signature du principal dont l’accès est en révision. Cette fonctionnalité donne aux réviseurs une visibilité sur les comptes dormants de l’organisation et recommande les décisions à appliquer concernant l’accès continu du principal.

Les révisions d’accès prennent également en charge l’audit des décisions prises sur chaque instance de révision d’accès, avec les décisions également téléchargeables pour l’audit hors connexion.

Étendue de l’appel de l’API d’avis d’accès

L’API d’avis d’accès prend en charge les contextes délégués et d’application .

Dans un contexte délégué (utilisateur), une application appelle l’API d’avis d’accès au nom d’un utilisateur. Les scénarios classiques sont les suivants :

  • Un administrateur utilise un script pour créer, lire ou mettre à jour une révision d’accès.
  • Un propriétaire de ressource utilise une application ou un script pour créer une révision d’accès pour une ressource dont il est propriétaire.
  • Un administrateur collecte automatiquement toutes les décisions relatives à une ou plusieurs révisions d’accès.

Dans un contexte d’application, une application appelle l’API d’avis d’accès sans qu’un utilisateur ne soit présent. Un scénario classique est un script en arrière-plan programmé qui collecte régulièrement des décisions pour toutes les révisions d’accès.

Étapes suivantes