Acesso Condicional Falho

O Zero Trust necessita de um ponto de partida e neste caso o Acesso Condicional e o meu recurso preferido para tornar a estratégia do Zero Trust um sucesso.

Trabalhar com Acesso Condicional é maravilhoso, simplesmente torna a árdua tarefa de proteger os locatários mais simples, mais intuitiva!

Mas, se as configurações não estiverem boas você pode ter uma falsa sensação de segurança e vai acabar desprotegendo sua organização

Não deixe de conferir os links oficiais no final dessa postagem!

O que é acesso condicional

É um recurso premium do Azure AD e por padrão ele vem desabilitado, lembrando que temos um recurso chamado padrões de segurança esse recurso sempre vai estar desabilitada quando você tiver alguma politica de acesso condicional em vigor, você pode conhecer o Acesso Condicional neste link

O Acesso Condicional possui algumas peculiaridades, por exemplo, tudo é permitido e você terá que negar explicitamente algum acesso ou alguma condição.

Desenhar para não borrar…

Não é raro achar cenários em que as falhas no desenho do acesso condicional são relacionadas devido o foco de atuação da regra, ou seja, o foco da politica esta errado.

Diversos administradores usam o Acesso Condicional do ponto de vista do que deve ser acessado e não do ponto de vista do que deve ser bloqueado e dessa forma acabam expondo a organização a ataques.

Lembrando que muitas vezes as regras são criadas para usuários comuns e os atacantes são especialistas buscando as vulnerabilidades do ambiente

Primeiro Fator de Autenticação – Senha

Bom, a senha do usuário continua sendo o primeiro fator de autenticação e abordagem desse post e exatamente após a validação da senha do usuário, portanto, não vou entrar nas técnicas de roubos de senha que podem acontecer.

O que será abordado poderá acontecer após a primeira autenticação!

Vamos seguindo…

Assim funcionam as políticas de acesso condicional múltiplas

É bem diferente de um firewall, proxy, etc.. No acesso condicional todas as entradas são avaliadas uma por uma a cada entrada e cada política é aplicada de acordo com a sua configuração.

 Se um determinado usuário está em vários grupos com acesso condicional a regra será aplicada cada vez que ele entrar no ambiente.

Suponhamos um caso clássico, a organização exige MFA e que o dispositivo seja gerenciado pelo Microsoft EndPoint Manager (Intune), pode ser que a organização tenha duas regras para isso e acaba que as duas regras são analisadas e se o usuário está compatível com ambas as regras ele passa a ter o acesso, cada regra, sua análise.

Prioridades de atuação

Os bloqueios sempre vençem (yes!), funciona assim, se tiver uma ou mais políticas de bloqueio para uma determinada situação e se tivermos outras políticas que permitam o acesso, o bloqueio vence!

pontos fracos comuns

Abuso do Grupo de Exclusão

Já ouviu falar em grupo de exclusão? (vou escrever uma postagem apenas sobre isso) são contas de emergência que devem estar fora do alcance das políticas condicionais, esse grupo é apenas para emergência e é uma boa prática para administrar o ambiente de nuvem.

Um erro comum é adicionar contas que estão em produção neste grupo e assim essas contas fogem do Acesso Condicional, alguns administradores fazem isso e se uma dessas contas forem comprometidas todos perdem, simples assim.

Para os grupos de exclusão é importante manter uma rotina de verificação e assim mitigar algum tipo de ataque a essas contas.  

Requisitos de Negócios – Acesso Negado – Regras Vazias

Vazias? Sim, vazias! Isso porque as políticas são destinadas sempre com plataformas, locais, tipo de acesso etc. esquecem de analisar o que leva a ter essas políticas, qual o cenário da organização, quais os requisitos de negócios! Focam na tecnologia e esquecem o que move a tecnologia!

Com a política baseado em necessidades corriqueiras e não no cenário que a organização necessita bloquear estamos dando uma grande oportunidade para que os atacantes consigam identificar a regra e burlá-la!

É possível burlar local, plataforma e outros temas facilmente e assim já quebramos o Acesso Condicional.

A seguir está a mensagem de erro geral que um usuário recebe quando o acesso é negado por uma política de bloqueio. Observe que a mensagem de erro de bloqueio pode ser diferente dependendo de quais condições estavam na política de bloqueio. Isso é para ajudar o usuário a entender o que deu errado (veja algumas condições mais abaixo).

Use as informações de mais detalhes para ver se há alguma pista de qual condição acionou o bloqueio, como o local do endereço IP, o estado de gerenciamento do dispositivo ou o aplicativo de destino. Esta é uma informação importante daqui para frente.

  1. Aqui está um exemplo de bloqueio por localidade

Quando você clica em Mais Detalhes você tem, obvio, MAIS DETALHES!

Risco do usuário/Risco de login

(Risk detection)

Essa é aquelas questões tristes da vida, coisa boa, poucos vão ter!

O risco de entrada e o risco de usuários estão presentes no Azure AD Identity Protection (Azure AD Premium P2) e que não será um problema para um invasor. 

Se essas features estiverem habilitadas um invasor vai ter mais dor de cabeça para prosseguir, isso porque ele vai ter que usar alguma VPN da organização e diversas outras técnicas de intrusão para ser mais legitimo possível o acesso.

Quanto mais segurança mais difícil a vida do invasor.

Segue a imagem do bloqueio devido o risco percebido na conta.

Windows, Android, iOS…

Toda plataforma e baseada em string, exatamente por isso é bem vulnerável e qualquer política que inclui acesso mediante a plataforma pode ser facilmente burlada.

Com pouquíssimo conhecimento qualquer usuário consegue alterar sua string. A solução para isso e você ter uma política bloqueando todas as plataformas que não sejam homologadas em seu ambiente, mas, isso é tão raro quanto chuva no deserto.

É assim que você pode alterar sua string de agente de usuário com as ferramentas de desenvolvimento no Microsoft Edge, basta escolher qual plataforma você quer usar.

Quando temos uma política por plataforma temos a seguinte visualização:

Concluindo…

O Acesso Condicional é sem dúvida um dos mecanismos que agregam um grande campo de segurança e quem utiliza está comprometido com o “zero trust”.

Contudo, sendo mal implementado não terá a eficácia que imaginamos, mostrei com poucos passos como podemos burlar os mecanismos mais usados nas organizações e muitas vezes esses mecanismos são configurados isolados e não tem concordância com as demais políticas e isso torna o ambiente mais vulnerável.

Combine as políticas para buscar maior proteção, não foque apenas na tecnologia busque entender os requisitos de negócio para poder implementar um desenho de Acesso Condicional mais robusto.

Como todo ambiente é vivo devemos testar com uma certa frequência se nossas políticas ainda são eficazes, mantenha uma agenda de análise e testes, verifique as autenticações, usuários que possuem a conta ativa mas já não fazem parte da organização, aplicativos que podem estar comprometendo a segurança da organização e teste o seu ambiente.

Possua uma solução de SIEM, eu recomendo o Microsoft Sentinel, implemente os mecanismos de proteção a Identidade do Azure, e fique em alerta, sempre.

Referências

https://docs.microsoft.com/pt-br/azure/active-directory/conditional-access/concept-conditional-access-policies

https://docs.microsoft.com/pt-br/azure/active-directory/conditional-access/overview

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s