L'accesso a Claude Platform on AWS unifica tre ambienti, ma la precisione di IAM determina l'esito della sicurezza
AWS ha documentato tre percorsi di accesso a Claude Platform on AWS nell'ambito di un unico abbonamento, nonostante requisiti di credenziali e sicurezza nettamente differenti.
Pubblicata il 1° ottobre, l'implementazione collega i carichi di lavoro AWS, i laptop degli sviluppatori e i servizi esterni a workspace ospitati in un account AI Services dedicato. Le applicazioni di produzione usano Signature Version 4 tra account, gli sviluppatori ricevono chiavi API con ambito definito e i carichi di lavoro esterni si autenticano tramite federazione OpenID Connect.
L'architettura promette fatturazione e amministrazione centralizzate senza imporre a ogni ambiente un unico modello di credenziali. La sua tensione è altrettanto chiara. La centralizzazione semplifica la titolarità, ma una policy IAM troppo ampia o una chiave per sviluppatori gestita in modo improprio può indebolire i confini dei workspace che rendono utile il progetto.
Non si tratta semplicemente di un'altra guida all'integrazione di Claude. L'implementazione AWS trasforma l'autenticazione in un piano di controllo specifico per ambiente. Espone inoltre il lavoro operativo nascosto dietro l'espressione “abbonamento unico”.
Amazon Bedrock rimane un importante punto di riferimento. Fornisce modelli Claude tramite un servizio AWS gestito per i foundation model. Claude Platform on AWS offre invece l'esperienza della piattaforma nativa di Anthropic tramite un account AWS, comprese API, console e funzionalità della piattaforma.
Il nuovo schema di accesso non elimina questa distinzione. Mostra come le aziende possano estendere la piattaforma nativa di Anthropic in tutta un'organizzazione AWS mantenendo il controllo basato su IAM sul traffico di produzione.
Un unico abbonamento ora serve tre confini di fiducia
Il cambiamento importante non è soltanto una connettività più ampia. AWS ha associato tre ambienti a tre distinti metodi di autenticazione, mantenendo centralizzata la titolarità dei workspace.
La topologia proposta parte da tre ruoli account. Un account di gestione si occupa di fatturazione e governance a livello di organizzazione. Un account AI Services dedicato possiede l'abbonamento Claude Platform, i workspace, le chiavi API e i ruoli di accesso.
Uno o più account di carico di lavoro consumano quindi l'inferenza Claude senza possedere l'abbonamento. Le loro applicazioni assumono ruoli nell'account AI Services e chiamano risorse dei workspace autorizzate da tali ruoli.
Questa separazione assegna all'account AI Services uno scopo specifico. Diventa il confine amministrativo intorno all'accesso a Claude, anziché un altro account applicativo generico pieno di risorse non correlate.
AWS raccomanda di creare workspace distinti per produzione e sviluppo all'interno di tale account. Un workspace è il confine delle risorse utilizzato per separare team, progetti o ambienti, mantenendo al contempo un'amministrazione centralizzata.
Ogni workspace dispone di un Amazon Resource Name, o ARN, a cui le policy IAM possono fare riferimento. Le autorizzazioni possono quindi consentire l'inferenza su un workspace senza autorizzarne automaticamente un altro.
Il primo percorso di accesso copre le applicazioni già in esecuzione all'interno di AWS. AWS usa come esempio un pod Amazon EKS, sebbene lo schema possa applicarsi ad altri carichi di lavoro AWS.
Quel pod assume innanzitutto un ruolo tra account nell'account AI Services. Le credenziali temporanee firmano quindi le richieste Claude con AWS Signature Version 4, comunemente chiamato SigV4.
SigV4 firma crittograficamente le richieste API AWS usando credenziali AWS. Consente al servizio ricevente di verificare il chiamante, l'integrità della richiesta e il contesto di autorizzazione senza un segreto API statico separato.
Il ruolo tra account concede azioni aws-external-anthropic selezionate rispetto all'ARN del workspace di produzione. L'esempio include inferenza, conteggio dei token, recupero dei modelli ed elenco dei modelli.
Il ruolo non necessita dell'autorizzazione per accedere al workspace di sviluppo. Questo crea una relazione diretta tra l'identità del carico di lavoro, le azioni API consentite e il workspace Claude autorizzato.
Il secondo percorso riguarda i laptop degli sviluppatori. Gli sviluppatori hanno spesso bisogno di un metodo con minori attriti per testare prompt, comportamento degli SDK e logica applicativa al di fuori di un carico di lavoro distribuito.
AWS assegna a questi utenti una chiave API di lunga durata associata al workspace di sviluppo. L'SDK Anthropic standard può utilizzare tale chiave sull'endpoint regionale Claude Platform on AWS.
Questo percorso preserva un'esperienza familiare per gli sviluppatori, ma crea una credenziale bearer persistente. Chiunque detenga la chiave può usare le relative autorizzazioni finché non scade o un amministratore non la revoca.
Il terzo percorso è rivolto ai servizi esterni. Gli esempi includono carichi di lavoro in esecuzione su Google Cloud, cluster Kubernetes non AWS e sistemi CI/CD come GitHub Actions o GitLab CI.
Questi servizi utilizzano la federazione OIDC, che scambia il token firmato di un provider di identità con credenziali AWS temporanee. Le credenziali temporanee generano un token bearer Claude di breve durata.
L'esempio di AWS crea un token valido per un'ora. L'implementazione consente durate configurabili fino a 12 ore, trascorse le quali il servizio esterno deve ottenere un altro token.
Nel loro insieme, questi tre percorsi costituiscono il nucleo dell'accesso Claude multi-ambiente. L'abbonamento rimane in un unico account, mentre l'autenticazione cambia in base a dove viene eseguito il chiamante.
Questo è il progresso architetturale. Riconosce che un pod EKS, un laptop per sviluppatori e una pipeline esterna non dovrebbero condividere un unico schema universale di credenziali.
L'accesso a Claude Platform on AWS sposta il controllo in IAM
L'accesso a Claude Platform on AWS dipende ora meno da dove viene eseguito il codice e più dal fatto che IAM descriva accuratamente l'identità e il workspace previsti.
AWS ha introdotto il servizio come modo per utilizzare la piattaforma nativa di Anthropic tramite un account AWS esistente. L'azienda ha affermato che AWS è stato il primo cloud provider a offrire tale esperienza nativa attraverso la propria struttura di account.
Il lancio originale ha collegato autenticazione, fatturazione e funzioni di audit ad AWS. I clienti potevano utilizzare le API e gli strumenti di Anthropic senza instaurare una relazione commerciale separata.
Il progetto multi-ambiente estende questa proposta oltre una connessione API di base. Rende l'organizzazione AWS, anziché una singola applicazione, il livello organizzativo per l'accesso a Claude.
Questo è importante perché l'uso dell'AI in azienda raramente resta confinato in un unico ambiente. Un team può testare un'applicazione localmente, distribuirla su EKS ed eseguire valutazioni da un altro cloud.
Una chiave statica condivisa può collegare tutte e tre le posizioni, ma ne comprime anche le identità. I log mostrano la chiave, non necessariamente il carico di lavoro, l'account o la pipeline che l'ha utilizzata.
I ruoli tra account conservano più contesto. Il carico di lavoro assume un ruolo nominato, riceve credenziali temporanee ed effettua richieste firmate che AWS può attribuire a un principal.
Il ruolo crea anche due punti di controllo dell'autorizzazione. L'account del carico di lavoro deve consentire alla propria identità locale di assumere il ruolo di destinazione. L'account AI Services deve fidarsi di tale identità e organizzazione.
L'esempio di AWS aggiunge una condizione aws:PrincipalOrgID alla policy di trust. Tale condizione limita l'assunzione del ruolo ai principal associati all'organizzazione AWS specificata.
La policy delle autorizzazioni limita quindi l'inferenza all'ARN del workspace di produzione. Il trust risponde a chi può entrare nel ruolo, mentre le autorizzazioni definiscono cosa quel ruolo può fare in seguito.
Questa separazione mette sotto pressione i team che in precedenza trattavano l'accesso ai modelli come una distribuzione di segreti. Ora devono gestire l'autenticazione AWS di Claude come un'architettura di identità.
I team di sicurezza, piattaforma e applicazioni devono concordare la titolarità degli account. Hanno inoltre bisogno di standard di denominazione per ruoli, workspace, policy e mappature degli ambienti.
Un account dedicato può rendere visibili queste responsabilità. Tuttavia, non le rende automaticamente corrette.
L'architettura influenza anche la risposta agli incidenti. Un ruolo di produzione può essere disabilitato senza rimuovere immediatamente l'accesso degli sviluppatori. Una chiave di sviluppo compromessa può essere revocata senza modificare un ruolo del carico di lavoro EKS.
La separazione dei workspace può supportare anche l'attribuzione dei costi. AWS afferma che le organizzazioni possono applicare tag ai workspace e attivarli per l'allocazione dei costi.
Dopo l'attivazione, che secondo AWS può richiedere da 24 a 48 ore, i team possono filtrare i dati di AWS Cost Explorer per workspace. Questo crea un percorso dall'isolamento tecnico all'analisi della spesa a livello di progetto.
L'auditabilità richiede un'altra scelta esplicita. L'amministrazione dei workspace appare per impostazione predefinita negli eventi di gestione CloudTrail, ma l'inferenza appartiene alla categoria degli eventi dati.
La documentazione sul monitoraggio afferma che i team devono abilitare la registrazione degli eventi dati per acquisire l'inferenza e altre operazioni dei workspace. Questi eventi possono inoltre generare costi CloudTrail aggiuntivi.
Questa distinzione è facile da trascurare. Centralizzare l'abbonamento migliora la potenziale pista di audit, ma non garantisce che l'attività di inferenza venga registrata.
Il progetto spinge quindi i responsabili delle piattaforme a trattare l'osservabilità come parte del controllo degli accessi. Una policy può limitare un'azione, mentre la registrazione fornisce prove su quale principal l'abbia effettivamente eseguita.
I tre percorsi di autenticazione risolvono problemi diversi
L'architettura funziona perché evita di forzare praticità, identità del carico di lavoro e federazione esterna nello stesso ciclo di vita delle credenziali.
Per i carichi di lavoro AWS, SigV4 tra account offre l'allineamento più pulito con l'identità cloud esistente. L'applicazione riceve credenziali AWS temporanee assumendo un ruolo.
Firma quindi ogni richiesta all'endpoint Claude. Non esiste una chiave API Claude separata memorizzata nell'account del carico di lavoro, nell'immagine del container o nella configurazione di distribuzione.
Questo approccio segue le linee guida AWS consolidate. Le best practice IAM dell'azienda raccomandano credenziali di ruolo temporanee per i carichi di lavoro anziché chiavi di accesso a lunga durata.
Il ruolo di produzione può includere soltanto le azioni necessarie all'applicazione. Un'applicazione sincrona di base potrebbe richiedere autorizzazioni per inferenza e conteggio dei token, ma non azioni su file, batch o amministrazione.
Claude Platform on AWS utilizza lo spazio dei nomi IAM aws-external-anthropic. Il suo modello di autorizzazioni associa le route API ad azioni specifiche, come CreateInference per le richieste di messaggi.
Quell'azione può fare riferimento a un solo ARN del workspace. L'applicazione ottiene l'accesso al workspace di produzione senza ereditare privilegi Claude estesi all'intero account.
Questo è il più solido dei tre percorsi per carichi di lavoro AWS continui. L'applicazione non porta con sé un segreto Claude durevole e AWS può attribuire le richieste a un'identità assunta.
I laptop degli sviluppatori creano un vincolo diverso. Richiedere che ogni esperimento locale attraversi una catena di ruoli tra account può aumentare i costi di configurazione e rallentare l'iterazione.
AWS utilizza quindi una chiave API con ambito limitato al workspace per lo sviluppo. La chiave funziona con il client Anthropic standard e punta all'endpoint regionale Claude Platform on AWS.
La precisazione importante è che una chiave appena generata non è automaticamente abbastanza ristretta per questo schema. AWS afferma che al suo utente IAM di supporto viene inizialmente assegnata la policy gestita AnthropicLimitedAccess.
Secondo la guida all'implementazione, tale policy gestita concede l'accesso a tutti i workspace. Un amministratore deve scollegarla e sostituirla con una policy inline limitata allo sviluppo.
Quel passaggio è il controllo manuale più importante nel percorso per sviluppatori. Generare la chiave è semplice, mentre applicare il previsto confine del workspace richiede una modifica IAM separata.
AWS raccomanda di testare successivamente tale confine. Lo sviluppatore dovrebbe chiamare con successo il workspace di sviluppo, quindi tentare una richiesta alla produzione e confermare che IAM la neghi.
Questo test negativo è più importante della richiesta riuscita. Una risposta dall’ambiente di sviluppo prova la connettività, ma solo una chiamata alla produzione rifiutata verifica l’affermazione di isolamento.
La chiave API resta autoautenticante. Funziona da AWS, da un altro cloud o da un laptop perché il possesso della chiave fornisce la credenziale.
I team dovrebbero quindi conservarla in un gestore di segreti approvato e impostarne una scadenza. Servono inoltre procedure di revoca per dispositivi smarriti, cambi di ruolo ed esposizione accidentale nei repository.
Il percorso per i carichi di lavoro esterni elimina quel segreto persistente. OIDC consente a un provider di identità compatibile di emettere un JSON Web Token che identifica il carico di lavoro.
AWS Security Token Service convalida il token e verifica le condizioni di trust del ruolo. Quindi restituisce credenziali AWS temporanee tramite AssumeRoleWithWebIdentity.
La guida OIDC raccomanda questo schema per le applicazioni esterne ad AWS perché evita credenziali a lungo termine incorporate.
Il carico di lavoro esterno usa le proprie credenziali AWS temporanee per richiedere un token bearer Claude di breve durata. Una volta generato, tale token bearer può chiamare Claude senza conservare le credenziali AWS.
Questo è utile per container esterni e job CI/CD, ma il rinnovo del token diventa parte dell’applicazione. Un servizio in esecuzione continua deve aggiornare il token prima della scadenza.
Anche la policy di trust OIDC merita particolare attenzione. L’esempio di AWS verifica le attestazioni audience e subject del token rispetto ai valori previsti.
L’audience identifica il destinatario previsto del token. Il subject distingue il carico di lavoro consentito, il service account, il repository o l’identità della pipeline.
Filtri poco rigorosi sulle attestazioni possono ammettere più identità esterne del previsto. Un meccanismo di federazione corretto con una condizione di trust imprecisa produce comunque accessi eccessivi.
Questi percorsi sono quindi complementari, non intercambiabili.
SigV4 cross-account è adatto a carichi di lavoro di produzione già governati tramite identità AWS.
Le chiavi API limitate al workspace riducono l’attrito per lo sviluppo locale.
La federazione OIDC è adatta all’automazione esterna che può presentare un’identità del carico di lavoro verificabile.
L’elemento condiviso è il workspace. Ogni percorso di credenziali dovrebbe infine risolversi in autorizzazioni per il workspace appropriato a quell’ambiente.
La centralizzazione non elimina il rischio delle credenziali
Il design migliora l’isolamento solo quando ogni ruolo, chiave, condizione di trust, endpoint e impostazione di logging corrisponde al workspace previsto.
Il rischio più evidente risiede nel percorso per sviluppatori. Le istruzioni di AWS affermano che una chiave API generata dispone inizialmente di una policy gestita con accesso a ogni workspace.
Un amministratore deve identificare il nuovo utente IAM sottostante, rimuovere tale policy e allegare una policy inline più restrittiva.
Questo flusso di lavoro è vulnerabile all’errore umano. Un amministratore potrebbe limitare l’utente sbagliato, mantenere la policy gestita o fare riferimento a un ARN del workspace errato.
La chiave risultante continuerebbe comunque a funzionare. Una richiesta di sviluppo riuscita non rivelerebbe che ha conservato anche l’accesso alla produzione.
Un test obbligatorio di negazione può rilevare questo errore. Le organizzazioni dovrebbero rendere il test di accesso alla produzione parte dell’emissione della chiave, non una convalida facoltativa eseguita in seguito.
Le chiavi a lunga durata offrono inoltre un’attribuzione più debole rispetto all’accesso basato sui ruoli. Più sviluppatori che condividono una chiave possono apparire come lo stesso principal nei record di audit.
Le chiavi individuali migliorano l’attribuzione, ma aumentano il numero di credenziali che richiedono archiviazione sicura, scadenza, revoca e tracciamento della proprietà.
Il percorso cross-account presenta modalità di errore diverse. Una policy di trust può essere troppo ampia, oppure il permesso di assunzione sul lato del carico di lavoro può raggiungere il ruolo di destinazione sbagliato.
La condizione aws:PrincipalOrgID aiuta a limitare l’ambito organizzativo. Tuttavia, non sostituisce un ARN del principal esatto o una denominazione accurata dei ruoli.
Anche le autorizzazioni meritano una revisione a livello di azione. Concedere accesso wildcard nell’intero namespace aws-external-anthropic comprometterebbe la struttura a privilegi minimi della guida.
AWS pubblica esempi dettagliati di policy IAM per l’inferenza su un singolo workspace e altri controlli. I team dovrebbero convalidare le policy distribuite rispetto alle funzionalità API che utilizzano effettivamente.
Il percorso OIDC sposta la sicurezza verso le attestazioni dell’identità esterna. La sua sicurezza dipende dal corretto funzionamento congiunto di issuer, audience, filtro subject, policy del ruolo e logica di rinnovo del token.
Un pattern subject che copre un intero gruppo di repository potrebbe autorizzare pipeline non correlate. Un pattern troppo ampio per i service account può ammettere carichi di lavoro esterni al namespace previsto.
Le credenziali temporanee limitano la durata dell’esposizione, ma non correggono autorizzazioni eccessive durante tale periodo. L’accesso di breve durata è più sicuro dell’accesso permanente, ma non è automaticamente a privilegi minimi.
Anche il token Claude generato diventa una credenziale bearer autonoma. Fino alla scadenza, il possesso è sufficiente per usarlo entro il confine di autorizzazione ereditato.
Le applicazioni dovrebbero evitare di stamparlo nei log, nell’output di build, nelle tracce delle eccezioni o nei metadati di monitoraggio. La durata del token dovrebbe corrispondere, ove pratico, alla durata del job.
Il comportamento regionale aggiunge un altro vincolo operativo. I workspace vengono creati in una regione AWS e le richieste API devono puntare al corrispondente endpoint regionale.
AWS distingue questo vincolo dell’endpoint dalla geografia dell’inferenza. Le impostazioni di sicurezza del workspace determinano indipendentemente se l’inferenza usa il routing USA o globale.
Le chiavi a breve termine funzionano solo con lo stesso endpoint regionale in cui sono state generate. Secondo la guida AWS, le chiavi API a lunga durata non sono vincolate a una regione.
Questa differenza può produrre errori difficili da interpretare durante il deployment. Un processo di rinnovo del token potrebbe riuscire in una regione mentre un’applicazione punta a un altro endpoint.
L’architettura presenta anche un confine più ampio che gli acquirenti devono comprendere. AWS afferma che Claude Platform on AWS è gestita da Anthropic, con richieste e dati elaborati al di fuori del confine di sicurezza AWS.
Ciò rende il servizio distinto dall’ipotesi che tutta l’elaborazione resti all’interno di un perimetro di servizio controllato da AWS. Le organizzazioni con requisiti rigorosi di residenza dei dati necessitano di una revisione separata.
AWS posiziona Claude Platform on AWS come complementare ai modelli Claude disponibili tramite Amazon Bedrock. La scelta quindi non riguarda semplicemente un metodo di autenticazione rispetto a un altro.
Comprende funzionalità della piattaforma, responsabilità operative, confini di elaborazione e requisiti regionali. L’accesso multi-ambiente non risolve queste questioni per ogni carico di lavoro.
La centralizzazione può anche aumentare il raggio d’impatto degli errori amministrativi. L’account AI Services contiene l’abbonamento, i workspace, le chiavi API e i ruoli di accesso.
Una modifica in tale account può influenzare contemporaneamente più account applicativi. Il design dovrebbe quindi applicare a questo account controlli delle modifiche più rigorosi rispetto a un ambiente di sviluppo informale.
I team dovrebbero separare, dove possibile, la creazione delle policy dalla loro approvazione. L’infrastruttura come codice può inoltre ridurre definizioni di ruolo incoerenti tra team e workspace aggiuntivi.
AWS afferma che le organizzazioni con più ambienti possono creare un workspace per ogni team o carico di lavoro e ripetere il modello di ruolo cross-account.
Questo approccio scala il modello di isolamento, ma moltiplica anche policy, relazioni tra ruoli, log, tag e configurazioni degli endpoint. La disciplina operativa diventa il fattore limitante.
La promessa centrale dovrebbe quindi essere formulata con cautela. Il modello fornisce i componenti per l’isolamento dei workspace, ma sono le policy distribuite e la gestione delle credenziali a determinare se tale isolamento regge.
Cosa dovrebbero convalidare le aziende in seguito
Il prossimo test è stabilire se le organizzazioni possano gestire questo modello di accesso in modo coerente, non se i tre flussi di autenticazione funzionino in una dimostrazione.
Il primo segnale è la convalida automatizzata delle policy. I team dovrebbero confermare che ogni ruolo di produzione punti a un ARN del workspace previsto e soltanto alle azioni API necessarie.
L’emissione delle chiavi per sviluppatori dovrebbe includere sostituzione della policy, scadenza, archiviazione del segreto e un test forzato di negazione dell’accesso alla produzione. Un processo che dipende dalla memoria finirà inevitabilmente per degradarsi.
Se le organizzazioni automatizzano questi controlli tramite pipeline di deployment, il modello centralizzato di AWS diventa più credibile su larga scala. Eccezioni manuali ripetute indebolirebbero tale conclusione.
Il secondo segnale è la copertura dell’audit. I soli eventi di gestione CloudTrail non forniscono visibilità per chiamata sull’inferenza.
Le organizzazioni dovrebbero abilitare gli eventi dati per il tipo di risorsa del workspace Claude pertinente, quindi verificare che i record contengano un’attribuzione utile del principal.
Dovrebbero inoltre testare se i responsabili della risposta agli incidenti possano collegare una richiesta a un ruolo EKS, a una chiave per sviluppatori o a un’identità OIDC esterna.
Se il percorso di audit preserva queste distinzioni, l’architettura a tre percorsi supporta un accesso responsabile. Se i log appiattiscono i chiamanti in identità condivise, la centralizzazione offre meno valore investigativo.
Il terzo segnale è l’adozione oltre le applicazioni native AWS. Il percorso OIDC è progettato per cloud esterni, deployment Kubernetes e sistemi CI/CD.
Il suo vero test sarà la rotazione affidabile dei token durante job di lunga durata. I team devono inoltre mantenere ristrette le attestazioni subject e audience man mano che repository e service account cambiano.
Frequenti errori di autenticazione incoraggerebbero gli sviluppatori a ripiegare su segreti a lunga durata. Un rinnovo stabile con condizioni di trust precise rafforzerebbe l’approccio federato.
Le aziende dovrebbero anche monitorare la proliferazione dei workspace. Creare un workspace per team o carico di lavoro può migliorare isolamento, proprietà e allocazione dei costi.
Troppi workspace senza etichette coerenti e regole di ciclo di vita possono creare un’altra forma di proliferazione incontrollata. Chiavi obsolete, ruoli abbandonati e workspace inutilizzati richiedono un processo di dismissione.
L’account dedicato AI Services dovrebbe diventare un confine di servizio governato. I suoi amministratori necessitano di registri di proprietà per ogni workspace, ruolo e credenziale.
I team di piattaforma possono registrare le decisioni di accesso insieme all’architettura delle applicazioni e alle procedure di gestione degli incidenti. Una base di conoscenza ingegneristica ricercabile può aiutare a preservare queste associazioni mentre i team cambiano.
La valutazione più utile inizia con un percorso applicativo completo. Collegate un carico di lavoro di produzione tramite SigV4, un client di sviluppo tramite una chiave limitata e una pipeline tramite OIDC.
Quindi verificate richieste cross-workspace negate, rinnovo del token, eventi dati CloudTrail e revoca d’emergenza. Questi controlli continuano a reggere dopo normali modifiche alle policy?
Quella risposta conta più della prima richiesta riuscita. L’accesso a Claude Platform on AWS ora supporta tre ambienti con un unico abbonamento, ma il suo valore di sicurezza dipende da una prova ripetibile dell’isolamento.
