제한 뷰로 사용자별 데이터 행 구분하기

제한 뷰(Restricted view)는 기반 데이터셋 위에서 사용자가 읽을 수 있는 행을 정책으로 구분하는 리소스입니다. 예를 들어 영업 담당자에게 자신이 담당하는 지점의 고객만 보여 주어야 할 때 사용할 수 있습니다. 정책은 사용자 특성, 데이터 열과 정해진 값을 비교해 허용할 행을 결정합니다.

제한 뷰를 온톨로지 객체 유형의 기반 데이터소스로 지정하면, 한 행이 한 객체인 구성에서 어떤 객체를 볼 수 있는지도 이 정책으로 제어할 수 있습니다. 제한 뷰는 새 데이터셋을 만드는 일반 변환이나 배치 파생 작업의 입력으로는 사용할 수 없습니다. 읽은 값의 함수 처리, 액션, AIP Logic, OSDK 응답, 쓰기 반영과 내보내기에는 원래 행 정책이 계속 전파되지 않으므로 정책 전파 범위를 함께 고려해야 합니다.

정책의 구성 요소

정책은 규칙과 논리 연산자의 집합입니다. 사용자 특성, 기반 데이터셋의 열, 문자열이나 불리언 또는 숫자와 배열 같은 값을 비교할 수 있습니다. 사용자별 권한을 구현하려면 적어도 하나의 조건이 사용자 특성과 연결되어야 합니다.

사용자, 그룹과 조직의 신원을 참조하는 조건에는 정책 열과 정책 정의 양쪽 모두 UUID를 사용합니다. 이름으로 대체하면 이름 변경에 따라 정책 의미가 바뀔 수 있으므로 지원하지 않습니다. 조직에는 ri.multipass..organization.으로 시작하는 조직 RID가 아니라 조직의 보안 표지 UUID가 필요합니다.

그룹, 보안 표지나 조직 소속에 NOT 조건을 적용하면 안 됩니다. 범위가 제한된 토큰은 사용자의 전체 소속 중 일부만 포함할 수 있습니다. 이때 토큰에 없는 소속을 NOT으로 검사하면 조건이 참이 되어 의도보다 넓은 접근을 허용할 수 있습니다. 필요한 소속을 긍정 조건으로 표현합니다.

세분화된 접근 정책에서 지원 특성, 비교 연산자와 정책 크기 한도를 확인하고, 정책이 참조할 열과 파이프라인을 먼저 준비합니다.

제한 뷰 생성

기반 데이터셋의 Owner 또는 필요한 세부 권한이 있는 사용자는 데이터셋을 오른쪽 클릭해 제한 뷰를 만들 수 있습니다.

생성 마법사는 다음 네 단계로 구성됩니다.

저장 위치

Save as에서 이름과 파일시스템 위치를 지정합니다. 일반적으로 입력 데이터셋과 다른 프로젝트에 두면 이용자는 제한 뷰 쪽 프로젝트의 읽기 권한을 받고 원본 프로젝트는 보지 않게 구성하기 쉽습니다. 같은 프로젝트에 둘 수도 있지만, 그 경우에도 원본을 직접 읽어서는 안 되는 사용자를 보안 표지 등으로 구분해야 합니다.

정책 작성

Compose a granular policy에서 사용자 특성, 열과 값을 선택해 규칙을 작성합니다. 정책은 조회한 사용자에게 어떤 행이나 객체를 반환할지를 정합니다.

접근 요건 검토

Review access requirements에서 상류 데이터셋과 하류 제한 뷰의 파일 및 트랜잭션 수준 보안 표지를 함께 확인합니다. 제한 뷰를 통해서만 읽어야 하는 사용자가 원본을 직접 읽을 수 없도록 구성합니다.

필요한 표지 권한이 있으면 제한 뷰에서 상속한 표지를 제거하거나 원본에 표지를 적용하는 변경을 할 수 있습니다. 행 필터가 있다는 이유만으로 표지를 제거하지 않습니다. 표지 제거는 파생 데이터로 전파되던 자격 조건을 없애는 접근 범위 확대이므로, 보호 목적과 원본 직접 접근 경로를 함께 검토해야 합니다.

최종 구성과 초기 빌드

Summary에서 원본과 제한 뷰에 적용될 최종 접근 통제를 확인하고 Create를 선택합니다. 제한 뷰를 만들면 초기 빌드를 시작하며, 입력 데이터셋이 갱신될 때마다 제한 뷰를 다시 빌드하는 일정도 자동 생성됩니다.

행에 보안 표지 목록을 저장하는 정책

각 행에 필요한 보안 표지 ID의 배열을 저장하고, 사용자에게 그 표지들이 모두 허용되는지 검사할 수 있습니다. 다음은 가상의 표지 이름을 사용한 예입니다. 첫 행을 읽으려면 A1과 A2가 모두 필요하고, 둘째 행을 읽으려면 B1이 필요합니다.

구성 절차는 다음과 같습니다.

1. 보안 표지 UUID를 문자열 배열로 담는 열을 하나 이상 만듭니다. 셀 하나에는 해당 행에 필요한 표지들의 목록이 들어갑니다.
2. Dataset Preview의 COLUMNS에서 열을 선택하고 Add typeclasses에 marking_type.mandatory를 추가할 수 있습니다. 이 타입클래스는 일부 화면이 값을 보안 표지로 표시하도록 주는 힌트이며, 세분화된 권한 적용의 필수 조건은 아닙니다.
3. 제한 뷰 정책의 왼쪽에 사용자의 보안 표지, 오른쪽에 Columns와 해당 표지 열을 선택합니다. 사용자의 표지 집합이 행의 모든 표지를 포함해야 하는 조건은 Superset of로 표현합니다.
4. 표지 열이 여러 개이면 열별 규칙을 만들고 업무 요건에 따라 AND 또는 OR로 결합합니다.

표지 ID 열에는 보안 표지와 조직의 보안 표지 UUID를 함께 넣을 수 있습니다. 데이터형은 단일 문자열이 아니라 문자열 배열이어야 합니다.

예제 CSV는 배열을 담는 파일 형식을 보여 줍니다. CSV의 네 UUID는 설명용 값이므로 자신의 환경에서 실제로 사용할 보안 표지 UUID로 바꿔야 합니다. 업로드 후 Details > Schema에서 Markings 열의 추론된 형식이 STRING이면 기존 열 정의의 다른 항목을 유지한 채 다음 형식으로 바꿉니다.

{
  "type": "ARRAY",
  "arraySubtype": {
    "type": "STRING"
  }
}

이 조각은 Dataset Preview의 스키마 편집 형식입니다. REST API의 전체 데이터셋 스키마 요청 본문으로 사용하는 값은 아닙니다. 정책 열에 NULL이 생기지 않도록 상류에서 관리해야 합니다.

Marketplace 제품에 포함

Foundry DevOps에서 제품을 만든 뒤 출력 추가 단계의 Add files를 선택하고, 파일시스템에서 제한 뷰를 찾아 제품에 넣을 수 있습니다. 제품에는 제한 뷰의 정책을 패키징하며 데이터를 함께 패키징하는 것은 아닙니다.

제한 뷰의 Marketplace 패키징에는 다음 제약이 있습니다.

• 상수는 string과 boolean만 지원합니다.
• 상수는 데이터 필드(열) 또는 사용자의 그룹 속성과 비교할 수 있습니다.
• 같은 필드에 여러 개의 필드-상수 비교 조건을 적용하는 구성은 지원하지 않습니다.

설치 대상 환경에서는 그 환경의 사용자 특성과 그룹 소속으로 정책을 평가합니다. 원래 환경의 사용자 특성이나 그룹 소속 상태를 제품이 함께 옮기지 않으므로, 설치 담당자가 필요한 특성과 그룹을 준비하고 정책이 의도대로 적용되는지 확인해야 합니다. 설치 후에도 이 정책은 읽기 필터이며, 반환된 값의 후속 파생 결과에 자동 전파되지 않습니다.

객체 유형 연결과 지원 작업은 권한 및 운영 제한, 브랜치에서 정책을 변경하는 절차는 제한 뷰 브랜치, 특정 사용자의 접근 상태는 권한 확인에서 다룹니다.