Uno scenario quotidiano possibile: un modulo continua a essere visualizzato, ma l’interfaccia a valle non accetta più richieste. Oppure un’importazione notturna si ferma perché l’autenticazione non è più valida. Queste dipendenze spesso emergono solo quando il processo aziendale non viene eseguito.
Una credenziale API richiede quindi più di un archivio sicuro. Responsabilità, validità, procedura di sostituzione e verifica del funzionamento effettivo vanno insieme. Vale per API key, credenziali client OAuth, account di servizio e certificati, ciascuno con regole diverse.
Scadenza, rotazione e revoca sono eventi diversi
Una scadenza fissa può impedire tecnicamente l’ulteriore utilizzo. Una regola di rotazione stabilisce invece quando sostituire una credenziale. Può essere imposta dal fornitore o concordata operativamente. La revoca termina un’autorizzazione per una ragione concreta e può riguardare anche una credenziale non ancora scaduta.
Non tutte le chiavi hanno automaticamente la stessa durata. Google documenta ad esempio che le chiavi degli account di servizio create dall’utente non scadono per impostazione predefinita; apposite policy organizzative possono modificarlo. I client secret Microsoft Entra hanno invece una validità definita. Si registra la regola dell’emittente effettivo, senza presumere lo stesso intervallo per tutti i servizi.
In OAuth, access token, eventuale refresh token e credenziali dell’applicazione sono elementi distinti. Nell’inventario i loro cicli di vita non vanno riuniti in un’unica «API key». Anche l’identità di un account di servizio è diversa dalla singola chiave associata.
L’inventario richiede responsabilità, non segreti in chiaro
Per ogni credenziale d’integrazione importante si registrano almeno servizio, progetto, processo interessato, emittente e tipo. Si aggiungono responsabile o ruolo, sostituto e percorso di escalation raggiungibile. Chi riceve un avviso deve sapere quale processo aziendale ne dipende.
- Regola: Data di emissione, scadenza effettiva o assenza esplicita di scadenza, rotazione prevista e possibili modifiche del fornitore.
- Dipendenze: Applicazioni, job, installazioni e ambienti separati che usano la credenziale.
- Archiviazione: Riferimento al deposito di segreti approvato e alla gestione competente; nessun valore grezzo nell’inventario.
- Sostituzione: Procedura di prova, anticipo, autorizzazione, ritorno e data dell’ultimo test riuscito.
Una data nel deposito di segreti e la validità tecnicamente applicata dall’emittente si verificano separatamente. Aggiornare un metadato non rinnova automaticamente la credenziale presso il fornitore.
Avvisare presto e verificare il funzionamento reale
L’avviso di scadenza deve lasciare tempo sufficiente per autorizzazione, predisposizione e test. L’anticipo dipende da fornitore, rischio e impegno organizzativo. Un destinatario senza sostituto o un avviso instradato sulla stessa integrazione interessata crea una dipendenza inutile.
Si osserva anche se il processo atteso funziona: le richieste arrivano? L’importazione gira? La richiesta al modello prevista può essere elaborata? Tassi di errore, esecuzioni mancanti e test riproducibili possono rilevare anomalie anche senza scadenze vicine. La verifica dovrebbe generare meno dati e costi aggiuntivi possibile.
Una chiamata fallita non significa automaticamente una chiave scaduta. Permessi, quote, stato di fatturazione o pagamento, modifiche del fornitore e raggiungibilità tecnica si esaminano separatamente. Errore concreto e impatto determinano l’azione successiva.
| Evento | Significato | Preparazione adatta |
|---|---|---|
| Scadenza tecnica | Una credenziale termina secondo la regola dell’emittente. | Verificare la data, sostituire in tempo e provare la funzione. |
| Rotazione prevista | Una credenziale esistente viene sostituita secondo piano. | Conoscere tutti i sistemi utilizzatori, verificare passaggio e ritorno. |
| Revoca o ritiro | Un’autorizzazione viene terminata intenzionalmente. | Considerare motivo, credenziali interessate e operazioni in corso. |
| Altro errore d’integrazione | Ad esempio permessi, quota, pagamento o raggiungibilità. | Esaminare separatamente causa concreta e processo aziendale. |
Pianificare la sostituzione come processo unitario
Se il fornitore supporta più credenziali valide contemporaneamente, si può preparare la nuova mentre la precedente funziona ancora. Microsoft descrive questo principio ad esempio per risorse con due chiavi. È una possibilità specifica del fornitore, non una promessa generale per ogni API.
- Preparare: Verificare permessi e tutti gli utilizzatori, predisporre la nuova credenziale nel deposito sicuro previsto.
- Testare: Verificare le azioni realmente necessarie con la nuova credenziale in un ambiente di test adatto o con perimetro controllato.
- Commutare: Aggiornare ordinatamente applicazioni e job interessati; considerare comportamento di caricamento ed eventuali cache.
- Osservare: Controllare funzionamento e andamento degli errori. Verificare se un utilizzatore trascurato richiede ancora la vecchia credenziale.
- Concludere: Revocare la vecchia credenziale dopo il passaggio confermato e aggiornare inventario e documentazione operativa.
Se è valida una sola credenziale alla volta, il cambio richiede un coordinamento più preciso. Può essere utile una finestra di manutenzione concordata. Il ritorno si definisce prima; una vecchia credenziale compromessa o revocata non va semplicemente riattivata.
Ridurre ove possibile la necessità di chiavi permanenti
Le piattaforme adatte offrono identità gestite o autenticazione federata per le applicazioni. Possono ridurre la gestione di segreti longevi distribuiti autonomamente. Restano da verificare idoneità, permessi di destinazione, durata e ripristino. Anche un certificato richiede un ciclo di vita.
Uno scanner di segreti integra la protezione individuando credenziali potenzialmente pubblicate. Non mantiene però l’inventario operativo delle dipendenze né esegue il cambio completo di tutti gli utilizzatori. Ricerca delle fughe e gestione delle durate svolgono compiti diversi.
Iniziare dalle connessioni critiche per l’attività
DAXS censisce interfacce importanti e responsabilità, verifica i percorsi di avviso ed elabora una sostituzione ripetibile. Un progetto pilota può partire dall’invio di un modulo, un’importazione o un collegamento a un modello. Sono possibili test, non incidenti attribuiti a clienti.
I servizi di sviluppo e integrazione e la pagina tecnica su MCP e interfacce spiegano l’integrazione. L’ articolo sui permessi MCP per progetto completa il controllo degli accessi. Puoi richiedere un inventario delle tue credenziali d’integrazione.
Domande frequenti
Ogni API key va rigenerata regolarmente?
Non esiste una regola unica per tutti i fornitori. Validità, regole dell’emittente, rischio e processo operativo si verificano nel concreto. Anche una chiave senza scadenza fissa richiede una gestione ordinata.
Basta un’email poco prima della scadenza?
Un avviso serve solo se esistono responsabilità, sostituto e procedura collaudata. Deve inoltre risultare se la funzione dipendente funziona davvero.
La rotazione può avvenire sempre senza interruzioni?
Dipende da fornitore, credenziali utilizzabili in parallelo e caricamento delle applicazioni. Dove il passaggio sovrapposto non è possibile, si prevede una procedura coordinata con finestra di manutenzione adeguata.
Fonti: Google Cloud: chiavi degli account di servizio e scadenza (link esterno) · Microsoft: credenziali applicative e rotazione (link esterno) · Microsoft: cambio con due credenziali (link esterno) · Microsoft: rotazione con una credenziale (link esterno) · IETF: token OAuth e autenticazione applicativa (link esterno) · OWASP: ciclo di vita dei segreti (link esterno) · GitHub: ambito della scansione dei segreti (link esterno)
Scenari possibili e procedure semplificate; regole e opzioni concrete dipendono da fornitore e applicazione. Grafico e immagine illustrativa non mostrano una configurazione cliente.
