Un pare-feu entre ports n'est pas une frontière d'hôte

Le site répond sur 443, le VPN répond sur 1194, le pare-feu autorise exactement ces deux-là, et la revue passe. Rien dans cette séquence n'a demandé ce que le travailleur web peut lire ni quels fichiers il peut réécrire. Un travailleur compromis n'a pas besoin d'un port ouvert s'il peut atteindre une socket de contrôle ou un répertoire de configuration inscriptible. La frontière, c'est l'autorité, et les écouteurs ne sont que la partie facile à voir.

Un nom de service distinct est une étiquette ; une identité distincte est une propriété de sécurité.

Comptez l'autorité du travailleur, pas les ports

Commencez par l'utilisateur d'exécution, ses groupes, ses capacités et sa vue du système de fichiers. Un compte de service qui appartient par hasard à un groupe VPN peut lire du matériel de clé sans qu'aucun port ne soit ouvert. Les montages inscriptibles sont l'autre moitié : les téléversements et les caches doivent rester loin des fichiers de politique et des secrets, et un répertoire inscriptible partagé sans nécessité ruine un nommage soigné. Vérifiez le processus qui effectuerait l'opération, car un parent privilégié et des travailleurs non privilégiés ne partagent pas une même autorité.

Que la clé VPN soit lisible au démarrage du démon ne signifie pas que le travailleur web en ait besoin. Séparez la lecture effectuée par le démon de l'accès accordé à l'application.

Des sockets qui accordent plus qu'elles n'en ont l'air

Certains points de terminaison sont des API administratives déguisées en flux de métriques. L'interface de gestion du VPN peut changer des sessions, déconnecter des clients et lire l'état. La socket du moteur de conteneurs est plus large encore : y accéder équivaut à contrôler l'hôte, bien au-delà des besoins d'une application web. Ni l'une ni l'autre n'appartient au jeu de montages d'une application ordinaire, et ni l'une ni l'autre n'apparaît quand on compte les ports en écoute.

Lier un écouteur de gestion à une adresse locale est un début, pas une restriction complète, car chaque chemin d'entrée vers cette adresse compte encore. N'autorisez que les sources et interfaces prévues.

Les conteneurs partagent un noyau

Les conteneurs ajoutent des frontières de processus, de système de fichiers et de réseau, et ils partagent un noyau avec l'hôte. Cela rend décisifs les choix de capacités, les montages de l'hôte et l'accès au démon : monter des secrets de l'hôte ou accorder un contrôle privilégié d'exécution efface la frontière que suggère l'étiquette du conteneur. Des VM séparées donnent bel et bien des noyaux invités séparés, tandis que l'hyperviseur, les identités administratives, le stockage et les sauvegardes restent partagés. Choisissez la frontière dont la configuration et les mises à jour ont un propriétaire nommé.

Un agencement plus élaboré que personne n'entretient est pire qu'un agencement simple qui est réellement relu.

Testez le refus, puis le service

Utilisez des contrôles approuvés dans le contexte réel du travailleur pour confirmer qu'il ne peut pas modifier la politique VPN, lire des secrets inutiles ni toucher l'interface de gestion. Une lecture réussie en administrateur ne teste rien de ce refus. Vérifiez ensuite le site, une opération VPN ordinaire autorisée, et ce qui arrive à chacune au redémarrage. Conservez un chemin de reprise qui ne dépende pas de la réparation du VPN, pour qu'une erreur reste récupérable.

Les deux rôles partagent encore le CPU, la mémoire, la capacité de liaison montante et les événements de maintenance. Ces ressources partagées font partie du plan même lorsque la frontière d'autorité est propre.

Consignez ce que chaque processus peut faire, ce qui échoue s'il s'arrête et quelle frontière reste partagée. Le décompte des ports n'est pas cette consignation.