Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

B2B와 B2C의 데이터 공유 경계

공유 공간(Space)은 협업할 수 있는 조직의 범위를 정합니다. 실제 프로젝트 역할, 상속된 조직 요건과 마킹 및 제한 뷰 정책은 별도로 충족해야 합니다.

고객별 비공개 공간

고객 사이의 협업이 필요 없다면 고객별 조직, 공간과 온톨로지를 둡니다. 다른 조직의 사용자를 게스트로 초대해 특정 고객 공간에서 작업하게 할 수 있습니다.

게스트 소속을 추가하는 것만으로 비공개 공간 사이의 리소스 가져오기가 허용되지는 않습니다. 다른 조직의 자료를 결합하려면 조직 마킹과 공유 공간의 경계를 고려해야 합니다.

기본적으로 다른 조직의 존재를 발견할 수 없으며, Control Panel에서 조직 간 이름 및 사용자와 그룹의 가시성을 구성합니다.

여러 조직의 공유 공간

공유 공간과 그 온톨로지에 여러 조직을 허용하고, 각 프로젝트에는 필요한 조직만 적용할 수 있습니다. 예를 들어 애플리케이션별로 프로젝트를 나누고 해당 애플리케이션을 사용할 조직을 제한합니다.

제한 뷰를 결합하면 같은 애플리케이션을 사용하더라도 조직별로 허용된 행만 볼 수 있게 구성할 수 있습니다. 비공개 공간의 데이터셋을 공유 공간에서 참조하고, 공유 공간에 제한 뷰를 만든 뒤 그 제한 뷰를 공유 온톨로지의 객체 유형에 연결하는 방식입니다. 이 과정에서도 상속된 조직 요건을 필요한 승인 아래 처리해야 합니다.

제한 뷰의 정책, 프로젝트 권한과 조직 간 가시성을 함께 구성해야 합니다. 원본 데이터셋에 직접 접근하는 별도 경로를 허용하면 제한 뷰만으로 그 접근을 제한할 수 없습니다.

비공개 공간과 공유 공간 병행

공통 앱과 데이터는 공유 공간에, 고객별 맞춤 업무는 비공개 공간에 둘 수 있습니다. 공통 수집 및 연산이나 날씨 같은 공개 데이터를 함께 사용하면서 각 조직이 자기 방식으로 분석하는 경우에도 적합합니다.

조직 요건의 OR와 파생 데이터의 AND

마킹은 프로젝트 역할에 더해 리소스나 내용에 적용하는 접근 조건입니다. 위치에서 부여하는 조직 범위와 상위 데이터에서 상속하는 요건을 구분합니다.

조건적용 방식
저장 위치에 적용된 조직 A와 BA 또는 B의 구성원이나 게스트가 조직 요건을 만족. A OR B
UI에서 적용한 일반 마킹적용된 마킹을 모두 만족해야 함. 예를 들어 PII가 있으면 해당 마킹 자격이 필요
여러 입력에서 상속한 조직 요건각 입력의 조건을 모두 만족해야 함. 입력별 조건 사이에는 AND 적용

예를 들어 첫 데이터셋의 조건이 (A OR B), 두 번째가 (A OR C)라면 결합한 결과의 상속 조건은 (A OR B) AND (A OR C)입니다. A의 자격이 있거나, B와 C의 자격을 모두 갖춰야 이 조직 조건을 만족합니다. 프로젝트 역할과 일반 마킹은 별도로 확인합니다.

상위 데이터가 없는 공통 애플리케이션을 A와 B의 공유 프로젝트에 만들면 위치의 A OR B 요건이 적용됩니다.

A의 비공개 데이터와 B의 비공개 데이터를 결합한 결과에는 기본적으로 A AND B가 적용됩니다. 승인받아 상속 조직 요건을 제거한 뒤에는 공유 위치의 A OR B 요건을 따를 수 있습니다.

상속 요건 제거와 제한 뷰

변환에서 일반 마킹 전파를 중단하는 stop_propagating과 입력에서 상속한 조직 요건을 제거하는 stop_requiring은 대상이 다릅니다. stop_requiring에 나열하는 조직 ID는 승인 대상을 정하며, 그 입력에서 상속하는 조직 요건 전체를 제거합니다. 공유하면 안 되는 행과 열을 먼저 정리하고 보호 브랜치와 승인 조건을 적용합니다.

제한 뷰에서도 권한을 갖춘 사용자가 특정 마킹을 내용 전체에서 제거하고 더 세분화된 행 수준 정책을 적용할 수 있습니다. 예를 들어 현재 사용자의 식별자와 행에 저장한 담당자 식별자가 같은 경우에만 행을 보여 주는 정책을 구성할 수 있습니다.

마킹을 제거하면 파생 리소스로 전파되는 접근 조건도 사라집니다. 제한 뷰의 행 정책은 읽기 시점에만 적용되므로, 읽은 행으로 만든 반환값이나 내보낸 파일에 같은 정책이 자동으로 따라가지 않습니다. 후속 파생 리소스에도 보호가 필요하면 마킹을 유지하고, 외부 파일의 통제는 별도로 설계합니다.

실제 권한과 정책 조건은 제한 뷰에서 확인합니다.

B2C에서 개별 고객 분리

고객 수가 매우 많다면 내부 운영 조직과 별도로 모든 외부 사용자를 담는 하나의 조직을 둘 수 있습니다. 두 조직은 고객용 공유 공간과 온톨로지에 접근하고, 외부 사용자 조직에서는 사용자 및 그룹 탐색을 비활성화합니다.

사용자 탐색 제한은 사용자나 그룹을 찾는 범위를 제어합니다. 각 고객이 자기 데이터만 보게 하려면 별도의 제한 뷰 정책이 필요합니다.

자신이 만든 객체만 보게 하려면 제한 뷰를 뒷받침 데이터 소스로 사용하는 객체 유형을 만들고, 생성 액션이 현재 사용자의 식별자를 지정한 속성에 기록하도록 구성합니다. 제한 뷰 정책은 해당 속성과 현재 사용자 식별자를 비교합니다. 식별자 기록을 액션에 구성하는 단계와 그 값을 검사하는 행 정책을 함께 적용해야 합니다.

행 정책은 조회 범위를 정하며, 객체 생성 및 수정과 삭제의 액션 권한은 따로 구성합니다.