Documentation sur Oracle Cloud Infrastructure

Utilisation des campagnes de révision d'accès dans Oracle Access Governance

Utilisez des campagnes pour lancer un processus de révision d'accès. Pour utiliser efficacement les évaluations d'accès, comprenez le cycle de vie de la campagne, ainsi que des concepts cruciaux, tels que l'autocertification des accès et le mécanisme de secours lorsqu'un réviseur ou un responsable non valide est détecté. Utiliser des directives ou des meilleures pratiques tout en travaillant avec des campagnes pour assurer un processus d'examen efficace.

Accéder aux étapes de la campagne de révision

En tant qu'administrateur ou administrateur de campagne, pour certifier les privilèges d'accès, configurez d'abord et programmez des campagnes de révision d'accès. Au cours de son cycle de vie, une campagne se déroule dans divers états de révision d'accès. Les tâches que vous pouvez effectuer dépendent de l'état ou du statut d'une campagne.

En tant qu'administrateur ou administrateur de campagne, lancez le processus de révision d'accès en créant une campagne à partir de la section Révisions d'accès. Vous pouvez configurer une campagne ad hoc ou programmer une campagne périodique, en formant une série de campagnes. Une campagne se déroule à différentes étapes ou états de son cycle de vie. Cela implique la définition de la portée, la définition des flux d'approbation, la sélection des responsables de campagne et la planification des campagnes. Une fois lancés, les réviseurs peuvent accepter ou révoquer les privilèges d'accès. Les décisions prises sont prises dans le cadre du processus de correction en boucle fermée.

Voici les états de certification des campagnes de révision d'accès :
Accéder aux étapes de la campagne de révision

  • Provisoire : Lorsqu'une nouvelle campagne de révision d'accès est créée ou ajoutée, mais pas encore lancée. À l'état Provisoire, vous pouvez :
    • Voir les détails de la campagne
    • Modifier une campagne
    • Supprimer une campagne
  • Programmé : Lorsqu'une campagne de révision d'accès est créée pour être lancée à un moment précis dans le futur. À l'état Programmé, vous pouvez :
    • Voir les détails de la campagne
    • Modifier une campagne
    • Cloner une campagne
    • Mettre fin à une campagne
    • Mettre fin à la série de campagnes
  • En cours : Lorsqu'une campagne de révision d'accès est lancée. Les réviseurs de campagne sont avisés de la campagne par courriel. Les réviseurs peuvent prendre des décisions sur les tâches d'évaluation affectées en acceptant ou en révoquant les privilèges d'accès pour finalement exécuter la décision dans le cadre du processus de correction en boucle fermée. À l'état En cours, vous pouvez :
    • Voir les détails de la campagne
    • Cloner une campagne
    • Mettre fin à une campagne
    • Mettre fin à la série de campagnes
    • Voir le rapport
    • Modifier la responsabilité de la campagne
    • Télécharger les données CSV
  • Prêt pour approbation : Lorsque les tâches de révision sont terminées ou que la date d'échéance de la campagne est écoulée, la campagne passe à l'état Prêt pour approbation. Si des éléments d'évaluation sont en attente, les actions suggérées dans le flux des travaux d'approbation sont automatiquement prises en compte. Par exemple, approuvez toutes les tâches de révision d'accès non révisées. À l'état Prêt pour approbation, vous pouvez :
    • Voir les détails de la campagne
    • Cloner une campagne
    • Mettre fin à une campagne
    • Mettre fin à la série de campagnes
    • Voir le rapport
    • Télécharger les données CSV
    • Modifier la responsabilité de la campagne
  • Approuvé : Lorsqu'un responsable de campagne approuve et approuve une campagne à partir de l'option Actions, elle est marquée comme Approuvée. La campagne passe de la file d'attente Mes campagnes en cours à la file d'attente Mes campagnes précédentes. À l'état Approuvé, vous pouvez :
    • Voir les détails de la campagne
    • Cloner une campagne
    • Voir le rapport
    • Télécharger les données CSV
  • Fin du système : Lorsqu'une erreur inattendue se produit, la campagne peut être abandonnée, ce qui entraîne le statut Fin du système. Avec le statut Terminé par le système, vous pouvez voir les détails de la campagne, cloner une campagne, voir le rapport ou télécharger le rapport CSV. Voici quelques causes possibles :
    • Lorsqu'une erreur système interne se produit, par exemple un échec de génération de données clés ou un échec de validation des critères de campagne.

    • Toutes les campagnes Provisoire et Programmées créées avant la version de juin 2023 sont automatiquement abandonnées et marquées comme Fin du système.

    • Lorsqu'une instance de service Oracle Access Governance est supprimée, toutes les campagnes de cette instance de service sont abandonnées et marquées comme Fin du système.
    • Lorsqu'une défaillance du système se produit lors de l'arrêt d'une campagne, celle-ci est abandonnée et passe à l'état Fin du système.
  • Interrompu : Lorsqu'une campagne est interrompue par un administrateur de campagne ou un responsable de campagne. Vous pouvez mettre fin à une campagne lorsqu'elle a l'état Programmée, En cours ou Prêt pour approbation. Une campagne prend également fin lorsque :
    • Le réviseur est inactif et la hiérarchie de gestion n'a pas d'utilisateur actif ou le responsable de la campagne est inactif.
    • Le processus de secours ne parvient pas à affecter un responsable ou un réviseur de campagne approprié. La campagne est interrompue par le système.
    • Le nombre de membres dans la collection d'identités est inférieur au nombre de réviseurs définis pour le flux de travail d'approbation de la collection d'identités.
    À l'état Terminé, vous pouvez :
    • Voir les détails de la campagne
    • Cloner
    • Voir le rapport
    • Télécharger les données CSV

Présentation des barrières d'autocertification

L'autocertification est un processus d'approbation ou de certification de vos propres droits d'accès sans l'intervention d'un réviseur externe. Il s'agit d'un processus d'affaires valide établi pour réduire le fardeau administratif ou pour d'autres justifications commerciales appropriées. Cependant, l'auto-certification n'est généralement pas recommandée pour les accès à haut risque impliquant des données critiques, ou lorsqu'un avantage personnel potentiel est impliqué. Oracle Access Governance vous permet d'activer ou de désactiver le processus d'autoapprobation.

Selon le type de flux de travail d'approbation, Oracle Access Governance active ou désactive les limites d'autocertification pour une campagne.
  • Si vous sélectionnez Utilisateur personnalisé, Collecte d'identités ou Responsable, vous pouvez choisir d'activer ou de désactiver le processus d'autocertification. Si vous choisissez le flux de travail Bénéficiaire, vous pouvez également approuver automatiquement vos accès.
  • Si vous sélectionnez un autre flux de travail ou choisissez de désactiver le processus d'autoapprobation, le système lance un mécanisme de secours approprié pour affecter automatiquement la tâche d'évaluation au prochain réviseur valide disponible.

Présentation du mécanisme de secours : Méthodes pour empêcher la cessation d'une campagne

Lors de l'utilisation de campagnes, vous choisissez votre réviseur prévu en sélectionnant l'un des modèles d'approbation définis dans la fonction Flux de travail d'approbation d'Oracle Access Governance. Le service Campagnes lancera un mécanisme de secours en cas de détection d'un réviseur non valide ou d'un responsable de campagne non valide pour empêcher la fin d'une campagne.

Voici quand Oracle Access Governance marque un réviseur comme non valide :
  • Lorsqu'une identité Oracle Access Governance Inactive est sélectionnée en tant que réviseur.
  • Lorsqu'une identité active avec le type d'utilisateur Consommateur est sélectionnée en tant que réviseur.
  • Lorsque l'autoapprobation est désactivée dans le modèle d'approbation sélectionné, et que le réviseur est le même que le bénéficiaire dont les accès sont en cours de révision ou de certification.

Mécanisme de secours pour un réviseur non valide

Si le réviseur prévu n'est pas valide, Oracle Access Governance lance le mécanisme de secours suivant, dans l'ordre indiqué, pour affecter un réviseur valide :

Réviseur invité → Chaîne de gestion du réviseur prévu → Responsable de la campagne → Tout utilisateur sélectionné au hasard ayant le rôle Administrateur de la gouvernance des accès.

  • Réviseur prévu
  • Gestionnaire immédiat du réviseur, jusqu'à la chaîne de gestion définie jusqu'à ce qu'un réviseur valide soit trouvé.
  • Si aucun gestionnaire actif n'est trouvé, le réviseur est défini en tant que responsable de la campagne.
  • Si l'auto-approbation n'est pas autorisée, qu'aucun gestionnaire actif n'est trouvé, que le responsable de la campagne est le bénéficiaire, alors tout utilisateur, choisi au hasard, avec les rôles Administrateur est automatiquement affecté en tant que réviseur de l'accès.

Mécanisme de secours pour un responsable de campagne non valide

Les responsables de campagne non valides peuvent être des utilisateurs inactifs, des utilisateurs consommateurs ou des utilisateurs qui ne font pas partie du flux d'approbation.

Si le responsable de campagne prévu n'est pas valide, Oracle Access Governance lance le mécanisme de secours suivant pour affecter un responsable de campagne valide :

Responsable de la campagne intensive → Chaîne de gestion du responsable de la campagne → Tout utilisateur, sélectionné au hasard, ayant le rôle Administrateur de la gouvernance des accès.

  • Chaîne de gestion du responsable de la campagne.
  • Si aucun gestionnaire valide n'est trouvé, tout utilisateur choisi au hasard avec le rôle Administrateur est automatiquement affecté en tant que responsable de la campagne.

Exemple 1 - Présentation du mécanisme de secours lorsque l'autocertification est permise

Scénario : En tant qu'administrateur de campagne et responsable de la campagne, Sarah lance les révisions périodiques d'accès aux identités pour son propre service. Elle sélectionne le modèle de flux de travail d'approbation du responsable et autorise l'autoapprobation des révisions d'accès. Il génère deux révisions d'accès, avec le type d'affectation Compte comme suit :
  • Bénéficiaire : John Doe et Responsable de compte en tant que Sarah
  • Bénéficiaire : Sarah et Responsable de compte en tant que Sarah
À l'aide du modèle Responsable avec l'autocertification activée, le réviseur prévu pour cette campagne sera le responsable du compte, comme suit :
  • Bénéficiaire : John Doe et Réviseur : Sarah
  • Le bénéficiaire est Sarah et le réviseur est Sarah

Exemple 2 - Comprendre le mécanisme de secours lorsque l'autocertification n'est pas autorisée

Scénario : En tant qu'administrateur de campagne et responsable de la campagne, Sarah lance les révisions d'accès aux identités ad hoc pour les fonctions critiques des applications à risque élevé de son service. Elle sélectionne le modèle de flux de travail d'approbation du responsable et ne permet pas l'autoapprobation des révisions d'accès. Il génère deux révisions d'accès, avec le type d'affectation Autorisation comme suit :
  • Bénéficiaire : John Doe et Responsable de l'autorisation en tant que Sarah
  • Bénéficiaire : Sarah et Responsable de l'autorisation en tant que Sarah
Comme l'autocertification est désactivée, le réviseur prévu pour cette campagne ne peut pas être le même que le bénéficiaire. Ainsi, un mécanisme de repli sera lancé comme suit :

Réviseur invité → Chaîne de gestion du réviseur prévu → Responsable de la campagne → Tout utilisateur sélectionné au hasard ayant le rôle Administrateur de la gouvernance des accès.

Supposons qu'aucun gestionnaire valide n'est trouvé dans la chaîne de gestion, puis que le responsable de la campagne suivante doit être affecté en tant que réviseur. Dans cet exemple, le responsable de la campagne est le même que le bénéficiaire dont l'autocertification est désactivée, puis le réviseur d'accès est choisi aléatoirement, avec le rôle Administrateur, qui dans cet exemple est Carol Beck. Les réviseurs d'accès seront donc les suivants :

  • Bénéficiaire : John Doe et Réviseur : Sarah
  • Beneficiary (Bénéficiaire) comme Sarah et Reviewer comme Carol Beck

Meilleures pratiques : Lignes directrices à prendre en compte lors de l'utilisation de campagnes

Lors de l'exécution de campagnes, vous devez respecter quelques bonnes pratiques et directives pour assurer un processus de révision d'accès efficace.

Voici quelques directives que vous devez respecter lors de l'exécution des campagnes :
  • Les campagnes ne peuvent être créées que par l'administrateur ou l'administrateur de campagne d'Oracle Access Governance.
  • Toutes les campagnes ne peuvent être gérées que par l'administrateur d'Oracle Access Governance. L'administrateur de campagne peut gérer les campagnes qu'ils ont créées. Les responsables de campagne peuvent gérer la campagne dont ils sont responsables.
  • Vous pouvez exécuter des révisions d'identité en fonction des autorisations accordées directement dans vos systèmes gérés (également appelés autorisations rapprochées) sans avoir à les provisionner à partir d'Oracle Access Governance. Toutefois, pour gérer vos accès à un niveau granulaire, utilisez les ensembles d'accès et provisionnez les autorisations à partir d'Oracle Access Governance.
  • Vous pouvez certifier rapidement des privilèges en exécutant des révisions d'accès aux identités à partir du système Oracle Access Governance en fonction des autorisations affectées directement. Les autorisations ou les comptes provisionnés au moyen d'une politique, ou les comptes d'identité Oracle Identity Governance (OIG) et Oracle Cloud Infrastructure (OCI) ne sont pas couverts par cette révision. Pour plus d'informations sur l'exécution de révisions basées sur des autorisations rapprochées, voir Révisions d'accès aux identités pour les autorisations affectées directement dans les systèmes gérés.
  • Dans une seule campagne, vous ne pouvez pas combiner deux types différents de révisions d'accès. Par exemple, si vous créez une campagne pour réviser les politiques, les critères pour les révisions d'accès aux identités ou les révisions de collection d'identités ne sont plus applicables et sont désactivés.
  • Les campagnes peuvent être certifiées par tout utilisateur actif associé à un flux d'approbation spécifique. Les réviseurs ne peuvent voir que les tâches d'évaluation qui leur sont associées. Un réviseur qui n'est associé à aucun flux de travail d'approbation ne peut effectuer de tâches pour aucune évaluation.
  • Si aucune évaluation n'est générée, elle passe automatiquement à l'état Prêt pour approbation.
  • Responsable de la campagne :
    • doit être un utilisateur actif d'Oracle Access Governance.
    • peut recevoir des avis par courriel chaque fois qu'une campagne progresse dans divers états de campagne.
    • peut être un réviseur d'accès basé sur le mécanisme de secours si le réviseur initial prévu n'est pas valide.
    • Peut gérer une campagne qui leur appartient.
  • Vous pouvez approuver ou autocertifier vos accès à l'aide du modèle Utilisateur personnalisé, Collecte des identités ou Responsable. Vous pouvez également approuver automatiquement vos accès lors de l'utilisation du modèle d'approbation du bénéficiaire.
  • Vous pouvez certifier les privilèges d'accès des utilisateurs consommateurs, mais un utilisateur consommateur ne peut pas être un réviseur d'accès.
  • Pour les révisions de politique, vous ne devez pas modifier la politique une fois les campagnes programmées. L'exécution de la demande de mesures correctives échouera. Les énoncés de politique doivent être cohérents tout au long du processus de campagne.
  • Pour les révisions de collection d'identités, vous ne devez pas modifier les membres une fois les campagnes programmées. L'exécution de la demande de mesures correctives échouera. La liste des membres doit être cohérente tout au long du processus de campagne.