Como este tema funciona na sua empresa
Service accounts (contas de serviço) são contas técnicas sem usuário humano associado. Aplicações, scripts, integrações rodam sob essas contas. Problema: credenciais frequentemente hardcoded em código ou configuração, nunca rotadas, e quando descobertas em breach, viram backdoor permanente.
Tipos de service accounts
Service accounts variam por contexto: OS-level (NT AUTHORITY\SERVICE no Windows, root daemons em Linux), database accounts (sa, oracle, user de integração), API accounts (tokens de integração em Salesforce, SAP, Slack), built-in accounts (SYSTEM, LOCAL SERVICE). Cada um requer abordagem diferente de descoberta, armazenamento e rotação1.
Risco: credencial comprometida é backdoor
Diferença crítica entre usuário humano e service account: usuário tem sessão (login/logout, hora determinada); service account roda 24/7 sob mesma identidade. Se credencial de usuário é comprometida, logout o desconecta. Se credencial de service account é comprometida, atacante tem acesso persistente. Caso SolarWinds: service account de integração foi comprometida; atacante usou para inserir backdoor que infectou 18.000 clientes2.
Discovery: encontrando service accounts ocultos
Muitas orgs não têm inventário de service accounts; quando descobrem, contam muito mais do que esperavam. Técnicas de descoberta: scanning de código (grep por strings de credencial, buscar em .config, .properties), scanning de processos rodando (listar contas ativas), query em diretório (LDAP para contas de aplicação), interrogar logs de aplicação (quem faz login recorrente em horários não-humanos). Challenge: service accounts desativados ou esquecidos que ainda têm credenciais ativas.
Inventário e proprietário
Cada service account descoberto entra em inventário: nome, propósito, idade da credencial, proprietário (aplicação/time responsável), criticidade, data da última rotação. Inventário é ponto de partida para remediação. Priorizar: contas de aplicações críticas (ERP, banco de dados central), contas antigas (sem rotação em anos), contas com acesso administrativo3.
Armazenamento seguro: vault obrigatório
Nunca hardcode credenciais em código ou arquivo de configuração. Solução: vault corporativo (HashiCorp Vault, CyberArk, AWS Secrets Manager) que centraliza armazenamento criptografado, acesso via API, auditoria de quem acessou. Integração com aplicação: ao iniciar, aplicação pede credencial ao vault (dinâmica, não hardcoded). Benefit: credencial muda no vault; aplicação obtém a nova na próxima request.
Rotação automática de credenciais
Rotação manual é tedioso e esquecida. Rotação automática: vault integra com banco de dados, muda senha semanalmente (ou configurável), aplicação obtém nova no próximo request. Requisito: aplicação deve tolerar mudança de senha sem downtime (testes essenciais antes de automatizar). Fallback: se rotação falha, alerta imediato para análise. Algumas orgs usam gMSA (Group Managed Service Accounts) em Windows, que rodam rotação automaticamente.
Auditoria e detecção de anomalias
Service account não pode autenticar com MFA (sem usuário para responder challenge). Alternativas: IP whitelist (service account só acessa de server específico), mTLS (certificado cliente), análise de anomalia (comportamento esperado é X, alerta se desvio). Integração com SIEM: registrar cada ação (login, query, transfer) e correlacionar com padrão. Detecção: se service account de integração acessa dados que nunca acessou antes, alerta.
Sinais de que service accounts não estão controlados
- Credenciais hardcoded em código ou arquivo .config
- Sem inventário de service accounts (não sabe quantos existem)
- Contas antigas sem rotação há anos
- Sem vault; credenciais salvas em emails, wikis, anotações
- Sem auditoria; impossível saber quem fez o quê via service account
Próximos passos por porte de empresa
Perguntas frequentes
- O que é service account e como diferencia de conta de usuário?
- Service account é técnica (sem usuário humano), roda 24/7 sob mesma identidade. Usuário tem sessão (login/logout). Compromiso de service account é backdoor persistente.
- Por que service accounts são risco de segurança?
- Credenciais frequentemente hardcoded, nunca rotadas. Se comprometidas, atacante tem acesso persistente e invisível (sem logout).
- Como descobrir todos os service accounts em um ambiente?
- Scanning de código (grep credenciais), query em diretório (LDAP), análise de processos rodando, interrogação de logs (logins recorrentes fora de horário humano).
- Service accounts precisam de MFA?
- Não viável (sem usuário). Alternativas: IP whitelist, mTLS, análise de anomalia, integração com SIEM.
- Como automatizar rotação de credencial de service account?
- Vault integrado com sistema (banco, API) que muda credencial automaticamente. Aplicação obtém nova no próximo request (dinâmica).
- Como auditar ações de service account?
- Registrar cada ação (login, query, transfer) em logs centralizados. Integrar com SIEM para correlação e detecção de anomalia.
Referências
- 1 NIST SP 800-53 — AC-2 (Account Management): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- 2 Caso SolarWinds (APT uso de service account): https://www.cisa.gov/
- 3 CyberArk: Service Account Discovery White Paper: https://www.cyberark.com/resources/