La ce mai poate ajunge un gateway web compromis?
Un gateway web limitează ce deschide un vizitator, nu la ce poate ajunge o gazdă compromisă. Două revizuiri, un tabel al autorității și comenzi de măsurare a accesului.
Să presupunem că gazda gateway-ului este compromisă în timp ce certificatul său este încă valid. Fiecare regulă care stabilea ce pagini poate solicita un vizitator rămâne în vigoare, iar niciuna dintre aceste reguli nu limitează conexiunea pe care atacatorul o deschide acum de pe acea gazdă spre subrețeaua bazei de date. Exact acest decalaj face ca un punct de intrare doar web să nu fie aceeași afirmație ca o rețea segmentată. Cele două afirmații necesită revizuiri separate, din puncte de plecare diferite, înainte ca vreuna să poată fi făcută onest.
Două afirmații, și doar una dintre ele începe la vizitator
Prima afirmație este despre o persoană: un vizitator cu browser și sesiune validă poate deschide o aplicație și nimic altceva. Un punct de intrare doar web răspunde bine acestei afirmații, pentru că vizitatorul primește o pagină, nu o rută. Acel răspuns merită păstrat și este și singura afirmație pe care o înregistrează majoritatea diagramelor.
A doua afirmație este despre o componentă: se presupune că gateway-ul, sau procesul aplicației din spatele lui, se află sub controlul altcuiva. Din această presupunere întrebarea se schimbă de la ce URL-uri sunt permise la la ce destinații și identități mai poate ajunge procesul.
Cele două afirmații au proprietari diferiți, produc dovezi diferite și eșuează independent. O echipă de identitate poate demonstra prima cu un test de sesiune; a doua necesită politică de rețea, revizuirea contului de serviciu și controale ale gazdei. Un design care înregistrează doar jumătatea vizitatorului pare complet pe un slide de revizuire și subțire în timpul unui incident, pentru că controalele care contează după o compromitere nu au fost niciodată în scop. Numiți ce afirmație susține fiecare control, altfel o regulă a gateway-ului va fi creditată ambelor.
Un serviciu de cheltuieli lucrat, și cele două moduri în care pierde
Luați un serviciu de cheltuieli: un gateway public la 10.60.4.10 autentifică personalul și redirecționează cererile aprobate către un ascultător al aplicației pe portul 8443, iar aplicația ajunge la un singur ascultător PostgreSQL la 10.60.4.20:5432 ca rolul expenses_app. Angajații nu trebuie să primească acces intern general. În funcționarea normală, designul oferă într-adevăr o intrare specifică aplicației fără a publica ascultătorul bazei de date nicăieri. Adresele contează, pentru că fiecare verificare ulterioară din acest articol le numește.
Acum scoateți gateway-ul din setul de încredere. La ce destinații poate ajunge 10.60.4.10 odată ce procesul său aparține unui atacator? Filtrul URL care restricționa vizitatorii nu spune nimic despre o conexiune pe care gazda gateway-ului o deschide spre subrețeaua bazei de date.
Scoateți în schimb procesul aplicației, iar autoritatea își schimbă forma: rolul expenses_app, serviciile la care poate ajunge acel server și fișierele pe care le poate citi acel cont. În ambele cazuri ușa din față poate rămâne doar web în timp ce granița backend lipsește. Așadar eticheta de pe ușa din față nu este răspuns la niciuna dintre cele două întrebări.
Cartografiați autoritatea pe care o deține efectiv fiecare parte
Un contract scris ca permisiuni intenționate tinde să vă repete designul. Scrieți-l ca autoritate deținută, verificarea care infirmă excesul și proprietarul acelei verificări, iar fiecare rând devine testabil. Acest tabel este o propunere pentru exemplul de mai sus, nu o afirmație despre produs:
| 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 |
Proprietatea urmează autoritatea. Echipa de identitate deține aserțiunile, echipa platformei de rețea deține rutele, echipa de aplicație deține rolul bazei de date, administratorul bazei de date deține ascultătorul și regulile sale bazate pe gazdă, iar proprietarul platformei deține planul de management. O respingere fără proprietar este o propoziție într-un document, nu un control.
Împărțirea împiedică și dubla numărare. O restricție de port nu poate exprima un privilegiu de tabel, iar un rol de bază de date nu poate împiedica o gazdă să deschidă un socket către o subrețea fără legătură.
Enumerați la ce poate ajunge gateway-ul în loc să o afirmați
O afirmație despre graniță este doar atât de bună cât enumerarea din spatele ei. Pe gazda gateway-ului, trei comenzi acoperă selecția rutei, o sondă live și politica de ieșire:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputCitiți rezultatul în această ordine. Ruta spune dacă 10.60.4.20 este măcar selectat de pe acea gazdă; sonda spune dacă ascultătorul răspunde; lista de reguli arată dacă politica oprește pachetul sau dacă nu a existat niciodată nimic pe calea lui.
Repetați enumerarea de pe gazda aplicației. De acolo, partea bazei de date este o singură interogare rulată ca rol al aplicației:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'O conexiune reușită sub un rol care nu poate citi altă schemă este un rezultat diferit de o conexiune reușită sub un rol proprietar. Doar a doua este o constatare.
Înregistrați respingerile, apoi datați revizuirea
Acceptarea se scrie ca rezultate, nu ca intenții: o sesiune de angajat nu poate ajunge la ascultător, gazda gateway-ului nu poate ajunge la o subrețea fără legătură, iar rolul aplicației nu poate crea o bază de date. Fiecare este o verificare separată cu un proprietar numit și o dată.
Mențineți monitorizarea, patch-urile și recuperarea accesibile prin calea de management concepută pentru ele. O graniță care blochează și proprietarul ei devine o întrerupere, iar primul răspuns obișnuit la acea întrerupere este să lărgi din nou regula. Ghidul de perimetru al CISA cere ca accesul de intrare și de ieșire să fie limitat la porturi și protocoale justificate, inclusiv traficul dintre rețelele interne, care este direcția inițiată de backend pe care majoritatea diagramelor o omit.
Datați revizuirea și numiți proprietarul ei. Rulați din nou enumerarea și interogarea privilegiilor după orice modificare a imaginii gateway-ului, a tabelului de rutare sau a rolului aplicației.