Workflows d'approbation dans Oracle Access Governance
Les workflows d'approbation sont des processus structurés conçus pour automatiser les approbations en fonction de workflows prédéfinis. Ces flux de travail garantissent que les demandes d'accès, les micro-certifications et les examens d'accès sont examinés et approuvés par les parties prenantes appropriées, ce qui améliore la sécurité et la conformité.
Par exemple, lorsqu'un utilisateur demande l'accès à un lot d'accès via un module en libre-service, le workflow d'approbation associé à cette demande déclenche une notification par e-mail aux approbateurs, qui vérifient 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 workflows d'approbation, reportez-vous aux rubriques Créer des workflows d'approbation et Gérer les workflows d'approbation.
Modèles de workflow d'approbation intégrés
Oracle Access Governance propose des modèles de workflow d'approbation que vous pouvez utiliser comme base pour concevoir les workflows personnalisés. Vous pouvez combiner plusieurs modèles en parallèle ou séquentiellement pour créer vos propres workflows 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'auto-approuver une autorisation spécifique. L'utilisateur qui demande l'accès doit l'approuver lui-même. Convient aux autorisations à faible risque pour lesquelles le bénéficiaire est autorisé à approuver son propre accès
Exemple : Utilisez cet exemple pour demander l'accès à un logiciel d'entreprise pré-approuvé et non sous licence, où le bénéficiaire auto-approuve la demande.
Responsable du bénéficiaire
La demande d'approbation est envoyée au responsable du bénéficiaire. Utilisez cette option pour vérifier si l'accès est approprié, pertinent ou dans le périmètre d'activité.
Exemple : Utilisez-le lorsque vous demandez l'accès à un outil tiers sous licence.
Responsable principal
La demande d'approbation est envoyée au propriétaire principal de la ressource. Vous pouvez configurer pour autoriser ou interdire l'auto-approbation. Si l'auto-approbation est définie sur Oui, l'approbateur et le bénéficiaire peuvent avoir la même identité.
Exemple : Envoi d'une demande d'approbation au propriétaire principal du groupe d'accès pour approuver les autorisations liées à la base de données dans un groupe d'accès.
Propriétaires
La demande d'approbation est envoyée aux propriétaires de ressource (propriétaires principaux et supplémentaires) pour garantir une utilisation correcte de la ressource. Vous pouvez configurer pour autoriser ou interdire l'auto-approbation. Si l'auto-approbation est définie sur Oui, l'approbateur et le bénéficiaire peuvent avoir la même identité.
Exemple : Envoi d'une demande d'approbation aux propriétaires de groupe d'accès pour approuver les demandes d'accès au groupe d'accès.
Utilisateur personnalisé
La demande d'approbation est dirigée vers une identité prédéfinie spécifique, 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 commençant par le responsable du bénéficiaire et en remontant la chaîne selon les besoins. Convient aux autorisations stratégiques nécessitant des approbations à plusieurs niveaux.
Exemple : utilisez cette option 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 minimum d'approbations requises pour poursuivre la demande.
- Veto pouvoir de refuser la demande, si un membre rejette.
- Collection d'identités escaladée qui reçoit la demande à l'expiration de la chronologie de la demande initiale.
Si le groupe manque de membres, la demande est annulée. Reportez-vous à Gestion des groupes volumineux dans les workflows d'approbation.
Exemple : utilisez cette option lorsqu'une identité demande un accès de privilège d'administrateur de base de données pour acheminer une demande vers la collection d'identités d'administrateur de base de données.Gestion des escalades dans les workflows d'approbation
Lors de la configuration de vos workflows d'approbation, vous pouvez définir un délai d'escalade (le nombre de jours d'attente avant l'escalade de la demande d'approbation à l'approbateur suivant). Cela se produit car l'approbateur d'origine n'a pas répondu dans le délai configuré.
S'applique à : types de modèle Bénéficiaire, Responsable de bénéficiaire, Propriétaire, Utilisateur personnalisé, Chaîne de gestion
La première escalade se produit lorsqu'une tâche d'approbation n'est pas terminée à temps. Recherche la chaîne hiérarchique de l'approbateur d'origine pour le premier responsable actif disponible. Les escalades suivantes se produisent si même l'approbateur escaladé n'effectue aucune action. Désormais, le système lance sa prochaine recherche à partir du gestionnaire de la dernière personne qui a eu la tâche, en remontant la chaîne.
Chaque fois que l'horloge d'escalade expire pour une demande, Oracle Access Governance suit un processus structuré pour faire avancer la tâche. Un courriel de notification est envoyé à l'approbateur escaladé (responsable ou partie d'identité de la collecte d'identités escaladée) pour l'informer de la tâche escaladée.
- Première escalade : permet de rechercher le premier responsable actif inclus dans Oracle Access Governance dans la chaîne de gestion de l'approbateur.
- Escalades suivantes : permet de rechercher le responsable de l'approbateur le plus récent vers lequel la tâche a été escaladée, en passant par la chaîne hiérarchique.
- Remarques concernant le plafond : si un plafond d'escalade (nombre maximum de niveaux de hiérarchie) est défini, la recherche arrête un niveau avant de l'atteindre.
- Recherche chaque partie de membre de 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é escaladée vers toutes ces tâches, aucune autre action n'est entreprise. Si un plafond d'escalade (nombre maximum de niveaux hiérarchiques) est défini, la recherche s'arrête à un niveau avant de l'atteindre.
Gérer les approbations de groupe important : limites et critères des membres
Lorsque vous sélectionnez une collection d'identités pour une partie quelconque du workflow 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 un maximum de 25 membres peuvent recevoir et approuver activement des tâches. Oracle Access Governance sélectionne les 25 premiers membres ACTIVE/WORKFORCE.
ACTIVE/WORKFORCE sont disponibles, CONSUMERS est ajouté pour atteindre la limite de 25 membres. Toutefois, aucun membre CONSUMER ne reçoit de tâche d'approbation, mais un mécanisme de secours est activé, comme suit.- Pour les révisions d'accès, reportez-vous à Mécanisme de rappel dans la révision d'accès.
- Pour les demandes d'accès, Oracle Access Governance effectue une recherche dans la chaîne de gestion de l'approbateur jusqu'à ce qu'il trouve une valeur
ACTIVE/WORKFORCE, qui est ensuite affectée en tant qu'approbateur.Remarque
Pour les workflows d'approbation escaladés ou délégués, les membres du destinataire ne sont pas pris en compte et le mécanisme de secours ne s'applique pas.
Modification d'appartenance dans l'affectation d'approbation
Les tâches de révision restent toujours avec les 25 membres affectés. Si un membre est enlevé d'une collection d'identités ou devient INACTIVE/CONSUMER, les tâches sont transmises à un autre membre du groupe pour tenir à jour le nombre de 25 membres.
Matrices et critères d'approbation automatique
Les tableaux suivants récapitulent les critères clés pour l'approbation automatique dans les deux matrices.
| L'approbateur est-il un demandeur ou un workflow a une approbation automatique IC et le demandeur est-il membre ? | Le workflow autorise l'approbation automatique si des violations AGR ou SOD sont présentes ? | Le workflow autorise l'auto-approbation ? | L'approbateur est-il bénéficiaire ? | Les violations sont-elles présentes ? | Action d'approbation automatique |
|---|---|---|---|---|---|
| Oui | Non | Non | Non | Non | Approuver |
| Oui | Non | Non | Non | Oui | Aucune intervention |
| Oui | Non | Non | Oui | Non | Aucune intervention |
| Oui | Non | Non | Oui | Oui | Aucune intervention |
| Oui | Non | Oui | Non | Non | Approuver |
| Oui | Non | Oui | Non | Oui | Aucune intervention |
| Oui | Non | Oui | Oui | Non | Approuver |
| Le workflow est-il 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 | Non | Approuver |
| Oui | Oui | Aucune intervention |