Endurecimento do host

O PEART defende suas próprias superfícies, mas alguns controles são do host e não podem ser impostos pela aplicação. Esses são os que o operador possui.

A postura de sandbox em que o PEART é suportado

As três units distribuídas rodam sob o sandbox do systemd, e o PEART é suportado com tudo ligado. Você não precisa afrouxar diretiva nenhuma para o produto funcionar. Se descobrir que precisa, isso é defeito a relatar, não drop-in a escrever. O que cada um dos quatro encontrados assim imprimia, e o que segura cada correção, está em Quando a causa é uma diretiva de endurecimento.

As três units carregam NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes, PrivateTmp=yes, PrivateDevices=yes, ProtectKernelTunables=yes, ProtectKernelModules=yes, ProtectControlGroups=yes, RestrictNamespaces=yes, RestrictRealtime=yes, RestrictSUIDSGID=yes, LockPersonality=yes, SystemCallArchitectures=native e SystemCallFilter=@system-service.

O renderizador carrega mais, porque é ele que interpreta conteúdo escrito por um atacante: PrivateNetwork=yes, IPAddressDeny=any, MemoryDenyWriteExecute=yes, um segundo SystemCallFilter subtraindo @privileged, @resources e @obsolete, e o MemoryMax=1G com TasksMax=256 que limitam uma renderização descontrolada.

O que cada serviço pode escrever é diferente, e a diferença é o desenho. O peart escreve em qualquer lugar sob /var/lib/peart. O peart-portal escreve só em db, lê renditions e reports, e não enxerga evidence nem a chave mestra. O peart-render não escreve em lugar nenhum da árvore de dados: /var/lib/peart/work é montado só para leitura para ele, então o processo que interpreta HTML hostil tem apenas o próprio PrivateTmp para escrever.

Duas partes desta postura são do host e não da unit, e são suportadas do mesmo jeito: as três contas de serviço são usuários de sistema sem diretório pessoal criado, e o volume de dados pode ser montado nosuid.

Leia a lista como promessa. Mudança que precise afrouxar uma destas é quebra dela, e deve chegar até você como decisão com razão, não como drop-in que você escreve no seu host.

Cifragem de disco para o banco

O banco é texto claro por desenho (ver Cifragem). A cifragem de disco no host, LUKS, é o controle recomendado e documentado para o banco em repouso. É responsabilidade do operador, porque é um controle de host, e é o controle compensatório sobre o qual toda a decisão de banco-em-claro se apoia. Se você fizer um passo de endurecimento, faça esse.

Desbloqueio sem ninguém no console

Numa VM de produção sem console, LUKS puro significa digitar uma passphrase a cada boot, o que não escala e na prática deixa de acontecer em silêncio. O padrão que torna a cifra em repouso sustentável é o desbloqueio ligado à rede: o host abre o volume sozinho quando, e só quando, alcança um servidor de chave na rede confiável. A sua distribuição documenta o mecanismo e os comandos dele, e esta página deliberadamente não os repete, porque um handbook que transcreve a linha de comando de outro projeto herda as mudanças dele sem nenhuma forma de perceber.

Três coisas nisso são do PEART, e são as que ninguém mais vai escrever para você.

O serviço herda a latência de boot do servidor de chave. Um volume que desbloqueia pela rede não monta antes de a rede subir e o servidor de chave responder, e /var/lib/peart é esse volume. É por isso que o RequiresMountsFor=/var/lib/peart que as units trazem importa mais aqui do que num volume local: sem ele, ou com a montagem chegando tarde, o serviço sobe contra um ponto de montagem vazio no sistema de arquivos raiz, escreve ali, e o dado some quando o volume monta por cima. Rodar como serviço trata o caso geral; o desbloqueio por rede é o que alarga a janela.

O keyslot de emergência não é opcional. Ligue o volume ao servidor de chave num keyslot próprio e guarde uma passphrase em outro. Sem ele, um servidor de chave fora do ar não atrasa o seu dado, ele o remove. É a troca que este padrão faz, e ela precisa ser feita de olhos abertos: sai uma passphrase que ninguém digita, entra um servidor de chave que, inalcançável, segura o boot.

Prove que ele recusa. Tire o servidor de chave do ar e reinicie: o volume não pode abrir sozinho, e tem de pedir a passphrase de emergência. Devolva o servidor e reinicie: volta a abrir sozinho. Enquanto esse teste não for feito, ninguém sabe se a cifra em repouso está valendo ou se o volume apenas por acaso abre, e controle não testado é o que se descobre na pior hora possível.

Exposição de rede

As duas superfícies têm exposição diferente por desenho, e o host deve impô-la. O portal (peart-portal) é alcançável pelo cliente pela internet; a superfície interna (peart) deve ser alcançável só da rede restrita ou VPN da consultoria, nunca de onde o cliente alcança o portal. Ambos ficam presos ao loopback e atrás de um proxy reverso que termina TLS, então o firewall e o proxy são o que de fato decidem quem alcança qual superfície.

O isolamento do sidecar de renderização

O renderizador processa HTML derivado de conteúdo hostil e não pode alcançar a internet nem o endpoint de metadados da nuvem. No systemd isso é PrivateNetwork=yes e IPAddressDeny=any no peart-render.service; no caminho por container é a rede internal sem rota para fora. É um requisito, não um botão de ajuste, e removê-lo reabre em silêncio uma superfície de server-side request forgery. Não afrouxe.

Arquivo de chave e permissões

A chave mestra mora fora do diretório de dados, modo 0600, do usuário que roda, então um backup dos dados nunca pode contê-la. Mantenha assim, e guarde a cópia exportada (ver Backup e restore) em local separado do backup dos dados. Uma chave no mesmo lugar que os dados que ela protege torna a cifragem um teatro.