Què pot assolir encara una passarel·la web compromesa?
La passarel·la web limita què obre un visitant, no què pot marcar un amfitrió compromès. Dues revisions, una taula d'autoritat i ordres de comprovació de l'abast.
Suposem que l'amfitrió de la passarel·la queda compromès mentre el seu certificat encara és vàlid. Totes les regles que regien quines pàgines pot demanar un visitant continuen en vigor, i cap d'aquestes regles no limita la connexió que l'atacant obre ara des d'aquest amfitrió cap a la subxarxa de la base de dades. Aquest buit és la raó per la qual un punt d'entrada només web no és la mateixa afirmació que una xarxa segmentada. Les dues afirmacions necessiten revisions separades, des de punts de partida diferents, abans que cap d'elles es pugui fer honestament.
Dues afirmacions, i només una comença al visitant
La primera afirmació tracta d'una persona: un visitant amb un navegador i una sessió vàlida pot obrir una aplicació i res més. Un punt d'entrada només web respon bé aquesta afirmació, perquè el visitant rep una pàgina i no una ruta. Aquesta resposta val la pena, i també és l'única afirmació que registren la majoria de diagrames.
La segona afirmació tracta d'un component: es pressuposa que la passarel·la, o el procés d'aplicació que hi ha darrere, està sota el control d'una altra persona. A partir d'aquest supòsit, la pregunta canvia de quins URL es permeten a quines destinacions i identitats pot arribar encara el procés.
Les dues afirmacions tenen propietaris diferents, produeixen proves diferents i fallen de manera independent. Un equip d'identitat pot demostrar la primera amb una prova de sessió; la segona necessita política de xarxa, revisió del compte de servei i controls de l'amfitrió. Un disseny que només registra la meitat del visitant sembla complet en una diapositiva de revisió i prim durant un incident, perquè els controls que importen després d'un compromís mai no van ser a l'abast. Nomena quina afirmació recolza cada control, o una regla de passarel·la s'atribuirà a totes dues.
Un servei de despeses treballat, i les dues maneres com perd
Prenem un servei de despeses: una passarel·la pública a 10.60.4.10 autentica el personal i reenvia les sol·licituds aprovades a un oient d'aplicació al port 8443, i aquesta aplicació arriba a un oient PostgreSQL a 10.60.4.20:5432 com a rol expenses_app. No es pretén que els empleats rebin accés intern general. En funcionament normal, el disseny sí que lliura una entrada específica de l'aplicació sense publicar l'oient de la base de dades enlloc. Les adreces importen, perquè cada comprovació posterior en aquest article les nomena.
Ara treu la passarel·la del conjunt de confiança. A quines destinacions pot arribar 10.60.4.10 un cop el seu procés pertany a un atacant? El filtre d'URL que restringia els visitants no diu res sobre una connexió que l'amfitrió de la passarel·la obre cap a la subxarxa de la base de dades.
Treu en canvi el procés d'aplicació, i l'autoritat canvia de forma: el rol expenses_app, els serveis que aquest servidor pot assolir i els fitxers que aquest compte pot llegir. En tots dos casos la porta d'entrada pot quedar només web mentre la frontera del backend és absent. Per tant, l'etiqueta de la porta d'entrada no és resposta a cap de les dues preguntes.
Mapa l'autoritat que cada part té realment
Un contracte escrit com a permisos previstos tendeix a repetir-te el disseny. Escriu-lo com a autoritat tinguda, la comprovació que refuta l'excés i el propietari d'aquesta comprovació, i cada fila esdevé comprovable. Aquesta taula és una proposta per a l'exemple anterior, no una afirmació de producte:
| 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 propietat segueix l'autoritat. L'equip d'identitat posseeix les assercions, l'equip de plataforma de xarxa posseeix les rutes, l'equip d'aplicació posseeix el rol de base de dades, l'administrador de base de dades posseeix l'oient i les seves regles basades en amfitrió, i el propietari de la plataforma posseeix el pla de gestió. Una denegació sense propietari és una frase en un document, no un control.
La divisió també evita el doble recompte. Una restricció de port no pot expressar un privilegi de taula, i un rol de base de dades no pot impedir que un amfitrió obri un sòcol cap a una subxarxa no relacionada.
Enumera què pot assolir la passarel·la en lloc d'afirmar-ho
Una afirmació de frontera val tant com l'enumeració que hi ha al darrere. A l'amfitrió de la passarel·la, tres ordres cobreixen la selecció de ruta, una sonda en viu i la política de sortida:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLlegeix la sortida en aquest ordre. La ruta diu si 10.60.4.20 s'escull fins i tot des d'aquell amfitrió; la sonda diu si l'oient respon; el llistat de regles mostra si la política atura el paquet o si mai no hi havia res al seu camí.
Repeteix l'enumeració des de l'amfitrió de l'aplicació. Des d'allà, el costat de la base de dades és una consulta executada com a rol de l'aplicació:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Una connexió correcta sota un rol que no pot llegir un altre esquema és un resultat diferent d'una connexió correcta sota un rol propietari. Només la segona és una troballa.
Registra les denegacions i després data la revisió
L'acceptació s'escriu com a resultats i no com a intencions: una sessió d'empleat no pot arribar a l'oient, l'amfitrió de la passarel·la no pot arribar a una subxarxa no relacionada, i el rol de l'aplicació no pot crear una base de dades. Cadascuna és una comprovació separada amb un propietari nomenat i una data.
Mantén el monitoratge, els pedaços i la recuperació accessibles pel camí de gestió dissenyat per a ells. Una frontera que també bloqueja el seu propietari es converteix en una caiguda, i la primera resposta habitual a aquesta caiguda és tornar a ampliar la regla. La guia de perímetre de la CISA demana limitar l'accés d'entrada i de sortida a ports i protocols justificats, inclòs el trànsit entre xarxes internes, que és la direcció iniciada pel backend que la majoria de diagrames ometen.
Data la revisió i nomena'n el propietari. Torna a executar l'enumeració i la consulta de privilegis després de qualsevol canvi a la imatge de la passarel·la, la taula d'encaminament o el rol de l'aplicació.