View a markdown version of this page

자연어로 정책 작성 - Amazon Bedrock AgentCore
개요예제정책 효과권한 부여 의미 체계정책 요소정책 예시조건 구문조건 결합일반적인 함정

자연어로 정책 작성

AgentCore의 정책은 정책 작성 서비스를 통해 이루어진 추론 요청을 처리하기 위해 리전 내에서 최적의 리전을 자동으로 선택합니다. 이렇게 하면 사용 가능한 컴퓨팅 리소스와 모델 가용성이 극대화되고 최상의 고객 경험이 제공됩니다. 데이터는 요청이 시작된 리전에만 저장되지만 입력 프롬프트 및 출력 결과는 해당 리전 외부에서 처리될 수 있습니다. 모든 데이터는 Amazon의 보안 네트워크를 통해 암호화되어 전송됩니다.

AgentCore의 정책은 다음과 같이 요청이 시작된 지리적 영역 내의 사용 가능한 컴퓨팅 리소스로 추론 요청을 안전하게 라우팅합니다.

  • 유럽 연합에서 시작된 추론 요청은 유럽 연합 내에서 처리됩니다.

  • 미국에서 시작된 추론 요청은 미국 내에서 처리됩니다.

  • 아시아 태평양에서 시작된 추론 요청은 아시아 태평양 내에서 처리됩니다.

개요

Cedar는 정확한 액세스 제어를 제공하지만 공식 구문을 학습해야 합니다. NL2Cedar를 사용하면 다음을 수행할 수 있습니다.

  1. 자연어로 권한 부여 요구 사항 작성

  2. Cedar 구문으로 자동 변환

  3. 생성된 정책이 요구 사항과 일치하는지 확인

참고

자연어 정책 생성에는 배포된 AgentCore Gateway 및 정책 엔진이 필요합니다. 서비스는 AgentCore Gateway 스키마를 사용하여 유효한 Cedar 정책을 생성합니다. 설정 지침은 AgentCore의 정책 시작하기를 참조하세요.

참고

자연어는 유연하지만 보안을 위해서는 정밀도가 필수적입니다. 정책은 명확하고 모호하지 않아야 합니다.

예제

이전 섹션의 환불 정책은 자연어로 표현할 수 있습니다.

자연어:

환급 금액이 500 USD 미만인 경우 사용자 이름이 "refund-agent"인 보안 주체가 환급을 처리하도록 허용합니다.

Cedar로 변환: 

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundTool___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/refund-gateway"
)
when {
  principal.hasTag("username") &&
  principal.getTag("username") == "refund-agent" &&
  context.input.amount < 500
};

정책 효과

권한 부여 정책에는 허용과 금지라는 두 가지 효과가 있습니다.

허용 정책

허용 정책은 사용자가 수행할 수 있는 작업을 지정합니다.

  • “사용자 환급 에이전트가 환급을 처리하도록 허용”

  • “역할 디렉터가 있는 사용자에게 결정을 승인할 수 있는 권한 부여”

  • “범위 관리자: 쓰기를 사용하여 적용 범위를 업데이트하도록 사용자에게 권한 부여”

금지 정책

금지 정책은 사용자가 수행할 수 없는 작업을 지정합니다.

  • “사용자가 고감도 모델에 액세스하지 못하도록 차단”

  • “하위 인수자의 결정 승인 거부”

  • “위험 검증이 보류 중일 때 사용자가 환급을 처리하지 못하도록 금지”

권한 부여 의미 체계

Cedar가 정책을 평가하는 방법을 이해하는 것은 효과적인 권한 부여 규칙을 작성하는 데 매우 중요합니다. Cedar는 세 가지 기본 원칙을 따릅니다.

  • 기본적으로 모든 것이 거부됨 - 작업을 명시적으로 허용하는 정책이 없는 경우 자동으로 차단됩니다.

  • 항상 금지 성공 - 금지 정책이 일치하면 허용 정책도 일치하더라도 액세스가 거부됩니다.

  • 하나 이상의 허가 필요 - 액세스 권한을 부여하려면 하나 이상의 허가 정책이 일치해야 하며 금지 정책이 일치하지 않아야 합니다.

기본적으로 모든 항목이 거부되는 경우 금지 정책을 사용하는 이유는 무엇입니까?

금지 정책은 특정 작업이 실수로 허용되지 않도록 합니다. 누군가 더 광범위한 허용 정책을 작성하더라도 금지 정책이 우선하고 액세스를 차단합니다.

예제 시나리오: 

// Broad permit policy - allows all users to view model results
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ModelAPI___view_results",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model"
);

// Forbid policy - blocks access to high-sensitivity results
forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ModelAPI___view_results",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model"
)
when {
  context.input.sensitivity == "high"
};

결과: 사용자는 민감도가 낮거나 중간인 결과를 볼 수 있지만(권한 적용), 민감도가 높은 결과는 항상 차단됩니다(금지 성공).

다음에 대해 금지 정책을 사용합니다.

  • 재정의해서는 안 되는 명시적 보안 제한 사항

  • 규정 준수 요구 사항

  • 비상 종료

  • 더 광범위한 허용 정책에 대한 예외 생성

정책 요소

권한 부여 정책에는 세 가지 주요 요소가 필요합니다.

  1. 누가 - 작업을 수행할 수 있는 사용자 또는 역할

  2. 내용 - 사용할 수 있는 작업 또는 도구

  3. 시기 - 어떤 조건 또는 제약 조건에서

보안 주체 사양

보안 주체는 정책이 적용되는 사용자, 역할 또는 그룹을 식별합니다.

유연한 표현식:

  • "사용자 refund-agent가 다음을 수행하도록 허용..."

  • "사용자 이름 refund-agent를 사용하여 사용자 허용..."

  • "역할 보험 에이전트가 있는 사용자는... "

  • "환불:쓰기 범위가 있는 사람은 누구나... "

  • "모든 사용자는... "

자격 증명에 대해 구체적으로 설명하세요.

미완료: ❌ "500 USD 미만의 환불 처리 허용"

완료: ✓ "환불 에이전트가 500 USD 미만의 환불을 처리하도록 허용"

작업 사양

"What"은 정책이 제어하는 작업, 도구 또는 작업을 식별합니다.

유연한 작업 동사:

  • “사용자가 환급을 처리하도록 허용”

  • “환불 처리 허용”

  • “사용자가 애플리케이션을 생성할 수 있습니다.”

  • “감사 로그 보기 권한 부여”

도구에 대해 구체적으로 설명하세요.

모호: ❌ "사용자가 모델에 액세스하도록 허용"

지우기: ✓ '데이터 과학 팀이 분석 모델에 액세스하도록 허용'

조건 사양

"언제"는 정책이 적용되는 상황을 지정합니다.

유연한 조건식:

  • "... 금액이 500 USD 미만인 경우"

  • "... 리전이 미국, CA 또는 영국인 경우"

  • "... 승인 상태가 approved-by-manager인 경우에만 해당"

  • “... 위험 점수가 제출된 경우”

다음과 같은 조건에 정확하게 대처합니다.

모호: ❌ "금액이 합리적일 때 전송 허용"

정밀도: ✓ "금액이 10,000 USD 미만일 때 전송 허용"

정책 예시

다음 예제에서는 명확한 보안 주체, 작업 및 조건을 사용하여 자연어 정책을 구성하는 방법을 보여줍니다.

예제 1: 간단한 사용자 기반 정책

금액이 500 USD 미만인 경우 사용자 환급 에이전트가 환급을 처리하도록 허용합니다.

요소:

  • 대상: user refund-agent

  • 내용: 환불 처리

  • 시기: 금액이 500 USD 미만인 경우

예제 2: 여러 조건이 있는 역할 기반

담당 범위 유형이 책임 또는 충돌이고 정책이 활성 상태인 경우 역할 보험 에이전트가 있는 사용자가 담당 범위를 업데이트하도록 허용합니다.

요소:

  • 대상: 역할 보험 에이전트가 있는 사용자

  • 내용: 적용 범위 업데이트

  • 시기: 적용 범위 유형이 책임 또는 충돌이고 정책이 활성 상태인 경우

예제 3: 범위 기반 액세스

범위가 travel:book인 사용자가 리전이 EU가 아니고 제품이 적격한 경우 항공편 예약을 생성할 수 있도록 허용합니다.

요소:

  • 대상: 범위가 travel:book인 사용자

  • 내용: 항공편 예약 생성

  • 시기: 리전이 EU가 아니고 제품이 적격인 경우

예제 4: 제약이 있는 모든 사람

데이터 민감도가 낮거나 중간이고 결과 유형이 위험 점수인 경우 모든 사용자가 모델 결과를 볼 수 있도록 허용합니다.

요소:

  • 대상: 모든 사용자

  • 내용: 모델 결과 보기

  • 시기: 데이터 민감도가 낮거나 중간이고 결과 유형이 위험 점수인 경우

조건 구문

정책이 모호해지는 경우가 많습니다. 다음은 명확하고 테스트 가능한 조건을 작성하는 방법입니다.

숫자 비교식

좋은 예:

  • “금액이 500 USD 미만인 경우”

  • "적용 금액이 5백만 미만인 경우"

  • “클레임이 10,000,000 USD를 초과하는 경우”

  • "승객 수가 정확히 2인 경우"

모호한 용어를 피합니다.

  • ❌ “금액이 적은 경우”

  • ❌ "적용 범위가 높을 때"

문자열 일치

정확히 일치:

  • “리전이 미국인 경우”

  • “결제 방법이 신용 카드인 경우”

  • "상태가 승인되면"

여러 옵션:

  • “리전이 미국, CA 또는 영국인 경우”

  • "결정 유형이 승인 또는 참조되는 경우"

패턴 일치:

  • “이메일에 @example.com이 포함된 경우”

  • "범위에 admin:write가 포함된 경우"

음수:

  • “리전이 EU가 아닌 경우”

  • “분류가 제한되지 않는 경우”

부울 조건

직접 확인:

  • "제품이 적합한 경우"

  • “위험 점수가 제출되는 경우”

  • “특급 배송이 요청되는 경우”

음수:

  • "제품이 적합하지 않은 경우"

  • “위험 점수가 제출되지 않은 경우”

필드 존재

필수 필드:

  • “이유가 제공된 경우”

  • "애플리케이션 ID가 있는 경우"

  • “반환 날짜가 지정된 경우”

조건 결합

실제 정책에는 여러 조건이 필요한 경우가 많습니다. 명확한 논리적 커넥터를 사용합니다.

AND 로직(모두 true여야 함)

"and", "also", "additionally", "while", "with"와 같은 단어를 사용합니다.

예제:

리전이 미국이고 제품이 적합하며 지역이 활성 상태인 경우 애플리케이션을 허용합니다.

OR 로직(최소 1개는 참이어야 함)

"or", "alternatively", " either"과 같은 단어를 사용합니다.

예제:

클레임이 10,000,000 USD를 초과하거나 위험 수준이 높거나 중요할 때 승인을 허용합니다.

복합 로직

복잡한 조건의 경우 명확한 구조를 사용합니다.

예제:

워크플로 단계가 검토 완료 또는 승인되고 규정 준수 상태가 전달되고 권한이 관리자 또는 디렉터인 경우 마무리를 허용합니다.

일반적인 함정

자연어 정책을 작성할 때 이러한 일반적인 실수를 피하여 Cedar 구문으로 올바르게 변환되도록 합니다.

실수 1: 모호한 보안 주체

잘못된: "환불 도구에 대한 액세스 허용"

좋음: "사용자 환급 에이전트가 환급 도구에 액세스하도록 허용"

실수 2: 모호한 작업

잘못된: "사용자의 데이터 액세스 허용"

좋음: "사용자가 환자 레코드를 볼 수 있도록 허용"

실수 3: 주관적 조건

잘못된: "금액이 합리적일 때 전송 허용"

좋음: "금액이 10,000 USD 미만인 경우 이전 허용"

실수 4: 조건 누락

잘못된: "범위가 admin:write인 사용자가 적용 범위를 업데이트하도록 허용"

좋음: “정책이 활성 상태이고 적용 범위 유형이 책임 또는 충돌인 경우 범위 admin:write가 있는 사용자가 적용 범위를 업데이트하도록 허용”

실수 5: 명확하지 않은 로직

잘못된: "A 또는 B 및 C일 때 허용"

양호: "(A 또는 B) 및 C인 경우 허용" 또는 "A 또는 (B 및 C)인 경우 허용"