Com as identidades sendo a primeira barreira de defesa sob o controle do cliente em qualquer ambiente em nuvem, precisamos estabelecer políticas efetivas de segurança que considerem diferentes níveis de risco apresentados ao ambiente e que coletem a maior quantidade possíveis de informação. Pensando nisso, podemos potencializar a segurança de nosso ambiente com o Microsoft Entra ID Protection!
Entendendo a primeira barreira de proteção
Como mencionado na abertura do artigo, as identidades são a primeira barreira de proteção nos ambientes em nuvem. Mas o que isso quer dizer?
Nos ambientes em nuvem a segurança física do ambiente não é preocupação do cliente. Essa responsabilidade é 100% exclusiva do cloud service provider. No modelo de defesa em profundidade (defense in-depth) a primeira camada é representada pela camada física. Não tendo influência sobre ela, o cliente pode desconsiderá-la da jogada e iniciar a proteção de seu ambiente pela próxima camada, a de identidade.
O acesso aos nossos recursos em nuvem é feito sempre à partir de um IdP (Identity Provider). Por padrão, os IdPs utilizados são os do próprio provedor de nuvem (ex: Azure - Entra ID, AWS - AWS IAM), porém é extremamente comum que em uma arquitetura empresarial multi-cloud, a gestão de acesso nos ambientes seja feita por um IdP centralizado, facilitando a gestão dos acessos e seguindo as melhores práticas de IAM.
Utilizando o Entra ID como IdP empresarial
Considerando o Microsoft Entra ID como o IdP de escolha da sua empresa, você poderá usufruir das capacidades de segurança que nele estão presentes. Capacidades essas que deixarão os acessos aos seus ambientes em nuvem e às suas aplicações federadas muito mais seguros!
Na arquitetura apresentada acima, temos uma visão macro sobre como é representada a gestão de um ambiente multi-cloud com um IdP centralizado. Não entrarei nos detalhes técnicos de configuração, provisionamento de funções (roles) e de outros objetos, mas com uma solução gerenciando os acessos aos múltiplos ambientes com apenas um conjunto de credenciais, nós teremos não apenas uma gestão mais eficiente do ciclo de vida das identidades, mas como também poderemos identificair os riscos atrelados aos acessos e às credenciais em aplicações de diferentes domínios e em diferentes ambientes!
User x Sign-in risks
Dentro do ID Protection os riscos são classificados como riscos de usuário e riscos de login. Nas seções abaixo você terá mais informações sobre as identificações feitas e sobre os riscos em si.
Algumas detecções de riscos necessitam de uma licença P2 atribuída, enquanto outras são fornecidas de maneira gratuita pela Microsoft.
Algumas detecções são feitas apenas no modo online, enquanto outras ocorrem de maneira offline.
Os parágrafos abaixo conterão tabelas com as informações sobre os riscos. Essas tabelas foram retiradas desta documentação oficial da Microsoft. As tabelas apresentarão em 3 colunas, respectivamente: a detecção, tipo de detecção (offline ou real-time) e o tipo de licença necessária.
Outro fator importante que devemos citar é que por mais que estejamos falando dos riscos identificados e mitigados à partir do Entra ID Protection, algumas detecções citadas abaixo necessitam de outras soluções para garantir sua aplicabilidade (soluções como o Defender for Endpoint).
User Risks
Os riscos atrelados aos usuários dizem respeito à suas credenciais e também às atividades realizadas na conta.
Comentando sobre alguns dos riscos apresentados acima:
Atividade anômala: é detectado que as operações realizadas na conta do usuário não são comuns ao seu padrão de uso. Isso pode indicar um possível uso indevido das credenciais daquele usuário;
Credenciais vazadas: como parte do Entra ID, a Microsoft realiza varreduras em recursos na internet para identificar credenciais vazadas em explorações de vulnerabilidades bem sucedidas;
(Bônus) Inteligência contra ameaças: capacitando as capacidades de defesa do Microsoft Entra, a solução utiliza de modelos de machine learning para identificar vetores de ataque que apresentam ameaças à sua conta.
Sign-in Risks
As detecções de login acontecem quando uma tentativa de login é considerada arriscada pela análise da solução.
Como fizemos com os user risks, vamos comentar um pouco sobre alguns dos riscos mencionados acima:
Viagem atípica: utiliza informações sobre a geocalização do usuário de de outras atividades realizadas na plataforma para compreender se os diferentes acessos vem de destinos onde seria impossível o transporte durante o período de tempo aplicado;
Token anormal: identifica o uso indevido e anormal de um token de acordo com as características do mesmo. Uma das detecções realizadas é o caso de token replay;
Pulverização de senha (password spray): múltiplas tentativas malsucedidas de login com credenciais diferentes podem indicar um ataque do tipo password spray.;
Acesso em massa a arquivos confidenciais: esse é um dos exemplos de risco detectado com a ajuda de uma solução auxiliar, nesse caso o Defender for Cloud Apps. Essa solução identifica os acessos aos recursos protegidos e sensibiliza o ID Protection.
Severidade dos riscos
Antes de seguirmos para a aplicação das políticas é importante entendermos como o Entra ID classifica a severidade dos riscos.
Tanto os riscos de usuário quanto os riscos de login, são classificados como baixo, médio e alto. Essa classificação é dada de acordo com a avaliação dos pontos de informação coletados pela plataforma e análisado pelos algoritmos de detecção de ameaças implementados pela Microsoft.
Aplicação das políticas
Após compreendermos o modelo de classificação dos riscos, seguiremos para a aplicação das políticas, tanto no modelo antigo quanto no modelo novo.
Versão legado
Hoje em dia essas configurações são todas feitas dentro das políticas de acesso condicional. Antigamente, dentro do Identity Protection tínhamos uma seção específica para criação dessas políticas. Essa seção ainda está ativa, porém ao acessá-la, somos apresentados com o seguinte aviso:
Aviso esses que menciona a migração das políticas para o Conditional Access.
Neste modelo, era configurada 1 política de user risk e 1 política de sign-in risk. Nós selecionávamos os usuários e grupos que iriam sofrer os impactos da política, o risco dela (baixo, médio ou alto) e o controle. A grande diferença entre a política de user risk e de sign-in risk é: na detecção de um risco de usuário nós podíamos bloquear o acesso daquele usuário ou aprovar o acesso e requerer uma troca de senha, para as detecções de risco de login era possível bloquear o acesso ou aprovar e requerer o uso de um segundo fator de autenticação.
Neste modelo, os times de segurança tinham pouquíssima flexibilidade de proteção e poucos recursos para proteger da maneira correta o ambiente.
Versão atual
Nos modelos atuais, utilizamos as políticas de Acesso Condicional (Conditional Access policies) para implementar os controles de segurança de acordo com a severidade do risco identificado.
Dentro das políticas de acesso condicional, na seção "Conditions" nós conseguimos configurar qual a severidade do risco e qual tipo de risco aquela política deve monitorar e remediar, como mostra a imagem abaixo.
Somado a isso, nós temos a extensa granularidade de controles que podem ser impostos ao usuário. Controles como:
Uso de multi-factor authentication;
Acesso feito de dispositivo compliant;
Mudança de senha.
Abaixo uma imagem com todos os controles aplicáveis.
Conseguimos aplicar inúmeros controles a mais, isso somado a outros fatores como a localização de onde o usuário está fazendo os acessos, as aplicações acessadas, as plataformas usadas e muito mais!
Melhores práticas
De acordo com as documentações oficiais da Microsoft, para riscos de usuário considerados alto, você deve exigir a troca de senha. Essa implementação conta por padrão com a exigência do uso de MFA antes da atualização da credencial.
Para riscos de login identificados como médio ou alto, o uso de MFA já é suficiente.
Essas são recomendações genéricas e aplicáveis à maioria dos cenários. É importante que você não se prenda apenas ao que diz a documentação e analise seu caso de uso.
Algumas aplicações de negócio podem oferecer acesso à recursos de extremo valor, logo as políticas de segurança aplicadas sobre o acesso à essas aplicações deve ser diferente das aplicações de uso geral. Múltiplas camadas de controle de acesso devem ser aplicadas, bem como diferentes níveis de remediação de acordo com o risco detectado.
É essencial que as suas políticas de acesso condicional estejam bem estruturadas para tratar os casos genéricos e que se enquadram na maioria dos incidentes identificados, porém você deve se manter atento às exceções, aplicações que apresentam alto risco aos ativos da sua empresa. Essas exceções devem ser tratadas com extrema cautela e segurança reforçada!
Depois deste texto, você não apenas está capacitado para promover a segurança do seu ambiente mas também compreendeu a necessidade de se ter um olhar crítico para cada ambiente, não apenas seguir as recomendações padrão.
Espero que tenha gostado do conteúdo e me coloco à disposição para responder suas dúvidas.
Até logo!