Preparar-se para uma revisão de acesso de usuários a um aplicativo

  • Artigo

O Microsoft Entra ID Governance permite que você equilibre a necessidade de segurança e produtividade dos funcionários da sua organização com os processos e a visibilidade certas. Ele fornece recursos para garantir que as pessoas certas tenham o acesso certo aos recursos certos.

Organizações com requisitos de conformidade ou planos de gerenciamento de riscos têm aplicativos confidenciais ou comercialmente críticos. A confidencialidade do aplicativo pode ser baseada na finalidade ou nos dados que ele contém, como informações financeiras ou pessoais dos clientes da organização. Para esses aplicativos, apenas um subconjunto de todos os usuários da organização terá o acesso autorizado, e o acesso só será permitido com base nos requisitos de negócios documentados. O Microsoft Entra ID pode ser integrado a vários aplicativos SaaS populares, aplicativos locais e aplicativos que sua organização desenvolveu, usando o protocolo padrão e interfaces de API. Por meio dessas interfaces, o Microsoft Entra ID pode ser a fonte autoritativa para controlar quem tem acesso a esses aplicativos. Ao integrar seus aplicativos ao Microsoft Entra ID, você pode usar as revisões de acesso para certificar novamente os usuários que têm acesso a esses aplicativos e remover o acesso daqueles que não precisam mais. Você também pode usar outros recursos, incluindo termos de uso, acesso condicional e gerenciamento de direitos, para controlar o acesso a aplicativos, conforme descrito em Como controlar o acesso a aplicativos no seu ambiente.

Pré-requisitos para revisar o acesso

Para usar o Microsoft Entra ID para uma revisão de acesso a um aplicativo, você precisa ter uma das seguintes licenças no locatário:

  • Microsoft Entra ID P2 ou Microsoft Entra ID Governance
  • Licença do Enterprise Mobility + Security (EMS) E5

Embora o uso do recurso de revisões de acesso não exija que as licenças estejam atribuídas ao usuários para que eles usem o recurso, você precisará ter licença suficientes. Para obter mais informações, consulte Cenários de licença de exemplo para revisões de acesso.

Além disso, embora não seja necessário revisar o acesso a um aplicativo, recomendamos também a revisão regular da associação de funções de diretório com privilégios que tenham a capacidade de controlar o acesso de outros usuários a todos os aplicativos. Os administradores com as funções Global Administrator, Identity Governance Administrator, User Administrator, Application Administrator, Cloud Application Administrator e Privileged Role Administrator podem fazer alterações nos usuários e nas atribuições de função de aplicativo, portanto, verifique se a revisão de acesso dessas funções de diretório foi agendada.

Determinar como o aplicativo é integrado ao Microsoft Entra ID

Para que as revisões de acesso sejam usadas para um aplicativo, o aplicativo precisa primeiro ser integrado ao Microsoft Entra ID e representado no seu diretório. Um aplicativo integrado à ID do Microsoft Entra significa que um destes dois requisitos precisa ser atendido:

  • O aplicativo depende do Microsoft Entra ID para o SSO federado, e o Microsoft Entra ID controla a emissão de tokens de autenticação. Se o Microsoft Entra ID for o único provedor de identidade do aplicativo, somente os usuários atribuídos a uma das funções do aplicativo no Microsoft Entra ID poderão entrar no aplicativo. Os usuários negados em uma revisão perdem a atribuição de função de aplicativo e não podem mais obter um novo token para entrar nele.
  • O aplicativo depende de listas de usuários ou de grupos que recebe do Microsoft Entra ID. Esse preenchimento pode ser feito por meio de um protocolo de provisionamento, como o System for Cross-Domain Identity Management (SCIM), pelo aplicativo consultando o Microsoft Entra ID via Microsoft Graph, o Microsoft Entra provisionando usuários no banco de dados do aplicativo ou grupos que são gravados no AD DS. Os usuários negados em uma revisão perdem a atribuição de função de aplicativo ou a associação a um grupo e, quando essas alterações são disponibilizadas ao aplicativo, esses usuários perdem o acesso.

Se nenhum desses critérios for atendido em um aplicativo, como o aplicativo não depende do Microsoft Entra ID, as revisões de acesso ainda poderão ser usadas, mas poderá haver algumas limitações. Os usuários que não estão no seu Microsoft Entra ID ou não estão atribuídos às funções de aplicativo no Microsoft Entra ID, não serão incluídos na revisão. Além disso, as alterações de remoção dos negados não poderão ser enviadas automaticamente ao aplicativo se não houver nenhum protocolo de provisionamento compatível com o aplicativo. A organização precisa ter um processo para enviar os resultados de uma revisão concluída ao aplicativo.

Para permitir que uma ampla variedade de requisitos de aplicativos e de TI sejam atendidos pelo Microsoft Entra ID, há vários padrões de como um aplicativo pode ser integrado ao Microsoft Entra ID. Cada padrão faz uso de diferentes artefatos do Microsoft Entra. O fluxograma a seguir ilustra como selecionar entre três padrões de integração, A, B ou C, apropriados para aplicativos usados com governança de identidade. É interessante saber qual padrão está sendo usado em um aplicativo específico para que você possa configurar os recursos apropriados no Microsoft Entra ID como preparação para a revisão de acesso.

Flowchart for application integration patterns

Padrão Padrão de integração de aplicativo Etapas de preparação para uma revisão de acesso
A O aplicativo dá suporte ao SSO federado, o Microsoft Entra ID é o único provedor de identidade e o aplicativo não depende de declarações de grupo ou de função. Nesse padrão, você vai configurar que o aplicativo requer atribuições de função de aplicativo individuais e que os usuários são atribuídos ao aplicativo. Depois, para executar a revisão, você criará para o aplicativo uma só revisão de acesso dos usuários atribuídos a essa função de aplicativo. Quando a revisão for concluída, se um usuário for negado, ele será removido da função de aplicativo. O Microsoft Entra ID não emitirá mais tokens de federação para esse usuário e ele não poderá entrar nesse aplicativo.
B Se o aplicativo usar declarações de grupo além de atribuições de função de aplicativo. Um aplicativo pode usar uma associação de grupo do Active Directory ou do Microsoft Entra, diferente das funções de aplicativo, para expressar um acesso mais refinado. Aqui, com base nos requisitos de negócios, você pode escolher que os usuários com atribuições de função de aplicativo sejam revisados ou revisar os usuários que têm associações a um grupo. Se os grupos não fornecerem uma cobertura de acesso abrangente, ou seja, se os usuários puderem ter acesso ao aplicativo mesmo que não sejam membros desse grupos, recomendamos a revisão das atribuições de função de aplicativo, como no padrão A acima.
C Se o aplicativo não depender exclusivamente do Microsoft Entra ID para o SSO federado, mas oferecer suporte ao provisionamento via SCIM, por meio de atualizações em uma tabela SQL de usuários, tiver um diretório LDAP que não seja do AD ou oferecer suporte a um protocolo de provisionamento SOAP ou REST. Nesse padrão, você vai configurar o Microsoft Entra ID para provisionar os usuários com atribuições de função de aplicativo no banco de dados ou no diretório do aplicativo, atualizar as atribuições de função de aplicativo no Microsoft Entra ID com uma lista dos usuários que têm acesso no momento e criar uma só revisão de acesso das atribuições de função de aplicativo. Para obter mais informações, confira Controlar os usuários existentes de um aplicativo para atualizar as atribuições de função de aplicativo no Microsoft Entra ID.

Outras opções

Os padrões de integração listados na seção anterior são aplicáveis a aplicativos SaaS de terceiros ou a aplicativos que foram desenvolvidos pela sua organização ou para ela.

  • Alguns Serviços Online da Microsoft, como o Exchange Online, usam licenças. Embora as licenças do usuário não possam ser revisadas diretamente, se você estiver usando atribuições de licença baseadas em grupo, com grupos com usuários atribuídos, você poderá examinar as associações desses grupos.
  • Alguns aplicativos usam o consentimento do usuário delegado para controlar o acesso ao Microsoft Graph ou a outros recursos. Como os consentimentos de cada usuário não são controlados por um processo de aprovação, eles não podem ser revisados. Nesse caso, você pode revisar quem pode se conectar ao aplicativo por meio de políticas de acesso condicional, que podem ser baseada em atribuições de função de aplicativo ou associações de grupo.
  • Se o aplicativo não der suporte a protocolos de federação ou provisionamento, você precisará de um processo para aplicar manualmente os resultados quando uma revisão for concluída. Para um aplicativo que dá suporte apenas à integração de SSO de senha, se uma atribuição de aplicativo for removida quando uma revisão for concluída, o aplicativo não aparecerá na página myapps do usuário, mas isso não impedirá que um usuário que já saiba a senha continue a entrar no aplicativo. Para seus aplicativos locais, consulte controlar os usuários de um aplicativo que não dá suporte ao provisionamento. Para aplicativos SaaS, peça que o fornecedor do SaaS se integre à galeria de aplicativos para federação ou provisionamento atualizando o aplicativo para dar suporte a um protocolo padrão.

Verificar se o aplicativo está pronto para a revisão

Agora que você identificou o padrão de integração do aplicativo, verifique se o aplicativo representado no Microsoft Entra ID está pronto para revisão.

  1. Entre no Centro de administração do Microsoft Entra como, no mínimo, um Administrador de Governança de Identidade.

  2. Navegue até >Identidade>Aplicativos>Aplicativos empresariais.

  3. Aqui você pode verificar se o aplicativo está na lista de aplicativos empresariais em seu locatário.

  4. Se o aplicativo ainda não estiver listado, verifique se ele está disponível na galeria de aplicativos em aplicativos que podem ser integrados para SSO federado ou provisionamento. Se ele estiver na galeria, siga os tutoriais para configurá-lo para federação e, se ele der suporte ao provisionamento, configure-o também para provisionamento.

  5. Se o aplicativo ainda não estiver listado, mas usar grupos de segurança do AD e for um aplicativo Web, e a configuração do aplicativo puder ser alterada para procurar grupos de segurança diferentes no AD, adicione o aplicativo para acesso remoto por meio do Proxy de Aplicativo, mova a associação dos grupos de segurança existentes do AD para novos grupos do Microsoft Entra e configure o write-back de grupo para o AD. Em seguida, atualize o aplicativo para verificar os novos grupos do AD criados pelo write-back de grupo, conforme descrito em Controlar aplicativos baseados no Active Directory local (Kerberos).

  6. Se o aplicativo ainda não estiver listado, mas usar grupos de segurança do AD e for um aplicativo Web, e a configuração do aplicativo não puder ser alterada para procurar grupos de segurança diferentes no AD, adicione o aplicativo para acesso remoto por meio do Proxy de Aplicativo, mova a associação dos grupos de segurança existentes do AD para novos grupos do Microsoft Entra e configure o write-back de grupo para o AD. Em seguida, atualize os grupos de segurança do AD existentes que o aplicativo estava verificando para incluir os novos grupos como membro, conforme descrito em Controlar aplicativos baseados no Active Directory local (Kerberos).

  7. Se o aplicativo ainda não estiver listado, use grupos de segurança do AD e não seja um aplicativo Web e a configuração do aplicativo poderá ser alterada para procurar grupos de segurança diferentes no AD e, em seguida, mover a associação dos grupos de segurança existentes do AD para novos grupos do Microsoft Entra e configurar o write-back de grupo para o AD. Em seguida, atualize o aplicativo para verificar os novos grupos do AD criados pelo write-back de grupo, conforme descrito em Controlar aplicativos baseados no Active Directory local (Kerberos). Depois, siga para a próxima seção.

  8. Se o aplicativo ainda não estiver listado, use grupos de segurança do AD e não seja um aplicativo Web e a configuração do aplicativo não poderá ser alterada para procurar grupos de segurança diferentes no AD e, em seguida, mover a associação dos grupos de segurança existentes do AD para novos grupos do Microsoft Entra e configurar o write-back de grupo para o AD. Em seguida, atualize os grupos de segurança do AD existentes que o aplicativo estava verificando para incluir os novos grupos como membro, conforme descrito em Controlar aplicativos baseados no Active Directory local (Kerberos). Depois, siga para a próxima seção.

  9. Quando o aplicativo estiver na lista de aplicativos empresariais no locatário, selecione-o na lista.

  10. Mude para a guia Propriedades. Verifique se a opção Atribuição de usuário necessária? está definida como Sim. Se ela estiver definida como Não, todos os usuários no diretório, incluindo as identidades externas, poderão acessar o aplicativo e você não poderá revisar o acesso a ele.

    Screenshot that shows planning app assignments.

  11. Altere para a guia Funções e administradores. Essa guia exibe as funções administrativas que dão direitos de controle de representação do aplicativo no Microsoft Entra ID, não direitos de acesso no aplicativo. Para cada função administrativa que tiver permissões para permitir a alteração da integração ou das atribuições do aplicativo e tiver uma atribuição a essa função administrativa, verifique se somente os usuários autorizados estão nessa função.

  12. Mude para a guia Provisionamento. Se o provisionamento automático não estiver configurado, for interrompido ou estiver em quarentena, o Microsoft Entra ID não terá como notificar o aplicativo quando o acesso de um usuário for removido se o acesso for negado durante a revisão. O provisionamento poderá não ser necessário para alguns padrões de integração, se o aplicativo for federado e depender apenas do Microsoft Entra ID como provedor de identidade ou se o aplicativo usar grupos do AD DS. No entanto, se a integração do aplicativo for o padrão C e o aplicativo não der suporte ao SSO federado com o Microsoft Entra ID como o único provedor de identidade, você precisará configurar o provisionamento do Microsoft Entra ID para o aplicativo. O provisionamento será necessário para que o Microsoft Entra ID possa remover automaticamente os usuários revisados do aplicativo quando uma revisão for concluída e para que essa etapa de remoção possa ser feita por meio de uma alteração enviada do Microsoft Entra ID ao aplicativo por meio de SCIM, LDAP, SQL, SOAP ou REST.

Para obter mais informações, consulte integração de aplicativos ao Microsoft Entra ID.

  1. Se o provisionamento estiver configurado, clique em Editar Mapeamentos de Atributo, expanda a seção Mapeamento e clique em Provisionar Usuários do Microsoft Entra. Verifique se, na lista de mapeamentos de atributo, há um mapeamento de isSoftDeleted para o atributo no armazenamento de dados do aplicativo que você queira definir como false quando um usuário perder o acesso. Se esse mapeamento não estiver presente, o Microsoft Entra ID não notificará o aplicativo quando um usuário sair do escopo, conforme descrito em como o provisionamento funciona.

  2. Se o aplicativo der suporte ao SSO federado, mude para a guia Acesso Condicional. Inspecione as políticas habilitadas para esse aplicativo. Se houver políticas que estejam habilitadas, bloqueiem o acesso, tenham usuários atribuídos a elas, mas nenhuma outra condição, esses usuários já poderão estar impedidos de obter o SSO federado para o aplicativo.

  3. Mude para a guia Usuários e grupos. Essa lista contém todos os usuários atribuídos ao aplicativo no Microsoft Entra ID. Se a lista estiver vazia, uma revisão do aplicativo será concluída imediatamente, pois não há nenhuma tarefa para o revisor executar.

  4. Se o aplicativo estiver integrado ao padrão C, você precisará confirmar que os usuários nessa lista são iguais aos do armazenamento de dados interno do aplicativo, antes de iniciar a revisão. O Microsoft Entra ID não importa automaticamente os usuários nem os direitos de acesso de um aplicativo, mas você pode atribuir usuários a uma função de aplicativo por meio do PowerShell. Confira Controlar os usuários existentes de um aplicativopara saber como trazer usuários de diferentes armazenamentos de dados de aplicativos para o Microsoft Entra ID e atribuí-los a uma função de aplicativo.

  5. Verifique se todos os usuários estão atribuídos à mesma função de aplicativo, como Usuário. Se os usuários forem atribuídos a várias funções e você criar uma revisão de acesso do aplicativo, todas as atribuições a todas as funções do aplicativo serão revisadas em conjunto.

  6. Verifique a lista de objetos de diretório atribuídos às funções para confirmar se não há grupos atribuídos às funções de aplicativo. Será possível revisar esse aplicativo quando houver um grupo atribuído a uma função, mas um usuário membro do grupo atribuído à função cujo acesso foi negado não será removido automaticamente do grupo. Se o aplicativo não depender de grupos, recomendamos primeiro converter o aplicativo para ter atribuições diretas de usuário, em vez de membros de grupos, para que quando o acesso de um usuário for negado durante a revisão de acesso, a atribuição de função de aplicativo dele seja removida automaticamente. Se o aplicativo depender de grupos, e todos os grupos do aplicativo forem atribuídos à mesma função de aplicativo, você examinará as associações de grupo em vez de examinar as atribuições do aplicativo.

Verificar se os grupos estão prontos para a revisão

Se o aplicativo não depende de grupos, vá para a próxima seção. Caso contrário, se a integração de aplicativo também exigir que um ou mais grupos sejam revisados, conforme a descrição no padrão B, verifique se cada grupo está pronto para revisão.

  1. Entre no Centro de administração do Microsoft Entra como, no mínimo, um Administrador de Governança de Identidade.
  2. Navegue até >Grupos.
  3. Pesquise e selecione cada grupo na lista.
  4. Na guia Visão Geral, verifique se o Tipo de associação é Atribuído e se a Origem é Nuvem. Se o aplicativo usa um grupo dinâmico ou um grupo sincronizado do ambiente local, essas associações a um grupo não poderão ser alteradas no Microsoft Entra ID. Recomendamos converter o aplicativo em grupos criados no Microsoft Entra ID com associações atribuídas e copiar os usuários membros para esse novo grupo.
  5. Altere para a guia Funções e administradores. Essa guia exibe as funções administrativas que dão direitos de controle de representação do grupo no Microsoft Entra ID, não direitos de acesso no aplicativo. Para cada função administrativa que permite alterar a associação a um grupo e contém usuários, verifique se há somente usuários autorizados.
  6. Mude para a guia Membros. Verifique se os membros do grupo são usuários e se não há membros que não sejam usuários nem grupos aninhados. Se não houver membros de um grupo quando a revisão for iniciada, a revisão desse grupo será concluída imediatamente.
  7. Mude para a guia Proprietários. Verifique se nenhum usuário não autorizado seja mostrado como proprietário. Se você solicitar que os proprietários do grupo executem a revisão de acesso de um grupo, confirme se o grupo tem um ou mais proprietários.

Selecionar os revisores apropriados

Quando você cria uma revisão de acesso, os administradores podem escolher um ou mais revisores. Todos os revisores podem iniciar e executar uma revisão escolhendo usuários para acesso contínuo a um recurso ou removendo-os.

Normalmente, um proprietário de recurso é responsável por executar uma revisão. Ao criar uma revisão de grupo durante a revisão do acesso de um aplicativo integrado ao padrão B, você poderá selecionar os proprietários do grupo como revisores. Como os aplicativos no Microsoft Entra ID não têm necessariamente um proprietário, não é possível selecionar o proprietário do aplicativo como revisor. Nesse caso, ao criar a revisão, você pode fornecer os nomes dos proprietários do aplicativo para serem os revisores.

Ao criar uma revisão de um grupo ou de um aplicativo, você também pode optar por fazer uma revisão em várias fases. Por exemplo, você pode selecionar que o gerente de cada usuário atribuído execute a primeira fase da revisão e o proprietário do recurso execute a segunda fase. Dessa forma, o proprietário do recurso pode se concentrar nos usuários que já foram aprovados pelo gerente.

Antes de criar as revisões, verifique se você tem estações suficientes do Microsoft Entra ID P2 ou do SKU do Microsoft Entra ID Governance em seu locatário. Além disso, verifique se todos os revisores são usuários ativos com endereços de email. Quando as revisões de acesso começarem, cada um deles revisará um email do Microsoft Entra ID. Se o revisor não tiver uma caixa de correio, ele não receberá o email quando a revisão for iniciada nem um lembrete por email. E, se eles forem impedidos de entrar no Microsoft Entra ID, não poderão executar a revisão.

Criar as revisões

Depois de identificar os recursos, o aplicativo e, opcionalmente, um ou mais grupos, com base no padrão de integração e em quem devem ser os revisores, você poderá configurar o Microsoft Entra ID para iniciar as revisões.

  1. Para essa etapa, você precisará estar na função Global administrator ou Identity Governance administrator.

  2. Nos padrões A e C, você criará uma revisão de acesso selecionando o aplicativo. Siga as instruções no guia para criar uma revisão de acesso de grupos ou aplicativos para criar a revisão das atribuições de função de aplicativo.

  3. Se o aplicativo estiver integrado ao padrão B, use o mesmo guia a fim de criar revisões de acesso adicionais para cada um dos grupos.

    Observação

    Se você criar uma revisão de acesso e habilitar auxiliares de decisão de revisão, o auxiliar de decisão variará dependendo do recurso que estiver sendo revisado. Se o recurso for um aplicativo, as recomendações serão baseadas no período de intervalo de 30 dias, dependendo de quando o usuário entrou pela última vez no aplicativo. Se o recurso for um grupo, as recomendações serão baseadas no intervalo desde quando o usuário entrou pela última vez em qualquer aplicativo no locatário, não apenas no aplicativo que usa esses grupos.

  4. Quando a revisão de acesso começar, solicite que os revisores respondam. Por padrão, cada um receberá um email do Microsoft Entra ID com um link para o painel de acesso, em que revisarão as associações aos grupos ou o acesso ao aplicativo.

Exibir as atribuições que são atualizadas quando as revisões forem concluídas

Depois que as revisões forem iniciadas, você poderá monitorar o progresso e atualizar os aprovadores, se necessário, até que a revisão seja concluída. Depois, você poderá confirmar os usuários cujo acesso foi negado pelos revisores tiveram o acesso removido do aplicativo.

  1. Monitore as revisões de acesso, garantindo que os revisores estejam fazendo seleções para aprovar ou negar a necessidade de acesso contínuo do usuário até que a revisão de acesso seja concluída.

  2. Se a aplicação automática não for selecionada quando a revisão for criada, você precisará aplicar os resultados da revisão quando ela for concluída.

  3. Aguarde até que o status da revisão seja alterado para Resultado aplicado. É necessário esperar que os usuários negados, se houver algum, sejam removidos da associação do grupo ou da atribuição do aplicativo em alguns minutos.

  4. Se você já tiver configurado o provisionamento de usuários para o aplicativo, quando os resultados forem aplicados, o Microsoft Entra ID começará a desprovisionar os usuários negados do aplicativo. Você pode monitorar o processo de desprovisionamento de usuários. Se o provisionamento indicar um erro com o aplicativo, você poderá baixar o log de provisionamento para investigar se houve um problema com o aplicativo.

  5. Se você tiver configurado o write-back de grupo para os grupos revisados, aguarde até que o write-back do grupo seja concluído no Microsoft Entra Cloud Sync e as alterações sejam propagadas para todos os controladores de domínio.

  6. Se o provisionamento não foi configurado para o aplicativo, poderá ser necessário copiar separadamente a lista de usuários negados para o aplicativo. Por exemplo, em revisões de acesso de um grupo gerenciado pelo Windows Server AD, use este script de exemplo do PowerShell. O script descreve as chamadas do Microsoft Graph necessárias e exporta os cmdlets do PowerShell do Windows Server AD para realizar as alterações.

  7. Se desejar, você também poderá baixar um relatório de histórico de revisão com as revisões concluídas.

  8. O período de tempo em que um usuário com acesso contínuo negado poderá continuar usando um aplicativo federado dependerá do tempo de vida da sessão do aplicativo e do tempo de vida do token de acesso. Se os aplicativos usarem Kerberos, uma vez que o Kerberos armazena as associações de grupo de um usuário quando ele entra em um domínio, os usuários poderão continuar a ter acesso até que seus tíquetes Kerberos expirem. Para saber como controlar o tempo de vida dos tokens de acesso, confira Tempos de vida de token configuráveis.

Próximas etapas