Amazon Verified Permissions 정식 출시 – 애플리케이션 권한 관리 방법을 간소화하기

Amazon Verified Permissions 정식 출시 – 애플리케이션 권한 관리 방법을 간소화하기

새 애플리케이션을 개발하거나 기존 애플리케이션을 새 환경에 통합할 때 사용자 인증 및 권한 부여를 올바르게 구현하려면 상당한 노력이 필요합니다. 과거에는 자체 인증 시스템을 구축했지만 이제는 Amazon Cognito 등의 외부 자격 증명 공급자를 사용할 수 있습니다. 그러나 권한 부여 로직은 일반적으로 코드로 구현됩니다.

모든 사용자에게 해당 직무에 대한 역할을 할당하여 간단하게 시작할 수 있습니다. 그러나 시간이 지남에 따라 이러한 권한은 점점 더 복잡해집니다. 권한이 더욱 세분화되면서 역할 수도 늘어납니다. 새로운 사용 사례로 사용자 지정 권한이 필요해집니다. 예를 들어, 한 사용자가 다른 역할의 다른 사용자와 문서를 공유하거나 지원 상담원이 문제를 해결하기 위해 고객 계정에 대한 임시 액세스 권한을 요구할 수 있습니다. 코드에서 권한을 관리하면 오류가 발생하기 쉬우며, 권한을 감사하고 누가 무엇에 액세스할 수 있는지 결정할 때 심각한 문제가 발생합니다. 특히 이러한 권한이 여러 애플리케이션에서 표현되고 여러 프로그래밍 언어를 사용하는 경우에는 더욱 그러합니다.

지난 AWS re:Invent 2022에서는 어떤 규모에서든 사용할 수 있는 애플리케이션에 대한 세분화된 권한 관리 및 권한 부여 서비스인 Amazon Verified Permissions을 미리 보기로 소개했습니다. Amazon Verified Permissions는 정책 스토어의 권한을 중앙 집중화하고 개발자가 해당 권한을 사용하여 애플리케이션 내에서 사용자 작업을 승인할 수 있도록 지원합니다. ID 공급자가 인증을 간소화하는 방식과 마찬가지로 정책 저장소를 사용하면 일관되고 확장 가능한 방식으로 권한 부여를 관리할 수 있습니다.

Amazon Verified Permissions는 세분화된 권한을 정의하기 위해 Cedar를 사용하며 이는 오픈 소스 정책 언어 및 액세스 제어용 소프트웨어 개발 키트(SDK)입니다. 보안 주체 유형, 리소스 유형 및 유효 작업의 관점에서 권한 부여 모델의 스키마를 정의할 수 있습니다. 이러한 방식으로 정책을 생성하면 권한 부여 모델과 비교하여 유효성을 검사합니다. 템플릿을 사용하여 유사한 정책을 단순화할 수 있습니다. 정책 저장소의 변경 사항은 감사받으므로 누가 언제 변경했는지 확인할 수 있습니다.

그런 다음 AWS SDK를 통해 애플리케이션을 Amazon Verified Permissions에 연결하여 액세스 요청을 승인할 수 있습니다. 각 권한 부여 요청에 대하여 관련 정책을 검색 및 평가하여 작업 허용 여부를 결정합니다. 이러한 권한 부여 요청을 재현하여 권한이 의도대로 작동하는지 확인할 수 있습니다.

오늘 Amazon Verified Permissions을 AWS 관리 콘솔에서 새로운 기능과 간소화된 사용자 경험과 함께 제공합니다.

이제, 실제로 어떻게 사용할 수 있는지 봅시다.

Amazon Verified Permissions 정책 저장소 생성
Amazon Verified Permissions 콘솔에서 정책 저장소 생성을 선택합니다. 정책 저장소는 정책과 스키마를 저장하는 논리적 컨테이너입니다. 권한 부여 결정은 정책 저장소에 있는 모든 정책을 기반으로 내려집니다.

새 정책 저장소를 구성하기 위해 다른 방법을 사용할 수 있습니다. 먼저 가이드 설정, 샘플 정책 저장소(예: 사진 공유 앱, 온라인 스토어 또는 작업 관리자용) 또는 빈 정책 저장소(고급 사용자에게 권장)로 시작할 수 있습니다. 가이드 설정을 선택하고 스키마(MyApp)의 네임 스페이스를 입력한 후 다음을 선택합니다.

리소스는 주도자가 조치를 취할 수 있는 객체입니다. 제 애플리케이션에는 사용자(주체)가 있으며 이 사용자는 문서(리소스)를 생성, 읽기, 업데이트 및 삭제할 수 있습니다. 문서 리소스 유형을 정의하기 시작합니다.

리소스 유형의 이름을 입력하고 두 개의 필수 속성을 추가합니다.

• 소유자(문자열)는 누가 문서의 소유자인지 지정합니다.
• 누구나 읽을 수 있는 공개 문서에 플래그를 지정하려면 isPublic(Boolean)을 사용합니다.

문서 리소스 유형에 다음 네 가지 작업을 지정합니다.

• DocumentCreate
• DocumentRead
• DocumentUpdate
• DocumentDelete

사용자를 문서에서 이러한 작업을 사용할 주 유형의 이름으로 입력합니다. 그런 다음 다음을 선택합니다.

이제 사용자 주체 유형을 구성합니다. 사용자 지정 구성을 사용하여 외부 자격 증명 소스를 통합할 수 있지만, 이 경우에는 이전에 생성한 Amazon Cognito 사용자 풀을 사용합니다. 사용자 풀 연결을 선택합니다.

대화 상자에서 사용자 풀이 위치한 AWS 리전을 선택하고 사용자 풀 ID를 입력한 다음 연결을 선택합니다.

이제 Amazon Cognito 사용자 풀이 연결되었으므로 클라이언트 애플리케이션 ID를 검증하여 보호 수준을 한 단계 더 높일 수 있습니다. 지금은 이 옵션을 사용하지 않기로 했습니다.

주요 속성 섹션에서는 정책의 속성 기반 액세스 제어에 사용할 속성을 선택합니다. 하위(주제)를 선택합니다. 이는 OpenID Connect 사양에 따라 최종 사용자를 식별하는 데 사용됩니다. 속성을 더 선택할 수 있습니다. 예를 들어 정책에 email_verified를 사용하여 이메일이 확인된 Amazon Cognito 사용자에게만 권한을 부여할 수 있습니다.

정책 저장소 생성의 일환으로 사용자 danilop에게 doc.txt 문서에 대한 읽기 권한을 부여하는 첫 번째 정책을 생성합니다.

다음 코드의 콘솔에서는 Cedar 언어를 사용하여 결과 정책을 미리 볼 수 있습니다.

permit(
  principal == MyApp::User::"danilop",
  action in [MyApp::Action::"DocumentRead"],
  resource == MyApp::Document::"doc.txt"
) when {
  true
};

마지막으로 정책 저장소 생성을 선택합니다.

정책 저장소에 권한 추가
이제 정책 저장소가 생성되었으므로 탐색 창에서 정책을 선택합니다. 정책 생성 드롭다운에서 정적 정책 생성을 선택합니다. 정적 정책은 평가에 필요한 모든 정보를 포함합니다. 두 번째 정책에서는 모든 사용자가 공개 문서를 읽을 수 있도록 허용합니다. 기본적으로 모든 것이 금지되므로 정책 효과에서 허용을 선택합니다.

정책 범위에서는 모든 보안 주체 및 모든 리소스를 선택한 상태로 두고 DocumentRead 작업을 선택합니다. 정책 섹션에서 when 조건 절을 변경하여 isPublic이 참과 동일한 리소스에 대한 허용을 제한하도록 합니다.

permit (
  principal,
  action in [MyApp::Action::"DocumentRead"],
  resource
)
when { resource.isPublic };

정책에 대한 설명을 입력하고 정책 생성을 선택합니다.

세 번째 정책에서는 문서 소유자에게 전체 액세스를 허용하는 또 다른 정적 정책을 생성합니다. 다시 정책 효과에서 허용을 선택하고 정책 범위에서는 모든 보안 주체 및 모든 리소스를 선택한 상태로 둡니다. 이번에는 모든 작업도 선택된 상태로 둡니다.

정책 섹션에서 when 조건 절을 변경하여 소유자가 주체의 하위와 동일한 리소스에 대한 허용을 제한하도록 합니다.

permit (principal, action, resource)
when { resource.owner == principal.sub };

내 애플리케이션에서 문서 소유자가 아닌 특정 사용자에게 읽기 권한을 허용해야 합니다. 이를 단순화하기 위해 정책 템플릿을 생성합니다. 정책 템플릿을 사용하면 기본 또는 리소스와 같은 일부 값에 자리 표시자를 사용하는 템플릿에서 정책을 생성할 수 있습니다. 템플릿의 자리 표시자는 ?자로 시작하는 키워드입니다.

탐색 창에서 정책 템플릿을 선택한 다음 정책 템플릿 생성을 선택합니다. 설명을 입력하고 다음 정책 템플릿 본문을 사용합니다. 이 템플릿을 사용할 때 ?principal 및 ?resource 자리 표시자의 값을 지정할 수 있습니다.

permit(
  principal == ?principal,
  action in [MyApp::Action::"DocumentRead"],
  resource == ?resource
);

정책 템플릿 생성을 완료했습니다. 이제 템플릿을 사용하여 정책 생성을 단순화합니다. 탐색 창에서 정책을 고른 다음 Create a template-linked policy을 정책 드롭다운 생성에서 선택합니다. 방금 생성한 정책 템플릿을 선택하고 다음을 선택합니다.

사용자(danilop)에게 특정 문서(new-doc.txt)에 대한 액세스 권한을 부여하려면 다음 값을 전달하기만 하면 됩니다(참고로 MyApp은 정책 저장소의 네임스페이스입니다).

• 주체의 경우: MyApp::User::"danilop"
• 리소스의 경우: MyApp::Document::"new-doc.txt"

이제 정책 생성을 완료했습니다. 이제 정책이 예상대로 작동하는지 테스트할 차례입니다.

콘솔에서의 테스트 정책
내 애플리케이션에서는 AWS SDK를 사용하여 권한 부여 요청을 실행할 수 있습니다. 콘솔은 내 애플리케이션이 수행하는 작업을 시뮬레이션할 수 있는 방법을 제공합니다. 탐색 창에서 테스트 벤치를 선택합니다. 테스트를 단순화하기 위해 Visual 모드를 사용합니다. 대안으로 SDK와 동일한 JSON 구문을 사용하는 옵션이 있습니다.

주체로서 janedoe 사용자를 합격시킵니다. 리소스로는 requirements.txt를 사용합니다. 이는 공개 문서가 아니고 (isPublic은 거짓) 소유자 속성은 janedoe의 하위와 동일합니다. 작업의 경우 MyApp::Action::"DocumentUpdate"을(를) 선택합니다.

권한 부여 요청을 실행할 때 요청과 관련된 보안 주체 및 리소스에 대한 자세한 정보가 포함된 추가 엔티티를 전달할 수 있습니다. 일단 이 부분은 비워 두겠습니다.

현재 정책에 따른 결정을 보려면 상단에서 승인 요청 실행을 선택합니다. 예상대로 결정은 허용됩니다. 여기에서는 권한 부여 요청을 통해 어떤 정책이 충족되었는지도 확인할 수 있습니다. 이 경우 문서 소유자에게 전체 액세스를 허용하는 것이 정책입니다.

다른 값을 테스트할 수 있습니다. 문서 소유자와 작업을 DocumentRead로 변경하면 결정은 거부입니다. 그런 다음 리소스 속성 isPublic을 참으로 설정하면 모든 사용자가 공개 문서를 읽을 수 있도록 허용하는 정책이 있기 때문에 결정이 허용됩니다.

권한에서의 그룹 처리
내 애플리케이션의 관리 사용자는 모든 문서를 삭제할 수 있어야 합니다. 이를 위해 관리자 사용자용 역할을 생성합니다. 먼저 탐색 창에서 스키마를 선택한 다음 스키마 편집을 선택합니다. 엔티티 유형 목록에서 새 엔티티 유형을 추가하도록 선택합니다. 역할을 유형 이름으로 사용 및 추가합니다. 그런 다음 엔티티 유형에서 사용자를 선택하고 역할을 상위로 추가하도록 편집합니다. 변경 사항을 저장하고 다음 정책을 생성합니다.

permit (
  principal in MyApp::Role::"admin",
  action in [MyApp::Action::"DocumentDelete"],
  resource
);

테스트 벤치에서 권한 부여 요청을 실행하여 jeffbarr 사용자가 (DocumentDelete) 리소스 doc.txt를 삭제할 수 있는지 확인합니다. 그는 리소스 소유자가 아니므로 요청이 거부됩니다.

이제 추가 엔티티에서 MyApp::User 엔티티와 jeffbarr를 식별자로 추가합니다. 상위로서 MyApp::Role 엔티티와 admin을 식별자로 추가하고 확인합니다. 콘솔에서는 MyApp::Role::"admin" 엔터티가 참조되지만 추가 엔터티 데이터에는 포함되지 않는다는 경고가 표시됩니다. 이를 추가하고 이 문제를 해결하기로 결정했습니다.

권한 부여 요청을 다시 실행했는데 이제 허용되었습니다. 추가 엔티티에 따르면 주체 (jeffbarr) 가 관리자이기 때문입니다.

애플리케이션에서 Amazon Verified Permissions 사용
내 애플리케이션에서는 isAuthorized API 작업 (또는 보안 주체가 외부 ID 소스에서 오는 경우 isAuthrizedWithToken)을 사용하여 권한 부여 요청을 실행할 수 있습니다.

예를 들어, 다음 Python 코드는 AWS SDK for Python(Boto3)를 사용하여 사용자에게 문서에 대한 읽기 권한이 있는지 확인합니다. 권한 부여 요청은 방금 생성한 정책 저장소를 사용합니다.

import boto3
import time

verifiedpermissions_client = boto3.client("verifiedpermissions")

POLICY_STORE_ID = "XAFTHeCQVKkZhsQxmAYXo8"

def is_authorized_to_read(user, resource):

    authorization_result = verifiedpermissions_client.is_authorized(
        policyStoreId=POLICY_STORE_ID, 
        principal={"entityType": "MyApp::User", "entityId": user}, 
        action={"actionType": "MyApp::Action", "actionId": "DocumentRead"},
        resource={"entityType": "MyApp::Document", "entityId": resource}
    )

    print('Can {} read {} ?'.format(user, resource))

    decision = authorization_result["decision"]

    if decision == "ALLOW":
        print("Request allowed")
        return True
    else:
        print("Request denied")
        return False

if is_authorized_to_read('janedoe', 'doc.txt'):
    print("Here's the doc...")

if is_authorized_to_read('danilop', 'doc.txt'):
    print("Here's the doc...")

이 코드를 실행하면 예상대로 출력은 이전에 실행한 테스트와 일치합니다.

janedoe가 doc.txt를 읽을 수 있나요?
요청 거부됨
danilop이 doc.txt 를 읽을 수 있나요?
요청 허용됨
여기 문서가 있습니다...

가용성 및 요금
Amazon Verified Permissions은 현재 중국에 기반을 둔 리전을 제외한 모든 상용 AWS 리전에서 사용할 수 있습니다. Amazon Verified Permission을 사용하면 서비스에 대한 승인 요청 및 API 호출의 수를 기준으로 사용한 만큼만 비용을 지불하면 됩니다. 자세한 내용은 Amazon Verified Permissions 요금을 참조하십시오.

Amazon Verified Permissions을 사용하면 Cedar 정책 언어를 사용하여 세분화된 권한을 구성하고 애플리케이션 코드를 단순화할 수 있습니다. 이렇게 하면 권한이 중앙 저장소에서 유지 관리되며 감사하기가 더 용이해집니다. 여기에서 자동화된 추론 및 미분 테스트를 통해 Cedar를 구축한 방법에 대해 자세히 알아볼 수 있습니다.

– Danilo

Source: Amazon Verified Permissions 정식 출시 – 애플리케이션 권한 관리 방법을 간소화하기