기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
런타임 인스턴스에 대한 보안 모델 및 권한
인스턴스 컴퓨팅 유형에서 에이전트를 호스팅하면 에이전트가 자체 AWS 계정의 Amazon EC2 인스턴스에서 실행됩니다. 이렇게 하면 서버리스 microVM 컴퓨팅 유형과 비교하여 공동 책임 모델이 변경됩니다. 인스턴스는 계정 및 VPC에서 실행되고, 에이전트는 런타임 실행 역할의 권한으로 실행되며, 에이전트의 데이터는 계정에 유지됩니다. 이 주제에서는 인스턴스의 보안 모델, 관련 권한, 다중 테넌트 배포에 따라야 하는 사례에 대해 설명합니다.
이 주제에서는 AgentCore 런타임에 대한 보안 모범 사례의 런타임 전체 지침을 보완합니다. IAM 최소 권한, 인증, 암호화, 네트워크 보안 및 감사와 같은 해당 사례는 인스턴스에도 적용됩니다. 세션에 연결된 EBS 볼륨을 암호화하는 방법은 런타임 인스턴스의 유휴 시 암호화를 참조하세요.
보안 모델
-
인스턴스는 계정에 있습니다. 용량 공급자가 시작한 EC2 인스턴스는 계정에서 실행되고 VPC는 Amazon EC2 관리형 인스턴스로 실행됩니다. 계정의 CloudTrail 및 VPC 흐름 로그를 통해 이를 검사하고, 자체 컨트롤을 적용하고, 활동을 감사할 수 있습니다.
-
인스턴스의 에이전트는 서로 격리되지 않음 - 여러 에이전트가 동일한 인스턴스에서 실행되고 파일 시스템을 공유할 수 있습니다. 에이전트는 컨테이너의 인스턴스에서 실행되거나 직접 배포된 에이전트의 경우 인스턴스에서 직접 프로세스로 실행됩니다. 둘 다 동일한 인스턴스의 워크로드 간에 보안 경계를 제공하지 않습니다. 인스턴스를 공유하는 모든 에이전트는 상호 신뢰해야 합니다.
-
세션은 격리 단위입니다. 즉, 용량 공급자와 세션 ID의 조합으로 식별되는 세션이 하나의 EC2 인스턴스(1:1)에 매핑됩니다. 서로 다른 두 용량 공급자에서 동일한 세션 ID는 서로 다른 두 인스턴스에서 서로 다른 두 세션을 나타냅니다. 서로 격리된 상태로 유지하려는 에이전트는 세션을 공유해서는 안 됩니다.
-
자격 증명 벤딩 - AgentCore는 인스턴스에서 실행되는 에이전트에게 실행 역할 자격 증명을 제공하고 주기적으로 새로 고칩니다. 인스턴스에서 실행되는 모든 코드는 사용 가능한 자격 증명을 읽을 수 있습니다. 각 런타임의 실행 역할의 범위를 에이전트에 필요한 최소 권한으로 지정합니다. 자세한 내용은 자격 증명 관리를 참조하세요.
-
계정 제어 적용 - 인스턴스가 계정에서 실행되므로 AWS Organizations 서비스 제어 정책(SCPs), 권한 경계 및 VPC 제어가 계정에서 수행된 작업을 제어합니다. AgentCore는 사용자가 제공하거나 승인하는 인프라 역할을 통해 작동하며, IAM 조건(예: 특정 VPCs, 서브넷 또는 인스턴스 유형)으로 범위를 지정합니다. 단, SCPs에 의해 제한되지 않는 리소스를 삭제하고 정리하는 데 사용되는 AgentCore 서비스 연결 역할은 예외입니다. 이는가 서비스 연결 역할을 일반적으로 AWS 처리하는 방식과 일치합니다.
-
데이터 레지던시 - 에이전트는 지정한 VPC, 서브넷, 계정 및 리전에서 실행되며 세션 데이터 및 EBS 볼륨은 계정에 남아 있습니다.
필수 권한
인스턴스에서 에이전트를 호스팅하려면 에이전트 코드에 런타임 권한을 부여하는 에이전트 런타임 실행 역할 외에도 다음 역할이 필요합니다.
-
인스턴스 프로파일 - EC2 인스턴스에 연결됩니다. AgentCore는 이를 사용하여 인스턴스에서 시스템 로그를 수집하며, 에이전트 코드에 권한을 부여하지 않습니다(에이전트 런타임 실행 역할이 이를 수행함).
-
인프라 역할 - AgentCore는이 역할을 수임하여 사용자 대신 계정의 EC2 인스턴스를 프로비저닝하고 관리합니다. 즉, 인스턴스 및 해당 네트워크 인터페이스에 대한 네트워킹을 시작, 태그 지정 및 구성합니다. 이 역할은 계정에서 컴퓨팅을 관리할 수 있는 권한을 AgentCore에 부여하므로 워크로드에 필요한 최소 권한으로 범위를 지정하고 IAM 조건을 사용하여 적절한 경우 특정 VPCs, 서브넷 또는 인스턴스 유형으로 제한합니다.
역할 구성 단계는 인스턴스 시작하기를 참조하세요.
세션 라우팅 및 다중 테넌트 격리
AgentCore 런타임은 개별 세션이 아닌 에이전트 런타임 리소스 ARN에 대한 호출을 승인합니다.
에이전트를 호출할 때를 제공하면 runtimeSessionId AgentCore는 해당 세션 ID의 형식을 검증하지만 호출 자격 증명에 속하는지 확인하지 않습니다. 이는 멀티테넌트 배포에 중요한 결과를 초래합니다.
중요
단일 IAM 보안 주체가 여러 최종 사용자를 대신하여 호출하는 배포에서 플랫폼은가 호출하는 사용자에게 sessionId 속하도록 적용하지 않습니다. 백엔드가 사용자sessionId당 올바른를 전달하도록 하는 것은 사용자의 책임입니다.
여러 최종 사용자가 동일한 IAM 보안 주체(예: 모든 사용자를 InvokeAgentRuntime 호출하는 단일 백엔드 실행 역할)를 공유하고 백엔드가 사용자에게 세션을 바인딩하지 않는 경우 인증된 사용자는 다른 사용자의 세션 ID를 제공하고 요청을 해당 사용자의 세션으로 라우팅할 수 있습니다. 다음 방법은 이를 완화합니다.
백엔드에서 session-to-user 바인딩 적용
백엔드에서 애플리케이션 수준 session-to-user 바인딩을 구현합니다. 각 최종 사용자와 애플리케이션의 세션 IDs 간에 매핑을 유지하고 한 사용자에 대한 요청을 다른 사용자의 로 발행할 수 없도록 합니다runtimeSessionId. 를 인증된 최종 사용자로부터 파생된 runtimeSessionId 서버 측 값으로 취급합니다. 신뢰할 수 없는 클라이언트 입력에서 직접 수락하지 마십시오. 공유 보안 주체, 다중 테넌트 배포의 경우 백엔드의 애플리케이션 수준 바인딩은 한 사용자가 요청을 다른 사용자의 세션으로 라우팅하지 못하도록 하는 제어입니다.
보안이 뛰어난 다중 테넌트 배포에 고유한 IAM 보안 주체 사용
고보안 다중 테넌트 배포의 경우 단일 공유 보안 주체가 아닌 최종 사용자(또는 테넌트 그룹)별로 고유한 IAM 보안 주체를 사용하여 에이전트를 호출합니다. 각 사용자 또는 테넌트가 자체 보안 주체를 통해 호출하면 IAM 자체가 세션 범위 지정을 적용합니다. 보안 주체는 정책에서 허용하는 런타임만 호출할 수 있으며, 이는 세션 라우팅 위험의 공유-보안 주체 클래스를 제거합니다. 이는 가장 강력한 제어이며 배포가 사용자당 또는 테넌트당 보안 주체를 지원할 수 있을 때마다 권장됩니다.
감사 및 모니터링
감사를 사용하여 세션 라우팅 정찰 및 비정상적인 액세스를 감지합니다.
-
보안 주체와 세션 ID 상호 연결 - AWS CloudTrail은 인증된 보안 주체와 대상을
sessionId동일한InvokeAgentRuntime이벤트에 기록합니다. 이를 사용하여 다른 보안 주체가 생성한 세션으로의 보안 주체 라우팅을 감지합니다. -
런타임 전체 감사 사례 적용 - CloudTrail 및 VPC 흐름 로그를 활성화하고, 요청 IDs를 사용하여 로그를 상호 연관시키고, 감사 및 모니터링에 설명된 대로 지표 필터 및 경보를 설정합니다.
모범 사례
-
신뢰 수준별로 워크로드 분리 - 상호 신뢰하지 않는 워크로드에는 서로 다른 세션을 사용합니다. 동일한 세션에서 신뢰할 수 없는 에이전트를 함께 배치하지 마십시오.
-
모든 역할에 최소 권한 적용 - 에이전트 런타임 실행 역할과 인프라 역할의 범위를 각 역할에 필요한 작업과 리소스로만 지정합니다.
-
백엔드의 사용자에게 세션 바인딩 - 하나의 보안 주체가 여러 최종 사용자에게 서비스를 제공하는 배포의 경우 애플리케이션 계층에서 session-to-user 바인딩을 적용합니다.
-
사용자별 또는 테넌트별 보안 주체 선호 - 가능한 경우 IAM이 세션 범위를 적용하도록 개별 IAM 보안 주체를 통해 호출합니다.
-
교차 보안 주체 라우팅 모니터링 - CloudTrail을 사용하여 다른 보안 주체가 생성한 세션으로의 보안 주체 라우팅과 같은 라우팅 이상을 감지합니다.
인스턴스에도 적용되는 런타임 전체 보안 지침은 AgentCore 런타임의 보안 모범 사례를 참조하세요.
