제한 뷰의 권한과 운영 제한
제한 뷰는 데이터셋과 비슷하게 보이지만, 결과가 정책 정의와 조회 시점의 사용자 특성 및 그룹 소속에 함께 의존합니다. 같은 제한 뷰를 보는 두 사용자가 서로 다른 행과 집계값을 얻을 수 있으므로, 일반 데이터셋과 같은 재현성 가정을 적용하지 않습니다.
생성과 편집 권한
Settings의 Platform Settings 사이드바에서 Roles를 열면 Granular Permissions Administration 작업 권한 묶음을 관리할 수 있습니다. 역할 관리 화면 자체에는 별도 플랫폼 관리 권한이 필요하며, 필요한 관리 접근이 없으면 Palantir 담당자에게 문의합니다.
| 권한 | 필요한 대상과 용도 |
|---|---|
Create restricted view resource | 제한 뷰를 저장할 폴더 또는 프로젝트에 필요합니다. |
Create restricted view for dataset | 제한 뷰의 상류 데이터셋에 필요합니다. |
Edit resource granular policy | 리소스의 세분화된 접근 정책을 편집합니다. |
Read resource granular policy | 리소스의 세분화된 접근 정책을 읽습니다. |
Edit restricted view resource | 제한 뷰의 정책이나 적용할 보안 표지 등 리소스 설정을 편집합니다. |
View restricted view resource | 정책이나 보안 표지 등 제한 뷰의 속성을 봅니다. |
View restricted view transaction | 과거 트랜잭션의 정책과 보안 표지 등 메타데이터를 봅니다. |
제한 뷰를 빌드하려면 입력 데이터셋의 읽기 권한과 출력 제한 뷰의 편집 권한이 필요합니다. Contour 분석에서 제한 뷰를 읽으려면 Read restricted view 권한이 필요합니다. 리소스의 정책 메타데이터를 볼 권한과 실제 행을 읽을 권한은 구분합니다.
객체 유형의 기반 데이터소스로 연결
Object Explorer에서 객체 유형의 특정 객체만 보여 주려면 Ontology Manager에서 그 유형의 기반 데이터소스를 제한 뷰로 지정합니다. 구성과 저장을 수행할 사용자는 다음 조건을 모두 충족해야 합니다.
- 제한 뷰의 입력 데이터셋에 대한
View접근 - 정책을 보거나 설정 및 변경할 수 있는 제한 뷰의
Edit접근 - Ontology Manager에 접근할 수 있는 Ontology 관리자 그룹 소속
데이터셋 기반 객체에 세분화된 정책을 적용해 Object Explorer에서 읽으려는 사용자에게는 데이터셋의 View ontology data source 권한도 필요합니다. 정책이 허용하는 행만 읽을 수 있다는 조건은 계속 적용됩니다.
지원하는 작업
| 작업 | 지원 여부 | 조건과 범위 |
|---|---|---|
| 읽기 | 지원 | 객체를 통해 읽거나 Contour에서 읽습니다. |
| 조회 중 계산 | 지원 | 허용된 행을 대상으로 객체에서는 Quiver나 Functions, 데이터셋에서는 Contour 등의 도구로 계산할 수 있습니다. |
| 쓰기 반영(Writeback) | 지원 | 제한 뷰를 기반으로 한 객체에도 쓰기 반영을 정의할 수 있습니다. 쓰기 대상의 통제가 적용됩니다. |
| 내보내기 | 지원 | Quiver, Contour 등의 애플리케이션에서 허용된 데이터를 내보낼 수 있습니다. 내보내기 권한과 관련 통제도 따릅니다. |
| 배치 처리 | 미지원 | 사용자마다 행 집합이 달라 새 데이터셋을 만드는 일반 배치 파생 작업의 입력으로 사용할 수 없습니다. |
| 변환 결과를 Foundry 데이터셋으로 저장 | 미지원 | 제한 뷰에 수행한 변환을 일반 데이터셋 출력으로 저장하는 경로는 지원하지 않습니다. 이후 트랜잭션에 같은 사용자별 읽기 규약을 재현할 수 없기 때문입니다. |
| Postgres 동기화 | 미지원 | 사용자 특성에 의존하는 행 권한을 유지할 수 없어 제한 뷰를 Postgres로 동기화할 수 없습니다. |
배치 제한에는 일반 변환, Code Workbook 출력과 데이터셋에 쓰는 Pipeline Builder 출력이 포함됩니다. Spark가 제한 뷰의 사용자별 행 권한을 네이티브 데이터셋 트랜잭션의 속성으로 유지하는 것은 아닙니다.
이력과 재현성
트랜잭션 이력에는 정책 정의의 이력을 보관합니다. 그러나 모든 시점의 사용자 특성과 그룹 소속 전체를 트랜잭션 이력에 보관할 수는 없습니다. 따라서 과거 정책 정의만으로 당시 모든 사용자가 어떤 행을 보았는지 완전히 재현할 수 없습니다.
협업자가 같은 정책 문장을 읽을 권한이 없거나 서로 다른 그룹과 특성을 가지면, 같은 분석에서도 결과와 집계가 달라질 수 있습니다. 결과를 공유할 때에는 어떤 사용자 맥락에서 계산했는지와 공유 대상의 접근 범위를 고려합니다.
제한 뷰의 읽기 전용 성격은 정책이 참조하는 스키마와 열을 보존하는 무결성 제약입니다. 이것이 사용자가 읽은 값을 모든 후속 경로에서 다시 쓰거나 내보낼 수 없게 한다는 뜻은 아닙니다. 함수나 액션, 클라이언트 코드에서 읽은 값을 사용하는 경우에는 목적지와 해당 작업의 통제가 적용됩니다.
읽기 정책과 강제적 접근 요건의 전파를 구분하고, 필요한 경우 기반 데이터에 보안 표지나 데이터 분류를 적용합니다. 제한 뷰 생성과 패키징은 제한 뷰 구성, 안전한 정책 변경은 브랜치와 검토 절차에서 다룹니다.