Flux de travail d'approbation dans Oracle Access Governance
Les flux d'approbation sont des processus structurés conçus pour automatiser les approbations en fonction de flux de travail prédéfinis. Ces flux de travail garantissent que les demandes d'accès, les microcertifications et les examens d'accès sont examinés et approuvés par les parties prenantes appropriées, améliorant ainsi la sécurité et la conformité.
Par exemple, lorsqu'un utilisateur demande l'accès à un ensemble d'accès au moyen d'un module en libre-service, le flux d'approbation associé à cette demande déclenche un avis par courriel aux approbateurs, qui consultent ensuite la demande et décident de l'approuver, de la rejeter ou de demander des informations supplémentaires. Le résultat du processus d'approbation est mis à jour et les activités de provisionnement sont déclenchées dans le système orchestré spécifique. Pour créer et gérer des flux de travail d'approbation, voir Créer des flux de travail d'approbation et Gérer les flux de travail d'approbation.
Modèles de flux de travail d'approbation intégrés
Oracle Access Governance offre des modèles de flux de travail d'approbation que vous pouvez utiliser comme base pour concevoir les flux de travail personnalisés. Vous pouvez combiner plusieurs modèles en parallèle ou séquentiellement pour créer vos propres flux d'approbation.
Bénéficiaire
La demande d'approbation est envoyée à l'identité qui reçoit l'accès (le bénéficiaire), ce qui lui permet d'approuver lui-même une autorisation spécifique. L'utilisateur qui demande l'accès doit l'approuver lui-même. Convient aux autorisations à faible risque lorsqu'on fait confiance au bénéficiaire pour approuver son propre accès
Exemple : Utilisez cette option pour demander l'accès à un logiciel d'entreprise préapprouvé sans licence, lorsque le bénéficiaire approuve lui-même la demande.
Gestionnaire du bénéficiaire
La demande d'approbation est envoyée au gestionnaire du bénéficiaire. À utiliser pour valider si l'accès est approprié, pertinent ou dans le cadre de la portée commerciale.
Exemple : Utilisez ceci lors de la demande d'accès à un outil tiers sous licence.
Responsable principal
La demande d'approbation est envoyée au responsable principal de la ressource. Vous pouvez configurer pour autoriser ou interdire l'autoapprobation. Si l'autoapprobation est réglée à Oui, l'approbateur et le bénéficiaire peuvent avoir la même identité.
Exemple : Envoi d'une demande d'approbation au responsable principal de l'ensemble d'accès pour approuver les autorisations relatives à la base de données au sein d'un ensemble d'accès.
Responsables
La demande d'approbation est envoyée aux responsables des ressources (principaux et supplémentaires) pour garantir une utilisation appropriée de la ressource. Vous pouvez configurer pour autoriser ou interdire l'autoapprobation. Si l'autoapprobation est réglée à Oui, l'approbateur et le bénéficiaire peuvent avoir la même identité.
Exemple : Envoi d'une demande d'approbation aux responsables de l'ensemble d'accès pour approuver les demandes d'accès à l'ensemble d'accès.
Utilisateur personnalisé
La demande d'approbation est dirigée vers une identité spécifique prédéfinie, généralement pour un contrôle centralisé. Convient aux scénarios nécessitant une autorisation d'approbation spécialisée.
Exemple : Envoi d'une demande d'approbation à un administrateur informatique lorsqu'un sous-traitant demande l'accès à une application de collaboration d'équipe d'entreprise.
Chaîne de gestion
La demande d'approbation suit une structure hiérarchique, en partant du gestionnaire du bénéficiaire et en remontant la chaîne au besoin. Convient pour les autorisations essentielles à l'entreprise nécessitant des approbations à plusieurs niveaux.
Exemple : À utiliser lorsqu'une identité demande une autorisation de rôle "Contributeurs" pour publier et télécharger des mises à jour sur un système de stockage orienté client.
Collections d'identités
- Nombre minimal d'approbations requises pour traiter la demande.
- Veto pouvoir de refuser la demande, si un membre rejette.
- Collecte d'identités escaladée qui reçoit la demande à l'expiration du délai de la demande initiale.
Si le groupe manque de membres, la demande est annulée. Voir Gestion des groupes volumineux dans les flux de travail d'approbation.
Exemple : À utiliser lorsqu'une identité demande un accès au privilège d'administrateur de base de données pour acheminer une demande vers la collection d'identités de l'administrateur de base de données.Traitement d'escalade dans les flux d'approbation
Lors de la configuration de vos flux d'approbation, vous pouvez définir un délai d'escalade (nombre de jours à attendre avant de transmettre la demande d'approbation à l'approbateur suivant). Cela se produit parce que l'approbateur initial n'a pas répondu dans le délai configuré.
S'applique à : Bénéficiaire, Gestionnaire du bénéficiaire, Responsable, Utilisateur personnalisé, Chaîne de gestion types de modèle
Le premier recours hiérarchique se produit lorsqu'une tâche d'approbation n'est pas terminée à temps. Recherche dans la chaîne de gestion de l'approbateur initial le premier gestionnaire actif disponible. Les escalades ultérieures se produisent si même l'approbateur escaladé ne prend pas d'action. Maintenant, le système commence sa prochaine recherche à partir du gestionnaire de la dernière personne qui a eu la tâche, en continuant la chaîne.
Chaque fois que le temporisateur d'escalade expire pour une demande, Oracle Access Governance suit un processus structuré pour faire avancer la tâche. Un courriel d'avis est envoyé à l'approbateur escaladé (gestionnaire ou partie identité de la collecte d'identités escaladée) pour l'informer de la tâche escaladée.
- Première escalade : Recherche dans la chaîne de gestion de l'approbateur le premier gestionnaire actif inclus dans Oracle Access Governance.
- Recours ultérieurs : Recherche le gestionnaire de l'approbateur le plus récent vers lequel la tâche a été escaladée, en conitinant la chaîne de gestion.
- Position du plafond : Si un plafond d'escalade (nombre maximal de niveaux hiérarchiques) est défini, la recherche arrête un niveau avant de l'atteindre.
- Recherche chaque membre dans la collection d'identités escaladée et affecte la tâche à toute personne qui ne l'a pas déjà reçue. Si la tâche a déjà été transmise à tous, aucune autre mesure n'est prise. Si un plafond d'escalade (nombre maximal de niveaux hiérarchiques) est défini, la recherche arrête un niveau avant de l'atteindre.
Traitement des approbations de grands groupes : Limite de membres et critères
Lorsque vous sélectionnez une collection d'identités pour n'importe quelle partie du flux d'approbation, telle que les approbations, les escalades ou les délégations, Oracle Access Governance applique une limite de membres.
Vous pouvez sélectionner une collection d'identités de toute taille, mais seulement 25 membres au maximum peuvent recevoir et approuver activement des tâches. Oracle Access Governance sélectionne les 25 premiers membres ACTIVE/WORKFORCE.
ACTIVE/WORKFORCE sont disponibles, CONSUMERS sont ajoutés pour atteindre la limite de 25 membres. Toutefois, aucun membre CONSUMER ne reçoit une tâche d'approbation, mais un mécanisme de secours est lancé, comme suit.- Pour les révisions d'accès, voir Mécanisme de secours dans la révision d'accès.
- Pour les demandes d'accès, Oracle Access Governance recherche la chaîne de gestion de l'approbateur jusqu'à ce qu'il trouve un
ACTIVE/WORKFORCE, qui est ensuite affecté en tant qu'approbateur.Note
Pour les flux de travail d'approbation escaladés ou délégués, les membres du consommateur ne sont pas pris en compte et le mécanisme de secours ne s'applique pas.
Modification de l'appartenance à l'affectation d'approbation
Les tâches d'évaluation restent toujours avec les 25 membres affectés. Si un membre est supprimé d'une collection d'identités ou devient INACTIVE/CONSUMER, les tâches sont transmises à un autre membre du groupe pour conserver le nombre de 25 membres.
Matrices et critères d'approbation automatique
Les tableaux suivants résument les principaux critères d'approbation automatique pour les deux matrices.
| L'approbateur est-il le demandeur ou le flux de travail a-t-il un IC d'approbation automatique et le demandeur est-il membre? | Le flux de travail permet-il d'approuver automatiquement si des violations AGR ou SOD sont présentes? | Le flux de travail permet-il l'autoapprobation? | L'approbateur est-il bénéficiaire? | Les violations sont-elles présentes? | Action d'approbation automatique |
|---|---|---|---|---|---|
| Oui | Nombre | Nombre | Nombre | Nombre | Approuver |
| Oui | Nombre | Nombre | Nombre | Oui | Aucune action |
| Oui | Nombre | Nombre | Oui | Nombre | Aucune action |
| Oui | Nombre | Nombre | Oui | Oui | Aucune action |
| Oui | Nombre | Oui | Nombre | Nombre | Approuver |
| Oui | Nombre | Oui | Nombre | Oui | Aucune action |
| Oui | Nombre | Oui | Oui | Nombre | Approuver |
| Le flux de travail est configuré pour approuver automatiquement si aucune violation AGR ou SOD n'est détectée? | Les violations sont-elles présentes? | Action d'approbation automatique |
|---|---|---|
| Oui | Nombre | Approuver |
| Oui | Oui | Aucune action |