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

  • Artigo

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

As organizações com requisitos de conformidade ou planos de gerenciamento de riscos têm aplicativos sensíveis ou críticos para os negócios. A sensibilidade do aplicativo pode ser baseada em sua finalidade ou nos dados que contém, como informações financeiras ou informações pessoais dos clientes da organização. Para esses aplicativos, apenas um subconjunto de todos os usuários da organização está autorizado a ter acesso, e o acesso só deve ser permitido com base em requisitos de negócios documentados. O Microsoft Entra ID pode ser integrado com muitos aplicativos SaaS populares, aplicativos locais e aplicativos que sua organização desenvolve, usando interfaces de protocolo e API padrão. Por meio dessas interfaces, o Microsoft Entra ID pode ser a fonte autorizada para controlar quem tem acesso a esses aplicativos. À medida que você integra seus aplicativos com o Microsoft Entra ID, você pode usar as revisões de acesso para recertificar os usuários que têm acesso a esses aplicativos e remover o acesso dos usuários que não precisam mais de acesso. 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 em seu ambiente.

Pré-requisitos para rever o acesso

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

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

Embora o uso do recurso de revisões de acesso não exija que os usuários tenham essas licenças atribuídas a eles para usar o recurso, você precisa ter licenças 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 para revisar o acesso a um aplicativo, recomendamos também revisar regularmente a associação de funções de diretório privilegiadas que têm a capacidade de controlar o acesso de outros usuários a todos os aplicativos. Os administradores no , Identity Governance Administrator, User Administrator, Application AdministratorCloud Application Administrator e Privileged Role Administrator podem fazer alterações nos usuários e em suas atribuições de função de aplicativo, portanto, certifique-se de que a Global Administratorrevisão de acesso dessas funções de diretório tenha sido agendada.

Determinar como o aplicativo é integrado ao Microsoft Entra ID

Para que as revisões de acesso sejam usadas para um aplicativo, o aplicativo deve primeiro ser integrado ao ID do Microsoft Entra e representado em seu diretório. Um aplicativo que está sendo integrado com o Microsoft Entra ID significa que um dos dois requisitos deve ser atendido:

  • O aplicativo depende do Microsoft Entra ID para SSO federado e o Microsoft Entra ID controla a emissão do token de autenticação. Se o Microsoft Entra ID for o único provedor de identidade para o 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 que são negados por uma revisão perdem sua atribuição de função de aplicativo e não podem mais obter um novo token para entrar no aplicativo.
  • O aplicativo depende de listas de usuários ou grupos que são fornecidas ao aplicativo pelo 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, Microsoft Entra provisionando usuários no banco de dados do aplicativo ou grupos que são gravados no AD DS. Os usuários que são negados por uma revisão perdem sua atribuição de função de aplicativo ou associação de grupo e, quando essas alterações são disponibilizadas para o aplicativo, os usuários negados não terão mais acesso.

Se nenhum desses critérios for atendido para um aplicativo, como o aplicativo não depende do Microsoft Entra ID, as revisões de acesso ainda poderão ser usadas, no entanto, haverá algumas limitações. Os usuários que não estiverem na sua ID do Microsoft Entra ou que não estiverem atribuídos às funções do aplicativo na ID do Microsoft Entra não serão incluídos na revisão. Além disso, as alterações para remover negado não poderão ser enviadas automaticamente para o aplicativo se não houver nenhum protocolo de provisionamento suportado pelo aplicativo. Em vez disso, a organização deve ter um processo para enviar os resultados de uma revisão concluída para o aplicativo.

Para permitir que uma ampla variedade de aplicativos e requisitos de TI sejam abordados com o 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 e C que são apropriados para aplicativos para uso com governança de identidade. Saber qual padrão está sendo usado para um aplicativo específico ajuda você a configurar os recursos apropriados no Microsoft Entra ID para estar pronto para a revisão de acesso.

Fluxograma para padrões de integração de aplicativos

Padrão Padrão de integração de aplicativos Etapas para se preparar para uma revisão de acesso
A O aplicativo oferece suporte a SSO federado, o Microsoft Entra ID é o único provedor de identidade e o aplicativo não depende de declarações de grupo ou função. Nesse padrão, você configura que o aplicativo requer atribuições de função de aplicativo individuais e que os usuários são atribuídos ao aplicativo. Em seguida, para executar a revisão, crie uma única revisão de acesso para o aplicativo, dos usuários atribuídos a essa função de aplicativo. Quando a revisão for concluída, se um usuário tiver sido 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 o usuário não poderá entrar nesse aplicativo.
N Se o aplicativo usa declarações de grupo além de atribuições de função de aplicativo. Um aplicativo pode usar a associação de grupo do Ative Directory ou do Microsoft Entra, distinta das funções do aplicativo para expressar acesso mais refinado. Aqui, você pode escolher, com base em seus requisitos de negócios, fazer com que os usuários que têm atribuições de função de aplicativo sejam revisados ou revisar os usuários que têm associações de grupo. Se os grupos não fornecerem cobertura de acesso abrangente, em particular se os usuários puderem ter acesso ao aplicativo mesmo que não sejam membros desses grupos, recomendamos revisar as atribuições de função do aplicativo, como no padrão A anterior.
C Se o aplicativo não depender apenas do Microsoft Entra ID para SSO federado, mas oferecer suporte ao provisionamento via SCIM, por meio de atualizações para uma tabela SQL de usuários, tiver um diretório LDAP não AD ou suportar um protocolo de provisionamento SOAP ou REST. Nesse padrão, você configura a ID do Microsoft Entra para provisionar os usuários com atribuições de função de aplicativo para o banco de dados ou diretório do aplicativo, atualiza as atribuições de função de aplicativo na ID do Microsoft Entra com uma lista dos usuários que atualmente têm acesso e, em seguida, cria uma revisão de acesso único das atribuições de função de aplicativo. Para obter mais informações, consulte Governando os usuários existentes de um aplicativo para atualizar as atribuições de função do aplicativo na ID do Microsoft Entra.

Outras opções

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

  • Alguns Microsoft Online Services, como o Exchange Online, usam licenças. Embora as licenças de 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, poderá revisar as associações desses grupos.
  • Alguns aplicativos usam o consentimento delegado do usuário 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, os consentimentos não podem ser revisados. Em vez disso, você pode examinar quem pode se conectar ao aplicativo por meio de políticas de Acesso Condicional que podem ser baseadas em atribuições de função de aplicativo ou associações de grupo.
  • Se o aplicativo não oferecer 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 suporta apenas a 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 para o usuário, mas isso não impedirá que um usuário que já conhece a senha possa continuar a entrar no aplicativo. Para seus aplicativos locais, consulte Governar os usuários de um aplicativo que não oferece suporte ao provisionamento. Para aplicativos SaaS, peça ao fornecedor de SaaS para integrar a galeria de aplicativos para federação ou provisionamento, atualizando seu aplicativo para oferecer suporte a um protocolo padrão.

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

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

  1. Entre no centro de administração do Microsoft Entra como pelo menos um Administrador de Governança de Identidade.

  2. Navegue até >Identity>Applications>Enterprise Applications.

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

  4. Se o aplicativo ainda não estiver listado, verifique se o aplicativo está disponível na galeria de aplicativos para aplicativos que podem ser integrados para SSO federado ou provisionamento. Se estiver na galeria, use os tutoriais para configurar o aplicativo para federação e, se ele oferecer suporte ao provisionamento, configure também o aplicativo 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 do AD existentes para novos grupos do Microsoft Entra e configure o write-back do grupo para o AD. Em seguida, atualize o aplicativo para verificar os novos grupos do AD criados por write-back de grupo, conforme descrito em Governar aplicativos locais baseados no Ative Directory (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 do AD existentes para novos grupos do Microsoft Entra e configure o write-back do 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 Governar aplicativos locais baseados no Ative Directory (Kerberos).

  7. Se o aplicativo ainda não estiver listado, usar grupos de segurança do AD e não for um aplicativo Web, e a configuração do aplicativo puder ser alterada para procurar grupos de segurança diferentes no AD, mova a associação dos grupos de segurança do AD existentes para novos grupos do Microsoft Entra e configure o write-back do grupo para o AD. Em seguida, atualize o aplicativo para verificar os novos grupos do AD criados por write-back de grupo, conforme descrito em Governar aplicativos locais baseados no Ative Directory (Kerberos). Em seguida, continue na próxima seção.

  8. Se o aplicativo ainda não estiver listado, usar grupos de segurança do AD e não for um aplicativo Web, e a configuração do aplicativo não puder ser alterada para procurar grupos de segurança diferentes no AD, mova a associação dos grupos de segurança do AD existentes para novos grupos do Microsoft Entra e configure o write-back do 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 Governar aplicativos locais baseados no Ative Directory (Kerberos). Em seguida, continue na próxima seção.

  9. Quando o aplicativo estiver na lista de aplicativos corporativos em seu locatário, selecione o aplicativo na lista.

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

    Captura de tela que mostra o planejamento de atribuições de aplicativos.

  11. Mude para a guia Funções e administradores . Esta guia exibe as funções administrativas que dão direitos para controlar a representação do aplicativo no Microsoft Entra ID, não os direitos de acesso no aplicativo. Para cada função administrativa que tenha permissões para permitir a alteração da integração ou atribuições de aplicativos e tenha uma atribuição a essa função administrativa, certifique-se de que apenas usuários autorizados estejam nessa função.

  12. Mude para a guia Provisionamento . Se o provisionamento automático não estiver configurado, interrompido ou em quarentena, a ID do Microsoft Entra não terá como notificar o aplicativo quando o acesso de um usuário for removido se esse acesso for negado durante a revisão. O provisionamento pode não ser necessário para alguns padrões de integração, se o aplicativo for federado e depender exclusivamente da ID do Microsoft Entra como seu 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 oferecer suporte ao SSO federado com o Microsoft Entra ID como seu único provedor de identidade, você precisará configurar o provisionamento do Microsoft Entra ID para o aplicativo. O provisionamento é 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 essa etapa de remoção pode ser feita por meio de uma alteração enviada do ID do Microsoft Entra para o aplicativo por meio de SCIM, LDAP, SQL, SOAP ou REST.

Para obter mais informações, consulte integrando aplicativos com o Microsoft Entra ID.

  1. Se o provisionamento estiver configurado, selecione Editar mapeamentos de atributos, expanda a seção Mapeamento e selecione Provisionar usuários do Microsoft Entra. Verifique se na lista de mapeamentos de atributos, há um mapeamento para isSoftDeleted o atributo no armazenamento de dados do aplicativo que você gostaria de ter o ID do Microsoft Entra definido como false quando um usuário perde 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 oferecer suporte a SSO federado, mude para a guia Acesso Condicional. Inspecione as políticas habilitadas para este aplicativo. Se houver políticas habilitadas, bloqueiem o acesso, tenham usuários atribuídos às políticas, mas sem outras condições, esses usuários já podem estar impedidos de obter SSO federado para o aplicativo.

  3. Mude para a guia Usuários e grupos . Esta 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, já que não há acesso para o revisor analisar.

  4. Se seu aplicativo estiver integrado ao padrão C, você precisará confirmar se os usuários nessa lista são os mesmos que os do armazenamento de dados interno dos aplicativos, antes de iniciar a revisão. O Microsoft Entra ID não importa automaticamente os usuários ou seus direitos de acesso de um aplicativo, mas você pode atribuir usuários a uma função de aplicativo por meio do PowerShell. Consulte Governando os usuários existentes de um aplicativo para saber como trazer usuários de diferentes armazenamentos de dados de aplicativos para o ID do Microsoft Entra 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, se você criar uma revisão de acesso do aplicativo, todas as atribuições a todas as funções do aplicativo serão revisadas juntas.

  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 do aplicativo. É possível rever esta aplicação se existir um grupo atribuído a uma função; No entanto, um usuário que seja membro do grupo atribuído à função e cujo acesso foi negado não será removido automaticamente do grupo. Se o aplicativo em si 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 um usuário cujo acesso é negado durante a revisão de acesso possa ter sua atribuição de função de aplicativo removida automaticamente. Se o aplicativo depender de grupos e todos os grupos do aplicativo forem atribuídos à mesma função de aplicativo, você revisará as associações de grupo em vez de revisar as atribuições do aplicativo.

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

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

  1. Entre no centro de administração do Microsoft Entra como pelo menos 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 está atribuído e se a origem é nuvem. Se o aplicativo usa um grupo dinâmico ou um grupo sincronizado localmente, essas associações de grupo não podem ser alteradas no Microsoft Entra ID. Recomendamos converter o aplicativo em grupos criados no Microsoft Entra ID com associações atribuídas e, em seguida, copiar os usuários membros para esse novo grupo.
  5. Mude para a guia Funções e administradores . Esta guia exibe as funções administrativas que concedem direitos para controlar a representação do grupo no Microsoft Entra ID, não os direitos de acesso no aplicativo. Para cada função administrativa que permite alterar a associação ao grupo e tem usuários nessa função administrativa, certifique-se de que apenas usuários autorizados estejam nessa função.
  6. Mude para a guia Membros . Verifique se os membros do grupo são usuários e se não há membros não-usuários ou 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 . Certifique-se de que nenhum usuário não autorizado seja mostrado como proprietário. Se você estiver solicitando aos proprietários do grupo que realizem a revisão de acesso de um grupo, confirme se o grupo tem um ou mais proprietários.

Selecione os revisores apropriados

Ao criar cada revisão de acesso, os administradores podem escolher um ou mais revisores. Os revisores podem realizar 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 realizar uma revisão. Se você estiver criando uma revisão de um grupo, como parte do acesso de revisão para um aplicativo integrado no padrão B, poderá selecionar os proprietários do grupo como revisores. Como os aplicativos no Microsoft Entra ID não têm necessariamente um proprietário, a opção para selecionar o proprietário do aplicativo como revisor não é possível. Em vez disso, ao criar a revisão, você pode fornecer os nomes dos proprietários do aplicativo para serem os revisores.

Você também pode escolher, ao criar uma revisão de um grupo ou aplicativo, por ter uma revisão de vários estágios. Por exemplo, você pode optar por fazer com que o gerente de cada usuário atribuído execute o primeiro estágio da revisão e o proprietário do recurso o segundo estágio. Dessa forma, o proprietário do recurso pode se concentrar nos usuários que já foram aprovados por seu gerente.

Antes de criar as avaliações, verifique se você tem assentos suficientes de SKU de Governança do Microsoft Entra ID P2 ou Microsoft Entra ID no seu locatário. Além disso, verifique se todos os revisores são usuários ativos com endereços de e-mail. Quando as revisões de acesso começam, cada uma delas analisa um e-mail do Microsoft Entra ID. Se o revisor não tiver uma caixa de correio, ele não receberá o e-mail quando a avaliação começar ou um lembrete por e-mail. E, se eles forem impedidos de entrar no Microsoft Entra ID, eles não poderão realizar a revisão.

Crie as avaliações

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

  1. Para esta etapa, você deve estar na Identity Governance Administrator função.

  2. Nos padrões A e C, você cria 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 do aplicativo.

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

    Nota

    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 está 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 no aplicativo pela última vez. Se o recurso for um grupo, as recomendações serão baseadas no intervalo em que o usuário entrou pela última vez em qualquer aplicativo no locatário, não apenas no aplicativo que usa esses grupos.

  4. Quando as avaliações de acesso começarem, peça aos revisores para dar entrada. Por padrão, cada um deles recebe um e-mail do Microsoft Entra ID com um link para o painel de acesso, onde analisam a associação aos grupos ou o acesso ao aplicativo.

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

Depois que as avaliações começarem, você poderá monitorar seu progresso e atualizar os aprovadores, se necessário, até que a revisão seja concluída. Em seguida, você pode confirmar se os usuários, cujo acesso foi negado pelos revisores, estão tendo seu 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 do usuário de acesso contínuo, até que a revisão de acesso seja concluída.

  2. Se a opção de aplicação automática não tiver sido selecionada quando a avaliação foi criada, você precisará aplicar os resultados da avaliação quando ela for concluída.

  3. Aguarde até que o status da revisão mude para Resultado aplicado. Você deve esperar ver usuários negados, se houver, sendo removidos da associação ao grupo ou atribuição de aplicativo em alguns minutos.

  4. Se você configurou anteriormente o provisionamento de usuários para o aplicativo, quando os resultados forem aplicados, a ID do Microsoft Entra começará a desprovisionar 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ê configurou o write-back de grupo para os grupos revisados, aguarde até que o write-back de grupo seja concluído no Microsoft Entra Cloud Sync e as alterações se propaguem para todos os controladores de domínio.

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

  7. Se desejar, você também pode baixar um relatório do histórico de avaliações concluídas.

  8. Por quanto tempo um usuário a quem foi negado acesso contínuo poderá continuar a usar um aplicativo federado depende do tempo de vida da sessão do próprio aplicativo e do tempo de vida do token de acesso. Se os aplicativos usassem Kerberos, como o Kerberos armazena em cache as associações de grupo de um usuário quando eles entram em um domínio, os usuários podem continuar a ter acesso até que seus tíquetes Kerberos expirem. Para saber mais sobre como controlar o tempo de vida dos tokens de acesso, consulte Tempos de vida dos tokens configuráveis.

Próximos passos