TLS natif, redirection SSH ou VPN pour un seul service cloud

La question est rarement de savoir s’il faut chiffrer quelque chose entre deux machines cloud ; elle est de savoir quelle interface vous chiffrez et qui vérifie l’identité de qui. Je commence ces conversations par le service plutôt que par le schéma réseau, parce que le service sait déjà ce dont il a besoin. Trois frontières couvrent la plupart des cas : le TLS propre à l’application, un seul port TCP redirigé via SSH et un overlay routé qui donne une adresse à chaque participant. Elles ne sont pas classées par force, mais par la part du problème qu’elles couvrent.

Commencez par le service, pas par le réseau

Partez du processus vers l’extérieur. Quel protocole parle-t-il, quel nom le client vérifiera-t-il et qui est autorisé à ouvrir une connexion ? Ces trois réponses éliminent des options plus vite que n’importe quel tableau comparatif, et la configuration du service y répond généralement en quelques minutes.

Prenez une petite API interne qui sert déjà HTTPS sur le port 8443 avec un certificat pour api.internal.example. ss -ltnp sur l’hôte montre à quoi elle se lie, et openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example montre si le certificat est valide pour le nom que le client utilisera réellement. Si les deux sont sains, le service peut protéger son propre flux et il ne reste que l’accessibilité. C’est un problème bien plus petit que de construire un réseau.

Étape 1 : le service se protège-t-il lui-même ?

C’est l’option à prendre quand elle convient, et elle convient plus souvent que les équipes ne le supposent. Le chiffrement du service couvre tout le chemin entre le client et le serveur, y compris chaque saut intermédiaire, ce qu’aucun tunnel autour du milieu n’améliore. Configurez le nom attendu et la confiance explicitement au lieu de vous fier à ce que le magasin par défaut du client contient par hasard.

Le chiffrement et l’accessibilité restent des contrôles distincts, et c’est leur fusion qui fait échouer cette option. Un service TLS sur un écouteur public non restreint accepte toujours des tentatives de connexion de n’importe qui, donc l’écouteur et les règles réseau doivent être délimités indépendamment du fait que la charge utile est protégée. Vérifiez ensuite les dépendances, car une API sur TLS ne dit rien du point de découverte, du port d’administration ou du canal de transfert en masse à côté. Chacun a besoin de sa propre réponse, et un seul frère non protégé suffit à faire de toute la frontière une fiction.

Étape 2 : un seul port TCP est-il toute l’exigence ?

Quand l’exigence est vraiment un seul port TCP, une redirection est la plus petite chose qui fonctionne. Une redirection locale SSH transporte ce port à travers une connexion authentifiée qui existe déjà.

La forme est ssh -N -L 8443:127.0.0.1:8443 [email protected], et le détail qui compte est l’adresse cible : 127.0.0.1 est résolu du côté distant, donc la connexion au service est ouverte depuis le bastion et non depuis votre portable. Liez l’écouteur local étroitement en -L 127.0.0.1:8443:... pour ne pas publier le service sur votre propre réseau local par accident. Côté serveur, limitez ce que le compte peut rediriger au lieu de faire confiance au bon comportement du client. PermitOpen, AllowTcpForwarding local et un GatewayPorts no par défaut sont les trois réglages qui transforment un relais générique en canal précis.

Le contrat est étroit dans les deux sens. SSH protège son propre canal, et un saut supplémentaire du bastion vers une autre application a besoin de sa propre protection. Un service qui n’écoute que sur le loopback du bastion a une exposition très différente de celui qu’on atteint par un autre réseau, et la redirection n’y change rien. Gardez l’authentification et les contrôles TLS de l’application au lieu de traiter le tunnel comme leur substitut.

Cela fonctionne bien pour une connexion avec un propriétaire. À l’échelle, cela devient un système : conflits de ports locaux, supervision, rotation des clés et la question de qui redémarre la redirection après un redémarrage.

Étape 3 : le routage est-il l’exigence réelle ?

Cette liste est le coût honnête de la plus petite option, et c’est pourquoi les équipes finissent par remplacer une poignée de commandes d’arrière-plan oubliées par quelque chose de géré. Le remplacement n’est pas automatiquement un VPN. Si l’exigence reste un seul port TCP, une redirection supervisée avec un propriétaire documenté coûte moins cher à exploiter qu’un overlay et échoue de façon visible. Mesurez la propriété opérationnelle avant de mesurer l’élégance.

Le routage devient la bonne réponse quand le routage est l’exigence. Plusieurs applications ayant besoin d’une connectivité IP ordinaire, des protocoles qu’une redirection TCP ne peut pas transporter, ou des services qui se déplacent entre hôtes pointent tous dans la même direction.

Un overlay donne aux participants une adresse et une route, puis le vrai travail commence : plages non chevauchantes, propriété des routes, DNS, enrôlement, révocation et ce qui se passe quand un pair disparaît. Rien de tout cela n’arrive avec l’adresse. Un pair admis dans l’overlay n’est pas non plus automatiquement autorisé pour chaque opération sur la destination, donc l’authentification au niveau du service reste.

Ce que vous possédez ensuite

Deux choses appartiennent à l’enregistrement que vous laissez. La première est l’identité que le client est censé vérifier, car chacune de ces frontières se dégrade silencieusement dès qu’une vérification de nom est relâchée pour faire fonctionner quelque chose. La seconde est l’étape de retrait : quelle clé, quelle règle ou quelle route disparaît quand l’accès se termine, et qui l’exécute.

La visite se termine là où elle a commencé, au service. Choisissez la frontière qui couvre le trafic réel et vérifie les pairs que vous vouliez vérifier, puis notez comment l’accès est mis à jour, surveillé et retiré. La référence OpenSSH est l’endroit où confirmer les options de redirection avant de promettre un contrat étroit. Si vous ne pouvez pas décrire l’étape de retrait en une phrase, la frontière est plus grande que le problème.