Os eventos mundiais desde março de 2020 destacaram um dos principais benefícios do Office 365 e dos serviços baseados em nuvem em geral: eles estão disponíveis a qualquer momento, em qualquer lugar e em qualquer dispositivo. À medida que o mundo foi forçado a trabalhar em casa, aplicativos do Office 365 como Teams, Outlook, SharePoint e OneDrive puderam ser facilmente acessados fora da rede tradicional da empresa, e até mesmo em dispositivos não pertencentes à empresa. Na verdade, a maioria das assinaturas do Office 365 e do Microsoft 365 permite que os usuários instalem e usem seus aplicativos em até cinco dispositivos.

Uma de suas principais preocupações como resultado disso pode ser a prevenção de perda de dados. Por exemplo, por padrão, um usuário pode autenticar sua conta do 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 dos dados quando esse usuário deixa a organização?

O Azure Active Directory Conditional Access pode devolver o controle aos administradores. Parte da licença do Azure Active Directory Premium P1, com o Conditional Access você controla as condições nas quais um usuário tem ou não acesso aos recursos do Azure AD. Mesmo que você conceda acesso, é possível exigir medidas adicionais, como responder a uma solicitação de autenticação multifator (MFA) ou definir um tempo limite antes que o usuário precise 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. Isso é feito com base no estado do dispositivo.

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

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

Unir híbrido ao Azure AD refere-se a um estado em que um dispositivo está unido ao seu Active Directory local, mas também sincronizado e unido ao Azure AD baseado em 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 união híbrida ao Azure AD.

Marcado 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, esse é 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 do Group Policy ou Intune. Dispositivos em nenhum estado são considerados não gerenciados. Supondo que tenhamos limitado a capacidade de inscrição no Intune apenas a dispositivos corporativos, podemos usar razoavelmente os termos gerenciado e corporativo 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 é tipicamente em plataformas não baseadas na Microsoft, como as plataformas da Apple e do Google. Isso ocorre porque as informações do estado do dispositivo são mantidas em um certificado nesse dispositivo, e nem todo software torna isso disponível automaticamente ao Azure AD durante a autenticação.

Criando a política de Acesso Condicional

As políticas de Acesso Condicional são criadas dentro do Azure AD > Segurança > Acesso Condicional. A prática recomendada é dar à sua política um nome que facilite identificar exatamente o que a política visa alcançar. Isso porque, se várias políticas corresponderem a uma tentativa de autenticação, todas serão aplicadas, 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. As atribuições são o equivalente a uma lista de verificação de tudo que deve ser verdadeiro sobre o login para que a política seja aplicada ao login. Para a maioria dessas configurações, você pode incluir e excluir condições. Por exemplo, inclua todos os usuários, mas exclua equipe 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 verdadeiras.

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

Atribuições

Usuários e grupos controlam a quem a política será aplicada. 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 querer limitar a 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 útil criar uma política que limite todos os aplicativos que considere 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 Exchange Online e 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 suas partes componentes é devido à natureza integrada do serviço. A seleção da 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 (o que, falando de forma geral, significa acesso por aplicativo da web ou cliente). Em nosso exemplo, bloquearemos o acesso a todos 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. No entanto, um uso comum dessas condições é ter regras diferentes para acesso via web e acesso por aplicativo de desktop.

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

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 concessão e sessão.

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

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

As configurações de sessão controlam o que um usuário pode fazer uma vez que recebe acesso. Por exemplo, em sessões de navegador da web, você pode usar restrições aplicadas pelo aplicativo para bloquear downloads de serviços como Exchange Online e SharePoint Online. Com sorte, isso te faz pensar nas várias formas que você pode moldar suas políticas: potencialmente uma para bloquear acesso para aplicativos completos em dispositivos não gerenciados, mas outra que permite acesso apenas a aplicativos da web, impondo nenhum download.

Implantando a política de Acesso Condicional

Com todas as configurações aplicadas, sua política de Acesso Condicional agora pode ser colocada nos estados somente-relatório ou ligado. 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 essas 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 para o modo somente-relatório em nosso caso. Como mencionado anteriormente, para o Azure AD verificar o estado do dispositivo, ele precisa consultar um certificado, e alguns 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 ele poderia ter feito. Você sempre será avisado sobre isso em políticas se incluir configurações baseadas no estado do dispositivo.

Quando você estiver confortável de que sua política foi configurada corretamente e não afetará negativamente o negócio, basta alterar o estado para ligado, momento em que a política é 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 (compliance do Intune ou integrado ao Azure AD híbrido), o Azure AD informará que o acesso está bloqueado. Isso é válido para qualquer meio de acesso, seja através de um aplicativo web ou um aplicativo de cliente completo. Novamente, você pode usar condições para ter regras diferentes tanto para aplicativos web quanto para aplicativos de cliente.

Nos dispositivos corporativos, o processo de autenticação não muda do ponto de vista do usuário: eles continuarão navegando sem problemas. 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 o pacote Office 365, mas pode ser um problema, por exemplo, 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 suporta o estado do dispositivo se estiver usando a extensão de Contas do Windows 10 e, como você pode imaginar, o Edge baseado em Chromium suporta isso como padrão.

Artigo Relacionado:

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