Verified Permissions의 정책 평가와 애플리케이션의 집행 책임

신원 확인, 인가 결정, 실제 실행은 세 단계다

Amazon Verified Permissions는 요청에 대해 누가 어떤 작업을 수행할 수 있는지 판단하는 인가(authorization) 서비스다. 개념적으로 주체(principal), 작업(action), 리소스(resource), 문맥(context)을 받아 허용 또는 거부 결정을 내린다. 예를 들면 ‘이 상담원이 현재 상황에서 이 고객 기록을 수정해도 되는가’를 판단한다. 주체의 신원을 확인하는 인증(authentication)과 이러한 권한 판단은 구분한다. 실제 요청의 필드와 토큰 검증 방식은 사용할 API나 통합 방식의 명세를 확인해야 한다.

정책 평가를 요청한 뒤 허용이면 작업을 수행하고 거부이면 요청을 막는 것은 애플리케이션 처리 경로의 책임이다. 서비스가 허용 결정을 반환했다는 이유만으로 문서 수정·송금·모델 호출이 실제 완료된 것은 아니다. 앱이 평가를 호출하지 않는 별도 경로를 열어 둔다면 그 경로까지 자동으로 통제된다고 가정할 수 없다.

Express 통합에서는 미들웨어(middleware)가 요청을 받아 인가(authorization)를 검사하도록 구성할 수 있다. 모든 검사 코드를 직접 작성해야 하는 것은 아니지만, 미들웨어를 어느 경로에 적용할지, 사용자를 어떻게 매핑할지 정확히 정해야 한다. 보호해야 할 요청이 검사를 거치지 않고 실행되지 않는지도 테스트한다.

정책 스토어와 앱 데이터 저장소는 같은 것이 아니다

Amazon Verified Permissions는 Cedar 정책(policy)을 정책 스토어(policy store)에 저장해 중앙에서 관리한다. 앱은 인가 API로 정책 평가를 요청한다. Express 통합에서는 정책 스토어를 만들고 스키마(schema)를 연결한 뒤 정책을 등록하고 사용자 풀(user pool)과 그룹(group)을 연계한다. 먼저 앱의 업무 개념을 엔터티(entity), 작업(action), 그룹으로 모델링해야 정책이 실제 업무 대상을 구별할 수 있다.

스키마는 엔터티 유형과 작업 구조를 선언한다. 정책이 그 구조에 맞는지 검증하는 것과 실제 사용자 요청을 허용하는 것은 다르다. 스키마는 선택 사항이지만 프로덕션 사용을 권장하며, 정책 검증을 활성화했을 때 새 정책의 준수가 요구된다는 조건을 함께 읽어야 한다. ‘항상 모든 정책이 자동 검증된다’고 일반화하지 않는다.

정책 스토어(policy store)는 권한 규칙을 저장하는 곳이지 대화 이력이나 모든 LLM 프롬프트(prompt)와 응답을 영구 저장하는 곳이 아니다. 인가 요청과 응답의 감사 로그(audit log)를 어디에 얼마나 보관할지는 별도로 확인해야 한다. 로그의 민감 정보도 최소화한다. 정책을 생성하거나 갱신하는 작업과 조직의 사람 승인(approval)도 다르므로, 필요한 승인 절차와 제품의 지원 기능을 따로 확인한다.

IAM과 앱 인가를 겹쳐 놓지 않는다

IAM 인증과 인가에서 다룬 IAM 역할(role)은 AWS 서비스와 API를 실행하는 주체의 권한을 관리한다. Verified Permissions는 고객 앱의 업무 리소스(resource)와 작업(action)에 대해 세분화된 권한 결정을 내린다. 같은 ‘권한’이라도 적용 대상이 다르므로 두 계층을 함께 설계해야 한다.

자체 예: 상담 앱의 백엔드 역할이 Amazon Bedrock을 호출할 IAM 권한을 갖고 있어도 모든 상담원이 모든 고객 기록을 읽을 권한을 갖는 것은 아니다. 앱은 상담원과 고객 기록의 관계에 맞는 인가를 먼저 확인해야 한다. 반대로 앱 정책이 기록 열람을 허용해도 백엔드에 필요한 AWS 권한이 없으면 AWS 호출이 성공한다고 보장할 수 없다.

앱의 ‘관리자·직원·고객’ 그룹과 AWS IAM 역할을 동일시하지 않는다. Express 문서의 그룹별 정책은 앱 권한 모델의 예이며 이름만 같다고 IAM 권한이 생성되거나 상속되는 것은 아니다.

제약과 추가로 확인할 조건

외부에서 신원을 확인하는 인증(authentication) 흐름을 설명했다고 해서 Verified Permissions가 토큰(token)을 전혀 검증하지 못한다는 뜻은 아니다. Express 한국어 문서는 인가 정책 평가와 토큰 검증을 함께 수행할 수 있다고 설명한다. 지원 토큰, 발급자(issuer), 대상(audience) 등의 조건은 사용할 API의 상세 문서에서 확인해야 한다.
Express 문서는 정책이 없는 경우 거부한다고 설명한다. 모든 Cedar 충돌·오류 처리 규칙까지 확인한 것은 아니다.
API 반환값의 부가 필드, 엔터티 전달 형식, 로그 보관·내장 승인, IAM과 Cedar 문법의 완전한 호환성 판정은 상세 API 문서에서 확인해야 한다.
표시 예제를 실행하지 않았고 라이브러리 이름·버전 불일치나 운영 적합성을 보증하지 않는다.

적용 범위: 위 제약과 예외를 적용 대상의 현재 공식 문서와 대조한다. 이 해설은 API 실행 성공이나 법적 준수를 보증하지 않는다.

공식 출처와 이어 읽기

용어 확인: 인증(authentication) · 인가(authorization) · 대규모 언어 모델(large language model, LLM).