AdAce AdsRuota una chiave API per l'integrazione AI con inventario e verifica di revoca
Creare una chiave sostitutiva è solo una parte della rotazione. Il problema operativo è trovare ogni utilizzatore, sostituire la credenziale senza confondere le identità e confermare che la vecchia non funzioni più. Questo runbook suggerito descrive quel ciclo di vita in AdAce Ads senza ripetere il tutorial di creazione della chiave, esporre un segreto o dare per scontato che un client AI esterno sia connesso.
Inventaria gli utilizzatori prima della sostituzione
Inizia con un inventario delle credenziali che registra ID della chiave o prefisso sicuro, proprietario, spazio di lavoro, utilizzatore previsto, ambiti, scadenza, riferimento alla posizione di archiviazione e contatto operativo. Registra la posizione di un segreto, mai il suo valore. Distingui una chiave usata da un processo di reporting da una usata in modo interattivo. Una chiave senza utilizzatore identificato è un elemento dell'inventario non risolto, non automaticamente sicuro da lasciare attivo. Le prove di uso recente possono aiutare, ma l'assenza di uso non è una mappa completa delle dipendenze.
AdAce Ads memorizza un hash della chiave, mostra la chiave completa solo alla creazione e valuta i suoi ambiti insieme alle autorizzazioni attuali del proprietario. La rotazione deve preservare o ridurre il perimetro richiesto, non aggiungere l'ambito propose solo perché viene emessa una nuova chiave. Per un'attività di solo reporting, usa la funzionalità di lettura prevista. Una chiave API e un'autorizzazione OAuth sono credenziali diverse; sostituirne una non sostituisce né revoca l'altra. Identifica il percorso di autenticazione effettivo prima di iniziare.
Un esempio didattico ha due utilizzatori: uno script di preparazione dei report e una sessione temporanea di un analista. Lo script richiede una sostituzione pianificata; la sessione temporanea è terminata e deve essere chiusa anziché migrata. Il runbook registra un passaggio e una rimozione. Non copia la stessa sostituzione in ogni dispositivo noto. Un utilizzatore non identificato che usa la vecchia identità dopo il passaggio è un motivo per indagare, non per ripristinare la vecchia chiave indefinitamente per comodità.
Passaggio e revoca richiedono controlli separati
- Scegli la modalità di rotazione in base al motivo. Una sostituzione di routine può consentire una breve sovrapposizione controllata quando supportata; un'esposizione sospetta può richiedere la revoca immediata e un'interruzione temporanea del servizio. Non dare per scontato che la continuità sia più importante del contenimento.
- Usa una matrice di verifica con vecchia credenziale, credenziale sostitutiva e utilizzatori interessati. Una lettura riuscita con la sostituzione dimostra solo quel percorso di lettura. Non dimostra che la vecchia credenziale sia revocata o che ogni utilizzatore pianificato sia stato aggiornato.
- Nel runbook conserva identificatori e timestamp, non screenshot di campi segreti o header di autenticazione. Un report di rotazione dovrebbe essere utile a un altro operatore senza diventare un nuovo canale di distribuzione delle credenziali.
Sostituisci, verifica e chiudi
- Identifica il proprietario e tutti gli utilizzatori documentati. Controlla gli ambiti richiesti e l'accesso ai clienti, poi scegli la gestione ordinaria o di emergenza. Registra il proprietario autorizzato del passaggio e la condizione per terminare qualsiasi periodo di sovrapposizione.
- Se la sostituzione è necessaria, predisponi una chiave sostitutiva tramite il flusso autorizzato esistente. Controlla limiti e autorizzazioni attuali dell'account invece di inserirli direttamente nel runbook. Archivia il nuovo valore direttamente nella posizione segreta approvata senza incollarlo in note, chat o log.
- Aggiorna un utilizzatore controllato e verifica una lettura innocua consentita nello spazio di lavoro previsto. Conferma che legga l'ambito giusto e non invochi propose_change o alcuno strumento di scrittura. Ripeti il controllo specifico per utilizzatore dove credenziali o ambienti di esecuzione differiscono.
- Revoca la vecchia chiave tramite il controllo autorizzato e conferma che una lettura isolata con la vecchia credenziale venga rifiutata. Usa strumenti sicuri che nascondano gli header della richiesta e il segreto. Non inserire la credenziale in un comando shell, URL, screenshot o report di test esportato.
- Chiudi la rotazione con prove sicure: ID della chiave sostitutiva, vecchio ID, controlli degli utilizzatori, risultato della revoca, verificatore e ora. Monitora gli utilizzatori che falliscono usando la vecchia credenziale e risolvili con una migrazione o chiusura appropriata. Un segreto revocato non deve diventare il meccanismo di ripristino.
Scopri quale perimetro della credenziale è cambiato
- La revoca di una chiave impedisce l'autenticazione futura tramite quella chiave; non ritira i dati già letti, non annulla ogni autorizzazione indipendente né revoca un'appartenenza diretta alla piattaforma pubblicitaria. Controlla separatamente questi perimetri quando chiudi una relazione.
- Questo è un runbook operativo proposto, non un report che dichiara che una rotazione live è stata eseguita. I test locali e la revisione del codice possono stabilire il comportamento previsto, ma le verifiche controllate devono essere confermate nell'ambiente reale. Nessun esempio richiede una scrittura sull'API pubblicitaria.
Fonti e approfondimenti
Provalo sui tuoi account
Crea uno spazio di lavoro, collega Google o Meta in un paio di clic e visualizza chiaramente i tuoi account. Le modifiche seguono le tue approvazioni o le regole che configuri.
Crea il tuo spazio di lavoro