객체와 속성 보안 정책 구성
객체 보안 정책(Object security policy)은 어떤 객체를 볼 수 있는지 정합니다. 속성 보안 정책(Property security policy)은 그 객체 안의 특정 속성값을 추가로 제한합니다. 객체 정책을 통과하지 못하면 객체가 보이지 않습니다. 객체 정책은 통과하지만 해당 속성 정책을 통과하지 못하면 그 속성값을 null로 표시합니다.
속성 정책이 없는 속성에도 객체 정책은 적용됩니다. 두 정책을 함께 적용한 속성은 양쪽 정책을 모두 통과해야 합니다.
조회, 편집과 다운로드 권한
조회에는 객체 유형의 Viewer, 구성된 세부 정책과 보안 표지 및 조직 또는 분류 검사를 모두 충족해야 합니다. 객체나 속성 정책을 사용하는 유형은 기반 데이터소스의 Viewer 없이도 정책이 허용한 객체를 볼 수 있습니다.
예외는 구형 데이터소스 파생 권한 모델입니다. 이 모델에서는 보안 정책을 구성해도 유형과 객체를 보기 위해 기반 데이터소스 Viewer가 필요합니다. 프로젝트 권한으로 먼저 이전하는 것이 권장됩니다.
정책 생성과 편집에는 객체 유형의 Owner가 필요합니다. 프로젝트 기반 모델에서는 해당 유형을 담은 프로젝트의 Owner여야 합니다. 데이터소스 파생 모델에서는 온톨로지 Owner가 필요하고, 정책 구성 이후 속성 추가와 제거에도 온톨로지 Owner가 필요합니다.
다운로드 권한은 조회와 별도로 검사합니다.
| 유형의 위치 또는 권한 모델 | 다운로드 권한 검사 대상 |
|---|---|
| 프로젝트에 저장한 유형 | 객체 유형 |
| 구형 온톨로지 역할 또는 데이터소스 파생 모델 | 기반 데이터소스 |
VIP 행과 개인정보 속성의 예
가상의 Passenger 유형에 User ID, Flight Number, Seat Assignment, Name, Address, Phone Number가 있다고 가정합니다. VIP 승객은 VIP 보안 표지가 있어야 객체를 볼 수 있고, 이름과 주소 및 전화번호는 PII 표지가 있어야 볼 수 있게 구성합니다. 민감한 원천 데이터셋에는 PII와 VIP 표지를 유지하면서 온톨로지에서 필요한 범위만 제공합니다.
객체 정책 설정
Ontology Manager에서 객체 유형의 Security 탭을 엽니다.
Security policies의 Create를 선택하여 데이터소스 정책을 객체 정책으로 재정의합니다.
객체의 조회 조건, 조직과 보안 표지 및 세부 정책을 구성합니다.
이 예제에서는 모든 객체가 일괄적으로 PII와 VIP를 요구하지 않게 객체 정책의 Markings에서 두 표지의 상속을 중단합니다. 이어지는 행 및 속성 조건까지 함께 완성한 뒤 저장해야 합니다.
VIP 행의 제한은 필수 통제 속성(Mandatory control property)에 행마다 필요한 보안 표지 집합을 넣고 Granular policy로 구성합니다. VIP를 요구하는 행은 사용자가 해당 표지를 충족해야 볼 수 있습니다.
그룹, 보안 표지나 조직의 멤버십에 NOT을 사용하면 안 됩니다. 범위가 제한된 토큰(Scoped token)은 사용자 권한 중 일부만 담을 수 있습니다. 검사할 멤버십이 토큰에 없으면 부정 조건이 참이 되어 의도보다 넓은 접근을 허용할 수 있습니다.
개인정보 속성 정책 설정
Security policies에서 속성 정책을 추가합니다.
정책 이름을 지정하고 Name, Address, Phone Number를 선택합니다.
해당 속성 정책의 Manage markings에서 PII를 추가합니다.
나머지 속성은 객체 정책으로 보호하고, 개인정보 속성에는 객체 정책과 PII 속성 정책을 함께 적용합니다.
정책의 구조와 한도
속성 정책을 만들기 전에 객체 정책이 있어야 합니다. 기본 키 속성은 속성 정책에 넣을 수 없고, 나머지 속성 하나는 최대 한 개의 속성 정책에만 포함할 수 있습니다.
세부 정책은 사용자 특성과 객체 속성 및 값을 비교합니다. 객체 정책에서는 크다, 크거나 같다, 작다, 작거나 같다 연산자를 지원하지 않습니다. 정책 하나는 비교를 최대 10개 포함할 수 있습니다.
| 비교 종류 | 가중치 |
|---|---|
| 상수와 필드의 비교 | 1 |
| 컬렉션과 필드의 비교 | 1,000 |
| 보안 표지 조건 | 3,000 |
속성 정책의 세부 정책과 객체 정책의 세부 정책을 합친 가중치는 10,000 미만이어야 합니다.
객체 정책은 기본으로 원천의 보안 표지, 조직과 분류 등 모든 필수 통제를 상속합니다. 필요한 통제를 추가하거나 더 이상 필요하지 않은 상속 통제를 제거하는 설정을 할 수 있습니다. 세부 행 필터가 있다는 이유만으로 하류 데이터의 보호까지 해결되었다고 판단하지 않아야 합니다.
읽기 제어와 구체화의 통제 전파
세부 행과 열 조건은 읽는 시점의 가시성을 제어하며 그 조건 자체가 하류 출력이나 내보내기로 전파되지는 않습니다. 보안 표지와 데이터 분류는 Foundry 안의 파생 데이터에도 적용됩니다. CBAC의 프로젝트 분류는 프로젝트 접근을 제한하며 데이터 의존 관계를 따라 상속되지 않습니다.
외부로 내보낸 평문 파일에는 Foundry 접근 정책이 자동으로 집행되지 않습니다. 플랫폼 내부의 통제 전파와 다운로드 및 외부 전송의 허용 범위를 나누어 설계합니다.
객체 보안 정책을 사용하는 유형은 구체화를 일반 Foundry 데이터셋으로만 만들 수 있습니다. 결과에는 가장 제한적인 통제를 적용하며 다음 표지가 포함됩니다.
- 모든 기반 데이터소스의 보안 표지
- 객체 또는 속성 정책에 추가한 보안 표지
- 모든 객체 및 속성 세부 정책에서 사용하는 필수 통제 속성의 보안 표지
구체화 트랜잭션은 빌드할 당시 생성한 정책으로 보호됩니다. 객체나 속성 정책에 표지를 추가하거나 제거해도 과거 트랜잭션을 자동으로 다시 보호하지는 않습니다.
새 표지를 출력 트랜잭션에 반영하려면 그 표지를 포함한 정책으로 새 구체화 빌드를 완료해야 합니다. 객체 정책만 수정했다고 기존 출력이 즉시 새 표지로 보호되는 것은 아닙니다. 구체화의 자동 또는 주기 빌드 설정과 완료 상태를 확인해야 하며, Dataset Preview에서는 수동 빌드할 수 없습니다.
전체 과거 트랜잭션까지 보호하려면 구체화 데이터셋이나 기반 데이터셋 자체에도 해당 표지를 적용해야 합니다. 새 빌드가 이후 출력에 적용하는 통제와 데이터셋 자체의 표지로 과거 출력을 보호하는 조치는 서로 구분합니다.
저장하지 않은 정책 시험
Security policies의 Test policies를 선택하면 현재 인덱싱된 유형에 저장하지 않은 정책을 적용해 특정 사용자가 어떤 값을 볼 수 있는지 시험할 수 있습니다. 세부 정책에서 참조하는 속성값을 바꾸어 가상의 객체 상태도 검사할 수 있습니다.
Test security policies의 Configure test에서 User와 Object를 고릅니다. Results는 그 설정에서 사용자가 볼 수 있는 속성을 보여 줍니다.
파생 속성은 원천 객체에 대한 사용자의 가시성에도 의존하므로 이 시험으로 가시성을 확인할 수 없습니다. 또한 시험하는 구성자가 정책에서 참조하는 조직의 멤버도 관리자도 아니라면 그 조직의 게스트 멤버십과 보조 조직을 반영하지 않습니다. 이 경우 접근하지 못하는 조직 목록을 경고로 표시합니다.
제한 뷰에서 정책으로 이전
Security 탭의 이전 도구는 제한 뷰를 그 기반 데이터셋으로 교체하고, 기존 제한 뷰 정책과 같은 조건의 객체 보안 정책을 구성합니다.
다음 구성은 이전 도구에서 지원하지 않습니다.
- 다중 데이터소스 객체 유형
- 구체화가 여러 개 있거나 제한 뷰 구체화 하나가 있는 유형
- 크다, 크거나 같다, 작다, 작거나 같다 비교를 사용하는 제한 뷰의 세부 정책
- Integer, Long이나 Double 같은 숫자 상수를 참조하는 세부 정책
- 사용자 속성으로 Authorized group IDs, Organization Marking IDs나 Static marking IDs를 참조하는 세부 정책
마지막 경우에는 동등한 보안을 필수 통제 속성으로 표현하는 방식을 검토할 수 있습니다. 제한 뷰가 있던 프로젝트의 조회 조건까지 유지하려면 이전 도구에서 객체 유형을 같은 프로젝트로 옮깁니다.