Eventos mundiais desde março de 2020 destacaram um dos principais benefícios do Office 365 e dos serviços SaaS baseados em nuvem em geral: eles estão disponíveis a qualquer momento, em qualquer lugar e em qualquer dispositivo.  Enquanto o mundo foi forçado a trabalhar em casa, aplicativos do Office 365, como Teams, Outlook, SharePoint e OneDrive, poderiam ser facilmente acessados fora da rede corporativa tradicional e até mesmo em dispositivos não corporativos.  De fato, a maioria das assinaturas do Office 365 e do Microsoft 365 licencia usuários para instalar e usar seus aplicativos em até cinco dispositivos.

Uma das principais preocupações decorrentes disso pode ser a prevenção de perda de dados.  Por exemplo, por padrão, um usuário pode se autenticar em seu OneDrive corporativo ou caixa de correio em um dispositivo pessoal sem nenhuma limitação na capacidade de sincronizar todos os arquivos e e-mails hospedados nesse serviço.  O que acontece com as cópias locais de dados quando esse usuário deixa a organização?

O Azure Active Directory Conditional Access pode colocar os administradores de volta no controle. Parte da licença Azure Active Directory Premium P1, com o Conditional Access você controla as condições sob as quais um usuário é concedido ou bloqueado o acesso aos recursos do Azure AD. Mesmo que você conceda acesso, pode forçar medidas adicionais, como responder a um prompt de autenticação multifator (MFA) ou quanto tempo antes que eles precisem fazer login novamente.

Como o Conditional Access identifica dispositivos corporativos

Em nosso cenário, usaremos o Conditional Access para permitir que os usuários façam login no Office 365 apenas em dispositivos corporativos.  Fazemos isso com base no estado do dispositivo.

Embora não haja um estado de dispositivo chamado “dispositivo corporativo” no Acesso Condicional, podemos identificar duas coisas sobre um dispositivo e inferir a partir delas se um dispositivo é de propriedade corporativa:

1. O dispositivo está conectado ao Azure AD híbrido?
2. O dispositivo está marcado como compatível?

O Azure AD híbrido refere-se a um estado em que um dispositivo está conectado ao seu Active Directory local, mas também sincronizado e conectado ao Azure AD baseado na nuvem. Já abordamos como colocar seus dispositivos nesse estado aqui. Isso é adequado apenas para dispositivos Windows.

Na captura de tela abaixo, você pode ver como o Azure AD relata o tipo de associação híbrida ao Azure AD.

Marcação como compatível significa que o dispositivo está inscrito em uma solução de gerenciamento de dispositivos móveis, como o Intune, e atende aos requisitos de conformidade desse MDM, como ter um firewall ativo. De muitas maneiras, este é um controle melhor do que apenas verificar a associação de domínio do dispositivo, pois você também está garantindo um nível de postura de segurança, o que é benéfico para uma estratégia de confiança zero. No entanto, se você estiver apenas interessado em confirmar que o dispositivo está inscrito no Intune, você poderia definir uma política de conformidade sem requisitos de segurança específicos. Este método pode ser usado para as “4 grandes” plataformas modernas: Windows 10, macOS, iOS e Android.

Na captura de tela abaixo, você pode ver como o Intune relata a conformidade do dispositivo.

Estritamente falando, o termo correto para um dispositivo em qualquer um desses estados é um dispositivo gerenciado. Isso significa que um administrador de TI tem algum nível de controle sobre esse dispositivo, como a capacidade de aplicar e controlar configurações a partir do Group Policy ou do Intune. Dispositivos em nenhum desses estados são considerados não gerenciados. Supondo que tenhamos limitado a capacidade de se inscrever no Intune a dispositivos corporativos apenas, podemos usar os termos gerenciados e corporativos de forma intercambiável.

Um ponto importante a ser observado é que o Azure AD pode solicitar informações de certificado em algumas plataformas e navegadores se uma política de Acesso Condicional baseada no estado do dispositivo for usada. Isso geralmente ocorre em plataformas não Microsoft, como plataformas Apple e Google. Isso acontece porque as informações sobre o estado do dispositivo são mantidas em um certificado naquele dispositivo e nem todos os softwares disponibilizam isso automaticamente para o Azure AD durante a autenticação.

Criando a política de Acesso Condicional

As políticas de Acesso Condicional são criadas dentro de Azure AD > Segurança > Acesso Condicional. A prática recomendada é dar um nome à sua política que facilite identificar exatamente qual o objetivo da política. Isso porque, se várias políticas correspondem a uma tentativa de autenticação, elas todas se aplicam, e uma boa convenção de nomenclatura simplifica a solução de problemas e o gerenciamento.

As políticas são divididas em atribuições e controles de acesso. Atribuições são equivalentes a uma lista de verificação de tudo o que deve ser verdadeiro sobre o login para que a política se aplique a ele. Para a maioria dessas configurações, é possível incluir e excluir condições. Por exemplo, incluir todos os usuários exceto funcionários de TI. Se a política se aplicar, então os controles de acesso determinam se o acesso é negado ou permitido e, quando permitido, quais outras etapas e medidas precisam ser aplicadas ou ser verdadeiras.

Antes de mergulhar no Acesso Condicional, é importante considerar o quão poderoso ele é: ele oferece a capacidade de bloquear completamente a autenticação de todos os aplicativos. Portanto, é possível configurar algo incorretamente e bloquear usuários importantes de aplicativos importantes, ou até mesmo todos os administradores. Deve-se considerar a criação de exceções para contas de acesso de emergência de quebra de vidro, cuja atividade de login você monitora. Pessoalmente, este é o primeiro passo que eu tomo ao criar qualquer política de Acesso Condicional.

Atribuições

Usuários e grupos controlam a quem a política se aplicará. Se você não estiver nesta atribuição, não estará sujeito às suas regras. Para uma política que bloqueia o acesso ao Office 365 em dispositivos não gerenciados, você pode desejar abranger todos os usuários, mas excluir convidados/usuários externos e as contas de acesso de emergência. Alternativamente, inclua apenas um grupo apropriado do Azure AD.

Para Aplicativos ou ações na nuvem, selecione Office 365. Você pode selecionar mais de um aplicativo na nuvem, então pode ser interessante criar uma política que limite todos os aplicativos que você considera sensíveis, não apenas o Office 365. O aplicativo do Office 365 listado no Acesso Condicional é na verdade uma coleção de outros aplicativos que você pode selecionar individualmente. Por exemplo, ele inclui o Exchange Online e o SharePoint Online, mas teoricamente você pode escolher apenas os aplicativos componentes. A razão pela qual você deseja selecionar o Office 365 e não nenhuma de suas partes componentes deve-se à natureza integrada do serviço. Selecionar a plataforma unificada reduz os problemas associados às dependências que eles têm entre si.

Condições são onde você especifica sinais e propriedades de autenticação como endereços IP, sistemas operacionais e aplicativos (que, de maneira geral, significam acesso web ou de aplicativo cliente). Em nosso exemplo, estaremos bloqueando o acesso a todas os métodos de acesso do Office 365, então não especifique nenhuma condição. Isso significa que todas as condições se aplicam. Um uso comum dessas condições, no entanto, é ter regras diferentes para acesso web e acesso de aplicativo desktop.

Você também notará a condição de estado do dispositivo aqui, mas na verdade não a selecionaremos para esta política. Continue lendo para entender por quê.

Controles de acesso

Agora que lidamos com o elemento “se isso…” de nossa política, é hora do “então isso…”. Os controles de acesso são divididos em configurações de conceder e sessão.

No painel de concessão, selecione conceder acesso e marque as caixas para dispositivo necessário a ser marcado como compatível e exigir dispositivo híbrido Azure AD juntado. Você também terá a opção de escolher se o dispositivo deve ser ambos, ou apenas um deles. A recomendação é selecionar exigir um dos controles selecionados para que tanto dispositivos somente Azure AD quanto dispositivos de domínio no local possam obter acesso.

O que fizemos aqui é dizer “você pode obter acesso, mas precisa de um dispositivo gerenciado”. De outra forma, isso também diz “você não pode obter acesso a menos que seja um dispositivo gerenciado”. Considerando que nosso processo de junção de domínio no local é seguro e nosso registro em Intune é limitado a dispositivos corporativos, isso limita todo o acesso ao Office 365 a dispositivos corporativos.

Configurações de sessão controlam o que um usuário tem permissão para fazer depois que eles recebem acesso. Por exemplo, em sessões de navegador, você pode usar restrições aplicadas pelo aplicativo para bloquear downloads de serviços como Exchange Online e SharePoint Online. Espero que isso o faça pensar sobre as várias maneiras pelas quais você pode moldar suas políticas: potencialmente uma para bloquear o acesso a aplicativos completos em dispositivos não gerenciados, mas outra que permite o acesso apenas a aplicativos web, impondo nenhum download.

Implantação da política de Acesso Condicional

Com todas as configurações aplicadas, sua política de Acesso Condicional pode agora ser colocada nos estados somente relatório ou ativado. A intenção do modo somente relatório é permitir que os logs de entrada no Azure AD auditem o que teria acontecido sem interromper o ambiente de produção. Você pode então usar estas informações para entender as consequências da política: por exemplo, quanto de interrupção podemos esperar e, portanto, que tipo de orientação devemos fornecer aos nossos usuários?

Existe um aviso significativo no modo somente relatório em nosso caso. Como mencionado anteriormente, para o Azure AD determinar o estado do dispositivo, ele precisa consultar um certificado, e algumas plataformas não permitem isso automaticamente. Mesmo que você esteja operando no modo somente relatório, ainda é necessário esse certificado para saber o que poderia ter feito. Você sempre será avisado sobre isso em políticas se incluir configurações baseadas no estado do dispositivo.

Quando você se sentir confortável de que sua política foi configurada corretamente e não afetará adversamente o negócio, basta alterar o estado para ativado, momento em que a política será imediatamente aplicada nas futuras tentativas de autenticação no Azure AD.

Experiência do usuário

Se um usuário tentar acessar qualquer recurso do Office 365 em um dispositivo não corporativo (conforme Intune ou unindo ao Azure AD híbrido), o Azure AD irá informá-lo que o acesso está bloqueado. Isso é válido para qualquer meio de acesso, seja utilizando um aplicativo web ou um aplicativo cliente completo. Novamente, você pode usar condições para ter regras diferentes tanto para aplicativos web quanto para aplicativos cliente.

Em dispositivos corporativos, o processo de autenticação não muda no que diz respeito ao usuário: eles vão entrar diretamente. A única exceção a isso é quando o aplicativo não consegue verificar o estado do dispositivo. Isso não deve ser um problema para aplicativos de primeira parte, como a suíte Office 365, mas, por exemplo, pode ser um problema com navegadores de terceiros, mesmo no Windows. Seus usuários podem receber um erro semelhante ao da captura de tela acima. O Chrome para Windows dá suporte ao estado do dispositivo ao usar a extensão Windows 10 Accounts e, como você pode imaginar, o Edge baseado em Chromium oferece suporte a ele como padrão.

Artigo Relacionado:

• Por Que Você Deve Restringir o Acesso ao Office 365 Usando Políticas de Acesso Condicional da Microsoft