Un firewall tra porte non è un confine di host

Il sito web risponde sulla 443, la VPN risponde sulla 1194, il firewall consente esattamente quelle due, e la revisione passa. Nulla in quella sequenza ha chiesto cosa può leggere il lavoratore web o quali file può riscrivere. Un lavoratore compromesso non ha bisogno di una porta aperta se riesce a raggiungere un socket di controllo o una directory di configurazione scrivibile. Il confine è l'autorità, e gli ascoltatori sono solo la parte facile da vedere.

Un nome di servizio separato è un'etichetta; un'identità separata è una proprietà di sicurezza.

Contate l'autorità del lavoratore, non le porte

Partite dall'utente di esecuzione, dai suoi gruppi, dalle sue capacità e dalla sua vista del filesystem. Un account di servizio che appartiene per caso a un gruppo VPN può leggere materiale di chiave senza alcuna porta aperta. I mount scrivibili sono l'altra metà: caricamenti e cache devono stare lontani dai file di policy e dai segreti, e una directory scrivibile condivisa inutilmente vanifica una denominazione ordinata. Verificate il processo che eseguirebbe l'operazione, perché un genitore privilegiato e lavoratori non privilegiati non condividono un'unica autorità.

Che una chiave VPN sia leggibile all'avvio del demone non significa che il lavoratore web ne abbia bisogno. Separate la lettura compiuta dal demone dall'accesso concesso all'applicazione.

Socket che concedono più di quanto sembri

Alcuni endpoint sono API amministrative vestite da flusso di metriche. L'interfaccia di gestione della VPN può cambiare sessioni, disconnettere client e leggere lo stato. Il socket del runtime dei container è ancora più ampio: accedervi equivale di fatto al controllo dell'host, ben oltre ciò che serve a un'applicazione web. Nessuno dei due appartiene all'insieme di mount di un'applicazione ordinaria, e nessuno dei due compare quando contate le porte in ascolto.

Vincolare un ascoltatore di gestione a un indirizzo locale è un inizio, non una restrizione completa, perché ogni percorso d'ingresso verso quell'indirizzo conta ancora. Consentite solo le origini e le interfacce previste.

I container condividono un kernel

I container aggiungono confini di processo, filesystem e rete, e condividono un kernel con l'host. Ciò rende decisive le scelte di capacità, i mount dell'host e l'accesso al demone: montare segreti dell'host o concedere controllo privilegiato del runtime cancella il confine che l'etichetta del container suggerisce. VM separate danno davvero kernel ospiti separati, mentre l'hypervisor, le identità amministrative, lo storage e i backup restano condivisi. Scegliete il confine la cui configurazione e i cui aggiornamenti hanno un proprietario nominato.

Una disposizione più elaborata che nessuno mantiene è peggiore di una semplice che viene davvero revisionata.

Verificate il diniego, poi il servizio

Usate controlli approvati nel contesto reale del lavoratore per confermare che non può modificare la policy VPN, leggere segreti non necessari né toccare l'interfaccia di gestione. Una lettura riuscita come amministratore non verifica nulla su quel diniego. Poi verificate il sito web, un'operazione VPN ordinaria consentita, e cosa succede a ciascuno al riavvio. Conservate un percorso di ripristino che non dipenda dalla riparazione della VPN, così un errore resta recuperabile.

Entrambi i ruoli condividono ancora CPU, memoria, capacità di uplink e eventi di manutenzione. Queste risorse condivise fanno parte del piano anche quando il confine di autorità è pulito.

Registrate cosa può fare ciascun processo, cosa fallisce se si ferma e quale confine resta condiviso. Il conteggio delle porte non è quel registro.