AzureAD Acesso Condicional Conditional Access deep dive

Faaala galera, 100%?

Hoje é um bom dia pra falar sobre um baita recurso do AzureAD, o amado e as vezes não tão bem compreendido Conditional Access! A ideia do artigo é introduzir conceitos sobre o recurso e, em partes, evoluir o assunto até chegarmos a exemplos de implantação, mão na massa.

Espero que curta!

CA – O que é isso?

Acesso condicional é um recurso que atua na segunda linha de defesa, após a autenticação do usuário, avaliando sinais e definindo se o acesso será permitido ou garantido. Ao meu ver, em um cenário com que tem como foco implementar as práticas Zero Trust esse recurso passa a ser o core de todo o processo, logo, é mais do que válido entender como funcionar e ajusta-los as demandas do seu ambiente.

Let’s rock!

Como funciona?

Como já dito, o CA atua como segunda linha de defesa, após a autenticação do usuário. Com base em sinais coletados e as políticas definidas o recurso faz uma análise em duas etapas.

De uma forma não técnica a ideia é:

Quando isso acontecer → Faça Isso

• Quando isso acontecer = Condições definidas
  • Device não registrado ou ingressado em um dominio
  • Conexão vinda um IP desconhecido
  • Conexão vinda de uma plataforma mobile
• Faça isso = Controle de acesso
  • Solicite MFA
  • Solicite a troca de senha

Esse processo se repete para todas as conexões que façam parte da regra. A avaliação sempre ocorrerá em duas fases. Primeiramente todas as políticas são avaliadas de acordo com os sinais coletados do device ou usuário e com base nos resultados o controle de acesso é aplicado.

As condições são verificadas quando a autenticação ocorre e se as condições forem verdadeiras acontece o match com a política. O controle de acesso, por sua vez, precisa que ações sejam realizadas ou que de informações sejam verdadeiras após o match ter ocorrido. Esse, como esperado, que permitirá ou não o uso/acesso ao recurso.

A quem posso atribuir uma CA?

Usuário e Grupos

Como esperado você precisa definir quais usuários farão parte dessa regra. É possível incluir, todos os usuários, um usuário apenas, quem possui roles específicas ou trabalhar com grupo, que, como já sabemos, é sempre o mais indicado.

Aqui também é possível trabalhar com exclusões. Imagine que você tenha um grupo com 10 usuários e atribui uma política de CA a esse grupo.

Dentre os 10 usuário um deles, aquele user “diferentão”, não deve fazer parte da política. E agora José!? EASY…basta manter o grupo como parte da política e adicionar esse usuário “diferentão” nas exclusões. Dessa forma CA não o considerará.

Lembre-se sempre que uma exclusão sempre sobrepõe a inclusão.

Há, também é possível definir que apenas usuários externos e convidados façam parte da política.

Aplicações Cloud e Ações do usuário

Nessa etapa definimos quais aplicações podem gerar um controle de acesso. Aqui é possível escolher quais aplicações cloud. É possível definir apenas uma aplicação, com acesso ao Azure Active Directory ou todas as aplicações do mundo 365 (Exchange Online, ShrePoint, Teams…).

Nessa opção aplica-se também a possibilidade de se ter exclusões. Podemos então definir que qualquer acesso feito a cargas na nuvem dispararão exigirão o MFA, exceto chamadas para o MSGraph.

Para ações de usuários temos, no momento, duas opções:

• Registro de informações de segurança: Aqui temos a opção solicitar algum controle de acesso para que informações de segurança do usuário sejam atualizadas.
• Registro ou Join de devices: Essa opção é bacana pois, a princípio, o controle que existia era aplicado a nível de tenant, o famoso “Tenant wide. Com essa opção ganhamos em granularidade.

Entraria aqui ainda a opção de “Autenticação de Contexto (Auth Context)” mas vamos deixar esse tem pra um artigo específico.

O que posso usar como condição?

Em condições existe VÁRIAS opções! Isso é bacana pois mostra a flexibilidade que conseguimos atingir utilizando políticas de CA.

Sinais vindos do AzureAD ID Protection – User e Sign-in Risk (Para que sejam utilizadas políticas de Risk Based uma licença de Azure P2 é exigida.)

Device Plataform – Aqui é possível selecionar entre Android, Windows, iOS, Windows Phone (não, eu não estou brincando), Linux e MacOS

Locations – Se a conexão parte de dentro do perímetro de rede corporativa ou não.

Client app – Qual aplicativo está sendo utilizado para acessar a carga. Aqui entra desde o browser até apps mobile e clientes desktop.

Filtro para dispositivos – Essa parte é bacana. Via consulta é possível realizar filtro em dispositivos diferenciando conexões vindas de dispositivos registrados/Hybrid Joined por exemplo.

Políticas de CA podem ser atribuídas a usúarios ou grupos.

Qual é a ordem de processamento?

Não existe ordem! Calma, pode parecer, mas não é bagunçado!

O que ocorre é: Todas as políticas que derem match serão mescladas. Dificilmente existe apenas uma política de CA no ambiente, em geral cria-se várias políticas para atender a vários requisitos de segurança/negócio. Logo, quando um usuário acessa uma carga em nuvem todas as políticas serão avaliadas e se o usuário fizer parte de mais de uma elas serão mescladas, incluindo condições e controles de acesso. O usuário precisará cumprir o requisito de todos os controles de acesso de todos as políticas que deu match para conseguir ter o acesso liberado.

Licenciamento

Acesso Condicional é um recurso do AzureAD Premium, logo, você precisará ao menos do AzureAD P1

Conclusão

Parte crucial em um ambiente Zero Trust entender os conceitos que estão por trás do CA é muito importante pra conseguir explorar ao máximo o potencial do recurso. Aqui apresentei os conceitos base e nos próximos artigo trarei alguns detalhes mais avançados e com toda certeza alguns exemplos praticos!

Espero que tenha curtido! Grande abraço \,,/