Quali componenti di un’applicazione self-hosted necessitano dell’accesso a Internet? Checklist per la mappatura dell’esposizione

Perché “accessibile pubblicamente” non è un requisito di deployment completo

“L’app deve essere pubblica” può significare cose molto diverse. Può voler dire che chiunque debba poter caricare un sito web, che soltanto dipendenti nominati debbano poter accedere da qualunque luogo, che un sistema partner debba inviare webhook oppure che l’applicazione debba semplicemente chiamare un’API esterna. Questi requisiti comportano decisioni diverse in merito all’esposizione di rete.

Considera la raggiungibilità inbound e la connettività outbound come decisioni separate. Nel networking Docker, un container può effettuare connessioni in uscita quando il suo host dispone di accesso a Internet, mentre una porta del container normalmente non è raggiungibile dall’esterno dell’host a meno che non sia pubblicata o instradata deliberatamente. Un’applicazione può quindi richiedere accesso a Internet senza richiedere una porta applicativa raggiungibile pubblicamente.

L’obiettivo non è rendere ogni componente privato o ogni componente pubblico. L’obiettivo è autorizzare esplicitamente ciascun flusso di dati, esporre solo i punti di ingresso necessari e registrare il motivo per cui ciascuno esiste. Questo è in linea con l’esito del NIST Cybersecurity Framework 2.0 relativo al mantenimento di rappresentazioni delle comunicazioni di rete e dei flussi di dati interni ed esterni autorizzati.

• Sostituisci “pubblico” con una dichiarazione specifica: chi si connette, da dove, a quale hostname, usando quale protocollo e per quale scopo.
• Separa l’accesso dal browser, le richieste machine-to-machine in ingresso, le chiamate in uscita e l’accesso degli amministratori.
• Decidi se ciascun flusso è su Internet pubblico, limitato a indirizzi IP noti, solo su rete privata o non consentito.
• Registra i dati scambiati in ciascun flusso, in particolare credenziali, dati personali, record dei clienti, file e token API.

Inizia con una mappa dell’esposizione: utenti, amministratori, integrazioni e servizi di supporto

Una mappa dell’esposizione è un inventario pratico dei percorsi di comunicazione consentiti dell’applicazione. Costruiscila prima di scegliere domini, aprire regole firewall o pubblicare porte dei container. Dovrebbe coprire più della schermata principale dell’applicazione: servizi di supporto, strumenti amministrativi, sistemi di identità, provider email e destinazioni di monitoraggio possono tutti creare dipendenze di rete.

Inizia elencando asset e attori. Il NIST CSF 2.0 considera software, servizi, sistemi, dati e servizi dei fornitori come asset che devono essere identificati e gestiti. Per un deployment self-hosted, ciò significa documentare sia i tuoi componenti sia i servizi esterni che essi contattano.

Poi traccia frecce direzionali. Ogni freccia dovrebbe avere un responsabile e una decisione: consentita, limitata, solo privata o rifiutata. Questo rende visibili fin dall’inizio le ipotesi nascoste, ad esempio un workflow di automazione che deve ricevere un webhook da un fornitore oppure una dashboard interna che si presumeva raggiungibile da ogni rete dei dipendenti.

• Utenti: visitatori pubblici, clienti, dipendenti, collaboratori esterni, utenti mobili e account di servizio.
• Amministratori: amministratori dell’applicazione, amministratori dell’infrastruttura e personale di supporto.
• Integrazioni inbound: webhook, client API, callback del provider di identità e sistemi partner.
• Integrazioni outbound: invio email, provider di identità, API esterne, download di software, download di modelli e destinazioni di monitoraggio.
• Servizi di supporto: database, cache, code, object storage, servizi di ricerca, reverse proxy e dashboard amministrative.
• Per ogni flusso, acquisisci origine, destinazione, protocollo e porta, hostname, direzione, metodo di autenticazione, classificazione dei dati, responsabile e giustificazione aziendale.

Classifica l’accesso inbound: interfaccia web pubblica, utenti autenticati, endpoint partner e ricevitori di webhook

L’accesso inbound è ciò che la maggior parte dei team intende per esposizione, ma dovrebbe essere suddiviso in classi distinte. Un’interfaccia pubblica di marketing o pubblicazione ha un profilo di rischio diverso da un’applicazione riservata ai dipendenti. Un ricevitore di webhook può dover accettare richieste da un sistema esterno anche quando nessuna interfaccia rivolta alle persone dovrebbe essere ampiamente disponibile.

Usa il reverse proxy come punto di ingresso inbound intenzionale. Nel modello di Traefik, gli entry point ricevono traffico TCP o UDP, i router corrispondono alle richieste in arrivo e i servizi ricevono il traffico backend instradato. Questo supporta un progetto in cui il proxy accetta solo traffico approvato, mentre i container dell’applicazione restano dietro di esso.

Quando un endpoint è usato solo da parti note, documenta se una regola basata su IP è adatta in aggiunta all’autenticazione a livello applicativo. Traefik offre un meccanismo di allowlist IP che accetta o rifiuta le richieste prima che raggiungano un backend. Questo può ridurre l’esposizione non necessaria, ma dipende da indirizzi sorgente stabili e identificati correttamente e non dovrebbe essere considerato un sostituto di un’autenticazione appropriata.

• Interfaccia web pubblica: destinata a visitatori non autenticati; esponi solo le route web e l’hostname necessari.
• Accesso di utenti autenticati: destinato a clienti o dipendenti; definisci identità, accesso, sessione e requisiti di autorizzazione nel progetto applicativo.
• Endpoint API partner: definisci il partner, il metodo di autenticazione, la rete sorgente prevista, le aspettative sul rate e le route esatte.
• Ricevitore di webhook: definisci mittente, convalida della firma o dell’autenticazione, route, dati del payload attesi e gestione degli errori.
• Interfaccia amministrativa: classificala separatamente dall’applicazione principale; non presumere che debba risiedere sull’hostname pubblico.
• Rifiuta l’esposizione catch-all: una porta o un hostname raggiungibile dall’esterno dovrebbe avere uno scopo e un responsabile nominati.

Identifica le dipendenze outbound prima di presumere che l’applicazione possa funzionare in privato

Un accesso inbound privato non significa che un’applicazione non abbia dipendenze da Internet. Molti carichi di lavoro aziendali, di automazione e di IA devono avviare connessioni verso servizi esterni all’host. Questi possono includere servizi di invio email, provider di identità, API di terze parti, fonti di pacchetti, download di modelli o destinazioni di monitoraggio.

Per ogni dipendenza, determina se è richiesta durante l’installazione, all’avvio, in base a una pianificazione o durante la normale attività degli utenti. Questa distinzione è importante negli ambienti soggetti a restrizioni. Un download una tantum di software o modelli può essere gestito diversamente da una connessione sempre attiva a un provider di identità o a un’API aziendale esterna.

Non descrivere l’accesso outbound come un’unica autorizzazione generale. Identifica l’hostname o il servizio di destinazione, il protocollo, lo scopo operativo, i dati inviati e ricevuti, la credenziale utilizzata e il comportamento di fallback quando la destinazione non è disponibile. Consulta la documentazione ufficiale dell’applicazione e dell’integrazione specifiche, poiché le dipendenze variano in base al prodotto e alla configurazione.

• Invio email: identifica il provider, il metodo di connessione, l’identità del mittente e se l’applicazione deve inviare reimpostazioni della password, notifiche o messaggi di workflow.
• Provider di identità: identifica endpoint di autenticazione, endpoint token, dettagli dell’emittente e se il login smette di funzionare quando il provider non è raggiungibile.
• API esterne: elenca ogni provider separatamente, i dati scambiati, l’approccio per l’archiviazione delle credenziali e se le chiamate sono attivate dagli utenti o automatizzate.
• Download di pacchetti, plugin o modelli: stabilisci se l’accesso a Internet è necessario solo durante configurazione o aggiornamenti, oppure regolarmente in fase di esecuzione.
• Monitoraggio e segnalazione degli errori: stabilisci quali dati di telemetria o eventi lasciano l’ambiente e chi approva tale trasferimento.
• Controlli degli aggiornamenti e chiamate relative alle licenze: verificali direttamente nella documentazione ufficiale del fornitore anziché presumere che siano necessari o assenti.

Mantieni privati per impostazione predefinita i servizi dati

Un database, una cache, una coda, un object store o un servizio di ricerca è generalmente un componente di supporto, non un prodotto esposto a Internet. Parti da un accesso solo privato e aggiungi un percorso soltanto quando esiste una ragione operativa documentata. In una configurazione Docker bridge, i servizi connessi all’host o alla stessa rete possono comunicare come configurato, mentre le porte dei container non sono accessibili dall’esterno dell’host per impostazione predefinita, salvo che siano pubblicate o altrimenti instradate deliberatamente.

Presta particolare attenzione alla pubblicazione per comodità. Docker documenta che la pubblicazione di una porta senza specificare un indirizzo host la associa per impostazione predefinita a tutti gli indirizzi dell’host, il che può rendere il servizio raggiungibile dall’esterno. Se un servizio è destinato solo all’host locale nello scenario NAT documentato, associarlo al loopback è un modo per impedire agli host remoti di accedere a quella porta pubblicata.

I piani di controllo amministrativi meritano lo stesso trattamento privato per impostazione predefinita. Traefik avverte che la sua API e dashboard di produzione possono esporre elementi di configurazione, compresi dati sensibili, e raccomanda di limitare la propria porta API alle reti interne. Applica questo principio anche alle interfacce di amministrazione dell’applicazione, alle interfacce di gestione dei container e agli strumenti di osservabilità.

• Database: consenti l’accesso solo dai componenti dell’applicazione e dai percorsi di manutenzione approvati.
• Cache e code: mantienile su reti private; non esporle soltanto per semplificare il troubleshooting.
• Object storage e servizi file interni: definisci quali componenti dell’applicazione richiedono accesso e come interagiscono con essi i backup.
• Servizi di ricerca, vettoriali e di supporto all’IA: documenta se sono backend interni oppure API intenzionalmente esposte ad altri sistemi.
• Dashboard del proxy, pannelli amministrativi dell’applicazione e piani di controllo dell’infrastruttura: usa percorsi di accesso separati e limitati.
• Prima del lancio, esamina ogni porta pubblicata e conferma il suo binding host, i client previsti e il responsabile.

Verifica i casi limite comuni che modificano il progetto di accesso

Diversi dettagli di deployment si scoprono facilmente tardi, dopo che sono già stati scelti un hostname o una policy firewall. Affrontali presto perché possono determinare se è necessario un hostname pubblico, un percorso di callback stabile o una particolare sorgente di rete.

OAuth è un esempio chiave. Gli URL di redirect e callback sono requisiti di deployment, non impostazioni estetiche. RFC 9700 richiede ai server di autorizzazione di usare una corrispondenza esatta di stringa rispetto agli URI di redirect preregistrati, salvo la gestione localhost specificata per le app native. Una modifica di schema, hostname, percorso o barra finale può quindi interrompere il login.

Proteggi anche il percorso di callback. RFC 9700 avverte che gli endpoint URI di redirect non devono fungere da open redirector. Identifica inoltre un rischio quando le pagine che gestiscono le risposte OAuth collegano pagine controllate da un attaccante o caricano contenuti di terze parti che potrebbero divulgare l’URL della risposta di autorizzazione attraverso l’header Referer. Mantieni intenzionalmente circoscritta la gestione del callback ed evita contenuti di terze parti incorporati non necessari su quella pagina.

• OAuth e SSO: conferma l’esatto URL esterno, protocollo, hostname e percorso di callback da registrare con il provider di identità.
• Contenuti incorporati: identifica iframe, script, immagini o widget che si connettono a terze parti, in particolare sulle pagine di risposta all’autenticazione.
• Client mobili e desktop: conferma se richiedono un endpoint pubblico, un hostname fisso, la gestione localhost o un percorso su rete privata.
• Allowlist IP: convalida gli indirizzi sorgente reali dopo aver considerato intermediari, NAT, reti di distribuzione dei contenuti o infrastruttura partner.
• Email in ingresso o trasferimenti di file: determina se sono consegnati direttamente all’applicazione o recuperati in uscita da un altro servizio.
• WebSocket, streaming e connessioni di lunga durata: verifica i requisiti del proxy e dell’applicazione nella documentazione ufficiale anziché presumere che i normali valori predefiniti HTTP siano sufficienti.

Domande da verificare nella documentazione ufficiale dell’applicazione prima del deployment

La documentazione dell’applicazione è l’autorità per i requisiti specifici del prodotto. Non dedurre che un’applicazione supporti un deployment privato, un particolare comportamento del proxy, un provider SSO o un modello di webhook soltanto perché un’altra applicazione lo fa. Conferma i requisiti rispetto alla documentazione ufficiale della versione e della configurazione che prevedi di usare.

Le risposte dovrebbero essere acquisite nella mappa dell’esposizione e riviste quando cambiano le integrazioni. Se la documentazione lascia irrisolta una domanda, trattala come un rischio di implementazione anziché colmare la lacuna con un’ipotesi.

Questa verifica è particolarmente importante per le applicazioni che combinano un’interfaccia web con worker in background, motori di automazione, servizi di modelli IA o più container di supporto. L’interfaccia browser visibile è spesso solo una parte del progetto operativo.

• Quali porte e protocolli inbound sono necessari, se presenti, e quale componente termina TLS?
• L’applicazione può operare dietro un reverse proxy e richiede impostazioni di trusted proxy o URL esterno?
• Quale URL canonico o di base richiede l’applicazione?
• Quali route devono ricevere webhook, callback OAuth, assertion SSO o richieste API partner?
• Quali hostname o categorie di servizi outbound sono necessari per il normale funzionamento, la configurazione, gli aggiornamenti, le email, l’identità, il monitoraggio o le integrazioni opzionali?
• Quali servizi dati sono necessari e le loro porte devono restare private?
• Sono necessari processi worker o container separati e cosa devono poter raggiungere?
• Quali dati di backup, posizioni di archiviazione e passaggi di ripristino sono necessari? Airbip offre backup configurabili giornalieri, settimanali e mensili, ma il proprietario dell’applicazione deve comunque decidere quali dati rientrano nell’ambito e testare procedure di ripristino appropriate al proprio ambiente.

Integra domini, TLS e reverse proxy nel progetto senza esporre servizi non necessari

Scegli i domini dopo aver identificato i punti di ingresso previsti. Un hostname dovrebbe rappresentare uno scopo di accesso deliberato, come un’applicazione rivolta agli utenti, un endpoint webhook con ambito ristretto o un percorso di amministrazione con restrizioni aggiuntive. Evita di creare nomi DNS pubblici per servizi interni soltanto perché sono comodi da ricordare.

Anche la convalida dei certificati TLS fa parte del progetto di esposizione. Con la convalida HTTP-01 di Let’s Encrypt, l’autorità di certificazione recupera un file di challenge all’hostname e la challenge HTTP-01 è limitata alla porta 80. Può essere appropriata per un endpoint web pubblico, ma è un requisito concreto di raggiungibilità da pianificare. La convalida DNS-01 di Let’s Encrypt può convalidare nomi i cui server web non sono esposti a Internet pubblico, perché la convalida avviene tramite un record TXT DNS.

Un reverse proxy permette a un team di rendere il proxy — e non ogni componente dell’applicazione — il perimetro pubblico selezionato. Può instradare hostname e percorsi approvati ai servizi backend mentre le porte backend restano private. Questo non rende automaticamente sicura un’architettura; il team necessita comunque di configurazione corretta dell’applicazione, controlli di accesso, proprietà DNS, rinnovo dei certificati e controllo delle modifiche.

Airbip distribuisce le applicazioni del catalogo come workload Docker su server cloud Airbip e automatizza routing e certificati TLS tramite Traefik e Let’s Encrypt. I clienti possono usare un sottodominio Airbip o un dominio personalizzato compatibile. Queste capacità sono utili quando il progetto documentato richiede un endpoint applicativo pubblico gestito, ma non eliminano la necessità di decidere quali route e flussi di dati siano approvati.

• Assegna un unico responsabile per ogni zona DNS e hostname.
• Documenta se la convalida dei certificati usa un percorso HTTP pubblico o la convalida DNS, in base al progetto di accesso.
• Esponi gli entry point del reverse proxy richiesti dai servizi pubblici approvati; mantieni private le porte dei servizi backend.
• Usa hostname separati o route attentamente circoscritte quando le funzioni pubbliche e limitate non possono essere separate in modo pulito all’interno dell’applicazione.
• Verifica il risultato visibile dall’esterno al di fuori della rete del server, non solo dall’host stesso.
• Esamina le responsabilità relative al rinnovo dei certificati e alle modifiche DNS come parte della titolarità operativa.