Cedar 정책 언어 기초: permit, forbid, 그리고 기본은 거부

AgentCore Policy 글을 쓰면서 Cedar라는 이름을 처음 제대로 봤습니다. 에이전트의 도구 호출을 막는 규칙을 이 언어로 쓴다고 해서, 기초를 따로 정리해 둡니다.

Cedar가 하는 일

공식 문서는 Cedar를 인가 정책을 쓰고, 그 정책으로 인가를 판단하는 언어라고 소개합니다. 앱이 "이 요청을 허용해도 되나?"를 물으면 Cedar 엔진이 답합니다.

정책이 앱 코드와 분리된다는 점이 핵심입니다. 접근 규칙을 바꿀 때 앱을 다시 배포하지 않아도 됩니다.

정책은 네 가지를 묻는다

정책은 누가(principal), 무엇을(action), 어디에(resource), 어떤 상황에서(context) 할 수 있는지를 적습니다. 맥락은 요청 시각, IP 주소, MFA 사용 여부 같은 그때그때의 정보입니다.

AgentCore 예시로 바꿔 보면 이렇습니다. 누가는 refund-agent 역할의 사용자, 무엇을은 환불 도구 호출, 조건은 금액 200달러 미만입니다.

규칙 세 개만 기억하면 된다

정책 작성 문서에서 가장 중요한 규칙은 셋입니다.

1. permit이 맞으면 허용, forbid가 맞으면 거부
2. 맞는 permit이 하나도 없으면 거부(암묵적 거부)
3. forbid 하나라도 맞으면, 다른 permit이 아무리 많아도 거부

정리하면 기본은 막혀 있고, 열려면 permit이 필요하고, forbid는 언제나 이깁니다. 보안 쪽에서 좋아하는 구조입니다. 실수로 정책을 빼먹으면 열리는 게 아니라 닫힙니다.

문서의 예시

forbid (
    principal,
    action,
    resource
)
when {
    resource.private
}
unless {
    principal == resource.owner
};

private로 표시된 리소스에는 누구도 아무 행동을 할 수 없습니다. 단, 소유자는 예외입니다. when은 참이어야 정책이 적용되고, unless는 거짓이어야 적용됩니다.

이 정책은 막기만 합니다. 소유자가 실제로 무언가를 하려면 별도의 permit 정책이 있어야 합니다. 처음에 헷갈렸던 부분입니다.

스키마는 미리 검증용

엔터티 타입, 속성, 행동, 맥락의 모양은 스키마로 정의합니다. 문서에 따르면 스키마는 요청을 판단할 때가 아니라 정책을 만들거나 고칠 때 검증에 씁니다. 오타 난 속성 이름을 배포 전에 잡아 준다는 뜻입니다.

에이전트에 쓸 때

에이전트의 도구 호출 통제에 Cedar가 잘 맞는 이유는 "기본 거부"에 있습니다. 새 도구를 붙였는데 정책을 안 썼다면, 에이전트는 그 도구를 쓸 수 없습니다. 프롬프트로 "하지 마세요"라고 부탁하는 것과 출발점이 반대입니다.