Criando políticas de acesso condicional

Criando políticas de acesso condicional

Sendo um dos recursos de maior valor do Entra ID (antigo Azure AD), as políticas de acesso condicional (conditional access policies) fornecem aos times uma maneira poderosa de proteger os recursos no Azure e as aplicações conectadas ao Entra ID. Vamos mergulhar nesse recurso!

OBS: antes de começarmos a trabalhar com as políticas, é importante que você se atente ao licenciamento necessário para utilizá-las. A Microsoft exige que você tenha um tenant do Entra ID com qualquer uma das licenças (P1, P2, E3 ou E5). Tendo qualquer uma delas, você estará habilitado para começar a construir suas políticas e proteger seu ambiente.

OBS2: pode ser que ao entrar no portal do Entra na blade de Acesso Condicional (Proteção > Acesso Condicional) você seja apresentado com o seguinte aviso:

“Parece que você está prestes a gerenciar as configurações de segurança da sua organização. Você precisa desabilitar os padrões de segurança antes de habilitar uma política de Acesso Condicional.”

Os tenants do Entra ID tem uma configuração chamada padrões de segurança (security defaults) que está habilitada por padrão em todos os novos tenants. Para desativá-la basta clicar no texto clicável do aviso (“desabilitar os padrões de segurança”) e selecionar “Desabilitado”.

Padrões de Segurança (Security Defaults): a função dos padrões de segurança é fornecer alguns requisitos mínimos de proteção ao ambiente do Entra ID. Quando habilitado, os administradores não precisam realizar nenhum tipo de configuração adicional, visto que o tenant como um todo será protegido pelos padrões. Os controles de segurança aplicados pelos security defaults são os seguintes:

  • Autenticação multifator: exige que os usuários cadastrem alguma forma de autenticação multifator;

  • Bloqueio de autenticações legado: com o objetivo de oferecer mais segurança ao ambiente, o bloqueio de protocolos legado não permite autenticações que utilizem protocolos legado;

  • Proteção de atividades privilegiadas: para contas privilegiadas (alto nível de acesso e permissões), os usuários terão que realizar a autenticação multifator;


Iniciando com as políticas

Após desativar os padrões de segurança, podemos prosseguir com a criação da nossa primeira política de acesso condicional.

Nesse tutorial, vamos criar uma política que exija autenticação multifator (MFA) para determinados usuários do nosso tenant.

Painel do acesso condicional no portal do Entra

O primeiro passo é criar um nome. É importante lembrar que sua organização provavelmente terá dezenas (se não centenas) de políticas de acesso condicional, então escolher um bom nome e que descreva corretamente o que a política fará é de extrema importância. Isso facilitará o trabalho dos profissionais que terão que modificar as políticas no futuro ou que desejam consultá-las para entender quais proteções estão sendo aplicadas no ambiente.

Vamos seguir com o seguinte nome:

Exigir MFA para usuários específicos


Usuários

Entrando efetivamente na construção das nossas políticas, o primeiro passo é selecionar quem será afetado por ela:

Ao selecionar o campo “usuários” você poderá escolher na aba “incluir”, usuários e grupos que serão afetados pela política. Na aba “excluir” você colocará as exceções para a política, ou seja, usuários e grupos que não deverão sofrer a aplicação das regras. Ao contrário da aba “incluir”, não é obrigatório preencher nenhum dos campos da aba “excluir”.

Para este exemplo, vamos aplicar a política apenas à um usuário como mostra a imagem a seguir:

Após escolher “selecionar usuários e grupos” você terá essas opções à cima para serem marcadas.

“Usuários convidados ou externos” são contas que não são nativas do seu tenant.

“Funções do diretório” permite que você selecione algumas “roles”, assim os usuários que contenham qualquer uma delas sofrerão a aplicação da política.

“Usuários e grupos” permite que você escolha qualquer um dos usuários e grupos presentes no seu tenant.


Recursos de destino

Após escolher quem será impactado pelas políticas, é hora de escolher O QUE será impactado.

Recursos de destino disponíveis

Nessa seção nós selecionaremos quais aplicativos o usuário utilizar e/ou quais ações o usuário realizar que serão impactadas pela política.

Aplicativos de nuvem

Dentro dessa seção nós podemos escolher aplicações que estão “federadas” no Entra ID devem ter seu acesso controlado. Caso seu tenant seja novo, você provavelmente não terá nenhuma aplicação federada, mas por padrão você poderá selecionar o Office 365 e o portal do Azure para terem o acesso controlado.

Painel dos aplicativos em nuvem

O aplicativo selecionado (portais de administração da Microsoft) contém um conjunto de aplicações (como o Portal do Entra e o Portal do Azure). Quando seu tenant tiver mais aplicações federadas (SaaS, portais, aplicações próprias, etc) você poderá selecioná-los para serem impactados pelas políticas.

Nesse caso não faremos uso da funcionalidade de exclusão da política, mas para fins de conhecimento ela funciona da mesma forma que na seção de usuários.

Esse campo “editar filtro” permite que você crie regras personalizadas baseadas em atributos das aplicações para selecioná-las de maneira dinâmica.

Ações do usuário

Essa seleção permite escolher duas ações que podem ser realizadas pelos usuários: inserir informações de segurança e entrar com um dispositivo no Entra ID (seja registrá-lo ou apenas realizar login no mesmo).

Para esse tutorial não vamos utilizar essa capacidade da plataforma.

Contexto de autenticação

Os contextos de autenticação fornecem uma maneira de proteger o acesso à áreas e informações sensíveis de aplicações.

Essa funcionalidade habilita que os administradores dos sistemas controlem o acesso à informações personalizadas utilizando a força das políticas de acesso condicional.

Esse recurso também oferece certa granularidade na proteção das aplicações. A usabilidade das plataformas é de extrema importância para os administradores, pois isso afeta a produtividade dos usuários no dia a dia. Apenas imagine, você precisando se re-autenticar o tempo todo enquanto utiliza uma aplicação crítica para suas atividades. Pensando na usabilidade, podemos restringir as re-autenticações apenas ao acesso a informações privilegiadas.

Antes de configurar o contexto de autenticação na política, é necessário registrar o contexto. Se quiser ter mais detalhes, recomendo a leitura dessa documentação.


Condições

Após selecionarmos QUEM e o QUE terão seus acessos controlados, chegou a hora de selecionar outras informações que deverão ser levadas em conta quando estivermos construindo nossas políticas.

Essa seção é enorme e cheia de variáveis, não entraremos a fundo em cada uma das possibilidades. Para melhor conhecimento, sugiro que faça seus testes em casa construindo as mais variáveis políticas.

Painel das condições

O Entra ID Identity Protection fornece diferentes capacidades de análise de segurança para os usuários da plataforma. Com ele, diversas informações dos usuários e de seus logins são captadas e analisadas pela própria plataforma, identificando ameaças, invasões, atividades suspeitas e outros riscos às identidades e aos recursos da sua empresa. Os riscos de usuário e riscos de entrada são funcionalidades próprias do Entra ID Identity Protection.

A lista de riscos identificados pelo ID Protection é extensa, então para facilitar o seu entendimento, vou inserir um print das capacidades de cada um deles, bem como o link para a documentação oficial da Microsoft que trata dessas informações.

Risco de usuário

Quais são os riscos do Azure AD Identity Protection — Microsoft Entra | Microsoft Learn

Dentro dessa área da política, você poderá selecionar qual a severidade de risco que deverá ser levada em conta para que a política seja aplicada.

Os riscos de usuário podem ser classificados como baixo, médio e alto.

Risco de entrada

Quais são os riscos do Azure AD Identity Protection — Microsoft Entra | Microsoft Learn

Com uma gama de riscos identificáveis muito maior, os riscos de entrada contém uma categoria a mais que os riscos de usuário. Elas são: sem riscos, baixo, médio e alto.

Plataforma de dispositivo

Nessa seleção, você poderá escolher quais sistemas operacionais devem ser levados em conta quando o acesso for realizado.

Essa seleção pode ser útil principalmente se a sua organização utilizar dispositivos de apenas um sistema operacional. Com essa política, podemos identificar acessos não autorizados vindo de dispositivos de fora da organização.

Locais

Podemos levar em conta a localização física do usuário que está realizando o acesso. Essa capacidade é muito útil para restringir acesso à aplicações apenas de dentro da rede da empresa.

Não é escopo desse artigo, mas com o Entra ID nós podemos registrar ranges de IP que são confiáveis para a empresa e esses podem ser escolhidos dentro da política de acesso condicional.

Aplicativos cliente

Após escolher qual plataforma de dispositivo, é possível selecionar os diferentes locais onde as aplicações estão sendo executadas (aplicações web e/ou nativas do dispositivo).

Filtro para dispositivos

Essa capacidade permite criar regras personalizadas e baseadas em atributos dos dispositivos para aplicação das políticas.

Aqui está um exemplo de uma política com filtro. A query acima seleciona dispositivos que NÃO estejam em compliance com as regras definidas pela empresa. Essa capacidade oferece dezenas de propriedades que podem ser utilizadas e é uma funcionalidade extremamente potente para aumentar a cobertura das suas políticas.


Controles de acesso

Entrando na seção final da nossa política, temos o controle de acesso. Nesse campo nós selecionaremos quais controles serão aplicados aos acessos que tiverem a política aplicada.

Conceder

Podemos escolher entre bloquear o acesso do usuário ou permitir o acesso e aplicar algum dos controles fornecidos logo em seguida. Você pode selecionar um ou mais controles e no final pode escolher se todos os controles selecionados devem ser aplicados ou se somente um deles é necessário.

Caso você selecione a opção “requerer mudança de senha” não será possível escolher mais nenhuma outra opção e será requerido que você selecione a força de autenticação como mostra a imagem abaixo:

Essa configuração exigirá que o usuário realize sua autenticação utilizando o método selecionado na lista acima.

Sessão

O controle de sessão permite impor restrições à usabilidade das aplicações por parte dos usuários.

Dentre as opções existentes podemos exigir uma re-autenticação na aplicação, tempo de duração das sessões (quanto tempo um usuário pode ficar sem se re-autenticar) e muitas outras opções.


Habilitação da política

Após ter construído sua política, podemos colocá-la em 3 estados possíveis:

  • Somente relatório: a política não agirá de acordo com as regras determinadas, ou seja, o usuário não será impactado de forma alguma. Nesse caso, todos os logins e atividades dos usuários passam pela política e são feitos registros (logs) que informam se a política foi aplicada e de que forma;

  • Ativado: a política entrará em ação e todos os seus controles serão aplicados quando necessário;

  • Desativado: sua política será criada mas não estará em funcionamento;


Resultado final: essa política exigirá que o usuário (User A) realize a autenticação multifator ao acessar qualquer um dos portais administrativos da Microsoft. O usuário que não tiver nenhum dispositivo de MFA cadastrado, será apresentado com uma página no navegador que conterá a jornada para download do aplicativo mobile Microsoft Authenticator bem como seu registro para permitir a autenticação.


As políticas de acesso condicional são um grande aliado para você e para sua empresa na luta contra os ciberataques e contra os riscos relacionados às identidades. Utilize-as e proteja seu ambiente de maneira correta e eficiente.

Espero que tenha gostado e que agora se sinta hábil para construir suas policies sozinho.

Até logo!