Trabalhando com Campanhas de Revisão de Acesso no Oracle Access Governance

Use Campanhas para iniciar um processo de revisão de acesso. Para usar as Revisões de Acesso de forma eficaz, entenda o ciclo de vida da campanha, juntamente com conceitos cruciais, como autocertificação de acessos e mecanismo de fallback quando um revisor ou proprietário inválido for detectado. Use diretrizes ou melhores práticas enquanto trabalha com campanhas para garantir que o processo de revisão eficaz seja conduzido.

Acessar Estágios da Campanha de Revisão

Como Administrador ou Administrador da Campanha, para certificar privilégios de acesso, primeiro configure e programe Campanhas de Revisão de Acesso. Durante seu ciclo de vida, uma campanha percorre vários estados de revisão de acesso. As tarefas que você pode executar dependem do estado ou do status de uma campanha.

Como Administrador ou Administrador da Campanha, inicie o processo de revisão de acesso criando uma Campanha na seção Revisões de Acesso. É possível configurar uma campanha ad-hoc ou programar uma campanha periódica, formando uma série de campanhas. Uma campanha prossegue em vários estágios ou estados em seu ciclo de vida. Isso envolve definir o escopo, definir fluxos de trabalho de aprovação, selecionar proprietários de campanha e programar campanhas. Uma vez iniciado, os revisores podem aceitar ou revogar privilégios de acesso. As decisões tomadas são cumpridas como parte do processo de remediação em circuito fechado.

Estes são os estados de certificação para Campanhas de Revisão de Acesso:
Acessar Estágios da Campanha de Revisão

  • Preliminar: quando uma nova Campanha de Revisão de Acesso é criada ou adicionada, mas ainda não iniciada. No estado Rascunho, você pode:
    • Exibir detalhes da campanha
    • Editar uma campanha
    • Excluir uma campanha
  • Agendado: Quando uma campanha de revisão de acesso é criada para ser lançada em um momento específico no futuro. No estado Agendado, você pode:
    • Exibir detalhes da campanha
    • Editar uma campanha
    • Clonar uma campanha
    • Encerrar uma campanha
    • Encerrar série de campanhas
  • Em Andamento: Quando uma campanha de revisão de acesso é iniciada. Os revisores da campanha são notificados sobre a campanha por e-mail. Os revisores podem tomar decisões sobre as tarefas de revisão atribuídas aceitando ou revogando os privilégios de acesso para finalmente cumprir a decisão como parte do processo de correção de ciclo fechado. Em um estado Em Andamento, você pode:
    • Exibir detalhes da campanha
    • Clonar uma campanha
    • Encerrar uma campanha
    • Encerrar série de campanhas
    • Exibir relatório
    • Alterar propriedade da campanha
    • Fazer download dos dados CSV
  • Pronto para Aprovação: quando as tarefas de revisão tiverem sido concluídas ou a data de vencimento da campanha tiver decorrido, a campanha será movida para o estado Pronto para Aprovação. Caso haja itens de revisão pendentes, as ações sugeridas fornecidas no workflow de aprovação serão consideradas automaticamente. Por exemplo, aprove todas as tarefas de revisão de acesso não revisadas. No estado Pronto para Aprovação, você pode:
    • Exibir detalhes da campanha
    • Clonar uma campanha
    • Encerrar uma campanha
    • Encerrar série de campanhas
    • Exibir relatório
    • Fazer download dos dados CSV
    • Alterar propriedade da campanha
  • Aprovado: Quando um proprietário da campanha aprova e aprova uma campanha na opção Ações, ela é marcada como Aprovado. A campanha é movida da fila minhas campanhas em andamento para a fila minhas campanhas anteriores. No estado Aprovado, você pode:
    • Exibir detalhes da campanha
    • Clonar uma campanha
    • Exibir relatório
    • Fazer download dos dados CSV
  • Sistema Encerrado: Quando ocorre um erro inesperado, a campanha pode ser abortada, levando ao status Sistema Encerrado. No status Sistema Encerrado, você pode exibir detalhes da campanha, clonar uma campanha, exibir relatório ou fazer download do relatório CSV. Algumas causas possíveis são:
    • Quando ocorre um erro interno do sistema, como falha na geração de Insights ou falha na validação de critérios de campanha.
    • Todas as campanhas Preliminares e Agendadas criadas antes da versão de junho de 2023 são automaticamente abortadas e marcadas como Sistema encerrado.

    • Quando uma instância de serviço do Oracle Access Governance é excluída, todas as campanhas nessa instância de serviço são abortadas e marcadas como Sistema Finalizado.
    • Quando ocorre uma falha no sistema durante o encerramento de uma campanha, ela é abortada e resulta no estado Sistema Finalizado.
  • Encerrado: quando uma campanha é encerrada por um Administrador da Campanha ou por um proprietário da Campanha. Você pode encerrar uma campanha quando ela estiver no estado Agendado, Em Andamento ou Pronto para Aprovação. Uma campanha também é encerrada quando:
    • O revisor está inativo e a hierarquia gerencial não tem um usuário ativo ou o proprietário da campanha está inativo.
    • O processo Fallback falha ao atribuir um proprietário ou revisor da campanha apropriado. A campanha é Encerrada pelo sistema.
    • O número de membros na Coleta de Identidades é menor que os revisores definidos para o fluxo de trabalho de aprovação da Coleta de Identidades.
    No estado Encerrado, você pode:
    • Exibir detalhes da campanha
    • Clonar
    • Exibir relatório
    • Fazer download dos dados CSV

Noções Básicas Sobre Corrimões de Autocertificação

A autocertificação é um processo de aprovação ou certificação de seus próprios direitos de acesso sem a intervenção de um revisor externo. É um processo de negócio válido estabelecido para reduzir a carga administrativa ou para outras justificativas de negócios apropriadas. No entanto, a autocertificação geralmente não é recomendada para acessos de alto risco envolvendo dados críticos ou onde um benefício pessoal potencial está envolvido. O Oracle Access Governance oferece a opção de ativar ou desativar o processo de autoaprovação.

Com base no tipo de workflow de aprovação, o Oracle Access Governance ativa ou desativa os guardrails de autocertificação para uma Campanha.
  • Se você selecionar Usuário Personalizado, Coleta de Identidades ou workflow Proprietário, poderá optar por ativar ou desativar o processo de autocertificação. Se você escolher o workflow Beneficiário, também poderá autoaprovar seus acessos.
  • Se você selecionar qualquer outro workflow ou optar por desativar o processo de autoaprovação, o sistema iniciará um mecanismo de fallback apropriado para atribuir automaticamente a tarefa de revisão ao próximo revisor válido disponível.

Entendendo o Mecanismo de Fallback: Métodos para Evitar o Encerramento da Campanha

Ao trabalhar com Campanhas, você escolhe o revisor desejado selecionando um dos modelos de aprovação definidos no recurso Workflows de Aprovação do Oracle Access Governance. O serviço Campanhas iniciará um mecanismo de fallback no caso de um revisor inválido ou de um proprietário de campanha inválido ser detectado para evitar o encerramento de uma campanha.

Veja quando o Oracle Access Governance marca um revisor como inválido:
  • Quando uma identidade do Oracle Access Governance Inativa é selecionada como revisor.
  • Quando uma identidade ativa com o tipo de usuário Consumidor é selecionada como um revisor.
  • Quando a autoaprovação é desativada no modelo de aprovação selecionado, e o revisor é igual ao beneficiário cujos acessos estão sendo revisados ou certificados.

Mecanismo de Fallback para um Revisor Inválido

Se o revisor pretendido for inválido, o Oracle Access Governance iniciará o seguinte mecanismo de fallback, na ordem listada, para atribuir um revisor válido:

Revisor PretendidoCadeia de Gerenciamento do revisor pretendidoProprietário da campanhaQualquer usuário, selecionado aleatoriamente com a função Administrador do Access Governance.

  • Revisor Pretendido
  • Gerente imediato do revisor, até a cadeia de gerenciamento definida até que um revisor válido seja encontrado.
  • Se nenhum gerente ativo for encontrado, o revisor será definido como proprietário da Campanha.
  • Se a autoaprovação não for permitida, nenhum gerente ativo será encontrado, o proprietário da campanha será o beneficiário e qualquer usuário, escolhido aleatoriamente, com as funções de Administrador será atribuído automaticamente como um revisor de revisão de acesso.

Mecanismo de Fallback para um Proprietário de Campanha Inválido

Proprietários de campanha inválidos podem ser usuários inativos, usuários consumidores ou usuários que não fazem parte do fluxo de trabalho de aprovação.

Se o proprietário da campanha pretendido for inválido, o Oracle Access Governance iniciará o seguinte mecanismo de fallback para atribuir um proprietário de campanha válido:

Proprietário da Campanha PretendidoCadeia de Gerenciamento do proprietário da campanhaQualquer usuário, selecionado aleatoriamente, que tenha a atribuição Administrador do Access Governance.

  • Cadeia de gerenciamento do proprietário da campanha.
  • Se nenhum gerente válido for encontrado, qualquer usuário, escolhido aleatoriamente, com a atribuição Administrador será automaticamente designado como o proprietário da campanha.

Exemplo 1 - Noções Básicas sobre o Mecanismo de Fallback quando a Auto-Certificação é Permitida

Cenário: como Administrador da Campanha e Proprietário da Campanha, Sarah inicia as revisões periódicas de acesso de identidade para seu próprio departamento. Ela seleciona o modelo de workflow de aprovação do Proprietário e permite a autoaprovação de revisões de acesso. Ele gera duas revisões de acesso, com o tipo de Atribuição Conta da seguinte forma:
  • Beneficiário: John Doe e Proprietário da conta como Sarah
  • Beneficiário: Sarah e Proprietário da conta como Sarah
Usando o modelo de Proprietário com a autocertificação ativada, o revisor pretendido para essa campanha será o proprietário da conta, da seguinte forma:
  • Beneficiário como John Doe e Revisor como Sarah
  • Beneficiário como Sarah e Revisor como Sarah

Exemplo 2 - Noções Básicas sobre o Mecanismo de Fallback quando a Auto-Certificação não é Permitida

Cenário: como Administradora de Campanha e Proprietária de Campanha, Sarah inicia as revisões de acesso de identidade ad hoc para funções críticas em aplicativos de alto risco para seu departamento. Ela seleciona o modelo de workflow de aprovação do Proprietário e não permite a autoaprovação de revisões de acesso. Ele gera duas revisões de acesso, com o tipo de Atribuição Permissão da seguinte forma:
  • Beneficiário: John Doe e Proprietário da permissão como Sarah
  • Beneficiário: Sarah e Proprietário da permissão como Sarah
Como a autocertificação está desativada, o revisor pretendido para esta campanha não pode ser o mesmo que o beneficiário. Assim, o mecanismo de fallback será iniciado da seguinte forma:

Revisor PretendidoCadeia de Gerenciamento do revisor pretendidoProprietário da campanhaQualquer usuário, selecionado aleatoriamente com a função Administrador do Access Governance.

Suponha que nenhum gerente válido seja encontrado na cadeia de gerenciamento; em seguida, o próximo proprietário da campanha deve ser atribuído como um revisor. Neste exemplo, o proprietário da campanha é o mesmo beneficiário com a autocertificação desativada, então o revisor de acesso é escolhido aleatoriamente, tendo a atribuição Administrador, que neste exemplo é Carol Beck. Portanto, os revisores de acesso serão os seguintes:

  • Beneficiário como John Doe e Revisor como Sarah
  • Beneficiário como Sarah e Revisor como Carol Beck

Melhores Práticas: Diretrizes a Considerar ao Trabalhar com Campanhas

Ao executar campanhas, você deve seguir algumas práticas recomendadas e diretrizes para garantir um processo de revisão de acesso eficaz.

Aqui estão algumas diretrizes que você deve seguir ao executar campanhas:
  • As campanhas só podem ser criadas pelo Administrador ou pelo Administrador da Campanha do Oracle Access Governance.
  • Todas as campanhas só podem ser gerenciadas pelo Administrador do Oracle Access Governance. O Administrador da Campanha pode gerenciar as campanhas que ele criou. Os proprietários da campanha podem gerenciar a campanha de sua propriedade.
  • Você pode executar revisões de identidade com base nas permissões concedidas diretamente em seus Sistemas Gerenciados (também conhecidas como permissões reconciliadas) sem a necessidade de provisioná-las no Oracle Access Governance. No entanto, para gerenciar seus acessos em um nível granular, use Pacotes de Acesso e provisione as permissões do Oracle Access Governance.
  • Você pode certificar rapidamente privilégios executando revisões de acesso de identidade no sistema Oracle Access Governance com base nas permissões designadas diretamente. Permissões ou contas provisionadas por meio de política ou contas de identidade do Oracle Identity Governance (OIG) e do Oracle Cloud Infrastructure (OCI) não são cobertas nesta revisão. Para obter mais informações sobre como executar revisões com base em permissões reconciliadas, consulte Revisões de Acesso de Identidade para Permissões Atribuídas Diretamente em Sistemas Gerenciados.
  • Em uma única campanha, não é possível combinar dois tipos diferentes de revisões de acesso. Por exemplo, se você criar uma campanha para revisar políticas, os critérios para revisões de acesso de identidade ou revisões de coleta de identidade não serão mais aplicáveis e serão desativados.
  • As campanhas podem ser certificadas por qualquer usuário ativo associado a um fluxo de trabalho de aprovação específico. Os revisores podem visualizar apenas suas tarefas de revisão associadas. Um revisor não associado a nenhum workflow de aprovação não pode executar tarefas em nenhuma revisão.
  • Se nenhuma revisão for gerada, ela irá automaticamente para o estado Pronto para aprovação.
  • Proprietário da Campanha:
    • deve ser um usuário ativo do Oracle Access Governance.
    • pode receber notificações por e-mail sempre que uma campanha avança por vários estados da campanha.
    • pode ser um revisor de revisão de acesso com base no mecanismo de fallback se o revisor original pretendido for inválido.
    • Pode gerenciar uma campanha de sua propriedade.
  • Você pode autoaprovar ou autocertificar seus acessos usando o modelo Usuário personalizado, Coleta de Identidade ou Proprietário. Você também pode aprovar automaticamente seus acessos ao usar o modelo de aprovação Beneficiário.
  • Você pode certificar privilégios de acesso para usuários consumidores, mas um usuário consumidor não pode ser um revisor de acesso.
  • Para revisões de política, você não deve modificar a política após as campanhas terem sido programadas. Isso resultará em falha ao concluir a solicitação de correção. As declarações de política devem ser consistentes durante todo o processo da campanha.
  • Para revisões de coleta de identidades, você não deve modificar membros após a programação das campanhas. Isso resultará em falha ao concluir a solicitação de correção. A lista de membros deve ser consistente durante todo o processo de campanha.