Passer au contenu principal
Toute la documentation

Gouvernance des identités et accès privilégiés

Gérez les demandes d’accès, les habilitations, les revues, les garde-fous des rôles et les accès privilégiés temporaires en conservant les preuves.

Parcours
  1. Définir le périmètreChoisissez le tenant, la ressource, le propriétaire, l’approbateur et le motif professionnel.
  2. Définir les garde-fousPrévisualisez les règles d’affectation et de séparation des tâches avant publication.
  3. Demander un accèsSoumettez une demande limitée, justifiée et assortie d’une durée, pour approbation indépendante.
  4. Certifier les accèsExaminez les affectations concernées, consignez les décisions et vérifiez les mesures correctives.
  5. Mettre fin aux privilègesLaissez expirer ou révoquez les accès temporaires, puis vérifiez les preuves d’audit.

Demandes et approbation

Les demandes précisent le tenant, la ressource, le rôle ou l’habilitation, le motif et la période de validité. La création et l’approbation sont distinctes ; l’auto-approbation et les cibles inter-tenants sont bloquées lorsque nécessaire. Une demande refusée ou expirée ne donne aucun accès. Les approbateurs s’appuient sur le besoin consigné et le résultat des règles, pas sur des messages informels.

  1. Demandez la ressource exacte et indiquez le motif et la date de fin.
  2. Transmettez la demande à un approbateur indépendant autorisé et vérifiez que sa décision est consignée.
  3. À la fin de l’intervention, révoquez l’accès et vérifiez que l’affectation est inactive.

Habilitations et packages

Les catalogues et packages prennent en charge les brouillons versionnés, la publication et le retour arrière sous forme d’une nouvelle version. Les affectations à un utilisateur ou à un groupe peuvent expirer et nécessitent une décision indépendante. Les modes historiques ou réservés aux personnes affectées suivent les règles d’application publiées. Les packages ne supplantent ni les limites des tenants ni les règles de séparation des tâches (SoD).

  1. Avant toute modification, vérifiez le contenu du package, son propriétaire et l’application cible.
  2. Validez et publiez la version examinée, puis confirmez qu’elle est active.
  3. Demandez l’affectation en précisant le motif et l’expiration, puis vérifiez son état.

Hiérarchie des rôles et séparation des tâches

La hiérarchie des rôles et les règles de séparation des tâches limitent les combinaisons d’accès. Simulez et versionnez les règles ; toute exception fait l’objet d’une demande, d’une approbation indépendante et d’une révocation distinctes. Changer un parent peut affecter ses descendants. N’élargissez jamais un rôle pour contourner un conflit ; limitez les exceptions et leur durée.

  1. Simulez la combinaison de rôles envisagée par rapport aux règles actuelles du tenant.
  2. Publiez les règles examinées et vérifiez les conflits attendus.
  3. Demandez toute exception en précisant le motif et la durée ; révoquez-la dès qu’elle n’est plus nécessaire.

Revues et campagnes

Les revues d’accès certifient les appartenances et les affectations. Les campagnes définissent une population, des réviseurs et une échéance ; les réviseurs statuent sur chaque élément. La décision et sa révocation ultérieure sont deux états distincts. Suivez les retards dans l’état de la campagne : l’absence de réponse ne vaut pas approbation.

  1. Créez une campagne pour le tenant avec des réviseurs responsables et une échéance.
  2. Confirmez ou révoquez chaque élément selon le besoin actuel et consignez les motifs.
  3. Vérifiez la fin de la campagne et la mesure corrective sur l’affectation elle-même.

PIM, authentification renforcée et accès d’urgence

L’éligibilité PIM ne signifie pas qu’un privilège est actif. L’activation peut nécessiter un motif, une durée, une approbation et une authentification renforcée récente, liée à l’utilisateur ou résistante à l’hameçonnage. Maintenez les contrôles de protection. Le mécanisme break-glass possède son propre défi et sa piste d’audit ; il ne sert pas à contourner habituellement l’absence de rôle ou de facteur.

  1. Vérifiez l’éligibilité, le facteur et la période d’activation autorisée.
  2. Effectuez réellement l’authentification renforcée et confirmez le rôle actif et son expiration.
  3. Terminez ou laissez expirer l’accès, puis examinez la session privilégiée et l’audit.

Workflows et preuves

Les workflows de cycle de vie prennent en charge les déclencheurs, actions, versions, approbations, déploiements progressifs, retours arrière et suivis d’exécution. Validez et effectuez un essai à blanc lorsque cette option existe. Selon les autorisations, les exécutions peuvent être mises en pause, reprises, annulées, rejouées ou approuvées. Les exports d’audit, règles de conservation et mises sous séquestre juridique encadrent les preuves ; préservez l’historique lors d’une correction.

  1. Validez le déclencheur et les actions, puis effectuez un essai à blanc et examinez son impact.
  2. Demandez l’approbation, préparez le déploiement progressif et publiez la version voulue.
  3. Surveillez l’exécution et évaluez les effets d’un doublon avant tout rejeu.

Questions fréquentes

Puis-je approuver ma propre demande ?

Non, lorsque le workflow exige un examen indépendant ; transmettez-la à un autre approbateur autorisé.

Une affectation de package est-elle immédiate ?

Elle peut attendre une approbation et reste soumise à l’appartenance, à l’expiration et aux règles.

Que faire si la SoD bloque l’accès ?

Examinez les preuves de simulation et demandez une exception limitée si les règles le permettent.

Un rôle PIM éligible est-il actif ?

Non. Activez-le avec l’authentification renforcée requise, puis vérifiez son expiration limitée.

La fin d’une revue révoque-t-elle l’accès ?

Vérifiez l’affectation séparément : la décision de revue et sa mise en œuvre corrective sont distinctes.

Puis-je supprimer des preuves d’audit après une erreur ?

Non. Corrigez par une nouvelle version ou un retour arrière et préservez l’historique d’audit et les mises sous séquestre.

Pages associées