Por que suas contas "svc-" são uma bomba-relógio

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

Bem-vindo de volta ao podcast e ao nosso aprofundamento contínuo em arquitetura de segurança corporativa. Se a sua organização for parecida com a maioria, uma olhada rápida no seu Active Directory ou no diretório do Microsoft Entra ID vai revelar um cemitério enorme de contas começando com "svc-", "app-" ou "admin-bot". Essas contas mantêm tudo funcionando, os dados fluindo e as automações rodando. Mas elas também são o maior ponto cego da sua postura de segurança moderna. Neste post, vamos expandir a nossa conversa mais recente para explicar por que as contas de serviço tradicionais minam completamente a sua arquitetura Zero Trust e por que migrar para as Identidades de Carga de Trabalho do Microsoft Entra é o único caminho a seguir.

Para uma análise completa em áudio deste tema, não deixe de ouvir o nosso episódio complementar do podcast, Replace Service Accounts with Entra Workload Identities. Agora, vamos mergulhar na mecânica do risco não humano e em como você pode eliminá-lo de vez.

TL;DR

Contas de serviço com segredos estáticos e direitos amplos são a sua maior lacuna de identidade. As Identidades de Carga de Trabalho (no Microsoft Entra ID) dão a cada ator não humano uma identidade governada, com privilégio mínimo, ciclo de vida, políticas de Acesso Condicional, rotação e trilhas de auditoria completas, sem quebrar as suas automações.

Por que as contas de serviço falham (e quebram o Zero Trust)

O modelo tradicional de conta de serviço foi criado para uma era de perímetros de rede que não existem mais. Naquela época, em que a confiança era definida por um dispositivo estar conectado à LAN corporativa, uma senha estática armazenada em um arquivo de configuração parecia aceitável. Hoje, essa filosofia de design é um passivo.

Segredos estáticos e sem MFA -> fáceis de roubar, difíceis de rotacionar com segurança
Privilégios excessivos por padrão -> permissões do tipo "faça funcionar" tornam-se permanentes
Sem ciclo de vida -> contas órfãs ou esquecidas sobrevivem a migrações e reorganizações
Auditoria precária -> "quem usou isso e por quê?" = adivinhação e capturas de tela
Cultura de exceções -> exclusões de Acesso Condicional/MFA para bots ampliam discretamente a sua superfície de ataque

Identidades Gerenciadas: um bom passo, mas restritas ao Azure

Quando as organizações percebem que contas de serviço estáticas são perigosas, o primeiro movimento natural costuma ser em direção às Identidades Gerenciadas do Azure. Embora as Identidades Gerenciadas representem um enorme avanço, pois eliminam completamente os segredos para recursos hospedados no Azure, elas têm limites bem definidos.

✅ Acesso sem segredos para recursos nativos do Azure (Functions, VMs, Logic Apps)
❌ Lacunas para destinos híbridos/de terceiros, mapeamento de responsabilidade fraco e visões de governança limitadas
❌ A cobertura de Acesso Condicional e de direitos não é uniforme em superfícies fora do Azure

Identidades de Carga de Trabalho: o que você realmente ganha

É aqui que entram as Identidades de Carga de Trabalho do Microsoft Entra. Em vez de tratar atores não humanos como cidadãos de segunda classe ou de forçá-lo a restrições exclusivas do Azure, as Identidades de Carga de Trabalho elevam aplicativos, scripts e serviços automatizados à condição de entidades de segurança de primeira classe.

Identidades não humanas de primeira classe (apps, scripts, conectores, RPA, integrações)
Permissões com escopo definido (funções do Graph e de recursos, autenticação somente de aplicativo) com privilégio mínimo
Ciclo de vida (proprietário, cadência de revisão, fluxo de desativação) vinculado ao processo de negócio
Acesso Condicional para cargas de trabalho (controles baseados em risco e contexto, controles de sessão onde houver suporte)
Higiene de credenciais (segredos de curta duração, certificados, política de rotação de chaves)
Visibilidade unificada (entradas, tokens, acesso a recursos, histórico de alterações) -> pronta para auditoria

Matriz comparativa (visão geral)

Recurso	Conta de serviço	Identidade gerenciada	Identidade de carga de trabalho
Segredos	Senhas estáticas	Sem segredos (Azure)	Sem segredos/curta duração + rotação
Escopo	Amplo / semelhante a usuário	Centrado no Azure	Qualquer carga de trabalho (apps/scripts/conectores)
AC / Risco	Raramente aplicado	Limitado	Baseado em políticas, onde houver suporte
Ciclo de vida	Ad hoc	Básico	Proprietário + revisões + desativação
Auditoria	Esparsa	Logs do Azure	Trilha centralizada de entradas e direitos

Padrões de arquitetura (casos de uso comuns)

Implementar Workload Identities exige mapeá-las corretamente de acordo com os padrões de arquitetura. Veja como elas se aplicam às cargas de trabalho corporativas mais comuns:

Conectores do Power Platform / fluxos de nuvem -> Atribua uma workload identity por integração; conceda apenas os escopos necessários do Graph/Dataverse.
Aplicativos de linha de negócio (APIs web, daemons) -> Registro de aplicativo + certificado; use funções de aplicativo + Graph somente com aplicativo; aplique CA onde aplicável.
Scripts de automação (Azure Automation, GitHub Actions, DevOps) -> Use credenciais federadas (OIDC), sem segredos armazenados.
Jobs entre locatários / B2B -> Workload identity dedicada por fronteira de locatário; isole os direitos e os logs.

Playbook de migração (90 dias, sem sobressaltos)

Lidar com centenas de contas de serviço legadas pode parecer avassalador. É por isso que você precisa de um playbook de migração estruturado, de 90 dias, com foco na redução de riscos.

Fase 1 — Descobrir e priorizar (Semanas 0–3)

Inventarie os logons não humanos e os objetos: svc-*, app-*, caixas de correio compartilhadas, registros de aplicativos, segredos que expiram em menos de 90 dias.
Mapeie cada um quanto a proprietário, finalidade de negócio, destinos, permissões e dependência de contas de acesso de emergência.
Classifique por risco: senhas estáticas, funções globais, ausência de proprietário, rotação recente inexistente.

Fase 2 — Converter primeiro os de alto risco (Semanas 4–8)

Crie uma workload identity por integração (não reutilize).
Substitua a autenticação por senha por certificados ou credenciais federadas; defina a rotação.
Migre para permissões somente de aplicativo; remova as permissões delegadas por usuário quando não forem necessárias.
Aplique políticas de Acesso Condicional para os logons de cargas de trabalho (onde houver suporte).
Implemente análises de acesso (trimestrais) + propriedade registrada no CMDB/ITSM.

Fase 3 — Desativar e governar (Semanas 9–12)

Desabilite as contas de serviço antigas; monitore por 14 dias; depois exclua.
Imponha padrões de criação: nomenclatura, proprietário, classificação de dados e frequência de revisão.
Adicione alertas: logons anômalos, identidades inativas há mais de 30/60/90 dias e segredos prestes a expirar.
Incorpore verificações de identidade ao CI/CD (policy-as-code).

Acesso Condicional e permissões (proteções práticas)

Um dos recursos mais poderosos das plataformas de identidade modernas é a capacidade de aplicar proteções especificamente voltadas a atores não humanos. Ao separar as políticas de identidades humanas e de cargas de trabalho, você impede que bots acionem alertas de viagem impossível e, ao mesmo tempo, continua bloqueando o tráfego malicioso.

Políticas separadas para identidades humanas e de cargas de trabalho; bloqueie o logon interativo para cargas de trabalho.
Locais nomeados / restrições de rede para acesso somente de aplicativo, quando viável.
Permissões com prazo (PIM para funções de aplicativo, quando disponível; análises de acesso agendadas).
Escopos: prefira funções de aplicativo / funções específicas de recurso em vez de direitos em todo o diretório.

Logs e auditoria (o que apresentar ao auditor)

Quando oficiais de conformidade e auditores batem à porta, eles não aceitam mais planilhas ou garantias verbais sobre quem tem acesso a scripts de back-end. Você precisa conseguir comprovar a governança imediatamente, com logs centralizados.

Proprietário do aplicativo/carga de trabalho, finalidade e sensibilidade dos dados
Logs de entrada (logons de entidades de serviço), público-alvo do token, IP, aplicativo cliente
Atribuições de função (quem aprovou, quando foi certificada)
Histórico de credenciais (tipo, última rotação, expiração)
Ciclo de vida: criado/modificado/desabilitado/excluído, com o responsável pela alteração

Painel de KPIs (comprove a melhoria)

Para manter o apoio da liderança, acompanhe e reporte indicadores-chave de desempenho que demonstrem a redução de riscos das identidades não humanas ao longo do tempo.

% de identidades não humanas com proprietário + frequência de revisão (meta ≥ 95%)
Contas de serviço órfãs (meta -> 0)
Segredos com mais de 90 dias (meta -> 0; prefira certificado/credencial federada)
Abrangência de funções somente de aplicativo (contagem de “Directory.ReadWrite.All” -> em queda)
Achados de auditoria sobre acesso não humano (trimestre a trimestre ↓)

Padrões antipadrão a eliminar

Ao limpar o ambiente, garanta que as equipes não voltem aos velhos hábitos. Elimine imediatamente estes antipadrões:

Reutilizar uma única conta de serviço genérica em vários sistemas
Incorporar senhas em scripts, web.config ou Key Vault sem nenhuma política de rotação
Conceder Global Admin / Owner “por precaução” para manter os jobs em execução
Exceções “temporárias” ao CA que nunca expiram

Ganhos rápidos (esta semana)

Você não precisa esperar o início de um grande projeto para começar a melhorar sua postura de segurança. Aqui estão quatro ganhos rápidos que você pode executar esta semana:

Marque todas as identidades não humanas com Owner, System, Data Class.
Migre um job de alto risco para credenciais federadas (GitHub OIDC -> Entra).
Substitua uma conta de serviço compartilhada no Power Automate por uma identidade de carga de trabalho.
Crie um relatório de service principals com segredos expirando ou expirados e agende alertas.

Perguntas frequentes (respostas rápidas)

As identidades de carga de trabalho quebram jobs legados on-prem?
Não. Faça a ponte com autenticação somente de aplicativo, certificados ou serviços intermediários, e aposentе as senhas gradualmente.

Posso aplicar o Acesso Condicional a logons não humanos?
Sim, para os fluxos suportados (logons de service principal). Use sinais de rede, localização e dispositivo quando aplicável e bloqueie o modo interativo.

Como evito a proliferação?
Uma identidade de carga de trabalho por integração (não por equipe). Imponha nomenclatura, proprietário e revisões na criação; automatize a limpeza de itens inativos.

E o Power Platform?
Use Service Principals / Identidades de carga de trabalho para conectores e Dataverse; pare de usar contas de usuário compartilhadas.

Conclusão

Você não consegue resolver o risco de contas de serviço apenas rotacionando senhas. As Identidades de carga de trabalho do Entra trazem o acesso não humano para o mesmo modelo de Zero Trust, ciclo de vida e auditoria que você já exige para pessoas, sem interrupções nem gambiarras. Comece pelas contas “svc-” mais arriscadas, converta-as em identidades de carga de trabalho governadas e faça com que as exceções voltem a ser exceções.

Se você gostou deste artigo, não deixe de conferir a discussão completa no nosso episódio do podcast, Replace Service Accounts with Entra Workload Identities. Assine o programa para mais análises aprofundadas sobre estratégias de segurança do Microsoft 365 e Azure para empresas!