O futuro dos serviços de diretório é sem domínio

As abordagens fundamentais de segurança, gerenciamento de dispositivos e controle de acesso estão mudando.

Durante quase 30 anos, essas prioridades centrais de TI foram inseparáveis ​​do Active Directory e do OpenLDAP, que eram soluções excelentes na era do domínio local. Mas a recente mudança para o trabalho remoto deixa claro que a segurança de perímetro tradicional e a infraestrutura local não são mais suficientes para proteger as identidades dos usuários de uma organização e os dados confidenciais na nuvem.

Para gerenciar melhor os ambientes de trabalho modernos, precisamos reimaginar as funções individuais de um serviço de diretório e separar essas funções do conceito datado do domínio hardwired, castelo-e-fosso. O que mais importa hoje é proteger o usuário e o dispositivo, não importa onde eles estejam.

O futuro dos serviços de diretório, então, não tem domínio. Aqui está uma visão mais detalhada de como chegamos aqui, como é a empresa sem domínio na prática e as etapas que as organizações podem seguir para modernizar sua infraestrutura de IAM.

Reimaginando os serviços de diretório e o conceito de domínio

O conceito de domínio como o conhecemos foi essencialmente arquitetado na década de 1990 e foi uma excelente solução para a governança segura de usuários e computadores nos ambientes de escritório com fio da época. Embora a maioria das outras áreas de TI tenha se transformado completamente desde então, esse modelo ainda sustenta as abordagens da maioria das organizações para o gerenciamento de identidade e acesso hoje.

Muitos profissionais de TI consideram o domínio como garantido e supõem que o próximo passo lógico é adaptá-lo e estendê-lo para a era da nuvem, adicionando provedores de logon único (SSO) de aplicativos da Web e outras pontes de identidade. Mas uma abordagem mais prática pode ser olhar para os problemas centrais que o domínio foi inicialmente projetado para resolver, decidir quais desses problemas ainda são relevantes hoje e explorar novas maneiras de resolvê-los usando inovações modernas.

Em meados da década de 1990 até meados da década de 2000, as configurações de escritório eram muito diferentes. Os trabalhadores entravam em estabelecimentos físicos usando cartões-chave ou chaves reais. Eles caminharam até suas mesas e se sentaram na frente de computadores estacionários. Esses computadores foram conectados por meio de um cabo ethernet a algum data center interno ou armário de servidores dentro do escritório físico. De dentro desse local central, o controlador de domínio concedeu acesso aos recursos de TI na rede local. Essa rede física, por sua vez, era protegida de ataques externos por um firewall e pelo próprio prédio para acesso físico.

Na época, essa configuração era essencialmente segura e simples de gerenciar e oferecia uma experiência de usuário tão perfeita que os usuários não precisavam gerenciar várias senhas ou pensar nos processos de autorização e autenticação que aconteciam nos bastidores. Os ambientes eram homogêneos, com uma torre de desktop executando programas Windows e Microsoft em cada estação de trabalho. O Active Directory (AD) era tão adequado para esse tipo de ambiente que foi capaz de fornecer aos usuários o que talvez tenha sido a primeira experiência de logon único (SSO): um único conjunto de credenciais para acessar seus recursos de TI baseados em Windows por meio de um único login do sistema.

Agora, avance para o presente e derrube todas as paredes daquele prédio. A TI estava tendendo à flexibilidade fora do escritório, habilitada pela tecnologia de nuvem e internet sem fio de alta velocidade amplamente disponível. Em vez de computadores fixos com torres e monitores de tubo, os funcionários agora têm laptops e outros dispositivos que podem levar consigo para praticamente qualquer lugar, conectar-se à Internet e começar a trabalhar. Essa é a empresa sem domínio em poucas palavras, e essa é a nossa realidade atual.

Mas em um mundo em que tanto trabalho acontece fora do domínio, os departamentos de TI são forçados a reavaliar os desafios que o Active Directory lidava sozinho.

Deficiências modernas do modelo de domínio

O Active Directory tem se esforçado para se adaptar e integrar-se a recursos modernos de nuvem e sistemas operacionais não Windows, e o modelo de segurança de perímetro para o qual foi projetado não é suficiente para proteger os trabalhadores remotos.

Portanto, a questão é como traduzir o fluxo de trabalho administrativo centralizado e a experiência de usuário simples e segura, uma vez oferecida pelo AD, para um ambiente moderno que inclui sistemas Mac e Linux, aplicativos da Web, servidores em nuvem e redes remotas, e pode ou não ter -prem infraestrutura também. Os usuários precisam se conectar aos seus recursos de TI com o mínimo de atrito, independentemente de onde estejam trabalhando, e os administradores de TI precisam ter certeza de que as identidades dos usuários e os dados proprietários estão protegidos contra ataques.

O problema é que a TI não tem quase o nível de controle sobre as identidades de usuário modernas que teria em um ambiente de domínio AD convencional. Os aplicativos migraram de uma arquitetura legada de compra única e instalação local para um modelo de assinatura baseado em nuvem. Alguns aplicativos ainda são instalados localmente, com identidades e configurações manipuladas na nuvem por meio de um navegador da web.

Deixados para gerenciar suas próprias identidades, os usuários acabam com dezenas – se não centenas – de senhas e enfrentam a tentação de ignorar as diretrizes de segurança e compartilhar ou reutilizar senhas fracas.

Os usuários também podem ser tentados a criar suas próprias contas para novos aplicativos como acharem melhor, sem a aprovação ou regulamentação de TI. Essa sombra de TI representa um risco de segurança desnecessário para a organização. E mesmo as identidades gerenciadas pela TI podem existir em seus próprios silos, com cada identidade separada exigindo seu próprio processo manual de provisionamento e desprovisionamento.

Não existe uma identidade única e central análoga à identidade AD do passado. Os administradores precisam de uma nova maneira de proteger as conexões, manter tudo seguro sob a alçada da TI, atender às linhas de base de segurança e conformidade e preparar os dispositivos para o trabalho remoto.

Quando se trata de sistemas, os sistemas MacBooks e Linux agora são comuns. Onde os administradores experientes da Microsoft já resistiram à introdução de sistemas Mac no local de trabalho, agora é uma prática padrão acomodar esses sistemas. Em um domínio tradicional do Active Directory, o gerenciamento de sistemas Mac e Linux não seria tão fácil ou seguro sem a adição de outras soluções pontuais além do AD, como uma ferramenta de gerenciamento de sistema ou até mesmo um MDM.

Os ambientes de domínio construídos em torno do OpenLDAP não estão muito melhores: domínios e servidores LDAP gerenciam principalmente identidades, senhas, grupos e unidades organizacionais, mas geralmente não possuem gerenciamento de sistema, aplicação de políticas de segurança e recursos de integração de aplicativos em nuvem. Os recursos de TI deixaram de usar apenas o LDAP como o protocolo de autenticação preferido para aproveitar os padrões modernos, como SAML, SCIM, OAuth, OIDC e muito mais. Os ambientes LDAP legados também exigem um alto grau de experiência para configurar e manter.

A maneira lógica de preencher as lacunas acima na supervisão de TI é implementar uma arquitetura moderna sem domínio.

O que realmente significa sem domínio na prática?

A perspectiva de ficar sem domínio pode parecer um pouco assustadora para administradores experientes, mas um ambiente sem domínio configurado corretamente pode ser consideravelmente mais seguro do que uma configuração de domínio tradicional no cenário de TI atual. Em um ambiente sem domínio, a postura de segurança da organização envolve cada usuário individual, seu sistema Mac, Windows ou Linux e os recursos que eles precisam acessar, onde quer que cada um desses componentes esteja localizado.

Cada recurso de TI agora tem seu próprio perímetro restrito. Isso significa que, em vez de funcionar essencialmente desprotegido dentro dos limites de um perímetro maior protegido após a autenticação uma vez, as identidades e os direitos de acesso são constantemente verificados e verificados. Os usuários acessam seus recursos diretamente por meio de uma conexão padrão com a Internet, em vez de rotear por meio de um domínio para autenticação. E no lugar de um controlador de domínio, um serviço de diretório em nuvem lida com gerenciamento de acesso, autenticação de usuário e aplicação de segurança.

É esse conceito de serviço de diretório em nuvem que torna a empresa sem domínio alcançável na prática. Mas mesmo que tantos outros aspectos de TI tenham migrado efetivamente para a nuvem, muitos administradores têm reservas quanto à implementação de um espectro completo de serviços de diretório na nuvem.

Na maioria das vezes, isso ocorre porque a ideia de um serviço de diretório em si está tão inextricavelmente ligada ao Active Directory – a ferramenta existente representa os problemas individuais que uma vez resolveu. E o aspecto de segurança do domínio é mais intuitivo: firewalls e fechaduras são familiares e nos dão uma sensação de controle. Parece lógico que desistir do domínio significaria maior exposição a ataques e menor controle sobre a segurança.

Mas a verdade é que mesmo com medidas como firewalls, detecção de rede e detecção e resposta de endpoint em vigor, as organizações ainda são violadas. Depois que cada novo ataque bem-sucedido chega ao ciclo de notícias, a comunidade de TI se concentra em como aplicar uma versão melhor e mais forte da mesma abordagem de segurança. Claramente, a velha maneira de fazer as coisas não está funcionando. Chegou a hora de uma abordagem centrada na nuvem fundamentalmente nova.

Funções principais de um serviço de diretório em nuvem

A expressão serviço de diretório em nuvem é usada para descrever uma variedade de soluções que se encaixam vagamente na categoria de IAM, mas é difícil definir o que essa frase realmente significa de fornecedor para fornecedor.

Diferentes soluções de diretório em nuvem raramente oferecem funcionalidade comparável e quase nenhuma delas replica toda a gama de recursos originais de controle de acesso, autenticação e governança do sistema do AD como o principal provedor de identidade de uma organização. Mas é exatamente isso que um serviço de diretório em nuvem precisa fazer para dar suporte e proteger uma arquitetura moderna sem domínio.

Na verdade, um serviço de diretório de nuvem que vale a pena deve ir além do escopo original do AD, gerenciando o acesso a aplicativos de terceiros e sistemas operacionais não Windows em uma única plataforma.

Essa distinção é importante na comparação de um verdadeiro serviço de diretório em nuvem com uma plataforma de SSO de aplicativo da Web, que fornece aos usuários uma identidade para acessar seus aplicativos SaaS, mas pode não ser capaz de gerenciar o acesso ao dispositivo, linhas de base de segurança ou autenticar usuários em legados ou locais recursos usando seus protocolos de autenticação preferidos. Nesse sentido, o SSO baseado em SAML é apenas um componente de um serviço de diretório em nuvem; os termos não são intercambiáveis.

Em vez de criar uma tradução de um para um do modelo de domínio AD estabelecido na nuvem, um serviço de diretório de nuvem adequado divide as funções do AD em suas partes componentes e reimagina cada uma dessas partes. Se pudermos separar os problemas individuais da solução que damos como certa, podemos chegar a novas maneiras de resolvê-los.

Os seguintes recursos principais são essenciais para um serviço de diretório em nuvem criado para a empresa sem domínio:

• Uma identidade de usuário única e segura para acessar dispositivos, aplicativos, WiFi/VPNs, servidores e infraestrutura de desenvolvimento, tanto no local quanto na nuvem e independentemente do fornecedor
• Capacidade de integrar e consolidar identidades de usuários de outros serviços, incluindo G Suite, Office 365, AWS, AD/Azure e sistemas de RH/folha de pagamento
• Recurso automatizado de provisionamento e desprovisionamento de usuários
• Gerenciamento remoto do sistema com controle de política semelhante a GPO sobre sistemas Mac, Windows e Linux e relatórios detalhados sobre o status e os atributos do sistema
• Autenticação multifator (MFA) no login do sistema Mac, Windows e Linux e para acesso a praticamente todos os outros recursos de TI, além do recurso de gerenciamento de chaves SSH
• Administração flexível e automatizada por meio de scripts, API ou PowerShell
• Dados detalhados e registro de eventos para atender às necessidades de auditoria e conformidade

Muitas falhas de segurança são atribuídas não à ausência total de qualquer um dos componentes acima, mas à incapacidade de aplicá-los, impô-los e atualizá-los uniformemente em toda a organização. Com isso em mente, o valor de um serviço de diretório em nuvem centralizado fica claro.

As chaves para ficar sem domínio: confiança do dispositivo e MFA

Embora muitas soluções de IAM em nuvem sejam totalmente baseadas em navegador, elas estão perdendo a chave para a segurança moderna sem domínio: o dispositivo. Os usuários ainda precisam de um gateway físico para seu trabalho, seja esse gateway um laptop, tablet ou smartphone. Grande parte da verificação constante necessária para proteger um ambiente sem domínio deve ser tratada pelo dispositivo, usando uma estrutura que podemos considerar como confiança do dispositivo .

A ideia é que o usuário faça login no dispositivo uma vez, usando uma combinação de senha ou credenciais sem senha mais MFA e, em seguida, obtenha acesso seguro a todos os seus recursos de TI. Cada transação é protegida e criptografada em nível atômico, para que o trabalho possa ser realizado com segurança por meio de uma conexão padrão com a Internet.

A experiência do usuário é semelhante à experiência do SSO de fazer login em uma máquina desktop no domínio AD do final da década de 1990/início de meados da década de 2000, mas o que está acontecendo nos bastidores é muito mais complexo e a amplitude dos recursos de TI disponíveis para acesso é bem maior.

Para que um serviço de diretório em nuvem estabeleça um relacionamento confiável com um dispositivo, vários critérios devem ser atendidos e reafirmados constantemente. Esses critérios simplificam a verificação de que:

• O usuário certo está acessando o dispositivo e esse usuário é quem eles dizem ser
• O dispositivo certo está solicitando acesso
• O acesso está sendo solicitado no local certo
• As permissões certas estão sendo aplicadas para o usuário/dispositivo em um determinado recurso

É aqui que o conceito de MFA se expande para além das medidas voltadas para o usuário, como tokens TOTP e chaves de segurança WebAuthn. Os requisitos acima podem ser confirmados entre o dispositivo e o serviço de diretório em nuvem, estabelecendo terceiro, quarto, quinto e mais fatores de autenticação que seriam praticamente impossíveis para um invasor replicar juntos.

A ideia de violar uma rede é radicalmente alterada por essa autenticação multifator repetida: não há mais uma área insegura para atravessar durante uma sessão aberta após apenas uma autenticação inicial. Isso porque no modelo sem domínio, a segurança e o controle de acesso acontecem efetivamente em cada nível, e não apenas no nível da rede. Somente a pessoa certa, com a máquina certa, acessando do local certo com as permissões apropriadas, pode acessar dados e aplicativos.

Um serviço de diretório em nuvem estabelece a confiança do dispositivo por meio de uma combinação de governança de sistema semelhante a GPO, software criado com base no princípio de privilégio mínimo e criptografia de todos os dados em trânsito e em repouso. Outra maneira de pensar sobre essa abordagem é dentro do contexto da segurança de confiança zero .

Segurança de confiança zero na prática

A segurança de confiança zero significa que o serviço de diretório responsável pela autenticação nunca considera garantida a legitimidade de um usuário, dispositivo, aplicativo ou outro recurso de TI. Isso é alcançado protegendo as quatro áreas a seguir: funcionários, sistemas, aplicativos e rede.

Funcionários

Um sistema está em vigor para verificar se eles são realmente quem eles dizem ser, confirmando sua senha (algo que eles sabem) e seu token MFA (algo que eles têm) no banco de dados do diretório, que serve como uma fonte autorizada de verdade.

Sistemas

O sistema, provavelmente uma máquina corporativa, que uma pessoa validada está usando para acessar os recursos de TI deve estar limpo e a pessoa deve ter acesso a essa máquina por direito. Na prática, isso significa algum tipo de mecanismo para garantir que a máquina seja conhecida, políticas e configurações impõem padrões de segurança e um alto grau de certeza de que o usuário é quem diz ser. O software de segurança é verificado e atualizado. A telemetria do sistema ajuda a garantir a visibilidade de que a própria máquina não é comprometida.

Formulários

É fundamental que apenas as pessoas certas, em sistemas confiáveis, estejam acessando os aplicativos. A extensão lógica do acima, então, é verificar se o usuário e a máquina têm direitos ao aplicativo e à rede em que o aplicativo está e verificar a segurança dessa rede. É aqui que uma VPN às vezes ainda pode desempenhar um papel crucial na empresa sem domínio, como um túnel seguro para um aplicativo ou recurso.

Rede

Qualquer que seja a rede em que o usuário esteja, deve ser a mais segura possível, mas mesmo que não seja completamente segura, o usuário pode criar um enclave seguro dentro dessa rede usando uma VPN. Além disso, as redes podem ser protegidas por meios adicionais, como MFA e até mesmo segmentação de VLAN.

Primeiros passos para implementar uma arquitetura sem domínio

Essa ideia de uma arquitetura sem domínio habilitada por um serviço de diretório em nuvem e segurança de confiança zero não é puramente filosófica ou uma aspiração distante para o futuro: está aqui agora, e as equipes de TI podem começar a implementá-la imediatamente, completamente ou numa abordagem gradual e gradual adequada à sua infra-estrutura existente.

Para organizações que investem profundamente em um domínio AD funcional, um serviço de diretório em nuvem pode envolver a instância AD, fornecendo muitos dos benefícios do modelo sem domínio e servindo como um trampolim para o modelo totalmente em nuvem.

Um serviço de diretório de nuvem forte terá a capacidade de se manter por conta própria como um provedor de identidade principal, portanto, mesmo as organizações que não estão prontas para se tornar 100% sem domínio agora têm a opção de sair do AD quando essa migração fizer sentido.

Se você quiser saber mais, explore informações sobre serviços de diretório em nuvem no G2.