Contas de serviço em diferentes famílias de SO: privilégio mínimo para os próprios serviços em segundo plano de um agente

O que é

Cada família de SO oferece a um processo sem supervisão uma identidade que não é o login de uma pessoa:

• Usuários de sistema Linux: criados com useradd --system e com o shell /usr/sbin/nologin (ou /bin/false). A página de manual nologin(8) o descreve como um programa que recusa o login de forma educada e exibe o conteúdo de /etc/nologin.txt, se esse arquivo existir; a conta continua a ser dona de arquivos e a executar processos normalmente, apenas não consegue iniciar uma sessão interativa.
• systemd DynamicUser=: em vez de criar um usuário de sistema persistente, uma unit pode definir DynamicUser=yes na seção [Service]. A systemd.exec(5) documenta que o systemd então aloca um UID/GID dinamicamente apenas durante a execução da unit, sem conta persistente, diretório home ou shell para proteger; StateDirectory= continua a fornecer armazenamento persistente com o dono correto.
• Contas virtuais do Windows: identidades no formato NT SERVICE\<servicename>, geridas automaticamente pelo SO, sem senha para armazenar ou rotacionar. A Microsoft as documenta como uma opção ao lado das contas internas tradicionais Local System, Network Service e Local Service.
• Contas de serviço gerenciadas por grupo (gMSA): uma conta gerida pelo Active Directory, cuja senha é gerada e rotacionada automaticamente pelo AD e só pode ser obtida pelas máquinas especificamente autorizadas para ela, conforme a visão geral de gMSA da Microsoft. É o equivalente, em ambiente com domínio, da conta virtual para serviços que rodam em várias máquinas ou precisam de acesso ao domínio.
• Usuários daemon do macOS: os daemons geridos pelo launchd costumam rodar sob UIDs de sistema dedicados, na faixa baixa reservada, e não sob um usuário de login real; são configurados pelo arquivo de propriedades (plist) do launchd do daemon, e não por login em um shell.

Por que importa

Um agente que instala o seu próprio serviço em segundo plano (um agendador, um listener de webhook, um daemon de sincronização) herda a conta com que foi iniciado. Um serviço executado como um administrador comum ou como a conta do "usuário que fez o deploy" carrega todo o acesso a arquivos dessa conta e, no Windows, as suas credenciais de rede, muito mais do que o serviço precisa. Cada um dos mecanismos acima existe justamente para evitar isso: sem login interativo, sem senha de longa duração gerida à mão e, muitas vezes, sem nenhuma identidade persistente para limpar depois.

Como aplicar

• No Linux, prefira DynamicUser=yes (com StateDirectory= para os dados que precisam ser mantidos); recorra a um usuário --system com nologin quando arquivos fora dos diretórios geridos pelo systemd exigirem um UID estável.
• No Windows, um serviço criado com sc.exe create ou New-Service roda como LocalSystem, a menos que se indique o contrário; por isso, defina NT SERVICE\<name> explicitamente. Uma conta virtual acessa a rede como a conta do computador; use uma gMSA quando o serviço precisar de identidade de domínio própria ou rodar em vários hosts, em vez de uma conta de domínio compartilhada com senha estática.
• No macOS, execute os agentes em segundo plano como um usuário daemon dedicado, via launchd, e não como o usuário que está logado interativamente.
• Em todos os casos, conceda apenas as permissões específicas de arquivos, rede e API de que o serviço precisa, e não as permissões de quem o instalou.

Armadilhas

• Supor que nologin impede a conta de executar processos: ele bloqueia apenas o login interativo em shell; cron, systemd e su -s ainda podem executar comandos como esse usuário.
• Deixar a lista de computadores autorizados de uma gMSA mais ampla do que as máquinas que realmente executam o serviço.