Bloqueando o acesso externo ao O365 – Parte 1 (ADFS)

By: Cesar Hara

O número de clientes preocupados com o acesso externo aos dados hospedados na nuvem vem crescendo muito, um dos principais motivos é a questão do vazamento de informação.

Antes de começar vale ressaltar que este bloqueio/controle é feito na camada de autenticação - ou seja, se você está procurando um controle dentro da aplicação, outros métodos serão necessários.

Para melhor entendimento, utilizarei as Claims Authorization Rules do ADFS 2.0, que funcionam no ADFS 3.0 (porém na versão 3.0, também é possível criar as regras de maneira diferente conforme este artigo ) .

Espero que este artigo possa ajudá-los, vamos começar!

O primeiro passo é definir qual será a política de bloqueio. Para o nosso exemplo, vamos criar um bloqueio externo para todos os serviços do Office 365 e então liberar o acesso somente a um grupo específico.

Segundo passo: definir a regra. Nossa regra deverá seguir o formato abaixo (irei explicar as condições):

  

exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) &&
 NOT exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "GroupSiD"]) &&
 NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "IP Public List"]) 
 =>issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");

A lógica da regra funciona da seguinte forma: todas as três primeiras condições precisam ser verdadeiras para que o acesso seja negado:

• O acesso precisa ser efetuado através do WAP (ADFS Proxy) e por este motivo é mandatório ter o WAP instalado e publicá-lo na internet (ou um proxy de terceiro que estampe o cabeçalho x-ms-proxy, mais detalhes aqui).
• O usuário não faz parte do grupo especificado.
• O acesso não foi feito pelo range de IP público da empresa declarado na regra. Extremamente importante: clientes Outlook mesmo estando dentro da rede e utilizando autenticação “Basic Over HTTPS”, fazem um acesso externo para se autenticar no ADFS. Deve seguir o formato regex, conforme este artigo.

Consequentemente, se um usuário tentar se autenticar externamente e uma das condições não for verdadeira, o acesso será concedido. Por exemplo:

• Se o acesso não vier do WAP (ocorre em clientes que não implementaram WAP ou o proxy de terceiros não estampa o cabeçalho “x-ms-proxy” ).
• O acesso for realizado por um usuário membro do grupo.
• O acesso é efetuado de um IP declarado no range.

O nosso terceiro passo será implementar a regra no ADFS (recomendamos que este passo seja feito em um ambiente de testes antes de produção):

1. O group SID na nossa regra de exemplo será: S-1-5-21-1857692361-4164961978-1545530999-7102;
2. Na condição de IP público, utilizaremos primeiramente um IP fictício e depois para comprovar o funcionamento da regra adicionaremos o correto: \b187\.56\.239\.163\b;
3. Para inserir a regra de bloqueio, o acesso é efetuado na console do ADFS “Relying Party Trusts”, selecionando a opção “Microsoft Office 365 Identity Platform” e então “Edit Claim Rules”:
   
4. Na janela seguinte selecione a aba “Issuance Authorization Rules” , opção “Add Rule” para adicionar a regra:
   
5. Na próxima janela escolha a útlima opção no dropbox “Send Claims Using a Custom Rule”:
   
6. Dê um nome a regra, por exemplo “Block All External Access”, e então insira a regra, clicando em “Finish” e depois “Apply”:
   
   *Para fins de teste, o IP acima foi adicionado na regra para simular o bloqueio. Ou seja, se o usuário não for membro do grupo então o acesso externo só será possível se feito através do IP 192.168.10.10.

Quarto passo, hora de testar a nossa regra. Esse é um momento muito crítico em que atendo diversos clientes pois a regra não estava “funcionando”.

Para o teste via browser podemos utilizar qualquer conta que a efetividade da regra é imediata – já para testes via Outlook client, recomendo utilizar uma conta de teste que nunca tenha se autenticado na máquina que será utilizada (pelo fato da existência de cache de token do ADFS e Exchange Online que pode distorcer o resultado dos testes).

1. A primeira tarefa antes de iniciar os testes é habilitar a auditoria do serviço do ADFS, seguindo este artigo.
2.  Após habilitar a auditoria, limpe os logs de segurança do Windows no Event Viewer para uma maior facilidade na visualização dos eventos.
3. Realize o acesso externo ao portal do Office 365 (de uma rede não autorizada e com a conta que não faz parte do grupo). A seguinte mensagem deve ser exibida:
   
4. Ao analisar o Event Viewer, os seguintes logs irão indicar a falha de acesso:
   
   Os logs acima trazem as informações que precisamos: o IP de origem do dispostivo, group membership do usuário, tipo do dispositivo, etc. Estas informações são muito importantes para troubleshooting e também para entender o motivo caso a regra não se comporte adequadamente:
   
   Podemos verificar que o IP de origem acima não estava na nossa regra. Nos eventos 501 não existe nenhuma informação que o usuário pertence ao grupo permitido.
5. Vamos incluir o IP de origem acima em nossa regra para que o usuário consiga acessar, garantindo que a rede liberada está realmente permitida, a regex ficará no seguinte formato: "\b192\b.168\b.10\b.10\b|\b187\b.56\b.239\b.163\b"
6. Ao realizar um novo teste, o acesso foi concedido com sucesso:
   
7. Através do Event Viewer agora veremos novos eventos e o log de que o token foi emitido com sucesso:
   

Se você conseguiu chegar até aqui, gostaria de agradecer todo tempo dedicado. Agora você pode explorar outros cenários mais específicos, conforme os artigos mencionados acima.

Na versão de ADFS do Windows Server 2016, existem templates pre-criados que facilitam muito a nossa vida, mas acredito ser interessante entender como as regras funcionam primeiro. Este artigo detalha o funcionamento do “Access Control Policy Template”.

Como notaram no título do artigo, esta é a “Parte 1”. O bloqueio completo que atende 100% dos cenários requer outra tecnologia chamada “Conditional Access” - uma feature do “Azure Active Directory Premium”, que realiza um controle muito interessante por Aplicação, mas se aplica somente a autenticação via ADAL (Modern Auth, oAuth).

Até o próximo artigo!