Claude Enterprise 읽기 전용 관리자 권한: 설정은 보여주고 변경은 막는 법
TL;DR
Claude Enterprise custom role의
Can view
는 선택한 관리자 영역의 페이지와 설정을 보여주되, 제어 항목은 비활성화하거나 읽기 전용으로 표시합니다. 조회할 필요가 없는 영역은
No access
로 숨깁니다. 실제 변경 담당자에게만
Can manage
를 줍니다.
역할을 저장한 것만으로는 끝나지 않습니다. 대상 사용자가 그룹에 포함되고 역할이
Custom
으로 바뀌었는지 먼저 확인합니다. 이어서
View effective role
과 실제 사용자 화면에서 조회 가능·변경 불가·비대상 영역 숨김을 각각 검증해야 합니다.
핵심 3줄 요약
핵심 1
핵심 1:
No access
는 관리자 영역을 숨깁니다.
Can view
는 설정을 보여주되 변경을 막고
Can manage
는 읽기와 쓰기를 모두 허용합니다.
핵심 2
핵심 2: 한 관리자 영역 안에서는 개별 페이지나 설정만 골라 허용할 수 없으므로 영역 단위로 범위를 정합니다.
핵심 3
핵심 3: 그룹 할당과
Custom
전환, 최대 15분의 반영 시간,
View effective role
, 실제 사용자 화면까지 확인해야 적용을 판정할 수 있습니다.
이 글에서 다룰 내용
이 글은 Claude Enterprise에서 감사·보안·재무 검토자에게 Owner 권한을 주지 않고 필요한 관리자 설정만 읽게 하는 흐름을 다룹니다. 비민감 테스트 그룹과 한 개 관리자 영역에서 시작해 변경 권한이 차단됐는지 확인합니다.
조직 전체 capability 변경, connector·model 권한 수정, Owner·Admin 대량 전환, 실제 운영 설정 변경은 첫 완료 범위에 넣지 않습니다. 결과물은 역할 변경 자체가 아니라 사람의 승인을 받은 권한 검증 기록입니다.
왜 조회 권한과 변경 권한을 나눠야 할까
설정 상태를 확인해야 한다는 이유만으로 Owner나 쓰기 권한을 줄 필요는 없습니다. 공식 문서는 compliance reviewer, finance auditor, security team처럼 구성을 확인하되 바꾸면 안 되는 담당자에게
Can view
를 쓰는 예를 듭니다.
반대로
Can manage
는 선택한 영역의 읽기와 쓰기를 모두 허용합니다. 특히
Identity & Access
를
Can manage
로 받은 구성원은 그룹과 역할을 만들거나 수정할 수 있습니다. 자기 역할 정의도 바꿔 접근을 넓힐 수 있으므로 이 권한은 신뢰할 수 있는 보안·IT 관리자에게만 맡겨야 합니다.
Claude Enterprise 읽기 전용 관리자 권한이란
Claude Enterprise의 custom role에는 관리자 영역마다
No access
,
Can view
,
Can manage
세 수준을 지정할 수 있습니다. 관리자 영역은
Identity & Access
,
Billing
,
Analytics
,
Privacy
,
User Management
,
Libraries
로 나뉩니다.
No access
면 해당 영역이 Organization settings에 나타나지 않습니다.
Can view
면
Can manage
사용자가 보는 것과 같은 페이지와 설정이 보입니다. 다만 모든 제어 항목은 비활성화되거나 읽기 전용으로 표시됩니다.
Can manage
는 조회를 포함한 전체 읽기·쓰기 권한입니다.
영역 안의 개별 페이지나 설정만 따로 허용하거나 제한할 수는 없습니다. 검토 범위를 먼저 정하고 영역 단위로 권한을 선택해야 합니다.
이 흐름이 맞는 상황
현재 설정을 확인해야 하지만 저장·삭제·권한 변경을 실행해서는 안 되는 내부 검토자에게 알맞습니다. 예를 들어 재무 검토자가
Billing
을 읽거나 보안 검토자가
Privacy
상태를 확인하는 파일럿을 만들 수 있습니다.
일상적인 Claude 사용 기능은 관리자 권한과 별도입니다. 공식 문서는 공통 기능을 주는 base role과 필요한 권한만 추가하는 additive role 구성을 일반적인 패턴으로 안내합니다. 첫 파일럿에서는 기존 base role을 유지하고 읽기 전용 관리자 역할만 더해 정상 업무가 계속되는지도 확인합니다.
시작 전에 기록할 것
변경 전 기록은 Claude가 자동으로 만드는 백업이 아니라 운영자가 관리하는 내부 점검표입니다. 다음 항목을 적습니다.
- 대상 Enterprise 조직과 비민감 테스트 그룹
- 검토할 관리자 영역 한 개와 현재 권한 수준
- 대표 검토자, 역할 변경 실행자, 승인자, 롤백 판단 담당자
- 사용자의 현재 built-in role 또는
Custom상태와 소속 그룹 - 유지해야 할 base role과 정상 업무 확인 항목
- 예상 반영 시간, 검증 시각, 원복 조건
Owners·Primary Owners 또는
Identity & Access
가
Can manage
인 custom role만 역할을 관리합니다. 파일럿 실행 계정이 이 조건을 충족하는지 먼저 확인합니다.
1단계: 한 개 관리자 영역과 검증 기준을 고릅니다
실제 운영 관리자 전체를 한꺼번에 바꾸지 않습니다. 승인된 테스트 그룹과 대표 사용자 한 명을 정합니다.
Billing
이나
Privacy
처럼 검토 목적에 맞는 영역 한 개만 선택합니다.
완료 기준을 세 갈래로 적습니다. 선택 영역은 보여야 하고 제어 항목은 저장할 수 없어야 합니다.
No access
로 둔 비대상 영역은 보이지 않아야 하며 기존 base role이 제공하는 정상 Claude 업무는 계속되어야 합니다.
2단계: Organization settings > Roles에서 역할을 준비합니다
Organization settings > Roles
로 이동합니다. 기존 테스트 역할을 열거나
Add role
로 역할을 만들고
Permissions
탭을 선택합니다.
이번 파일럿은 관리자 권한만 다룹니다.
Capabilities
,
Connectors
,
Models
탭을 임의로 바꾸지 않습니다. 새 역할을 만들 때는 각 탭의 기본값을 사람이 확인하고 승인 범위 밖의 권한이 추가되지 않았는지 기록합니다.
3단계: 선택 영역은 Can view, 나머지는 No access로 둡니다
선택한 관리자 영역에
Can view
를 지정합니다. 검토와 무관한 관리자 영역은
No access
로 둡니다. 파일럿 역할에는
Can manage
를 넣지 않습니다.
한 영역 안에서는 특정 페이지만 읽게 하거나 특정 설정만 숨길 수 없습니다. 선택 영역 전체가 보인다는 점을 승인자가 이해한 뒤 저장해야 합니다. 민감한 영역을 읽을 필요가 없다면
Can view
가 아니라
No access
가 맞습니다.
4단계: 그룹 할당과 Custom 전환을 따로 확인합니다
Custom role은 그룹에 할당합니다. 대상 사용자가 그 그룹에 실제 포함됐는지 확인합니다. 해당 구성원의 역할이
Custom
인지도 따로 봅니다.
User·Admin·Owner 같은 built-in role은 custom role에서 권한을 받지 않습니다. 역할을 만들어도 구성원이
Custom
이 아니거나 연결 그룹에 없으면 읽기 전용 권한은 적용되지 않습니다.
Owner나 Admin을 이번 파일럿에서
Custom
으로 바꾸지 않습니다. 공식 문서는 이 전환이 기존 Owner·Admin 접근을 제거한다고 경고하므로 별도 마이그레이션 계획과 승인이 필요합니다.
5단계: 반영을 기다리고 View effective role을 확인합니다
역할 변경은 적용까지 최대 15분이 걸릴 수 있고 브라우저 새로고침이 필요할 수 있습니다. 저장 직후에는 성공 여부를 단정하지 않습니다. 검증 시각부터 기록합니다.
Organization settings > Members
에서 대상 구성원의 메뉴를 열어
View effective role
을 확인합니다. 선택 영역의 관리자 권한과
Granted by
에 표시된 역할을 대조합니다. 다른 역할이 예상 밖의 권한을 부여하는지도 함께 봅니다.
6단계: 조회 가능·변경 불가·정상 업무를 양쪽에서 검증합니다
대표 검토자 계정으로 선택한 관리자 영역을 엽니다. 페이지와 설정은 보여야 하고 모든 제어 항목은 비활성화되거나 읽기 전용이어야 합니다. 저장·삭제·변경이 가능한 상태라면 통과가 아닙니다.
비대상 영역이 Organization settings에서 숨겨졌는지 확인합니다. 이어서 기존 base role로 허용된 비민감 정상 업무가 계속되는지 확인합니다. 관리자 변경 차단만 통과하고 정상 업무가 끊겼다면 파일럿을 확대하지 않습니다.
그대로 복사해 쓸 읽기 전용 권한 검토 프롬프트
아래 프롬프트는 비민감한 역할 설계 기록을 검토하는 용도입니다. Claude에게 관리자 설정을 변경시키지 않으며 실제 값, 사용자 신원, 결제 정보는 넣지 않습니다.
목표: Claude Enterprise 테스트 그룹에 한 개 관리자 영역의 읽기 전용 검토 권한을 부여하고 변경 차단과 정상 업무를 검증한다.
허용 입력: 익명 조직·그룹·사용자 라벨, 선택 관리자 영역, 현재·목표 권한 수준, base role 이름, 검증 시각, 원복 조건.
제외 입력: 실제 이름·이메일, 청구 금액·결제 정보, 보안 설정값, 고객 자료, 자격 증명, 운영 역할의 즉시 변경.
출력 형식: 1) 변경 전 상태 2) 역할·그룹·Custom 적용 확인 3) 조회 가능 항목 4) 변경 차단 항목 5) 정상 업무 확인 6) 확인 필요 7) 승인 지점.
완료 기준: 선택 영역은 보이고 제어 항목은 읽기 전용이며 비대상 영역은 숨겨지고, 기존 base role의 승인된 업무가 유지된 검토표.
추정 금지: 개별 페이지 권한, 즉시 반영, 자동 롤백, 다른 역할의 미확인 grant, 제품이 자동 생성한 감사 기록, 입력하지 않은 설정값.
승인 지점: 역할 저장 전, 구성원의 Custom 전환 전, 파일럿 확대 전 담당 승인자가 각각 확인한다.
실전 인사이트: View effective role과 실제 화면을 함께 봅니다
View effective role
은 어떤 역할이 권한을 주는지 찾는 데 유용합니다. 그러나 설정 결과는 실제 대표 사용자 화면에서도 확인해야 합니다. 관리자가 보는 역할 정의만으로 사용자 화면의 조회·차단 상태를 대신 판정하지 않습니다.
검증표에는
선택 영역 Can view
,
비대상 영역 No access
,
변경 제어 비활성
,
base role 정상 업무 유지
,
확인 필요 grant
를 별도 행으로 적습니다. 이렇게 나누면 권한 설계 오류와 반영 지연, 다른 역할의 grant를 구분하기 쉽습니다.
주의할 점
- Custom role은 Claude Enterprise 조직에서 사용합니다. Team이나 개인 플랜에 같은 경로가 있다고 가정하지 않습니다.
- 관리자 권한은 조직 capability 토글이나 구성원 개인 설정에 의해 제한되는 항목이 아닙니다. Custom role이 관리자 권한을 주면 그 접근이 생깁니다.
-
Can view는 선택 영역 전체를 보여 줍니다. 개별 페이지나 설정만 골라 숨기는 권한으로 설명하지 않습니다. -
Identity & Access > Can manage는 자기 역할을 바꿔 접근을 넓힐 수 있으므로 읽기 전용 파일럿에서 제외합니다. - Custom role은 그룹에 할당되고 구성원이
Custom이어야 적용됩니다. 역할 생성만으로 적용됐다고 보지 않습니다. - 변경은 최대 15분 걸릴 수 있습니다. 반영 중인 상태를 권한 실패로 단정하지 않습니다.
- 실제 설정 변경, Owner·Admin 전환, connector·model 수정, 대량 배포는 첫 완료 경계 밖에 둡니다.
자주 묻는 질문
Can view를 주면 일부 설정만 읽게 할 수 있나요?
아닙니다. 공식 문서에 따르면 한 관리자 영역 안에서는 모든 View 또는 모든 Manage를 부여합니다. 개별 페이지나 설정만 따로 허용하거나 제한할 수 없으므로 영역 전체를 볼 필요가 있는지 먼저 판단합니다.
No access와 Can view의 차이는 무엇인가요?
No access
는 해당 관리자 영역을 Organization settings에서 숨깁니다.
Can view
는 페이지와 설정을 보여 주지만 제어 항목을 비활성화하거나 읽기 전용으로 표시합니다.
역할을 저장했는데 사용자 화면이 달라지지 않는 이유는 무엇인가요?
대상 사용자가 역할과 연결된 그룹에 없거나 built-in role 상태일 수 있습니다. 적용에 최대 15분이 걸리거나 브라우저 새로고침이 필요할 수도 있습니다. 그룹,
Custom
상태,
View effective role
, 검증 시각을 차례로 확인합니다.
읽기 전용 역할을 주면 기존 Claude 업무가 끊기나요?
관리자 권한과 사용자 capability는 별도입니다. 공통 업무 capability를 주는 base role을 유지하고 읽기 전용 관리자 역할을 추가하는 구성을 검토합니다. 파일럿에서 정상 업무가 계속되는지 실제 대표 사용자로 확인해야 합니다.
출처
마무리
Claude Enterprise에서 설정 조회와 변경은 같은 권한일 필요가 없습니다. 필요한 영역은
Can view
, 불필요한 영역은
No access
, 실제 변경 책임은 별도
Can manage
역할로 나누면 검토와 변경 통제를 함께 유지할 수 있습니다.
마지막 판정은 역할 저장 화면이 아닌 실제 사용자 상태에서 내립니다. 그룹과
Custom
전환을 확인하고
View effective role
과 실제 화면의 조회·차단·정상 업무를 함께 검증한 뒤에만 파일럿을 넓힙니다.
