기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
OPA용 모델 설계
APIs에서 PEPs와 함께 중앙 집중식 PDP 사용
APIs 모델의 정책 적용 지점(PEPs)은 업계 모범 사례를 따라 API 액세스 제어 및 권한 부여를 위한 효과적이고 쉽게 유지 관리되는 시스템을 생성합니다. 이 접근 방식은 다음과 같은 몇 가지 주요 원칙을 지원합니다.
-
권한 부여 및 API 액세스 제어는 애플리케이션의 여러 지점에서 적용됩니다.
-
권한 부여 로직은 애플리케이션과 독립적입니다.
-
액세스 제어 결정은 중앙 집중식입니다.
이 모델은 중앙 집중식 PDP를 사용하여 권한 부여 결정을 내립니다. PEPs는 PDP에 대한 권한 부여 요청을 하기 위해 모든 APIs에서 구현됩니다. 다음 다이어그램은 가상 다중 테넌트 SaaS 애플리케이션에서이 모델을 구현하는 방법을 보여줍니다.

애플리케이션 흐름(다이어그램에 파란색 번호가 지정된 콜아웃으로 표시됨):
-
JWT를 사용하는 인증된 사용자는 Amazon CloudFront에 대한 HTTP 요청을 생성합니다.
-
CloudFront는 CloudFront 오리진으로 구성된 Amazon API Gateway에 요청을 전달합니다.
-
API Gateway 사용자 지정 권한 부여자를 호출하여 JWT를 확인합니다.
-
마이크로서비스는 요청에 응답합니다.
권한 부여 및 API 액세스 제어 흐름(다이어그램에 빨간색 번호가 지정된 콜아웃으로 표시됨):
-
PEP는 권한 부여 서비스를 호출하고 JWTs 포함한 요청 데이터를 전달합니다.
-
권한 부여 서비스(PDP)는 요청 데이터를 가져와 사이드카로 실행되는 OPA 에이전트 REST API를 쿼리합니다. 요청 데이터는 쿼리에 대한 입력 역할을 합니다.
-
OPA는 쿼리에 지정된 관련 정책을 기반으로 입력을 평가합니다. 필요한 경우 데이터를 가져와 권한 부여 결정을 내립니다.
-
OPA는 권한 부여 서비스에 결정을 반환합니다.
-
권한 부여 결정이 PEP로 반환되고 평가됩니다.
이 아키텍처에서 PEPs Amazon CloudFront 및 Amazon API Gateway와 각 마이크로서비스에 대한 서비스 엔드포인트에서 권한 부여 결정을 요청합니다. 권한 부여 결정은 OPA 사이드카가 있는 권한 부여 서비스(PDP)에서 내립니다. 이 권한 부여 서비스를 컨테이너 또는 기존 서버 인스턴스로 운영할 수 있습니다. OPA 사이드카는 로컬에서 RESTful API를 노출하므로 API는 권한 부여 서비스에서만 액세스할 수 있습니다. 권한 부여 서비스는 PEPs. 권한 부여 서비스가 PEPs와 OPA 간의 중개자 역할을 하도록 하면 PEPs의 권한 부여 요청이 OPA에서 예상하는 쿼리 입력을 준수하지 않는 경우와 같이 필요할 수 있는 PEP와 OPA 간의 변환 로직을 삽입할 수 있습니다.
이 아키텍처를 사용자 지정 정책 엔진과 함께 사용할 수도 있습니다. 그러나 OPA에서 얻는 모든 이점은 사용자 지정 정책 엔진에서 제공하는 로직으로 대체해야 합니다.
APIs의 PEPs 있는 중앙 집중식 PDP는 APIs에 대한 강력한 권한 부여 시스템을 쉽게 생성할 수 있는 옵션을 제공합니다. 구현은 간단하며 APIs, 마이크로서비스, 프런트엔드 백엔드(BFF) 계층 또는 기타 애플리케이션 구성 요소에 대한 권한 부여 결정을 내릴 수 있는 easy-to-use 반복 가능한 인터페이스도 제공합니다. 그러나 권한 부여 결정 시 별도의 API를 호출해야 하므로이 접근 방식은 애플리케이션에 지연 시간을 너무 많이 발생시킬 수 있습니다. 네트워크 지연 시간이 문제가 되는 경우 분산 PDP를 고려할 수 있습니다.
APIs에서 PEPs와 함께 분산 PDP 사용
APIs 모델의 정책 적용 지점(PEPs)은 업계 모범 사례를 따라 API 액세스 제어 및 권한 부여를 위한 효과적인 시스템을 생성합니다. APIs 모델에서 PEPs 사용하는 중앙 집중식 PDP와 마찬가지로이 접근 방식은 다음과 같은 주요 원칙을 지원합니다.
-
권한 부여 및 API 액세스 제어는 애플리케이션의 여러 지점에서 적용됩니다.
-
권한 부여 로직은 애플리케이션과 독립적입니다.
-
액세스 제어 결정은 중앙 집중식입니다.
PDP가 배포될 때 액세스 제어 결정이 중앙 집중화되는 이유가 궁금할 수 있습니다. PDP는 애플리케이션의 여러 위치에 존재할 수 있지만 동일한 권한 부여 로직을 사용하여 액세스 제어 결정을 내려야 합니다. 모든 PDPs 동일한 입력을 고려하여 동일한 액세스 제어 결정을 제공합니다. PEPs는 PDP에 대한 권한 부여 요청을 하기 위해 모든 APIs에서 구현됩니다. 다음 그림은 가상 다중 테넌트 SaaS 애플리케이션에서이 분산 모델을 구현하는 방법을 보여줍니다.
이 접근 방식에서는 PDPs 애플리케이션의 여러 위치에 구현됩니다. 사이드카 또는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 사용하는 컨테이너화된 서비스와 같이 OPA를 실행하고 PDP를 지원할 수 있는 온보드 컴퓨팅 기능이 있는 애플리케이션 구성 요소의 경우, 중앙 집중식 PDP 서비스에 RESTful API를 호출할 필요 없이 PDP 결정을 애플리케이션 구성 요소에 직접 통합할 수 있습니다. 이는 중앙 집중식 PDP 모델에서 발생할 수 있는 지연 시간을 줄이는 이점이 있습니다. 모든 애플리케이션 구성 요소가 권한 부여 결정을 얻기 위해 추가 API 호출을 수행할 필요는 없기 때문입니다. 하지만 Amazon CloudFront 또는 Amazon API Gateway 서비스와 같이 PDP를 직접 통합할 수 있는 온보드 컴퓨팅 기능이 없는 애플리케이션 구성 요소에는 중앙 집중식 PDP가 여전히 필요합니다.
다음 다이어그램은 중앙 집중식 PDP와 분산형 PDP의 이러한 조합을 가상 다중 테넌트 SaaS 애플리케이션에서 구현하는 방법을 보여줍니다.

애플리케이션 흐름(다이어그램에 파란색 번호가 지정된 콜아웃으로 표시됨):
-
JWT를 사용하는 인증된 사용자는 Amazon CloudFront에 대한 HTTP 요청을 생성합니다.
-
CloudFront는 CloudFront 오리진으로 구성된 Amazon API Gateway에 요청을 전달합니다.
-
API Gateway 사용자 지정 권한 부여자를 호출하여 JWT를 확인합니다.
-
마이크로서비스는 요청에 응답합니다.
권한 부여 및 API 액세스 제어 흐름(다이어그램에 빨간색 번호가 지정된 콜아웃으로 표시됨):
-
PEP는 권한 부여 서비스를 호출하고 JWTs 포함한 요청 데이터를 전달합니다.
-
권한 부여 서비스(PDP)는 요청 데이터를 가져와 사이드카로 실행되는 OPA 에이전트 REST API를 쿼리합니다. 요청 데이터는 쿼리에 대한 입력 역할을 합니다.
-
OPA는 쿼리에 지정된 관련 정책을 기반으로 입력을 평가합니다. 필요한 경우 데이터를 가져와 권한 부여 결정을 내립니다.
-
OPA는 권한 부여 서비스에 결정을 반환합니다.
-
권한 부여 결정이 PEP로 반환되고 평가됩니다.
이 아키텍처에서 PEPs CloudFront 및 API Gateway와 각 마이크로서비스에 대한 서비스 엔드포인트에서 권한 부여 결정을 요청합니다. 마이크로서비스에 대한 권한 부여 결정은 애플리케이션 구성 요소가 있는 사이드카로 작동하는 권한 부여 서비스(PDP)에서 내립니다. 이 모델은 컨테이너 또는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행되는 마이크로서비스(또는 서비스)에 사용할 수 있습니다. API Gateway 및 CloudFront와 같은 서비스에 대한 권한 부여 결정은 여전히 외부 권한 부여 서비스에 문의해야 합니다. 그럼에도 불구하고 권한 부여 서비스는 PEPs. 권한 부여 서비스가 PEPs와 OPA 간의 중개자 역할을 하도록 하면 PEPs의 권한 부여 요청이 OPA에서 예상하는 쿼리 입력을 준수하지 않는 경우와 같이 필요할 수 있는 PEP와 OPA 간의 변환 로직을 삽입할 수 있습니다.
이 아키텍처를 사용자 지정 정책 엔진과 함께 사용할 수도 있습니다. 그러나 OPA에서 얻는 모든 이점은 사용자 지정 정책 엔진에서 제공하는 로직으로 대체해야 합니다.
APIs의 PEPs 있는 분산 PDP는 APIs에 대한 강력한 권한 부여 시스템을 생성하는 옵션을 제공합니다. 구현은 간단하며 APIs, 마이크로서비스, 프런트엔드(BFF) 계층 또는 기타 애플리케이션 구성 요소에 대한 권한 부여 결정을 내릴 수 있는 easy-to-use 반복 가능한 인터페이스를 제공합니다. 또한이 접근 방식은 중앙 집중식 PDP 모델에서 발생할 수 있는 지연 시간을 줄이는 이점이 있습니다.
분산 PDP를 라이브러리로 사용
애플리케이션 내에서 사용할 수 있는 라이브러리 또는 패키지로 제공되는 PDP에 권한 부여 결정을 요청할 수도 있습니다. OPA는 Go 타사 라이브러리로 사용할 수 있습니다. 다른 프로그래밍 언어의 경우이 모델을 채택하면 일반적으로 사용자 지정 정책 엔진을 생성해야 합니다.