업무용 애플리케이션의 데이터와 편집 권한 설계

업무용 애플리케이션을 사용하려면 애플리케이션 파일, 온톨로지 유형 정의, 실제 객체 데이터와 액션에 필요한 권한을 각각 충족해야 합니다. 애플리케이션을 편집하는 사람과 데이터 파이프라인을 편집하는 사람이 다르면 두 리소스를 별도 프로젝트에 두어 관리할 수 있습니다.

다음은 가상의 Sky Industries가 Flight Alert Inbox를 만드는 예입니다. 항공편 데이터 파이프라인의 최종 결과는 Aviation [Ontology] 프로젝트에 있습니다.

데이터셋 기반 객체와 쓰기 반영

Flight, Flight Alert, Delay, Aircraft 객체 유형을 만들고, 준비한 데이터셋을 기반 데이터소스로 선택합니다. 열을 속성에 매핑하고 행을 객체 인스턴스로 나타내는 구성에서는 기반 데이터셋의 권한이 객체 데이터를 보호합니다.

예를 들어 Aircraft가 /Sky Industries/Aviation [Ontology]/aircraft 데이터셋을 기반으로 한다면, Aviation [Ontology] - Viewer 그룹에 부여한 읽기 역할과 해당 데이터의 추가 접근 요건을 충족하는 사용자가 객체 데이터를 읽습니다.

객체 간 관계에 맞춰 링크 유형도 생성합니다.

쓰기 반영은 기존 속성값의 정정이나 상태 갱신뿐 아니라 새로운 업무 데이터와 판단 결과를 기록하는 데 사용할 수 있습니다. 편집 데이터셋을 생성하는 구성에서는 Editor 영역에서 쓰기 반영 데이터셋을 만들고, 기반 데이터셋과 같은 온톨로지 프로젝트에 저장하면 접근 권한을 일관되게 관리하기 쉽습니다. 객체 편집에는 액션을 사용하는 방식을 권장하며, 액션은 API로도 호출할 수 있습니다. 액션 제출과 쓰기 대상의 권한은 별도로 적용됩니다.

네 객체의 기반 데이터가 같은 프로젝트에 있고 추가 제한이 같다면, 새 사용자에게 해당 프로젝트의 Viewer 그룹 소속을 부여해 데이터 접근을 관리할 수 있습니다.

온톨로지 정의의 편집 권한

객체 유형, 링크 유형과 액션 유형의 정의는 해당 리소스가 저장된 Compass 프로젝트의 역할로 관리합니다. 프로젝트 Security에서 역할을 조정합니다. 예를 들어 Flight Alert 유형의 정의를 편집하려면 그 유형이 저장된 프로젝트에서 해당 편집을 허용하는 역할이 필요합니다.

객체 유형에 역할을 부여하는 것은 유형 정의와 메타데이터에 대한 권한입니다. 실제 객체 데이터의 접근 권한까지 함께 부여하지는 않습니다. 데이터는 기반 데이터소스의 권한으로 관리합니다.

승객 객체의 행별 접근 제한

국가별 담당자에게 해당 국가의 승객만 보여 주려면 데이터셋 전체의 읽기 권한만으로는 요구를 표현할 수 없습니다. 객체 유형의 기반 데이터소스를 제한 뷰로 바꾸거나, Ontology Manager의 Security에서 객체 보안 정책을 구성합니다.

제한 뷰를 사용할 경우 입력 데이터셋의 Create restricted view를 선택합니다.

이 예에서는 원본과 접근 대상을 구분하기 위해 Customer Information [Restricted] 프로젝트를 만들고 제한 뷰를 저장합니다. 이용자에게 원본 데이터셋의 직접 읽기 권한을 주지 않도록 구성합니다.

정책은 다음 두 조건을 OR로 결합합니다.

• 사용자의 location:country 특성이 행의 country 열과 같습니다.
• 사용자가 모든 국가의 승객 데이터를 볼 수 있는 passenger-data-global-access 그룹에 속합니다.

그룹을 정책에서 식별할 때에는 이름을 그대로 비교 대상으로 넣지 않고 실제 그룹 UUID를 사용합니다. 이 예의 그룹 이름과 특성값은 업무 규칙을 설명하기 위한 값입니다.

그룹, 조직이나 보안 표지 소속을 NOT으로 부정하는 정책은 사용하지 않습니다. 범위가 제한된 토큰에 소속 정보가 빠지면 부정 조건이 참이 되어 의도보다 넓은 접근을 허용할 수 있습니다.

제한 뷰를 빌드한 뒤 Passenger 객체의 기반 데이터소스로 지정하면 해당 정책으로 볼 수 있는 객체 인스턴스를 구분합니다. 읽기 필터는 사용자에게 반환된 값의 후속 쓰기나 내보내기에 자동 전파되지 않습니다. 제한 뷰의 권한과 운영 제한을 함께 고려합니다.

앱 프로젝트의 역할 분리

Workshop으로 앱을 만들고 Flight Alert Inbox라는 별도 프로젝트에 저장합니다. 이 예의 앱 프로젝트에는 보안 표지가 없으므로, 사용자는 Sky Industries 조직 요건과 프로젝트 역할을 충족해야 합니다.

이 역할 구분은 최종 데이터와 앱 파일에 대한 기본 구성이며, 별도 프로젝트에 저장한 Passenger 제한 뷰나 다른 의존 리소스의 접근 조건을 대신하지 않습니다. 승객 데이터를 읽는 사용자는 제한 뷰 리소스 접근과 행 정책도 충족해야 합니다.

Check access의 Additional data requirements에서 앱이 사용하는 객체, 링크와 액션 유형의 접근 상태까지 확인합니다.