이 권장사항에는 Looker에 익숙한 교차 기능 팀에서 공유한 권장사항이 반영되어 있습니다. 이 유용한 정보는 Looker 고객과 함께한 구현부터 장기적 성공에 이르는 수년간의 경험을 통해 얻은 것입니다. 권장사항은 대부분의 사용자 및 상황에 맞게 작성되지만 구현할 때는 항상 신중하게 판단하시기 바랍니다.
이 페이지에서는 Looker 인스턴스의 관리자에게 콘텐츠 액세스 제어의 설정 예시를 제공합니다. 구현 프로세스를 살펴보고 새 프로젝트부터 시작하여 모델, 모델 세트, 권한 세트, 그룹, 역할, 사용자 속성을 계속 살펴봅니다.
먼저 이 맥락에서 기본 Looker 기능을 이해하기 위한 비유는 다음과 같습니다.
프로젝트는 집과 같습니다.모델은 특정 콘텐츠로 채워진 집의 방입니다.
모델 세트는 방 그룹 또는 단일 방(침실, 주방)입니다.
권한 세트는 사람이 방에서 할 수 있는 작업(예: 식사, 놀이, 수면)을 지정하는 활동 체크리스트입니다.
그룹은 공유 특성(성인, 아동, 게스트)과 사용자를 통합하는 방법입니다.
역할은 다양한 방 세트에서 사용자 그룹에게 활동 체크리스트를 부여하는 방법입니다.
사용자 속성은 집의 특수 항목을 여는 키입니다(찻주전자, 전동 공구).
시나리오
다음은 재무, 영업, 제품 팀이 있는 스타트업의 예시입니다. CEO는 유일한 관리자이며 각 팀의 부사장이 모든 팀의 콘텐츠에 액세스할 수 있어야 한다는 점을 제외하고 각 팀이 각자와 관련된 콘텐츠만 보기를 원합니다. 그녀는 표준 직원, 관리자, 부사장을 위한 다양한 기능 액세스를 원합니다.
- 표준 직원은 자신의 모델에서 데이터를 보고 탐색할 수 있어야 합니다.
- 관리자는 표준 액세스 권한이 있어야 하며 콘텐츠를 다운로드하고 예약할 수 있습니다.
- 부사장은 CEO만 사용할 수 있는 일부 권한을 제외한 거의 모든 권한을 가져야 합니다.
CEO는 영업 담당자가 자신의 활동에 대한 데이터를 볼 수 있지만 다른 영업 담당자의 개별 판매 수치를 볼 수 없도록 하려고 합니다. 하지만 영업 관리자는 모든 영업 담당자의 수치를 볼 수 있어야 합니다. 마지막으로 그녀가 해당 모델을 사용하는 표준 직원에게는 마스킹되기를 원하는 민감한 정보가 포함된 일부 금융 분야가 있습니다.
조직 차트는 다음과 같습니다.
위의 차트는 예시의 스타트업에 대한 다음 조직 구조를 보여줍니다.
- CEO
- 재무 부문 부사장
- 재무 관리자
- 회계사
- 영업 부문 부사장
- 서부 영업 관리자
- 서부 영업 담당
- 동부 영업 관리자
- 동부 영업 담당자
- 제품 부문 부사장
- 제품 관리자
- 엔지니어
원하는 액세스 제어를 구현하려면 다음 단계를 수행해야 합니다.
- 프로젝트 만들기: 프로젝트는 데이터베이스 연결과 데이터 모델 간의 구조적 링크입니다.
- 모델 추가: 어떤 사용자에게 어떤 데이터를 표시할지 결정합니다.
- 모델 세트 만들기: 관련 모델을 함께 그룹화합니다.
- 권한 세트 만들기: 모델 세트 내에서 사용자가 수행할 수 있는 작업을 명시적으로 정의합니다.
- 그룹 만들기: 유사한 사용자를 함께 버킷합니다.
- 역할 만들기: 모델 세트, 권한 세트, 그룹 간의 연결을 만듭니다.
- 콘텐츠 액세스 수정: 사용자가 폴더를 통해 볼 수 있는 대시보드 및 Looks를 관리합니다.
- 데이터 필터 추가: 특정 사용자가 모델 내에서 액세스할 수 있는 데이터를 추가로 필터링합니다.
1. 프로젝트 만들기
가장 먼저 필요한 것은 하나 이상의 모델을 위한 컨테이너인 프로젝트입니다. 프로젝트가 이미 설정되어 있으면 이 단계를 건너뛸 수 있습니다. 그렇지 않으면 새 프로젝트를 만들기 위해 Looker의 개발 섹션에서 프로젝트를 선택하고 새 LookML 프로젝트를 선택하여 LookML 프로젝트 페이지로 이동할 수 있습니다. 새 프로젝트 만들기에 대한 자세한 안내는 새 LookML 프로젝트 만들기 문서 페이지를 참조하세요.
새 프로젝트 페이지에서 다음 설정으로 프로젝트를 만듭니다.
- 이름 섹션에서 프로젝트 이름을 지정합니다.
- 시작 지점 섹션에서 데이터베이스 스키마에서 모델 생성을 선택합니다.
- 연결 드롭다운 메뉴에서 데이터베이스 연결 이름을 선택합니다.
- 이 예시에서는 빌드 보기 선택 섹션에서 모든 테이블 옵션을 선택하면 LookML 생성기가 데이터베이스의 각 테이블에 대한 뷰 파일을 만듭니다.
새 프로젝트에 원하는 설정이 구성되면 프로젝트 만들기를 선택합니다.
프로젝트를 만들면 프로젝트의 자동 생성된 LookML 모델이 표시됩니다. 이 시점에서 Git 구성 버튼을 사용하여 프로젝트의 버전 제어를 설정해야 합니다. 버전 제어 설정에 대한 자세한 안내는 Git 연결 설정 및 테스트 문서 페이지를 참조합니다.
2. 모델 추가
데이터 모델은 데이터베이스로 맞춤설정할 수 있는 포털과 같습니다. 각 모델은 사용자에게 다른 데이터를 노출할 수 있습니다. 이 예에서 영업 담당자는 엔지니어와 다른 데이터가 필요하므로 데이터베이스의 적절한 정보를 각 종류의 사용자에게 노출하기 위해 별도의 모델을 추가할 것입니다.
LookML 프로젝트에서 원하는 각 모델(finance
, sales
, product
)의 이름으로 새 LookML 모델 파일을 추가합니다. 각 모델 파일에 하나 이상의 Explore를 정의해야 합니다. 그러면 모델 세트를 만들 때 모델을 선택할 수 있습니다(그렇지 않으면 선택 항목에 표시되지 않습니다). 모델 파일에서 explore
매개변수를 사용하는 방법에 대한 자세한 내용은 모델 및 뷰 파일 이해 문서 페이지를 참조합니다.
모델을 성공적으로 추가한 후에도 모델을 구성해야 합니다. 모델을 구성하기 위해 개발 섹션의 프로젝트 페이지로 돌아가면 각 모델 이름과 함께 인라인으로 '사용하려면 구성 필요'라는 빨간색 텍스트가 표시됩니다.
각 모델 옆에 있는 구성을 선택합니다. 이 모델에서 사용할 수 있는 연결과 함께 프로젝트 이름이 올바른지 확인하고 저장합니다.
모든 모델이 올바르게 구성되면 이전에 발생한 빨간색 구성 문제 메시지가 더 이상 표시되지 않습니다.
Looker에서 사용자에게 한 모델에 대한 see_lookml
또는 develop
권한을 부여하면 해당 프로젝트에 있는 모든 모델에 대한 권한이 부여된다는 점을 기억해야 합니다. 따라서 LookML을 보거나 개발하기 위해 권한을 파티션하려면 별도의 프로젝트를 만들어야 합니다. 그렇지 않으면 새 모델을 만들어야 합니다. 모델 권한은 특정 사용자만 특정 데이터를 쿼리할 수 있도록 보장하기에 충분합니다.
권한에 대한 자세한 내용은 역할에 대한 문서를 참조합니다.
3. 모델 세트 만들기
이제 각 부서의 데이터 모델이 구성되었으므로, 각 부서의 해당 모델을 빌드하는 모델 세트에 추가합니다. 새 모델 세트를 만들려면 관리자 패널의 역할 페이지로 이동하여 새 모델 세트를 선택합니다. 새 모델 세트를 만드는 방법에 대한 자세한 내용은 역할 문서 페이지를 참조하세요.
새 모델 세트가 생성되면 다음 예시 스크린샷에 표시된 것처럼 역할 페이지의 모델 세트 섹션에 표시됩니다.
4. 권한 세트 만들기
다음으로 방금 만든 모델 세트를 사용하여 권한 세트를 만듭니다. 시나리오를 설정할 때 언급했듯이 조직 차트의 4가지 계층 수준에 해당하는 4단계 권한이 필요하며 상위 계층에는 아래 계층의 권한이 포함되어야 합니다. 이 시나리오에서는 다음과 같이 권한 세트를 식별합니다.
- CEO는 관리자 권한 세트를 가집니다.
- 부사장은 제한된 관리자 권한 세트를 가집니다.
- 관리자는 다운로드 및 공유 권한 세트를 가집니다.
- 표준 직원은 보기 및 탐색 권한 세트를 가집니다.
새 권한 세트를 만들려면 관리자 패널에서 역할 페이지로 이동하여 새 권한 세트를 선택합니다. 각 권한 등급에 대해 적절한 권한을 선택할 것입니다. 일반적으로 권한 세트는 최대한 겹치지 않아야 하며 각 세트는 이 권한 세트가 있는 사용자에게 부여하려는 특정 권한만 추가합니다. 이는 일부 사용자에게 여러 권한 세트를 부여할 것이며, 각 권한 세트가 무엇을 허용하는지 정확히 알고 싶어하기 때문입니다. 하지만 트리 구조로 인해 일부 중복이 필요한 경우가 많습니다.
이 예시에서는 사용자가 콘텐츠를 보고, 질문하고, 유용한 타일을 저장할 수 있도록 보기 및 탐색 권한 세트를 설정합니다. 따라서 콘텐츠 보기와 관련된 권한(예: see_looks
및 see_user_dashboards
), explore
권한, save_content
권한을 부여합니다. 주목할 만한 예외로는 개발자 용도로만 필요한 see_lookml
와 SQL을 이해하고 데이터베이스 구조를 보도록 신뢰할 수 있는 사용자를 위해 예약된 see_sql
가 있습니다. 이러한 모든 권한은 엄격하게 access_data
브랜치 아래에 있습니다. 트리 하단에서 see
권한을 부여하지 않습니다. 이러한 권한이 관리 권한이기 때문입니다.
다운로드 및 공유 권한 세트의 경우 다운로드, 예약, 공유, 공개 Look 생성(Looker가 아닌 사용자에게 Look 공유 허용) 및 see_schedules
와 관련된 권한을 추가합니다(일정을 생성할 수 있으므로, 관리 패널에서도 볼 수 있다는 것이 논리적입니다).
보기 및 탐색 및 다운로드 및 공유 권한 세트를 모두 구성할 때 선택된 유일한 필드는 access_data
브랜치에 추가된 하위 권한을 선택하는 데 필요한 상위 권한입니다. 따라서 다운로드 및 공유 권한 세트가 있는 사용자는 보기 및 탐색 권한 세트도 갖게 되므로 다운로드 및 공유 권한 세트에 see_lookml_dashboards
,see_user_dashboards
및 explore
와 같은 권한을 포함할 필요가 없습니다. 이러한 권한에는 다운로드 및 공유 권한 세트에 필요한 하위 권한이 포함되어 있지 않기 때문입니다.
마지막으로 제한된 관리자 권한 세트의 경우 CEO 자신에 대해서만 원하는 manage_models
및 sudo
권한을 제외하고 대부분의 관리 권한을 트리 하단에 추가합니다. 이런 모습입니다.
모든 작업이 완료되면 권한 세트에 다음 권한이 포함됩니다.
- 관리자: 예시 회사의 CEO를 위해 예약된 관리자 권한 세트에는 모든 권한이 포함됩니다.
- 제한된 관리자: 제한된 관리자 권한 세트에는
create_prefetches
,login_special_email
,manage_homepage
,manage_spaces
,see_alerts
,see_datagroups
,see_logs
,see_pdts
,see_queries
,see_users
및update_datagroups
권한이 포함됩니다. - 다운로드 및 공유: 다운로드 및 공유 권한 세트에는
access_data
,create_public_looks
,download_with_limit
,download_without_limit
,save_content
,schedule_external_look_emails
,schedule_look_emails
,see_looks
,see_schedules
,send_outgoing_webhook
,send_to_s3
및send_to_sftp
권한이 포함됩니다. - 보기 및 탐색: 보기 및 탐색 권한 세트에는
access_data
,create_table_calculations
,explore
,save_content
,see_drill_overlay
,see_lookml_dashboards
,see_looks
및see_user_dashboards
권한이 포함됩니다.
역할 관리 페이지의 권한 세트 섹션으로 이동하여 기존 권한 세트에 속하는 권한을 볼 수 있습니다.
5. 그룹 만들기
다음 단계는 그룹을 만들고 사용자를 버킷하는 것입니다. 각 부서에서 일반 직원과 관리자를 위한 그룹을 만들게 되는데, 이는 이후에 만드는 여러 역할과 일치하기 때문입니다. 부사장은 자체 그룹에 속하며 CEO는 그룹이 필요하지 않습니다. 완료되면 그룹 페이지에 Looker에서 자동으로 생성되는 다음 그룹과 해당 그룹 ID가 나열됩니다. 예를 들면 다음과 같습니다.
ID | 이름 |
---|---|
1 | 모든 사용자 |
3 | 재무 |
4 | 영업 |
5 | 제품 |
7 | 영업 관리자 |
8 | 제품 관리자 |
9 | 재무 관리자 |
10 | 부사장 |
그룹이 생성되면 이러한 그룹에 사용자를 추가해야 합니다. 사용자를 그룹에 추가하는 방법은 그룹 문서 페이지를 참조합니다.
관리자가 만든 그룹에 사용자를 추가할 때는 구조화된 권한이 있으므로 상위 계층이 하위 계층 그룹에 포함될 수 있습니다. 예를 들어 재무 그룹의 부사장이 필요하지만 제품 그룹의 영업 관리자는 원하지 않습니다. 이 접근 방식을 사용하는 효율적인 방법은 사용자를 상위 계층(예: 부사장)에 추가하여 하위 계층에 그룹으로 추가할 수 있도록 하는 것입니다.
6. 역할 생성
이제 모델 세트, 권한 세트, 그룹이 준비되었으므로 역할을 사용하여 모두 합칠 수 있습니다. 모든 역할에는 단일 권한 세트 및 단일 모델 세트가 포함되며 하나 이상의 그룹을 포함할 수 있습니다. 역할에는 모델 세트가 포함되어야 하므로 표준 직원과 각 부서의 관리자 역할을 다시 만듭니다.
- 표준 역할: 표준 역할에는 해당 모델 세트와 함께 보기 및 탐색 권한 세트가 포함됩니다. 해당 부서의 표준 및 관리자 그룹과 부사장에게 표준 역할을 할당합니다. 예를 들어 표준 재무 역할을 재무 및 재무 관리자 그룹과 재무 부문 부사장에 할당합니다.
- 관리자 역할:관리자 역할에는 해당 모델 세트와 함께 다운로드 및 공유 권한 세트가 있습니다. 이러한 역할은 해당 부서의 관리자 그룹 및 부서의 부사장에게 할당되어야 합니다.
- 관리자 역할:관리자 역할에는 해당 모델 세트와 함께 다운로드 및 공유 권한 세트가 있습니다. 이러한 역할은 해당 부서의 관리자 그룹 및 부서의 부사장에게 할당되어야 합니다.
- 부사장 역할: 부사장 역할에는 제한된 관리자 권한 세트와 전체 모델 세트가 있습니다. 이 역할은 부사장 그룹에 할당됩니다.
7. 콘텐츠 액세스 수정
다음 단계는 각 그룹이 자체 콘텐츠에만 액세스할 수 있도록 폴더 액세스 권한을 구성하는 것입니다. 다음은 예시 인스턴스의 폴더 레이아웃으로, 관리 패널의 콘텐츠 액세스 페이지로 이동하여 확인할 수 있습니다.
폴더에 대한 액세스는 계층적 상속 규칙을 따릅니다. 작동 방식에 대한 자세한 내용은 액세스 수준 및 액세스 제어 및 권한 관리 문서를 참조합니다.
폴더 액세스 규칙에 따라 공유 폴더의 모든 사용자에게 보기 액세스 권한을 부여하려고 합니다. 각 그룹에는 그룹이 액세스할 수 있는 폴더 위의 트리에 있는 상위 폴더에 대한 보기 액세스 권한이 부여됩니다. 그러면 트리를 순회하는 동안 그룹에 폴더를 표시하지 않으려는 경우 액세스 권한을 부여할 때 해당 그룹을 포함하지 않습니다.
해당 폴더를 볼 수 있는 사용자를 제어하려는 폴더에 있는 그룹에 액세스 관리, 수정 액세스 수준을 부여할 수 있습니다. 이 예시에서는 CEO와 부사장에게만 이러한 권한을 부여하려고 합니다. 그 외 모든 사용자에게는 필요한 폴더에 대한 보기 액세스 권한만 부여됩니다.
8. 사용자 속성으로 데이터 액세스 제한 추가
이 섹션에서는 특정 사용자가 액세스 권한이 있는 모델에서 특정 행 또는 열에 액세스하는 것을 방지하는 방법을 보여줍니다. CEO는 영업 담당자가 자신의 개별 활동에 대한 데이터는 볼 수 있지만 다른 사람의 활동에 대해서는 볼 수 없도록 하고자 한다는 점을 기억해 주십시오. 하지만 영업 관리자는 모든 영업 담당자의 수치를 볼 수 있어야 합니다. 이를 위해 사용자 속성과 sql_always_where
매개변수를 활용합니다.
사용자 속성 만들기
먼저 사용자에게 숨겨져 있는 access_level
이라는 새 사용자 속성을 만듭니다. 이렇게 하면 여러 그룹의 액세스 등급을 정의할 수 있습니다. 사용자 속성을 만들 때 다음 값을 설정합니다.
- 이름:
access_level
- 라벨: 액세스 수준
- 데이터 유형: 문자열
- 사용자 액세스: 수정
- 값 숨기기: 아니요
이 예시에서는 기본값 설정 상자를 선택 해제 상태로 둡니다.
필드를 만드는 동안 기본, 프리미엄, 전체의 세 가지 액세스 수준을 구성합니다. 이러한 수준을 각각 표준, 관리자, 부사장 그룹에 할당합니다. 이 작업은 동일한 섹션의 그룹 값 탭에서 수행됩니다. 자세한 내용은 사용자 속성 문서의 사용자 그룹에 값 할당 섹션을 참조합니다.
이러한 규칙의 순서가 중요하므로 낮은 액세스 값을 맨 아래 쪽으로 재정의하기 위해 가장 높은 액세스 값을 목록 상단에 배치합니다. 이 동작은 사용자 속성 문서 페이지에 자세히 설명되어 있습니다.
사용자 속성으로 행 데이터 필터링
모든 판매 정보가 포함된 Explore가 이미 구성되어 있다고 가정해 보겠습니다. Explore 분석을 쿼리하는 사용자의 액세스 수준을 확인합니다. 액세스 수준이 기본(모든 표준 영업 담당자에게 제공)인 경우 항상 사용자 이름으로 Explore를 필터링하므로 각 영업 담당자의 자체 행만 액세스할 수 있습니다. 액세스 수준이 프리미엄 또는 전체인 경우 쿼리가 필터링되지 않습니다. 기본적으로 Looker 사용자 이름인 이름이라는 사용자 속성이 있습니다. Explore의 LookML은 다음과 같습니다.
explore: sales_info { sql_always_where: {% if {{_user_attributes['access_level']}} == "Basic" %} ${sales_info.name} = "{{_user_attributes['name']}}" % endif % ;; }
사용자 속성으로 열 데이터 필터링
마지막으로 재무 모델에는 일부 사용자에게서 숨기고자 하는 PII(개인 식별 정보) 열이 있습니다. 이를 위해 우리가 만든 사용자 속성과 함께 사용자 속성 문서 페이지의 Looker에서 데이터베이스 수준 권한을 적용하기 위한 지침을 사용하여 전체 액세스 수준이 있는 사용자에게만 PII 필드를 볼 수 있는 기능을 부여할 수 있습니다.
이제 끝입니다. 콘텐츠 및 데이터 액세스 제어 설정을 완료했으므로 모든 사용자가 자유롭게 Looker를 탐색할 수 있습니다. 이렇게 하면 사용자는 허가한 콘텐츠만 볼 수 있습니다.