변환에서 상속 보안 표지와 조직 요건 제거하기

민감한 내용을 제거하거나 적절히 가린 파생 데이터에는 입력의 보안 표지나 조직 접근 요건을 더 이상 적용하지 않을 수 있습니다. stop_propagating은 보안 표지의 전파를 중단하고, stop_requiring은 입력에서 상속하는 조직 요건을 제거합니다. 실제 데이터 정리 로직과 제거할 접근 요건을 함께 승인받아야 합니다.

접근 요건과 제거 범위

조직 제거는 나열한 조직만 선택적으로 없애는 방식이 아닙니다. 해당 입력에서 상속하는 조직 요건 전체를 제거하며, 나열한 ID는 누구의 승인을 받아야 하는지를 정합니다. 상위 조직을 최소 하나 지정해야 하고, 모든 상위 조직의 승인을 요구하려면 모든 ID를 나열합니다. 모든 입력의 상속 조직 요건을 제거한 출력은 자신이 속한 프로젝트의 조직 요건을 따릅니다.

보호 브랜치와 승인 전제

• 저장소에 보호 브랜치가 최소 하나 있어야 합니다.
• 해당 보호 브랜치는 필수 승인자를 최소 한 명 요구해야 합니다.
• 제거는 지정한 보호 브랜치에서만 적용합니다. 제거 대상 목록에 보호되지 않은 브랜치를 넣으면 빌드가 실패합니다.
• Python, Java와 SQL에서 지원합니다.
• 보안 표지 제거 승인에는 해당 표지의 Remove marking 권한이 필요합니다.
• 조직 요건 제거 승인에는 해당 조직의 Expand access 권한이 필요합니다.

출력 프로젝트에는 모든 입력의 프로젝트 참조를 추가해야 합니다.

기본 절차는 보호 브랜치에서 기능 브랜치를 만들고, 입력에 제거 설정과 실제 정리 로직을 추가한 뒤 보호 브랜치로 PR을 여는 것입니다. 적절한 권한을 가진 검토자가 승인하면 편집자가 병합하고 출력 데이터셋을 빌드합니다. 검토자가 여러 명이면 한 명의 거절도 전체 PR의 거절로 이어집니다.

제거 설정은 새 출력 트랜잭션에 적용합니다. 과거 출력의 보안 표지가 소급하여 사라지는 것은 아니므로 기존 파이프라인의 전환에는 트랜잭션 이력과 재빌드 조건을 적용합니다.

입력별 설정

표지나 조직을 전달하는 입력이 여러 개이면 제거가 필요한 각 입력에 설정해야 합니다. 출력 인자에 넣는 속성이 아닙니다. ID와 브랜치 이름은 문자열로 지정합니다.

OrgMarkings라는 이름은 조직을 내부적으로 다른 종류의 보안 표지로 표현하는 데서 비롯합니다. 보안 표지 ID는 Settings의 Markings, 조직 ID는 Organizations 목록에서 확인합니다.

Python 변환 생성 함수

다음 함수는 실제 입력 및 출력 경로, 보안 표지 ID, 조직 ID와 보호 브랜치를 인자로 받아 등록 가능한 Transform을 만듭니다. 반환한 Transform을 저장소 파이프라인에 등록합니다.

가상 업무에서 입력 A에는 employee_key, title, department가 있고 입력 B에는 employee_key, tenure_months가 있다고 가정합니다. 각 입력의 employee_key는 고유하며, 두 입력이 모두 가진 키만 내부 조인합니다. 출력에는 별도로 공유 승인을 받은 title, department, tenure_months만 남깁니다. 이 열 조합 자체가 일반적인 익명화나 공개 적합성을 보장하지는 않습니다.

from transforms.api import Input, Markings, OrgMarkings, Output, transform


def make_clean_join(
    *,
    input_a_path: str,
    input_b_path: str,
    output_path: str,
    lemon_marking_id: str,
    apple_marking_id: str,
    cherry_marking_id: str,
    org_a_id: str,
    protected_branch: str,
):
    branches = [protected_branch]

    @transform(
        input_a=Input(
            input_a_path,
            stop_propagating=Markings([lemon_marking_id], branches),
            stop_requiring=OrgMarkings([org_a_id], branches),
        ),
        input_b=Input(
            input_b_path,
            stop_propagating=Markings(
                [apple_marking_id, cherry_marking_id], branches
            ),
            stop_requiring=OrgMarkings([org_a_id], branches),
        ),
        output=Output(output_path),
    )
    def compute(input_a, input_b, output):
        employees = input_a.dataframe().select(
            "employee_key", "title", "department"
        )
        tenure = input_b.dataframe().select("employee_key", "tenure_months")
        approved = (
            employees.join(tenure, on="employee_key", how="inner")
            .select("title", "department", "tenure_months")
        )
        output.write_dataframe(approved)

    return compute

선택하지 않은 다른 보안 표지는 계속 전파됩니다. 예를 들어 입력 A에 banana가 함께 있어도 위 함수는 이를 제거하도록 요청하지 않습니다. 보호 브랜치가 main이면 그 이름을, 실제 보호 브랜치가 master이면 해당 이름을 전달합니다.

Java 구성

자동 등록의 입력 애너테이션

자동 등록 변환은 public 비정적 @Compute 메서드와 입출력 애너테이션으로 정의하고, Pipeline.autoBindFromPackage()로 등록합니다. 표지를 제거할 입력 매개변수에 다음 애너테이션을 적용합니다.

입력 선언에 적용하는 문법 예시는 다음과 같습니다. UUID는 가상 예시이므로 실제 ID로 바꾸며, main은 실제 보호 브랜치여야 합니다.

@StopPropagating(
    markings = {"11111111-1111-4111-8111-111111111111"},
    onBranches = {"main"}
)
@StopRequiring(
    orgMarkings = {"22222222-2222-4222-8222-222222222222"},
    onBranches = {"main"}
)
@Input("/Company/private/employees")
FoundryInput input

표지나 브랜치가 하나이면 Java 애너테이션의 배열 표기인 중괄호를 생략할 수도 있습니다. 예를 들어 onBranches = "main"을 사용할 수 있습니다. 실제 @Compute 메서드에서는 입력을 읽어 승인된 행과 열을 선택하고 FoundryOutput에 기록합니다. 출력에도 @Output으로 실제 출력 경로를 지정합니다.

이 애너테이션들은 자동 등록에서만 지원합니다. 수동 등록에서는 다음 빌더 속성을 사용합니다.

수동 등록의 desiredUnmarkings

수동 등록은 계산 함수를 담은 객체와 입출력 매핑을 MyPipelineDefiner.java의 define(Pipeline pipeline)에서 구성합니다. 고수준 변환의 계산 함수는 @Compute가 붙은 public 비정적 메서드이며 Dataset<Row> 입력을 받아 실제로 정리한 Dataset<Row>를 반환합니다.

각 Unmarking.builder()에는 다음 값을 지정하고 build()로 명세를 완성합니다.

표지와 조직을 모두 제거하려면 같은 입력, 출력과 브랜치를 가리키되 ID가 다른 두 명세를 집합에 넣습니다. 등록 매핑의 경로와 제거 명세의 alias가 어긋나지 않도록 일치시킵니다.

SQL 힌트

SQL에서는 SELECT의 Spark SQL 힌트로 제거를 요청합니다.

다음 예시는 title, department만 공개 가능한 열로 승인되었다는 가정의 변환입니다. 경로, 가상 UUID와 보호 브랜치를 실제 구성으로 바꿉니다.

CREATE TABLE `/Company/public/employees` AS
SELECT /*+ foundry_stop_propagating('11111111-1111-4111-8111-111111111111') foundry_stop_requiring('22222222-2222-4222-8222-222222222222') foundry_on_branches('main') */
    title,
    department
FROM `/Company/private/employees`

힌트는 하위 쿼리의 SELECT에도 적용할 수 있습니다. 다음 예시는 공개 설정 테이블이 report_year를 가진 한 행이고, 비공개 직원 입력에서 승인된 두 열만 선택하는 경우입니다.

CREATE TABLE `/Company/public/employee_report` AS
SELECT settings.report_year, employees.title, employees.department
FROM `/Company/public/report_settings` AS settings
CROSS JOIN (
    SELECT /*+ foundry_stop_propagating('11111111-1111-4111-8111-111111111111') foundry_on_branches('main') */
        title,
        department
    FROM `/Company/private/employees`
) AS employees

다른 입력이 같은 표지나 조직 요건을 계속 전달하면 해당 입력에도 필요한 제거를 설정해야 합니다.

승인자의 접근과 권한

승인자가 코드를 읽고 PR을 검토하려면 프로젝트와 저장소 자체의 조직 및 보안 표지 요건을 충족하고, 기본 Stemma View Repository 작업 권한이 포함된 역할이 있어야 합니다. 이 권한은 기본 Viewer 역할에 포함됩니다.

그와 별도로 제거 대상 표지의 Remove marking 또는 조직의 Expand access 권한이 필요합니다. 제거를 승인하는 권한을 가졌다는 사실이 해당 표지나 조직의 구성원이라는 뜻은 아닙니다. 제거 대상의 구성원일 필요가 없는 경우에도 저장소 자체를 볼 수 있는 접근 조건은 충족해야 합니다.

저장소별 재승인 모드

데이터 거버넌스 담당자는 저장소와 각 표지 또는 조직의 조합마다 승인 모드를 정할 수 있습니다.

PHI가 재승인을 요구하는 경우

PHI를 처음 제거하는 PR에는 PHI의 제거 승인 권한이 필요합니다. 다음 PR에서 같은 변환을 수정해도 다시 필요하고, 저장소의 다른 파일만 수정해도 PHI 승인이 필요합니다.

PALANTIR 조직이 재승인을 요구하지 않는 경우

처음 제거하는 PR에는 PALANTIR 조직의 Expand access 승인이 필요합니다. 이후 같은 변환 또는 다른 파일을 변경할 때는 이 조직의 재승인을 요구하지 않습니다.

PII, USA와 PALANTIR를 함께 사용하는 경우

같은 저장소에서 변환 1은 PII와 PALANTIR 조직 요건을 제거하고, 변환 2는 USA 표지를 제거한다고 가정합니다. PII만 재승인을 요구하고 USA 및 PALANTIR는 요구하지 않는 설정입니다.

재승인 기준이 파일 단위가 아니라 저장소와 제거 요건의 조합이라는 점 때문에, 변환 2의 변경에도 PII 승인이 필요할 수 있습니다.

여러 조직에 걸친 제거 절차

가상 입력 A에는 lemon, banana 표지가 있고 입력 B에는 apple, cherry 표지가 있습니다. 원천 프로젝트는 OrgA 또는 OrgB 구성원으로 접근을 제한하며, 하위 프로젝트는 OrgC 사용자에게도 결과를 제공하려 합니다.

목표는 lemon, apple, cherry를 제거하고 banana만 남기는 것입니다. 상위 조직 요건도 제거하여 출력 프로젝트의 조직 설정에 따라 접근하도록 합니다.

1. 하위 프로젝트에 두 입력의 참조를 추가합니다.
2. feature/clean-data 브랜치에서 실제 민감 정보 정리 로직과 입력별 제거를 작성합니다.
3. 제거를 운영 보호 브랜치에만 지정했다면 기능 브랜치에서는 여전히 모든 상위 표지와 조직 요건을 상속합니다. 해당 브랜치에서 작업하는 것만으로 운영 제거 승인을 받은 것은 아닙니다.
4. 보호 브랜치로 PR을 만들고 lemon, apple, cherry의 제거 승인자와 조직 접근 확대 승인자에게 검토를 요청합니다. 요청한 담당자에게 Foundry 알림이 전달됩니다.
5. 승인 후 병합하고 출력을 빌드합니다.

상위 조직 승인자는 다음과 같이 선택할 수 있습니다.

어느 경우든 승인된 해당 입력에서는 모든 상속 조직 요건이 제거됩니다. 이 예시에서는 데이터의 주된 책임 조직인 OrgA를 지정할 수 있습니다. 출력에 남는 banana 접근 요건과 출력 프로젝트의 역할 및 조직 요건은 여전히 충족해야 합니다.

이후 다른 개발자가 다른 코드 파일을 바꾸어도 재승인을 요구하는 표지나 조직이 하나라도 있으면 관련 보안 승인이 필요합니다. 어떤 요건도 재승인을 요구하지 않도록 설정했다면 이후 PR은 그 제거에 대한 보안 검토 없이 승인될 수 있습니다.