Conditional Access Session Controls, Sign-In Frequency, Locais Nomeados: O Que Realmente Revoga um Token Ativo

Conditional Access Session Controls Sign-In Frequency Locais Nomeados: O Que Cada Um Controla

Se você pesquisou por conditional access session controls sign-in frequency locais nomeados, você quase certamente está atrás de uma única pergunta: apertar um controle de sessão realmente expulsa alguém que já está conectado? A resposta curta é não. Um controle de sessão descreve o que acontece na próxima vez que o Microsoft Entra ID avalia a sessão — ele não alcança um token de acesso já emitido para revogá-lo.

A referência de controles de sessão da Microsoft lista oito controles: restrições aplicadas pela aplicação, Conditional Access application control, frequência de login, sessão de navegador persistente, personalizar a avaliação contínua de acesso, desabilitar padrões de resiliência, exigir proteção de token para sessões de login e usar o perfil de segurança do Global Secure Access. Dois deles — frequência de login e sessão de navegador persistente — se comportam ao longo do tempo de formas documentadas em uma página separada, políticas de tempo de vida de sessão adaptável, onde a Microsoft também afirma que "o Conditional Access é um recurso do Microsoft Entra ID P1 ou P2 que exige uma licença premium."

Se você auditar essas configurações via Microsoft Graph em vez do portal, o quadro fica ainda mais restrito. O recurso v1.0 conditionalAccessSessionControls expõe exatamente cinco propriedades — applicationEnforcedRestrictions, cloudAppSecurity, disableResilienceDefaults, persistentBrowser, signInFrequency —, então um script que enumera os controles de sessão v1.0 não verá proteção de token nem o botão de CAE.

O padrão é mais permissivo do que a maioria dos administradores imagina. A Microsoft afirma claramente: "a configuração padrão do Microsoft Entra ID para a frequência de login do usuário é uma janela móvel de 90 dias." O raciocínio é explícito — "não peça aos usuários para fornecerem suas credenciais se a postura de segurança de suas sessões não mudou."

Como Funciona: Quando Uma Política É Realmente Avaliada

Esta é a frase que rege tudo o mais. Da documentação de sinais de rede da Microsoft:

As políticas de Acesso Condicional são avaliadas quando: um usuário faz login inicialmente em uma aplicação web, móvel ou desktop. Uma aplicação móvel ou desktop que usa autenticação moderna utiliza um refresh token para adquirir um novo token de acesso. Por padrão, essa verificação ocorre uma vez por hora.

E, para navegadores: "para aplicações web, as políticas se aplicam no login inicial e valem pela duração da sessão na aplicação web." A Microsoft acrescenta a consequência prática: "por padrão, o Microsoft Entra ID emite tokens a cada hora. Depois que os usuários saem da rede corporativa, dentro de uma hora a política é aplicada para aplicações que usam autenticação moderna."

Portanto, uma política de localização é uma verificação no momento da renovação, não um gatilho ao vivo — a menos que a avaliação contínua de acesso esteja em jogo.

Frequência de login, incluindo "Sempre"

A frequência de login "especifica por quanto tempo um usuário pode acessar um recurso antes de precisar fazer login novamente." Escolher Sempre não significa continuamente. Microsoft: "quando você seleciona Sempre, a política exige reautenticação completa quando a sessão é avaliada. Isso significa que, se o usuário fechar e abrir o navegador durante a duração da sessão, ele pode não ser solicitado a se reautenticar." O controle também "considera cinco minutos de tolerância de relógio quando 'sempre' é selecionado, para não solicitar os usuários com mais frequência do que uma vez a cada cinco minutos."

A aplicação também é adiada para tudo que for não interativo: "se o aplicativo cliente (em detalhes de atividade) for um navegador, o sistema adia a aplicação da frequência de login de eventos e políticas em serviços em segundo plano até a próxima interação do usuário. Em clientes confidenciais, o sistema adia a aplicação da frequência de login em logins não interativos até o próximo login interativo."

Em dispositivos ingressados há um segundo relógio: "desbloquear o dispositivo ou fazer login interativamente atualiza o Primary Refresh Token (PRT) a cada quatro horas." O próprio exemplo da Microsoft mostra uma política de SIF de uma hora solicitando o usuário às 05:45 — cinco horas e 45 minutos após o login inicial às 00:00 — porque o PRT foi atualizado às 04:45.

A avaliação contínua de acesso é a parte que revoga

A avaliação contínua de acesso (Continuous Access Evaluation, CAE) é o que transforma a política em revogação quase em tempo real, e o faz para uma lista fechada de eventos críticos: uma conta de usuário é excluída ou desabilitada; uma senha é alterada ou redefinida; o MFA é habilitado para o usuário; um administrador revoga explicitamente todos os refresh tokens; alto risco de usuário é detectado pelo ID Protection. A latência declarada pela Microsoft: "a meta para a avaliação de eventos críticos é que a resposta seja quase em tempo real, mas uma latência de até 15 minutos pode ser observada devido ao tempo de propagação do evento; no entanto, a aplicação da política de localizações IP é instantânea."

O custo são tokens mais longos: "a duração do token aumenta para de longa duração, até 28 horas, em sessões CAE." Sem clientes com suporte a CAE, "a duração padrão do token de acesso permanece em 1 hora." E, de forma crucial para este artigo: "a frequência de login é respeitada com ou sem CAE."

A Lacuna: Onde Um Token Ativo Sobrevive à Sua Política

1. Locais nomeados baseados em país são invisíveis para o CAE

Esta é a linha de maior valor em toda a documentação de CAE:

O CAE só tem visibilidade sobre locais nomeados baseados em IP. O CAE não tem visibilidade sobre outras condições de localização, como IPs confiáveis de MFA ou locais baseados em país/região. Quando um usuário vem de um IP confiável de MFA, de um local confiável que inclui IPs confiáveis de MFA, ou de um local de país/região, o CAE não será aplicado depois que esse usuário se mover para um local diferente. Nesses casos, o Microsoft Entra emite um token de acesso de uma hora sem verificação instantânea de aplicação de IP.

Uma política de "bloquear acesso de fora desses países" portanto reverte o tenant para o modelo horário pré-CAE. A orientação da própria Microsoft é inequívoca: "não use condições de localização por país/região nem o recurso de IPs confiáveis disponível na página de configurações de serviço da autenticação multifator do Microsoft Entra."

2. Excesso de intervalos de IP desabilita silenciosamente a aplicação de localização ao vivo

"Quando a soma de todos os intervalos de IP especificados em políticas de localização excede 5.000, o CAE não consegue aplicar o fluxo de mudança de localização do usuário em tempo real. Nesse caso, o Microsoft Entra emite um token CAE de uma hora." O limite é para todo o tenant — a soma de todas as políticas de localização, não um teto por política —, então ele é ultrapassado por acúmulo, e não por uma única edição. Apenas a aplicação de localização se degrada: "o CAE continua aplicando todos os outros eventos e políticas, exceto os eventos de mudança de localização do cliente." Os limites estruturais também são finitos: no máximo 195 locais nomeados, no máximo 2.000 intervalos de IP por local nomeado, e apenas máscaras CIDR maiores que /8.

3. Caminhos de saída divididos disparam a exceção de variação de IP

Quando o IP que o Entra vê e o IP que o provedor de recursos vê são diferentes — proxies, VPN split-tunnel, SD-WAN, SNAT, IPv6 — "o Microsoft Entra interpreta que o cliente continua em um local permitido e que o acesso deve ser concedido. Portanto, o Microsoft Entra emite um token de uma hora que suspende as verificações de endereço IP no recurso até a expiração do token." Esse é o modo padrão, ativo por padrão. A alternativa mais rígida da Microsoft, que sua página de CAE ainda rotula como Public Preview, é a aplicação estrita de localização: "parar imediatamente o acesso se o endereço IP detectado pelo provedor de recursos não for permitido pela política de Acesso Condicional."

4. Cookies de navegador persistente sobrevivem à política

O aviso da Microsoft sobre persistência é direto: "em navegadores persistentes, os cookies permanecem armazenados no dispositivo do usuário mesmo depois que o navegador é fechado. Esses cookies podem acessar artefatos do Microsoft Entra, que permanecem utilizáveis até a expiração do token, independentemente das políticas de Acesso Condicional aplicadas ao ambiente do recurso." Um proxy adversary-in-the-middle que rouba esse cookie herda exatamente essa propriedade — veja replay de token AiTM e detecção de viagem impossível no Entra ID e device code phishing para saber como o roubo acontece, em primeiro lugar.

5. A condição de plataforma do dispositivo é uma entrada não verificada

"O Conditional Access identifica a plataforma do dispositivo usando informações fornecidas pelo próprio dispositivo, como strings de user agent. Como strings de user agent podem ser modificadas, essa informação não é verificada." Uma condição de plataforma é um mecanismo de escopo, não um controle de autenticação. A recomendação da Microsoft é usá-la "junto com políticas de conformidade de dispositivo do Microsoft Intune ou como parte de uma instrução de bloqueio."

6. Edições de política não se aplicam retroativamente

"Alterações feitas em políticas de Acesso Condicional e na associação de grupos feitas por administradores podem levar até um dia para entrar em vigor... Alguma otimização é feita para atualizações de política, o que reduz o atraso para duas horas." Apertar uma política depois de um incidente não expulsa as sessões que já existem. Vale citar dois outros pontos cegos: "o CAE não oferece suporte a contas de usuário convidado", e "o Teams é composto por vários serviços; os serviços de chamadas e chat não seguem políticas de Acesso Condicional baseadas em IP."

Detecção

Comece pela configuração, depois pela telemetria.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'Policy.Read.All'

# Politicas sem nenhum controle de sessao, e as que dependem de locais por pais
Get-MgIdentityConditionalAccessPolicy |
    Select-Object DisplayName, State,
        @{n='SessionControls';e={ $_.SessionControls | ConvertTo-Json -Depth 4 -Compress }},
        @{n='Locations';e={ $_.Conditions.Locations | ConvertTo-Json -Depth 3 -Compress }}

# Locais nomeados: quais sao baseados em IP (visiveis ao CAE) e quais sao confiaveis
Get-MgIdentityConditionalAccessNamedLocation |
    Select-Object Id, DisplayName, AdditionalProperties

Ambos os cmdlets precisam apenas de Policy.Read.All; a Microsoft lista Global Reader, Security Reader, Security Administrator e Conditional Access Administrator entre os papéis com menor privilégio para essas leituras. As chamadas REST equivalentes são GET /identity/conditionalAccess/policies e GET /identity/conditionalAccess/namedLocations.

Na resposta do Graph, um local baseado em IP é #microsoft.graph.ipNamedLocation com isTrusted e ipRanges[].cidrAddress; um local por país é #microsoft.graph.countryNamedLocation com countriesAndRegions e includeUnknownCountriesAndRegions. Apenas o primeiro tipo é aplicado ao vivo pelo CAE. Um controle de navegador persistente aparece como persistentBrowser com mode igual a always ou never, e frequência de login como signInFrequency com frequencyInterval igual a timeBased ou everyTime.

A tabela SigninLogs do Azure Monitor traz tudo isso. Uma consulta inicial para o problema do caminho dividido:

SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(IPAddressFromResourceProvider)
| where IPAddressFromResourceProvider != IPAddress
| summarize Sessions = count(),
            Users = dcount(UserPrincipalName)
        by AppDisplayName, IPAddress, IPAddressFromResourceProvider, ConditionalAccessStatus
| order by Sessions desc

A referência da tabela SigninLogs da Microsoft descreve IPAddressFromResourceProvider como "o endereço IP que um usuário usou para alcançar um provedor de recursos, usado para determinar a conformidade com o Acesso Condicional em algumas políticas... Esse valor costuma ser nulo" — nulo é o caso saudável, ou seja, ambas as visões concordam. O equivalente no portal é a coluna Endereço IP (visto pelo recurso) nos logs de sign-in, e a Microsoft disponibiliza um modelo de workbook público, Continuous Access Evaluation Insights, para expor exatamente essas discrepâncias.

Remediação (Remediation)

1. Converta os locais críticos para aplicação em locais nomeados baseados em IP. Microsoft: "se você quer que suas políticas de localização sejam aplicadas em tempo real pela avaliação contínua de acesso, use apenas a condição de localização do Acesso Condicional baseada em IP e configure todos os endereços IP — incluindo tanto IPv4 quanto IPv6 — que possam ser vistos pelo seu provedor de identidade e pelos provedores de recursos." Mantenha locais por país apenas para bloqueios grosseiros, e lembre-se de que um local marcado como confiável "não pode ser excluído sem primeiro remover a designação de confiável."

2. Enumere todo IP de saída — nas duas visões. Inclua os endereços que o Entra vê na autenticação e os endereços que o Exchange Online, o SharePoint Online, o Teams e o Microsoft Graph veem. Não infle a lista: "não adicione IPs de saída não dedicados ou não enumeráveis a regras de Acesso Condicional de Locais Nomeados Confiáveis, pois isso pode enfraquecer a segurança." Mantenha o total do tenant abaixo de 5.000 intervalos.

3. Corrija corretamente o ponto cego do proxy. Com um proxy em nuvem ou VPN, "o endereço IP que o Microsoft Entra ID usa ao avaliar uma política é o endereço IP do proxy. O header X-Forwarded-For (XFF)... não é usado porque não há validação de que ele vem de uma fonte confiável." A Microsoft recomenda a restauração do IP de origem via Global Secure Access, ou um controle baseado em dispositivo em vez de uma lista de IPs.

4. Só então considere a aplicação estrita de localização. Valide primeiro com o workbook de CAE e o filtro Endereço IP (visto pelo recurso). A ressalva da Microsoft: "se o tráfego para o Microsoft Entra ID ou para um recurso com suporte a CAE passa por um IP de saída compartilhado ou indeterminável, não habilite a aplicação estrita de localização em suas políticas de Acesso Condicional." Implemente grupo por grupo.

5. Defina a sessão de navegador persistente como never — e delimite-a corretamente. O Graph documenta a restrição diretamente na propriedade: "todos os aplicativos devem ser selecionados para que esse controle de sessão funcione corretamente." Uma política de navegador persistente com escopo em um subconjunto de aplicativos não faz o que seu nome sugere.

6. Não confie apenas na condição de plataforma. Combine Plataformas de dispositivo com conformidade do Intune ou a condição Filtro para dispositivos. Note que a condição mais antiga Estado do dispositivo está descontinuada, e "estado do dispositivo e filtros para dispositivos não podem ser usados juntos em uma política de Acesso Condicional."

7. Elimine dois conflitos conhecidos antes de habilitar a frequência de login. Desative primeiro "Lembrar MFA em dispositivos confiáveis" — "usar essas duas configurações juntas pode solicitar os usuários de forma inesperada" — e não misture controles de sessão com o recurso legado de duração de token configurável, que "a Microsoft descontinuou... para durações de refresh token e de sessão em 30 de janeiro de 2021."

8. Revogue explicitamente durante um incidente. Como as edições de política levam até um dia (duas horas com otimização) para chegar aos provedores de recursos, use a ação direta:

Import-Module Microsoft.Graph.Users.Actions

# Um UPN tambem pode ser usado como -UserId.
Revoke-MgUserSignInSession -UserId $userId

O Revoke-MgUserSignInSession "invalida todos os refresh tokens emitidos para aplicativos de um usuário (e os cookies de sessão no navegador do usuário), redefinindo a propriedade de usuário signInSessionsValidFromDateTime para a data e hora atuais." Ele exige, no mínimo, User.RevokeSessions.All. O equivalente no portal é Revogar Sessão na página de perfil do usuário. Confirme que suas contas break-glass estão excluídas de qualquer política de localização antes de apertá-la.

9. Adicione proteção de token onde o cliente oferecer suporte. A proteção de token "tenta reduzir ataques que usam roubo de token, garantindo que um token só possa ser usado a partir do dispositivo pretendido", e a coluna TokenProtectionStatusDetails em SigninLogs informa se um token de login foi vinculado ao seu dispositivo.

Como o EtcSec Detecta Isso

Um audit Azure do EtcSec lê suas políticas de Acesso Condicional e locais nomeados via Microsoft Graph e sinaliza as lacunas de configuração por trás de cada cenário acima: CA_NO_SESSION_CONTROLS quando nenhuma política habilitada define uma frequência de login ou um modo de navegador persistente, CA_PERSISTENT_BROWSER_ENABLED quando cookies de navegador podem persistir, CA_NO_NAMED_LOCATIONS e CA_NO_TRUSTED_LOCATIONS quando o tenant não tem o vocabulário de localização que o CAE precisa para aplicar, CA_NO_LOCATION_BLOCK quando nenhuma política bloqueia por localização, e CA_NO_PLATFORM_FILTER quando nenhuma política delimita por plataforma de dispositivo. Isso se encaixa bem com a revisão mais ampla em falhas de acesso condicional do Entra ID, lacunas de cobertura da política baseline e o guia de auditoria de segurança do Entra ID de ponta a ponta.