Archivio credenziali del provider per gateway AI multimodello: runtime, amministrazione, fatturazione e accesso BYOK separati

Le chiavi API downstream e le credenziali del provider upstream risolvono diversi problemi. Una chiave sviluppatore emessa dal gateway identifica l'app, il team, il tenant, il budget e il contesto dei criteri. Una chiave del fornitore a monte consente al gateway di spendere denaro e accedere ai modelli in un account del fornitore. Trattarli come lo stesso tipo di segreto è il motivo per cui i team si ritrovano con una chiave illimitata in un progetto condiviso, credenziali di amministratore nei servizi runtime e nessun modo affidabile per rispondere a quale tenant ha causato quale addebito lato provider.

Il modello pratico è un archivio credenziali del fornitore: un piano di controllo dedicato per l'importazione, la classificazione, l'archiviazione, la selezione, la rotazione e il controllo delle credenziali upstream. Dovrebbe trovarsi dietro il router, il registro di fatturazione, il motore delle policy e il flusso di lavoro delle operazioni, non all'interno del codice dell'applicazione, dei file di configurazione del modello, dei record del tenant o degli eventi di analisi.

Il problema del lettore: le credenziali upstream diventano un'infrastruttura invisibile

La maggior parte delle implementazioni multimodello iniziano con un obiettivo semplice: instradare una richiesta compatibile con OpenAI al miglior provider disponibile. Vengono quindi visualizzati più account: un progetto del fornitore per la produzione, un altro per la valutazione, uno spazio di lavoro antropico per un'unità aziendale, un progetto Google Cloud per Gemini e diverse chiavi fornite dal cliente per i contratti BYOK.

Il rischio non è semplicemente una fuga di notizie segreta. È la perdita del contesto di autorizzazione. Una chiave del provider valida può essere tecnicamente in grado di chiamare un endpoint, ma il gateway deve comunque sapere se tale chiave è consentita per questo tenant, questa famiglia di modelli, questa policy di conservazione dei dati, questo budget, questa regione e questo percorso di automazione.

Fatto: le piattaforme dei fornitori espongono diversi limiti di account e tipi di credenziali. OpenAI documenta progetti e account di servizio e le autorizzazioni della chiave API dell'account di servizio sono predefinite per l'accesso in lettura e scrittura per le risorse API del progetto. OpenAI espone inoltre gli oggetti chiave API di amministrazione separatamente dal normale utilizzo dell'API di progetto/runtime. Anthropic documenta gli spazi di lavoro come un confine organizzativo e afferma che gli endpoint API di amministrazione richiedono chiavi API di amministrazione distinte dalle chiavi API standard; Anthropic rileva inoltre che le chiavi API sono legate allo spazio di lavoro in cui vengono create e non possono essere spostate tra spazi di lavoro. La documentazione della chiave API Gemini di Google afferma che ogni chiave API Gemini è associata a un progetto Google Cloud e consiglia restrizioni API per ridurre i danni se una chiave viene compromessa.

Raccomandazione: non creare un campo generico "provider_key" e considerarlo fatto. Crea un inventario delle credenziali che preservi i confini specifici del provider esponendo al contempo al gateway un modello di policy normalizzato.

Definire una tassonomia delle credenziali prima di accettare le chiavi

Un vault dovrebbe rifiutare credenziali ambigue. Al momento dell'importazione, l'operatore o il flusso di lavoro di automazione deve classificare la credenziale. Come minimo, utilizza queste categorie:

• Credenziali di inferenza di runtime: utilizzate dal gateway per chiamare endpoint di inferenza del modello come chat, risposte, incorporamenti, moderazione, trascrizione o generazione di immagini, a seconda del supporto del provider.
• Credenziali di automazione dell'amministrazione: utilizzate per gestire organizzazioni, aree di lavoro, progetti, utenti, chiavi o risorse amministrative lato provider. Questi non dovrebbero mai trovarsi nel percorso della richiesta di runtime.
• Credenziali di fatturazione e reporting: utilizzate per recuperare l'utilizzo, le fatture, i costi o i report dell'organizzazione in cui i fornitori supportano tali API. Mantienili separati dalle chiavi di inferenza in modo che i lavori di reporting non possano generare l'utilizzo del modello.
• Credenziali di sola valutazione: utilizzate dai flussi di lavoro di benchmark, QA, migrazione o gestione temporanea. Dovrebbero avere quote basse, etichette ambientali chiare e nessuna idoneità alla produzione di riserva.
• Credenziali BYOK del cliente: chiavi fornite dal cliente vincolate a un tenant, un account del fornitore, un contratto e una policy sui dati specifici. Non devono essere raggruppati nel routing condiviso a meno che il cliente non lo acconsenta esplicitamente.

Questa tassonomia non è solo documentazione. Dovrebbe guidare il controllo degli accessi, l'idoneità del routing, gli avvisi e i flussi di lavoro di rotazione. Se una credenziale viene importata senza categoria, proprietario, limite dell'account del fornitore e utilizzo consentito, dovrebbe rimanere disabilitata.

Archivia i segreti in un deposito, non nei record del prodotto

L'insieme di credenziali dovrebbe essere l'unico componente in grado di decrittografare le credenziali upstream. Altri sistemi possono archiviare riferimenti, hash, campi di stato e metadati delle policy, ma non il valore della credenziale stesso.

Non archiviare i segreti upstream in questi luoghi

• Righe del profilo del tenant.
• File di configurazione del routing del modello.
• Log di richiesta o intervalli di traccia.
• Payload degli eventi di Analytics.
• Variabili CI rivolte allo sviluppatore.
• Biglietti di supporto, strumenti di chat o screenshot.

Un progetto di volta utilizzabile ha due piani. Il piano segreto memorizza il materiale delle credenziali crittografate e controlla strettamente le operazioni di decrittografia. Il piano dei metadati memorizza gli attributi non segreti utilizzati dal routing e dalla governance. Il router in genere dovrebbe necessitare solo di un ID credenziale e di un recupero segreto in memoria di breve durata al momento dell'invio, non di un ampio accesso al database per ogni chiave del provider.

Proteggi l'archivio protetto come infrastruttura di alto valore: crittografia busta o KMS gestito, identità di servizio rigorose, procedure break-glass, test di backup e ripristino, verifica degli accessi e avvisi su volumi di decrittografia insoliti. Un caveau centrale semplifica la governance, ma concentra anche il rischio. Questo è il compromesso.

Allega i metadati della policy a ogni credenziale

Il modello di metadati deve essere sufficientemente esplicito da consentire al gateway di decidere se una credenziale è idonea prima che tocchi l'endpoint del provider.

Un registro pratico delle credenziali include:

• credential_id: identificatore interno immutabile.
• provider: OpenAI, Anthropic, Gemini, Azure OpenAI o un altro adattatore.
• provider_account_boundary: organizzazione, progetto, area di lavoro, progetto cloud, abbonamento o equivalente.
• credential_class: runtime, amministrazione, fatturazione, valutazione o BYOK.
• ambiente: produzione, allestimento, sviluppo, valutazione, sandbox.
• tenant_binding: credenziale della piattaforma condivisa, singolo tenant, gruppo di tenant o tenant BYOK del cliente.
• allowed_model_families: ad esempio, generazione di testo, incorporamenti, visione, immagine, audio o profili di modelli specifici.
• allowed_endpoints: funzionalità del gateway normalizzate mappate agli endpoint del provider.
• data_policy: classe di conservazione consentita, classe di registrazione, requisito di residenza e limitazioni delle funzionalità.
• budget_scope: centro di costo, cliente rivenditore, reparto interno o contratto.
• proprietario: team nominato o persona responsabile.
• creato_a, scade_at, rotazione_due_at, last_used_at.
• stato_salute: sconosciuto, sano, degradato, non autorizzato, quota_esaurita, disabilitato.
• emergency_disable: blocco di routing immediato indipendente dal normale stato della politica.

Mantieni questo modello neutrale rispetto al fornitore, ma non cancellare le realtà dei fornitori. Una chiave associata all'area di lavoro Anthropic e una chiave Gemini legata a un progetto Google Cloud non sono intercambiabili solo perché entrambe possono generare testo. Il gateway necessita di tale provenienza per controlli, chargeback e failover sicuro.

Accesso separato a runtime, amministrazione e fatturazione

La regola più importante è semplice: una chiave utilizzata per l'inferenza di runtime non deve gestire organizzazioni del provider, aree di lavoro, utenti, progetti o risorse amministrative.

Il traffico di runtime ha un volume elevato ed è esposto alla più ampia superficie operativa. Passa attraverso router di richiesta, logica di ripetizione, gestori di streaming, adattatori di modelli e flussi di lavoro degli incidenti. Le credenziali di amministratore sono a bassa frequenza e ad alto impatto. Dovrebbero vivere dietro un percorso di approvazione separato con TTL brevi, denominata approvazione umana ove appropriato, registrazione avanzata e nessuna idoneità al routing in runtime.

Anche le credenziali di fatturazione meritano la separazione. Un processo di creazione di report che riconcilia le fatture non dovrebbe essere in grado di generare completamenti e una chiave di inferenza di runtime non dovrebbe essere l'unico modo per recuperare report sull'utilizzo. Quando un provider non offre una separazione granulare, compensa nel gateway: isola la credenziale, limita l'identità del servizio interno che può recuperarla e registra ogni utilizzo.

Raccomandazione: rendi la classe di credenziali un limite di autorizzazione rigido, non un'etichetta. Un dispatcher di runtime non dovrebbe essere in grado di richiedere la decrittografia per una credenziale di amministratore anche se un errore di configurazione fa riferimento al suo ID.

Crea un motore di criteri di selezione delle credenziali

La selezione delle credenziali dovrebbe avvenire dopo che il gateway ha autenticato il chiamante downstream e prima che venga tentata qualsiasi chiamata al provider. Il motore delle politiche dovrebbe unire diversi input:

• ID tenant e ambito della chiave API downstream.
• Profilo del modello richiesto o ID modello specifico del fornitore.
• Funzionalità endpoint: chat, incorporamenti, immagini, audio, batch, file, strumenti o automazione dell'amministrazione.
• Requisiti di conservazione e residenza dei dati.
• Budget, prenotazione del credito e centro di costo.
• Stato limite e pressione sulle quote.
• Metadati delle credenziali, integrità, ambiente e associazione del tenant.

Il motore dovrebbe restituire uno dei tre risultati: consenti con una credenziale selezionata, nega con un motivo relativo ai criteri o richiedi l'approvazione. Le smentite dovrebbero essere sufficientemente precise da consentire ai team operativi di risolvere il problema senza rivelare materiale segreto agli sviluppatori.

Esempio di decisione:

{
  "tenant_id": "tenant_42",
  "requested_profile": "prod-testo-veloce",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "classe": "tempo di esecuzione",
    "ambiente": "produzione",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "testo",
    "health_status": "sano"
  },
  "decisione": "consentire",
  "credential_id": "cred_8f2...",
  "audit_reason": "le credenziali BYOK del tenant corrispondono al profilo di testo di runtime e alla policy dei dati"
}

Non implementare il fallback come "prova la chiave successiva". Il fallback deve rieseguire la policy. Una credenziale della piattaforma condivisa può essere valida per l'accesso del fornitore ma non valida per un cliente solo BYOK. Una credenziale in un altro progetto potrebbe avere una quota, ma potrebbe violare i requisiti di attribuzione dei costi o di conservazione.

Gestire BYOK come accesso di proprietà del tenant, non come capacità di riserva

BYOK cambia il modello di fiducia. Il cliente ha fornito le credenziali in modo che il traffico possa essere addebitato, regolato o isolato all'interno dell'account del proprio fornitore. Tali credenziali devono essere vincolate alla provenienza dell'account del tenant del cliente e del fornitore.

Controlli BYOK consigliati:

• Un record del vault per cliente, fornitore, limite dell'account e ambiente.
• Nessun routing tra tenant tramite credenziali BYOK.
• Nessun utilizzo come capacità di fallback condivisa a meno che il cliente non acconsenta esplicitamente.
• Stato di integrità visibile al cliente che non rivela la chiave grezza.
• Flusso di lavoro di rotazione separato che consente al cliente di aggiungere una sostituzione prima che la vecchia chiave venga disabilitata.
• Chiara attribuzione nell'analisi dell'utilizzo e nelle fatture: tenant del gateway, limite dell'account del fornitore, ID credenziale, profilo del modello e ID di traccia della richiesta.

Per agenzie, rivenditori e automazione delle API dei partner, BYOK può essere più complesso perché un servizio può fornire tenant e credenziali in modo programmatico. Si applica ancora la stessa regola: l'automazione può importare e associare le credenziali, ma non dovrebbe offuscare la proprietà del tenant.

Aggiungi controlli di integrità preflight senza perdite di istruzioni

Una credenziale può non funzionare per molti motivi: chiave revocata, area di lavoro errata, accesso al modello mancante, fatturazione disattivata, esaurimento della quota, restrizione dell'endpoint, mancata corrispondenza delle politiche regionali o interruzione del provider. Scoprirlo solo dopo l'arrivo di una richiesta di produzione crea incidenti rumorosi.

Utilizza controlli di integrità che convalidano la funzionalità senza inviare richieste ai clienti. Un controllo sintetico potrebbe richiamare un endpoint minimo, elencare i modelli consentiti ove appropriato o inviare un messaggio fisso innocuo se questa è l'unica opzione pratica. Mantieni questi controlli economici, con tariffe limitate ed etichettati come traffico sintetico nella telemetria e nella fatturazione.

I controlli di integrità dovrebbero essere eseguiti:

• All'importazione delle credenziali.
• Prima di abilitare una credenziale per il routing di produzione.
• Dopo le modifiche alle restrizioni lato provider.
• Durante il cambio di rotazione.
• Periodicamente per credenziali con idoneità alla produzione.

Compromesso: i controlli automatizzati rilevano in anticipo le chiavi scadute o con ambito insufficiente, ma controlli mal progettati possono creare chiamate non necessarie al fornitore, rumore nella fatturazione o falsi allarmi durante le interruzioni del fornitore. Archivia il risultato dell'integrità con timestamp, classe di errore del provider, endpoint testato e famiglia di modelli testata. Non memorizzare valori segreti o richieste sensibili.

Ruota con due slot, nessuna sostituzione rischiosa

La rotazione delle credenziali non dovrebbe essere un'operazione di cancellazione e preghiera. Utilizza un modello di rotazione a due slot:

1. Importa credenziali sostitutive come inattive, con metadati e proprietario completi.
2. Esegui controlli di integrità sintetici per gli endpoint, le famiglie di modelli e i limiti dell'account previsti.
3. Abilita l'idoneità shadow per una piccola parte di traffico sintetico sicuro o a basso rischio, ove appropriato.
4. Sposta gradualmente il traffico di produzione dalla vecchia credenziale alla nuova credenziale.
5. Monitora errori, latenza, quota e attribuzione dei costi in base all'ID credenziale.
6. Blocca il fallback alla vecchia credenziale una volta che la nuova credenziale è stabile.
7. Revocare le vecchie credenziali presso il fornitore e contrassegnare il record del vault revocato.
8. Verificare che non vengano effettuate decrittografie o chiamate al provider tramite la vecchia credenziale dopo la revoca.

Le scadenze della rotazione dovrebbero essere visibili nelle visualizzazioni delle operazioni e negli avvisi. La rotazione di emergenza richiede un percorso più breve: disabilita le credenziali, blocca il routing, abilita la sostituzione approvata e conserva tutti i record di controllo per la revisione degli incidenti.

Limita le chiavi del provider laddove il provider le supporta

La politica del gateway è necessaria, ma le restrizioni lato provider riducono il raggio d'azione se una chiave viene compromessa o utilizzata in modo improprio. Per Gemini e altre chiavi API della piattaforma cloud, utilizzare le restrizioni API/servizi e le restrizioni applicative adeguate, ove disponibili. Per progetti, aree di lavoro e account di servizio del provider, evita ampi privilegi organizzativi quando è sufficiente una chiave di runtime con ambito di progetto.

Raccomandazione: mantieni un elenco di controllo delle restrizioni lato provider per ogni classe di credenziali. La lista di controllo dovrebbe far parte dell'approvazione dell'importazione e dell'approvazione della rotazione, non di un compito di sicurezza separato che potrebbe essere ignorato sotto pressione.

Compromesso: le restrizioni lato fornitore aggiungono un sovraccarico operativo. Nuovi endpoint, famiglie di modelli, regioni o funzionalità di automazione potrebbero richiedere modifiche alle policy e alle restrizioni. È preferibile piuttosto che scoprire dopo una fuga di notizie che una chiave potrebbe accedere a ogni carico di lavoro in un progetto condiviso.

Conserva un registro di controllo delle credenziali di sola aggiunta

Un audit trail dovrebbe rispondere a chi ha importato una credenziale, cosa gli è stato consentito fare, quali decisioni di instradamento l'hanno selezionata, quando ha avuto esito negativo e quando è stata ruotata o revocata.

Registra questi eventi:

• Credenziali create o importate.
• Metadati modificati, inclusi endpoint consentiti, associazione del tenant o policy dei dati.
• Controllo dello stato eseguito e risultato registrato.
• Credenziali selezionate dalla policy di instradamento per una richiesta.
• Decifratura delle credenziali richiesta da un'identità di servizio interna.
• Chiamata al provider non riuscita a causa di un errore di autenticazione, autorizzazione, quota o restrizione.
• Rotazione avviata, traffico spostato, vecchia credenziale revocata.
• Disabilitazione di emergenza abilitata o deselezionata.
• Accesso alle credenziali di amministratore o break-glass.

Non inserire valori di credenziali grezzi negli eventi di controllo. Utilizza ID credenziali, limiti dell'account del fornitore, ID di traccia delle richieste, identità degli attori e ragioni delle decisioni relative alle policy. Per il traffico di runtime a volume elevato, puoi campionare la telemetria di decrittografia dettagliata, ma la selezione del routing e l'attribuzione dei costi dovrebbero rimanere sufficientemente complete per la fatturazione e la risposta agli incidenti.

Lista di controllo per l'implementazione

• Crea una tassonomia delle credenziali e rifiuta le importazioni non classificate.
• Sposta tutti i segreti del provider in un deposito crittografato dedicato.
• Memorizza i metadati di routing separatamente dal materiale segreto.
• Rendi le credenziali di runtime, amministrazione, fatturazione, valutazione e BYOK classi di autorizzazione separate.
• Associa le credenziali BYOK alla provenienza dell'account del tenant e del fornitore.
• Richiedi l'approvazione del motore delle politiche prima di selezionare qualsiasi credenziale upstream.
• Esegui controlli sanitari tempestivi prima dell'idoneità alla produzione.
• Utilizza la rotazione a due slot con spostamento graduale del traffico e revoca da parte del provider.
• Applica restrizioni lato provider laddove disponibili.
• Conserva log di controllo di sola aggiunta per importazione, utilizzo, errori, rotazione e revoca.
• Mantieni le credenziali di amministratore dietro controlli rivoluzionari: TTL breve, approvazione denominata, registrazione avanzata, nessun utilizzo del runtime.

Conclusione attuabile

Inizia facendo l'inventario di tutte le credenziali del fornitore upstream attualmente utilizzate dal gateway, dagli script, dai processi CI, dai sistemi di valutazione e dall'automazione dei partner. Per ognuno, assegnare una classe, un proprietario, un limite dell'account del provider, un'associazione del tenant, endpoint consentiti, famiglie di modelli consentite, scadenza della rotazione e stato di disabilitazione di emergenza. Tutto ciò che non puoi classificare dovrebbe essere disabilitato o messo in quarantena finché non ha uno scopo chiaro.

Quindi applica una regola architetturale: gli sviluppatori downstream ricevono chiavi con ambito gateway; solo il gateway controlla l'accesso del provider a monte. Questa separazione ti consente di preservare privilegi minimi, attribuzione del tenant, accuratezza della fatturazione, routing della politica dei dati e automazione sicura anche quando fornitori, progetti, spazi di lavoro e clienti BYOK si moltiplicano.

Leggi correlati

• Gestione delle chiavi API rivolta al team e risposta alle perdite
• politiche di routing data-retention-aware
• registro di fatturazione e attribuzione dei costi controlli