보안 표지 적용과 제거를 파이프라인에 설계하기

보안 표지는 리소스에 적용된 모든 표지의 구성원만 접근할 수 있게 하는 요건입니다. 폴더 계층과 직접 의존 관계를 따라 상속되므로 원천에 표지를 붙이면 파생 데이터도 영향을 받습니다. 적절한 권한이 있으면 리소스에서 직접 제거하거나 변환의 입력에서 상속을 중단할 수 있습니다.

상위 단계에서 민감한 데이터를 보호하고, 해당 내용을 제거한 하위 단계에서 표지를 해제하는 파이프라인은 도입 순서가 중요합니다. 기존 사용자에게 필요한 접근을 갑자기 막지 않도록 현재의 권한 전파와 트랜잭션 이력을 먼저 구분합니다.

기존 severing을 표지 제거로 전환

severing은 권한 전파를 끊던 이전 기능입니다. 이미 표지를 사용하고, severing의 유일한 목적이 그 표지의 전파를 막는 것이며, 프로젝트의 Propagate View Requirements가 꺼져 있다면 명시적인 보안 표지 제거로 전환하는 것이 권장됩니다.

상속 중단을 입력의 stop_propagating으로 표현하고 실제 민감 정보 제거 로직과 함께 승인받습니다. 저장소의 재승인 모드도 결정합니다. severing을 해제하는 변경과 표지 제거 설정은 함께 적용하여 중간에 표지가 의도치 않게 전파되지 않도록 합니다.

Propagate View Requirements가 켜져 있다면 다음 전환 절차를 먼저 검토합니다.

프로젝트 조회 요건 전파와 보안 표지

새 프로젝트는 Propagate View Requirements가 기본적으로 꺼져 있습니다. 이 설정이 꺼진 상위 프로젝트에서 만든 데이터를 다른 프로젝트가 사용하더라도, 하위 데이터를 읽기 위해 상위 프로젝트의 조회 권한까지 요구하지 않습니다.

설정이 켜져 있으면 하위 데이터 조회에도 해당 상위 프로젝트의 조회 권한이 추가로 필요합니다.

보안 표지는 이 설정과 관계없이 전파됩니다. 조회 요건 전파를 끈다고 보안 표지가 사라지는 것은 아닙니다. 민감한 데이터의 보호에는 조회 요건 전파보다 보안 표지를 사용하는 방식이 권장됩니다.

기존 설정을 바꾸기 전에는 왜 조회 요건 전파를 켰는지 확인합니다.

1. 유지해야 할 이유가 없다면 설정을 끄고 사용자가 실제로 필요한 데이터셋에만 접근하도록 역할 권한을 정리할 수 있습니다.
2. 프로젝트의 일부 데이터만 민감하다면 민감한 데이터와 그렇지 않은 데이터를 구분하고 민감한 구간을 보안 표지로 보호합니다.
3. 이 구조로 요구를 충족하지 못하면 Palantir 담당자와 전환 방법을 검토합니다.

조회 요건 전파를 보안 표지로 바꾸는 순서

가상 원천 프로젝트 Datasource에서 raw_dataset_1만 민감하고, 하위 프로젝트에는 A, B, C, D가 있다고 가정합니다. 기존에는 A를 읽기 위해 원천과 하위 프로젝트 양쪽의 Viewer 권한이 필요하며, B 이전의 severing이 상위 조회 요건을 끊고 있습니다.

전환 후 A에는 하위 프로젝트의 Viewer 권한과 새 표지 접근 요건이 필요합니다. 민감하지 않은 경로의 C와 D에는 이 예시의 프로젝트 조회 권한 기준으로 하위 프로젝트 Viewer만 필요합니다. 그 밖의 조직이나 다른 보안 표지 요건은 별도로 충족해야 합니다.

이 절차는 기존 severing이 이미 있고 이를 표지 제거로 교체하는 경우를 전제로 합니다.

1. 새 보안 표지를 만들고 필요한 사용자에게 표지 접근 권한을 부여합니다.
2. raw_dataset_1에 표지를 적용합니다. severing으로 끊기지 않은 트랜잭션 의존 경로에는 즉시 전파됩니다.
3. 표지 적용 후 원천 프로젝트의 Propagate View Requirements를 끕니다.
4. severing을 해제하면서 같은 변경에서 표지 제거를 적용합니다.
5. 파이프라인의 모든 데이터셋을 빌드합니다.
6. 더 이상 원천 프로젝트에 접근할 필요가 없는 사용자의 원천 프로젝트 접근을 정리합니다.

기존 severing이 없는 파이프라인은 이 순서를 그대로 적용하지 않고 과거 트랜잭션의 영향을 확인해야 합니다.

기존 파이프라인에 새 표지를 도입하는 경우

원시 데이터 A, 민감한 내용을 제거하는 파생 데이터 B, B를 사용하는 하위 데이터셋이 있다고 가정합니다. A 또는 A를 포함한 폴더에 표지를 붙이면 A의 전체 과거 트랜잭션에 적용되고, 그 이력을 참조하는 B와 하위 데이터셋에도 즉시 영향을 줍니다.

A에서 B로 가는 변환에 표지 제거를 넣고 B를 다시 빌드하면 새 출력 트랜잭션에는 제거 설정이 적용됩니다. B의 과거 트랜잭션에서 표지를 소급하여 제거하는 것은 아닙니다. 표지 적용과 변환에서의 제거는 이 점에서 대칭적인 동작이 아닙니다.

현재 데이터셋 뷰의 권한은 각 입력의 가장 최근 트랜잭션을 기준으로 확인합니다. 따라서 증분 하위 데이터셋도 일반 빌드로 최신의 표지 없는 입력을 참조하도록 갱신할 수 있습니다. B의 제거 변환부터 해당 하위 데이터셋까지 사이에 있는 모든 데이터셋을 제거 설정 적용 후 다시 빌드해야 합니다. 과거 트랜잭션이 바뀌었다는 뜻이나 모든 경우에 전체 스냅샷 빌드가 필요하다는 뜻은 아닙니다.

하위 재빌드가 너무 많은 경우의 입력 교체

아직 기존 A에 새 표지를 적용하지 않은 상태에서, 하위 전체를 재빌드하지 않도록 새 원천 A′를 사용하는 전환을 검토할 수 있습니다.

1. 내용이 A와 같은 새 데이터셋 A′를 만듭니다.
2. B가 A 대신 A′를 입력으로 읽도록 바꾸고, 같은 변환에 필요한 표지 제거 설정도 추가합니다.
3. 이 변경 후 B를 즉시 빌드합니다. 명시적으로 스냅샷 빌드를 요청할 필요는 없지만 입력 교체 자체가 비증분 스냅샷 실행을 유발할 수 있으므로 성능 영향을 고려합니다.
4. A′에 새 표지를 적용합니다.
5. 대체한 기존 A를 휴지통으로 이동합니다.
6. 이 구성에서는 그 뒤 하위 데이터셋을 추가로 재빌드할 필요가 없습니다.

중요한 파이프라인이거나 기존 이력과 의존 관계가 이 조건에 맞는지 불분명하면 Palantir 담당자와 전환을 검토합니다.

공개할 데이터의 허용 목록

표지가 필요한 기준을 명확히 정의하고, 제거 변환에서는 공개해도 되는 행과 열을 적극적으로 선택합니다. 현재 알려진 민감 필드나 값만 제외하는 방식은 상위에 새로운 민감 정보가 추가되었을 때 그대로 통과시킬 수 있습니다.

다음은 가상 정책에서 salary, title, department와 주 코드 OH, CA, DE가 공유 가능하다고 별도로 승인되었다는 전제의 로직입니다. 이 열 이름이나 주 코드 자체가 일반적으로 공개 가능한 데이터라는 뜻은 아닙니다.

from pyspark.sql import DataFrame, functions as F


def select_approved_columns(dataframe: DataFrame) -> DataFrame:
    return dataframe.select("salary", "title", "department")


def select_approved_states(dataframe: DataFrame) -> DataFrame:
    return dataframe.filter(F.col("state").isin(["OH", "CA", "DE"]))

행과 열 제한을 함께 적용할 때는 select_approved_states로 행을 선택한 뒤 select_approved_columns로 출력 열을 제한합니다.

반대로 firstname, lastname만 drop하거나 FL, TX, IL만 제외하면 새 민감 열이나 다른 제한 대상 행이 들어올 때 보호하지 못할 수 있습니다. 이 제외 목록 방식은 표지 제거의 안전 기준으로 권장하지 않습니다.

표지를 제거하는 설정은 민감 정보 제거 또는 가림을 실제로 수행하는 변환에 둡니다. 정리 로직을 다른 저장소에 숨기거나, 아무 처리 없이 입력을 그대로 전달하는 별도 표지 제거 저장소를 만들지 않습니다. 프로젝트 안에서는 입력을 가져온 직후처럼 가능한 상위 지점 또는 출력을 내보내기 직전처럼 가능한 하위 지점에 제거 경계를 명확히 둘 수 있습니다.

저장소와 재승인

기본적으로 Require re-approval을 유지합니다. Don't require re-approval이 꼭 필요하면 편집자 범위를 줄이고 필요한 승인 절차를 거칩니다. 이 모드에서 이후 로직 변경이 보안 승인 없이 진행될 수 있기 때문입니다.

프로젝트마다 저장소 하나를 두는 일반 권장과 재승인 범위가 충돌하면, 실제 가림 및 열 제거 로직이 있는 변환들을 별도 저장소에 모으고 그 저장소에 재승인을 요구할 수 있습니다. 이는 아무 처리 없는 identity 변환만 모아 표지를 제거하는 저장소와 다릅니다.

stop_propagating과 stop_requiring은 출력 속성이 아닙니다. 특정 출력에서 상속을 중단하려면 제한을 전달하는 모든 입력에 각각 설정합니다. Python, Java와 SQL에서 지원하며, 문법과 승인 조건은 상속 표지와 조직 제거에서 설명합니다.

severing보다 명시적인 표지 제거를 사용하면 전파 변경의 대상과 승인 범위를 세밀하게 관리할 수 있습니다. 기존 저장소를 전환하면서 새 변환에 severing을 추가하지 못하게 하려면 Palantir 담당자에게 해당 제한을 요청합니다.