Best practice di sicurezza per AgentCore Runtime

• Comprendi il limite di isolamento: ogni sessione utente viene eseguita in una microVM dedicata con CPU, memoria e file system isolati. I comandi e il codice dell'agente non possono accedere ai carichi di lavoro degli altri clienti o sfuggire ai limiti delle macchine virtuali. Dopo il completamento della sessione, l'intera microVM viene terminata e la memoria viene disinfettata.

• Applica le mappature da sessione a utente nel backend: non impone le mappature da sessione a utente. AgentCore Il backend del client deve mantenere la relazione tra gli utenti e i relativi ID di sessione e implementare la gestione del ciclo di vita, ad esempio il numero massimo di sessioni per utente.

• Fai attenzione al comportamento di autorizzazione dei file system: quando utilizzi file system persistenti, le autorizzazioni vengono archiviate ma non applicate all'interno della sessione. chmode stat funzionano correttamente, ma i controlli di accesso hanno sempre esito positivo perché l'agente viene eseguito come unico utente nella MicroVM.

• Comprendi l'esposizione delle credenziali all'interno della macchina virtuale: qualsiasi codice o attore in esecuzione all'interno della microVM può accedere alle credenziali del ruolo di esecuzione chiamando l'endpoint dei metadati (MMDS). Definisci attentamente le autorizzazioni del ruolo di esecuzione. Per ulteriori informazioni, consulta Gestione delle credenziali.

• Non utilizzare CLI-generated le policy in produzione: le policy IAM create dalla AgentCore CLI sono progettate per scopi di sviluppo e test. Queste autorizzazioni garantiscono un ampio accesso e non sono adatte alla produzione. Crea policy IAM personalizzate che limitano le autorizzazioni solo alle risorse e alle azioni specifiche richieste. Per il riferimento completo, consulta IAM Permissions for AgentCore Runtime.

• Ambita le autorizzazioni per ARN di runtime specifici: evita le dichiarazioni di risorse wildcard. Usa l'ARN completo delle tue risorse di runtime nei campi delle policy Resource IAM.

• Limita InvokeAgentRuntimeForUser: solo i responsabili affidabili dovrebbero avere questa autorizzazione. Adattalo a risorse di runtime specifiche utilizzando le condizioni delle risorse IAM.

• Nega la delega degli ID utente dove non è necessaria: per i runtime in cui non è richiesta la delega degli ID utente, nega esplicitamente l'azione:

  {
     "Statement": [
        {
           "Sid": "DenyUserIdDelegation",
           "Effect": "Deny",
           "Action": "bedrock-agentcore:InvokeAgentRuntimeForUser",
           "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT_ID:runtime/*"
        }
     ]
  }

• Impedisci l'escalation dei privilegi: assicurati che il ruolo di esecuzione associato al runtime disponga di privilegi uguali o inferiori a quelli dei principali che possono richiamarlo. Per ulteriori informazioni, consulta Gestione delle credenziali.

• Usa le chiavi di condizione IAM per applicare le implementazioni VPC: bedrock-agentcore:subnets utilizza le chiavi bedrock-agentcore:securityGroups e condiziona per richiedere che tutti i runtime siano distribuiti in VPC approvati. Per esempi, consulta Usare le chiavi di condizione VPC con AgentCore Runtime.

• Usa IAM Access Analyzer: convalida le tue policy IAM per assicurarti che aderiscano alle migliori pratiche e ai principi dei privilegi minimi.

• Comprendi l'autorizzazione gerarchica: per operazioni di runtime API comeInvokeAgentRuntime, and InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, AWS valuta le policy sia sul runtime dell'agente che sull'endpoint dell'agente. Entrambi devono consentire l'azione.

• Configura entrambe le risorse per l'accesso su più account: per concedere l'accesso a più account, crea policy basate sulle risorse sia sul runtime dell'agente che sull'endpoint dell'agente. Se una delle due risorse non dispone di un'autorizzazione esplicita, la richiesta viene rifiutata.

• Ricorda che la negazione esplicita vince sempre: se una politica (basata sull'identità o basata sulle risorse) nega esplicitamente un'azione, l'accesso viene negato indipendentemente dalle altre politiche.

• Usa aws:SourceArn e aws:SourceAccount: aggiungi queste condizioni alla tua politica di fiducia per i ruoli di esecuzione per limitare AgentCore le risorse che possono assumere il ruolo:

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "bedrock-agentcore.amazonaws.com"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
          "StringEquals": {
            "aws:SourceAccount": "123456789012"
          },
          "ArnLike": {
            "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:*"
          }
        }
      }
    ]
  }

• Usa l'ARN completo quando possibile: se conosci la risorsa di runtime specifica, usa l'ARN completo al posto dei caratteri jolly. aws:SourceArn

• Policy-based autorizzazione: utilizza il motore di policy del gateway per controllare quali chiamanti possono invocare quali obiettivi e in quali condizioni. Per ulteriori informazioni, consulta Utilizzare le policy per controllare l'accesso alle destinazioni del gateway.

• Guardrails: applica Amazon Bedrock Guardrails tramite il motore di policy per esaminare richieste e risposte. Per ulteriori informazioni, consulta Use guardrails nelle policy.

• Intercettori di richieste e risposte: ispeziona o trasforma il traffico con le funzioni Lambda di intercettazione configurate sul gateway.

• Runtime IAM (SigV4): allega una policy basata sulle risorse che limita l'invocazione al ruolo di esecuzione del gateway. Vedi Limita la chiamata in entrata di IAM (SigV4) al tuo gateway.

• Runtime OAuth (JWT): configura sull'autorizzatore del runtime. allowedWorkloadConfiguration Vedi Limita l'invocazione al tuo gateway.

• Scegli il metodo di autenticazione giusto: utilizza IAM SigV4 per le chiamate da servizio a servizio all'interno di. AWS Usa l'autenticazione con token JWT bearer quando gli utenti finali si autenticano direttamente tramite un provider di identità. Un runtime può supportare un metodo alla volta; crea versioni separate per diversi tipi di autenticazione.

• Preferisci JWT-based l'identificazione degli utenti per la produzione: quando il tuo agente recupera i token OAuth per conto degli utenti finali, preferisci il JWT bearer token path (GetWorkloadAccessTokenForJWT), che convalida l'emittente, la firma e la scadenza del token. Il UserId percorso (GetWorkloadAccessTokenForUserId/X-Amzn-Bedrock-AgentCore-Runtime-User-Idheader) tratta l'identificatore utente come una stringa opaca senza la verifica dell'IdP: utilizzalo solo per lo sviluppo, gli scenari di avvio rapido o le architetture aziendali che risolvono l'identità dell'utente a monte. Per ulteriori informazioni, consulta Get workload access token.

• Configura completamente gli autorizzatori JWT: quando utilizzi l'autenticazione JWT, configura tutti i campi di convalida disponibili: URL di rilevamento, destinatari consentiti, client consentiti, ambiti consentiti e attestazioni personalizzate obbligatorie.

• Non codificare mai i token nel codice di produzione: utilizza meccanismi sicuri di recupero dei token. I token hardcoded rappresentano un rischio per la sicurezza nel controllo del codice sorgente e negli artefatti implementati.

• Deriva l'ID utente dal principale autenticato: se si utilizza l'X-Amzn-Bedrock-AgentCore-Runtime-User-Idintestazione, il valore deve essere derivato dal contesto del principale autenticato (identità del chiamante IAM o attestazioni del token utente), non da valori arbitrari forniti dal client. Ciò impedisce agli utenti autenticati di impersonare altri utenti.

• Nega ForUserId dove non è necessario: per i carichi di lavoro che hanno sempre un JWT disponibile, nega esplicitamente e nelle politiche IAM. bedrock-agentcore:GetWorkloadAccessTokenForUserId bedrock-agentcore:InvokeAgentRuntimeForUser Ciò garantisce che tutte le identificazioni degli utenti passino attraverso il percorso JWT verificato crittograficamente.

• Configura le policy degli endpoint VPC per il tuo metodo di autenticazione: le policy degli endpoint VPC possono limitare solo i chiamanti in base ai principi IAM, non agli utenti OAuth. Per OAuth-based le richieste, imposta nella policy dell'endpoint. Principal * Per SigV4-based l'autenticazione, specifica le identità IAM consentite.

• Usa AgentCore Identity per l'autenticazione in uscita: AgentCore Identity gestisce le credenziali OAuth e le chiavi API in modo sicuro, impedendo l'esposizione delle credenziali nel codice o nei log dell'agente. Usalo per tutti gli accessi ai servizi di terze parti (Slack, Zoom). GitHub

• Comprendi l'esposizione delle credenziali MMDS: il MicroVM Metadata Service (MMDS) fornisce le credenziali del ruolo di esecuzione a qualsiasi codice in esecuzione nella macchina virtuale, in modo simile all'IMDS di EC2. Limita le autorizzazioni dei ruoli di esecuzione solo a ciò che richiede il tuo agente.

• Abilita MMDSv2: a partire dal 30 giugno 2026, i runtime degli agenti devono avere MMDSv2 abilitato. I runtime senza MMDSv2 abilitato non possono essere richiamati e restituiscono un. ValidationException Per abilitarlo, chiama UpdateAgentRuntime with set to in. requireMMDSV2 true metadataConfiguration Per ulteriori informazioni sulla risoluzione di questo errore, vedere Risoluzione dei problemi di MMDSv2 ValidationException .

• Esegui i contenitori come utenti non root: quando crei immagini di container personalizzate, configurale per l'esecuzione come utente non root. Ciò limita l'impatto delle potenziali vulnerabilità legate all'esecuzione del codice.

• Credenziali autonome e delegate dall'utente: utilizza l'autenticazione delegata dall'utente (Authorization Code Grant) quando l'agente agisce per conto di un utente specifico. Utilizza l'autenticazione autonoma (Client Credentials Grant) quando l'agente opera in modo indipendente.

• Implementa i runtime in un VPC per l'accesso alle risorse private: configura la connettività VPC per accedere a database privati, API interne e servizi senza esporli a Internet. Per i dettagli sulla configurazione, consulta Configure AgentCore Runtime for VPC.

• Utilizzo AWS PrivateLink per l'accesso all'API: crea endpoint VPC di interfaccia per il piano AgentCore dati (com.amazonaws.region.bedrock-agentcore) e il piano di controllo () per evitare l'com.amazonaws.region.bedrock-agentcore-controlattraversamento di Internet. Per ulteriori informazioni, consulta Use. AWS PrivateLink

• Applica il privilegio minimo ai gruppi di sicurezza: definisci regole in uscita che consentano solo il traffico minimo richiesto. Non aprite un ampio accesso in uscita a meno che non sia necessario.

• Configura gli endpoint VPC richiesti per gli agenti contenitore: per gli agenti VPC-mode contenitore, configura gli endpoint VPC per ECR (com.amazonaws.region.ecr.dkr,com.amazonaws.region.ecr.api), S3 (endpoint com.amazonaws.region.s3 gateway) e Logs (). CloudWatch com.amazonaws.region.logs L'endpoint gateway S3 elimina i costi di elaborazione dei dati del gateway NAT per l'acquisizione del livello di immagine ECR.

• Ambito della policy degli endpoint del gateway S3 per gli agenti container: limita la policy degli endpoint del gateway S3 solo al bucket utilizzato da Amazon ECR per lo storage a livello di immagine:

  {
    "Statement": [
      {
        "Sid": "AllowECRLayerAccess",
        "Principal": "*",
        "Action": [
          "s3:GetObject"
        ],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::prod-region-starport-layer-bucket/*"]
      }
    ]
  }

  Sostituiscilo region con l'identificatore AWS della tua regione (ad esempio,). us-east-2

• Ambita la policy degli endpoint del gateway S3 per gli agenti di distribuzione diretta del codice: per le distribuzioni basate su zip, limita la policy al bucket di artifact di codice interno di proprietà del servizio. Aggiungi una aws:PrincipalServiceName condizione per garantire che solo il responsabile del servizio possa accedere ai bucket tramite questa policy sugli endpoint: AgentCore

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": [
          "arn:aws:s3:::acr-code-*-region-an",
          "arn:aws:s3:::acr-code-*-region-an/*"
        ],
        "Condition": {
          "StringEquals": {
            "aws:PrincipalServiceName": "bedrock-agentcore.amazonaws.com"
          }
        }
      }
    ]
  }

  regionSostituiscilo con il tuo identificatore di AWS regione (ad esempio,). us-west-2 I bucket di elementi del AgentCore codice vengono creati nei bucket generici dello spazio dei nomi regionali Account. Solo AWS può possedere i nomi effettivi dei bucket utilizzati dal servizio. La aws:PrincipalServiceName condizione garantisce che solo il responsabile del AgentCore servizio possa accedere ai bucket tramite questa politica degli endpoint. Se utilizzi anche file system persistenti, aggiungi il bucket di archiviazione della sessione a questa politica. Per ulteriori informazioni, consulta Configurare AgentCore Runtime for VPC.

• Usa sottoreti private con gateway NAT: le sottoreti pubbliche non forniscono l'accesso a Internet per Runtime. AgentCore Posiziona sempre gli ENI di runtime in sottoreti private con un percorso verso un gateway NAT per l'accesso a Internet in uscita.

• Sicurezza del trasporto: tutte le connessioni utilizzano TLS 1.2 o versioni successive. WebSocket le connessioni, inclusoInvokeAgentRuntimeCommandShell, utilizzano esclusivamente WSS (WebSocket Secure) su HTTPS. Le ws:// connessioni in testo semplice non sono supportate.

• Applica i limiti di intestazione: le intestazioni personalizzate sono limitate a 4 KB per valore e 20 intestazioni per runtime. L'Authorizationintestazione è riservata agli agenti con accesso in entrata OAuth.

• Crittografia in transito: tutte le comunicazioni tra client e AgentCore Runtime e tra AgentCore Runtime e le sue dipendenze sono protette tramite TLS 1.2 o versioni successive. È configurato di default e non richiede alcuna configurazione aggiuntiva.

• Crittografia a riposo: per impostazione predefinita, i dati inattivi vengono crittografati utilizzando AWS chiavi di crittografia di AWS proprietà del AWS Key Management Service (KMS).

• Usa TLS 1.3 ove possibile: sebbene TLS 1.2 sia il minimo, AWS consiglia TLS 1.3 per migliorare la sicurezza e le prestazioni.

• Abilita CloudTrail la registrazione: AWS CloudTrail registra le chiamate APIInvokeAgentRuntime, tra cui, InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, e le operazioni del piano di controllo. Ogni record include l'identità del chiamante, il timestamp, l'indirizzo IP di origine e lo stato della risposta.

• Usa CloudWatch Logs per il controllo dei comandi: AgentCore Runtime invia l'ID della richiesta e il comando di input al gruppo di log Logs dell'agente. CloudWatch Utilizza questi registri per mantenere una traccia di controllo dei comandi eseguiti nelle sessioni.

• Correla i log utilizzando gli ID di richiesta: utilizza l'ID della richiesta per correlare CloudTrail i record (chi ha chiamato l'API) con CloudWatch i log (quale comando è stato eseguito).

• Configura filtri metrici e allarmi: configura i filtri metrici CloudWatch Logs per rilevare schemi di comando imprevisti o tentativi di accesso non autorizzati. Crea allarmi per notificare al tuo team eventuali anomalie.

• Registra le relazioni di delega degli ID utente: quando utilizzi l'X-Amzn-Bedrock-AgentCore-Runtime-User-Idintestazione, registra la relazione tra il principale IAM autenticato e il valore dell'ID utente a fini di controllo.

• Abilita i log di flusso VPC: per i VPC-connected runtime, abilita i log di flusso VPC per controllare il traffico a livello di rete e identificare modelli di comunicazione imprevisti.

• Rivedi CloudTrail i log regolarmente: esamina periodicamente i log per individuare eventuali tentativi di accesso non autorizzati, in particolare per carichi di lavoro sensibili.

AWS responsabilità:

• Infrastruttura sicura e isolamento delle microVM a livello hardware

• Applicazione di patch al kernel del sistema operativo per tutte le modalità di distribuzione

• Applicazione di patch in fase di esecuzione del linguaggio per distribuzioni dirette di codice

• Sicurezza dell'infrastruttura di rete

• Disponibilità e resilienza del servizio

Le tue responsabilità:

• Sicurezza del codice degli agenti e gestione delle dipendenze

• Controlli degli accessi e politiche delle risorse IAM

• Sicurezza dei comandi eseguiti nelle sessioni di runtime

• Session-to-user applicazione della mappatura

• Aggiornamenti delle immagini dei container (per le implementazioni in container): ricostruisci regolarmente con l'immagine di base sicura più recente

• Convalida dell'input e prevenzione tempestiva dell'iniezione, inclusa la convalida dell'InvokeHarnessinput quando si utilizza l'harness gestito (vedere Harness shares the Runtime trust boundary) AgentCore

• Configurazione di rete (gruppi di sicurezza, endpoint VPC, tabelle di routing)

• InvokeAgentRuntimeCommand— One-shot, esecuzione di comandi non interattiva over. HTTP/2 Azione IAM:bedrock-agentcore:InvokeAgentRuntimeCommand.

• InvokeAgentRuntimeCommandShell— Sessione WebSocket shell interattiva con accesso PTY persistente. Azione IAM:bedrock-agentcore:InvokeAgentRuntimeCommandShell.

• Comprendi i limiti di sicurezza: i comandi hanno pieno accesso al filesystem del contenitore e a qualsiasi credenziale o segreto configurato all'interno della microVM. Il limite di isolamento è la microVM stessa. In base al modello di responsabilità condivisa, l'utente è responsabile della sicurezza di qualsiasi codice eseguito nel contenitore di runtime.

• Usa operazioni deterministiche per attività deterministiche: utilizza InvokeAgentRuntimeCommand or InvokeAgentRuntimeCommandShell per operazioni come test, git e build. Non indirizzate le operazioni deterministiche attraverso il LLM via. InvokeAgentRuntime

• Limita chi può eseguire i comandi: utilizza le politiche IAM per limitare i principali che possono chiamare o. InvokeAgentRuntimeCommand InvokeAgentRuntimeCommandShell Non tutti gli utenti che possono invocare un agente dovrebbero essere in grado di eseguire comandi arbitrari. Esempio di risorsa ARN:. arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent

• WebSocket shell utilizza solo wss://: InvokeAgentRuntimeCommandShell le connessioni vengono stabilite esclusivamente tramite WSS (WebSocket Secure). Le ws:// connessioni in testo semplice non sono supportate. I chiamanti si autenticano tramite SigV4 al momento dell'aggiornamento. WebSocket

• Mantieni il traffico all'interno della tua rete: configura gli endpoint VPC per evitare l'attraversamento di Internet per le chiamate API di esecuzione dei comandi.

• Imposta i timeout appropriati: configura i timeout dei comandi in base alla durata di esecuzione prevista per evitare lo spreco di risorse dovuto ai processi inattivi.

• Limita l'accesso a localhost nel codice dell'agente: configura il tuo agente e tutti gli strumenti di rete per impedire l'accesso illimitato a localhost. Il codice dell'agente non deve effettuare chiamate HTTP arbitrarie a localhost a meno che non sia richiesto per un'integrazione specifica.

• Allowlist richiede solo le porte per le configurazioni secondarie: se l'architettura utilizza un pattern container-in-container o sidecar su localhost, allowlist esplicitamente solo le porte specifiche utilizzate dai servizi sidecar. Non aprite un accesso generalizzato ai localhost.

• Controlla gli strumenti di rete per la copertura di localhost: esamina tutti gli strumenti che fornisci al tuo agente (come gli strumenti di richiesta HTTP o le utilità di rete generali) per assicurarti che non possano effettuare richieste involontarie agli endpoint localhost. Applica il filtraggio degli URL o l'elenco consentito a livello di strumento.