Accesso condiviso o account separati? Scegliere un modello di identità per le applicazioni self-hosted

Con la crescita dello stack, l'architettura di accesso diventa una decisione operativa

Una singola applicazione self-hosted può di norma essere gestita con account utente locali. Tuttavia, quando un team utilizza più applicazioni, la progettazione dell'accesso influisce su molto più della comodità degli utenti. Influisce su chi crea gli account, sulla rapidità con cui viene rimosso l'accesso, su dove gli amministratori mantengono l'accesso di recupero e su cosa accade se un servizio di accesso condiviso non è disponibile.

Un provider di identità condiviso per applicazioni self-hosted può ridurre il lavoro ripetitivo di gestione degli account. Può anche diventare una dipendenza critica: se il servizio di identità, il suo processo amministrativo o il suo processo di recupero si guastano, gli utenti potrebbero non riuscire ad accedere contemporaneamente a più servizi. La scelta giusta, quindi, non è automaticamente «centralizzare tutto». È il modello che il team può gestire e ripristinare in sicurezza.

Airbip gestisce l'infrastruttura cloud attorno ai carichi di lavoro delle applicazioni Docker distribuite, incluse automazione del routing e dei certificati TLS, verifiche DNS, gestione del ciclo di vita dei servizi e backup configurabili. Questi servizi infrastrutturali non scelgono la fonte di identità di un'applicazione, il modello di autorizzazione, il processo di recupero dell'account o la governance degli accessi. Restano decisioni del cliente, da prendere applicazione per applicazione.

• Considera l'architettura dell'identità come una decisione di progettazione operativa, non soltanto come una preferenza per la schermata di accesso.
• Valuta il probabile impatto di un'interruzione del servizio di identità prima di renderlo il punto di accesso a ogni applicazione.
• Assegna responsabili nominativi per le attività del ciclo di vita degli utenti, l'accesso privilegiato e le procedure di recupero.
• Mantieni separata la decisione sull'identità dalle decisioni relative a backup dell'applicazione, conservazione dei dati, gestione delle sessioni e autorizzazione dell'applicazione.

Parti dalla distinzione: autenticazione, autorizzazione e ruoli

L'autenticazione risponde alla domanda: «Questa persona può dimostrare di controllare l'autenticatore associato a questa identità?» NIST descrive l'autenticazione riuscita come quella che consente a un verificatore di asserire un identificatore, e facoltativamente degli attributi, al servizio a cui si accede.

L'autorizzazione è una decisione distinta: «Che cosa può fare qui questa persona autenticata?» Un'applicazione può usare le informazioni ricevute durante l'autenticazione per prendere tale decisione, ma necessita comunque di una propria logica di accesso. I ruoli a livello di applicazione esprimono quindi i permessi disponibili all'interno di tale applicazione, come un ruolo di amministratore, editor o sola lettura.

Questa distinzione evita un errore di progettazione comune. Un accesso centrale può stabilire chi è una persona in più applicazioni, ma non rende intrinsecamente coerenti i permessi tra di esse. La stessa persona può opportunamente essere amministratore in un sistema e avere accesso limitato in un altro. La documentazione ufficiale corrente di ciascuna applicazione dovrebbe essere la fonte di riferimento per ruoli, comportamento dei gruppi e qualsiasi integrazione di identità supportata.

• Autenticazione: verifica il controllo dell'autenticatore da parte del richiedente.
• Autorizzazione: determina l'accesso a un servizio o a una risorsa.
• Ruoli e gruppi: rappresentano permessi e responsabilità specifici dell'applicazione.
• Sessioni: regolano il modo in cui un browser o client autenticato resta connesso; richiedono controlli e revisioni propri.

I tre modelli di identità praticabili

Gli account locali separati implicano che ciascuna applicazione mantenga i propri utenti e metodi di autenticazione. Questo modello comporta un'amministrazione più ripetitiva, ma un'interruzione o un problema di configurazione in un'applicazione non impedisce automaticamente l'accesso al resto dello stack.

Un modello con provider di identità condiviso usa la federazione dove supportata: il provider di identità autentica la persona e invia un'asserzione all'applicazione che vi fa affidamento. L'applicazione verifica l'asserzione, crea una sessione autenticata e concede l'accesso alle proprie funzioni. La federazione può ridurre la necessità di autenticazioni separate in più applicazioni e centralizzare parti della gestione degli account.

Un modello ibrido combina i due approcci. Per esempio, un team può usare un provider di identità condiviso per le applicazioni che lo supportano e mantenere account locali attentamente controllati quando un'applicazione li richiede o quando è necessario un accesso amministrativo di emergenza. L'ibrido è spesso un modello operativo deliberato, non una migrazione incompleta.

• Account locali: minori dipendenze condivise; maggiore amministrazione degli account in ogni applicazione.
• Provider di identità condiviso: un processo di autenticazione principale; maggiore concentrazione del rischio operativo.
• Ibrido: accoglie le diverse capacità delle applicazioni preservando un percorso di fallback documentato.
• Non presumere che un prodotto supporti federazione, provisioning automatizzato, mappatura granulare dei gruppi o un protocollo specifico. Conferma la documentazione primaria corrente e la configurazione della tua distribuzione.

Quando gli account separati sono la scelta più sicura

Gli account separati sono spesso proporzionati per un team piccolo e stabile con un numero limitato di applicazioni, ingressi e uscite poco frequenti e nessuno incaricato di gestire un servizio di identità dedicato. In questa situazione, una piattaforma di identità centrale può aggiungere più lavoro di configurazione, recupero e monitoraggio di quanto ne elimini.

Questa scelta è sicura solo quando il lavoro ripetitivo è realmente gestibile. Gli account locali necessitano di un processo chiaro per nuovi ingressi, cambi di ruolo e uscite. Se la rimozione dell'accesso dipende dal fatto che qualcuno ricordi ogni applicazione, il modello può fallire silenziosamente man mano che lo stack si espande.

Applica il principio del privilegio minimo in ogni applicazione: concedi solo l'accesso richiesto per una responsabilità definita, limita gli account amministrativi e registra chi è responsabile di ogni ruolo. Un ambiente piccolo può usare un semplice registro e revisioni pianificate anziché una piattaforma di identità complessa, purché il registro sia mantenuto aggiornato.

• Scegli gli account locali quando il numero di utenti è ridotto e le modifiche agli account sono poco frequenti.
• Scegli gli account locali quando il team non ha la capacità di amministrare, proteggere e ripristinare un servizio di identità condiviso.
• Usa record di account univoci anziché un accesso condiviso del team, così le azioni possono essere attribuite e l'accesso può essere rimosso per una singola persona.
• Mantieni un inventario di ogni applicazione, del titolare dell'account, degli account privilegiati, del contatto per il recupero e della data di revisione.
• Assicurati che ogni amministratore critico disponga di un metodo di recupero documentato ed evita di progettare il recupero attorno a una sola persona.

Quando l'accesso condiviso è giustificato

L'autenticazione centralizzata diventa più convincente quando l'onboarding e l'offboarding avvengono frequentemente, quando il numero di applicazioni rende inaffidabile l'amministrazione ripetuta o quando l'organizzazione dispone già di controlli di identità maturi e di una chiara responsabilità amministrativa. Il vantaggio non consiste semplicemente in un minor numero di password; consiste in un modo più ripetibile per creare e rimuovere l'accesso ai servizi supportati.

La federazione non elimina l'applicazione che vi fa affidamento dal modello di accesso. NIST osserva che un account dell'applicazione federata deve essere predisposto prima che possa essere creata una sessione autenticata e che l'applicazione può disabilitare o terminare il proprio account locale indipendentemente dal provider di identità. Pianifica per entrambi i lati: il record di identità e l'account dell'applicazione o il record di autorizzazione.

Centralizza solo dove il vantaggio è concreto. Un'applicazione senza integrazione supportata, che necessita di un amministratore locale o ha un ciclo di vita diverso, può restare locale. Forzare ogni servizio attraverso un unico percorso di accesso può creare soluzioni alternative fragili e rendere poco chiara la responsabilità.

• Dai priorità all'accesso condiviso quando l'avvicendamento degli account rende soggetta a errori l'amministrazione manuale degli account locali.
• Verifica l'esatta opzione di integrazione, il comportamento dei ruoli e il metodo di provisioning degli account nella documentazione ufficiale prima di impegnarti in una progettazione.
• Definisci chi può amministrare il provider di identità, approvare gli accessi e modificare le assegnazioni dei ruoli applicativi.
• Documenta come viene revocato l'accesso sia presso il provider di identità sia in ciascuna applicazione che vi fa affidamento.
• Verifica l'effetto della non disponibilità del provider di identità sugli utenti normali e sugli amministratori.

Domande a cui rispondere prima di centralizzare l'autenticazione

Inizia dalla compatibilità, ma non fermarti lì. Per ogni applicazione, identifica dalla documentazione primaria corrente le opzioni supportate di autenticazione e federazione, la configurazione richiesta, il comportamento di provisioning degli account e il modo in cui funzionano le eccezioni locali. Le capacità dei prodotti possono variare in base al prodotto, all'edizione, alla versione e alla configurazione di distribuzione.

Successivamente, progetta l'amministrazione e il recupero. Il recupero dell'account è distinto dall'autenticazione ordinaria. NIST identifica approcci di recupero che includono codici di recupero salvati o emessi, contatti per il recupero, ripetizione della verifica dell'identità e metodi specifici dell'applicazione basati su un'analisi del rischio documentata. NIST raccomanda inoltre di incoraggiare gli utenti a mantenere almeno due mezzi di autenticazione separati per ridurre gli eventi di recupero.

Infine, decidi cosa accade se il percorso normale non è disponibile. Un account break-glass è un percorso di accesso amministrativo di emergenza, non una scorciatoia quotidiana per aggirare la governance. Dovrebbe avere un responsabile nominativo, un uso limitato, materiale di recupero protetto, una procedura di test documentata e una revisione dopo ogni utilizzo.

• Quali opzioni di autenticazione o federazione supporta attualmente ciascuna applicazione?
• Chi è responsabile del tenant o servizio del provider di identità, dei suoi account privilegiati e delle modifiche alla sua configurazione?
• Quali account applicativi devono ancora esistere localmente e perché?
• Come vengono creati i nuovi utenti, approvate le modifiche di ruolo e rimossi gli utenti che lasciano l'organizzazione?
• Qual è il percorso break-glass se il provider di identità, un account amministratore o un autenticatore non è disponibile?
• Chi detiene i contatti o il materiale di recupero e come viene protetto e testato tale accesso?
• Come vengono terminate o riautenticate le sessioni quando il rischio o le modifiche di ruolo lo richiedono?
• Quali evidenze dimostreranno che gli accessi e i permessi sono stati revisionati?

L'autenticazione centralizzata non crea permessi coerenti

Un provider di identità condiviso può offrire a una persona un'unica esperienza di autenticazione nelle applicazioni supportate. Non definisce automaticamente ciò che quella persona può fare dopo l'accesso. L'autorizzazione e la determinazione dell'accesso restano decisioni dell'applicazione, e applicazioni diverse possono interpretare ruoli, gruppi e attributi in modi diversi.

Evita di assegnare ampi diritti amministrativi solo perché un utente ha effettuato con successo l'accesso tramite il servizio centrale. Definisci invece una matrice di accesso per ogni applicazione: responsabilità lavorativa, ruolo applicativo, approvatore, titolare dell'account e frequenza di revisione. Dove è disponibile la mappatura di gruppi o attributi, verifica il comportamento effettivo nella documentazione corrente del prodotto e, ove possibile, testalo con account non di produzione.

Anche i livelli di autenticazione esterni possono avere un ruolo circoscritto. Per esempio, Traefik ForwardAuth delega l'autenticazione a un servizio esterno e consente l'accesso quando quel servizio restituisce una risposta 2XX. Questo descrive un filtro di autenticazione; non stabilisce di per sé ruoli interni all'applicazione, permessi sui dati o controlli del ciclo di vita.

• Mantieni definizioni dei ruoli specifiche per applicazione anche quando l'autenticazione è condivisa.
• Richiedi un'approvazione esplicita per i ruoli privilegiati.
• Rivedi le mappature da gruppo a ruolo ogni volta che cambia la configurazione dell'identità o dell'applicazione.
• Non considerare un filtro di autenticazione del reverse proxy come un sistema completo di autorizzazione.
• Mantieni nel perimetro i controlli delle sessioni e le regole di accesso ai dati come aspetti separati della sicurezza applicativa.

Gestisci il modello con evidenze, revisioni e responsabilità documentate

Qualunque modello tu scelga, mantieni un registro delle identità applicazione per applicazione. Registra la fonte di identità, il proprietario dell'applicazione, gli account privilegiati, le eccezioni per gli account locali, i contatti per il recupero, il metodo di provisioning ordinario, il metodo di deprovisioning e le evidenze dell'ultima revisione dei permessi. Ciò offre a un team in crescita un record operativo verificabile senza presumere automazioni non supportate.

Organizza le revisioni attorno a nuovi ingressi, cambi di ruolo e uscite. A un nuovo ingresso serve solo l'accesso approvato necessario per iniziare a lavorare. Per un cambio di ruolo, i vecchi diritti devono essere rivalutati al variare delle responsabilità, non semplicemente aggiunti a nuovi diritti. Per un'uscita, è necessaria la rimozione o disabilitazione tempestiva dell'accesso attraverso ogni percorso pertinente, incluse eccezioni locali e account privilegiati. Stabilisci una cadenza in base al volume di cambiamenti e al rischio, quindi conserva le evidenze che la revisione è avvenuta e che le eccezioni sono state risolte.

Il Cybersecurity Framework 2.0 di NIST evidenzia la governance attraverso ruoli, responsabilità, autorità, policy e supervisione. Applica questo principio in modo pratico: qualcuno dovrebbe essere responsabile del servizio di identità, qualcuno del modello di autorizzazione di ciascuna applicazione e i percorsi di escalation dovrebbero essere noti prima che si verifichi un blocco dell'accesso o un'uscita.

L'hosting gestito di applicazioni Docker può ridurre l'amministrazione dell'infrastruttura attorno ai servizi distribuiti. Non sostituisce l'ingegneria delle identità né la governance delle identità aziendali. Se l'integrazione con directory, gli obblighi normativi, l'alta disponibilità o i requisiti formali di garanzia dell'identità superano la capacità del tuo team, usa un servizio di identità specializzato o un accordo di hosting enterprise invece di considerare una piattaforma generale gestita per applicazioni come una soluzione completa di gestione delle identità.

• Crea e mantieni un registro delle identità per ogni applicazione.
• Rivedi l'accesso dopo le modifiche di ruolo, non solo durante gli audit periodici.
• Rivedi gli account privilegiati più attentamente degli account ordinari.
• Documenta le eccezioni per gli account locali e rimuovile quando non sono più giustificate.
• Verifica le procedure di recupero e break-glass con una cadenza pianificata; registra risultati e azioni correttive.
• Usa la documentazione ufficiale delle applicazioni e dei provider di identità come base per le decisioni di configurazione e controllo.
• Rivaluta il modello quando cambiano il numero di applicazioni, il turnover del personale, la sensibilità dei dati o i requisiti operativi.