É fácil perceber porque é que as empresas estão a gravitar em torno de um modelo de gestão de identidades híbrido que promete o melhor de dois mundos - um pouco na nuvem e um pouco no local. Num ambiente centrado no Active Directory, tirar partido da nuvem significa integrar-se no Azure Active Directory.
Afinal, o Azure Active Directory (AAD) foi concebido a pensar nas aplicações SaaS, fornecendo um início de sessão único e controlo de acesso. À medida que a adopção da nuvem aumenta, a capacidade de gerir o acesso no local e na nuvem está a tornar-se uma necessidade. Lever o AAD juntamente com o Active Directory (AD) ajuda a tornar a gestão de identidades híbridas uma realidade.
No entanto, como em tudo o que diz respeito às TI, continua a aplicar-se o ditado "olhar antes de saltar".
Leitura relacionada
Monumental mudança com a mudança para a nuvem
Mover qualquer parte de uma operação de TI para a nuvem requer um ajuste. A autenticação do utilizador não é diferente. De um ponto de vista conceptual, as organizações precisam de considerar três questões críticas.
1. Um novo modelo de autenticação
Depois de 20 anos a gerir a identidade de uma só forma, acrescentar o AAD à mistura será um ajuste ajustamento. Passar da utilização exclusiva do AD local para a extensão à autenticação na nuvem requer uma mentalidade e uma abordagem diferentes. No AAD, não existem unidades organizacionais ou florestas, nem objectos de política de grupo. Os conceitos (e cicatrizes de batalha) sobre como proteger as identidades no AD já não se aplicam no AAD.
Muitos administradores começam por pensar que a protecção do AAD é semelhante à protecção do AD, o que não é o caso. Ae você pode já estar a utilizar o AAD sem pensar muito nisso. Se a sua organização estiver a utilizar qualquer software Microsoft cserviços altos da Microsoft, como o Office 365, então o AAD já está a ser utilizado em segundo plano. O AAD também é muito utilizado para se conectar a outros aplicativos SaaS que não são da Microsoft, como o Salesforce. Todos estes factores introduzem novas considerações e escolhas. Por exemplo, deve manter o AD e o AAD separados ou fundi-los utilizando o Azure AD Connect? É necessário compreender muitos conceitos novos para que possa tomar estas decisões e manter os sistemas de informação seguros.
2. A extensão do perímetro
Quando uma organização adota a nuvem, a noção do perímetro de rede tradicional deixa de existir. Para os administradores de TI que passaram as últimas duas décadas executando o AD no local, essa noção é um tremendo ajuste. Em um ambiente de identidade híbrida, as organizações agora devem estar preparadas para se protegerem contra um conjunto infinito de possíveis pontos de entrada.
3. Mudanças radicais no modelo de permissão
A mudança para o AAD também altera drasticamente o modelo de permissões que as organizações precisam de proteger. No local, é bastante fácil controlar quem tem acesso físico aos controladores de domínio, e os pontos de entrada de gestão geral estão bem definidos e documentados. Num ambiente AD híbrido, as identidades também estão agora armazenadas na nuvem, vulneráveis à exploração por qualquer pessoa que tenha acesso à Internet. De repente, os administradores estão a lidar com um modelo inerentemente aberto para ligações de acesso inicial, que-quando associado ao maior número de serviços, funções e permissões necessárias-tem um impacto significativo no risco.
A Microsoft tem tentado activamente fornecer materiais educativos para preparar as empresas para as mudanças causadas pela adopção do AAD. No entanto, muitas organizações de TI ainda não estão a compreender totalmente as implicações da gestão de identidades híbridas. À medida que mais empresas adoptam uma abordagem híbrida, os atacantes expandiram o seu modus operandi em conformidade.
Em Setembro 2020os investigadores da Mandiant (FireEye) observaram um aumento de incidentes que envolviam o Microsoft 365 e o Azure Active Directory, na sua maioria associados a e-mails de phishing que tentavam levar as vítimas a introduzir as suas credenciais do Office 365 num site de phishing. Os investigadores da Mandiant também observaram atacantes a utilizar um módulo PowerShell chamado AADInternalsque permite aos atacantes passar do ambiente local para o AAD, criar backdoors, roubar palavras-passe e realizar outras acções maliciosas. Estas ameaças continuarão a aumentar com o crescimento exponencial do interesse no Azure e no Office 365.
Permissões, permissões, permissões
De longe, dos três assuntos mencionados acima, o maior risco de segurança é causado pelas mudanças no modelo de permissões. Há um grande número de serviços que estão disponíveis quando as organizações mudam para um ambiente de identidade híbrida. Em vez de um conjunto bem definido de grupos administrativos no Active Directory, tem agora funções no Azure AD, que não lhe serão familiares. Pode ver esta lista de funções aqui. Cada função tem uma longa lista de permissões atribuídas. É difícil entender as permissões atribuídas a cada função apenas a partir da descrição, mas muitas têm um alto nível de acesso que não é aparente.
Além disso, a ligação de qualquer serviço SaaS ao AAD, que é provavelmente a razão pela qual adicionou o AAD à mistura, acrescenta modelos de permissão que têm de ser geridos. O Microsoft Teams, por exemplo, utiliza a integração do SharePoint no back SharePoint. Com as configurações erradas, adicionar um convidado ao Teams podepode criar uma situação em que este novo utilizador passa a ter acesso a ficheiros armazenados no SharePoint para o Teams. Folks podem não ter conhecimento que estes ficheiros são agora disponíveis para utilizadores convidados que foram adicionados ao canal apenas para uma conversa rápida. Além disso, a capacidade de adicionar aplicações no Teams alarga efectivamente o modelo de permissão a estas ferramentas de terceiros. Este é apenas um exemplo da matriz de problemas complexos para cada serviço gerido através do AAD.
De facto, manter o controlo das permissões de aplicações de terceiros é fundamental e é uma área que é mal gerida na maioria das implementações do DAA. Estes pedidos de permissão accionam um pop-up único que lista as permissões de que a aplicação necessita. Estas listas podem ser longas e devem ser revistas cuidadosamente antes de serem aceites, mas raramente o são.
As organizações também mpode As organizações também se podem deparar com estes dois novos cenários relacionados com as permissões que têm de ser compreendidas num contexto de segurança:
- Ferramentas de terceiros que extraem dados do Azure AD e os armazenam na sua própria base de dados. Por exemplo, uma aplicação registada no Azure AD que permita a um sistema CRM ler perfis de utilizador ou tem outras permissões de leitura efectivamente tem a capacidade de recuperar e armazenar dados para si própria. Assim que os dados são retirados do Azure AD, ficam numa base de dados externa, deixando a organização depender da estrutura de segurança da ferramenta de terceiros.
- Ferramentas de terceiros com acesso de escrita que podem fazer alterações na sua ferramenta. Neste caso, a autenticação necessária para fazer alterações no inquilino é movida do Azure AD para quaisquer controlos que a ferramenta de terceiros tenha. Um utilizador mpode ser capaz de iniciar sessão na ferramenta sem autenticação multifactor porque não suporta o início de sessão único (SSO), funcionando em vez disso com a aplicação a actuar como o proxy de permissão que faz a acção em seu nome sem algumas das verificações que normalmente seriam necessárias.
As organizações de TI devem considerar fortemente a possibilidade de restringir quem pode aprovar aplicações ou, no mínimo, tere orientações claras sobre quais as permissões que devem ser consideradas adequadas. Adoptar uma abordagem de identidade híbrida requer lidar com um modelo de permissão muito mais amplo. Para o fazer de forma eficaz, as organizações têm de estabelecer uma forte governação das aplicações que vão ser activadas e dos direitos de acesso que lhes serão concedidos.
Compreender o risco da gestão de identidades híbridas
Quer a autenticação seja tratada na nuvem, no local ou em ambos, colocar a segurança em primeiro lugar é sempre uma obrigação. Embora a gestão da identidade num ambiente híbrido possa parecer tão simples como juntar um dispositivo Windows ao AAD, não ter em conta as alterações no cenário de risco abre a porta a problemas que podem causar dores de cabeça no futuro. O conhecimento é sempre a sua primeira linha de defesa, mas a quantidade de documentação necessária para compreender totalmente a segurança no AAD é assustadora. As ferramentas nativas ou de terceiros que automatizam essa compreensão e reduzem a complexidade da segurança ajudarão a reduzir o risco de segurança durante e após a implementação do seu ambiente híbrido.
