Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Descrição geral
Microsoft Entra ID está a implementar um modelo de aplicação melhorado para políticas de Acesso Condicional que visam Todos os recursos e incluem uma ou mais exclusões de recursos. Esta alteração garante que os log-ins que solicitam apenas os escopos baseline recebem as mesmas proteções de Acesso Condicional que outros acessos a recursos.
Anteriormente, certos escopos de baixo privilégio eram automaticamente excluídos da aplicação da política quando existia uma exclusão de recursos. Com esta alteração, esses escopos passaram a ser avaliados como acesso a diretórios e estão sujeitos às suas políticas de Acesso Condicional.
Para contexto técnico detalhado, veja Novo comportamento de Acesso Condicional quando uma política para TODOS os recursos tem uma exclusão de recursos.
Importante
Esta atualização de fiscalização está alinhada com a Iniciativa Futuro Seguro da Microsoft e com investimentos em defesa em profundidade. A Microsoft recomenda adotar o novo modelo de fiscalização para melhorar a sua postura de segurança.
Quem é afetado
Esta alteração afeta o seu inquilino se todas as seguintes condições forem verdadeiras:
- Tem uma ou mais políticas de Acesso Condicional que visam todos os recursos.
- Essas políticas têm uma ou mais exclusões de recursos.
- Os utilizadores do seu tenant iniciam sessão através de aplicações que solicitam apenas escopos de referência.
Se as suas políticas visam Todos os recursos sem exclusão de recursos, esta alteração não o afeta.
O que são os âmbitos de referência
Parâmetros de referência é um termo guarda-chuva para o seguinte conjunto de escopos:
-
Escopos OpenID Connect (OIDC):
email,offline_access,openid,profile -
Escopos de diretório base:
User.Read,User.Read.All,User.ReadBasic.All,People.Read,People.Read.All,GroupMember.Read.All,Member.Read.Hidden
O que está a mudar
Após a implementação, os seguintes cenários podem agora desencadear desafios de Acesso Condicional (como MFA ou conformidade com dispositivos) quando o acesso era anteriormente concedido sem aplicação:
-
Aplicações clientes públicas (como aplicações de ambiente de trabalho) que solicitam apenas escopos de base. Por exemplo, um utilizador inicia sessão no cliente de ambiente de trabalho do Visual Studio Code, que solicita
openideprofile, ou na CLI do Azure, que solicita apenasUser.Read. -
Aplicações cliente confidenciais (como aplicações web) que são excluídas de uma política de Todos os recursos e solicitam apenas escopos de diretório base. Por exemplo, uma aplicação web excluída da política que solicita apenas
User.ReadePeople.Read.
Os desafios exatos dependem dos controlos de acesso configurados nas suas políticas que visam Todos os recursos ou visam explicitamente o Windows Azure Active Directory (também conhecido como diretório Microsoft Entra ID) como recurso.
O que não muda
- Quando uma aplicação (pública ou confidencial) solicita qualquer âmbito além dos âmbitos de referência (por exemplo,
Mail.Read), a aplicação já está sujeita a Acesso Condicional. Este comportamento não muda. - Para aplicações confidenciais de clientes que são excluídas das políticas de Todos os recursos e solicitam apenas os âmbitos OIDC, não se espera qualquer alteração.
O que precisas de fazer
Use a tabela seguinte para determinar as ações necessárias para as suas candidaturas:
| Tipo de aplicação | Propriedade | Ação necessária |
|---|---|---|
| Cliente público a solicitar apenas escopos de referência | Qualquer | Revise se estes pedidos devem permanecer isentos da aplicação do Acesso Condicional. Se existirem razões comerciais válidas para manter uma isenção, consulte Manter comportamento legado com definições de âmbito base. |
| Cliente confidencial que solicita apenas escopos de diretório base, excluído da política de todos os recursos | Propriedade do inquilino | Revise se a exclusão ainda é necessária. Trabalhe com os seus programadores de aplicações para avaliar se a aplicação pode solicitar escopos OIDC (como openid, profile) em vez de escopos de diretório como User.Read para informações básicas de utilizador. Se as atualizações não puderem ser concluídas antes do lançamento, veja Manter comportamento legado com definições de âmbito base. |
| Cliente confidencial que solicita apenas escopos de diretório base, excluído da política de todos os recursos | Propriedade da ISV | Revise se a exclusão ainda é necessária. Colabore com o seu ISV para avaliar se a aplicação pode solicitar escopos OIDC em vez de escopos do diretório. Na maioria dos casos, os escopos OIDC fornecem o acesso com privilégios mínimos necessários para estes cenários. Se o ISV não conseguir fazer atualizações a tempo, veja Manter comportamento legado com definições de âmbito base. |
Importante
Para aplicações clientes públicas e confidenciais pertencentes ao seu inquilino, certifique-se de que a aplicação consegue lidar com desafios de Acesso Condicional (por exemplo, MFA ou conformidade com dispositivos). Se não, podem ser necessárias atualizações da candidatura. Consulte as orientações para programadores de Acesso Condicional sobre como atualizar a sua aplicação de forma adequada.
Como avaliar o impacto
Pré-visualizar a alteração na execução
Pode pré-visualizar o comportamento de aplicação melhorado antes do início da implementação:
- Inicie sessão no centro de administração Microsoft Entra pelo menos como administrador Acesso Condicional.
- Aceda às definições de âmbitos de linha de base em Acesso Condicional. Este link direto é necessário para visualizar as definições de pré-visualização.
- Escolha recurso-alvo predefinido (Windows Azure Active Directory).
- Selecione Guardar.
Observação
Esta definição ativa imediatamente as políticas atualizadas de comportamento de Acesso Condicional para Todos os recursos com exclusões.
Como resultado, alguns logins de utilizadores que anteriormente não estavam sujeitos à aplicação da CA podem agora ser avaliados e aplicados sob Acesso Condicional, usando Windows Azure Active Directory como recurso alvo.
Para reverter ao comportamento legado, selecione reiniciar nas definições do âmbito Baseline.
Se um recurso alvo personalizado não for selecionado, o lançamento baseado em Windows Azure Active Directory como recurso alvo padrão para os scopes base é aplicado em fases.
Identificar aplicações afetadas com um recurso alvo personalizado
Pode usar definições de âmbito base para identificar quais as aplicações no seu tenant que são afetadas. Uma vez ativada a definição de pré-visualização, os eventos de início de sessão onde as aplicações solicitam os âmbitos de referência listam a aplicação personalizada como audiência de Acesso Condicional nos registos de início de sessão. Para mais informações, consulte Resolver problemas de início de sessão com Acesso Condicional.
Consulta para aplicações afetadas
Use a seguinte consulta Microsoft Graph para listar aplicações que solicitam apenas os escopos base:
https://graph.microsoft.com/beta/auditLogs/signIns?$filter=conditionalAccessAudiences/any(a:a eq '<your-custom-app-id>')&$select=appId,appDisplayName
Substitua <your-custom-app-id> pelo ID da aplicação personalizada.
Durante um período de vários dias, o resultado desta consulta fornece uma lista de aplicações cliente que solicitam apenas os âmbitos padrão.
Manter o comportamento legado com configurações de âmbito padrão
Observação
A Microsoft recomenda alinhar-se com o novo modelo de fiscalização. Use definições de âmbito base apenas se tiver cenários específicos que exijam o comportamento legado.
As definições de âmbitos baseline são uma configuração ao nível do cliente que permite usar uma aplicação personalizada detida pelo cliente como recurso alvo para os âmbitos baseline. Ao excluir esta aplicação personalizada de políticas específicas de Todos os recursos, pode manter o comportamento legado.
Quem deve usar esta definição
Usa esta definição se tiveres cenários específicos que exijam que mantenhas o comportamento legado. Os cenários de exemplo incluem:
- Todas as políticas de recursos exigem um controlo de concessão de dispositivos compatível: Aplicações que são excluídas desta política porque devem ser acessíveis a partir de dispositivos não geridos.
- Todas as políticas de recursos que exigem uma política de proteção de aplicações e controlo de concessões: aplicações cliente que não estão integradas com o SDK Intune e que não conseguem satisfazer a política de proteção da aplicação.
- Todas as políticas de recursos com controlo de blocos: Aplicações cliente que devem ser excluídas da política de bloqueio.
- Clientes públicos que devem estar isentos dos requisitos de dispositivos conformes: Por razões específicas de segurança e conformidade.
FAQ
Como posso antever a alteração da implementação antes do lançamento?
Vai a https://aka.ms/BaselineScopesSettingsUX, escolhe o recurso alvo default (Windows Azure Active Directory) e seleciona Save. Esta configuração reforça imediatamente o comportamento melhorado. Para voltar atrás, selecione reiniciar. Para mais informações, consulte Pré-visualização da alteração da aplicação.
Como posso manter o comportamento legado após o lançamento?
Use as definições de âmbito base para atribuir uma aplicação personalizada proprietária de um inquilino como recurso de destino para os âmbitos base, e depois exclua essa aplicação das suas políticas de Todos os recursos. Para mais informações, consulte Reter comportamento legado com definições de âmbito base.
Preciso de atualizar todas as candidaturas?
Não. Apenas as aplicações que solicitam exclusivamente âmbitos básicos e são afetadas pelas suas políticas de todos os recursos com exclusões de recursos específicos precisam de atenção. Aplicações que solicitam âmbitos além da linha de base (por exemplo, Mail.Read) já estão sujeitas à aplicação da política de Acesso Condicional e não são afetadas por esta alteração.