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à.

Limitazione dell'accesso degli agenti in un AWS Account

AWS DevOps L'agente utilizza i ruoli IAM per scoprire e descrivere AWS le risorse durante le indagini sugli incidenti e le valutazioni preventive. Puoi controllare il livello di accesso dell'agente configurando le policy IAM associate a questi ruoli. La topologia dell'applicazione non mostra tutto ciò a cui l'agente ha accesso: le policy IAM sono l'unico modo per limitare realmente le API e le risorse di AWS servizio a cui l'agente può accedere.

Comprendere i ruoli IAM per AWS DevOps Agente

AWS DevOps L'agente utilizza i ruoli IAM per accedere alle risorse in due tipi di account:

Per entrambi i tipi di account, è possibile limitare AWS i servizi a cui l'agente può accedere, limitare l'accesso a risorse specifiche all'interno di tali servizi e controllare in quali regioni l'agente può operare.

Comprendere i guardrail relativi alle autorizzazioni

AWS DevOps L'agente applica un guardrail di autorizzazione a ogni sessione che crea quando accede alle risorse. AWS Questo guardrail funge da limite: definisce il set massimo di autorizzazioni che l'agente può mai utilizzare, indipendentemente dalle autorizzazioni concesse al ruolo IAM.

Come funziona

Quando l'agente assume il tuo ruolo IAM, passa una policy di sessione che limita le autorizzazioni effettive per quella sessione. Le autorizzazioni effettive sono l'intersezione di:

Un'autorizzazione deve essere presente in entrambi i livelli per avere effetto. Se aggiungi un'autorizzazione al tuo ruolo che non è inclusa nel guardrail, l'agente non può utilizzarla.

Autorizzazioni predefinite

La policy AIDevOpsAgentAccessPolicy gestita fornisce il set predefinito di autorizzazioni di sola lettura che l'agente utilizza per le indagini. Queste autorizzazioni sono incluse nel guardrail, quindi funzionano senza configurazioni aggiuntive.

Estensione delle autorizzazioni oltre quelle predefinite

La policy AIDevOpsAgentAccessPolicy gestita predefinita garantisce solo un sottoinsieme di ciò che il guardrail consente. Il guardrail consente inoltre ogni azione della policy ReadOnlyAccess AWS gestita, oltre ad alcune autorizzazioni aggiuntive. Per utilizzare un'autorizzazione che il guardrail consente ma la politica predefinita non la concede, aggiungila al tuo ruolo di politica in linea.

Ad esempio, per consentire all'agente di leggere oggetti dai bucket S3 durante le indagini, aggiungi una policy in linea al tuo ruolo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-application-bucket",
        "arn:aws:s3:::my-application-bucket/*"
      ]
    }
  ]
}

Poiché s3:GetObject e s3:ListBucket sono inclusi nel guardrail, questa politica in linea ha effetto. È possibile definire l'ambito di due bucket specifici Resource per seguire il principio del privilegio minimo.

Autorizzazioni aggiuntive supportate

Puoi abilitare qualsiasi autorizzazione supportata dal guardrail aggiungendola al tuo ruolo come politica in linea. Questi non sono concessi per impostazione predefinita: è necessario attivarli esplicitamente.

Abbiamo completamente testato e verificato che solo le autorizzazioni della policy AIDevOpsAgentAccessPolicy gestita sono sicure per l'uso con l'agente. Le altre autorizzazioni supportate dal guardrail non sono state testate con l'agente. La loro attivazione rientra nel modello di responsabilità AWS condivisa. Sei responsabile di valutare se tali azioni sono appropriate per l'agente rispetto alle tue risorse. Definitele in modo da seguire il principio del privilegio minimo.

La tabella seguente elenca le autorizzazioni aggiuntive supportate dal guardrail oltre alla policy gestitaReadOnlyAccess.

Autorizzazioni bloccate dal guardrail

Se aggiungi un'autorizzazione al tuo ruolo che non si trova nel guardrail, l'agente non può utilizzarla. Questo è previsto: il guardrail impedisce all'agente di eseguire azioni al di fuori dell'ambito previsto, anche se il ruolo le consentirebbe altrimenti.

Ad esempio, operazioni di scrittura come s3:PutObjectec2:TerminateInstances, o non dynamodb:DeleteItem sono incluse nel guardrail. Anche se il tuo ruolo concede queste autorizzazioni, l'agente non può eseguire queste azioni.

Riepilogo

Questo modello garantisce che l'agente operi entro un limite di sicurezza ben definito, offrendoti al contempo la flessibilità necessaria per estendere le sue funzionalità per il tuo caso d'uso specifico.

Scelta dei limiti delle risorse

Quando si limita l'accesso alle risorse, è necessario includere autorizzazioni sufficienti affinché l'agente possa indagare correttamente sugli incidenti relativi alle applicazioni. Questo include:

L'infrastruttura di supporto può includere:

Se si limita l'accesso in modo troppo limitato, l'agente potrebbe non essere in grado di identificare le cause principali che hanno origine nell'infrastruttura di supporto al di fuori dei confini definiti.

Limitazione dell'accesso ai servizi

È possibile limitare AWS i servizi a cui l'agente può accedere modificando le politiche IAM associate ai ruoli dell'agente. Quando crei policy personalizzate, segui queste best practice:

Esempio di politica che limita a servizi specifici:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:DescribeAlarms",
        "logs:GetLogEvents",
        "logs:FilterLogEvents",
        "ec2:DescribeInstances",
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "*"
    }
  ]
}

Limitazione dell'accesso alle risorse

Per limitare l'agente a risorse specifiche all'interno di un servizio, utilizza le autorizzazioni a livello di risorsa nelle politiche IAM. Ciò consente di concedere l'accesso solo alle risorse che corrispondono a modelli specifici.

Utilizzo dei pattern ARN delle risorse:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "arn:aws:lambda:*:*:function:production-*"
    }
  ]
}

Questo esempio limita l'agente all'accesso solo alle funzioni Lambda con nomi che iniziano con «production-».

Utilizzo delle restrizioni basate sui tag:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "production"
        }
      }
    }
  ]
}

Questo esempio limita l'agente all'accesso solo alle istanze EC2 contrassegnate con. Environment=production

Limitazione dell'accesso regionale

Per limitare AWS le regioni a cui l'agente può accedere, utilizza la chiave di aws:RequestedRegion condizione nelle politiche IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "lambda:Get*",
        "cloudwatch:Get*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}

Questo esempio limita l'agente all'accesso alle risorse solo nelle regioni us-east-1 e us-west-2.

Creazione di policy IAM personalizzate

Quando si crea un Agent Space o si aggiungono account secondari, è possibile creare un ruolo IAM personalizzato utilizzando un modello di policy. Ciò consente di implementare il principio del privilegio minimo.

Quando si crea un Agent Space

Dalla console dell' DevOps agente nella console AWS di gestione...

Quando si modifica un Agent Space

Dalla console dell' DevOps agente nella console AWS di gestione...

Best practice relative alle policy personalizzate