Fluxos de Trabalho de Aprovação no Oracle Access Governance
Fluxos de Trabalho de Aprovação são processos estruturados projetados para automatizar aprovações com base em fluxos de trabalho predefinidos. Esses fluxos de trabalho garantem que solicitações de acesso, microcertificações e revisões de acesso sejam revisadas e aprovadas pelas partes interessadas apropriadas, aumentando a segurança e a conformidade.
Por exemplo, quando um usuário solicita acesso a um pacote de acesso por meio de um módulo de autoatendimento, o workflow de aprovação associado a essa solicitação aciona uma notificação por e-mail para os aprovadores, que, em seguida, revisam a solicitação e decidem aprová-la, rejeitá-la ou solicitar mais informações. O resultado do processo de aprovação é atualizado e as atividades de provisionamento são acionadas no sistema orquestrado específico. Para criar e gerenciar workflows de aprovação, consulte Criar Workflows de Aprovação e Gerenciar Workflow de Aprovação.
Modelos de Workflow de Aprovação Incorporados
O Oracle Access Governance oferece modelos de workflow de aprovação que você pode usar como base para projetar os workflows personalizados. Você pode combinar vários modelos em paralelo ou sequencialmente para criar seus próprios workflows de aprovação.
Beneficiário(a)
A solicitação de aprovação é enviada à identidade que recebe o acesso (o beneficiário), permitindo que ela se autoaprove com permissão específica. O usuário que solicita o acesso deve aprová-lo por conta própria. Adequado para permissões de baixo risco em que o beneficiário é confiável para aprovar seu próprio acesso
Exemplo: use essa opção para solicitar acesso a software empresarial não licenciado e pré-aprovado, em que o beneficiário autoaprova a solicitação.
Gerente de Benefícios
A solicitação de aprovação é enviada ao gerente do beneficiário. Use esta opção para validar se o acesso é apropriado, relevante ou dentro do escopo de negócios.
Exemplo: use essa opção ao solicitar acesso a uma ferramenta de terceiros licenciada.
Proprietário principal
A solicitação de aprovação é enviada ao proprietário principal do recurso. Você pode configurar para permitir ou não a autoaprovação. Se a autoaprovação for definida como Sim, o aprovador e o beneficiário poderão ter a mesma identidade.
Exemplo: Enviando uma solicitação de aprovação ao proprietário principal do pacote de acesso para aprovar permissões relacionadas ao banco de dados em um pacote de acesso.
Proprietários
A solicitação de aprovação é enviada aos proprietários do recurso (proprietários principal e adicional) para garantir o uso adequado do recurso. Você pode configurar para permitir ou não a autoaprovação. Se a autoaprovação for definida como Sim, o aprovador e o beneficiário poderão ter a mesma identidade.
Exemplo: Enviando uma solicitação de aprovação aos proprietários do pacote de acesso para aprovar solicitações de acesso ao pacote de acesso.
Usuário Personalizado
A solicitação de aprovação é direcionada a uma identidade específica e predefinida, geralmente para controle centralizado. Adequado para cenários que exigem autoridade de aprovação especializada.
Exemplo: Enviando uma solicitação de aprovação a um administrador de TI quando um contratado solicita acesso a um aplicativo de colaboração de equipe empresarial.
Cadeia de Gerenciamento
A solicitação de aprovação segue uma estrutura hierárquica, começando pelo gerente do beneficiário e subindo a cadeia conforme necessário. Adequado para permissões essenciais para os negócios que exigem aprovações de vários níveis.
Exemplo: use essa opção quando uma identidade estiver solicitando uma permissão de atribuição "Colaboradores" para publicar e fazer download de atualizações em um sistema de armazenamento voltado para o cliente.
Coleções de Identidades
- Número mínimo de aprovações necessárias para continuar com a solicitação.
- Poder de veto para negar o pedido, se qualquer membro rejeitar.
- Coleta de identidades escalada que recebe a solicitação após o vencimento da linha do tempo da solicitação original.
Se o grupo não tiver membros suficientes, a solicitação será cancelada. Consulte Tratamento de Grupos Grandes em Workflows de Aprovação.
Exemplo: Use essa opção quando uma identidade estiver solicitando um acesso ao privilégio database-admin para rotear uma solicitação para a coleção de identidades do Administrador do Banco de Dados.Controle de Escalação em Workflows de Aprovação
Ao configurar seus fluxos de trabalho de aprovação, você pode definir um tempo de escalação — o número de dias de espera antes de escalar a solicitação de aprovação para o próximo aprovador. Isso acontece porque o aprovador original não respondeu no tempo configurado.
Aplica-se a: tipos de modelo Beneficiário, Gerente do beneficiário, Proprietário, Usuário Personalizado, Cadeia de Gerenciamento
Primeira Escalação acontece quando uma tarefa de aprovação não é concluída a tempo. Pesquisa a cadeia de gerenciamento do aprovador original para o primeiro gerente ativo disponível. Escalonamentos Subsequentes ocorrerão se nem mesmo o aprovador escalonado executar uma ação. Agora, o sistema inicia sua próxima pesquisa com o gerente da última pessoa que teve a tarefa, continuando na cadeia.
Cada vez que o cronômetro de escalonamento expira para uma solicitação, o Oracle Access Governance segue um processo estruturado para avançar a tarefa. Um e-mail de notificação é enviado ao aprovador escalado (gerente ou parte da identidade da coleta de identidade escalada) para informá-lo sobre a tarefa escalada.
- Primeira Escalação: Pesquisa a cadeia de gerenciamento do aprovador para localizar o primeiro gerente ativo incluído no Oracle Access Governance.
- Escalonamentos Subsequentes: Pesquisa o gerente do aprovador mais recente para o qual a tarefa foi escalada, correspondendo à cadeia de gerenciamento.
- Consideração Máxima: Se um teto de escalação (número máximo de níveis de hierarquia) for definido, a pesquisa interromperá um nível antes de atingi-lo.
- Pesquisa cada parte do membro da coleção de identidades escalada e atribui a tarefa a qualquer pessoa que ainda não a tenha recebido. Se a tarefa já tiver sido escalada para todos eles, nenhuma outra ação será tomada. Se um teto de escalação (número máximo de níveis de hierarquia) for definido, a pesquisa interromperá um nível antes de atingi-lo.
Tratando Aprovações de Grandes Grupos: Limite e Critérios de Membros
Quando você seleciona uma coleção de identidades para qualquer parte do workflow de aprovação, como aprovações, escalonamentos ou delegações, o Oracle Access Governance impõe um limite de membro.
Você pode selecionar uma coleção de identidades de qualquer tamanho, mas apenas um máximo de 25 membros pode receber e aprovar tarefas ativamente. O Oracle Access Governance seleciona os primeiros 25 membros do ACTIVE/WORKFORCE.
ACTIVE/WORKFORCE estiverem disponíveis, o CONSUMERS será adicionado para atingir o limite de 25 membros. No entanto, nenhum membro CONSUMER recebe uma tarefa de aprovação, em vez disso, um mecanismo de fallback é iniciado, da seguinte forma.- Para revisões de acesso, consulte Mecanismo de Fallback na Revisão de Acesso.
- Para solicitações de acesso, o Oracle Access Governance pesquisa a cadeia de gerenciamento do aprovador até encontrar um
ACTIVE/WORKFORCE, que é atribuído como o aprovador.Observação
Para workflows de aprovação escalados ou delegados, os membros do consumidor não são considerados e o mecanismo de fallback não se aplica.
Alteração de Associação na Atribuição de Aprovação
As tarefas de revisão sempre permanecem com os 25 membros atribuídos. Se um membro for removido de uma coleção de identidades ou se tornar INACTIVE/CONSUMER, as tarefas serão passadas para outro membro do grupo para manter a contagem de 25 membros.
Critérios e matrizes de aprovação automática
As tabelas a seguir resumem os principais critérios de aprovação automática nas duas matrizes.
| O aprovador é solicitante ou o workflow tem IC de aprovação automática e o solicitante é membro? | O workflow permite aprovação automática se houver violações de AGR ou SOD? | Workflow permite autoaprovação? | O aprovador é beneficiário? | As violações estão presentes? | Ação de aprovação automática |
|---|---|---|---|---|---|
| Sim | Não | Não | Não | Não | Aprovar |
| Sim | Não | Não | Não | Sim | Nenhuma ação |
| Sim | Não | Não | Sim | Não | Nenhuma ação |
| Sim | Não | Não | Sim | Sim | Nenhuma ação |
| Sim | Não | Sim | Não | Não | Aprovar |
| Sim | Não | Sim | Não | Sim | Nenhuma ação |
| Sim | Não | Sim | Sim | Não | Aprovar |
| O workflow está configurado para aprovação automática se nenhuma violação de AGR ou SOD for detectada? | As violações estão presentes? | Ação de aprovação automática |
|---|---|---|
| Sim | Não | Aprovar |
| Sim | Sim | Nenhuma ação |