AWS DevOps Sicurezza degli agenti

Funziona in modo indipendente con le proprie configurazioni e autorizzazioni

Definisce a quali AWS account e risorse può accedere l'agente

Stabilisce connessioni a piattaforme di terze parti

Le richieste di inferenza provenienti dall'Unione Europea verranno elaborate all'interno dell'Unione Europea.

Le richieste di inferenza provenienti dagli Stati Uniti verranno elaborate all'interno degli Stati Uniti.

Le richieste di inferenza provenienti dall'Australia verranno elaborate all'interno dell'Australia.

Le richieste di inferenza provenienti dal Giappone verranno elaborate all'interno del Giappone.

Se una richiesta di inferenza proviene da un'area non elencata, verrà elaborata per impostazione predefinita negli Stati Uniti.

DevOps Agent e Bedrock non sono influenzati dalle politiche dei clienti contenute nelle Service Control Policies (SCP) o nella Control Tower che limitano i contenuti dei clienti a regioni specifiche

Bedrock può utilizzare regioni diverse da quella di origine all'interno dell'area geografica dell'utente per eseguire inferenze senza stato per ottimizzare le prestazioni e la disponibilità

Asia Pacifico (Singapore) – ap-southeast-1

Asia Pacifico (Mumbai) – ap-south-1

Sud America (San Paolo) – sa-east-1

AWS Integrazione con Identity Center: il metodo di autenticazione principale utilizza OAuth 2.0 con autenticazione basata sulla sessione tramite cookie. HTTP-only AWS Identity Center può connettersi con provider di identità esterni tramite protocolli OIDC e SAML standard, inclusi provider come Okta, Ping Identity e Microsoft Entra ID. Questo metodo supporta l'autenticazione a più fattori tramite il tuo provider di identità. AWS Per impostazione predefinita, Identity Center ha una durata della sessione fino a 12 ore e può essere configurato per una durata desiderata.

Link di autenticazione IAM: un metodo alternativo fornisce l'accesso diretto all'app Web dalla console di AWS gestione utilizzando JWT-based token derivati da una sessione della console di gestione esistente AWS . Questa opzione è utile per valutare l' AWS DevOps agente prima di implementare l'integrazione completa con Identity Center e per ottenere l'accesso amministrativo se l'app web dell' AWS DevOps agente diventa inaccessibile tramite l'autenticazione basata su Identity Center. Le sessioni sono limitate a 10 minuti.

Ruolo principale dell'account: concede all'agente l'accesso alle risorse nell' AWS account in cui si crea l'Agent Space.

Ruoli secondari dell'account: concede all'agente l'accesso alle risorse in AWS account aggiuntivi collegati all'Agent Space.

Ruolo dell'app Web: consente agli utenti di accedere ai dati e ai risultati delle indagini degli AWS DevOps agenti nell'app Web.

Crittografia inattiva: tutti i dati vengono crittografati con chiavi AWS gestite.

Crittografia in transito: tutti i log, le metriche, gli elementi di conoscenza, i metadati dei ticket e altri dati recuperati vengono crittografati durante il transito all'interno della rete privata dell'agente e verso le reti esterne.

Registra ogni ragionamento, passo e azione intrapresa

Crea una trasparenza completa nei processi decisionali degli agenti

Non può essere modificato dagli agenti una volta registrato, riducendo al minimo gli attacchi, ad esempio l'iniezione tempestiva, e nascondendo azioni importanti

Includi tutti i messaggi di chat dalla pagina Indagine

La richiesta che è stata fatta all'agente

L'indirizzo IP dal quale è stata effettuata la richiesta

L'utente che ha effettuato la richiesta

Quando è stata effettuata

Funzionalità di scrittura limitate: gli strumenti a disposizione dell'agente non sono in grado di modificare le risorse, ad eccezione dell'apertura di ticket e dei casi di supporto. Ciò impedisce che istruzioni dannose modifichino l'infrastruttura o le applicazioni.

Applicazione dei limiti degli account: l' AWS DevOps agente opera solo entro i limiti consentiti dai ruoli assegnati all'agente negli account primario e secondario connesso. AWS L'agente non può accedere o modificare risorse al di fuori dell'ambito configurato.

Protezioni di sicurezza AI: AWS DevOps l'agente utilizza modelli con protezioni AI Safety Level 3 (ASL-3), che includono classificatori integrati che rilevano e resistono ai tentativi di iniezione tempestivi. L'agente utilizza anche il filtro di attacco rapido di Amazon Bedrock Guardrails per rilevare e bloccare i tentativi di prompt injection e jailbreak prima che possano influire sul comportamento dell'agente.

Audit trail immutabile: il diario dell'agente registra tutte le motivazioni e le azioni intraprese. Le voci del diario non possono essere modificate dall'agente una volta registrate, impedendo agli attacchi di prompt injection di nascondere azioni dannose.

Strumenti server MCP personalizzati: la funzionalità Bring-Your-Own MCP consente di introdurre strumenti personalizzati all'agente, il che può offrire ulteriori opportunità di iniezione immediata. Gli strumenti personalizzati potrebbero non avere gli stessi controlli di sicurezza degli strumenti nativi AWS DevOps dell'agente e istruzioni dannose potrebbero potenzialmente utilizzare questi strumenti in modi non intenzionali. Per ulteriori informazioni, consulta la sezione Modello di responsabilità condivisa.

Attacchi da parte degli utenti autorizzati: gli utenti autorizzati a operare all'interno dei confini dell' AWS account o degli strumenti connessi hanno maggiori probabilità di tentare un attacco contro l'agente. Questi utenti possono avere la possibilità di modificare le fonti di dati utilizzate dall'agente, come registri o tag di risorse, facilitando l'incorporamento di istruzioni dannose che l'agente elaborerà.

Integrazioni bidirezionali native: Built-in integrazioni in grado di inviare dati all'agente e ricevere aggiornamenti dall'agente. Questo utilizza i metodi di autenticazione del fornitore

Server MCP: server Remote Model Context Protocol che utilizzano flussi di autenticazione OAuth 2.0 e chiavi API per comunicare in modo sicuro con sistemi esterni.

Trigger Webhook: trigger di indagine provenienti da servizi remoti come ticket o sistemi di osservabilità. I webhook utilizzano le firme HMAC ( Hash-based Message Authentication Code) o una chiave API (token portante) per motivi di sicurezza.

Comunicazione in uscita: integrazioni come Slack e i sistemi di ticketing ricevono aggiornamenti dall'agente ma non supportano ancora la comunicazione bidirezionale.

GitHub— Utilizza il flusso OAuth per l'autenticazione. Dopo la registrazione GitHub a livello di account, ogni Agent Space può connettersi a repository specifici all'interno dell'organizzazione. GitHub

Dynatrace: utilizza l'autenticazione tramite token OAuth. Dopo aver registrato Dynatrace a livello di account, ogni Agent Space può connettersi a specifici ambienti Dynatrace o configurazioni di monitoraggio.

Slack: utilizza l'autenticazione tramite token OAuth. Dopo aver registrato Slack a livello di account, ogni Agent Space può connettersi a canali Slack specifici.

Datadog: utilizza MCP con flusso OAuth per l'autenticazione. Dopo aver registrato Datadog a livello di account, ogni Agent Space può connettersi a specifiche risorse di monitoraggio di Datadog.

New Relic: utilizza l'autenticazione con chiave API. Dopo aver registrato New Relic a livello di account, ogni Agent Space può connettersi a specifiche configurazioni di monitoraggio di New Relic.

Splunk: utilizza l'autenticazione con token al portatore. Dopo aver registrato Splunk a livello di account, ogni Agent Space può connettersi a specifiche fonti di dati Splunk.

GitLab— Utilizza l'autenticazione tramite token di accesso. Dopo la registrazione GitLab a livello di account, ogni Agent Space può connettersi a GitLab repository specifici.

ServiceNow— Utilizza l'autenticazione del client OAuth. key/token Dopo la registrazione ServiceNow a livello di account, ogni Agent Space può connettersi a ServiceNow istanze o code di ticket specifiche.

Server MCP remoti accessibili al pubblico generico: utilizza il flusso OAuth per l'autenticazione. Dopo aver registrato un server MCP remoto a livello di account, ogni Agent Space può connettersi a risorse specifiche esposte da quel server.

Strumenti ospitati privatamente: se i tuoi strumenti sono raggiungibili da un AWS VPC, puoi utilizzare le connessioni private degli AWS DevOps agenti per mantenere il traffico isolato verso AWS le reti e lontano dalla rete Internet pubblica. Per ulteriori informazioni, consulta Connessione a strumenti ospitati privatamente.

Strumenti ospitati pubblicamente: se i tuoi strumenti sono raggiungibili tramite Internet pubblico e utilizzano gli elenchi di indirizzi IP consentiti o le regole del firewall, devi consentire il traffico in entrata dai seguenti indirizzi IP di origine dell'agente: AWS DevOps

Mantenimento della sicurezza dei dati recuperati dall'agente

Protezione degli strumenti nativi disponibili per l'uso da parte dell'agente

Protezione dell'infrastruttura su cui è in esecuzione Agent AWS DevOps

Gestire l'accesso degli utenti allo spazio degli agenti

Limitazione dell'accesso agli utenti fidati di sistemi esterni che forniscono input all'agente, ad esempio servizi e risorse che producono registri, CloudTrail eventi, ticket e altro, che possono essere utilizzati per tentare l'iniezione di prompt dannosi.

Assicurati che tutte le fonti di dati connesse dispongano di dati affidabili che difficilmente verranno utilizzati per tentare attacchi di prompt injection

Garantire che le integrazioni dei server MCP bring-your-own funzionino in modo sicuro

Garantire che i ruoli IAM assegnati all'agente abbiano un ambito adeguato

Redazione dei dati PII prima di archiviarli nei log di osservabilità e in altre fonti di dati degli agenti

Seguendo la pratica consigliata di concedere solo autorizzazioni di sola lettura alle origini dati connesse, inclusi i server MCP bring-your-own