Administrer le NAS par VPN : gardez le nom, abandonnez le port public
Atteignez la page d'administration par le tunnel, pas par un nouveau port public. Résolvez le vrai nom, faites-y correspondre le certificat et autorisez un seul service depuis une seule source.
La page d'administration du NAS fonctionne à la maison et cesse de fonctionner à l'instant où l'administrateur voyage, alors quelqu'un ouvre un port et le problème disparaît avec la confidentialité. Il existe une meilleure forme pour cela. Laissez la page où elle est, laissez le tunnel fournir l'accessibilité, et faites de ce que vous documentez une URL complète avec un chemin d'autorisation nommé plutôt qu'une adresse d'appareil qui répond par hasard. Chaque décision ci-dessous, du nom au certificat et au seul port autorisé, découle du fait de l'écrire ainsi.
L'unité de conception est une URL, pas une adresse
Écrivez l'entrée comme une URL complète avec son port et son schéma, puis attachez-y les conditions : qui peut l'utiliser, depuis quel réseau et par quel chemin. Un exemple pourrait être https://nas.corp.example:8443 publié uniquement pour des clients privés approuvés, le nom et le port représentant ce sur quoi l'appareil écoute réellement.
Ce cadrage force les décisions tôt. Une URL implique un nom, un nom implique un certificat, et un certificat implique un accord de confiance. Une adresse n'implique rien de tout cela, et c'est précisément pourquoi la version adresse seule survit jusqu'au premier avertissement du navigateur, puis devient une habitude de cliquer à travers.
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
Gardez le nom pour lequel le certificat a été émis
Le client a besoin d'une route autorisée vers l'adresse privée du NAS, et un dispositif DNS privé peut résoudre le nom d'hôte prévu vers cette adresse tout en préservant le nom que le service HTTPS attend. Les deux moitiés comptent : la route y amène les paquets, le nom indique au client quelle identité vérifier.
Saisir l'adresse numérique à la place change l'exigence d'identité. La RFC 9525 sépare le nom que le client entend joindre de l'identité qu'un service présente, si bien qu'un certificat émis pour nas.corp.example peut légitimement échouer lorsque le navigateur a été pointé vers 10.20.0.15. L'avertissement est correct, et le correctif est le nom, pas une exception.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleExécutez les deux avant d'accuser le tunnel. Le premier montre si le nom privé se résout là où vous pensez, et le second montre quel certificat et quels autres noms de sujet le service présente réellement. Une AC privée peut être un choix parfaitement maîtrisé ; ce qui ne devrait pas devenir une routine, c'est d'apprendre aux gens à ignorer les avertissements d'identité.
Bornez le chemin d'administration
Autorisez exactement le service d'administration depuis la source prévue, à la fois sur la passerelle et sur le NAS. Cette phrase cache un détail qui mord : un pool de clients routés et une passerelle à traduction de source arrivent au NAS avec des adresses sources différentes, si bien qu'une règle d'autorisation écrite pour l'une échoue silencieusement pour l'autre.
Le NAS a aussi besoin d'un chemin de retour, et le navigateur doit utiliser le port et le schéma configurés plutôt que la valeur par défaut du fabricant tirée d'un message de forum. Atteindre l'appareil n'est pas la permission d'atteindre chacun de ses ports. L'écart entre un appareil qui répond au ping et une page d'administration qui se charge est l'écart entre deux règles distinctes. Écrivez-les comme deux règles avec deux commentaires, pour que la personne suivante voie pourquoi les deux existent.
Séparez l'admission VPN du privilège NAS
Être laissé passer par le tunnel n'est pas la même chose qu'être autorisé à administrer l'appareil. Un utilisateur qui a légitimement besoin de stockage de fichiers ne devrait pas hériter de l'administration de l'appareil parce que les deux vivent derrière une même passerelle, et le modèle de comptes du NAS est l'endroit où cette séparation doit être appliquée.
Une adresse de sortie partagée ou traduite ne peut pas non plus identifier un administrateur individuel. Si la piste d'audit doit nommer une personne, l'identité doit venir d'un compte authentifié plutôt que de l'adresse source d'un tunnel que beaucoup de gens utilisent.
Ce qu'il ne faut pas publier par accident
Un proxy inverse public et un relais constructeur sont tous deux des architectures réelles, et chacune porte ses propres décisions de confiance et d'exposition. Aucune ne devient nécessaire parce qu'un administrateur est loin de chez lui, et aucune ne devrait apparaître comme effet secondaire de l'exposition d'un serveur multimédia ou d'un partage de fichiers.
Documentez quatre choses et arrêtez-vous : le nom privé, l'écouteur auquel il correspond, le groupe autorisé à l'utiliser et le chemin de récupération si le tunnel est indisponible. Ces quatre éléments répondent aussi aux questions que posera une revue d'incident, ce qui n'est pas vrai d'une capture d'écran d'une page de redirection de port. Ce que vous obtenez est un point d'entrée administratif stable plutôt qu'un appareil dont chaque fonction fait face à l'internet.