Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Modello di sicurezza e autorizzazioni per le istanze di runtime
Quando ospiti agenti sul tipo di elaborazione Instances, i tuoi agenti vengono eseguiti su istanze Amazon EC2 nel tuo account. AWS Ciò modifica il modello di responsabilità condivisa rispetto al tipo di elaborazione MicroVM serverless: le istanze vengono eseguite nel tuo account e nel tuo VPC, gli agenti vengono eseguiti con le autorizzazioni del ruolo di esecuzione in fase di esecuzione e i dati su di essi rimangono nel tuo account. Questo argomento descrive il modello di sicurezza per le istanze, le autorizzazioni coinvolte e le pratiche da seguire per le implementazioni multi-tenant.
Questo argomento integra le Runtime-wide linee guida contenute nelle best practice di sicurezza per Runtime. AgentCore Le pratiche in vigore (privilegio minimo IAM, autenticazione, crittografia, sicurezza di rete e controllo) si applicano anche alle istanze. Per sapere come vengono crittografati i volumi EBS collegati alle sessioni, consulta Encryption at rest for Runtime Instances.
Argomenti
Modello di sicurezza
-
L'istanza è nel tuo account: le istanze EC2 avviate da un fornitore di capacità vengono eseguite nel tuo account e VPC come istanze gestite da Amazon EC2. Puoi ispezionarle, applicare i tuoi controlli e verificarne l'attività tramite i log di flusso VPC presenti nel tuo CloudTrail account.
-
Gli agenti su un'istanza non sono isolati l'uno dall'altro: più agenti possono essere eseguiti sulla stessa istanza e condividerne il file system. Gli agenti vengono eseguiti sull'istanza in contenitori o, per gli agenti distribuiti direttamente, come processi direttamente sull'istanza: nessuno dei due fornisce un limite di sicurezza tra i carichi di lavoro sulla stessa istanza. Tutti gli agenti che condividono un'istanza devono essere considerati attendibili reciprocamente.
-
La sessione è l'unità di isolamento: una sessione, identificata dalla combinazione di fornitore di capacità e ID di sessione, viene mappata su un'istanza EC2 (1:1). Lo stesso ID di sessione in due diversi fornitori di capacità si riferisce a due sessioni diverse su due istanze diverse. Gli agenti che intendi tenere isolati gli uni dagli altri non devono condividere una sessione.
-
Credential vending: fornisce AgentCore le credenziali del ruolo di esecuzione agli agenti in esecuzione sull'istanza e le aggiorna periodicamente. Qualsiasi codice in esecuzione sull'istanza può leggere le credenziali a sua disposizione. Assegna l'ambito del ruolo di esecuzione di ogni runtime al privilegio minimo richiesto dal relativo agente. Per ulteriori informazioni, vedere Gestione delle credenziali.
-
Si applicano i controlli dell'account: poiché le istanze vengono eseguite nel tuo account, le politiche di controllo dei servizi (SCP), i limiti di autorizzazione e i controlli VPC della tua AWS organizzazione regolano le azioni intraprese nel tuo account. AgentCore agisce in base al ruolo di infrastruttura che fornisci o approvi; applicalo alle condizioni IAM (ad esempio, a VPC, sottoreti o tipi di istanza specifici). L'eccezione è costituita dal ruolo AgentCore collegato ai servizi utilizzato per eliminare e ripulire le risorse, che non è limitato dagli SCP, in linea con il modo in cui vengono trattati i ruoli collegati ai servizi in generale. AWS
-
Residenza dei dati: gli agenti funzionano nel VPC, nelle sottoreti, nell'account e nella regione specificati dall'utente e i dati della sessione e i volumi EBS rimangono nel tuo account.
Autorizzazioni richieste
L'hosting degli agenti sulle istanze prevede i seguenti ruoli, oltre al ruolo di esecuzione del runtime dell'agente che concede al codice dell'agente le autorizzazioni di runtime.
-
Profilo dell'istanza: collegato all'istanza EC2. AgentCore lo utilizza per raccogliere i log di sistema dall'istanza; non concede autorizzazioni al codice dell'agente (il ruolo di esecuzione del runtime dell'agente fa questa operazione).
-
Ruolo di infrastruttura: AgentCore assume questo ruolo per fornire e gestire le istanze EC2 presenti nel tuo account per tuo conto, avviando, etichettando e configurando la rete per le istanze e le relative interfacce di rete. Poiché questo ruolo concede AgentCore l'autorizzazione a gestire l'elaborazione nel tuo account, assegna il privilegio minimo richiesto dai carichi di lavoro e utilizza le condizioni IAM per limitarlo a VPC, sottoreti o tipi di istanza specifici, se del caso.
Per i passaggi di configurazione del ruolo, consulta Guida introduttiva alle istanze. Inizia a usare Instances
Routing delle sessioni e isolamento multi-tenant
AgentCore Il runtime autorizza le chiamate sulla risorsa di runtime dell'agente ARN, non sulle singole sessioni.
Quando si richiama un agente, si fornisce un e si AgentCore convalida il formato di tale ID di sessioneruntimeSessionId, ma non si verifica che appartenga all'identità chiamante. Ciò ha una conseguenza importante per le implementazioni multi-tenant:
Importante
Nelle implementazioni in cui un singolo responsabile IAM invoca per conto di più utenti finali, la piattaforma non impone che a appartenga all'utente chiamantesessionId. Sei responsabile di garantire che il backend passi correttamente per utente. sessionId
Se più utenti finali condividono lo stesso principio IAM (ad esempio, un unico ruolo di esecuzione del backend che richiede InvokeAgentRuntime tutti gli utenti) e il backend non associa le sessioni agli utenti, un utente autenticato può fornire l'ID di sessione di un altro utente e indirizzare una richiesta alla sessione di quell'utente. Le seguenti pratiche attenuano questo problema.
Applica l'associazione tra sessione e utente nel tuo backend
Implementa l'associazione sessione-utente a livello di applicazione nel tuo backend. Mantieni la mappatura tra ciascun utente finale e i relativi ID di sessione nell'applicazione e assicurati che una richiesta per un utente non possa mai essere emessa con quella di un altro utente. runtimeSessionId Consideralo un valore lato server derivato dall'utente finale autenticato: non accettarlo mai direttamente da un input non attendibile del client. runtimeSessionId Per le implementazioni condivise e multi-tenant, l'associazione a livello di applicazione nel backend è il controllo che impedisce a un utente di indirizzare una richiesta alla sessione di un altro utente.
Utilizza principi IAM distinti per implementazioni multi-tenant ad alta sicurezza
Per le implementazioni multi-tenant ad alta sicurezza, utilizza principi IAM distinti per utente finale (o per gruppo di tenant) per richiamare gli agenti, anziché un singolo principale condiviso. Quando ogni utente o tenant richiama tramite il proprio principal, IAM stesso impone l'ambito della sessione: un principal può richiamare solo i runtime consentiti dalla sua policy, il che rimuove la classe condivisa principale del rischio di routing della sessione. Questo è il controllo più efficace ed è consigliato ogni volta che l'implementazione è in grado di supportare i principali per utente o per tenant.
Revisione e monitoraggio
Usa l'auditing per rilevare il routing delle sessioni, la ricognizione e gli accessi anomali:
-
Correlate l'ID principale e quello di sessione: AWS CloudTrail registra sia il principale autenticato che il destinatario nello stesso evento.
sessionIdInvokeAgentRuntimeUsalo per rilevare un indirizzamento principale a una sessione creata da un altro principale. -
Applica le pratiche Runtime-wide di controllo: abilita CloudTrail e VPC Flow Logs, correla i log utilizzando gli ID di richiesta e configura filtri metrici e allarmi come descritto in Controllo e monitoraggio. Controllo e monitoraggio
Best practice
-
Separa i carichi di lavoro per livello di attendibilità: utilizza sessioni diverse per carichi di lavoro che non sono attendibili reciprocamente. Non collocate agenti non attendibili nella stessa sessione.
-
Applica il privilegio minimo a ogni ruolo: assegna il ruolo di esecuzione del runtime dell'agente e il ruolo dell'infrastruttura solo alle azioni e alle risorse di cui ciascuno ha bisogno.
-
Associa le sessioni agli utenti del backend: per qualsiasi distribuzione in cui un principale serve più utenti finali, applica il binding da sessione a utente a livello di applicazione.
-
Preferisci i principali per utente o per tenant: laddove possibile, richiama tramite principali IAM distinti in modo che IAM applichi l'ambito della sessione.
-
Monitoraggio del routing interprincipale: da utilizzare per rilevare anomalie di routing, CloudTrail ad esempio il routing principale verso una sessione creata da un altro principale.
Per indicazioni Runtime-wide sulla sicurezza che si applicano anche alle istanze, consulta le best practice di sicurezza per Runtime. AgentCore
