Muitos Administradores provocam erros em suas configurações por não analisarem o ambiente como um todo! Nesta postagem vamos explorar alguns erros comuns que varios administradores (inclusive eu) já cometemos ou estamos cometendo!
- Redefinir Senha quando o usuário não possui senha
- Passe de Acesso Temporário
- “Confirmar entrada segura” não informa detecções futuras
- Não é quantidade de Políticas, é qualidade na política!
- Evite excluir os convidados das políticas de Proteção
- Atenção às Limitações de Retenção de Auditoria
- Fontes de pesquisa:
O EntraID Protection analisa os indicadores de todos os serviços do ecossistema da Microsoft, em caso de ambiente Hibrido, até do ambiente local.
Essa análise de risco tem a capacidade de notificar os administradores, e idealmente, pode ser integrada com outros recursos do Entra e do Defender XDR para implementar medidas corretivas e preventivas.
Destaco nessa análise que nem tudo esta associado a licença P2 (mais cara), atente-se a documentação do produto, as detecções de risco não premium não solicita a licença P2.
Em várias análises de segurança em Tenants recomendei diversas alterações em configurações que os administradores juravam estar correta e na verdade estavam erradas. Esses erros de administração torna a solução mais complicada no que diz respeito a entender a própria solução.
Os itens abaixo são recorrentes em erros de configuração:
Redefinir Senha quando o usuário não possui senha
Alguns cenários são propícios para gerar uma situação estranha.
Passe de Acesso Temporário
Os métodos de autenticação sem senha, como FIDO2 e entrada por telefone sem senha por meio do aplicativo Microsoft Authenticator, permitem que os usuários entrem com segurança sem uma senha. Os usuários podem inicializar métodos sem senha de duas maneiras:
- Usando métodos de autenticação multifator existentes do Microsoft Entra
- Usando um Passe de Acesso Temporário (TAP)
Outros itens devem ser levados em consideração:
- Usuário comprometido como Alto Risco
- Usuario faz uso da chave FIDO2
Principalmente o usuário e obrigado a redefinir a senha! Quando o usuário logar e se encaixar em algum das opções acima a redefinição vai falhar e o usuário afetado não vai acessar o ambiente.
“Confirmar entrada segura” não informa detecções futuras
é um problema!
Varios cenarios podem afetar sua configuração de usuários em risco! por exemplo:
- Você entra em uma VM do Azure com um IP público estático
- O Entra ID Protection sinaliza-o como de médio risco (propriedades de início de sessão desconhecidas)
- Uma política de Acesso Condicional bloqueia a entrada de médio risco
- Um administrador marca o login arriscado como login seguro confirmado no Entra ID Protection
Com o usuário em risco, ou arriscado, o administrador pode “liberar” esse usuário, acontece que o ambiente não aprende com isso, a forma que temos para que o ambiente aprenda com isso é com acesso política de Acesso Condicional com risco de entrada e MFA
Não é quantidade de Políticas, é qualidade na política!
Pessoas, Processos e Tecnologia!
Vejo uma questão recorrente em relação aos controles de segurança no Microsoft 365 e no EntraID. Esse tema é abordado em diversos blogs que tratam dos desafios de segurança do Microsoft 365. A capacidade de restringir o acesso a grupos específicos e aplicar regras distintas para diferentes cenários é fundamental, embora muitas vezes seja negligenciada na prática.
Em vez de depender das páginas de Política de Risco de Usuário ou Política de Risco de Entrada na seção de Proteção de Identidade, é possível utilizar o Acesso Condicional para gerenciar restrições de autenticação com base no risco identificado pelo EntraID. Isso permite estabelecer políticas mais rigorosas para usuários com privilégios elevados em comparação aos usuários padrão. Eis algumas sugestões práticas:
- Para os usuários padrão, considere bloquear o acesso em caso de alto risco.
- Para os membros da equipe executiva, cogite bloquear o acesso em caso de risco médio ou superior.
- Para os usuários com funções privilegiadas, como Administrador Global, pense em bloquear o acesso em caso de risco baixo ou superior.
É importante ressaltar que, à medida que se reduz o limiar de risco, aumenta-se a quantidade de autenticações que precisam ser avaliadas, o que pode resultar em sobrecarga. No entanto, essa é uma troca que pode ser justificada com base na tolerância ao risco e em outras considerações.
O objetivo não é sugerir uma abordagem excessivamente restritiva, onde apenas autenticações de baixo risco sejam permitidas. A ideia é encorajá-lo a considerar a implementação do EntraID Protection, mesmo que seja de forma gradual. Começar com escopos menores pode proporcionar benefícios imediatos e permitir a ampliação do uso à medida que a confiança no sistema cresce.
Evite excluir os convidados das políticas de Proteção
Já discutimos a importância de adotar abordagens variadas no EntraID Protection, adaptando as políticas de escopo de acordo com o usuário, apetite ao risco, entre outros fatores. Porém, um erro a ser evitado é a exclusão indiscriminada dos convidados das políticas de Proteção.
É comum justificar essa exclusão argumentando que não se pode controlar as credenciais dos convidados, que estão “hospedadas” no locatário de origem. Portanto, não é possível impor redefinições de senha ou mitigar riscos no nível do usuário para permitir a autenticação. Se uma política tentar impor uma redefinição de senha, por exemplo, ela será substituída por um bloqueio.
Entendo o raciocínio por trás disso. A preocupação é evitar que os convidados sejam bloqueados e prejudiquem a produtividade. Por isso, muitas vezes optamos por não impor políticas de risco baseadas no usuário aos convidados.
Entretanto, é importante lembrar que, na maioria dos casos de acesso de convidados, há muito menos supervisão e controle sobre a segurança do usuário, do dispositivo e da sessão. Embora seja possível, é raro que os clientes verifiquem a conformidade do dispositivo de um convidado. Na maioria das vezes, simplesmente permitimos que entrem sem garantias quanto à segurança do dispositivo.
Portanto, minha sugestão é que, quando possível, devemos ser mais proativos com as políticas de Proteção de EntraID para os convidados. Isso pode não ser algo que se implemente de forma agressiva de imediato, mas é algo a se considerar.
Atenção às Limitações de Retenção de Auditoria
O período de retenção dos logs do Entra ID varia conforme o nível de licença, mas os registros de usuários arriscados nunca expiram.
Isso implica que, no plano gratuito, apenas sete dias de entradas de risco são visíveis. Com o Entra ID P1, esse período se estende para 30 dias, enquanto o P2 amplia para 90 dias. Infelizmente, não é possível retroceder ao atualizar as licenças. Por exemplo, se um incidente ocorrer e você optar por adquirir P1/P2 para acessar mais dados, isso não afetará registros passados.
Essa limitação pode se tornar problemática caso nunca tenha investigado o EntraID Protection e decida ativá-lo posteriormente. As entradas na página de Usuários Arriscados não são afetadas pelos períodos de retenção, mas os dados necessários para investigação podem estar. Por exemplo, o campo “Risco da Última Atualização” pode estar além do período de retenção de log, o que poderia dificultar uma investigação completa de outros registros do EntraID, como logins arriscados ou detecções de risco.
Para evitar esse problema, mantenha-se atualizado sobre as investigações de risco e/ou exporte seus dados para outra solução, como Log Analytics ou Sentinel. Embora o Defender XDR tenha um período máximo de retenção de 180 dias.
Finalizando por hora…
Em resumo, o Entra ID Protection é uma ferramenta extremamente valiosa para fortalecer sua estratégia de defesa cibernética. Muitos incidentes poderiam ter sido prevenidos completamente se o sistema estivesse configurado adequadamente ou se fosse monitorado de forma mais eficaz. Na verdade, foi um desafio resumir este artigo em apenas cinco erros, pois há outros que merecem atenção!
Além de evitar as armadilhas discutidas neste artigo, é fundamental que você mergulhe profundamente no Entra ID Protection para compreender plenamente suas capacidades e nuances. A exploração completa dessa ferramenta permitirá que você maximize seu potencial de proteção cibernética e fortaleça a segurança de sua organização.
Fontes de pesquisa:
- Documentação Oficial do Microsoft Entrada de ID Protection: Microsoft Entrada de ID Protection
- Microsoft Security Blog: Microsoft Security Blog
- Microsoft Tech Community: Microsoft Tech Community
- Microsoft Security Center: Microsoft Security Center
- Proteção de ID do Entra – Série de erros de segurança comuns do Microsoft 365 – Ru Campbell MVP
- (2) Jef Kazimer (@JefTek) / X (twitter.com)
Blog do Chesley 