Uma firewall entre portas não é uma fronteira de host

O site responde na 443, a VPN responde na 1194, a firewall permite exatamente essas duas, e a revisão passa. Nada nessa sequência perguntou o que o trabalhador web pode ler ou que ficheiros pode reescrever. Um trabalhador comprometido não precisa de uma porta aberta se conseguir alcançar um socket de controlo ou um diretório de configuração onde possa escrever. A fronteira é a autoridade, e os ouvintes são apenas a parte fácil de ver.

Um nome de serviço separado é um rótulo; uma identidade separada é uma propriedade de segurança.

Conte a autoridade do trabalhador, não as portas

Comece pelo utilizador de execução, os seus grupos, as suas capacidades e a sua vista do sistema de ficheiros. Uma conta de serviço que pertence por acaso a um grupo de VPN pode ler material de chaves sem qualquer porta aberta. As montagens onde se pode escrever são a outra metade: os carregamentos e as caches devem ficar longe dos ficheiros de política e dos segredos, e um diretório partilhado onde se pode escrever sem necessidade arruína uma nomenclatura arrumada. Verifique o processo que executaria a operação, porque um pai privilegiado e trabalhadores sem privilégios não partilham uma única autoridade.

O facto de uma chave de VPN ser legível durante o arranque do daemon não significa que o trabalhador web precise dela. Separe a leitura feita pelo daemon do acesso concedido à aplicação.

Sockets que concedem mais do que parecem

Alguns pontos finais são API administrativas disfarçadas de fluxo de métricas. A interface de gestão da VPN pode mudar sessões, desligar clientes e ler o estado. O socket do tempo de execução de contentores é ainda mais amplo: o acesso a ele é efetivamente controlo do host, muito além do que uma aplicação web precisa. Nenhum dos dois pertence ao conjunto de montagens de uma aplicação comum, e nenhum aparece quando conta as portas à escuta.

Ligar um ouvinte de gestão a um endereço local é um começo, não uma restrição completa, porque cada caminho de entrada para esse endereço continua a importar. Permita apenas as fontes e interfaces previstas.

Os contentores partilham um núcleo

Os contentores acrescentam fronteiras de processo, sistema de ficheiros e rede, e partilham um núcleo com o host. Isso torna decisivas as escolhas de capacidades, as montagens do host e o acesso ao daemon: montar segredos do host ou conceder controlo privilegiado do tempo de execução apaga a fronteira que o rótulo do contentor sugere. As VM separadas dão sim núcleos convidados separados, enquanto o hipervisor, as identidades administrativas, o armazenamento e as cópias de segurança continuam partilhados. Escolha a fronteira cuja configuração e atualizações têm um proprietário nomeado.

Um arranjo mais elaborado que ninguém mantém é pior do que um simples que é realmente revisto.

Teste a negação e depois o serviço

Use verificações aprovadas no contexto real do trabalhador para confirmar que não pode alterar a política de VPN, ler segredos desnecessários nem tocar na interface de gestão. Uma leitura bem-sucedida como administrador não testa nada sobre essa negação. Depois verifique o site, uma operação de VPN comum e permitida, e o que acontece a cada uma ao reiniciar. Preserve um caminho de recuperação que não dependa de reparar a VPN, para que um erro continue recuperável.

Ambos os papéis continuam a partilhar CPU, memória, capacidade de ligação ascendente e eventos de manutenção. Esses recursos partilhados pertencem ao plano mesmo quando a fronteira de autoridade está limpa.

Registe o que cada processo pode fazer, o que falha se parar e que fronteira continua partilhada. A contagem de portas não é esse registo.