Zero trust no SOC pequeno: primeiros controles de acesso

Zero trust no SOC pequeno começa por quatro controles que cabem em uma equipe enxuta: MFA resistente a phishing nas contas administrativas, inventário dos dispositivos que acessam os sistemas, acesso privilegiado com escopo e tempo limitados e telemetria de autenticação alimentando a fila de alertas. Segmentação fina, avaliação contínua de políticas e automação entram depois, quando essa base já existe. Na definição do NIST, zero trust não concede confiança implícita a contas ou ativos com base apenas na localização física ou de rede, nem na propriedade do dispositivo, e é essa inversão que muda a ordem de prioridades de um time pequeno: o primeiro trabalho não é comprar plataforma, é saber quem acessa o quê, de qual dispositivo e por qual motivo.

Por que o perímetro não basta

A arquitetura de confiança zero descrita no SP 800-207 do NIST, publicado em agosto de 2020, responde a um cenário que o modelo de perímetro já não cobre: usuários remotos, dispositivos pessoais e ativos em nuvem que nunca passam pela rede corporativa. O documento é explícito em que o zero trust protege recursos — ativos, serviços, fluxos de trabalho e contas — em vez de segmentos de rede, porque a localização na rede deixou de ser o componente principal da postura de segurança de um recurso. Para um SOC pequeno, isso significa que o inventário de recursos protegidos vale mais do que qualquer regra interna de firewall.

Identidade: MFA resistente a phishing

O pilar de identidade concentra o melhor retorno por esforço. No modelo do NIST, autenticação e autorização, tanto do usuário quanto do dispositivo, são funções discretas executadas antes de a sessão para um recurso corporativo ser estabelecida — na prática, cada acesso é decidido na hora, com o menor privilégio possível por requisição, assumindo que a rede pode estar comprometida. A consequência operacional direta: códigos por SMS e e-mail deixam de ser aceitos para contas administrativas, porque podem ser capturados em uma página falsa e reutilizados na mesma sessão. Passkeys no padrão FIDO2 e chaves de segurança físicas eliminam o segredo transportável. Considere também que nenhuma camada de autenticação encerra a história: incidentes recentes mostram ransomware contornando MFA depois do acesso inicial, o que devolve a responsabilidade à detecção do SOC.

Dispositivos e redes conhecidas

Sem saber quais máquinas existem, toda decisão de acesso vira palpite. O inventário de dispositivos começa simples: todo host que acessa sistemas internos precisa estar registrado, com agente, certificado ou registro equivalente no provedor de identidade. O modelo de maturidade do CISA trata Devices e Networks como pilares próprios da jornada zero trust, e uma diretriz concreta do documento serve de primeiro passo: quando existem as opções HTTP e HTTPS, as políticas e configurações devem preferir HTTPS. Para a rede, a meta inicial não é microssegmentação completa, e sim reduzir o tráfego leste-oeste que nenhuma regra observa hoje — começando pelos caminhos entre estações de trabalho e servidores críticos, e registrando cada exceção de comunicação com justificativa.

Acesso privilegiado sob controle

Contas administrativas permanentes são o ativo mais rentável para um invasor, porque transformam um único acesso inicial em movimento lateral pela organização. O caminho curto para uma equipe pequena: eliminar admin permanente de estações de trabalho, exigir elevação just-in-time com aprovação registrada e documentar o que cada conta de serviço faz e onde autentica. A telemetria fecha o ciclo — técnicas como pass-the-hash continuam sendo o desfecho comum de um acesso concluído, e a elevação fora do horário de negócio é um dos sinais mais baratos de monitorar.

Telemetria que sustenta a decisão

Zero trust sem telemetria de autenticação centralizada é política de papel. Os eventos que merecem regra própria desde o primeiro dia: registro de nova credencial, mudança do método de autenticação de um usuário, picos de falhas de verificação seguidos de sucesso e autenticação interativa de conta de serviço. Essa coleta alimenta o mesmo pipeline que o time já usa para alertas, sem plataforma nova — o valor está em decidir qual evento de identidade vira alerta com dono definido na fila, e não em acumular log sem consumidor.

Sequência de implantação sugerida

Para não transformar a adoção em projeto infinito, use maturidade como régua. O modelo de maturidade do CISA organiza a jornada zero trust em pilares com níveis de maturidade tradicional, inicial, avançado e ótimo, e o próprio documento orienta que organizações de qualquer tipo podem considerar a adoção dos caminhos descritos, não apenas agências federais americanas. A meta de um SOC pequeno é sair do estágio tradicional no pilar de identidade e avançar um nível por vez.

Uma sequência possível para começar, recomendada por este guia como ponto de partida ajustável:

1. Inventariar contas administrativas e remover direitos permanentes não justificados.
2. Exigir MFA resistente a phishing em todas as contas administrativas e no acesso remoto.
3. Centralizar logs de autenticação no SIEM e criar as quatro regras mínimas de identidade.
4. Registrar os dispositivos autorizados no provedor de identidade e bloquear host desconhecido.
5. Implantar elevação just-in-time para administração de servidores.
6. Revisar trimestralmente contas, credenciais e excessos de privilégio.

Fontes

• NIST SP 800-207 — Zero Trust Architecture
• CISA — Zero Trust Maturity Model
• CISA — Zero Trust Maturity Model versão 2.0 (PDF, abril de 2023)