Aplique o princípio do privilégio mínimo: contas de serviço sem shell, sudo restrito, systemd isolado, usuários do banco, papéis no Proxmox e no Windows.

Para que serve

O privilégio mínimo é dar a cada pessoa, aplicação e script apenas as permissões necessárias para a sua tarefa, e nada além. Quando uma aplicação web roda como root ou o backup usa a senha de administrador do Proxmox, uma única falha vira controle total do servidor. Com contas e permissões separadas, o invasor fica preso ao pedaço que comprometeu. Este artigo mostra como aplicar isso no Linux, no banco de dados, no Proxmox VE e no Windows Server.

Pré-requisitos

  • Acesso root/administrador ao host e às VMs.
  • Uma lista dos serviços que rodam em cada VM e de quem precisa administrar o quê.
  • Uma janela de teste: mudar o usuário de um serviço pode exigir ajustar permissões de pastas.

Passo 1: privilégio mínimo para contas de serviço no Linux

  1. Crie um usuário de sistema por aplicação, sem senha e sem shell: 
    sudo useradd --system --home-dir /opt/minhaapp --shell /usr/sbin/nologin minhaapp
sudo chown -R minhaapp:minhaapp /opt/minhaapp
  2. Rode o serviço com esse usuário e com isolamento do systemd. Exemplo de /etc/systemd/system/minhaapp.service: 
    [Unit]
Description=Minha aplicação
After=network.target

[Service]
User=minhaapp
Group=minhaapp
ExecStart=/opt/minhaapp/bin/minhaapp
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/opt/minhaapp/dados /var/log/minhaapp
CapabilityBoundingSet=
Restart=on-failure

[Install]
WantedBy=multi-user.target
    Se a aplicação precisa escutar em porta abaixo de 1024, troque CapabilityBoundingSet= por AmbientCapabilities=CAP_NET_BIND_SERVICE e CapabilityBoundingSet=CAP_NET_BIND_SERVICE.
  3. Aplique e avalie: 
    sudo systemctl daemon-reload && sudo systemctl restart minhaapp
systemd-analyze security minhaapp.service
    O comando mostra uma nota de exposição e quais proteções ainda faltam.
  4. Separe sites em PHP-FPM: um pool por site, cada um com o próprio user e group, para que a invasão de um site não permita ler os arquivos do outro.

Passo 2: sudo restrito em vez de root

Pessoas e scripts de deploy raramente precisam de root completo. Libere só os comandos necessários com visudo:

sudo visudo -f /etc/sudoers.d/deploy
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart minhaapp.service, /usr/bin/systemctl status minhaapp.service

Evite liberar editores, tar, find, less ou interpretadores (python, bash) via sudo: todos permitem escapar para um shell de root. Revise periodicamente com sudo grep -r . /etc/sudoers.d/ e getent group sudo.

Cuidado: um erro de sintaxe nos arquivos do sudo pode deixar você sem privilégio administrativo. Use sempre visudo, que valida antes de salvar, e mantenha uma sessão root aberta enquanto testa. Se perder o acesso, entre como root pelo console IPMI/iLO.

Passo 3: usuários do banco de dados

  • MySQL/MariaDB: um usuário por aplicação, preso ao banco dela e ao IP de origem: 
    CREATE USER 'app_erp'@'10.10.10.21' IDENTIFIED BY 'senha-longa-gerada';
GRANT SELECT, INSERT, UPDATE, DELETE ON erp.* TO 'app_erp'@'10.10.10.21';
    Para backup, um usuário só de leitura (SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER).
  • PostgreSQL: o dono do banco (que cria tabelas nas migrações) e o usuário da aplicação no dia a dia devem ser papéis diferentes. Restrinja origem e método no pg_hba.conf.
  • Nunca use root/postgres/sa na string de conexão de uma aplicação.

Passo 4: papéis e tokens no Proxmox VE e no Backup Server

  1. Usuários nominais com papéis limitados. Para quem só opera algumas VMs: 
    pveum user add joao@pve
pveum passwd joao@pve
pveum acl modify /vms/101 --users joao@pve --roles PVEVMUser
    Com muitas VMs, agrupe em Pools e dê a permissão em /pool/nome-do-pool.
  2. Tokens de API com separação de privilégios para integrações (monitoramento, automação, painéis de terceiros): 
    pveum user add monitor@pve
pveum user token add monitor@pve zabbix --privsep 1
pveum acl modify / --tokens 'monitor@pve!zabbix' --roles PVEAuditor
    O token só tem o que foi dado a ele explicitamente; PVEAuditor permite apenas leitura.
  3. Backup que não consegue apagar backup. No Proxmox Backup Server, dê ao usuário ou token usado pelo Proxmox VE o papel DatastoreBackup: ele cria backups e lê os próprios, mas não pode podar nem apagar. A limpeza (prune) fica com um agendamento no próprio PBS. Assim, se o host for comprometido, o invasor não destrói os backups pelo mesmo acesso.

Passo 5: Windows Server

  • Conta administrativa separada: cada pessoa usa uma conta comum para o dia a dia e outra, distinta, só para administrar. Confira quem é administrador com: 
    Get-LocalGroupMember -Group "Administradores"
    (use "Administrators" em instalações em inglês).
  • Serviços com contas virtuais em vez de um usuário administrador com senha. Uma conta virtual tem o formato NT SERVICE\NomeDoServico e não tem senha para vazar: 
    sc.exe config MeuServico obj= "NT SERVICE\MeuServico"
    Em domínio Active Directory, prefira contas gMSA, que têm senha trocada automaticamente.
  • Impeça logon interativo de contas de serviço com as diretivas "Negar logon por meio dos Serviços de Área de Trabalho Remota" e "Negar logon localmente" (secpol.msc → Diretivas Locais → Atribuição de direitos de usuário).
  • SQL Server: logins por aplicação com papéis no banco específico, nunca sa.

Como saber se funcionou

  • ps -eo user,comm | sort | uniq -c | sort -rn mostra as aplicações rodando com os seus usuários próprios, e não como root.
  • systemd-analyze security mostra notas melhores nos serviços ajustados.
  • O usuário joao@pve vê e opera apenas as VMs permitidas; tentar outra VM retorna "permission denied".
  • Tentar remover um backup com o token do PVE no PBS falha por falta de permissão.

Problemas comuns

  • Serviço não sobe após trocar o usuário: falta permissão em alguma pasta ou arquivo de configuração. Veja journalctl -u minhaapp -e e ajuste com chown/chmod apenas o necessário.
  • "Read-only file system" com ProtectSystem=strict: inclua a pasta em ReadWritePaths=.
  • Token do Proxmox sem acesso a nada: com --privsep 1, a permissão precisa ser dada ao token, não só ao usuário.
  • Aplicação exige ser administrador: geralmente ela só precisa de escrita em uma pasta ou de uma porta privilegiada. Descubra o motivo antes de conceder administrador.

Perguntas frequentes

Por que não usar o root para tudo, se só eu acesso o servidor?

Porque o risco não é só você: é cada aplicação exposta na internet. Com contas separadas, a falha em um sistema não entrega os demais.

O que é uma conta de serviço?

Uma conta usada por um programa, não por uma pessoa. Ela não deve ter senha conhecida, login interativo nem privilégios além do que o programa precisa.

Com que frequência revisar permissões?

Todo mês, junto com o checklist de segurança, e sempre que alguém entrar ou sair da equipe.

Leitura complementar

Precisa de ajuda?

Se perdeu o acesso administrativo depois de alterar sudo ou permissões e precisa do console IPMI/iLO, abra um ticket ou chame o suporte 24/7.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também