마킹 관리

마킹은 Foundry 설정의 마킹 섹션에서 관리됩니다. 이후 마킹은 플랫폼 전반의 리소스에 적용됩니다.

마킹 카테고리 생성

관리자 사용자는 마킹과 마킹 카테고리를 생성하고, 메타데이터, 가시성, 멤버십을 제어할 수 있습니다. 플랫폼 설정의 마킹 섹션에 접근하려면 특별한 플랫폼 권한이 필요합니다.

필요한 권한을 가진 관리자 사용자라면, 플랫폼 설정의 마킹 섹션에서 새 마킹 카테고리 버튼을 클릭하여 마킹 카테고리를 생성할 수 있습니다.

마킹 카테고리를 생성할 때, 카테고리 가시성을 설정하고 카테고리 권한을 할당할 수 있습니다. 기본적으로 카테고리 작성자는 관리자가 됩니다. 작성자는 자신을 작성자에서 제거하고 다른 관리자를 추가할 수 있습니다.

카테고리 가시성

마킹 가시성은 카테고리별로 할당되며, 그룹 카테고리는 예외입니다. 각 그룹은 자체 가시성 설정을 가지고 있습니다.

대부분의 경우, 마킹과 카테고리의 이름 및 설명은 민감한 정보가 아니며, 마킹 접근 권한이 없는 사용자에게도 보여야 합니다. 이 동작은 기본적으로 Visible로 설정된 카테고리 가시성에 의해 결정됩니다.

카테고리 가시성이 Visible로 설정된 경우, 그룹 내 모든 사용자는 마킹 인터페이스에서 카테고리와 그 마킹의 존재를 볼 수 있습니다. 사용자가 마킹 권한을 충족하지 못하면 마킹이나 카테고리의 존재를 볼 수 없습니다.

마킹 카테고리 가시성이 Hidden으로 설정된 경우, 이 카테고리와 그 마킹의 존재는 민감한 정보로 간주됩니다. Hidden 카테고리는 Category Viewer 권한이 명시적으로 부여되지 않은 모든 사용자에게 보이지 않게 할 수 있습니다.

마킹 카테고리는 다음과 같은 가시성 규칙을 보장합니다:

• 가시성은 카테고리와 그 모든 마킹에 대해 함께 정의되며, 개별 마킹별로 할당할 수 없습니다.
• 마킹에 접근할 수 있는 모든 사용자는 카테고리와 그 안의 모든 마킹의 존재를 볼 수 있습니다. 이 사용자들은 API 결과에 "category viewers"로 나타나지 않지만 가정해야 합니다.
• 마킹에 역할(관리자, 제거자)이 있는 모든 사용자는 카테고리와 그 안의 모든 마킹의 존재를 볼 수 있습니다. 이 사용자들은 API 결과에 "category viewers"로 나타나지 않지만 가정해야 합니다.
• 카테고리에 역할(관리자, 뷰어)이 있는 모든 사용자는 카테고리와 그 안의 모든 마킹의 존재를 볼 수 있습니다.

카테고리 권한

사용자는 마킹 카테고리와 상호작용하는 방식을 지정하는 권한을 가질 수 있습니다:

• 카테고리 관리자: 카테고리의 설명과 권한을 변경하고 카테고리에 마킹을 생성할 수 있는 사용자.
• 카테고리 뷰어: 카테고리와 그 안의 모든 마킹의 존재를 볼 수 있는 사용자.

그룹별 카테고리 제한

마킹 카테고리는 단일 그룹에 제한되어 해당 그룹 외부의 사용자에게는 절대 보이지 않도록 할 수 있습니다.

마킹 생성

필요한 권한을 가진 관리자 사용자는 플랫폼 설정의 마킹 섹션에서 새 마킹 버튼을 클릭하여 새로운 마킹을 생성할 수 있습니다. 그런 다음 마킹 관리자와 마킹 제거자를 할당할 수 있습니다.

Foundry 내에서 마킹을 생성할 때, 자동으로 "Manage permissions" 접근 권한이 부여됩니다. 새로운 마킹에 대해 다른 팀원들에게 이 권한을 할당하는 것을 권장합니다. 이렇게 하면 모든 마킹 권한 관리를 단일 관리자에게 의존하지 않을 수 있습니다.

마킹 권한

새로운 마킹을 생성할 때, 다양한 수준의 접근 및 권한을 가진 사용자와 그룹을 추가할 수 있습니다:

• Manage permissions: 이 마킹, 그 멤버 및 메타데이터를 관리할 권한을 부여할 수 있는 사용자.
• Apply marking: 이 마킹을 프로젝트 및 리소스에 적용할 수 있는 사용자. 이 권한은 마킹을 적용할 수 있는 능력만 부여하며, 마킹의 멤버십을 부여하지 않습니다.
• Remove marking: 이 마킹을 프로젝트 및 리소스에서 제거할 수 있는 사용자. 마킹을 제거하려면 사용자가 마킹을 적용할 수 있어야 합니다.
• Members: 이 마킹으로 보호된 리소스와 프로젝트를 볼 수 있는 사용자.

위의 모든 권한은 별개이며 자동으로 사용자에게 멤버십 권한을 제공하지 않습니다. 예를 들어, 사용자가 마킹에 대해 “Apply marking” 및 "Manage permissions" 접근 권한을 가질 수 있지만 마킹의 멤버가 아닐 수 있습니다. 이 경우, 사용자는 플랫폼의 파일, 폴더 및 프로젝트에 마킹을 적용하고 마킹을 관리할 수 있지만, 해당 마킹으로 표시된 데이터를 볼 수는 없습니다.

사용자에게 마킹 부여

마킹은 사용자에게 전역적으로 부여됩니다. 사용자가 마킹을 부여받으면, 해당 마킹으로 제한된 콘텐츠 유형을 전역적으로 볼 수 있는 권한이 부여됩니다. 그러나 마킹에 접근할 수 있다고 해서 사용자가 해당 마킹이 있는 모든 콘텐츠를 볼 수 있는 것은 아닙니다. 사용자는 여전히 자신의 역할을 통해 권한을 가져야 합니다. 사용자는 추가적인 관리 권한이 없는 한 다른 사용자에게 마킹 접근 권한을 부여할 수 없습니다.

마킹 권한이 그룹에 부여된 경우, 그룹의 새로운 사용자는 해당 권한을 상속받습니다.

마킹 적용

리소스, 폴더, 또는 프로젝트에 마킹을 적용하려면 두 가지 요구 사항을 충족해야 합니다:

1. 마킹에 대한 “Apply marking” 권한이 있어야 합니다.
2. 기본적으로 소유자 역할에 포함된 “Update Markings on resource” 권한이 있어야 합니다.

마킹을 적용하는 것은 민감한 작업이며, 다운스트림 사용자를 제한할 수 있습니다. 기존 파이프라인에 마킹을 적용하기 전에 다음 단계를 따르는 것이 좋습니다:

1. 마킹의 존재 확인: 적용하려는 마킹이 생성되었는지 확인하거나 마킹 생성을 진행합니다.
2. 파이프라인의 브랜치 생성: 이러한 단계를 계속하기 위해 새 브랜치를 생성합니다. 기존 파이프라인에 마킹을 적용할 때, 파이프라인의 어느 시점에서 마킹의 전파를 중단해야 할 수 있습니다 (예: PII가 제거된 데이터셋이 최종 사용자에게 열릴 수 있도록). stop_propagating 구문은 보호된 브랜치에서만 효과가 있습니다. 새 브랜치가 보호된 브랜치에 병합될 때까지 상속된 마킹을 stop_propagating할 수 없습니다.
3. Data Lineage 검토: Data Lineage 그래프에서 노드의 전체 세트를 확인하고 잠재적 변경의 다운스트림 영향을 이해했는지 확인합니다.
4. 파이프라인의 트랜잭션 유형 검토: 마킹은 트랜잭션 수준에서 데이터 종속성을 따라 전파됩니다. 점진적으로 빌드된 데이터셋(APPEND 또는 UPDATE 유형)은 특별한 처리가 필요합니다. 특히, APPEND 트랜잭션으로 빌드된 데이터셋의 최신 보기에는 이전 업스트림 트랜잭션의 종속성이 포함됩니다. 반면, SNAPSHOT 트랜잭션(Foundry 기본값)으로 빌드된 데이터셋의 최신 보기에는 업스트림 데이터셋의 최신 트랜잭션만 의존합니다. SNAPSHOT 트랜잭션만 다루고 있다면 이 단계를 계속할 수 있습니다. 그렇지 않다면 APPEND 및 UPDATE 트랜잭션 및 마킹 전파 방법에 대한 문서를 참조하세요.
5. 마킹 상속 중단 시점 결정: 파이프라인의 Data Lineage에서 노드를 탐색하고 열 및 데이터 미리보기를 검토하여 적용하려는 마킹의 상속을 중단해야 할 시점을 결정합니다. 예를 들어, 파이프라인에서 DOB(생년월일) 열이 제거되면 PII 마킹의 전파를 중단하고 싶을 수 있습니다. 이 단계에서 시뮬레이션 모드를 활성화하여 마킹이 어디에서 어떻게 전파될지 확인할 수 있습니다.
6. 필요한 변환 변경 사전 준비: 브랜치에서 식별한 변환에 stop_propagating 구문을 추가합니다. 보호된 브랜치에 브랜치를 병합하여 stop_propagating 구문이 활성화되도록 합니다.
7. 프로덕션 파이프라인 빌드: 다운스트림의 모든 변환을 빌드하고, stop_propagating을 식별한 노드를 포함합니다. stop_propagating 구문이 있는 데이터셋과 stop_propagating 변환의 모든 다운스트림 데이터셋을 다시 빌드해야 합니다. 다운스트림에 APPEND 또는 UPDATE 데이터셋이 있는 경우, 이 가이드를 검토하세요.
8. 시뮬레이션된 변경 검토: 파이프라인의 최종 시뮬레이션된 Data Lineage를 검토합니다. stop_propagating 변환의 다운스트림 데이터셋이 새로운 마킹의 적용에 영향을 받지 않는지 확인합니다. 민감한 열이 전파된 마킹을 받지 않을 데이터셋에 나타나지 않는지 확인합니다.
9. 마킹 적용: 위의 단계는 마킹을 적용하면 민감한 데이터를 포함한 데이터셋을 보호하고 마킹이 필요한 범위를 넘어 전파되지 않도록 해야 합니다. 이 시점에서 마킹을 적용할 수 있습니다.

아래 예시에서는 DOB 열이 제거되고 stop_propagating 구문이 온톨로지 passengers 데이터셋에 적용되었습니다. PII 마킹은 원본 passenger 데이터셋에 적용되었고, 클린 passenger 데이터셋에만 전파되었습니다.

마킹 제거

마킹을 제거하여 더 많은 사용자에게 접근을 허용하거나, 변환된 데이터를 재분류하거나, 상속된 마킹에서 파생된 리소스를 분리할 수 있습니다.

예를 들어, 데이터셋 A가 PII를 포함하고 마킹이 데이터셋 A에서 파생된 데이터셋을 보호하는 경우를 가정합니다. 데이터셋 B가 데이터셋 A에서 파생되었지만 PII가 제거되도록 변환된 경우, 데이터셋 B에서 마킹을 제거하여 데이터를 더 널리 사용할 수 있도록 할 수 있습니다.

마킹을 제거하려면 특정 마킹을 적용하고 제거할 권한이 있어야 합니다. 또한, 관심 있는 리소스에 접근할 수 있는 역할을 통해 마킹을 변경할 수 있어야 합니다. 기본 역할을 사용하는 경우, 이 접근은 Owner 역할로 가능합니다.

직접 적용된 마킹 제거

파일, 폴더, 또는 프로젝트에서 직접 마킹을 제거하면, 마킹을 상속받은 모든 종속성에서 즉시 마킹이 제거됩니다. 직접 마킹을 제거한 후에는 다운스트림 데이터셋을 다시 빌드할 필요가 없습니다. 마킹이 즉시 다운스트림에서 제거되기 때문입니다. 다음 개념적 예시는 직접 적용된 PII 마킹을 보여줍니다.

상속된 마킹 제거

상속된 마킹은 제한된 뷰와 데이터셋에서만 제거할 수 있습니다. 파생 파일을 생성할 때 제한된 콘텐츠가 제거되거나 모호해지면, 파생 파일에서 마킹을 제거할 수 있습니다. 상속된 마킹이 제거되면, 다운스트림 데이터셋은 마킹으로 보호되지 않으며 더 많은 사용자가 데이터셋에 접근할 수 있습니다. 사용자는 여전히 상위 데이터에 접근하기 위해 마킹에 접근해야 합니다.

제한된 뷰에서 상속된 마킹을 제거하려면, 제한된 뷰를 편집하고 적절한 마킹 옆의 Stop Propagating을 클릭하세요.

데이터셋에서 상속된 마킹을 제거하려면, 변환 코드에서 stop_propagating 구문을 사용하세요. 상속된 마킹을 안전하게 제거하려면 다음 단계를 따르세요:

1. 민감한 데이터를 제거할 위치 결정: 전체 파이프라인을 검토하고 민감한 데이터를 제거할 위치를 결정합니다.
2. 브랜치 생성: stop_propagating 구문은 보호되고 Require security approvals before merging 설정이 활성화된 브랜치에서만 효과가 있습니다. 브랜치가 보호된 브랜치에 병합될 때까지 상속된 마킹을 stop_propagating할 수 없습니다.
3. 필요한 변환 변경: 선택한 데이터셋에서 민감한 데이터를 제거하고 변환에 stop_propagating 구문을 추가합니다.
4. 브랜치 빌드: 브랜치를 빌드하고 결과 데이터셋에서 민감한 데이터가 제거되었는지 확인합니다. 이 시점에서는 비보호 브랜치에 있으므로 stop_propagating 구문이 마킹 상속을 중단하지 않습니다.
5. 브랜치 병합: 민감한 데이터가 제거되었음을 확인한 후, 변환 변경을 메인 브랜치에 안전하게 병합할 수 있습니다. 브랜치를 병합하면 stop_propagating 구문이 적용됩니다.
6. 메인 브랜치 및 다운스트림 종속성 빌드: stop-propagating 변경은 파이프라인의 최신 트랜잭션을 따라 전파되어야 하며, 이를 위해 stop_propagating 구문이 있는 데이터셋과 stop_propagating 변환의 모든 다운스트림 데이터셋을 다시 빌드해야 합니다. 모든 데이터셋이 빌드되면 상속된 마킹이 제거되었는지 확인합니다. 다운스트림에 APPEND 또는 UPDATE 트랜잭션이 있는 경우, 추가 문서를 검토하세요.

아래 개념적 예시에서는 DOB 열이 제거되고 온톨로지 passengers 데이터셋에 stop_propagating 구문이 적용되어 PII 마킹이 더 이상 다운스트림으로 전파되지 않도록 했습니다.

마킹 상속 조사

마킹은 상속을 통해 파일 계층 구조와 데이터 종속성을 따라 전파됩니다. 이는 파일 자체가 마킹으로 보호될 수 있고/또는 데이터 자체가 마킹으로 보호될 수 있음을 의미합니다. 때로는 마킹이 어디에서 오는지 조사해야 하며, 마킹이 상속될 수 있는 다양한 방법을 개념적으로 이해하는 것이 중요합니다.

파일의 마킹을 보려면 파일을 선택하여 오른쪽 세부 정보 창을 열고 Access requirements > Markings 섹션을 확인하세요.

파일 계층 구조 조사

파일의 마킹을 보려면 파일을 선택하고 리소스 패널을 엽니다. Access 섹션을 확인하세요.

파일 계층 구조를 따라 상속된 마킹은 폴더 사이드카 아이콘으로 표시됩니다.

파일 계층 구조에서 마킹이 시작된 지점을 파악하려면 Foundry 워크스페이스에서 파일 계층 구조를 탐색하세요. 아래 개념적 예시에서는 원본 파일과 폴더 리소스의 파일 계층 구조를 시작점으로 하여 flight data 폴더가 PII 마킹을 가지고 있음을 확인할 수 있습니다. 접근 정보는 리소스 사이드바에 표시됩니다.

데이터 종속성 조사

마킹이 시작된 데이터 종속성을 파악하려면 Data lineage 애플리케이션을 사용하거나 데이터셋 파일을 연 후 Compare 탭을 사용하세요.

마킹은 파일 수준에서 적용되지만 트랜잭션을 따라 전파되므로, 데이터셋에 마킹이 언제 도입되었는지 파악하기 어려울 수 있습니다. 먼저 Data Lineage 애플리케이션을 확인하여 마킹이 어디에서 시작되었는지 확인하는 것이 좋습니다.

Data lineage 애플리케이션을 사용하여 Legend > Permissions type: Data access in datasets를 클릭합니다. 그런 다음 Data Lineage의 모든 업스트림 노드를 확장하고 마킹이 시작된 지점을 파악하기 위해 Data Lineage를 탐색합니다. 데이터 종속성을 따라 상속된 마킹은 Data Lineage 사이드카 아이콘으로 표시됩니다.

아래 예시 스크린샷에서는 employee_sensitive 데이터셋이 PII 마킹이 시작된 곳입니다:

마킹이 언제 도입되었는지에 대한 전체 그림을 얻으려면 관심 있는 파일의 트랜잭션을 확인하세요. 특정 파일을 열고 Compare 탭으로 이동하여 두 브랜치와 타임스탬프의 다른 트랜잭션을 비교하여 시간 경과에 따른 보안 및 논리 변경 사항을 확인하세요.

트랜잭션 비교 도구의 하단에서 논리 및 보안 변경 사항을 볼 수 있으며, 이를 통해 마킹이 정확히 언제 도입되었거나 제거되었는지 파악할 수 있습니다. 아래 예시는 새로운 입력이 추가되어 PII 마킹이 도입된 것을 보여줍니다:

아래 예시는 논리에서 입력이 삭제되어 PII 마킹이 제거된 것을 보여줍니다: