Restricted View

마킹과 역할은 강력한 접근 제어를 제공하지만, 일부 상황에서는 더 세분화된 권한이 필요합니다. 예를 들어, 특정 유형의 모든 오브젝트에 대한 접근 권한을 부여하는 것이 불충분하거나 부적절할 수 있습니다. 회사가 영업 사원이 지정된 지점의 고객만 볼 수 있도록 제한하는 경우처럼, 일부 오브젝트 유형은 다른 사용자에게 다른 오브젝트를 표시해야 할 수 있습니다. Restricted View는 이러한 추가적인 수준의 접근 제어를 제공합니다.

사용자는 Foundry에서 Restricted View 리소스와 상호작용하며, Restricted View는 세분화된 권한으로 구동됩니다. Restricted View는 사용자가 볼 수 있는 행으로 데이터셋 접근을 제한합니다. Restricted View는 백업 데이터셋 위에 구축되며 변환의 입력으로 사용할 수 없습니다. Restricted View의 정책은 사용자가 볼 수 있는 특정 행을 결정하며, 일반적으로 Restricted View 생성 시 소유자 역할을 가진 사용자에 의해 정의됩니다. 생성 후, Restricted View는 온톨로지의 오브젝트 유형에 대한 백업 데이터 소스로 사용할 수 있습니다. 예를 들어, Restricted View의 한 행이 온톨로지의 한 오브젝트로 표현되는 경우, Restricted View는 사용자에게 어떤 오브젝트를 볼 수 있는지 제어합니다.

Restricted View 정책

정책은 Restricted View의 핵심입니다. Restricted View 정책은 사용자가 볼 수 있는 행을 결정하기 위해 서로 다른 사용자 속성, 열 및/또는 값을 비교하는 규칙 및/또는 논리 연산자의 집합입니다. Restricted View 정책은 유연하며 다음과 같은 다양한 비교 및 용어를 지원할 수 있습니다:

• 사용자 속성: 데이터를 보는 사용자의 속성
• 열 이름: Restricted View 백업 데이터셋의 열
• 특정 값: 문자열, Boolean, 숫자 또는 배열

대부분의 정책은 사용자 속성과 비교되는 최소한 하나의 용어를 포함합니다. 사용자 기반 권한을 위해서는 최소한 하나의 용어가 필요합니다.

사용자, 그룹 또는 그룹을 참조할 때, 정책은 정책 열과 정책 정의 모두에 고유 식별자(UUID)가 필요합니다. 이름 대신 ID를 지정하는 것은 이름 변경 관련 문제를 방지하기 위해 지원되지 않습니다.

사용자 속성

아래는 Restricted View 정책에서 지원되는 사용자 속성 목록입니다:

• 사용자 ID: Foundry가 각 사용자에게 생성하는 고유 ID
• 사용자 이름: 로그인 시 사용자의 ID 제공자가 제공하는 고유 ID
• 그룹 ID: 사용자가 멤버로 있는 모든 그룹의 ID(직접 및 상속)
• 그룹 이름: 사용자가 멤버로 있는 모든 그룹의 이름(직접 및 상속)
• 승인된 그룹 ID: 범위 지정 세션과 관련된 고급 개념입니다. 범위 지정 세션과 함께 Restricted View를 사용할 계획이라면 Palantir 관리자에게 문의하십시오.
• 그룹 마킹 ID: 사용자가 멤버로 있는 모든 그룹의 마킹 ID(주요 및 게스트). 이는 UUID인 마킹 ID이며, ri.multipass..organization.으로 시작하는 그룹 ID가 아닙니다.
• 마킹 ID: 사용자가 볼 수 있는 모든 마킹의 ID
• 사용자 정의 속성: 제어 패널에서 ID 제공자가 구성한 사용자 정의 속성

Restricted View 정책 설계

다른 사용자에게 다른 오브젝트를 표시하는 오브젝트 유형을 구축하려고 한다고 가정해보겠습니다. 첫 번째 단계는 Restricted View 정책을 설계하는 것입니다. 다음 질문을 고려하십시오:

• 온톨로지의 데이터에 대한 접근을 어떻게 제한하고 싶습니까?
• 정책에서 사용할 수 있는 사용자 속성은 무엇입니까?
• 정책이 의존할 수 있는 데이터의 열은 무엇입니까?
• Restricted View를 생성할 때 마킹이 해제될 수 있는 파이프라인을 통해 전파되는 마킹은 무엇입니까?
• 새로운 사용자에게 오브젝트 권한을 어떻게 부여할 것입니까?

아래 예시에서는 Restricted View 정책에 적용할 수 있는 두 가지 규칙이 포함되어 있습니다:

권장 사항

Restricted View를 설계할 때 다음 지침을 권장합니다:

• 간단하게 유지: Restricted View를 생성하기 전에 적용하려는 정책을 적어보세요. 해당 정책에 필요한 최소 조건을 결정하세요. 정책이 복잡할수록 관리하고 검증하기 어려워집니다.
• 정책 열이 null이 아닌지 확인: 정책 열에 null 값이 있는 행은 모든 사용자에게 접근할 수 없습니다. 정책 열에 null 값이 있으면 해당 테이블의 Phonograph 동기화가 실패합니다.
• 파이프라인 활용: 현재 데이터 형태나 필드와 잘 맞지 않는 정책의 복잡성을 줄이기 위해, 정책 작성이 쉬워질 수 있는 열을 계산하기 위해 파이프라인을 사용하세요. Restricted View 정책보다는 파이프라인에서 복잡성을 처리하세요.
• 전용 정책 열 사용 고려: 정책에서 참조하는 백업 데이터셋의 열에 대한 변경은 정책 가정을 깨뜨릴 수 있습니다. 이러한 위험으로부터 정책을 보호하기 위해, 정책을 결정하는 논리를 분리하고 정책이 참조할 전용 열(또는 열들)을 만드는 것을 고려하세요.
• 속성 사용: 속성 기반 정책은 종종 가장 간단한 옵션일 수 있습니다. 속성은 SSO에서 가져오거나 사용자 관리자를 통해 게시할 수 있습니다.
• 마킹 사용: 정책의 백업 데이터셋에 마킹을 적용하여 보호를 보장하고 마킹에 접근 권한이 있는 사용자에게만 표시되도록 하세요. Restricted View는 이미 사용자가 볼 수 있는 행을 제어하므로 Restricted View에서 마킹 상속을 중지할 수 있습니다. 민감한 데이터가 소스에서 마킹되었고 마킹이 올바르게 전파되었다면, Restricted View를 생성할 때 새로운 마킹이 필요하지 않을 것입니다.

Restricted View 정책의 설계를 결정한 후, 이를 지원하기 위해 필요한 파이프라인 및 프로젝트 변경을 수행하세요. Restricted View 정책과 파이프라인이 마련되면 Restricted View를 생성할 수 있습니다.

Restricted View 생성

소유자 역할이나 필요한 권한을 가진 사용자는 데이터셋의 하류에서 마우스 오른쪽 버튼 클릭 컨텍스트 액션을 통해 Restricted View를 생성할 수 있습니다:

Restricted View 생성 대화 상자는 다음 단계로 구성됩니다:

1. 저장하기: Restricted View가 파일 시스템에 위치할 이름과 위치를 선택하세요.
2. 세분화된 정책 작성: Restricted View나 오브젝트에 접근할 때 사용자가 볼 수 있는 행이나 오브젝트를 결정할 정책 문을 정의하세요.
3. 접근 요구 사항 검토: 상류 데이터셋과 하류 Restricted View 모두에 대한 기존 파일 및 트랜잭션 수준 마킹을 검토하세요. 적절한 권한이 있는 경우, Restricted View에서 마킹을 해제(제거)할 수 있습니다.
4. 요약: Restricted View의 생성 및 초기 빌드 전에 선택 사항을 검토하세요.

저장하기

Restricted View의 이름을 지정하고 저장 위치를 선택하세요. 일반적으로, Restricted View를 입력 데이터셋과 다른 프로젝트에 저장하여 Restricted View를 소비하는 사용자가 하류 프로젝트에서 보기 권한을 가질 수 있도록 합니다. 또는 입력 데이터셋과 동일한 프로젝트에 Restricted View를 저장하고 마킹을 사용하여 입력 데이터셋을 보호할 수 있습니다.

세분화된 정책 작성

사용자 속성, 열 이름, 특정 값을 사용하여 규칙 기반 정책을 생성할 수 있습니다. 자세한 내용은 Restricted View 정책을 확인하세요.

접근 요구 사항 검토

Restricted View를 통해서만 민감한 데이터에 접근해야 하는 사용자는 상류 데이터셋에 접근할 수 없어야 합니다. 이 단계에서는 생성 중인 데이터셋과 Restricted View 모두에 대한 접근 요구 사항을 검토할 수 있습니다. 적절한 마킹 권한이 있는 경우, Restricted View에서 상속된 마킹을 제거하고/또는 상류 데이터셋에 마킹을 적용할 수 있습니다.

요약

요약은 데이터셋과 Restricted View 모두에 대한 최종 제안된 접근 제어를 제시합니다. 요약 결과에 만족하면 생성을 클릭하여 Restricted View의 초기 빌드를 시작하세요.

Restricted View가 생성되면, 입력 데이터셋이 업데이트될 때마다 자동으로 다시 빌드되는 빌드 일정이 백그라운드에서 생성됩니다.

오브젝트 유형을 백업하기 위해 Restricted View를 사용하는 방법에 대한 관리 문서를 검토하세요.

마킹 기반 Restricted View 생성

마킹 열이 있는 데이터셋을 기반으로 Restricted View를 생성할 수 있습니다. 각 행은 필요한 마킹 접근 권한이 있는 사용자에게만 표시됩니다. 예를 들어, 아래 Restricted View에서는 사용자가 첫 번째 행을 보기 위해 A1과 A2가 모두 필요하며, 두 번째 행을 보기 위해 B1이 필요합니다.

마킹 기반 Restricted View를 생성하려면 다음 단계를 따르세요:

1. Restricted View로 보안될 하나 이상의 마킹 열이 포함된 데이터셋을 준비하세요. 각 셀에는 STRING 마킹 ID 또는 STRING ARRAY의 마킹 ID가 포함되어야 합니다. 상류 데이터셋의 예상 형식에 대해 자세히 알아보세요.
2. 데이터셋 미리보기 인터페이스의 열 탭으로 이동하여 각 마킹 열을 주석 처리하고, 열을 선택한 다음 "타입 클래스 추가"를 클릭하고 marking_type.mandatory를 입력하세요. 이 단계는 세분화된 권한이 작동하는 데 필요하지 않지만, Foundry의 일부 인터페이스는 이를 힌트로 사용하여 열을 더 적절하게 렌더링합니다.

3. 데이터셋에서 Restricted View를 생성하세요. 정책 규칙의 왼쪽은 "사용자의 마킹"이어야 합니다. 오른쪽에서는 "열"을 선택하고 마킹 열을 선택하세요. 여러 열이 있는 경우, 각 열에 대해 규칙을 생성하고 원하는 대로 AND 또는 OR 규칙으로 결합하세요.

상류 데이터셋의 예상 형식

Restricted View가 생성되는 데이터셋에는 마킹 ID 열이 포함되어야 합니다.

• 이러한 ID는 전역적으로 고유한 식별자(UUID)입니다.
• 열은 STRING 타입이어야 하며(각 셀에 단일 마킹 ID가 있음) 또는 STRING ARRAY 타입이어야 하며(마킹 ID 목록을 포함함).
• 마킹 ID 열이 하나 이상 있을 수 있습니다.
• 동일한 열에 마킹과 그룹을 혼합할 수 있습니다.

예를 들어, 다음 데이터셋은 행당 하나의 보안 마킹을 포함합니다:

또 다른 예로, 이 데이터셋은 마킹 목록을 포함합니다. 아래 샘플 CSV는 Foundry에 직접 업로드할 수 있지만, 상세 > 스키마로 이동하여 "type": "STRING"을 "type": "ARRAY, "arraySubtype": { "type": "STRING" }로 수동으로 수정해야 합니다.

Restricted View를 Marketplace 제품에 추가 [베타]

Foundry DevOps를 사용하여 다른 사용자가 설치하고 재사용할 수 있는 Marketplace 제품에 Restricted View를 포함하세요. 첫 번째 제품을 만드는 방법을 확인하세요.

지원되는 기능

string 및 boolean 상수만 지원됩니다. 상수는 필드(열) 또는 "사용자의 그룹" 사용자 속성과만 비교할 수 있습니다. Marketplace는 현재 동일한 필드를 사용하는 여러 필드-상수 비교 조건을 지원하지 않습니다.

제품에 Restricted View 추가

제품에 Restricted View를 추가하려면 먼저 제품을 생성한 다음 아래와 같이 Restricted view 콘텐츠 유형을 선택하세요.

제품에 Restricted View를 추가하면 Restricted View의 정책이 포함되며, 데이터는 포함되지 않습니다.