Le organizzazioni devono condividere in modo sicuro le identità digitali per consentire una collaborazione senza soluzione di continuità tra dipartimenti, filiali e partner esterni. La federazione di identità permette ad un'organizzazione di autenticare un utente e quindi di passare tale rivendicazione di autenticazione ad un'altra organizzazione, garantendo l'accesso alle risorse senza richiedere un login separato. Tuttavia, per questo processo di essere sicuro, l'organizzazione di base deve avere assoluta certezza che l'affermazione di identità che riceve è legittima e non è stata manomessa.

Questo articolo fornisce una guida completa per la distribuzione di PKI per la federazione di identità. Si muove oltre le definizioni di base per esplorare le decisioni architettoniche, le strategie di implementazione e le pratiche di gestione del ciclo di vita necessarie per costruire un modello di fiducia federato di produzione-ready. Se si sta collegando due organizzazioni con una semplice integrazione SAML o la costruzione di una federazione multi-partita complessa, la comprensione del ruolo di PKI è essenziale per mantenere una forte postura di sicurezza.

Il ruolo centrale di PKI nella fedeltà federata

La sfida principale della federazione di identità è la distribuzione e la verifica della fiducia. In un ambiente non federale, la fiducia è spesso stabilita attraverso segreti condivisi, come password o gettoni API. Questo approccio non scala attraverso confini organizzativi perché richiede la condivisione fuori banda e lo stoccaggio sicuro di segreti su entrambi i lati.

In una federazione basata su PKI, ogni organizzazione ottiene un certificato digitale da una CA di fiducia reciproca. Questo certificato lega l'identità dell'organizzazione a una coppia di chiavi crittografiche. Quando un utente autentica presso la propria organizzazione domestica (il provider di identità, o IdP) e richiede l'accesso a una risorsa presso un'organizzazione partner (il fornitore di servizi, o SP), l'IdP firma crittograficamente l'autenticazione verificando l'affermazione utilizzando la chiave privata.

  • Autorizzazione:[ L'affermazione è stata effettivamente emessa dall'organizzazione che sostiene di averlo emesso.
  • Integrità:[ L'affermazione non è stata modificata in transito tra le due organizzazioni.
  • Non-Ripudiazione:[ L'organizzazione emessa non può negare di aver emesso l'affermazione, che è essenziale per i percorsi di audit e la conformità.

PKI trasforma un complesso web di relazioni di fiducia in senso binomio in un modello di fiducia gerarchico gestibile, invece di gestire segreti condivisi con ogni partner, un'organizzazione deve solo fidarsi della CA radice. La CA, a sua volta, vouches per le identità di tutte le organizzazioni partecipanti. Questo cambiamento fondamentale rende la federazione di identità su larga scala operativamente fattibile e molto più sicuro.

Ricostruire i componenti PKI per la Federazione

Per distribuire efficacemente PKI per la federazione di identità, è necessaria una solida comprensione dei suoi componenti principali e dei loro ruoli specifici, che svolgono un ruolo distinta nel garantire l'integrità e la sicurezza del sistema generale.

Autorità di certificazione (CA) e la catena di fiducia

La CA è l'entità di fiducia che rilascia certificati digitali. In un contesto federato, il ruolo della CA è quello di verificare l'identità di un'organizzazione o dei suoi servizi prima di rilasciare un certificato. La fiducia nell'intero sistema deriva dalla Root CA. Le organizzazioni che partecipano alla federazione includono il certificato di Root CA nel loro trust store.

Autorità di registrazione (RA) e Proofing di identità

Prima di rilasciare un certificato, l'identità del soggetto deve essere verificata. La RA gestisce questo processo di verifica. Per la federazione di identità, il soggetto è spesso un'organizzazione o un servizio specifico (ad esempio login.salesforce.com). La RA esegue la prova di identità, che potrebbe comportare la convalida dei documenti legali, la verifica del controllo DNS, o la conferma della proprietà del dominio.

Autorità di convalida (VA) e Controllo di revoca

La federazione deve avere un meccanismo per verificare che un certificato sia ancora valido al momento dell'uso. Questo è il ruolo dell'Autorità di Validazione (VA). La VA fornisce controlli in tempo reale attraverso due metodi primari:

  • Certificate Revocazioni Liste (CRL): Un elenco periodicamente aggiornato dei numeri di serie dei certificati revocati. Il SP deve scaricare e controllare questa lista. CRL possono diventare grandi e introdurre la latenza.
  • Protocollo di stato del certificato online (OCSP):[] Un protocollo in tempo reale che permette al SP di interrogare la CA per lo stato di un certificato specifico.

In una federazione ad alta garanzia, le parti che si affidano devono verificare lo stato di revoca di ogni certificato loro presentato, compresi quelli utilizzati per firmare le asserzioni SAML o per stabilire connessioni TLS. Il mancato funzionamento di un'organizzazione compromessa può continuare ad operare all'interno della federazione.

Moduli di sicurezza hardware (HSMs)

Le chiavi private delle CA e degli IdP sono i gioielli corona della federazione PKI. Se un attaccante compromette una chiave privata, possono falsificare le identità e autenticare come qualsiasi organizzazione della federazione. HSMs forniscono hardware antimanomissione, indurito per la memorizzazione e la gestione di queste chiavi private. Assicurano che la chiave privata non esista mai in testo semplice al di fuori del confine sicuro della federazione di dati di produzione.

Architetto un modello di fiducia di organizzazione trasversale

La scelta dell'architettura di fiducia giusta è la decisione di progettazione più importante per una federazione basata su PKI. L'architettura determina come la fiducia scorre tra le organizzazioni, quanto è facile aggiungere nuovi partecipanti, e come il sistema gestisce la partenza o il compromesso di un membro.

Il modello di Bridge CA

Il modello Bridge CA è una delle architetture più efficaci per le federazioni di identità su larga scala. Invece di ogni organizzazione che si prefigge di un'organizzazione trasversale, tutti i partecipanti si affidano a una centrale e neutrale Bridge CA. La Bridge CA garantisce la certificazione tra le Root CA di ogni organizzazione partecipante, creando una topologia della fiducia. Il vantaggio chiave è la scalabilità: l'aggiunta di una nuova organizzazione richiede solo la certificazione incrociata con le politiche di Bridge CA, non con ogni membro di assistenza sanitaria esistente.

Modello di certificazione trasversale

Nel modello di certificazione incrociata, due organizzazioni scambiano e firmano direttamente i certificati Root CA, che stabiliscono un rapporto di fiducia bilaterale, che è semplice e diretto, rendendolo adatto a federazioni più piccole con un numero limitato di partner noti. Tuttavia, la sua complessità cresce esponenzialmente mentre più organizzazioni si uniscono, poiché ogni coppia di organizzazioni deve gestire il proprio accordo di certificazione incrociata.

Modello gerarchico

Un singolo Root CA si trova in cima, emettendo certificati a CA intermedie, che poi rilascia certificati a entità fogliari (organizzazioni o servizi), questo modello è altamente standardizzato e facile da implementare. L'inconveniente principale è che la Root CA diventa un unico punto di fiducia. In un contesto inter-organizzativo, può essere difficile per più organizzazioni indipendenti accettare il potere su una singola autorità.

Negozi fiduciari federati e scambio di metadati

Indipendentemente dal modello di fiducia scelto, la federazione ha bisogno di un meccanismo sicuro per la distribuzione di materiale di fiducia, che spesso assume la forma di negozi di fiducia e file di metadati.

  • Riserve di rotta:[] Una raccolta di certificati affidabili di Root e di CA intermedia. Ogni partecipante deve mantenere un negozio di fiducia aggiornato. L'operatore della federazione definisce quali CA sono incluse in questo negozio.
  • Scambio di dati:[] Protocolli come SAML utilizzano i file di metadati XML per descrivere le capacità e i endpoint di IdPs e SP. Questi file di metadati sono firmati digitalmente per garantire la loro integrità e contenere le chiavi e i certificati pubblici necessari per verificare le affermazioni.

Se un attaccante può iniettare un file di metadati fraudolento contenente il proprio certificato, può impersonare un'organizzazione legittima.

Integrazione PKI con protocolli della Federazione

Il modello di fiducia teorica deve essere implementato attraverso protocolli di federazione concrete. PKI è profondamente integrato nei protocolli più comuni: SAML, OAuth 2.0 e OpenID Connect.

Firma digitali SAML 2.0 e XML

SAML 2.0 è uno dei protocolli più maturi e ampiamente utilizzati per la federazione di identità aziendale. La sicurezza di SAML si basa fortemente sulla firma digitale XML (XMLDSIG). Quando un IdP genera un'affermazione SAML, utilizza la sua chiave privata per creare una firma digitale sul documento XML. Il SP, che ha il certificato pubblico di IdP (spesso ottenuto tramite metadati), verifica questa firma.

È importante notare che l'affermazione SAML contiene spesso gli attributi di identità dell'utente. Segnala l'affermazione assicura che questi attributi non siano stati modificati da un fornitore di servizi o da un fornitore di servizi dannoso. Senza un PKI forte, l'affermazione SAML è solo un reclamo senza alcuna prova verificabile di origine.

OAuth 2.0, OpenID Connect e mTLS

Mentre OAuth 2.0 e OpenID Connect (OIDC) sono più moderni e flessibili di SAML, si affidano anche a PKI in diverse aree chiave.

  • Autenticazione Client:[] Un'organizzazione che agisce come client OAuth 2.0 può dimostrare la sua identità utilizzando un metodo di backup PKI. Il metodo `tls client auth` (RFC 8705) richiede al cliente di presentare un certificato X.509 quando si stabilisce una connessione TLS al server di autorizzazione.
  • Firma:[[]] I simboli JSON Web (JWT) rilasciati da un fornitore OIDC sono firmati utilizzando JSON Web Signatures (JWS). Le chiavi pubbliche utilizzate per verificare queste firme sono distribuite tramite un terminale JSON Web Key Set (JWKS) .
  • TLS Mutual TLS (mTLS): mTLS è l'applicazione più diretta di PKI per la comunicazione inter-service. In una connessione mTLS, sia il client che il server devono presentare un certificato X.509 valido. Per la federazione di identità, mTLS può essere utilizzato per garantire i endpoint di scambio di token, l'utente info endpoint, o qualsiasi backend API sistemi di chiamata tra i sistemi.

Gestione del ciclo di vita in una Federazione

La gestione continua dei certificati è spesso una sfida operativa significativa: un certificato che scade, viene revocato o viene compromesso può causare un'interruzione del servizio o una violazione della sicurezza per l'intera federazione.

Gestione automatica dei certificati

La gestione manuale del certificato è incline a errori e non scala. L'industria si sta muovendo verso l'automazione utilizzando protocolli come ACME (Automatic Certificate Management Environment). ACME permette ai server di richiedere automaticamente e rinnovare i certificati da una CA senza intervento umano. Per i servizi interni e la comunicazione macchina-macchina in una federazione, strumenti come in Kubernetes possono automatizzare l'intero ciclo di vita, assicurando che i certificati sono sempre freschi e riducendo il rischio di scadenza.

Strategie di rivocazione

Quando un certificato è compromesso o un'organizzazione lascia la federazione, il certificato deve essere revocato. Le informazioni di revoca devono essere propagate a tutte le parti che si affidano in modo efficiente.

  • CRL Distribuzione:[[] La CA pubblica un CRL a intervalli regolari. Le parti in ripieno devono prendere questa lista. La sfida principale è la la latenza tra il tempo di revoca e la successiva pubblicazione CRL.
  • OCSP Stapling:[ Per le connessioni TLS, OCSP Stapling consente al server di presentare il certificato di aggiungere una risposta OCSP, impostata sul tempo, dalla CA. Questo rimuove il carico dal client per interrogare il rispondente OCSP e riduce la latenza.

Una politica di federazione dovrebbe incaricare intervalli massimi accettabili per la pubblicazione di CRL e la freschezza della risposta di OCSP.

Governance e Politica

La gestione del ciclo di vita dei certificati in tutte le organizzazioni indipendenti richiede un quadro politico chiaro, che include la definizione dei profili di certificazione (dimensioni chiave, algoritmi di firma, periodi di validità), la definizione di una dichiarazione di certificazione (CPS), e la definizione di ruoli e responsabilità per la CA, RA e partecipanti.

Considerazioni di sicurezza avanzate

Oltre alla distribuzione di base, ci sono strategie avanzate che possono migliorare significativamente la postura di sicurezza di una federazione di identità basata su PKI.

Certificati a breve distanza

Invece di affidarsi alle liste di revoca, un'organizzazione può rilasciare certificati con brevissime vite (ad esempio, ore o giorni) che minimizzano la finestra dell'opportunità se una chiave privata è compromessa e semplifica notevolmente la logica di revoca. Quando un certificato scade, un nuovo viene automaticamente richiesto tramite ACME. Questo approccio si allinea bene con i principi di Zero Trust, dove la fiducia viene costantemente rivalutata.

Certificato Pinning vs. CA Trust Stores

Il certificato Pinning è la pratica di associare un host al certificato specifico o alla chiave pubblica che si prevede di utilizzare. Questo protegge da una CA compromessa che emette un certificato fraudolento per il tuo dominio. Tuttavia, pinning è fragile e difficile da gestire. Per la federazione di identità, mantenere un CA Trust Store strettamente controllato è generalmente preferito. L'operatore della federazione controlla che le CA sono affidabili e se una CA è compromessa, può essere rimosso da tutti i certificati di fiducia.

Monitoraggio e rilevamento di anomalie

La federazione dovrebbe essere monitorata attivamente per un comportamento anomalo del certificato, che include il monitoraggio per l'emissione di certificati inaspettati, l'uso di algoritmi crittografici deboli e controlli di revoca non riusciti. I team di sicurezza dovrebbero analizzare i log della CA, del VA e dell'IDP/SP per rilevare potenziali attacchi.

Costruire una federazione di identità sicura è un'impresa complessa, ma PKI fornisce le basi più affidabili e scalabili per farlo. Architettare con cura il modello di fiducia, gestire rigorosamente i cicli di vita dei certificati, e integrare PKI profondamente con i protocolli di federazione, le organizzazioni possono creare un ambiente collaborativo che sia altamente funzionale e estremamente sicuro. Questo approccio non solo risolve la sfida tecnica dell'autenticazione cross-domain ma fornisce anche la forte conformità di governance e auditability necessaria per soddisfare le più severe esigenze regolamentari.