docs: adicionada politica estrita Zero-Root de privilégios mínimos para Docker e sistema

This commit is contained in:
Rui
2026-05-10 05:52:59 +02:00
parent 77fcb72f97
commit 24ba95ec78
+12 -6
View File
@@ -244,13 +244,19 @@ Atualmente, a VPS 1 acumula as funções de **Gateway de Borda (Traefik)**, **Hu
--- ---
### 6. 🔒 Hardening Avançado de Containers ### 6. 🔒 Hardening de Privilégios Mínimos (Zero-Root) e Containers
Para garantir que a invasão de um container não resulte no comprometimento do sistema operacional host, aplicam-se as seguintes diretrizes de segurança no provisionamento de containers Docker: Como princípio fundamental de segurança de toda a infraestrutura, **absolutamente nada e ninguém deve rodar ou possuir privilégios de `root`**, especialmente os ambientes de containers Docker e serviços locais. O privilégio de superusuário (`root`) é restrito exclusivamente ao administrador humano de forma temporária e monitorada via comandos `sudo` específicos.
* **No-New-Privileges**: Impede que processos dentro do container ganhem novos privilégios via binários `setuid` ou `setgid`. * **🚫 Política de Zero-Root Geral**:
* **Read-Only Root Filesystem**: Monta o sistema de arquivos do container como apenas leitura, forçando gravações temporárias apenas em volumes declarados ou `/tmp` na memória (tmpfs). * É expressamente proibido rodar serviços, scripts personalizados, bancos de dados, crons ou ferramentas de monitoramento como `root`.
* **CAP Drop**: Remove capacidades de sistema desnecessárias ao container (ex: `NET_ADMIN`, `SYS_ADMIN`, `SYS_CHROOT`). * Todos os softwares do host devem rodar sob contas de sistema dedicadas e não privilegiadas (ex: usuário `deploy`, `postgres`, `git`, etc.).
* **Rootless Containers**: Sempre que suportado pela aplicação, os containers devem rodar com IDs de usuário não privilegiados (non-root).
* **🐋 Hardening Estrito no Docker**:
* **Docker Rootless Mode**: O motor do Docker Daemon deve ser instalado e operado no modo **Rootless** (sem privilégios de root no host). Isso garante que, mesmo que ocorra uma vulnerabilidade severa de escape de container ou comprometimento do daemon do Docker, o atacante ganhará apenas privilégios de um usuário comum e sem direitos administrativos no servidor principal.
* **Uso Obrigatório de Usuários Não Privilegiados (`USER`)**: É obrigatório declarar um usuário não root (ex: `USER node` ou `USER 1000:1000`) nas etapas finais de construção de todas as imagens Docker e arquivos `docker-compose.yml`. Nenhum processo interno de container pode rodar como UID `0` (root).
* **No-New-Privileges**: Todos os containers devem subir com a flag `--security-opt=no-new-privileges` ativa, impedindo que processos internos ganhem novos privilégios via binários `setuid` ou `setgid`.
* **Read-Only Root Filesystem**: O sistema de arquivos raiz do container deve ser montado como apenas leitura (`read_only: true`), limitando qualquer escrita temporária estritamente a volumes efêmeros montados em memória (`tmpfs`).
* **CAP Drop**: O container deve descartar todas as capacidades administrativas padrão do Linux Kernel (`cap_drop: [ "ALL" ]`) e habilitar estritamente apenas o mínimo necessário para a sua execução lógica básica.
--- ---