Inventariare l'identità di integrazione prima di ruotarla
Un account di servizio o una credenziale API rappresenta un percorso di accesso non interattivo, non semplicemente una stringa archiviata in un gestore di segreti. Prima di scrivere una procedura di rotazione, identificare il proprietario dell'integrazione, il tenant autorizzato, le operazioni consentite, ogni consumatore e il flusso di lavoro aziendale che dipende da esso. Una nuova credenziale con l'ambito sbagliato può aumentare l'esposizione anche se la rotazione stessa viene completata senza interruzioni. I requisiti dovrebbero pertanto affrontare congiuntamente i limiti di accesso e il ciclo di vita.
Questo articolo propone i requisiti per le integrazioni della piattaforma di autenticazione. Non afferma che EmailAuth supporti account di servizio, chiavi API con ambito, credenziali sovrapposte o qualsiasi particolare integrazione di gestione dei segreti. Nessuna credenziale è stata creata, visualizzata, trasmessa, revocata o testata. Linee guida sull'identità multi-tenant di Azure supporta la separazione dell'identità dall'autorizzazione e dai diritti delle risorse; la piattaforma effettiva deve documentare il proprio modello di accesso non interattivo supportato.
Definire l'autorità prevista più piccola
Creare una riga dell'inventario di integrazione contenente l'identità del servizio, lo scopo aziendale, l'associazione del tenant, l'ambito delle risorse, le operazioni consentite, il proprietario, le posizioni di distribuzione e il riferimento alle credenziali. Memorizza solo un riferimento a una posizione segreta approvata, non il valore della credenziale. Distinguere i report di sola lettura dalle esportazioni, dalle scritture di configurazione, dalla gestione degli utenti e dalle operazioni di fatturazione. Una credenziale amministrativa ampia non dovrebbe essere considerata necessaria semplicemente perché era conveniente durante un'integrazione iniziale.
Richiedere alla piattaforma di spiegare in che modo l'identità autenticata è legata a un tenant e in che modo ciascuna operazione controlla tale confine. Un parametro del tenant in un URL o nel corpo della richiesta non costituisce di per sé un'autorizzazione. Una credenziale utilizzata per un cliente non deve acquisire l'ambito di un altro cliente modificando un identificatore. Questi i criteri di accettazione proposti; non è stato analizzato alcun servizio in tempo reale e dai requisiti non si deduce alcuna capacità attuale del prodotto.
Sostituzione separata delle credenziali dalla riprogettazione dell'accesso
Una rotazione di routine dovrebbe normalmente preservare l'autorità approvata sostituendo il materiale segreto. Se la migrazione modifica anche i ruoli, l'ambito del tenant o l'accesso alle risorse, esaminare tali modifiche in modo esplicito. In caso contrario, una procedura definita manutenzione può nascondere un ampliamento dell'accesso. Registrare l'ambito vecchio e quello nuovo previsto utilizzando identificatori non segreti e confrontarli prima di qualsiasi passaggio autorizzato.
Scegli il tipo di credenziale supportato in base alla documentazione attuale della piattaforma e ai criteri organizzativi. Un account di servizio, una chiave API, un certificato o un'identità del carico di lavoro possono avere proprietà di emissione, scadenza e revoca diverse. Non dare per scontato che ogni integrazione offra credenziali di breve durata o che un gestore dei segreti modifichi automaticamente le credenziali nel servizio di destinazione. Il sistema target e ciascun consumatore devono essere coordinati in base alle loro effettive capacità.
Rotazione sovrapposta dell'ambito ai sistemi che la supportano
Tutorial sulla rotazione a doppia credenziale di Microsoft illustra uno specifico modello di archiviazione di Azure e Key Vault usando due credenziali. Spiega un meccanismo per alternare le credenziali durante l'aggiornamento del materiale segreto archiviato. Questa è la prova dello scenario documentato di Azure, non la prova che una piattaforma di autenticazione arbitraria supporti due chiavi API valide contemporaneamente o la stessa sequenza di rotazione.
Quando è supportata la sovrapposizione, il piano proposto dovrebbe identificare il riferimento della credenziale sostitutiva, i consumatori da migrare, la prova che ciascun consumatore utilizza la sostituzione e il punto in cui la vecchia credenziale viene revocata. La sovrapposizione può ridurre le interruzioni, ma lascia anche temporaneamente più di una credenziale utilizzabile. Limitarne la durata tramite un piano approvato anziché lasciare la vecchia credenziale attiva a tempo indeterminato. Se la sovrapposizione non è supportata, documenta l'interruzione prevista e il percorso di ripristino autorizzato invece di promettere un passaggio senza soluzione di continuità.
Verifica la migrazione prima di revocare il vecchio percorso
Definire prove che dimostrino l'uso efficace del sostituto senza esporlo. A seconda del fornitore effettivo, ciò potrebbe includere identificatori di credenziali non segreti nei registri approvati, osservazioni sullo stato dell'integrazione o eventi di controllo supportati. Una richiesta accettata da un lavoratore non dimostra che tutti i processi pianificati, tutti i lavoratori in background o tutti gli ambienti di ripristino di emergenza siano stati migrati. L'inventario deve tenere conto di ciascun consumatore o documentare esplicitamente il divario di copertura.
La revoca è un passaggio separato con la propria evidenza di esito. La rimozione di un segreto dalla configurazione di un'applicazione non dimostra che il servizio di destinazione lo abbia invalidato. Al contrario, la revoca a destinazione prima che tutti i consumatori migrano può interrompere i flussi di lavoro necessari. Il risponditore autorizzato deve verificare la disposizione del vecchio percorso attraverso prove supportate in un ambiente approvato. Questa bozza non esegue una richiesta utilizzando una credenziale vecchia o nuova.
Pianificare il fallimento e il recupero senza ripristinare l'esposizione alla cieca
Definire le condizioni di interruzione prima della modifica: ambito del tenant imprevisto, prove di audit mancanti, inventario dei consumatori incompleto o errori dopo la migrazione potrebbero richiedere la sospensione del cutover. Il ripristino dovrebbe distinguere un errore di distribuzione di routine dalla sospetta compromissione delle credenziali. Riutilizzare un segreto compromesso noto come un comodo rollback può reintrodurre proprio l'esposizione contenuta. Richiedere una decisione sulla sicurezza anziché trattare ogni credenziale precedente come materiale di ripristino sicuro.
Mantenere il piano libero da valori segreti. I registri e gli screenshot non devono rivelare intestazioni di autorizzazione, token o stringhe di connessione complete. Se materiale sensibile viene accidentalmente esposto, instradarlo attraverso il processo di incidente dell'organizzazione; non copiarlo in un canale di risoluzione dei problemi più ampio. Le prove della rotazione dovrebbero mostrare chi ha autorizzato l'azione, quale identità non segreta è cambiata, quali consumatori sono stati controllati e cosa riporta il servizio di destinazione sulla revoca.
Un foglio di lavoro per l'accettazione del ciclo di vita delle credenziali
Crea un foglio di lavoro con identità di integrazione, tenant, azioni consentite, riferimento segreto, elenco consumatori, identificatore di credenziali corrente dove sicuro, strategia di sostituzione, proprietario dell'approvazione, controlli di migrazione e controlli di revoca. Includere il modello di sovrapposizione supportato e la finestra di sovrapposizione massima pianificata come decisione interna, non come garanzia inventata del fornitore. Registrare la versione effettiva del provider o la data della documentazione utilizzata per progettare la sequenza.
Allegare una matrice di accesso che copra le operazioni di lettura, esportazione, scrittura e ciclo di vita consentite e negate su almeno due dispositivi tenant sintetici. La rotazione non deve modificare accidentalmente tali confini. Includere un controllo post-rotazione che attesti che l'accesso previsto funzioni ancora e che l'accesso non consentito rimanga negato. Si tratta di test difensivi proposti, non di risultati eseguiti o di autorizzazioni per sondare un tenant di produzione. Conservare tutte le prove operative originali contrassegnate come aperte finché un'esecuzione autorizzata non le conserva.
Diagnosi immaginaria: un lavoratore programmato trascurato
Un'integrazione di reporting fittizia prevede un lavoratore interattivo e un lavoro di aggregazione notturno. Il team aggiorna l'operatore interattivo con una credenziale sostitutiva e vede le richieste riuscite. Sta per revocare la vecchia credenziale quando la revisione dell'inventario rivela che il lavoro pianificato legge un riferimento segreto separato. Il controllo interattivo andato a buon fine non copriva il consumo notturno.
La risposta proposta è aggiornare il piano di migrazione, ottenere l'eventuale approvazione necessaria e verificare entrambi i consumatori prima di completare la revoca. Se si sospetta che le vecchie credenziali siano state compromesse, il proprietario dell'incidente potrebbe invece scegliere il contenimento immediato con un'interruzione controllata del servizio. In questo esempio fittizio non sono state coinvolte credenziali, lavoratori o interruzioni reali. Il suo scopo è quello di distinguere la copertura completa del consumatore da una richiesta accolta.
Richiedere le prove della piattaforma prima della pubblicazione
Un utile requisito di integrazione nomina i tipi di credenziali supportati, gli ambiti, l'associazione del tenant, l'autorità di emissione, il comportamento di sovrapposizione, la scadenza, la revoca e le prove di controllo. Dovrebbe indicare chiaramente le limitazioni anziché tradurre un tutorial generale sul cloud in una richiesta di funzionalità EmailAuth . Le impostazioni dimostrative dell'esercitazione di origine non rappresentano intervalli di rotazione universali o criteri organizzativi.
Il catalogo richiede una matrice di accesso e test negativi per letture, esportazioni, scritture tra tenant e modifiche del ciclo di vita dell'utente. Tali test rimangono non eseguiti. Rimangono aperti anche la revisione da parte di specialisti umani, l’applicabilità della fonte, i percorsi di produzione, l’accessibilità e il rilascio del proprietario. Questa bozza fornisce un modello operativo proposto e un esercizio fittizio, non credenziali, sovvenzioni di accesso o prova di una rotazione completata.