View a markdown version of this page

API 작업에서 Amazon Verified Permissions 정책 스토어 별칭 사용 - Amazon Verified Permissions
작업에서 정책 스토어 별칭 사용에서 정책 스토어 별칭 사용 AWS 리전정책 스토어 별칭은 트래픽 제어 메커니즘이 아닙니다.가동 중지 없는 정책 스토어 변경 수행

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

API 작업에서 Amazon Verified Permissions 정책 스토어 별칭 사용

IsAuthorized, IsAuthorizedWithTokenIsAuthorizedWithToken, GetPolicyStore와 같은 policyStoreId 파라미터를 수락하는 모든 Amazon Verified Permissions 작업은 정책 스토어 ID 대신 정책 스토어 별칭 이름을 수락할 수 있습니다.

중요

정책 스토어 별칭을 policyStoreId 파라미터 값으로 사용하는 경우 policy-store-alias/ 접두사를 포함해야 합니다. 예를 들어가 policy-store-alias/example-policy-store아닌를 사용합니다example-policy-store.

작업에서 정책 스토어 별칭 사용

다음 IsAuthorized 명령은 이름이 인 정책 스토어 별칭example-policy-store을 사용하여 정책 스토어를 식별합니다.

AWS CLI
$ aws verifiedpermissions is-authorized \
    --policy-store-id policy-store-alias/example-policy-store \
    --principal entityType=User,entityId=alice \
    --action actionType=Action,actionId=view \
    --resource entityType=Photo,entityId=photo123
참고

DeletePolicyStore 작업에는 policyStoreId 필드 대신 정책 스토어 별칭을 사용할 수 없습니다.

에서 정책 스토어 별칭 사용 AWS 리전

별칭의 가장 강력한 용도 중 하나는 여러 AWS 리전에서 실행되는 애플리케이션에서 사용하는 것입니다. 예를 들어 각 리전에 서로 다른 정책 스토어를 사용하는 글로벌 애플리케이션이 있을 수 있습니다.

  • us-east-1에서는를 사용하려고 합니다PSEXAMPLEabcdefg111111.

  • eu-west-1에서는를 사용하려고 합니다PSEXAMPLEabcdefg222222.

각 리전에서 다른 버전의 애플리케이션을 생성하거나 사전 또는 스위치 문을 사용하여 각 리전에 적합한 정책 스토어를 선택할 수 있습니다. 그러나 각 리전에서 동일한 정책 스토어 별칭 이름으로 정책 스토어 별칭을 생성하는 것이 훨씬 쉽습니다. 정책 스토어 별칭 이름은 대/소문자를 구분합니다.

AWS CLI
$ aws --region us-east-1 verifiedpermissions create-policy-store-alias \
    --alias-name policy-store-alias/my-app \
    --policy-store-id PSEXAMPLEabcdefg111111

$ aws --region eu-west-1 verifiedpermissions create-policy-store-alias \
    --alias-name policy-store-alias/my-app \
    --policy-store-id PSEXAMPLEabcdefg222222

그런 다음 코드에서 정책 스토어 별칭을 사용합니다. 코드가 각 리전에서 실행되면 정책 스토어 별칭은 해당 리전의 연결된 정책 스토어를 참조합니다.

AWS CLI
$ aws verifiedpermissions is-authorized \
    --policy-store-id policy-store-alias/my-app \
    --principal entityType=User,entityId=alice \
    --action actionType=Action,actionId=view \
    --resource entityType=Photo,entityId=photo123

그러나 정책 스토어 별칭이 삭제될 위험이 있습니다. 이 경우 애플리케이션의 정책 스토어 별칭 이름 사용 시도가 실패하고 정책 스토어 별칭을 다시 생성하거나 업데이트해야 할 수 있습니다. 이 위험을 완화하려면 보안 주체에게 애플리케이션에서 사용하는 정책 스토어 별칭을 관리할 수 있는 권한을 부여해야 합니다.

정책 스토어 별칭은 트래픽 제어 메커니즘이 아닙니다.

정책 스토어 별칭은 정책 스토어의 안정적이고 친숙한 이름입니다. 정책 스토어 간에 권한 부여 트래픽을 이동, 분할 또는 가중치를 부여하는 메커니즘은 아닙니다. Lambda 별칭과 같이 리소스 버전 간에 트래픽을 라우팅하는 기능에 익숙한 경우 정책 스토어 별칭은 동일한 방식으로 작동하지 않습니다. 설계상 정책 스토어 별칭은 AWS KMS 키 별칭에 더 가깝습니다. 즉, 앞에 있는 라우팅 계층이 아니라 리소스에 대한 내구성 있는 이름을 제공합니다.

이러한 이유로 의도적으로 UpdatePolicyStoreAlias 작업을 제공하지 않습니다. 정책 스토어 별칭이 가리키는 정책 스토어를 변경하려면 정책 스토어 별칭을 삭제하고 이름이 같고 다른 정책 스토어를 대상으로 하는 새 정책 스토어 별칭을 생성합니다. 이는 원자성 작업이 아니며 트래픽 제어 메커니즘이 보장하지 않습니다.

정책 스토어 별칭이 확인되는 정책 스토어를 변경하면 변경 사항이 동일한 시점에 모든 곳에서 적용되지 않습니다.

  • 업데이트된 매핑은 컨트롤 플레인에서 권한 부여 요청을 평가하는 데이터 플레인으로 전파되어야 합니다. 매핑은 즉시 전파되지 않습니다.

  • 정책 스토어 별칭 확인은 최종적으로 일관되고 캐시될 수 있으므로 변경 후 전환 기간이 존재합니다. 이 기간 동안 이전에 연결된 정책 스토어는 일부 요청을 처리하고 새로 연결된 정책 스토어는 다른 요청을 처리합니다. 이 창의 길이는 불확정입니다.

이 기간 동안 애플리케이션은 두 정책 스토어 중 하나로부터 권한 부여 결정을 받을 수 있습니다. 정책 스토어마다 정책, 엔터티 및 스키마가 다를 수 있으므로 동일한 요청은 어떤 정책 스토어가 이를 제공하는지에 따라 다른 결정을 내릴 수 있습니다. 따라서 정책 스토어 별칭은 정책 스토어 간에 원자성 전환을 제공할 수 없으며 배포 또는 트래픽 관리 전략을 대체하지 않습니다.

별칭을 전환 메커니즘으로 사용하지 마세요.

한 정책 스토어에서 다른 정책 스토어로 권한 부여 트래픽을 전환하기 위해 정책 스토어 별칭을 다시 가리키는 상위 수준의 infrastructure-as-code 또는 배포 프리미티브를 구축하지 마세요. 변경 사항은 원자성이 아니므로 불확정 기간 동안 두 정책 스토어에 대해 동시에 요청을 승인할 수 있습니다. 이로 인해 권한 부여 결정이 일관되지 않을 수 있습니다. 정책 스토어를 안전하게 전환하려면 섹션을 참조하세요가동 중지 없는 정책 스토어 변경 수행.

가동 중지 없는 정책 스토어 변경 수행

정책 스토어 별칭은 원자성 전환을 제공하지 않으므로( 참조정책 스토어 별칭은 트래픽 제어 메커니즘이 아닙니다.) 정책 스토어 별칭을 다시 지정하여 한 정책 스토어에서 다른 정책 스토어로 마이그레이션하지 않는 것이 좋습니다. 대신 새 정책 스토어를 검증하고 필요한 경우 즉시 롤백할 수 있도록 애플리케이션 내에서 마이그레이션을 제어합니다. 다음 접근 방식을 사용하면 가동 중지 없이 정책 스토어를 전환할 수 있습니다.

  1. 새 정책 저장소를 생성하고 고유한 정책 저장소 별칭을 지정하여 현재 정책 저장소와 새 정책 저장소에 각각 고유하고 안정적인 이름이 지정되도록 합니다. 예를 들어 현재 정책 스토어를 policy-store-alias/example-policy-store 계속 가리키고 새 정책 스토어에 policy-store-alias/example-policy-store-2 대해를 생성합니다. 전환을 수행하기 위해 단일 정책 스토어 별칭을 재사용하거나 다시 지정하지 마십시오.

  2. 정책, 스키마 및 기타 구성을 새 정책 스토어에 복제하고 현재 정책 스토어와 병렬로 실행합니다.

  3. 권한 부여 결정에 권한이 있는 정책 스토어 별칭을 결정하는 구성 값 또는 기능 플래그를 애플리케이션에 추가합니다(예: AppConfig 사용). 트래픽을 전환하기 위해 별칭 자체를 변경하는 데 의존하지 마십시오.

  4. 섀도우 모드에서 새 정책 스토어를 실행합니다. 두 정책 스토어에 동일한 IsAuthorized 또는 IsAuthorizedWithToken 요청을 보내고 결정을 비교합니다. 새 정책 스토어가 예상한 결정을 반환할 때까지 불일치를 기록하고 조사합니다.

  5. 기능 플래그를 사용하여 애플리케이션 호스트 또는 사용자 세그먼트 간에 단계별 롤아웃에서 권한 부여 결정을 새 정책 스토어 별칭으로 점진적으로 이동합니다. 진행하면서 권한 부여 결정 및 오류 발생률을 모니터링합니다.

  6. 문제가 감지되면 기능 플래그를 사용하여 즉시 원래 정책 스토어 별칭으로 다시 전환합니다. 애플리케이션이 스위치를 제어하기 때문에 롤백은 즉시 이루어지며 별칭 전파에 의존하지 않습니다.

  7. 새 정책 스토어가 완전히 검증되고 모든 트래픽을 처리한 후 이전 정책 스토어와 해당 정책 스토어 별칭을 폐기합니다.

이 패턴은 별칭 전파 대신 애플리케이션에 각 요청을 처리하는 정책 스토어를 제어합니다. 이러한 제어는 마이그레이션을 안전하고 되돌릴 수 있게 하며 정책 스토어 별칭을 다시 가리키는 전환 기간을 방지합니다.