View a markdown version of this page

메모리에 대한 세분화된 액세스 제어 - Amazon Bedrock AgentCore
세분화된 액세스 제어 작동 방식메모리에 대한 세분화된 액세스 제어 설정메모리 작업 및 요청 속성적용할 수 있는 사항기존 메모리에서 세분화된 액세스 제어 채택다른 액세스 제어 옵션과의 관계

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

메모리에 대한 세분화된 액세스 제어

Amazon Bedrock AgentCore 메모리에 대한 세분화된 액세스 제어(FGAC)를 사용하면 OAuth 인증 호출자의 자격 증명에 메모리 액세스를 바인딩할 수 있습니다.

호출자가 AWS IAM 자격 증명을 사용하여 메모리에 도달하면 메모리 조건 키와 함께 IAM 자격 증명 기반 및 리소스 기반 정책을 사용하여 작업, 메모리 리소스 및 요청의 액터, 세션 및 네임스페이스 범위별로 액세스를 이미 제한할 수 있습니다. 이러한 제어는 AgentCore의 메모리 조직 및 Amazon Bedrock AgentCore의 리소스 기반 정책을 참조하세요.

이러한 IAM 제어는 Memory를 호출하는 IAM 보안 주체와 일치합니다. OAuth 인증 호출자는 IAM 보안 주체가 아니기 때문에 OAuth/JWT 자격 증명에 키가 지정된 규칙을 표현할 수 없습니다. OAuth 이는 최종 사용자가 OpenID Connect 공급자를 통해 로그인하는 에이전트 애플리케이션과 같이 호출자가 AWS 자격 증명이 아닌 OAuth로 인증하는 애플리케이션에 중요합니다. 해당 아키텍처에서 HTTP 호출자는 일반적으로 각 요청과 함께 최종 사용자(또는 에이전트 자체)의 JWT를 전달하는 에이전트 또는 백엔드입니다. FGAC는 해당 토큰의 자격 증명과 비교하여 정책을 평가합니다. FGAC를 사용하면 요청 속성을 토큰의 클레임과 비교하는 정책을 작성할 수 있으므로 다음과 같은 규칙을 적용할 수 있습니다.

  • 호출자는 요청이 JWT sub 클레임과 actorId 동일한 이벤트에만 액세스할 수 있습니다.

  • 호출자는 자신의 토큰 클레임에 포함된 네임스페이스 하에서만 메모리 레코드를 검색할 수 있습니다.

  • 특정 OAuth를 제시하는 호출자에게만 액세스 권한이 부여됩니다client_id.

또한 FGAC 정책은 IAM이 제공하는 것과 동일한 작업, 메모리 리소스 및 요청 속성 범위를 조건으로 할 수 있으므로 단일 정책은 호출자가 누구인지와 액세스할 수 있는 작업 및 데이터를 결합할 수 있습니다.

메모리용 FGAC는 Amazon Bedrock AgentCore의 정책으로 구현됩니다. Cedar 정책 웹 사이트에 문서화된 오픈 소스 정책 언어인 Cedar에서 메모리 리소스 및 쓰기 정책을 앞에 배치하는 게이트웨이에 정책 엔진을 연결합니다. 게이트웨이는 메모리에 요청을 전달하기 전에 이러한 정책을 평가합니다. Cedar 정책 언어, 보안 주체 유형, 정책 엔진 및 정책 검증은 모두 Amazon Bedrock AgentCore의 정책에 문서화되어 있습니다.이 페이지에서는 메모리 커넥터가 노출하는 작업 및 요청 속성, 호출자별로 메모리 데이터를 격리하는 정책 패턴 등 메모리와 관련된 항목만 설명합니다.

참고

메모리용 FGAC는 AgentCore 메모리 커넥터를 기반으로 합니다. 먼저 메모리 커넥터 대상으로 게이트웨이를 설정합니다. 자세한 내용은 게이트웨이를 통한 AgentCore 메모리 액세스를 참조하세요.

주제

세분화된 액세스 제어 작동 방식

정책 엔진은 Cedar 정책 세트를 보유하고 연결된 게이트웨이를 통해 흐르는 각 요청에 대해 이를 평가합니다. 게이트웨이가 호출자를 인증하고 요청을 메모리 작업으로 해결한 후 정책 엔진은 요청의 보안 주체(호출하는 사람), 작업(메모리 작업), 리소스(게이트웨이) 및 컨텍스트(경로 파라미터 및 본문 필드와 같은 요청의 속성)를 기준으로 정책을 평가합니다. 평가는 deny-by-default되며를 forbid 재정의합니다permit.

메모리 커넥터를 사용하면 각 메모리 작업을 요청 필드와 함께 Cedar 작업으로 사용할 수 있으므로 정책은 요청 속성에 대해 특정 메모리 작업 및 조건을 허용하거나 거부할 수 있습니다. 정책 구조, permit/forbid, AgentCore::OAuthUser 및 AgentCore::IamEntity 보안 주체 유형, 태그, 일반 Cedar 모델은 Cedar 정책 및 핵심 개념 이해에 context.input 설명되어 있습니다. 핵심 개념

메모리에 대한 세분화된 액세스 제어 설정

참고

AWS 관리 콘솔, AWS SDK 및 AWS 명령줄 인터페이스(AWS CLI)를 통해 메모리에 대한 세분화된 액세스 제어를 설정할 수 있습니다.

메모리 커넥터 대상이 있는 게이트웨이가 있는 경우(게이트웨이를 통한 AgentCore 메모리 액세스 참조):

  1. 정책 엔진을 생성하고 Cedar 정책을 추가합니다. 단계는 정책 엔진 생성 및 정책 생성을 참조하세요. 작성할 정책은 메모리에 대한 정책 예제를 참조하세요.

  2. 게이트웨이의를 설정하여 정책 엔진을 메모리 리소스 앞에 있는 게이트웨이와 연결합니다policyEngineConfiguration. CreateGateway를 사용하여 게이트웨이를 생성할 때 설정하거나 나중에 UpdateGateway를 사용하여 추가할 수 있습니다.

정책 엔진의는 정책을 적용할지(ENFORCE) 아니면 트래픽을 차단하지 않고 평가 및 로깅할지()를 mode 제어합니다LOG_ONLY. 의도하지 않은 거부를 방지하기 ENFORCE 위해 로 전환하기 LOG_ONLY 전에에서 정책을 테스트합니다. 적용 모드, 정책 검증 및 테스트는 정책 검증 및 테스트 및 정책 사용을 참조하세요.

메모리 작업 및 요청 속성

이 섹션은 정책 작성을 위한 메모리별 참조로, 각 메모리 작업에 대한 Cedar 작업 ID와에서 사용할 수 있는 요청 속성입니다context.input.

메모리 작업 ID

각 메모리 작업은 라는 Cedar 작업입니다. <target-name>___<METHOD>:<uri-template>여기서 <target-name>는 커넥터 대상의 이름입니다. URI는 경로 파라미터 자리 표시자를 유지합니다. 구체적인 값으로 대체되지 않습니다. 다음 표에서 <target-name>를 커넥터 대상의 이름으로 바꿉니다.

메모리 작업 Cedar 작업 ID

ListEvents

<target-name>___POST:/memories/{memoryId}/actor/{actorId}/sessions/{sessionId}

CreateEvent

<target-name>___POST:/memories/{memoryId}/events

GetEvent

<target-name>___GET:/memories/{memoryId}/actor/{actorId}/sessions/{sessionId}/events/{eventId}

DeleteEvent

<target-name>___DELETE:/memories/{memoryId}/actor/{actorId}/sessions/{sessionId}/events/{eventId}

ListSessions

<target-name>___POST:/memories/{memoryId}/actor/{actorId}/sessions

ListActors

<target-name>___POST:/memories/{memoryId}/actors

RetrieveMemoryRecords

<target-name>___POST:/memories/{memoryId}/retrieve

ListMemoryRecords

<target-name>___POST:/memories/{memoryId}/memoryRecords

GetMemoryRecord

<target-name>___GET:/memories/{memoryId}/memoryRecord/{memoryRecordId}

DeleteMemoryRecord

<target-name>___DELETE:/memories/{memoryId}/memoryRecords/{memoryRecordId}

ListMemoryExtractionJobs

<target-name>___POST:/memories/{memoryId}/extractionJobs

StartMemoryExtractionJob

<target-name>___POST:/memories/{memoryId}/extractionJobs/start

Action-id 와일드카드는 지원되지 않습니다. 한 정책에서 여러 작업을 부여하려면를 사용하여 나열합니다action in […​].

참고

메모리 배치 작업(BatchCreateMemoryRecords, 및 BatchUpdateMemoryRecordsBatchDeleteMemoryRecords)은 Cedar 작업으로 사용할 수 없으며 세분화된 액세스 제어로 관리할 수 없습니다. 각는 단일 요청으로 여러 레코드를 전달하며, 정책 엔진은 개별적으로 평가할 수 없으므로 레코드당 또는 네임스페이스당 조건을 적용할 수 없습니다.

IAM 자격 증명 기반 및 리소스 기반 정책(예: bedrock-agentcore:BatchCreateMemoryRecords 작업 허용 또는 거부)을 사용하여 배치 작업을 전체적으로 허용하거나 거부할 수 있습니다. 누락된 것은 레코드별 세부 수준일 뿐입니다. 세분화된 액세스 제어 계층에서 배치 작업은 all-or-nothing.

컨텍스트 필드 요청

게이트웨이는 경로 파라미터와 요청 본문 필드를 context.input결합하여 아래에 각 요청의 속성을 노출합니다. 읽기 has 전에 각 필드를 로 보호합니다(예: context has input && context.input has actorId).

경로 파라미터(UTI에서):

  • context.input.memoryId

  • context.input.actorId

  • context.input.sessionId

  • context.input.eventId

  • context.input.memoryRecordId

요청 본문 필드(작업에 따라 다름, 요청 페이로드에서):

  • context.input.namespace

  • context.input.namespacePath

  • context.input.metadata

  • context.input.filter

  • context.input.payload

  • 및 각 작업의 스키마에서 정의한 기타 본문 필드

사용 가능한 필드는 작업에 따라 다릅니다. 한 작업에서 포함하는 필드(예: actorId)는 동일한 정책과 일치하는 다른 작업에 없을 ListEvents수 있습니다.

주의

컨텍스트 필드를 참조하는 정책은 범위 내 작업에 대한 스키마에 대해 검증되지만 런타임에 요청이 도달할 수 있는 모든 작업에 대해 검증되지는 않습니다. 정책이 수신 요청에 포함되지 않은 필드를 참조하는 경우 정책을 성공적으로 생성하고에 도달할 수 있지만 ACTIVE참조된 필드가 누락되었기 때문에 정책 엔진이 요청을 평가할 때 403 응답으로 요청을 거부할 수 있습니다. 이 조건은 정책을 생성할 때 보고되지 않습니다.

예기치 않은 거부를 방지하려면:

  • 각 정책의 범위를 정책이 참조하는 필드를 포함하는 특정 작업으로 지정하고 메모리 작업 ID 테이블의 각 작업에 대해 해당 필드를 확인합니다.

  • 필드가 없을 때 permit 조건이 예측 가능하게 평가되도록 has (예: context has input && context.input has actorId)를 사용하여 모든 필드 액세스를 보호합니다.

  • 정책을 적용하기 전에 LOG_ONLY 모드에서 테스트하여 라이브 트래픽을 거부하지 않고도 평가 결과를 관찰할 수 있습니다. 자세한 내용은 메모리에 대한 세분화된 액세스 제어 설정을 참조하세요.

적용할 수 있는 사항

메모리 커넥터를 통한 FGAC 적용은 게이트웨이의 모든 인바운드 인증 모드에서 사용할 수 있습니다. 위의 작업 및 속성을 사용하여 다음을 적용할 수 있습니다.

  • 보안 주체 유형 게이팅 - OAuth 전용 또는 IAM 전용 호출자로 범위가 지정된 정책이 호출자 클래스별로 일치하거나 거부됩니다.

  • 자격 증명별 격리 -와 같은 요청 속성은 JWT에서 인증된 사용자 또는 에이전트의 sub 클레임과 동일하여 소유자를 허용하고 다른 사용자를 거부하는 데 필요할 actorId 수 있습니다.

  • 네임스페이스 격리 - 요청의 namespace 또는를 리터럴namespacePath과 비교하거나 토큰 클레임에 전달된 네임스페이스 경로와 비교하면 호출자가 검색할 수 있는 레코드가 제한됩니다.

  • 작업 범위 지정 - 단일 작업, 작업 세트 또는 모든 작업을 허용할 수 있으며 허용되지 않는 작업은 거부됩니다.

  • 경로-파라미터 조건 - memoryId, actorId및와 같은 경로 파라미터입니다sessionId.

  • 요청-본문 조건 - metadata 및와 같은 본문 필드입니다namespacePath.

  • 리소스 고정 - 일치하는 게이트웨이 ARN이 허용되며 다른 ARN이 거부됩니다.

  • JWT 클레임 조건 - sub 및 client_id 게이트 액세스(OAuth 인바운드)와 같은 토큰 클레임입니다.

  • IAM 자격 증명 조건 - 발신자의 IAM ARN을 패턴(IAM 인바운드)별로 일치시킬 수 있습니다.

이를 구현하는 정책은 메모리에 대한 정책 예제를 참조하세요.

기존 메모리에서 세분화된 액세스 제어 채택

기본 격리 패턴을 사용하려면 요청actorId의이 호출자의 JWT sub 클레임()과 같아야 합니다context.input.actorId == principal.getTag("sub"). 기존 배포에서는 내부 사용자 ID를 자격 증명 공급자의 sub 값과 일치하지 actorId 않는 로 사용하는 경우가 많습니다. actorId 값이 공급자의와 이미 같으면 변경할 필요가 sub없습니다. 그렇지 않으면 다음 방법 중 하나를 선택합니다.

사용자 지정 JWT 클레임에서 일치

자격 증명 공급자가 내부 사용자 ID가 이미 있는 클레임(예: actorId 스키마를 미러링하는 사용자 지정 클레임)을 발급할 수 있는 경우 대신 해당 클레임과 비교합니다context.input.actorId == principal.getTag("custom:app_user_id"). 예sub: . hasTag 먼저 로 보호합니다. 이렇게 하면 저장된 데이터가 변경되지 않습니다.

대신 네임스페이스로 격리 actorId

장기 메모리 레코드가 사용자당 네임스페이스로 구성된 경우가 아닌 네임스페이스에 격리를 적용합니다actorId. 자격 증명 공급자가 호출자의 전체 네임스페이스 경로를 포함하는 클레임을 발행하도록 하고 요청의를 해당 클레임namespacePath과 비교합니다. 네임스페이스 격리 패턴은 메모리에 대한 정책 예제를 참조하세요.

actorId와 정렬 sub

기본 actorId == sub 패턴을 사용하려면 공급자의를 sub로 사용하도록 새 이벤트 및 레코드를 마이그레이션합니다actorId. AgentCore 메모리는 actorId 사용자가 제공한에 이벤트와 레코드를 저장하므로 일반적으로 기록 데이터를 다시 쓰지 않고 앞으로 적용됩니다. 두 스키마가 모두 존재할 수 있는 전환 기간을 계획합니다.

작은 정보

LOG_ONLY 모드에서 정책을 먼저 연결하고 평가 로그를 검토하여 라이브 트래픽에 영향을 주지 않고 이러한 접근 방식을 검증할 수 있습니다. 메모리에 대한 세분화된 액세스 제어 설정을 참조하세요.

다른 액세스 제어 옵션과의 관계

정책 엔진에서 평가하는 Cedar 정책은 게이트웨이를 통한 메모리 트래픽에 대한 자격 증명 인식 요청당 권한 부여 계층입니다. 게이트웨이의 다른 액세스 제어 옵션을 보완하고 결합할 수 있습니다.