AgentCore 런타임의 보안 모범 사례

• 격리 경계 이해 - 각 사용자 세션은 격리된 CPU, 메모리 및 파일 시스템이 있는 전용 microVM에서 실행됩니다. 명령 및 에이전트 코드는 다른 고객의 워크로드에 액세스하거나 VM 경계를 이스케이프할 수 없습니다. 세션이 완료되면 전체 microVM이 종료되고 메모리가 삭제됩니다.

• 백엔드에서 session-to-user AgentCore는 session-to-user 적용하지 않습니다. 클라이언트 백엔드는 사용자와 세션 IDs 간의 관계를 유지하고 사용자당 최대 세션 수와 같은 수명 주기 관리를 구현해야 합니다.

• 파일 시스템 권한 동작에 유의 - 영구 파일 시스템을 사용하는 경우 권한이 저장되지만 세션 내에 적용되지 않습니다. chmod 및는 올바르게 stat 작동하지만 에이전트가 microVM에서 유일한 사용자로 실행되므로 액세스 검사는 항상 성공합니다.

• VM 내 자격 증명 노출 이해 - microVM 내에서 실행되는 모든 코드 또는 액터는 메타데이터 엔드포인트(MMDS)를 호출하여 실행 역할 자격 증명에 액세스할 수 있습니다. 실행 역할 권한의 범위를 신중하게 지정합니다. 자세한 내용은 자격 증명 관리를 참조하세요.

• 프로덕션 환경에서 CLI 생성 정책을 사용하지 마세요 - AgentCore CLI에서 생성한 IAM 정책은 개발 및 테스트 목적으로 설계되었습니다. 이러한 권한은 광범위한 액세스 권한을 부여하며 프로덕션에 적합하지 않습니다. 필요한 특정 리소스 및 작업으로만 권한을 제한하는 사용자 지정 IAM 정책을 생성합니다. 전체 참조는 AgentCore 런타임에 대한 IAM 권한을 참조하세요.

• 특정 런타임 ARNs- 와일드카드 리소스 문을 사용하지 마세요. IAM 정책 Resource 필드에서 런타임 리소스의 전체 ARN을 사용합니다.

• 제한 InvokeAgentRuntimeForUser- 신뢰할 수 있는 보안 주체만이 권한을 가져야 합니다. IAM 리소스 조건을 사용하여 특정 런타임 리소스로 범위를 지정합니다.

• 필요하지 않은 경우 사용자 ID 위임 거부 - 사용자 ID 위임이 필요하지 않은 런타임의 경우 작업을 명시적으로 거부합니다.

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

• 권한 에스컬레이션 방지 - 런타임과 연결된 실행 역할이 이를 호출할 수 있는 보안 주체와 같거나 적은 권한을 가지고 있는지 확인합니다. 자세한 내용은 자격 증명 관리를 참조하세요.

• IAM 조건 키를 사용하여 VPC 배포 적용 - bedrock-agentcore:subnets 및 bedrock-agentcore:securityGroups 조건 키를 사용하여 모든 런타임이 승인된 VPCs에 배포되도록 요구합니다. 예제는 AgentCore 런타임에서 VPC 조건 키 사용을 참조하세요.

• IAM Access Analyzer 사용 - IAM 정책을 검증하여 모범 사례와 최소 권한 원칙을 준수하는지 확인합니다.

• 계층적 권한 부여 이해 - InvokeAgentRuntime, InvokeAgentRuntimeCommand및와 같은 런타임 API 작업의 경우는 에이전트 런타임과 에이전트 엔드포인트 모두에 대한 정책을 InvokeAgentRuntimeCommandShell AWS 평가합니다. 둘 다 작업을 허용해야 합니다.

• 교차 계정 액세스를 위한 두 리소스 구성 - 교차 계정 액세스 권한을 부여하려면 에이전트 런타임과 에이전트 엔드포인트 모두에 리소스 기반 정책을 생성합니다. 리소스에 명시적 허용이 없는 경우 요청이 거부됩니다.

• 명시적 거부는 항상 성공합니다. 정책(자격 증명 기반 또는 리소스 기반)이 작업을 명시적으로 거부하면 다른 정책에 관계없이 액세스가 거부됩니다.

• aws:SourceArn 및 사용 aws:SourceAccount- 실행 역할 신뢰 정책에 다음 조건을 추가하여 역할을 수임할 수 있는 AgentCore 리소스를 제한합니다.

  {
    "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:*"
          }
        }
      }
    ]
  }

• 가능하면 전체 ARN 사용 - 특정 런타임 리소스를 알고 있는 경우 와일드카드 aws:SourceArn 대신에서 전체 ARN을 사용합니다.

• 정책 기반 권한 부여 - 게이트웨이의 정책 엔진을 사용하여 어떤 호출자가 어떤 대상을 어떤 조건에서 호출할 수 있는지 제어합니다. 자세한 내용은 정책을 사용하여 게이트웨이 대상에 대한 액세스 제어를 참조하세요.

• 가드레일 - 정책 엔진을 통해 Amazon Bedrock 가드레일을 적용하여 요청 및 응답을 검사합니다. 자세한 내용은 정책에서 가드레일 사용을 참조하세요.

• 요청 및 응답 인터셉터 - 게이트웨이에 구성된 인터셉터 Lambda 함수를 사용하여 트래픽을 검사하거나 변환합니다.

• IAM(SigV4) 런타임 - 게이트웨이의 실행 역할에 대한 호출을 제한하는 리소스 기반 정책을 연결합니다. 게이트웨이에 대한 IAM(SigV4) 인바운드 호출 제한을 참조하세요.

• OAuth(JWT) 런타임 - 런타임의 권한 부여자에 allowedWorkloadConfiguration를 구성합니다. 게이트웨이에 대한 호출 제한을 참조하세요.

• 올바른 인증 방법 선택 service-to-service 호출에 IAM SigV4를 사용합니다 AWS. 최종 사용자가 자격 증명 공급자를 통해 직접 인증할 때 JWT 보유자 토큰 인증을 사용합니다. 런타임은 한 번에 하나의 메서드를 지원할 수 있으며, 다양한 인증 유형에 대해 별도의 버전을 생성할 수 있습니다.

• 프로덕션을 위한 JWT 기반 사용자 식별 선호 - 에이전트가 최종 사용자를 대신하여 OAuth 토큰을 검색할 때 토큰의 발급자, 서명 및 만료를 검증하는 JWT 보유자 토큰 경로(GetWorkloadAccessTokenForJWT)를 선호합니다. UserId 경로(GetWorkloadAccessTokenForUserId/ X-Amzn-Bedrock-AgentCore-Runtime-User-Id 헤더)는 IdP 확인 없이 사용자 식별자를 불투명 문자열로 취급합니다. 이는 사용자 ID 업스트림을 해결하는 개발, 빠른 시작 시나리오 또는 엔터프라이즈 아키텍처에만 사용합니다. 자세한 내용은 워크로드 액세스 토큰 가져오기를 참조하세요.

• JWT 권한 부여자 완전 구성 - JWT 인증을 사용하는 경우 검색 URL, 허용된 대상, 허용된 클라이언트, 허용된 범위 및 필요한 사용자 지정 클레임과 같은 사용 가능한 모든 검증 필드를 구성합니다.

• 프로덕션 코드에 토큰을 하드코딩하지 않음 - 보안 토큰 검색 메커니즘을 사용합니다. 하드코딩된 토큰은 소스 제어 및 배포된 아티팩트의 보안 위험입니다.

• 인증된 보안 주체로부터 사용자 ID 도출 - X-Amzn-Bedrock-AgentCore-Runtime-User-Id 헤더를 사용하는 경우 값은 임의의 클라이언트 제공 값이 아닌 인증된 보안 주체의 컨텍스트(IAM 호출자 자격 증명 또는 사용자 토큰 클레임)에서 파생되어야 합니다. 이렇게 하면 인증된 사용자가 다른 사용자를 가장하는 것을 방지할 수 있습니다.

• 필요하지 않은 경우 ForUserId 거부 - 항상 JWT를 사용할 수 있는 워크로드의 경우 IAM 정책bedrock-agentcore:InvokeAgentRuntimeForUser에서 bedrock-agentcore:GetWorkloadAccessTokenForUserId 및를 명시적으로 거부합니다. 이렇게 하면 모든 사용자 식별이 암호화로 확인된 JWT 경로를 통과할 수 있습니다.

• 인증 방법에 대한 VPC 엔드포인트 정책 구성 - VPC 엔드포인트 정책은 OAuth 사용자가 아닌 IAM 보안 주체를 기반으로 호출자만 제한할 수 있습니다. OAuth 기반 요청의 경우 엔드포인트 정책*에서를 Principal 로 설정합니다. SigV4-based 인증에서 허용되는 IAM 자격 증명을 지정합니다.

• 아웃바운드 인증에 AgentCore 자격 증명 사용 - AgentCore 자격 증명은 OAuth 자격 증명 및 API 키를 안전하게 관리하여 에이전트 코드 또는 로그의 자격 증명 노출을 방지합니다. 모든 타사 서비스 액세스(Slack, GitHub, Zoom)에 사용합니다.

• MMDS 자격 증명 노출 이해 - MicroVM 메타데이터 서비스(MMDS)는 EC2의 IMDS와 마찬가지로 VM에서 실행되는 모든 코드에 실행 역할 자격 증명을 제공합니다. 에이전트에 필요한 만큼만 실행 역할 권한의 범위를 지정합니다.

• MMDSv2 활성화 - 2026년 6월 30일부터 에이전트 런타임에 MMDSv2가 활성화되어 있어야 합니다. MMDSv2가 활성화되지 않은 런타임은 호출할 수 없으며를 반환합니다ValidationException. 활성화하려면 true에서가 로 requireMMDSV2 설정된 UpdateAgentRuntime를 호출합니다metadataConfiguration. 이 오류 해결에 대한 자세한 내용은 MMDSv2 ValidationException 문제 해결을 참조하세요.

• 루트가 아닌 사용자로 컨테이너 실행 - 사용자 지정 컨테이너 이미지를 빌드할 때 루트가 아닌 사용자로 실행되도록 구성합니다. 이는 잠재적 코드 실행 취약성의 영향을 제한합니다.

• 별도의 사용자 위임 자격 증명과 자율 자격 증명 - 에이전트가 특정 사용자를 대신하여 작업할 때 사용자 위임 인증(권한 부여 코드)을 사용합니다. 에이전트가 독립적으로 작동할 때 자율 인증(클라이언트 자격 증명 부여)을 사용합니다.

• 프라이빗 리소스 액세스를 위해 VPC에 런타임 배포 - 인터넷에 노출되지 않고 프라이빗 데이터베이스, 내부 APIs 및 서비스에 액세스하도록 VPC 연결을 구성합니다. 구성 세부 정보는 VPC용 AgentCore 런타임 구성을 참조하세요.

• API 액세스를 위한 Use AWS PrivateLink - 인터넷 순회를 방지하기 위해 AgentCore 데이터 영역(com.amazonaws.region.bedrock-agentcore) 및 컨트롤 플레인(com.amazonaws.region.bedrock-agentcore-control)에 대한 인터페이스 VPC 엔드포인트를 생성합니다. 자세한 내용은 Use AWS PrivateLink를 참조하세요.

• 보안 그룹에 최소 권한 적용 - 최소 필수 트래픽만 허용하는 아웃바운드 규칙을 정의합니다. 필요한 경우가 아니면 광범위한 아웃바운드 액세스를 열지 마십시오.

• 컨테이너 에이전트에 필요한 VPC 엔드포인트 구성 - VPC 모드 컨테이너 에이전트의 경우 ECR(, com.amazonaws.region.ecr.dkrcom.amazonaws.region.ecr.api), S3(com.amazonaws.region.s3게이트웨이 엔드포인트) 및 CloudWatch Logs()에 대한 VPC 엔드포인트를 구성합니다com.amazonaws.region.logs. S3 게이트웨이 엔드포인트는 ECR 이미지 계층 풀에 대한 NAT 게이트웨이 데이터 처리 요금을 제거합니다.

• 컨테이너 에이전트에 대한 S3 게이트웨이 엔드포인트 정책 범위 지정 - Amazon ECR이 이미지 계층 스토리지에 사용하는 버킷으로만 S3 게이트웨이 엔드포인트 정책을 제한합니다.

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

  를 AWS 리전 식별자(예: us-east-2)region로 바꿉니다.

• 직접 코드 배포 에이전트에 대한 S3 게이트웨이 엔드포인트 정책 범위 지정 - zip 기반 배포의 경우 정책을 내부 서비스 소유 코드 아티팩트 버킷으로 제한합니다. AgentCore 서비스 보안 주체만이 엔드포인트 정책을 통해 버킷에 액세스할 수 있도록 aws:PrincipalServiceName 조건을 추가합니다.

  {
    "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"
          }
        }
      }
    ]
  }

  를 AWS 리전 식별자(예: us-west-2)region로 바꿉니다. AgentCore 코드 아티팩트 버킷은 계정 리전 네임스페이스 범용 버킷에 생성됩니다. 만 서비스에서 사용하는 실제 버킷 이름을 소유할 AWS 수 있습니다. 이 aws:PrincipalServiceName 조건은 AgentCore 서비스 보안 주체만이 엔드포인트 정책을 통해 버킷에 액세스할 수 있도록 합니다. 영구 파일 시스템도 사용하는 경우이 정책에 세션 스토리지 버킷을 추가합니다. 자세한 내용은 VPC용 AgentCore 런타임 구성을 참조하세요.

• NAT 게이트웨이와 함께 프라이빗 서브넷 사용 - 퍼블릭 서브넷은 AgentCore 런타임에 대한 인터넷 액세스를 제공하지 않습니다. 아웃바운드 인터넷 액세스를 위해 NAT 게이트웨이로 가는 경로가 있는 프라이빗 서브넷에 런타임 ENIs를 항상 배치합니다.

• 전송 보안 - 모든 연결은 TLS 1.2 이상을 사용합니다. 를 포함한 WebSocket 연결은 HTTPS를 통해서만 WSS(WebSocket Secure)를 InvokeAgentRuntimeCommandShell사용합니다. 일반 텍스트 ws:// 연결은 지원되지 않습니다.

• 헤더 제한 적용 - 사용자 지정 헤더는 값당 4KB 및 런타임당 20개의 헤더로 제한됩니다. Authorization 헤더는 OAuth 인바운드 액세스 권한이 있는 에이전트용으로 예약되어 있습니다.

• 전송 중 암호화 - 클라이언트와 AgentCore 런타임 간의 모든 통신과 AgentCore 런타임과 해당 종속성 간의 모든 통신은 TLS 1.2 이상을 사용하여 보호됩니다. 이는 기본적으로 구성되며 추가 설정이 필요하지 않습니다.

• 유휴 데이터 암호화 - 유휴 데이터는 기본적으로 AWS Key Management Service(AWS KMS)의 AWS 소유 암호화 키를 사용하여 암호화됩니다.

• 가능한 경우 TLS 1.3 사용 - TLS 1.2가 최소이지만 보안 및 성능 향상을 위해 TLS 1.3을 AWS 권장합니다.

• CloudTrail 로깅 활성화 - AWS CloudTrail은 InvokeAgentRuntime, InvokeAgentRuntimeCommandShell, 및 컨트롤 플레인 작업을 포함한 API 호출InvokeAgentRuntimeCommand을 기록합니다. 각 레코드에는 발신자 자격 증명, 타임스탬프, 소스 IP 주소 및 응답 상태가 포함됩니다.

• 명령 감사에 CloudWatch Logs 사용 - AgentCore 런타임은 요청 ID와 입력 명령을 에이전트의 CloudWatch Logs 로그 그룹에 전송합니다. 이러한 로그를 사용하여 세션에서 실행되는 명령의 감사 추적을 유지합니다.

• 요청 IDs를 사용하여 로그 상호 연결 - 요청 ID를 사용하여 CloudTrail 레코드(API라고 함)를 CloudWatch Logs(실행된 명령)와 상호 연결합니다.

• 지표 필터 및 경보 설정 - 예상치 못한 명령 패턴 또는 무단 액세스 시도를 감지하도록 CloudWatch Logs 지표 필터를 구성합니다. 경보를 생성하여 팀에 이상을 알립니다.

• 사용자 ID 위임 관계 로깅 - X-Amzn-Bedrock-AgentCore-Runtime-User-Id 헤더를 사용할 때 감사 목적으로 인증된 IAM 보안 주체와 사용자 ID 값 간의 관계를 로깅합니다.

• VPC 흐름 로그 활성화 - VPC에 연결된 런타임의 경우 VPC 흐름 로그를 활성화하여 네트워크 수준 트래픽을 감사하고 예상치 못한 통신 패턴을 식별합니다.

• CloudTrail 로그를 정기적으로 검토 - 특히 민감한 워크로드에 대한 무단 액세스 시도가 있는지 로그를 정기적으로 검토합니다.

AWS 책임:

• 하드웨어 수준에서 인프라 및 microVM 격리 보호

• 모든 배포 모드에 대한 OS 커널 패치 적용

• 직접 코드 배포를 위한 언어 런타임 패치

• 네트워크 인프라 보안

• 서비스 가용성 및 복원력

사용자의 책임:

• 에이전트 코드 보안 및 종속성 관리

• IAM 액세스 제어 및 리소스 정책

• 런타임 세션에서 실행되는 명령의 보안

• Session-to-user 매핑 적용

• 컨테이너 이미지 업데이트(컨테이너 배포용) - 최신 보안 기본 이미지로 정기적으로 재구축

• 입력 검증 및 프롬프트 주입 방지 - 관리형 하네스 사용 시 InvokeHarness 입력 검증 포함(Harnessshare the AgentCore 런타임 신뢰 경계 참조)

• 네트워크 구성(보안 그룹, VPC 엔드포인트, 라우팅 테이블)

• InvokeAgentRuntimeCommand - HTTP/2를 통한 원샷, 비대화형 명령 실행. IAM 작업: bedrock-agentcore:InvokeAgentRuntimeCommand.

• InvokeAgentRuntimeCommandShell - 영구 PTY 액세스 권한이 있는 대화형 WebSocket 셸 세션입니다. IAM 작업: bedrock-agentcore:InvokeAgentRuntimeCommandShell.

• 보안 경계 이해 - 명령은 컨테이너 파일 시스템과 microVM 내에서 구성된 자격 증명 또는 보안 암호에 대한 전체 액세스 권한을 가집니다. 격리 경계는 microVM 자체입니다. 공동 책임 모델에 따라 런타임 컨테이너에서 실행되는 모든 코드의 보안에 대한 책임은 사용자에게 있습니다.

• 결정적 작업에 결정적 작업 사용 - 테스트, git 및 빌드와 같은 InvokeAgentRuntimeCommandShell 작업에 InvokeAgentRuntimeCommand 또는를 사용합니다. 를 통해 LLM을 통해 결정적 작업을 라우팅하지 마세요InvokeAgentRuntime.

• 명령을 실행할 수 있는 사용자 제한 - IAM 정책을 사용하여 InvokeAgentRuntimeCommand 또는를 호출할 수 있는 보안 주체를 제한합니다InvokeAgentRuntimeCommandShell. 에이전트를 호출할 수 있는 모든 사용자가 임의의 명령을 실행할 수 있는 것은 아닙니다. 리소스 ARN의 예: arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent.

• WebSocket 셸은 wss://만 사용합니다. InvokeAgentRuntimeCommandShell 연결은 WSS(WebSocket Secure)를 통해서만 설정됩니다. 일반 텍스트 ws:// 연결은 지원되지 않습니다. 호출자는 WebSocket 업그레이드 시 SigV4를 통해 인증합니다.

• 네트워크 내에 트래픽 유지 - 명령 실행 API 호출에 대한 인터넷 순회를 방지하도록 VPC 엔드포인트를 구성합니다.

• 적절한 제한 시간 설정 - 리소스 낭비가 런어웨이 프로세스에서 발생하지 않도록 예상 실행 기간에 따라 명령 제한 시간을 구성합니다.

• 에이전트 코드에서 localhost 액세스 제한 - localhost에 대한 무제한 액세스를 방지하도록 에이전트와 네트워킹 도구를 구성합니다. 에이전트 코드는 특정 통합에 필요한 경우가 아니면 localhost에 임의의 HTTP 호출을 해서는 안 됩니다.

• 사이드카 설정에 필요한 포트만 허용 목록 - 아키텍처가 localhost에서 컨테이너 내 container-in-container 또는 사이드카 패턴을 사용하는 경우 사이드카 서비스에서 사용하는 특정 포트만 명시적으로 허용 목록으로 지정합니다. 광범위한 localhost 액세스를 열지 마십시오.

• 로컬 호스트 도달을 위한 네트워크 도구 감사 - 에이전트에 제공하는 도구(예: HTTP 요청 도구 또는 일반 네트워킹 유틸리티)를 검토하여 로컬 호스트 엔드포인트에 의도하지 않은 요청을 하지 않도록 합니다. 도구 수준에서 URL 필터링 또는 허용 목록을 적용합니다.