A cosa può ancora arrivare un gateway web compromesso?
Un gateway web limita ciò che apre un visitatore, non ciò che può raggiungere un host compromesso. Due revisioni, una tabella delle autorità e comandi per misurare la portata.
Supponiamo che l'host del gateway sia compromesso mentre il suo certificato è ancora valido. Ogni regola che stabiliva quali pagine un visitatore può richiedere resta in vigore, e nessuna di queste regole limita la connessione che l'attaccante ora apre da quell'host verso la sottorete del database. È proprio questo divario che rende un punto di ingresso solo web non la stessa affermazione di una rete segmentata. Le due affermazioni richiedono revisioni separate, da punti di partenza diversi, prima che una di esse possa essere fatta onestamente.
Due affermazioni, e solo una delle due parte dal visitatore
La prima affermazione riguarda una persona: un visitatore con un browser e una sessione valida può aprire un'applicazione e nulla più. Un punto di ingresso solo web risponde bene a questa affermazione, perché il visitatore riceve una pagina invece di una rotta. Quella risposta vale la pena di averla, ed è anche l'unica affermazione che la maggior parte dei diagrammi registra.
La seconda affermazione riguarda un componente: si presume che il gateway, o il processo applicativo dietro di esso, sia sotto il controllo di qualcun altro. Da questo presupposto la domanda passa da quali URL sono consentiti a quali destinazioni e identità il processo può ancora raggiungere.
Le due affermazioni hanno proprietari diversi, producono prove diverse e falliscono in modo indipendente. Un team di identità può dimostrare la prima con un test di sessione; la seconda richiede criteri di rete, revisione dell'account di servizio e controlli dell'host. Una progettazione che registra solo la metà del visitatore sembra completa su una slide di revisione e sottile durante un incidente, perché i controlli che contano dopo un compromesso non sono mai stati nell'ambito. Nominate quale affermazione supporta ogni controllo, altrimenti una regola del gateway verrà accreditata a entrambe.
Un servizio spese sviluppato, e i due modi in cui perde
Prendiamo un servizio spese: un gateway pubblico su 10.60.4.10 autentica il personale e inoltra le richieste approvate a un listener applicativo sulla porta 8443, e quell'applicazione raggiunge un unico listener PostgreSQL su 10.60.4.20:5432 come ruolo expenses_app. I dipendenti non dovrebbero ricevere un accesso interno generale. In condizioni normali la progettazione offre davvero un ingresso specifico dell'applicazione senza pubblicare il listener del database da nessuna parte. Gli indirizzi contano, perché ogni verifica successiva in questo articolo li nomina.
Ora togliete il gateway dall'insieme fidato. Quali destinazioni può raggiungere 10.60.4.10 una volta che il suo processo appartiene a un attaccante? Il filtro URL che limitava i visitatori non dice nulla su una connessione che l'host del gateway apre verso la sottorete del database.
Togliete invece il processo applicativo, e l'autorità cambia forma: il ruolo expenses_app, i servizi che quel server può raggiungere e i file che quell'account può leggere. In entrambi i casi la porta d'ingresso può restare solo web mentre il confine del backend è assente. L'etichetta sulla porta d'ingresso non è quindi risposta a nessuna delle due domande.
Mappate l'autorità che ciascuna parte detiene davvero
Un contratto scritto come permessi previsti tende a ripetervi la progettazione. Scrivetelo come autorità detenuta, verifica che smentisce l'eccesso e proprietario di quella verifica, e ogni riga diventa verificabile. Questa tabella è una proposta per l'esempio precedente, non un'affermazione di prodotto:
| 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 proprietà segue l'autorità. Il team di identità possiede le asserzioni, il team della piattaforma di rete possiede i percorsi, il team applicativo possiede il ruolo del database, l'amministratore del database possiede il listener e le sue regole basate sull'host, e il proprietario della piattaforma possiede il piano di gestione. Un diniego senza proprietario è una frase in un documento, non un controllo.
La separazione impedisce anche il doppio conteggio. Una restrizione di porta non può esprimere un privilegio di tabella, e un ruolo del database non può impedire a un host di aprire un socket verso una sottorete non correlata.
Enumerate ciò che il gateway può raggiungere invece di affermarlo
Un'affermazione di confine vale quanto l'enumerazione che la sostiene. Sull'host del gateway, tre comandi coprono la selezione del percorso, una sonda dal vivo e la politica in uscita:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLeggete l'output in quest'ordine. Il percorso dice se 10.60.4.20 viene persino selezionato da quell'host; la sonda dice se il listener risponde; l'elenco delle regole mostra se la politica blocca il pacchetto o se non c'era mai nulla nel suo percorso.
Ripetete l'enumerazione dall'host dell'applicazione. Da lì il lato database è un'unica query eseguita come ruolo dell'applicazione:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Una connessione riuscita sotto un ruolo che non può leggere un altro schema è un risultato diverso da una connessione riuscita sotto un ruolo proprietario. Solo la seconda è un reperto.
Registrate i dinieghi, poi datate la revisione
L'accettazione si scrive come esiti e non come intenzioni: una sessione dipendente non può raggiungere il listener, l'host del gateway non può raggiungere una sottorete non correlata e il ruolo dell'applicazione non può creare un database. Ognuna è una verifica separata con un proprietario nominato e una data.
Mantenete monitoraggio, patch e ripristino raggiungibili attraverso il percorso di gestione progettato per loro. Un confine che blocca anche il suo proprietario diventa un'interruzione, e la prima risposta abituale a quell'interruzione è ampliare di nuovo la regola. La guida perimetrale della CISA chiede di limitare l'accesso in entrata e in uscita a porte e protocolli giustificati, incluso il traffico tra reti interne, che è la direzione avviata dal backend che la maggior parte dei diagrammi omette.
Datate la revisione e nominate il suo proprietario. Rieseguite l'enumerazione e la query sui privilegi dopo qualsiasi modifica all'immagine del gateway, alla tabella di routing o al ruolo dell'applicazione.