Documentation Oracle Cloud Infrastructure

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

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

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

En tant qu'administrateur ou administrateur de campagne, pour certifier les privilèges d'accès, configurez et planifiez d'abord les campagnes de révision d'accès. Au cours de son cycle de vie, une campagne suit différents é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 planifier une campagne périodique, en formant une série de campagnes. Une campagne passe par différentes étapes ou différents états de son cycle de vie. Cela implique de définir le périmètre, de définir des workflows d'approbation, de sélectionner des propriétaires de campagne et de planifier 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 exécutées dans le cadre du processus d'assainissement en boucle fermée.

Les états de certification pour les campagnes de révision d'accès sont les suivants :
Accéder aux phases de la campagne de révision

  • Brouillon : Lorsqu'une nouvelle campagne de révision d'accès est créée ou ajoutée mais pas encore lancée. Dans l'état Brouillon, vous pouvez :
    • Afficher les détails de campagne
    • Modifier une campagne
    • Supprimer une campagne
  • Planifié : Lorsqu'une campagne de révision d'accès est créée pour être lancée à un moment précis dans le futur. Dans l'état Planifié, vous pouvez :
    • Afficher les détails de campagne
    • Modifier une campagne
    • Cloner une campagne
    • Mettre fin à une campagne
    • Terminer 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 informés de la campagne par courriel. Les réviseurs peuvent prendre des décisions sur les tâches de révision affectées en acceptant ou en révoquant les privilèges d'accès pour exécuter la décision dans le cadre du processus de résolution en boucle fermée. Dans un état En cours, vous pouvez effectuer les opérations suivantes :
    • Afficher les détails de campagne
    • Cloner une campagne
    • Mettre fin à une campagne
    • Terminer la série de campagnes
    • Afficher le rapport
    • Modifier la propriété de la campagne
    • Télécharger des 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 de révision sont en attente, les actions suggérées dans le workflow d'approbation sont automatiquement prises en compte. Par exemple, approuvez toutes les tâches de révision d'accès non révisées. Dans l'état Prêt pour approbation, vous pouvez :
    • Afficher les détails de campagne
    • Cloner une campagne
    • Mettre fin à une campagne
    • Terminer la série de campagnes
    • Afficher le rapport
    • Télécharger des données CSV
    • Modifier la propriété de la campagne
  • Approuvé : Lorsqu'un propriétaire 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. Dans l'état Approuvé, vous pouvez :
    • Afficher les détails de campagne
    • Cloner une campagne
    • Afficher le rapport
    • Télécharger des données CSV
  • Fin du système : Lorsqu'une erreur inattendue se produit, la campagne peut être abandonnée et passer au statut Fin du système. Avec le statut Terminé par le système, vous pouvez afficher les détails de la campagne, cloner une campagne, afficher le rapport ou télécharger le rapport CSV. Voici quelques causes possibles :
    • Lorsqu'une erreur système interne se produit, telle qu'un échec de génération d'informations clés ou un échec de validation des critères de campagne.

    • Toutes les campagnes brouillon 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 finalisées par le système.
    • Lorsqu'une défaillance du système se produit lors de l'interruption d'une campagne, celle-ci est abandonnée et prend l'état Système terminé.
  • Terminé : Lorsqu'une campagne est interrompue par un administrateur de campagne ou un propriétaire de campagne. Vous pouvez mettre fin à une campagne dont l'état est Planifié, En cours ou Prêt pour approbation. Une campagne prend également fin lorsque :
    • Le réviseur est inactif et la hiérarchie des responsables n'a pas d'utilisateur actif ou le propriétaire de la campagne est inactif.
    • Le processus de rappel ne parvient pas à affecter un propriétaire ou un réviseur de campagne approprié. La campagne est terminée par le système.
    • Le nombre de membres dans la collecte d'identités est inférieur aux réviseurs définis pour le flux d'approbation de la collecte d'identités.
    Dans l'état Terminé, vous pouvez effectuer les opérations suivantes :
    • Afficher les détails de campagne
    • Clone
    • Afficher le rapport
    • Télécharger des données CSV

Comprendre les garde-fous 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 opérationnel valide établi pour réduire la charge administrative ou pour d'autres justifications commerciales appropriées. Cependant, l'autocertification 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'auto-approbation.

Selon le type de workflow d'approbation, Oracle Access Governance active ou désactive les garde-fous d'autocertification pour une campagne.
  • Si vous sélectionnez un workflow Utilisateur personnalisé, Collecte d'identités ou Propriétaire, vous pouvez activer ou désactiver le processus d'autocertification. Si vous choisissez le workflow Bénéficiaire, vous pouvez également auto-approuver vos accès.
  • Si vous sélectionnez un autre workflow ou si vous choisissez de désactiver le processus d'auto-approbation, le système lance un mécanisme de secours approprié pour affecter automatiquement la tâche de révision au réviseur valide disponible suivant.

Comprendre le mécanisme de secours : Méthodes pour empêcher la fin d'une campagne

Lorsque vous utilisez des campagnes, vous choisissez le réviseur voulu en sélectionnant l'un des modèles d'approbation définis dans la fonctionnalité Workflows d'approbation d'Oracle Access Governance. Le service Campagnes lance un mécanisme de restauration en cas de détection d'un réviseur non valide ou d'un propriétaire de campagne non valide pour empêcher la fin d'une campagne.

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'auto-approbation est désactivée dans le modèle d'approbation sélectionné et que le réviseur est identique au bénéficiaire dont les accès sont en cours de vérification 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 → Propriétaire de la campagne → Tout utilisateur, sélectionné de manière aléatoire avec le rôle Administrateur Access Governance.

  • Vérificateur prévu
  • Responsable immédiat du réviseur, jusqu'à la chaîne de gestion définie jusqu'à ce qu'un réviseur valide soit trouvé.
  • Si aucun responsable actif n'est trouvé, le réviseur est défini comme propriétaire de la campagne.
  • Si l'auto-approbation n'est pas autorisée, aucun responsable actif n'est trouvé, le propriétaire de la campagne est le bénéficiaire, puis tout utilisateur choisi de manière aléatoire avec les rôles Administrateur est automatiquement affecté en tant que réviseur de révision d'accès.

Mécanisme de secours pour un propriétaire de campagne non valide

Les propriétaires de campagne non valides peuvent être des utilisateurs inactifs, des utilisateurs consommateurs ou des utilisateurs ne faisant pas partie du workflow d'approbation.

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

Propriétaire de la campagne concernée → Chaîne de gestion du propriétaire de la campagne → Tout utilisateur, sélectionné de manière aléatoire, disposant du rôle Administrateur Access Governance.

  • Chaîne de gestion du propriétaire de la campagne.
  • Si aucun responsable valide n'est trouvé, tout utilisateur choisi de manière aléatoire avec le rôle Administrateur est automatiquement affecté en tant que propriétaire de la campagne.

Exemple 1 : Comprendre le mécanisme de secours lorsque l'autocertification est autorisée

Scénario : en tant qu'administrateur de campagne et propriétaire de campagne, Sarah lance les révisions d'accès aux identités périodiques pour son propre service. Elle sélectionne le modèle de workflow d'approbation Propriétaire et autorise l'auto-approbation 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 propriétaire du compte en tant que Sarah
  • Bénéficiaire : Sarah et propriétaire du compte en tant que Sarah
A l'aide du modèle Propriétaire pour lequel l'autocertification est activée, le réviseur prévu pour cette campagne sera le propriétaire du compte, comme suit :
  • Bénéficiaire en tant que John Doe et vérificateur en tant que Sarah
  • Beneficiary en tant que Sarah et Reviewer en tant que 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 propriétaire de campagne, Sarah lance les révisions d'accès aux identités ad hoc pour les fonctions critiques dans les applications à haut risque de son service. Elle sélectionne le modèle de workflow d'approbation Propriétaire et n'autorise pas l'auto-approbation 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 titulaire de l'autorisation en tant que Sarah
L'autocertification étant désactivée, le réviseur prévu pour cette campagne ne peut pas être le même que le bénéficiaire. Ainsi, le mécanisme de secours sera lancé comme suit :

Réviseur invité → Chaîne de gestion du réviseur prévu → Propriétaire de la campagne → Tout utilisateur, sélectionné de manière aléatoire avec le rôle Administrateur Access Governance.

Supposons qu'aucun responsable valide ne soit trouvé dans la chaîne hiérarchique, le prochain propriétaire de la campagne doit être affecté en tant que réviseur. Dans cet exemple, le propriétaire de la campagne est identique au bénéficiaire avec auto-certification désactivée, puis le réviseur d'accès est choisi de manière aléatoire, 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 en tant que John Doe et vérificateur en tant que Sarah
  • Beneficiary en tant que Sarah et Reviewer en tant que Carol Beck

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

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

Voici quelques directives auxquelles vous devez vous conformer lors de l'exécution de 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 Oracle Access Governance. L'administrateur de campagne peut gérer les campagnes qu'il a créées. Les propriétaires de campagne peuvent gérer la campagne qu'ils possèdent.
  • Vous pouvez exécuter des révisions d'identité en fonction des droits d'accès accordés directement dans vos systèmes gérés (également appelés droits d'accès rapprochés) sans avoir à les provisionner à partir d'Oracle Access Governance. Toutefois, pour gérer vos accès à un niveau granulaire, utilisez des groupes d'accès et provisionnez les droits d'accès à partir d'Oracle Access Governance.
  • Vous pouvez certifier rapidement les privilèges en exécutant des révisions d'accès aux identités à partir du système Oracle Access Governance en fonction des droits d'accès affectés directement. Les droits d'accès ou les comptes provisionnés par le biais d'une stratégie, ou les comptes d'identité Oracle Identity Governance (OIG) et Oracle Cloud Infrastructure (OCI) ne sont pas couverts dans cette revue. Pour plus d'informations sur l'exécution de révisions basées sur des droits d'accès rapprochés, reportez-vous à Révisions d'accès d'identité pour les droits d'accès affectés directement dans les systèmes gérés.
  • Dans une même campagne, vous ne pouvez pas combiner deux types de révision d'accès différents. Par exemple, si vous créez une campagne pour vérifier les stratégies, les critères de vérification d'accès aux identités ou de collecte d'identités ne sont plus applicables et sont désactivés.
  • Les campagnes peuvent être certifiées par tout utilisateur actif associé à un workflow d'approbation spécifique. Les réviseurs ne peuvent consulter que les tâches de révision qui leur sont associées. Un réviseur qui n'est associé à aucun workflow d'approbation ne peut effectuer de tâches sur aucune révision.
  • Si aucune vérification n'est générée, elle passe automatiquement à l'état Prêt pour approbation.
  • Propriétaire de la campagne :
    • doit être un utilisateur actif Oracle Access Governance.
    • peuvent recevoir des notifications par courriel chaque fois qu'une campagne progresse dans différents états de campagne.
    • peut être un réviseur de révision d'accès basé sur le mécanisme de restauration si le réviseur prévu d'origine n'est pas valide.
    • Peut gérer une campagne qu'ils possèdent.
  • Vous pouvez auto-approuver ou auto-certifier vos accès à l'aide du modèle Utilisateur personnalisé, Collecte d'identités ou Propriétaire. Vous pouvez également approuver vous-même vos accès lorsque vous utilisez le modèle d'approbation Bénéficiaire.
  • Vous pouvez certifier les privilèges d'accès pour les utilisateurs consommateurs, mais un utilisateur consommateur ne peut pas être un réviseur d'accès.
  • Pour les révisions de stratégie, vous ne devez pas modifier la stratégie une fois les campagnes planifiées. Cela entraînera l'échec de l'exécution de la demande de résolution. Les déclarations de stratégie doivent être cohérentes 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 planifiées. Cela entraînera l'échec de l'exécution de la demande de résolution. La liste des membres doit être cohérente tout au long du processus de campagne.