세분화된 접근 정책 설계

세분화된 접근 정책(Granular policy)은 사용자 특성, 그룹 소속과 데이터 값을 비교해 읽을 수 있는 행이나 객체를 정합니다. 제한 뷰와 객체 보안 정책이 이 규칙을 사용합니다. 소비 애플리케이션이 데이터를 요청하면 사용자 정보와 데이터 값을 정책 템플릿에 대입해 조회 조건을 만들고, 그 사용자에게 허용된 결과만 반환합니다.

정책을 만들기 전에 정할 사항

보호할 데이터 범위와 허용할 사용자를 먼저 문장으로 적습니다. 어떤 사용자 특성을 쓸 수 있는지, 어떤 열이나 객체 속성에 조건을 걸지, 새 사용자에게 어떻게 자격을 줄지 정해야 합니다. 파이프라인에서 전파되는 보안 표지를 유지하거나 제거할 조건도 별도로 판단합니다.

조건을 최소한으로 유지하고, 복잡한 조직 관계나 데이터 가공은 가능하면 상류 파이프라인에서 처리합니다. 정책 전용 열을 두면 업무용 열의 의미가 바뀌어 정책 가정까지 깨지는 위험을 줄일 수 있습니다. 사용자 특성은 SSO 또는 사용자 관리 모듈에서 제공할 수 있습니다.

정책 열은 NULL이 없도록 관리합니다. 정책 열에 NULL이 있는 행은 모든 사용자에게 접근 불가가 되며, Phonograph 동기화 등 하류 처리에도 문제가 생길 수 있습니다.

지원 사용자 특성

특성	의미와 주의점
`User ID`	Foundry가 사용자마다 생성하는 고유 식별자입니다.
`Username`	로그인할 때 신원 제공자가 제공하는 사용자 고유 식별자입니다.
`Group IDs`	사용자가 직접 또는 상속으로 속한 모든 그룹의 ID입니다.
`Group names`	사용자가 직접 또는 상속으로 속한 그룹의 이름입니다.
`Authorized group IDs`	범위 제한 세션과 관련된 고급 특성입니다. 범위 제한 세션과 함께 사용할 계획이면 플랫폼 관리자와 구성을 확인합니다.
`Organization Marking IDs`	기본 조직과 게스트 조직의 보안 표지 UUID입니다. `ri.multipass..organization.`으로 시작하는 조직 RID와 다릅니다.
`Marking IDs`	사용자가 열람할 자격이 있는 보안 표지들의 ID입니다.
`Custom attributes`	Control Panel의 인증 구성에서 신원 제공자가 제공하도록 설정한 사용자 정의 특성입니다.

사용자, 그룹과 조직의 신원을 정책 열이나 정의에서 참조할 때에는 UUID를 사용합니다. 지원 속성 목록에 이름 관련 항목이 있더라도, 소속 대상을 이름으로 지정해 UUID를 대신하는 방식은 지원하지 않습니다. 정책과 기반 열이 같은 식별자 체계를 사용해야 이름 변경으로 권한 의미가 바뀌지 않습니다.

소속을 부정하는 조건의 위험

그룹, 보안 표지나 조직 소속에 NOT을 적용하는 정책은 잘못된 구성입니다. 범위 제한 토큰은 사용자 전체 권한의 일부만 담을 수 있으므로, 사용자가 실제로 가진 소속이 토큰에서는 보이지 않을 수 있습니다. 이를 부정 조건으로 검사하면 권한을 줄인 토큰이 오히려 더 많은 데이터를 읽게 될 수 있습니다.

예를 들어 특정 그룹에 속하지 않은 사람에게 허용하는 조건 대신, 해당 업무를 승인받은 그룹에 속한 사람에게 허용하는 긍정 조건으로 정책을 구성합니다. 이 주의사항은 사용자에게 그룹 소속이 하나도 없는 세션에도 적용됩니다.

비교 연산자

양쪽 자료형은 같은 기본형 또는 그 기본형의 컬렉션이어야 합니다. 단일값과 컬렉션을 혼동하지 않습니다.

비교	의미	자료형 조건
`Equal`	양쪽 값이 같습니다.	양쪽 모두 단일값이며 같은 자료형이어야 합니다.
`Intersects`	양쪽에 공통값이 하나 이상 있습니다.	적어도 한쪽은 컬렉션이어야 합니다.
`Subset of`	왼쪽의 모든 값이 오른쪽 집합에 포함됩니다.	오른쪽은 컬렉션이어야 합니다.
`Superset of`	왼쪽 집합이 오른쪽의 모든 값을 포함합니다.	왼쪽은 컬렉션이어야 합니다.
`Less Than`	왼쪽 값이 오른쪽보다 작습니다.	양쪽 모두 단일값이며 같은 자료형이어야 합니다.
`Less Than or Equal`	왼쪽 값이 오른쪽보다 작거나 같습니다.	양쪽 모두 단일값이며 같은 자료형이어야 합니다.
`Greater Than or Equal`	왼쪽 값이 오른쪽보다 크거나 같습니다.	양쪽 모두 단일값이며 같은 자료형이어야 합니다.
`Greater Than`	왼쪽 값이 오른쪽보다 큽니다.	양쪽 모두 단일값이며 같은 자료형이어야 합니다.

객체 보안 정책은 작다 또는 크다 계열의 비교 연산자를 지원하지 않습니다. 제한 뷰에서 사용할 수 있는 비교를 객체 정책에도 그대로 옮길 수 있다고 가정하지 않습니다.

예를 들어 사용자 ID와 담당자 열을 비교하면 단일값의 Equal을 사용합니다. 사용자가 속한 그룹 중 하나가 행의 허용 그룹과 일치하는지 확인할 때에는 Intersects를, 행이 요구하는 모든 보안 표지를 사용자가 가진 경우에만 허용하려면 사용자 표지 집합의 Superset of를 사용합니다.

비교 개수와 가중치 한도

정책 하나에는 비교를 최대 10개까지 넣을 수 있습니다. 비교 개수와 별도로 가중치 합계가 10,000보다 작아야 합니다.

조건	가중치
상수와 필드 비교	1
컬렉션과 필드 비교	1,000
보안 표지 조건	3,000

사용자 ID라는 단일 상수와 필드를 비교하는 조건 하나, 사용자 그룹 컬렉션과 필드를 비교하는 조건 하나를 사용하면 합계는 1,001입니다. 반면 보안 표지 조건 세 개와 컬렉션 조건 하나는 10,000이므로 허용 범위를 벗어납니다. 비교가 네 개뿐이어도 가중치 제한을 만족하지 못할 수 있습니다.

정책 작성 시의 한도가 모든 조회 비용이나 복잡도를 보장하는 성능 검사는 아닙니다. 정책 구성 중 가중치 오류가 발생하면 Palantir Support에 문의합니다.

정책이 의존하는 데이터의 무결성

정책은 기반 열의 의미와 값이 올바르다는 가정에 의존합니다. 그 가정이 깨지면 정책 식 자체가 변하지 않아도 접근 결과가 잘못될 수 있습니다. 제한 뷰나 객체 정책 바로 상류에서 다음과 같은 검사를 적용할 수 있습니다.

불변 조건을 검사합니다. 예를 들어 event_occurred_in_state가 NY인 행에서는 state_name이 New York이어야 한다면, 조건을 위반한 빌드가 사용자에게 데이터를 노출하기 전에 실패하도록 합니다.
통계 변화의 허용 범위를 검사합니다. 조직 계층에서 자신 아래 사람의 데이터만 보게 하는 정책이라면, 하루 사이 계층의 20%를 초과하는 변경이 발생했을 때 담당자가 검토하도록 처리할 수 있습니다.

이 수치와 열 이름은 정책 관리 방식을 설명하는 예입니다. 실제 불변 조건과 허용 범위는 데이터 소유자가 업무에 맞게 정합니다. 정책을 관리하는 사람은 현재 규칙과 데이터의 관계를 알 수 있어야 하며, 변경은 적용 전에 검토합니다.

무결성 검사는 읽기 필터가 올바른 입력을 사용하도록 보호합니다. 반환된 값에 원본 정책을 계속 붙이는 기능은 아닙니다. 파생 데이터에 유지할 자격 조건은 기반 데이터의 보안 표지나 해당 데이터 분류로 구성하고, 플랫폼 밖 반출의 별도 통제도 검토합니다.

Keyboard shortcuts