Jusqu'où un gateway web compromis peut-il encore aller ?
Un gateway web limite ce qu'ouvre un visiteur, pas ce qu'un hôte compromis peut joindre. Deux revues, un tableau d'autorité et des commandes pour mesurer la portée.
Supposons que l'hôte du gateway soit compromis alors que son certificat est encore valide. Chaque règle qui déterminait quelles pages un visiteur peut demander reste en vigueur, et aucune de ces règles ne limite la connexion que l'attaquant ouvre à présent depuis cet hôte vers le sous-réseau de la base de données. C'est précisément cet écart qui fait qu'un point d'entrée purement web n'est pas la même affirmation qu'un réseau segmenté. Les deux affirmations exigent des revues distinctes, à partir de points de départ différents, avant que l'une ou l'autre puisse être faite honnêtement.
Deux affirmations, et une seule commence chez le visiteur
La première affirmation concerne une personne : un visiteur disposant d'un navigateur et d'une session valide peut ouvrir une application et rien d'autre. Un point d'entrée purement web répond bien à cette affirmation, car le visiteur reçoit une page plutôt qu'une route. Cette réponse vaut la peine d'être conservée, et c'est aussi la seule affirmation que la plupart des schémas enregistrent.
La seconde affirmation concerne un composant : on suppose que le gateway, ou le processus applicatif derrière lui, est sous le contrôle de quelqu'un d'autre. Partant de cette hypothèse, la question passe de quelles URL sont autorisées à quelles destinations et identités le processus peut encore atteindre.
Les deux affirmations ont des propriétaires différents, produisent des preuves différentes et échouent indépendamment. Une équipe d'identité peut démontrer la première par un test de session ; la seconde exige une politique réseau, une revue du compte de service et des contrôles de l'hôte. Une conception qui n'enregistre que la moitié visiteur paraît complète sur une diapositive de revue et mince pendant un incident, parce que les contrôles qui comptent après un compromis n'ont jamais été dans le périmètre. Nommez l'affirmation que chaque contrôle soutient, sinon une règle de gateway sera créditée aux deux.
Un service de notes de frais travaillé, et les deux façons dont il perd
Prenons un service de notes de frais : un gateway public à 10.60.4.10 authentifie le personnel et transmet les demandes approuvées à un écouteur applicatif sur le port 8443, et cette application atteint un écouteur PostgreSQL à 10.60.4.20:5432 en tant que rôle expenses_app. Les employés ne sont pas censés recevoir un accès interne général. En fonctionnement normal, la conception fournit bien une entrée propre à l'application sans publier l'écouteur de la base de données nulle part. Les adresses comptent, car chaque vérification ultérieure dans cet article les nomme.
Retirez maintenant le gateway de l'ensemble de confiance. Quelles destinations 10.60.4.10 peut-il atteindre une fois son processus aux mains d'un attaquant ? Le filtre d'URL qui limitait les visiteurs ne dit rien d'une connexion que l'hôte du gateway ouvre vers le sous-réseau de la base de données.
Retirez plutôt le processus applicatif, et l'autorité change de forme : le rôle expenses_app, les services que ce serveur peut atteindre et les fichiers que ce compte peut lire. Dans les deux cas, la porte d'entrée peut rester purement web tandis que la frontière du backend est absente. L'étiquette sur la porte d'entrée n'est donc pas une réponse à l'une ou l'autre des deux questions.
Cartographiez l'autorité que chaque partie détient réellement
Un contrat écrit comme des permissions prévues tend à vous répéter la conception. Écrivez-le comme autorité détenue, vérification qui réfute l'excès et propriétaire de cette vérification, et chaque ligne devient testable. Ce tableau est une proposition pour l'exemple ci-dessus, non une affirmation produit :
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
La propriété suit l'autorité. L'équipe d'identité détient les assertions, l'équipe de plateforme réseau détient les chemins, l'équipe applicative détient le rôle de base de données, l'administrateur de base de données détient l'écouteur et ses règles fondées sur l'hôte, et le propriétaire de la plateforme détient le plan de gestion. Un refus sans propriétaire est une phrase dans un document, pas un contrôle.
La séparation empêche aussi le double comptage. Une restriction de port ne peut pas exprimer un privilège de table, et un rôle de base de données ne peut pas empêcher un hôte d'ouvrir une socket vers un sous-réseau sans rapport.
Énumérez ce que le gateway peut atteindre au lieu de l'affirmer
Une affirmation de frontière ne vaut que ce que vaut l'énumération qui la sous-tend. Sur l'hôte du gateway, trois commandes couvrent la sélection de route, une sonde en direct et la politique de sortie :
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLisez la sortie dans cet ordre. La route indique si 10.60.4.20 est même sélectionné depuis cet hôte ; la sonde indique si l'écouteur répond ; la liste des règles montre si la politique arrête le paquet ou si rien n'a jamais été sur son chemin.
Répétez l'énumération depuis l'hôte applicatif. De là, le côté base de données est une seule requête exécutée sous le rôle applicatif :
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Une connexion réussie sous un rôle qui ne peut pas lire un autre schéma est un résultat différent d'une connexion réussie sous un rôle propriétaire. Seule la seconde est une constatation.
Enregistrez les refus, puis datez la revue
L'acceptation s'écrit en résultats et non en intentions : une session employé ne peut pas atteindre l'écouteur, l'hôte du gateway ne peut pas atteindre un sous-réseau sans rapport, et le rôle applicatif ne peut pas créer de base de données. Chacune est une vérification distincte avec un propriétaire nommé et une date.
Gardez la supervision, les correctifs et la restauration accessibles par le chemin de gestion prévu pour eux. Une frontière qui bloque aussi son propriétaire devient une panne, et la première réponse habituelle à cette panne est d'élargir à nouveau la règle. Le guide de périmètre de la CISA demande de limiter les accès entrants et sortants aux ports et protocoles justifiés, y compris le trafic entre réseaux internes, qui est la direction initiée par le backend que la plupart des schémas omettent.
Datez la revue et nommez son propriétaire. Relancez l'énumération et la requête de privilèges après toute modification de l'image du gateway, de la table de routage ou du rôle applicatif.