No Reino Unido, 98% das organizações afirmam que planeiam ou já implementaram o zero trust, mas apenas 15% relatam uma implementação completa. A lacuna não é a consciencialização. É a execução. A investigação sobre zero trust no Reino Unido mostra que muitas equipas iniciaram o planeamento, a segmentação ou projetos de identidade isolados sem ligar esses controlos a um único modelo operacional.
A questão prática não é se o zero trust é importante. É como implementar o zero trust sem interromper serviços em produção, frustrar utilizadores ou criar mais uma coleção de produtos de segurança desconectados. A resposta consiste em sequenciar a migração em torno da identidade, postura do dispositivo, ciclo de vida do diretório, WiFi seguro, segmentação e verificação contínua.
Por que Razão a Implementação de Zero Trust Estagna nas Empresas
51% das organizações permanecem numa fase inicial de planeamento, enquanto apenas 15% afirmam ter uma implementação total, e 80% enfrentaram barreiras técnicas ou operacionais. O relatório de organizações do Reino Unido mostra a lacuna entre selecionar uma direção e operar os controlos necessários. As equipas começam frequentemente com projetos isolados e depois descobrem que a identidade, dispositivos, diretórios, aplicações e redes dependem uns dos outros.
O zero trust remove a confiança inerente de sistemas, redes e serviços. Uma ligação interna não deve fornecer um acesso amplo. Uma conta antiga não deve manter permissões após a pessoa ou fornecedor já não necessitar delas. Um serviço não deve permanecer fidedigno indefinidamente por ter passado num único controlo de autenticação.
O UK National Cyber Security Centre enquadra o zero trust como uma migração faseada, e não como a compra de um produto. As suas diretrizes de arquitetura definem oito princípios de design, incluindo decisões de acesso baseadas na identidade e comunicações protegidas. A coleção zero-trust do NCSC foi publicada em 2021, com as diretrizes de implementação expandidas em setembro desse ano. Os princípios de design de arquitetura do NCSC são úteis porque exigem que as equipas definam as decisões de arquitetura e confiança antes de escolherem a tecnologia.
O modo de falha focado apenas no produto
O padrão de falha começa geralmente com a compra de uma plataforma. Uma equipa implementa um produto de identidade, uma ferramenta de segmentação ou um gateway ZTNA, e depois descobre que as contas de serviço, os dispositivos não geridos, as aplicações legadas, a autenticação sem fios e o desaprovisionamento de diretórios nunca foram mapeados.
O resultado é uma lista de exceções crescente. Os utilizadores recebem soluções temporárias, os administradores preservam credenciais partilhadas e as equipas de segurança não conseguem saber se a política está a ser aplicada de forma consistente. O WiFi expõe esta fraqueza rapidamente. A segmentação de rede pode separar o tráfego, mas não cria um acesso baseado em identidade se os utilizadores continuarem a aceder através de palavras-passe partilhadas ou se os dispositivos permanecerem desconhecidos. O WiFi sem palavra-passe com autenticação baseada em certificados, associada a registos de dispositivos e ao estado do diretório, fornece à política um sinal de identidade fiável. A revogação automática do diretório deve então remover o acesso quando uma conta é desativada, em vez de esperar por uma limpeza manual.
Os controlos de perímetro tradicionais ainda desempenham um papel, mas não conseguem responder a todas as questões de acesso. O artigo why traditional IT security fails explica como os serviços de nuvem, o acesso remoto e os dispositivos distribuídos enfraquecem o pressuposto de que uma rede interna é automaticamente segura.
Regra prática: Não escreva políticas de aplicação até saber quais as dependências de identidade, dispositivo, WiFi e serviços que a política poderá interromper.
Uma migração viável segue esta ordem:
- Descubra o parque tecnológico: Identifique utilizadores, dispositivos, aplicações, serviços e fluxos de dados.
- Defina limites: Decida quais os recursos que requerem isolamento e quais os caminhos de acesso legítimos.
- Construa o plano de controlo: Ligue identidade, MFA, acesso a dispositivos baseado em certificados, verificações de postura e o ciclo de vida do diretório.
- Aplique na periferia: Aplique a política a aplicações, redes e WiFi, e não apenas a sessões VPN.
- Observe e expanda: Comece com cargas de trabalho controladas, reveja as decisões de acesso e estenda o modelo gradualmente.
Esta sequência faz do zero trust um modelo operacional e não uma coleção de ferramentas. Também permite que as equipas de operações protejam a disponibilidade enquanto os controlos de identidade, o WiFi seguro e a segmentação amadurecem.
Preparar o Terreno com a Descoberta e Limites de Confiança
Comece com um inventário que reflita como a organização funciona, e não como o diagrama de rede diz que funciona. O NCSC recomenda a identificação de utilizadores, permissões necessárias, dispositivos e serviços, e depois desenhar a gestão de identidades e acessos com base nessas descobertas. O guia de migração do NCSC também orienta as equipas para o mapeamento de dependências legadas e a modelação de ameaças da arquitetura proposta antes da implementação.
O resultado deve ser um catálogo funcional, e não uma folha de cálculo estática. Registe o proprietário, o objetivo de negócio, o método de autenticação, as dependências, a sensibilidade dos dados, os utilizadores previstos e o impacto de falha para cada recurso importante.
Criar quatro inventários
Os utilizadores e as identidades vêm primeiro. Inclua colaboradores, prestadores de serviços, administradores privilegiados, contas de serviço e identidades de automatização. Separe o estatuto profissional de uma pessoa da sua necessidade de acesso. Um prestador de serviços pode necessitar de acesso a uma aplicação por um período definido, enquanto uma conta de serviço pode exigir autenticação de máquina, mas sem início de sessão interativo.
Os Dispositivos necessitam da sua própria classificação. Registe portáteis geridos, dispositivos móveis, terminais partilhados, impressoras, câmaras, sistemas de edifícios e outros equipamentos IoT. Registe quais os dispositivos que suportam certificados, encriptação moderna e relatórios de postura. O equipamento legado muitas vezes não consegue cumprir os requisitos de autenticação dos funcionários, pelo que necessita de uma estratégia de contenção explícita em vez de uma exceção não monitorizada.
As aplicações e os serviços devem ser mapeados de acordo com os seus requisitos de identidade e transporte. Documente se cada aplicação suporta SSO, MFA, protocolos modernos, certificados, acesso por proxy ou apenas um nome de utilizador e palavra-passe legados. Identifique diretórios a montante, bases de dados, serviços de DNS, APIs e dependências de registo de eventos.
Os fluxos de dados e as jornadas de negócio revelam limites de confiança. Mapeie a forma como um membro da equipa acede a um sistema clínico, como um prestador de serviços acede a um portal de manutenção, ou como um dispositivo de ponto de venda comunica com serviços autorizados. Um segmento não é útil se uma dependência não documentada forçar o acesso sem restrições através dele.
Definir limites antes das políticas
Um limite de confiança deve responder a três perguntas: o que está a ser protegido, quem precisa de acesso e sob que condições. As condições podem incluir a garantia de identidade, a integridade do dispositivo, o contexto de rede, a sensibilidade da aplicação e a aprovação limitada no tempo.
O WiFi para convidados, IoT e locais multi-inquilino merecem atenção especial. Os convidados nunca devem depender das credenciais de rede dos funcionários. Os dispositivos IoT devem comunicar apenas com os serviços necessários para a sua função. Os inquilinos podem partilhar a infraestrutura física enquanto mantêm o isolamento lógico e a administração de identidade separada.
O transporte seguro é importante em todas as fronteiras. Se a equipa precisar de uma reciclagem em linguagem simples sobre certificados, encriptação e confiança do navegador, o guia sobre SSL da Adwave Digital é uma referência útil antes de documentar os pressupostos de transporte de aplicações e WiFi.
Termine a fase de descoberta com um modelo de ameaças. Teste o que acontece se uma conta de diretório for comprometida, se um dispositivo gerido se tornar vulnerável, se um certificado for revogado, se um controlador sem fios estiver indisponível ou se um serviço legado não se conseguir autenticar junto do novo fornecedor de identidade. Esses caminhos de falha devem moldar a ordem de implementação.
Construir a Identidade e a Postura do Dispositivo como o Seu Painel de Controlo
As decisões de zero trust precisam de uma fonte de verdade. Na maioria das infraestruturas, isso significa selecionar o diretório que governa pessoas, grupos e eventos de ciclo de vida, como o Microsoft Entra ID, Google Workspace ou Okta. A escolha de design mais importante não é apenas a marca. É saber se todos os sistemas de acesso conseguem consumir o mesmo estado de identidade e reagir quando esse estado se altera.
Um utilizador que saia da organização deve perder o acesso em todos os locais importantes. Um prestador de serviços cujo contrato termine não deve permanecer ativo num sistema sem fios porque um administrador se esqueceu de remover uma conta separada. O aprovisionamento e a revogação automáticos tornam as alterações de diretório em controlos operacionais e não em lembretes administrativos.
Autenticar a pessoa e o dispositivo
Comece com SSO e MFA para aplicações de equipas de trabalho. O MFA aumenta a garantia, enquanto o SSO reduz o número de credenciais que os utilizadores e os canais de suporte têm de gerir. O NCSC recomenda especificamente desenhar o IAM em torno de MFA e considerar autenticação sem palavra-passe onde for adequado. Os métodos sem palavra-passe podem melhorar tanto a segurança como a usabilidade, mas necessitam de procedimentos de recuperação, controlos de registo de dispositivos e suporte para utilizadores que percam o acesso ao seu autenticador principal.
Para o WiFi dos funcionários, a autenticação baseada em certificados é normalmente mais forte operacionalmente do que as palavras-passe partilhadas. Com WPA2 ou WPA3-Enterprise e 802.1X, a rede pode vincular o acesso a uma identidade registada ou a um certificado de dispositivo. Isso elimina a necessidade de distribuir uma chave comum e torna a revogação precisa.
A postura do dispositivo adiciona a segunda metade da decisão. Verifique se o dispositivo é gerido, encriptado, atualizado, conforme e se utiliza um certificado aprovado. Um utilizador válido num portátil não gerido não deve receber automaticamente o mesmo acesso que esse utilizador num dispositivo empresarial em conformidade.
A identidade prova quem está a solicitar acesso. A postura do dispositivo determina se esse pedido de acesso é suficientemente seguro para ser aprovado.
Desenhar eventos de ciclo de vida, não apenas o início de sessão
A integração deve criar a identidade no diretório, atribuir os grupos corretos, registar o dispositivo e emitir o certificado necessário através de um fluxo de trabalho automatizado. A desativação deve desativar a identidade, revogar sessões e certificados, e remover o acesso à rede sem esperar por um administrador de WiFi separado.
Os prestadores de serviços precisam de um caminho diferente. Atribua-lhes uma associação a grupos com âmbito estrito, um processo de expiração ou aprovação e acesso apenas às aplicações e segmentos de rede que o seu trabalho exige. Não resolva a conveniência dos prestadores de serviços colocando-os numa rede geral de colaboradores.
Os dispositivos legados necessitam de contenção. Quando uma impressora, sensor ou terminal especializado não puder utilizar autenticação baseada em certificados, utilize um segmento dedicado, regras de firewall de âmbito estrito e um mecanismo de identidade controlado, como uma chave pré-partilhada individual. Isso mantém a exceção visível e limita o seu raio de impacto.
As equipas que avaliam o acesso à rede vinculado à identidade podem analisar o identity-based networking como um padrão de implementação. O princípio de arquitetura permanece o mesmo, independentemente da plataforma: o estado do diretório, a força da autenticação e o estado do dispositivo devem influenciar a decisão de acesso em conjunto.
Segmentação e WiFi Seguro Que Aplica Políticas
A segmentação é necessária, mas não consegue impor o acesso baseado em identidade por si só. 92% das organizações do Reino Unido inquiridas afirmam segmentar as suas redes até certo ponto, enquanto 98% afirmam que planeiam ou já implementaram o zero trust. A investigação no Reino Unido indica que o zoneamento de rede é generalizado, mas a garantia de identidade, a verificação contínua e a aplicação de políticas ainda necessitam de atenção.
Uma VLAN separa o tráfego. Não decide se uma pessoa, dispositivo ou sessão deve manter o acesso. Se um utilizador passar de um portátil em conformidade para um dispositivo não gerido, o dispositivo pode permanecer no mesmo segmento, a menos que o sistema de acesso avalie novamente a identidade e a postura.
Comparar os níveis de maturidade
| Área de Controlo | Implementação Parcial | Maturidade Zero Trust |
|---|---|---|
| Design de rede | VLANs ou zonas amplas separam convidados, funcionários e dispositivos | Políticas granulares restringem o acesso a recursos e fluxos específicos |
| Autenticação WiFi | Palavras-passe partilhadas, portais cativos ou chaves estáticas | WPA2 ou WPA3-Enterprise, 802.1X e acesso baseado em certificado ou identidade |
| Ciclo de vida do utilizador | Os administradores criam e removem contas manualmente | As alterações no diretório aprovisionam e revogam o acesso automaticamente |
| Garantia do dispositivo | Um dispositivo liga-se se tiver a credencial de rede correta | O estado de funcionamento do dispositivo e o estado do certificado influenciam cada decisão de acesso |
| Resposta a políticas | O acesso permanece ativo até que uma sessão ou conta seja alterada manualmente | As alterações de contexto desencadeiam a reavaliação, restrição ou revogação |
| Visibilidade | Os registos do controlador mostram eventos de ligação | Os eventos de identidade, dispositivo, política e recurso são correlacionados para análise |
Tratar o WiFi como um limite de identidade
O WiFi é frequentemente a primeira decisão de acesso empresarial com que um dispositivo se depara. Deixá-lo para o final do programa cria uma lacuna entre a política de diretório e a conectividade física.
Para os funcionários, utilize WPA2 ou WPA3-Enterprise com 802.1X, suportado por certificados ou outro método de identidade forte. O WiFi sem palavra-passe remove os segredos partilhados da experiência do utilizador, enquanto a autenticação baseada em certificados vincula a conectividade a uma identidade e dispositivo registados. O Passpoint e o OpenRoaming podem suportar o roaming seguro ao permitir que um dispositivo registado se autentique sem introduzir repetidamente uma palavra-passe.
O objetivo é uma conectividade encriptada e vinculada à identidade desde o primeiro pacote. Um Captive Portal que concede acesso amplo após o utilizador aceitar os termos não fornece esse controlo.
Para uma revisão prática da segurança de WiFi empresarial, avalie a distribuição de certificados, a integração com fornecedores de identidade, a gestão de revogações e a compatibilidade de controladores. O design deve funcionar em toda a infraestrutura, incluindo equipamentos Meraki, Aruba, Ruckus, Mist ou UniFi.
Os convidados necessitam de uma experiência e política separadas. Forneça acesso à internet sem privilégios de funcionários. Os dispositivos IoT necessitam de políticas restritas que permitam apenas os destinos e serviços necessários para o funcionamento.
Reavaliar o acesso continuamente
O NCSC destaca a reavaliação contínua, a observabilidade e a resiliência como requisitos explícitos de zero trust. As suas diretrizes de implementação de ZTNA apoiam a alteração do acesso quando o contexto muda, em vez de deixar as permissões fixas durante a duração de uma sessão.
A integração com o diretório deve suportar a revogação automática. Uma conta desativada, a remoção da associação a um grupo ou um certificado revogado devem acionar atualizações de políticas sem necessidade de intervenção de um administrador de WiFi dedicado. O resultado pode ser uma autenticação reforçada, a migração para uma rede restrita, o bloqueio de aplicações ou a revogação imediata do acesso.
A segmentação contém o incidente. A identidade, a postura do dispositivo e a telemetria atual determinam se o acesso continua. Essa combinação fecha a lacuna entre a separação de rede e o verdadeiro controlo baseado em identidade.
Implementar a Monitorização e Verificar Cada Decisão de Acesso
Uma implementação segura é controlada, observável e reversível. Não comece por impor uma nova política a todos os utilizadores, locais e categorias de dispositivos. Selecione um grupo ou local de baixo risco que ainda contenha complexidade real suficiente para expor problemas e, em seguida, comprove o caminho de acesso antes de o expandir.
Comece em modo de monitorização sempre que a tecnologia o permita. Registe o que a política permitiria e negaria, compare essas decisões com os requisitos de negócio e investigue dependências desconhecidas. O modo de monitorização não substitui a aplicação de regras. É uma forma de eliminar surpresas evitáveis antes que a aplicação de regras afete a produção.
Utilizar uma migração faseada
Uma sequência prática assemelha-se a isto:
- Escolha um piloto delimitado: Selecione uma aplicação, local ou grupo de utilizadores de baixo risco com um proprietário conhecido e uma rota de suporte clara.
- Registe a linha de base: Registe a autenticação bem-sucedida e falhada, a postura do dispositivo, o estado do certificado, a colocação na rede, o resultado da política e o resultado da aplicação.
- Teste os caminhos de negação: Confirme que MFA falhado, certificados revogados, identidades de diretório desativadas e dispositivos não conformes são bloqueados.
- Aplique de forma restrita: Aplique a política ao piloto, com uma condição de reversão documentada e um administrador que possa reverter a alteração.
- Expanda por dependência: Adicione grupos, locais ou serviços apenas após a fase anterior apresentar registos estáveis e um processo de suporte acordado.
O projeto-piloto deve incluir testes de falha. Desative uma identidade de teste, remova a sua pertença a um grupo, marque um dispositivo como não conforme e revogue o seu certificado. Confirme se o acesso à rede, o acesso às aplicações e as sessões ativas respondem conforme planeado.
Tornar a telemetria útil
Recolha eventos que expliquem decisões, e não apenas eventos que provem que uma ligação ocorreu. No mínimo, correlacione a identidade requerente, o identificador do dispositivo, o resultado da autenticação, o estado do certificado, o resultado da postura, o segmento de rede, o recurso de destino, a versão da política e a decisão final.
Procure padrões que necessitem de revisão humana:
- Utilização inesperada de identidade: Um utilizador acede a um recurso fora do seu cargo normal ou grupo aprovado.
- Alterações de postura: Um dispositivo anteriormente em conformidade perde o estado de gestão, encriptação ou certificado.
- Falhas repetidas: Ocorrem falhas de autenticação ou de postura em múltiplas contas ou localizações.
- Exceções de política: Um dispositivo ou serviço legado depende repetidamente de uma regra abrangente.
- Atrasos na revogação: Uma identidade de diretório desativada continua a receber acesso à rede ou a aplicações.
Utilize a Purple's data and security overview ao avaliar como uma plataforma de WiFi baseada em identidade lida com dados de acesso, controlos de segurança e visibilidade operacional. Independentemente das ferramentas que selecionar, os painéis de controlo devem apoiar as decisões. Um registo que ninguém analisa não irá melhorar a imposição de segurança.
Condição de reversão: Reverta uma política quando esta bloquear um percurso de negócio crítico, criar uma dependência insegura ou produzir falhas de acesso inexplicáveis. Preserve as provas, corrija o design e teste novamente. Não deixe uma exceção de emergência permanentemente aberta.
Proteger a disponibilidade como parte da segurança
O zero trust depende de diretórios, serviços de certificados, motores de políticas, controladores de rede e conectividade. Crie resiliência em cada dependência. Defina o que acontece se o fornecedor de identidade estiver inacessível, se os certificados não puderem ser validados, se um controlador falhar ou se um serviço de políticas ficar indisponível.
Utilize o design de serviço à prova de falhas com cuidado. Alguns ambientes precisam que as sessões existentes continuem brevemente durante uma interrupção do serviço de identidade. Outros devem restringir o acesso imediatamente para recursos confidenciais. A escolha certa depende do recurso, do modelo de ameaça e da consequência operacional.
Comunique antes da imposição das regras. Explique aos utilizadores o que vai mudar, quais os métodos de início de sessão que irão utilizar, como funciona o registo de dispositivos e onde reportar falhas. Monitorize as tendências do suporte técnico e a análise de acessos após cada fase. A redução da administração manual de contas, menos credenciais partilhadas e uma revogação mais rápida são indicadores práticos de que o modelo operacional está a melhorar.
A Sua Lista de Verificação de Implementação de Zero Trust e Próximos Passos
Um plano de implementação viável deve fazer parte da agenda da próxima reunião de arquitetura:
- Descobrir: Inventariar pessoas, contas de serviço, dispositivos, aplicações e serviços.
- Mapear dependências: Documentar fluxos de dados, métodos de autenticação, restrições legadas e proprietários operacionais.
- Definir limites: Separar o acesso de funcionários, convidados, IoT e inquilinos de acordo com as necessidades de recursos.
- Reforçar a identidade: Selecionar uma fonte de verdade de diretório, impor MFA e introduzir SSO.
- Adotar autenticação mais forte: Mover utilizadores e dispositivos elegíveis para acesso sem palavra-passe e baseado em certificados.
- Automatizar o ciclo de vida: Aprovisionar a partir de grupos de diretório e revogar o acesso quando as identidades ou certificados mudarem.
- Avaliar a postura: Verificar a gestão, o estado de funcionamento e a conformidade antes de conceder acessos confidenciais.
- Proteger o WiFi: Utilizar autenticação empresarial vinculada à identidade em vez de palavras-passe partilhadas de funcionários.
- Conter dispositivos legados: Colocar as exceções em segmentos restritos com políticas de âmbito estrito.
- Monitorizar primeiro: Executar políticas piloto em modo de observação e, em seguida, aplicá-las com critérios de reversão.
- Verificar continuamente: Testar acessos negados, revogações, alterações de postura e falhas de serviço.
- Expandir deliberadamente: Adicionar sites e cargas de trabalho apenas quando os registos, a propriedade e os processos de suporte estiverem prontos.
A decisão de implementação mais importante é a sequenciação. Não comece pelo produto mais visível ou pelo maior segmento de rede. Comece com uma jornada que consiga compreender, medir e reverter. Para o setor da hotelaria e retalho, isso pode significar a separação de funcionários, convidados e dispositivos operacionais num espaço físico ativo. Para o setor da saúde, pode significar a priorização dos controlos de identidade e de dispositivos em torno de uma aplicação sensível. Para habitação multi-inquilino, pode significar fornecer acesso simples aos residentes, preservando ao mesmo tempo o isolamento entre inquilinos e sistemas do edifício.
Escolha uma plataforma quando esta remover uma barreira de migração real. Se o seu parque informático necessita de WiFi sem palavra-passe, acesso de funcionários integrado com o diretório, revogação automática e menor dependência de RADIUS local, avalie se uma plataforma como o Purple se enquadra na arquitetura de identidade e rede existente. Mantenha a decisão associada aos seus objetivos de controlo, requisitos de integração e propriedade operacional.
Meça o progresso através de evidências, não de anúncios de implementação. Deve ser capaz de demonstrar quais as identidades que têm acesso, quais os dispositivos que são fidedignos, quais as políticas que recusaram pedidos, com que rapidez a revogação surtiu efeito e onde ainda existem exceções. É assim que o zero trust se torna uma capacidade operacional, em vez de mais um programa de segurança estagnado.
O Purple fornece WiFi e redes baseadas em identidade que ligam funcionários e dispositivos a diretórios existentes, suporta acesso sem palavra-passe e de nível de certificado, e pode automatizar o aprovisionamento e a revogação à medida que o estado do diretório muda. Visite a Purple para avaliar de que forma a sua autenticação WiFi, postura do dispositivo e integrações de rede podem apoiar uma implementação faseada de zero trust.
