Règle EC2 réservée au VPN : chaque groupe de sécurité attaché doit être d'accord

Vous ajoutez une règle entrante pour le pool de clients VPN, vous ne supprimez rien, et le service reste joignable depuis internet. Rien n'est cassé. Un groupe de sécurité n'a ni dérogation, ni priorité, ni refus final contre lesquels la règle étroite pourrait l'emporter. Chaque groupe attaché à l'instance apporte ses propres autorisations à un ensemble combiné, et la règle large que vous avez oubliée figure toujours dans cet ensemble. Rendre l'instance uniquement VPN signifie auditer tous les groupes, pas ajouter une règle qui sonne mieux à un seul.

Écrivez le service avant d'écrire la règle

Commencez par la destination exacte, le protocole et le port, ainsi que l'interface réseau sur laquelle le service écoute réellement. Une instance avec plusieurs interfaces ou plusieurs services sur un port exige l'audit par interface, car les groupes attachés peuvent différer. Déterminez ensuite quelle adresse source cette interface reçoit réellement pour un utilisateur VPN, plutôt que l'adresse que le client affiche dans sa propre fenêtre de connexion.

Ces deux adresses divergent plus souvent qu'on ne l'attend dès que la traduction et le routage entrent en jeu.

Trois modèles de source, trois règles différentes

Avec un accès privé routé, l'instance reçoit le pool de clients ou la plage d'entreprise, selon la façon dont le chemin est routé et traduit. Avec un point de terminaison public atteint via la sortie d'entreprise, l'instance voit à la place l'adresse NAT d'entreprise, et seulement si cette destination utilise réellement le chemin VPN, car le tunnel divisé peut la laisser sur une connexion domestique. Avec un point de terminaison Client VPN géré, le modèle documenté d'association et de réseau cible s'applique, et l'adresse du client provient du CIDR client configuré.

Ce qui ne fonctionne pas, c'est de référencer une passerelle VPN comme source d'un groupe de sécurité. Les références de groupe correspondent à des interfaces réseau élastiques dans le VPC ou dans un réseau appairé, et une passerelle qui transfère des paquets n'en fait pas partie.

Lisez l'union sur tous les groupes attachés

Ouvrez l'instance, trouvez son interface réseau et listez chaque groupe de sécurité qui y est attaché. Pour chacun, vérifiez chaque règle couvrant votre protocole et votre port, y compris les plages de ports larges et les deux familles d'adresses. Une règle IPv4 depuis 0.0.0.0/0 ne vous dispense pas de vérifier ::/0, et une règle autorisant tout le trafic masque entièrement la question du port. Ce n'est qu'après cet inventaire que vous pouvez dire quelle est la permission effective pour le service.

La référence des règles AWS décrit les groupes de sécurité comme uniquement autorisants et indique que les règles de tous les groupes attachés sont agrégées, ce qui est tout le mécanisme derrière cet échec.

Les ACL réseau sont une politique distincte et sans état, avec des entrées d'autorisation et de refus ordonnées, et elles s'évaluent sur le sous-réseau et non sur l'instance.

Ne répondez pas par un mur de refus

Ajouter un refus NACL à l'échelle du sous-réseau pour imiter un pare-feu auquel vous êtes habitué est le mauvais outil et un outil risqué. Les entrées NACL sont ordonnées et sans état, donc un refus placé au-dessus d'une autorisation existante casse silencieusement du trafic sans rapport, y compris le chemin de retour des sessions que vous cherchiez à conserver. Corrigez l'autorisation large du groupe de sécurité dans le groupe qui la possède, puis laissez l'ACL tranquille, sauf si elle fait vraiment partie de la conception.

Retirer une adresse publique de l'instance est une garantie plus forte, et c'est aussi un changement d'architecture avec des conséquences administratives et applicatives, pas une case à cocher sur une liste d'autorisations.

Testez avec une nouvelle session et gardez un moyen d'entrer

Avant de retirer une autorisation existante, confirmez un chemin d'administration indépendant et approuvé, car la règle que vous êtes sur le point de supprimer peut être celle dont dépend la récupération de votre session. Testez ensuite une nouvelle connexion autorisée depuis le VPN et une nouvelle connexion refusée depuis un chemin de test autorisé hors VPN. Les sessions suivies existantes survivent aux changements de règles d'une manière qui rend les anciens shells ouverts inutiles comme preuve d'acceptation.

Enfin, maintenez l'autorisation propre à l'application. Une sortie d'entreprise traduite peut représenter des centaines de personnes, et l'admission réseau n'a jamais identifié un utilisateur individuel ni son appareil.