액세스 권한을 효과적으로 관리하는 것은 Amazon Quick에서 안전하고 협업적인 환경을 유지하는 중요한 측면입니다. Quick은 다양한 아이덴티티 유형과 조직의 요구를 수용하도록 설계된 다재다능한 사용자 관리 옵션을 지원합니다. Quick Identity를 통해 기본적으로 사용자를 프로비저닝하거나 AWS IAM Identity Center 또는 Active Directory와 같은 엔터프라이즈 아이덴티티 공급자를 통해 사용자를 관리할 수 있습니다. 이러한 시스템을 통해 Admin, Author, Reader 등의 사용자 역할을 직무 기능 및 보안 요구 사항에 따라 할당하고 그룹화할 수 있습니다. 팀 구성원이 조직에 합류하거나 역할이 변경되거나 조직을 떠날 때, 관리자는 업무 워크플로를 방해하거나 보안 공백을 만들지 않으면서 전환이 원활하게 이루어지도록 해야 합니다.
정기적인 액세스 검토는 Quick 환경의 보안을 유지하는 데 중요합니다. 월별 또는 분기별로 사용자 역할을 감사하여 모든 사람이 적절한 권한을 가지고 있는지 확인하는 계획을 세우십시오. 팀 구성원의 책임이 변경될 때는 고아 리소스(orphaned resources)가 발생하지 않도록 해당 구성원의 대시보드 및 분석물 소유권을 사전에 이전하십시오. 이 관행은 다음에 권장된 바와 같으며, AWS Well-Architected Framework업무에 필수적인 시각화의 연속성을 유지하는 데 도움이 됩니다.
이 게시물에서는 특정하지만 중요한 사용자 수명 주기 작업인 사용자 역할 다운그레이드에 초점을 맞춥니다.
왜 다운그레이드해야 할까요?
최소 권한 원칙은 Quick 관리에 매우 잘 적용됩니다. 사용자는 자신의 특정 직무 기능에 필요한 것에만 액세스할 수 있어야 합니다. 사용자 역할 다운그레이드는 최소 권한을 시행하는 핵심 부분입니다. 사용자의 책임에 더 이상 작성 또는 관리 기능이 필요하지 않게 되면, 보안 노출 영역을 최소화하기 위해 그에 맞게 역할을 낮추십시오.
Quick 요금제도 역할 기반입니다: Author와 Admin은 사용자당 고정 월 요금을 지불하는 반면, Reader는 세션 기반 요금을 사용합니다. 대시보드를 소비만 하는 사용자가 Author로 프로비저닝되어 있는 조직은 이를 Reader 역할에 맞게 조정함으로써 비용을 상당히 절감할 수 있습니다. 최신 요금 세부 정보는 다음을 참조하십시오. Amazon Quick 요금 페이지.
Amazon Quick의 내장 역할을 넘어 더 세분화된 제어를 원한다면, 역할 할당을 다음과 함께 보완하는 것을 고려하십시오. Custom Permissions이는 역할 계층 내에서 특정 기능을 제한합니다. Amazon Quick과 다음의 통합은 AWS Identity and Access Management (IAM) 기본 역할 시스템을 보완하는 추가 권한 경계를 제공합니다.
이 게시물의 범위
정확한 단계는 사용자 아이덴티티 유형에 따라 다르지만, 이 게시물은 주로 Amazon Quick Identity 사용자(Quick 관리 사용자라고도 함)를 다룹니다. IAM Identity Center 또는 Active Directory를 통해 인증된 사용자는 일반적으로 외부 아이덴티티 공급자의 그룹 매핑을 통해 역할 변경이 관리됩니다. 환경에서 IAM Identity Center를 사용하는 경우, 역할 다운그레이드는 사용자를 한 IdC 그룹에서 다른 그룹으로 이동하여 처리됩니다(예: Quick-Admins 그룹에서 Quick-Readers 그룹으로). 단계적 강등 시퀀스가 필요하지 않습니다.
Amazon Quick 콘솔은 모든 역할 전환에 대한 직접적인 다운그레이드 경로를 제공하지 않지만(구체적으로, 콘솔 인터페이스를 통해 Admin에서 Reader로 또는 Author에서 Reader로 직접 다운그레이드할 수 없음), 두 가지 안정적인 솔루션이 존재합니다: 수동 삭제 및 재생성 방법과 AWS Command Line Interface (AWS CLI)를 사용하는 방법입니다. 팀이 발전함에 따라 적절한 액세스 관리를 유지하는 데 도움이 되도록 두 기술을 모두 안내해 드립니다.
사전 조건
시작하기 전에 Amazon Quick에 대한 관리자 액세스 권한이 있는 활성 AWS 계정이 있는지 확인하십시오. CLI 방법을 사용할 계획이라면 머신에 다음이 필요합니다. AWS CLI 설치 및 구성 역할을 변경해야 하는 사용자 목록을 준비해 두는 것도 유용합니다.
Amazon Quick 역할 이해
Amazon Quick은 서로 다른 역할 세트를 가진 두 가지 구독 계층을 제공합니다:
| 구독 | 역할 | 기능 |
| Amazon Quick Enterprise | Admin Pro, Author Pro, Reader Pro | 전체 BI + AI 기능(에이전트, 토픽, Q&A, 스토리, 생성형 요약) |
| Amazon Quick Sight (BI 전용) | Admin, Author, Reader | 기존 BI 제작 및 소비 |
콘솔에서는 Author 등급에서 Reader 등급으로 직접 강등할 수 있는 방법을 제공하지 않습니다. update-user API도 동일한 제약 조건을 적용하며, 직접 강등 시도에 대해 “You cannot downgrade a user role” 오류를 반환하며 거부합니다.
다음 스크린샷은 Amazon Quick Suite 사용자 관리 페이지를 보여주며, 콘솔에서는 사용자를 Author 등급에서 Reader 등급으로 강등하는 직접적인 컨트롤을 제공하지 않습니다. 이것이 이 게시물의 방법들이 필요한 이유를 보여줍니다.
그림 1: Amazon Quick Suite 사용자 관리 페이지
CLI 단계적 강등 방법은 레거시 BI 전용 역할 (Admin, Author, Reader)에 대해 다음 순서로 안정적으로 작동합니다:
Admin > Author > Restricted Reader > Reader
이 동일한 순서는 중간 단계에서 레거시 역할을 사용하는 한 Pro 사용자에게도 적용됩니다. 예를 들어, Author Pro > Author > Restricted Reader > Reader Pro는 성공적으로 완료됩니다.
변경을 수행하기 전에 고려해야 할 중요한 사항
두 가지 방법 중 어느 것을 통해 역할 변경을 구현할 때 염두에 두어야 할 몇 가지 중요한 요소가 있습니다. 첫째, 변경을 수행하기 전에 목록에 있는 모든 사용자가 현재 Admin 또는 Author 사용자인지 확인하십시오. 이미 낮은 권한을 가진 사용자를 강등하려고 시도하면 오류가 발생할 수 있습니다. CLI 방법을 사용하더라도 리소스 소유권 문제는 여전히 적용됩니다. 강등되는 사용자는 더 이상 이전에 소유했던 리소스를 편집할 수 없게 됩니다. CLI 방법을 사용하는 대규모 조직에서는 값을 하드코딩하는 대신 CSV 파일에서 사용자 이메일 주소를 로드하는 것을 고려하십시오. AWS CloudShell 을 로컬 CLI 설치 대신 사용하는 경우, AWS CloudShell이 현재 콘솔 리전 컨텍스트를 자동으로 사용하기 때문에 AWS 리전 지정을 생략할 수 있습니다.
자산 소유권 이전 (먼저 수행)
사용자를 삭제하기 전에 해당 사용자가 소유한 대시보드, 데이터 세트, 분석 등의 자산이 적절히 재할당되었는지 확인하는 것이 필수적입니다. 이는 중단을 방지하고 리소스가 고아 상태로 남는 것을 피합니다. 해당 사용자가 Author인 경우, 소유한 데이터 세트나 대시보드가 있는지 확인하고 여기에 설명된 것과 동일한 자산 재할당 단계를 따르십시오. Amazon Quick에서 자산 소유권 이전을 처리하는 데에는 세 가지 주요 방법이 있습니다.
옵션 1: 다른 관리자에게 사전에 소유권 이전
가장 통제된 방식은 사용자를 삭제하기 전에 소유권을 수동으로 재할당하는 것입니다. 이를 위해 Quick의 각 자산으로 이동하여 Share를 선택하고 다른 관리자를 공동 소유자로 지정하십시오. 이 방법을 사용하면 각 리소스를 누가 인수하는지 정확히 결정할 수 있으며, 이는 특히 영향이 큰 대시보드나 데이터 세트에 유용합니다. 대규모 환경에서는 시간이 많이 걸릴 수 있지만, 팀의 구조와 책임에 따라 자산을 분배할 수 있는 유연성을 제공합니다.
다음 스크린샷은 자산의 Share 대화 상자를 보여주며, 여기서 원래 사용자가 제거되기 전에 소유권이 이전되도록 다른 관리자를 공동 소유자로 추가합니다.
그림 2: 다른 사용자에게 자산 소유권 이전
옵션 2: Admin 페이지에서 Amazon Quick 대량 자산 이전 사용
사용자가 많은 자산을 소유하고 있는 경우 수동 방식은 비효율적일 수 있습니다. 이 경우 Quick의 Admin 섹션에서 사용할 수 있는 Manage assets 기능을 사용할 수 있습니다. 이 도구를 사용하면 관리자가 여러 자산에 대해 한 번에 대량 소유권 이전 또는 공유 권한 업데이트를 수행할 수 있습니다. 이는 특히 사용자 오프보딩이나 조직 변화 관리 시 재할당 프로세스를 크게 간소화합니다. 이 기능 사용 방법에 대한 자세한 내용은 공식 Managing assets in Amazon Quick 문서를 참조하십시오.
옵션 3: Quick 사용자 그룹과 자산 공유
또 다른 효과적인 전략은 사용자 그룹과 자산을 공유하는 것입니다. Quick Identity 사용자의 경우 Quick 그룹을 만들고 관련 팀 구성원을 추가한 다음, 개별 사용자가 아닌 그룹과 대시보드나 데이터 세트를 공유할 수 있습니다. 계정이 IAM Identity Center 또는 Active Directory와 통합되어 있는 경우, 동등한 그룹이 해당 시스템에서 생성 및 관리되며 Quick은 Quick 관리 그룹 대신 해당 외부 그룹을 액세스 제어에 사용합니다. 이렇게 하면 특정 사용자가 삭제되더라도 공유 리소스에 대한 액세스가 그대로 유지됩니다. 이는 향후 소유권 재할당의 필요성을 줄이고 변화하는 팀 전반에서 일관된 액세스를 유지하는 데 도움이 되는 탄력적인 접근 방식입니다.
수동 방법: 사용자 삭제 후 재생성
가장 효율적인 방법은 아니지만, 수동 삭제 및 재생성 방법은 CLI 사용이 불가능한 환경을 위한 하나의 옵션입니다. 이 방법은 관리자 사용자를 완전히 제거한 다음 reader 권한으로 다시 생성하는 것을 포함합니다. 이 동일한 수동 방법은 Author를 Reader로 강등할 때에도 적용되지만, 일반적으로 자산 소유권과 관련된 복잡한 문제는 더 적습니다.
이 방법은 더 낮은 역할로 사용자를 다시 생성하기 전에 사용자 계정을 삭제해야 하므로, 귀중한 리소스 손실과 워크플로 중단을 피하기 위해 신중한 준비가 필수적입니다. 진행하기 전에 이전 섹션에서 설명한 자산 소유권 이전을 완료했는지 확인하십시오.
1단계: 관리자 사용자 삭제
모든 리소스의 소유권을 이전한 후, AWS Management Console에 로그인하여 Amazon Quick 서비스로 이동하십시오. 거기서 프로필 아이콘을 선택한 다음 Manage Quick를 선택하고, 이어서 Manage users를 선택하십시오. 강등하려는 관리자 사용자를 찾으면 이름 옆의 삭제 아이콘을 선택하고 확인 메시지가 표시되면 삭제를 확인하십시오. 이렇게 하면 해당 사용자의 현재 시스템 액세스 권한이 완전히 제거됩니다.
사전에 모든 리소스를 이전하지 않은 경우, Quick이 소유권 이전 대화 상자를 표시합니다. 이 대화 상자는 해당 사용자의 모든 리소스 소유권을 받을 다른 관리자를 선택하라는 메시지를 표시합니다. 목록에서 적절한 관리자를 선택한 다음 다음을 선택하여 이전을 확인하십시오. 삭제 및 전송. 이 내장 전송 메커니즘은 고아 리소스 발생을 방지하는 데 도움이 되지만 모든 것을 단일 관리자에게 전송합니다. 보다 세밀한 제어를 원한다면 앞서 언급한 사전 대응 방식을 사용하여 팀 구성원들에게 전략적으로 리소스를 분배하십시오.
사전 전송을 건너뛴 경우, 다음 그림에 표시된 삭제 대화 상자를 통해 계정이 제거되기 전에 해당 사용자의 모든 리소스를 단일 관리자에게 재할당할 수 있습니다.
그림 3: 사용자 삭제 중 내장 리소스 전송
2단계: Reader 역할로 사용자 재생성
사용자를 성공적으로 삭제한 후에는 사용자 페이지에 머물며 다음을 선택하십시오. 사용자 초대. 사용자의 이메일 주소를 입력하고 사용 가능한 옵션에서 Reader 역할을 선택하세요. 초대를 보내면 사용자가 새로운, 더 제한적인 권한으로 Quick에 다시 참여할 수 있습니다.
3단계: 역할 변경 확인
사용자가 초대를 수락한 후:
- 권한이 Reader.
- 로 업데이트되었는지 확인합니다.
- 대시보드와 보고서만 볼 수 있는지 확인합니다.
콘텐츠를 수정하거나 만들 수 없는지 확인합니다.
AWS CLI 또는 AWS CloudShell을 사용하고 싶으시다면, 프로그래밍 방식으로 사용자의 역할을 변경할 수 있습니다. Quick에서는 역할 변경이 특정 순서에 따라 이루어져야 하기 때문에, 모든 Admin 역할에서 모든 Reader 역할로 직접 전환할 수는 없습니다. 대신 중간 역할을 단계적으로 거쳐야 합니다.
AWS CLI나 AWS CloudShell을 사용하려면 프로그래밍 방식으로 사용자의 역할을 변경할 수 있습니다. Quick은 역할 변경을 특정 순서로 수행해야 하므로, 어떤 Admin에서 어떤 Reader로 직접 전환할 수 없습니다. 대신 중간 역할을 단계적으로 거쳐야 합니다.
- 중요 참고 사항
<your-account-id>를 - 본인의 AWS 계정 ID로 바꾸세요.
<user-name>를 - 사용자의 사용자 이름으로 바꾸세요.
<user-email>를 - 사용자의 이메일 주소로 바꾸세요.
--regionCloudShell 외부에서 AWS CLI를 사용하는 경우 - 파라미터를 지정하세요.
--role값은 API 역할 이름과 정확히 일치해야 합니다(앞의 표 참조).
예: 레거시 트랙(Admin에서 Reader로)
1단계: Admin에서 Author로 역할 변경:
aws quicksight update-user \
--aws-account-id <your-account-id> \
--user-name <user-name> \
--namespace default \
--email <user-email> \
--role AUTHOR2단계: Author에서 Restricted Reader로 역할 업데이트:
aws quicksight update-user \
--aws-account-id <your-account-id> \
--user-name <user-name> \
--namespace default \
--email <user-email> \
--role RESTRICTED_READER3단계: Restricted Reader에서 Reader로 역할 변경:
aws quicksight update-user \
--aws-account-id <your-account-id> \
--user-name <user-name> \
--namespace default \
--email <user-email> \
--role READER다운그레이드 후: Limit Profiles 및 Custom Permissions 검토
역할 변경 시 Limit Profiles나 Custom Permissions 프로필이 자동으로 조정되지 않습니다. 두 항목 모두 사용자의 역할과 독립적으로 유지되므로 강등 후에는 반드시 검토해야 합니다.
- 한도 프로필 인덱스 스토리지 및 에이전트 시간과 같은 리소스에 대한 사용자별 상한을 제어합니다. 다운그레이드된 사용자에게 이전의 Admin 또는 Author 역할에 적합한 프로필이 할당되어 있었다면, 리소스 과다 할당을 피하기 위해 Reader에게 적합한 제한 프로필을 다시 할당하십시오. 다음을 참조하십시오. Limit Profiles 문서 자세한 내용은 다음을 참조하십시오.
- 사용자 지정 권한 역할 등급(role tier) 내에서 특정 기능을 제한합니다. Author에게 할당된 프로필이 Reader에서는 예상대로 작동하지 않을 수 있습니다. 최종 CLI 단계에서 프로필 적용을 해제하거나(을 사용하여),
--unapply-custom-permissions") 또는 Reader 등급용으로 설계된 프로파일을 할당하십시오.
여러 사용자를 업데이트하는 스크립트
여러 사용자를 업데이트하려면 다음 스크립트를 사용하세요.
#!/bin/bash
# Define AWS account details
AWS_ACCOUNT_ID="<your-account-id>"
REGION="<your-region>"
# Load users from file (format: username,email per line)
# Lines starting with # are treated as comments
INPUT_FILE="users_to_downgrade.txt"
while IFS=',' read -r username email; do
# Skip comments and empty lines
[[ "$username" =~ ^#.*$ || -z "$username" ]] && continue
echo "Processing user: $username"
# Role transition stages
for ROLE in AUTHOR RESTRICTED_READER READER; do
RESULT=$(aws quicksight update-user \
--aws-account-id "$AWS_ACCOUNT_ID" \
--user-name "$username" \
--namespace default \
--email "$email" \
--role "$ROLE" \
--region "$REGION" 2>&1)
if [ $? -ne 0 ]; then
echo " ERROR at $ROLE: $RESULT"
break
fi
echo " Transitioned to $ROLE"
sleep 3
done
echo "Role update completed for $username."
done < "$INPUT_FILE"
echo "All user role updates processed!"스크립트 기능
이 스크립트는 다음을 수행합니다:
- 외부 파일에서 사용자 이름과 이메일 주소를 읽어옵니다(#을 사용한 주석을 지원).
- 세 단계에 걸쳐 역할을 업데이트합니다: Admin > Author > Restricted Reader > Reader.
- 에러 처리는 어떤 단계든 실패하면 해당 사용자의 전환을 중단시킵니다.
- Sleep 명령은 변경 사항이 적용될 시간을 확보해 줍니다.
스크립트를 실행할 때 유의할 몇 가지 사항:
- 실행하기 전에 해당 사용자가 현재 Admin 또는 Author 사용자인지 확인하십시오.
- 연동(federated) 환경에서는 이메일 접두사와 다를 수 있는 실제 Quick 사용자 이름을 사용하십시오.
- AWS CloudShell에서는 리전(Region) 지정이 필요하지 않습니다.
- 다음의 CSV 내보내기에서 사용자를 불러오도록 스크립트를 수정할 수 있습니다.
list-users.
사용자 액세스 관리를 위한 모범 사례
Quick 환경을 안전하고 체계적으로 유지하려면 다음 모범 사례를 따르십시오:
- 사용자 역할을 정기적으로 검토합니다(월간 또는 분기별 감사).
- 역할을 변경하기 전에 리소스 소유권을 이전합니다.
- 최소 권한 원칙을 따릅니다.
- 역할 계층 내에서 세분화된 제어를 위해 Custom Permissions 프로파일을 사용합니다.
- 복원력을 위해 개인이 아닌 그룹과 리소스를 공유합니다.
- 추가 권한 경계를 위해 AWS Identity and Access Management를 사용합니다.
정리
사용자 역할 변경을 완료한 후:
- 테스트 사용자를 제거합니다.
- 의도하지 않은 리소스가 남아 있지 않은지 확인합니다.
- 임시 CLI 스크립트나 사용자 목록 파일을 삭제합니다.
- 최종 사용자 권한을 재확인합니다.
결론
이 게시물에서는 Amazon Quick에서 사용자 역할을 다운그레이드하는 두 가지 방법, 즉 수동 삭제 및 재생성 방식과 유연한 AWS CLI 방식을 살펴보았습니다. 이러한 전략은 팀 액세스를 효율적이고 안전하게 관리하는 데 도움이 됩니다.
IAM Identity Center를 사용하는 환경에서는 역할 변경이 IdC 그룹 재할당을 통해 관리되며, 여기서 설명하는 단계적 강등 절차가 필요하지 않습니다. 추가 거버넌스 제어를 위해 기능 수준 제한을 위한 Custom Permissions 과(와) 콘텐츠 수준 격리를 위한 Restricted Folders 을(를) 살펴보십시오.
리소스
- Amazon Quick에서 사용자 액세스 관리
- Amazon Quick에서 자산 관리
- Custom Permissions 프로파일
- AWS IAM 모범 사례
- AWS Business Intelligence Blog
사용자 관리 경험에 대한 이야기를 들려주세요. 귀하의 조직은 Quick Suite에서 역할 전환을 어떻게 처리합니까? 이러한 변경을 간소화하기 위해 사용자 지정 스크립트나 프로세스를 개발하셨습니까? 댓글에서 여러분의 생각과 어려움을 공유해 주세요.