Configuração de Tenant da Microsoft para Bloquear Usuários Comuns de Acessar Informações

1 year ago 76
BOOK THIS SPACE FOR AD
ARTICLE AD

A configuração do Tenant da Microsoft é uma etapa importante para garantir a segurança dos dados da sua organização. Uma das medidas que podem ser tomadas é a criação de regras condicionais para impedir que usuários comuns acessem informações críticas.

Tudo começou quando eu estava enumerando subdomínios da microsoft para procurar falhas de segurança em seus sistemas.

Encontrei o seguinte host: https://canary-endpoint.microsoft.com/

— Sinceramente era a primeira vez que eu estava tendo contato com este ambiente que compõe uma série de ferramentas do Azure. Então estava meio perdido, mas vamos lá.

Fiquei curioso e entrei com um e-mail corporativo, no qual não irei mencionar a empresa por motivos óbvios.

Para não me prejudicar nesta questão, por ser um e-mail de um serviço que estou pagando mas esta me dando acesso a essas informações, meu colega de trabalho teve a idéia de testar em tenant criado por ele.

De primeiro momento ja recebemos um “Sem permissões”,

por que isso acontece ? — bom pesquisando mais sobre como funcionava a ferramenta e pedindo uma ajuda para o meu colega de trabalho “Frederico Magalhães”, que tem contato mais diréto com essas ferramentas que compõe o Azure.

Vimos que a função do meu usuário no locatário do Azure, é um usuário membro mas sem nenhuma permissão administrativa.

Até o momento parece tudo OK né ? — Bom, Sim e Não.

Olhando por algum tempo a aplicação e vendo como ela funciona, como de costume abri o Burp Suite para interceptar todas requisições, cada clique que eu estava fazendo dentro da ferramenta, e todo lugar que eu tentava ter acesso eu recebia um “Sem permissões”.

Até que em um momento me deparei com a seguinte tela “Solução de problemas e suporte”. Achei interessante pois não estava me retornando nenhum erro de permissões, mas também não estava me retornando nenhuma informação de logs.

Resolvi clicar em Selecionar usuário e boom me retornou alguns e-mails.

Bom até ai beleza né alguns e-mails, resolvi ver os logs de notificações e encontrei outro endpoint vazando mais algumas informações, sem me retornar nenhum erro de permissões.

Abrindo o Burp Suite fui ver todas requisições que foram feitas de cada clique nesses pontos interessantes mencionados acima… eee Boooom!!!! encontrei algumas requisições GET/POST que posso fazer e obter as seguintes informações.

Bom Consigo pegar informações que vem direto do Azure AD que faz sincronia com o Ad On primese quando ele importa os dados pro Azure AD ele fica disponível em todas ferramentas que compoe o Azure dentre eles o End Point Manager.

O usuário ainda tem acesso a informações que são públicas, mas também a informações que não devem ser listadas (privadas).

informações do grupo local, data e hora da última alteração da senha do usuário, informações do usuário como e-mail secundário, cidade, estado etc… que não é público (alguns usuários tornam público, mas quem não torna visível eu também consigo ver).

A quais grupos esse usuário pertence, sejam eles administradores ou não, bem como quaisquer grupos criados por um administrador em “Teams” e “Exchange”.

Entrei em contato com a Microsoft para entender o por que isso era possível.

Primeiro Bloqueio: Pediram para realizar o seguinte bloqueio, seguindo esta documentação. https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions#restrict-member-users-default-permissions

Vamos lá, temos um usuário comum sem nenhuma permissão de administrador e com configurações padrão da Microsoft, o usuário ainda tem acesso a informações.

Bom, o primeiro bloqueio seguindo a documentação não funcionou, vamos passar para o segundo.

Segundo Bloqueio: Pesquisando com o meu colega Fred encontramos a seguinte solução.

O administrador aplica o seguinte comando:
cmdlet Set-MsolCompanySettings — UsersPermissionToReadOtherUser sEnabled $false

Com este comando parece que funcionou a princípio, o usuário comum não consegue ver nenhuma das informações mencionadas acima.

Porém, estamos com um problema que afetou outros produtos 365, todos os usuários agora estão com problemas para visualizar o organograma no Teams pois sumiram, e com problemas no planner todos os usuários estão em branco sem aparecer nomes, e-mail etc…

Na verdade, isso bloqueou usuários mal-intencionados comuns, mas afetou todos os outros usuários que utilizam os produtos 365 alocados na empresa.

Vimos que no primeiro bloqueio, de acordo com a documentação da Microsoft, ele ainda está vulnerável para acesso a várias informações (privadas e locais).

E no segundo bloqueio, pesquisando no fórum de ajuda da Microsoft, esse bloqueio funciona por um lado e estraga todo o contexto por outro.

Um outro colega nosso (Matheus Kozuki) teve a brilhante idéia, ja que não estavamos conseguindo encontrar uma solução definitiva que não afetasse os usuários e nem desse permissões a uma pessoa mal-intencionada. Ele foi até o CHATGPT e encontrou a seguinte solução.

Terceiro Bloqueio Solução final sem nenhum dano e o correto a ser feito:

O administrador bloqueará o acesso condicional baseado em aplicativo de nuvem.
O usuário comum nem terá acesso ao painel do EndPoint Manager, ele será barrado logo na etapa de autenticação.

Como faço isso ?

Para criar uma regra condicional, você pode seguir os seguintes passos:

Passo 1: Acesse o portal de administração do Azure da sua organização.Passo 2: Clique em “Azure Active Directory” na barra de navegação à esquerda.Passo 3: Selecione “Regras de Acesso Condicional” na seção “Segurança”.Passo 4: Clique em “Novo” para criar uma nova regra condicional.Passo 5: Selecione “Usuários e grupos” na seção “Usuários e grupos”.Passo 6: Escolha “Usuários e grupos específicos” e selecione os usuários que você deseja bloquear.Passo 7: Na seção “Acesso”, selecione “Negação” e escolha as opções de acesso que você deseja negar, como “Acesso ao portal do Azure” ou “Acesso a aplicativos específicos”.Passo 8: Salve a regra condicional e aguarde que ela seja aplicada a todos os usuários selecionados.

Ao criar uma regra condicional dessa forma, você pode bloquear usuários comuns de acesso a informações críticas, garantindo que apenas usuários autorizados tenham acesso a elas. Isso pode ajudar a proteger a sua organização contra possíveis violações de segurança e garantir a privacidade e confidencialidade dos seus dados.

Considerações Finais da Microsoft após semanas de e-mails trocados:

Hello Guilherme,

Entendemos sua preocupação.

Para responder à sua pergunta, a restrição será apenas no front-end, pois é assim que esse recurso é projetado. Essa opção é um recurso de restrição de interface do usuário e não uma restrição de segurança. O objetivo desse recurso é principalmente evitar que usuários não administradores configurem incorretamente os recursos de sua propriedade acidentalmente, embora ainda possam acessá-los usando PowerShell, GraphAPI ou outros clientes, de acordo com a função personalizada atribuída a eles .

Para atingir a restrição nas solicitações GET conforme você mencionou, recomendamos a criação de uma política de acesso condicional voltada para o gerenciamento do Microsoft Azure que bloqueará o acesso de não administradores ao gerenciamento do MS Azure.

Verifique se as informações abaixo fornecem mais clareza sobre o recurso “ Restringir o acesso ao portal de administração do Azure AD” .

https://learn.microsoft.com/ en-us/azure/active-directory/ fundamentals/users-default- permissions#restrict-member- users-default-permissions

Atenciosamente,

MSRC.

Fim !!!

É isso pessoal espero que tenham gostado, para quem ja tem essa informação compartilhe com os colegas, espero ajudar muitas empresas que não cometam este erro para tornar seu ambiente mais seguro.

Linkedin: https://www.linkedin.com/in/guilhermesgi/

Twitter: https://twitter.com/guilhermesgi

Read Entire Article