Como este tema funciona na sua empresa
Poucas contas privilegiadas, frequentemente compartilhadas entre pessoas. Controle manual, documentação mínima. Risco alto de: acesso não supervisionado, falta de auditoria, credential drifting. Primeiro passo: inventariar contas existentes, documentar proprietário, implementar MFA básico.
Separação começando a acontecer: admin separado para cada sistema. Service accounts começam a ser identificadas. Documentação de acessos, mas sem ferramenta centralizada. Próximo passo: implementar PAM (Privileged Access Management) básico, segregar funções, rotação de credenciais.
Taxonomia completa de contas. Separação rigorosa por função (admin para firewall ? admin para database). Service accounts em vault centralizado com rotação automática. Acesso JIT (just-in-time). Gravação de sessão para contas críticas. Monitoração contínua com SIEM e análise comportamental.
Contas privilegiadas são contas de usuário ou sistema com acesso elevado a recursos críticos (admin, root, DBA, service accounts), apresentando risco maior se comprometidas porque permitem impacto abrangente (lateral movement, exfiltração, sabotagem).
Por que contas privilegiadas são o "Crown Jewels" para atacante
Contas privilegiadas são alvo número 1 para atacante porque oferecem acesso de alto impacto: movimentação lateral em rede, exfiltração de dados, sabotagem de sistema. Estudos mostram que 70%+ dos breaches envolvem contas privilegiadas[1]. Sem controle robusto, risco cresce exponencialmente.
Tipos de contas privilegiadas: taxonomia clara
Não todo "privilégio" é igual. Cada tipo tem risco diferente e requer controle diferenciado:
Categorias de contas privilegiadas
Usuário com acesso administrative. Risco: comportamento (insider threat), credential theft. Controle: MFA obrigatório, acesso JIT, auditoria com logging completo (quem fez o quê, quando). Deve ter identidade clara, não compartilhada.
Conta para operações repetitivas (deployment, scaling). Risco: credential theft se credenciais armazenadas em script. Controle: usar ferramenta de secretos (vault), rotação automática, auditoria de ações. Não usar credentials em clear-text.
Conta de database administrator. Risco: acesso a dados sensíveis, queryabilidade. Controle: separação de funções (DBA para criação ? DBA para dados), auditoria de queries, tokenização de dados sensíveis quando possível. Logon com MFA.
Conta técnica usada por aplicação/script automático. Risco: credential theft, mal-uso por aplicação comprometida. Controle: credenciais em vault, rotação automática, permissões mínimas (least privilege), acesso restrito a IP/time window específico. FREQUENTEMENTE OVERLOOKED - requer tanta atenção quanto admin.
Conta de root do SO (Linux, Windows). Risco: acesso máximo, difícil de auditar. Controle: desabilitar login direto, usar `sudo` com logging, acesso JIT via PAM. Credencial armazenada com máxima segurança.
Conta de fornecedor ou consultoria. Risco: acesso pode ser deixado permanente após contrato, difícil de monitorar. Controle: credenciais temporárias, acesso JIT com justificação, monitoração, offboarding automático. Revisar trimestralmente se ainda é necessário.
Passos para governança de contas privilegiadas: o "PAM Lifecycle"
1. Descoberta: Inventariar todas contas privilegiadas existentes (admin em todos sistemas, service accounts, root). Muitas organizações descobrem contas "órfãs" que nem sabiam que existiam. Use ferramentas de discovery automático.
2. Documentação: Para cada conta: tipo, proprietário, sistema, data de criação, data de último uso, justificação de negócio. Revisar anualmente para remover contas desnecessárias.
3. Segregação de função: Admin para firewall ? admin para database ? admin para aplicação. Isso limita dano se uma conta é comprometida (attacker não tem acesso a todos sistemas).
4. Armazenamento seguro: Credenciais em vault centralizado (CyberArk, BeyondTrust, AWS Secrets Manager), nunca em clear-text. Vault oferece criptografia, auditoria, rotação automática.
5. Rotação automática: Credenciais rotacionam automaticamente (ex: a cada 90 dias). Humanos não veem a credencial, apenas vault. Reduz risco de credential drifting.
6. Acesso JIT (Just-In-Time): Ao invés de acesso permanente, conceder por tempo limitado (ex: 1 hora) quando necessário. Reduz janela de exposição se comprometida.
7. Auditoria contínua: Logs de quem acessou com qual credencial, quando, o quê foi feito. SIEM correlaciona logs de múltiplas contas, detecta padrão anômalo (ex: admin acessando database em horário estranho). Para contas críticas, gravação de sessão (screen/keyboard).
8. Offboarding: Quando pessoa sai, conta é removida no mesmo dia. Quando contrato com fornecedor termina, credencial é revogada. Automação reduz risco de acesso órfão.
MFA em contas privilegiadas: complexidade específica
MFA em service account é complexo porque não há prompt interativo ("não consigo digitar código no script"). Alternativas: whitelisting de IP (script roda em IP específico que é whitelist), certificate-based auth, hardware token. Para admin humano, MFA é obrigatório (TOTP, hardware token, push notification).
Detecção de anomalias: comportamento como sinal
SIEM detecta: admin acessando de geo-location incomum, admin acessando base de dados de cliente específico que não é seu responsável, admin acessando em horário noturno (off-hours) sem justificativa, mudança rápida de múltiplos arquivos (possível ransomware). Comportamento anômalo gera alerta para investigação.
Sinais de que sua governança de contas privilegiadas é fraca
- Você não tem inventário claro de contas privilegiadas existentes
- Contas privillegiadas são compartilhadas (múltiplas pessoas, 1 credencial)
- Credenciais são armazenadas em clear-text (email, arquivo, note)
- Não há rotação de credencial; senha é "admin" há 3 anos
- Sem acesso JIT; admin tem acesso permanente mesmo quando não precisa
- Service accounts rodam com credenciais em hardcoded em script
- Sem auditoria; não há log de quem acessou com qual conta quando
- Third-party ainda tem acesso após contrato expirado
Caminhos para implementar governança de contas privilegiadas
Se organização tem competência de segurança, pode implementar PAM básico internamente: descoberta manual, vault simples (AWS, Azure), rotação scripted, logging.
- Tempo: 3-6 meses para estruturar
- Faz sentido quando: tem time de segurança capaz
Fornecedores (CyberArk, BeyondTrust) oferecem plataforma completa: descoberta automática, vault, rotação, JIT, auditoria, análise comportamental.
- Tipo: CyberArk, BeyondTrust, Deloitte consultoria
- Vantagem: solução integrada, suporte especializado
- Custo: R$ 50-500 mil (implementação + 3 anos licença)
Precisa de apoio para governança de contas privilegiadas?
Se implementar PAM é desafio, o oHub conecta você gratuitamente a especialistas em privileged access management e consultores de segurança.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso.
Perguntas frequentes
Quais são os tipos de contas privilegiadas?
Admin humano (usuário com acesso admin), SRE/Operations (conta para automação), DBA (acesso a database), service account (conta técnica usada por aplicação), system/root (SO root), third-party (fornecedor). Cada tipo tem risco e controle diferente.
Qual é o risco de contas privilegiadas compartilhadas?
Sem identidade clara, não há auditoria (quem fez o quê). Se comprometida, múltiplas pessoas têm acesso (mais vetores). Se pessoa sai, esquece de mudar senha. Risco: insider threat, credential theft, falta de accountability. Contas devem ser individuais.
Como controlar contas privilegiadas adequadamente?
Inventariar (descoberta), documentar (proprietário, justificativa), segregar função, armazenar em vault, rotar automaticamente, acesso JIT, auditoria contínua (logs + SIEM), offboarding automático. Service accounts: credencial em vault, não em script. Admin: MFA obrigatório.
Service accounts precisam de MFA?
MFA tradicional (TOTP) é complexo porque script não consegue digitar código. Alternativas: IP whitelisting (script roda em IP específico), certificate-based auth, hardware token. Para admin humano, MFA é obrigatório.
Como detectar uso anômalo de contas privilegiadas?
SIEM correlaciona logs: admin de geo incomum, acessando sistema que não é responsável, em horário noturno, mudança rápida de arquivos. Comportamento anômalo gera alerta. Importante: análise de padrão (baseline vs anomalia), não só flag de evento específico.
Acesso permanente ou just-in-time para contas privilegiadas?
JIT é mais seguro: acesso concedido por tempo limitado quando necessário. Reduz janela de exposição. Para admin: JIT é ideal (1 hora de acesso a sistem X). Para service account: acesso contínuo é necessário, mas credencial em vault com rotação automática compensa.