Les règles AWS Client VPN relèvent de la ressource, pas du sous-réseau

Le personnel doit atteindre une application dans le VPC et ne doit pas atteindre l'écouteur de base de données sur la même instance, alors quelqu'un ajoute un second sous-réseau public pour le point de terminaison VPN et déclare l'exigence satisfaite. L'emplacement du sous-réseau change le routage et la disponibilité. Il n'accorde ni ne refuse un seul port. L'autorisation qui exprime l'exigence vit à la destination, dans le groupe de sécurité de la ressource, et la frontière VPN fournit la poignée à laquelle cette règle se réfère.

L'emplacement du sous-réseau relève du routage, pas de l'autorisation

L'endroit où se trouve l'association réseau du point de terminaison décide quelle table de routage transporte le trafic des clients et quelles zones de disponibilité survivent à une panne. Il ne dit rien du port, sur telle instance, que ce trafic peut atteindre. Deux clients associés au même sous-réseau arrivent toujours avec la même identité de source, et la ressource ne peut pas les distinguer par le nom du sous-réseau.

Partez plutôt de l'exigence : qui appelle, quelle ressource, quel port de service et dans quel sens. Choisissez ensuite le modèle de règle capable d'exprimer ces quatre éléments à la destination. Ce cadrage supprime généralement le sous-réseau supplémentaire du schéma.

Le groupe d'association Client VPN est la poignée

Pour un point de terminaison AWS Client VPN associé à un sous-réseau, la disposition documentée est précise. Appliquez le groupe de sécurité prévu aux associations de réseau cible du point de terminaison, puis autorisez le trafic requis dans le groupe de sécurité de la ressource en utilisant ce groupe Client VPN comme source.

Concrètement, le groupe de l'instance d'application autorise le port applicatif depuis le groupe d'association, et rien d'autre. La procédure d'accès aux ressources d'AWS décrit cette relation, et il vaut la peine de conserver la même politique de groupe sur chaque sous-réseau auquel le point de terminaison s'associe, car une association obsolète avec un autre groupe élargit discrètement la frontière.

Cette règle n'authentifie personne. La connexion est un contrôle distinct, et la route vers la ressource en est un troisième. Les trois doivent tenir avant qu'une requête n'arrive. Celle qui échoue détermine la correction pertinente, et modifier la règle n'est la bonne réponse que pour la première.

Ce qu'un groupe d'association ne peut pas distinguer

Chaque client derrière le même groupe d'association atteint la ressource comme la même source de groupe de sécurité. Deux utilisateurs aux rôles différents sont indistinguables à cette couche, quelle que soit la façon dont le groupe est nommé ou étiqueté. L'autorisation des groupes externes de Client VPN limite l'accès par préfixe de destination pour un groupe d'annuaire ou SAML, ce qui est plus grossier qu'un rôle de ressource et doit être traité comme une frontière réseau, non comme un système d'identité.

Les distinctions plus fines relèvent de l'application. Un écouteur de base de données qui doit rester fermé à la plupart du personnel est mieux protégé en n'étant pas atteignable du tout sur le préfixe autorisé qu'en espérant que l'appartenance au groupe reste propre.

Renommer le groupe ne crée pas une identité, et le dupliquer par équipe ne fait que multiplier les associations à auditer.

Ne copiez pas cette règle dans chaque conception VPN

Une passerelle EC2 VPN auto-gérée, un équipement d'inspection routé et un Client VPN géré sont trois chemins de paquets différents. Établissez quelle adresse source atteint réellement la ressource, si une traduction intervient en chemin et quels mécanismes de référence le service prend en charge sur ce chemin.

Faire transiter le trafic par un intermédiaire ne préserve pas une référence de groupe de sécurité source comme le fait le trafic direct d'instance à instance. AWS documente que de telles conceptions peuvent avoir besoin des adresses privées de source ou des CIDR appropriés plutôt que d'une référence de groupe. La procédure Client VPN géré ne prouve pas que le groupe attaché à chaque passerelle fonctionne comme un jeton d'identité universel pour les paquets transférés.

Un seul saut NAT sur le chemin suffit à briser l'hypothèse, et la panne ressemble à une règle présente qui ne correspond jamais.

Examinez la frontière effective

Lisez chaque groupe de sécurité attaché à la ressource, car les règles d'autorisation se combinent et une règle étroite n'annule pas une règle plus large sur un autre groupe. Vérifiez ensuite l'ACL réseau, le pare-feu de l'hôte et l'autorisation propre à l'application, qui sont des couches distinctes avec des erreurs distinctes.

Terminez par une requête autorisée et une requête délibérément exclue contre la même ressource. La paire prouve la frontière, alors qu'une seule connexion réussie ne prouve que l'ouverture de quelque chose. Confirmez la route, la source effective et le port de service prévu plutôt que le sous-réseau qui contient le point de terminaison.

Ordre du travail : rédigez l'exigence en quatre parties, attachez le groupe aux associations, limitez la règle de la ressource au port, vérifiez une autorisation et un refus, et seulement ensuite envisagez de diviser les sous-réseaux pour des raisons de routage.