Introdução

“Mas aqui no AzureAD (pra quem é dos tempos antigos ai) fica tudo no mesmo lugar. Não tem nem lugar pra organizar meus usuários”

Que atire a primeira pedra quem nunca disse ou pensou em algo parecido durante o primeiro contato com o EntraID (também conhecido, antes da vigésima alteração de nomes da Microsoft, como Azure AD). Foi assim comigo, o primeiro contato foi uma visão desorganizada e confusa, tudo no mesmo menu, sem segmentação por departamento ou qualquer outro nível.

O que eu sentia falta eram das famosas Unidades Organizacionais, ou para os mais íntimos, OUs (Organizational Units. Em um ambiente de Active Directory, o cenário classico e que reflete as melhoras práticas é a segmentação de objetos, departamentos e níveis de acesso utilizando as OUs. A partir delas, temos flexibilidade para aplicar políticas a determinada audiência no ambiente, seja por usuários ou por dispositivos.

Obs: Imagem meramente ilustrativa, eu particularmente mantenho contas de usuários e computadores dentro da mesma OU

Unidades Administrativas, o primo das das pastinhas (OUs)

Ao contrário do AD que utiliza um modelo hierárquico, e é por isso que as OUs fazem tanto sentido. O Entra ID, por sua vez, segue a filosofia de organização por atributo em que objetos do mesmo tipo são alocados juntos. Pois bem, como não estamos aqui para falar sobre tipos de design, deixe-me falar sobre o tópico principal.

Embora não existam as OUs, no Entra ID temos as Unidades Administrativas que vão funcionar de forma semelhante as OUs SE, e apenas SE, estivermos falando de permissões de acesso ao determinado objeto.

Funciona basicamente assim: Digamos que, por questões de governança, compliance ou requisito de negócio, apenas o pessoal autorizado pode ter acesso para modificar ou até mesmo dar suporte a contas de usuários C-Level na empresa. Por padrão, quem possui as roles do Entra de User Admin ou um Global Admin da vida, conseguirá realizar alterações em todos os usuários do seu Tenant (obviamente cada role terá sua permissão devida). Com as AUs (Administrative Units), conseguimos “quebrar” essa hierarquia de permissões e isolar alterações em contas específicas, definindo quem pode realizar qualquer ação nelas. A figurinha abaixo deve ajudar no entendimento.

Aqui temos 4 Unidades Administrativas. Dentro de cada uma podemos definir quem poderá dar suporte ou realizar qualquer alteração nos objetos que fazem parte dessa AU.

Digamos que o time de Suporte do Brasil, receba permissão de User Admin na AU Business School. Caso um usuário que esteja dentro da Business School solicite suporte e um membro do time de Suporte dos EU pegue esse chamado, ele(a) não conseguirá fazer absolutamente nada. Isso por que o acesso está restrito APENAS ao time de suporte do Brasil.

Obviamente o permissionamento é flexível, e você ajusta da forma que precisa, atribuindo cada objeto que você quer/precisa a respectiva AU e dando permissão a grupo de segurança x, y ou z.

E se eu for um Global Admin, sigo acessando tudo, certo? ERRADO!

Se configurado, as Unidades Administrativas valem também para um Global Admin. Claro que por ter permissões globais, um GA pode se auto-adicionar como membro de User Admin dentro de uma AU e alterar um usuário que faça parte dela, mas, o importante aqui é reforçar que por padrão, até mesmo um GA é afetado.

E como implantar (The basics)

Not that hard! As Unidades Adminstrativas ficam escondidas no menu de Roles & Admin, no Entra ID.

Clicando em “Add” voc”e defini o nome, uma descrição e segue para o próximo passo.

Na tela seguindo, você precisa quem terá qual role para essa AU. É onde definimos as permissões. É possível selecionar, por exemplo, User Admin e adicionar usuários a essa role APENAS para essa AU. Clicando no nome da Role, você verá a tela para atribuição onde poderá selecionar o que definir.

Uma vez concluido, clique em Review e Create!

Pronto, com a AU criada, você precisa entrar nela para adicionar os objetos que serão gerenciados. Veja que podes adicionar Users, Grupo e Devices.

Caso precise ajustar alguma permissão, no mesmo menu consegue acessar a parte de roles.

Conclusão

Uma vez configurado, os efeitos são imediatos. Simples e funcional.

Não é muito comum eu ver uso de AUs em ambiente, e embora seja um recurso relativamente simples, é super útil e cai muito bem onde a exigencia por compliance é mais rigorosa. Logo menos posto um caso de uso com AUs.

Espero que tenha te ajudado! Grande abraço \,,/

O post Unidades Administrativas – O que são e por que utilizar apareceu primeiro em Entra ID Brasil.

Faaala galera, 100%!?

Facilitar a vida para focar no que de fato importa é um dos lemas que devemos seguir para trazer inovação e garantir que o melhor está sendo entregue. Longe de mim cogitar que o tema do nosso artigo de hoje não seja importante, mas eu tenho certeza de que você vai curtir ter uma ajuda do Entra ID para te lembrar de rodar aquela verificação semestral de acessos.

A revisão de acessos é um ponto crítico na gestão de segurança da informação, principalmente quando se trata de acessos administrativos. O artigo de hoje vista compartilhar uma solução de revisão que utiliza o PIM (Privileged Identity Management) e o Access Review, dois recursos presentes na licença M365 E5 ou add-ons de compliance.

Antes de pular para a solução em si, obviamente, vamos começar do começo, definindo o que é cada recurso e como juntar as duas peças.

RBAC

Na nuvem Microsoft temos o conceito de acesso baseado em função, o famoso RBAC (Role based access). A ideia desse tipo de acesso é flexibilizar e granulizar as permissões existentes em cada workload. No Entra ID, por exemplo, ao invés de entregar a permissão de global admin, podemos ter o acesso específico para user administrators ou grupos. A ideia é trabalhar sempre considerando a maxima do zero trust de entregar a menor permissão necessária (least privilege access).

Além das funções padrões, é possível criar as custom roles, atribuindo ou removendo o que for necessário para seu cenário. Complexo, mas funcional.

PIM

Ainda considerando o Zero Trust, framework que deve ser seu guia, temos o conceito de just-in-time access (Acesso quando necessário). A ideia aqui é que administradores tenha acesso administrativo apenas quando for necessário e não o tempo todo, como era o padrão em ambientes ADDS.

O conceito busca manter o ambiente o mais fechado possível, considerando que uma conta administrativar não é e não deve ser utilizada o tempo todo.

A solução de PIM permite que você solicite elevação de privilegio, atrás de uma role, apenas quando for necessário e por um tempo determinado. Essa solicitação é feita via Entra ID e pode ter efeito imediato ou exigir uma aprovação antes de surtir efeito. A aprovação funciona como um segundo filtro, em que, caso a conta seja comprometida, o atacante não conseguirá executar nada visto que para ter o privilegio Global Admin uma segunda pessoa deve aprovar.

O PIM pode ser aplicado a usuário e grupos que estão habiltiados a receberem Roles do Entra.

Lembre-se que para adicionar uma role a um grupo a flag que permite essa configuração deve ser ativada no momento da criação do grupo.

Access Review

Parte do processo de governança inclui a revisão acesso a grupos e aplicações em seu ambiente. Como já comentado, embora simples, é um processo que pode ser moroso e nem sempre é tido como prioridade.

Para faciltiar a vida de todos, com o Access Review você pode escolher quais grupos ou aplicações farão parte da revisão de acesso e definir qual a peridiocidade e quem deve realizar a revisão.

Na data configurada, o Entra ID informará ao revisor ou revisores, a depender da configuração, para acessarem o portal e informar quem continuar tendo acesso (sendo membro) do grupo ou aplicação definido. E se ninguem responder? É possível definir uma ação automatica, sendo essa não realizar nada ou seguir o que a analise do Entra julga como correta.

Juntando as peças

Você já deve ter entendido onde quero chegar mas seguirei escrevendo, just in case.

Considerando que podemos adicionar grupos ao PIM, por que não incluir revisões periódicas utilizando o Acces Review? Dessa forma teremos o processo de revisão de acessos administrativos automatizado e garantiremos que apenas as pessoas corretas terão a possibilidade de solicitar elevação de privilegio via PIM.

O processo, de forma macro seria:

1. Crie um grupo que permita atribuição de roles
2. Configure as roles no PIM utilizando esse grupo
3. Adicione os usuários que pode soclitiar elevação de privilegio a esse grupo (obviamente, um grupo por role)
4. Crie uma politica no Access Review para esse grupo

Com essa estratégia você garantirá que periodicamente os usuários serão revisados e manutenção no grupo e de acesso privilegiado estará em dia.

Proximos passos

Agora que já temos a solução desenhada, vamos a implantação!

Meu proximo artigo será um passo a passo mostrando como encaixar todas as peças e entregar essa solução. Da criação do usuário até a configuração final e teste do Access Review.

Espero que esse artigo tenha te ajudado!

Grande abraço \,,/

O post PIM e Access Review: Melhore a Gestão de Acessos Privilegiados no Entra ID apareceu primeiro em Entra ID Brasil.