제한 뷰 기반 객체의 접근 제어
제한 뷰(Restricted view, RV)는 데이터셋의 특정 행만 보도록 정책을 적용합니다. 객체 유형(Object type)의 기반 데이터소스로 선택하면 전체 데이터셋 권한보다 세밀하게 객체별 접근을 구성할 수 있습니다.
입력 선택과 저장소별 차이
Ontology Manager에서 해당 제한 뷰를 Backing datasource로 선택합니다. 행을 제한하려는 구성이면 제한 뷰 대신 원래 데이터셋을 연결하지 않아야 합니다.
일반 데이터셋 기반 유형의 객체를 보려면 데이터셋에도 조회 권한이 필요합니다. 제한 뷰 경로에는 저장소별 차이가 있습니다.
| 저장소 | 제한 뷰 기반 객체의 조회 조건 |
|---|---|
| OSv1, 구형 경로 | 객체 유형을 볼 수 있어야 하고 제한 뷰의 보안 표지와 해당 행의 읽기 정책을 충족해야 합니다. 제한 뷰 리소스 자체를 볼 권한이 반드시 필요한 것은 아닙니다. |
| OSv2 | 객체 유형과 제한 뷰를 조회할 수 있어야 하며 해당 데이터 접근 조건도 충족해야 합니다. |
액션이 객체의 가시성을 바꾸는 경우
정책에서 사용하는 속성을 액션으로 바꾸면 객체의 접근 범위도 달라집니다. 액션은 원래 제한 뷰의 행을 수정하지 않으므로, 원천 행을 볼 수 있는 사람과 편집된 객체를 볼 수 있는 사람이 달라질 수 있습니다.
가상의 티켓이 다음과 같고 Assignee에 해당하는 그룹의 멤버만 읽는다고 가정합니다. 표의 그룹명은 설명용 표시 이름이며, 실제 정책의 그룹 참조에는 해당 그룹의 고유 ID를 사용합니다.
| Ticket ID | Title | Assignee의 그룹 |
|---|---|---|
| 101 | Ticket One | palantir-support |
액션으로 담당 그룹을 customer-support로 바꾸면 다음과 같습니다.
palantir-support에만 속한 사용자는 편집된 온톨로지 객체를 볼 수 없지만, 변경되지 않은 제한 뷰의 원천 행은 계속 볼 수 있습니다.customer-support에만 속한 사용자는 온톨로지 객체를 볼 수 있게 되지만, 원래 제한 뷰의 해당 행은 볼 수 없습니다.
원천 접근과 온톨로지 편집 상태의 정책 판단을 같은 값으로 간주하지 않아야 합니다.
구형 OSv1의 세부 편집 정책
Datasources의 Granular Policies에서 직접 편집 권한을 구성하는 경로는 OSv1이고 Only allow edits via actions를 선택하지 않은 유형에만 적용됩니다. 나머지 유형의 편집 권한은 액션으로 제어합니다.
이 구형 구성에는 다음 정책이 있습니다.
| 정책 | 적용 대상 |
|---|---|
Read | 제한 뷰의 속성을 읽을 수 있는 행을 결정합니다. 예를 들어 사용자 region과 행의 region을 비교합니다. |
Edit property | 쓰기 반영을 허용한 속성 중 세부 권한 정책에서 사용하지 않는 속성을 수정할 수 있는 사용자를 정합니다. name 같은 속성이 예입니다. |
Edit policy property | 세부 권한 정책이 사용하는 속성 자체를 수정할 수 있는 사용자를 정합니다. 접근을 결정하는 region 같은 속성이 예입니다. |
OSv1에서 등록 후 조회 정책을 바꿨다면 Datasources의 Phonograph 구역에서 Update를 선택하여 등록을 갱신해야 합니다. 갱신하지 않으면 최신 데이터를 과거 정책으로 제공할 수 있습니다. OSv2는 정책 전파를 기본으로 자동 처리하지만, 새 정책이 읽기에 반영되려면 관련 파이프라인 재빌드가 필요합니다.