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à.
AWS DevOps Sicurezza degli agenti
Questo documento fornisce informazioni su considerazioni relative alla sicurezza, alla protezione dei dati, ai controlli degli accessi e alle funzionalità di conformità per AWS DevOps Agent. Utilizzate queste informazioni per comprendere in che modo AWS DevOps Agent è progettato per soddisfare i requisiti di sicurezza e conformità.
Sicurezza a più livelli
AWS DevOps L'agente implementa la sicurezza a più livelli. Anche se vengono concesse autorizzazioni più ampie al ruolo IAM dell'agente, l'agente applica i propri controlli di accesso interni per limitare l'ambito delle sue azioni.
Consigliamo di seguire il principio del privilegio minimo durante la configurazione delle autorizzazioni IAM per l' AWS DevOps agente e l'implementazione della sicurezza a più livelli. Una difesa approfondita garantisce che nessuna singola configurazione errata possa compromettere la sicurezza dell'ambiente.
Agent Spaces
Gli Agent Spaces fungono da limite di sicurezza principale in AWS DevOps Agent. Ogni spazio per 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
Agent Spaces mantiene un rigoroso isolamento per garantire la sicurezza e prevenire accessi involontari tra diversi ambienti o team.
Elaborazione e flusso di dati a livello regionale
AWS DevOps L'agente opera a livello globale con funzionalità di elaborazione regionali. L'agente recupera i dati operativi dalle AWS regioni di tutti gli AWS account a cui è concesso l'accesso all'interno dell'Agent Space configurato. Questa raccolta di dati su più account in più regioni garantisce un'analisi completa degli incidenti rispettando i confini geografici per l'elaborazione delle inferenze.
Utilizzo di Amazon Bedrock e inferenza tra regioni
AWS DevOps L'agente selezionerà automaticamente la regione ottimale all'interno della tua area geografica per elaborare le tue richieste di inferenza. Ciò ottimizza le risorse di elaborazione disponibili, la disponibilità dei modelli e offre la migliore esperienza al cliente. I dati rimarranno archiviati solo nella regione in cui viene creato Agent Space, tuttavia, le richieste di input e i risultati di output potrebbero essere elaborati al di fuori di tale regione, come descritto nell'elenco seguente. Tutti i dati verranno trasmessi crittografati attraverso la rete sicura di Amazon.
AWS DevOps L'agente indirizzerà in modo sicuro le richieste di inferenza alle risorse di calcolo disponibili all'interno dell'area geografica in cui ha avuto origine la richiesta, come segue:
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 d'America.
DevOps Agent e Bedrock non sono influenzati dalle politiche dei clienti in Service Control Policies (SCPs) o Control Tower che limitano i contenuti dei clienti a regioni specifiche
Bedrock può utilizzare regioni diverse dalla regione di origine all'interno della vostra area geografica per eseguire inferenze senza stato e ottimizzare prestazioni e disponibilità
Gestione dell’identità e degli accessi
Metodi di autenticazione
AWS DevOps Agent fornisce due metodi di autenticazione per accedere all'app web Agent Space: AWS DevOps
AWS Integrazione con Identity Center: il metodo di autenticazione principale utilizza la OAuth versione 2.0 con autenticazione basata sulla sessione utilizzando cookie solo HTTP. AWS Identity Center può federarsi 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 L'impostazione predefinita di Identity Center prevede una durata delle sessioni fino a 12 ore e può essere configurato sulla durata desiderata.
Link di autenticazione IAM: un metodo alternativo fornisce l'accesso diretto all'app Web dalla console di AWS gestione utilizzando token basati su JWT 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 di 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.
Ruoli IAM
AWS DevOps L'agente utilizza i ruoli IAM per definire le autorizzazioni di accesso:
Ruolo dell'account principale: concede all'agente l'accesso alle risorse dell' AWS account in cui viene creato l'Agent Space, nonché l'accesso ai ruoli dell'account secondario.
Ruoli dell'account secondario: 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 dell' AWS DevOps agente nell'app Web.
Questi ruoli devono essere configurati secondo il principio del privilegio minimo, che concede solo le autorizzazioni di sola lettura necessarie per le indagini.
Protezione dei dati
Crittografia dei dati
AWS DevOps L'agente crittografa tutti i dati dei clienti:
Crittografia a riposo: tutti i dati sono crittografati con chiavi AWS gestite.
Crittografia in transito: tutti i log, le metriche, le informazioni, i metadati dei ticket e altri dati recuperati vengono crittografati in transito all'interno della rete privata dell'agente e verso reti esterne.
Archiviazione e conservazione dei dati
I dati vengono archiviati nella regione in cui viene creato il tuo Agent Space, mentre l'elaborazione delle inferenze può avvenire all'interno della tua area geografica, come descritto nella precedente sezione sull'utilizzo di Amazon Bedrock.
Informazioni personali identificabili (PII)
AWS DevOps L'agente non filtra le informazioni PII quando riepiloga i dati raccolti durante le indagini, le valutazioni dei consigli o le risposte alle chat. Si consiglia di oscurare i dati PII prima di archiviarli nei registri di osservabilità.
Registrazione del diario e degli audit degli agenti
Diario dell'agente
Entrambe le funzionalità di indagine e prevenzione degli incidenti mantengono diari dettagliati che:
Registra ogni fase di ragionamento e le azioni intraprese
Crea una trasparenza completa nei processi decisionali degli agenti
Non può essere modificato dagli agenti una volta registrato, in modo da ridurre al minimo gli attacchi, come l'iniezione tempestiva, che nascondono azioni importanti
Includi tutti i messaggi di chat dalla pagina Indagine
AWS CloudTrail integrazione
Tutte le chiamate AWS DevOps Agent API vengono acquisite automaticamente AWS CloudTrail dall' AWS account di hosting. Utilizzando le informazioni raccolte da CloudTrail, è possibile determinare:
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
Protezione da iniezione rapida
Un attacco di pronta iniezione si verifica quando un aggressore incorpora istruzioni dannose in dati esterni, come una pagina Web o un documento, che un sistema di intelligenza artificiale generativa elaborerà successivamente. AWS DevOps L'agente utilizza nativamente molte fonti di dati nell'ambito delle sue normali operazioni, inclusi log, tag di risorse e altri dati operativi. AWS DevOps Agent protegge dagli attacchi di pronta iniezione attraverso le seguenti misure di sicurezza, ma è importante garantire che tutte le fonti di dati connesse e l'accesso degli utenti a tali fonti di dati siano affidabili. Per ulteriori informazioni, consulta la sezione Modello di responsabilità condivisa.
Protezioni per l'iniezione rapida:
Capacità di scrittura limitate: gli strumenti a disposizione dell'agente non sono in grado di modificare le risorse, ad eccezione dell'apertura di ticket e richieste di assistenza. In questo modo si evita che istruzioni dannose modifichino l'infrastruttura o le applicazioni.
Applicazione dei limiti dell'account: AWS DevOps l'agente opera solo entro i limiti consentiti dai ruoli assegnati all'agente negli account secondari primari e collegati. 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). Queste protezioni includono classificatori che rilevano e prevengono gli attacchi di pronta iniezione prima che possano influire sul comportamento degli agenti.
Audit trail immutabile: il diario dell'agente registra ogni fase di ragionamento e ogni azione intrapresa. Le voci del diario non possono essere modificate dall'agente una volta registrate, per evitare che gli attacchi di prompt injection nascondano azioni dannose.
Sebbene AWS DevOps Agent fornisca più livelli di protezione contro gli attacchi di prompt injection, alcune configurazioni possono aumentare il rischio:
Strumenti server MCP personalizzati: la funzione bring-your-own MCP consente di introdurre strumenti personalizzati per l'agente, che possono offrire ulteriori opportunità di iniezione tempestiva. Gli strumenti personalizzati potrebbero non avere gli stessi controlli di sicurezza degli strumenti nativi di AWS DevOps Agent e istruzioni dannose potrebbero potenzialmente sfruttare questi strumenti in modi non intenzionali. Per ulteriori informazioni, consulta la sezione Modello di responsabilità condivisa.
Attacchi utente autorizzati: gli utenti autorizzati a operare entro i limiti 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 i log o i tag delle risorse, facilitando l'incorporazione di istruzioni dannose che l'agente elaborerà.
Per mitigare questi rischi:
Esamina e testa attentamente i server MCP personalizzati prima di distribuirli in Agent Spaces.
Assicurati che siano autorizzati a eseguire solo azioni di sola lettura
Verificate che gli utenti degli strumenti esterni a cui accedono i server MCP siano entità attendibili, poiché AWS DevOps gli agenti che si interfacciano con MCP si basano sulla relazione di fiducia implicita stabilita tra questi utenti dello strumento e l'agente AWS DevOps
Applica il principio del privilegio minimo quando concedi agli utenti l'accesso ai sistemi che forniscono dati all'agente
Controlla regolarmente quali server MCP sono collegati ai tuoi Agent Spaces
Poiché qualsiasi contenuto recuperato dalla lista consentita URLs potrebbe tentare di manipolare il comportamento dell'agente, includi nella lista delle autorizzazioni solo fonti attendibili.
Sicurezza dell'integrazione
AWS DevOps Agent supporta diversi tipi di integrazione, ognuno con il proprio modello di sicurezza:
Integrazioni bidirezionali native: integrazioni integrate 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: attivatori di indagine provenienti da servizi remoti come ticket o sistemi di osservabilità. I webhook utilizzano il codice di autenticazione dei messaggi basato su Hash (HMAC) 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.
Fornitori di registrazione
Alcuni strumenti esterni sono autenticati a livello di account e condivisi tra tutti gli Agent Spaces dell'account. Quando si registrano questi strumenti, ci si autentica una volta a livello di account, quindi ogni Agent Space può connettersi a risorse specifiche all'interno di quella connessione registrata.
I seguenti strumenti utilizzano la registrazione a livello di account:
GitHub— Utilizza il OAuth flusso 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 flow per l'autenticazione. OAuth Dopo aver registrato Datadog a livello di account, ogni Agent Space può connettersi a risorse di monitoraggio Datadog specifiche.
New Relic: utilizza l'autenticazione tramite chiave API. Dopo aver registrato New Relic a livello di account, ogni Agent Space può connettersi a specifiche configurazioni di monitoraggio New Relic.
Splunk: utilizza l'autenticazione con token bearer. Dopo aver registrato Splunk a livello di account, ogni Agent Space può connettersi a fonti di dati Splunk specifiche.
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 OAuth del client 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 OAuth flow 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.
La connettività di rete
AWS DevOps L'agente si connette ai sistemi di terze parti e ai server MCP remoti per eseguire indagini e altre operazioni.
Traffico in entrata dall' AWS DevOps agente ai tuoi sistemi
AWS DevOps L'agente avvia connessioni in uscita verso i sistemi di terze parti e i server MCP remoti, che arrivano come traffico in entrata all'infrastruttura. Il modo in cui proteggi questo traffico dipende da come sono ospitati i tuoi strumenti:
Strumenti ospitati privatamente: se i tuoi strumenti sono raggiungibili dall'interno di un AWS VPC, puoi utilizzare le connessioni private degli AWS DevOps agenti per mantenere il traffico isolato dalle AWS reti e lontano dalla rete Internet pubblica. Per ulteriori informazioni, consulta Connessione a strumenti ospitati privatamente.
Strumenti ospitati pubblicamente: se gli strumenti sono raggiungibili sulla rete Internet pubblica e utilizzano l'elenco degli indirizzi IP consentiti o le regole del firewall, è necessario consentire il traffico in entrata dai seguenti indirizzi IP di origine dell'agente: AWS DevOps
Asia Pacifico (Sydney) (ap-southeast-2)
13.237.95.19713.238.84.10252.64.174.242
Asia Pacifico (Tokyo) (ap-northeast-1)
13.192.12.23335.74.181.23057.183.50.158
Europa (Francoforte) (eu-central-1)
18.158.110.14052.57.96.16052.59.55.56
Europa (Irlanda) (eu-west-1)
34.251.85.2452.30.157.15752.51.192.222
Stati Uniti orientali (Virginia settentrionale) (us-east-1)
34.228.181.12844.219.176.18754.226.244.221
Stati Uniti occidentali (Oregon) (us-west-2)
34.212.16.13352.89.67.21254.187.135.61
Traffico in uscita dal tuo AWS DevOps VPC all'agente
Per il traffico in uscita dal tuo AWS VPC AWS DevOps all'agente (ad esempio, Richiamo DevOps dell'agente tramite Webhook utilizzando), puoi utilizzare gli endpoint VPC per mantenere questo traffico di rete isolato dalle reti. AWS Per ulteriori informazioni, consulta Endpoint VPC (AWS PrivateLink).
Modello di responsabilità condivisa
AWS responsabilità
AWS è responsabile di:
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
Responsabilità del cliente
I clienti sono responsabili di:
Gestione dell'accesso degli utenti allo spazio degli agenti
Limitazione dell'accesso a utenti affidabili 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 tempestiva di informazioni dannose.
Assicurati che tutte le fonti di dati connesse dispongano di dati affidabili che è improbabile che vengano utilizzati per tentare attacchi di pronta iniezione
Garantire che le integrazioni dei server bring-your-own MCP funzionino in modo sicuro
Garantire che i ruoli IAM assegnati all'agente abbiano un ambito adeguato
Oscurare i dati PII prima di archiviarli nei registri di osservabilità e in altre fonti di dati degli agenti
Seguendo la pratica consigliata di concedere solo autorizzazioni di sola lettura alle fonti di dati connesse, inclusi i server MCP bring-your-own
Utilizzo dei dati
AWS non utilizza i dati degli agenti, i messaggi di chat o i dati provenienti da fonti di dati integrate per addestrare modelli o migliorare il prodotto. AWS DevOps Agent Space utilizza il feedback dei clienti integrato nel prodotto per migliorare le risposte e le indagini degli agenti, ma AWS non lo utilizza per migliorare il servizio stesso.
