For AI agents: a documentation index is available at /docs/llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.
RBAC 모범 사례
Amplitude의 역할 기반 액세스 제어(RBAC) 시스템은 모든 Amplitude 제품 및 기능에 걸쳐 권한 관리를 통합합니다. 이러한 모범 사례는 조직의 성장에 따라 일관성과 확장성, 감사 가능성을 유지하도록 프로젝트 수준의 액세스를 설계하고 관리하는 방법을 보여줍니다. 역할, 권한 관리 및 동작에 대한 개념이나 전체 권한 참조에 대해서는 역할 기반 액세스 제어(RBAC)를 참조하십시오.
Amplitude의 프로젝트
Amplitude에서 프로젝트는 사용자가 보거나 수정할 수 있는 데이터, 사용할 수 있는 Amplitude 제품과 기능, 그리고 해당 프로젝트 첫 사용 후 수행할 수 있는 작업을 정의합니다.
프로젝트별로 권한 관리를 구성하고 관리할 때, 조직의 사용자는 해당 프로젝트 첫 사용 후 모든 Amplitude 제품에 대해 일관된 액세스를 받을 수 있습니다.
시스템 아키텍처
다음 지침을 따르면 귀사의 RBAC 구현이 귀사의 액세스 및 보안 요구 사항을 충족하는지 확인할 수 있습니다.
그룹을 기본 관리 계층으로 사용
그룹은 규모에 맞게 액세스를 관리하기 위한 기반입니다. Amplitude에서 그룹은 다음을 정의합니다.
- 그룹 구성원이 액세스할 수 있는 프로젝트입니다.
- 해당 프로젝트에서 사용자가 보유한 역할입니다.
- 적용되는 모든 데이터 액세스 제어.
그룹의 모든 구성원은 동일한 프로젝트에 대해 동일한 권한 관리 집합을 상속받습니다. 이를 통해 온보딩, 오프보딩 및 감사를 단순화할 수 있습니다.
관리 방법을 혼용하지 마십시오.
사용자가 그룹에 속해 있는 경우, 해당 사용자의 권한이 수동 재정의가 아닌 해당 그룹에서 파생되도록 하십시오.
필요한 경우에만 직접 역할 할당 사용
그룹 멤버십이 실용적이지 않은 경우에만 개별 사용자 수준 권한 관리를 사용하십시오. 예를 들면 다음과 같습니다.
- 계약자 또는 임시 협력자.
- 읽기 전용 액세스가 필요한 경영진.
- 서비스 또는 시스템 계정.
사용자에게 직접 권한 관리를 할당하는 경우 사유를 내부적으로 문서화하십시오.
일관성 유지
가능한 한 각 사용자를 그룹 또는 개별적으로 관리하십시오. 동일한 사용자에게 두 가지 방법을 모두 사용하지 마십시오.
조직 전체의 역할 표준화
프로젝트와 제품 전반에 적용되는 소규모 핵심 재사용 가능한 역할 집합을 정의합니다. 이를 통해 공유 정신 모델을 생성하고 관리 부담을 줄일 수 있습니다. 역할, 용도 및 권한 관리에 대한 예제를 아래 표에서 확인하십시오.
| 역할 | 대상 | 권한 관리 요약 |
|---|---|---|
| 뷰어 | 경영진, 이해 관계자 | 할당된 프로젝트 첫 사용 후 모든 Amplitude 제품에 대한 읽기 전용 액세스 권한 |
| 분석가 | PM, 분석가 | 차트와 대시보드만 구축 및 공유할 수 있습니다(데이터 모델 또는 실험 편집 불가능) |
| 데이터 거버너 | 데이터 관리자, 관리자 | 제품 전반에 걸쳐 이벤트 택소노미, 추적 계획 및 명명 규칙 관리 |
| 엔지니어 | 실험 소유자, 기능 개발자 | 실험 내에서 기능 플래그, 실험 설정 및 검증 관리 |
| 그로쓰 마케팅 담당자 | 생애주기 분석 및 활성화 팀 | 가이드 및 설문조사, CDP 대상자, 코호트 데이터 동기화 관리 |
단순성 유지
대부분의 조직은 5~7가지 역할을 통해 성공을 거두고 있습니다. 사용자 지정 역할은 거버넌스 또는 컴플라이언스에 필요한 경우에만 추가하십시오.
디자인 그룹
그룹은 Amplitude의 RBAC 시스템에서 확장 가능한 액세스의 기초입니다. Amplitude는 다음을 고려하여 기능과 범위를 하나의 논리적 구조로 결합하는 그룹을 권장합니다.
- 조직의 사용자가 Amplitude를 사용하는 방법.
- 해당 사용자가 액세스해야 하는 프로젝트입니다.
그룹을 워크플로우 및 프로젝트 범위 모두에 고정시킵니다.
그룹을 계획할 때 다음을 포착하는 그룹을 설계해야 합니다.
- 조직의 팀이 Amplitude를 사용하는 방법.
- 각 팀이 액세스해야 하는 프로젝트입니다.
팀의 기능이나 사용 사례와 팀이 업무를 수행하는 데 필요한 데이터 또는 제품 컨텍스트를 모두 고려하십시오.
각 그룹이 그룹 구성원이 하는 일과 그 일을 하는 위치를 설명하도록 하십시오.
그룹을 프로젝트 범위와 목적에 맞게 유지
잘 설계된 그룹은 명확한 기능, 일련의 프로젝트 및 일관된 역할을 제공합니다.
이를 위해서는 다음과 같이 하십시오.
- 각 그룹을 필요한 특정 프로젝트에 할당하십시오. 전체 작업 공간에 대한 액세스 권한을 부여하지 마십시오.
- 팀이 여러 프로젝트를 함께 작업하는 경우 해당 프로젝트를 동일한 그룹 첫 사용 후 할당하십시오.
- 액세스를 명확하고 감사 가능하게 유지하려면 그룹을 겹치거나 중첩하지 마십시오.
명확하고 일관된 이름 지정 적용
역할과 프로젝트 범위를 반영하는 예측 가능하고 읽기 쉬운 이름 지정 형식을 사용하십시오.
Function / Use Case - Role - Projects
다음 표에는 이 형식을 사용하는 그룹 이름 목록이 나와 있습니다.
| 그룹 | 사용자 |
|---|---|
| 프로덕트 분석 - 분석가(웹 앱 + iOS 앱) | 웹과 모바일 모두를 위한 차트와 대시보드를 만드는 분석가. |
| 실험 소유자 - 엔지니어(Android 앱) | Android 프로젝트에서 기능 플래그를 만들고 실험하는 엔지니어입니다. |
| 마케팅 운영 – 그로쓰 마케팅 담당자(웹 앱) | 웹 앱을 위한 가이드, 설문조사 및 코호트 데이터 동기화를 관리하는 마케팅 담당자입니다. |
| 데이터 거버넌스 위원회 - 데이터 거버넌스 담당자(모든 프로젝트) | 택소노미 및 추적 계획을 유지관리하는 데이터 관리자입니다. |
일관된 이름 지정을 통해 그룹에 속한 사람과 해당 사람이 액세스할 수 있는 콘텐츠와 기능을 명확하게 알 수 있습니다.
멤버십을 관리하기 쉬운 상태로 유지
그룹을 액세스 청사진이라고 생각하십시오. 각각은 명확한 목적, 소유권 및 생애주기 분석 관리를 갖추어야 합니다.
- 그룹 구성원을 10명에서 50명 대상 구간으로 유지하십시오.
- 프로젝트 역할이나 책임이 서로 다르면 그룹을 분리하십시오. 예를 들어
Experimentation - Engineer - Android App또는Experimentation - Engineer - iOS App. All Analysts또는Marketing Team와 같은 포괄적인 그룹은 피하십시오. 포괄적인 그룹은 혼란을 야기하고 Amplitude 환경의 일부를 과도하게 노출시킬 수 있습니다.
이 내용이 도움이 되었나요?