데이터 기반 보안에서 보았듯이, 다양한 프로젝트의 데이터 접근은 프로젝트 소유자에 의해 관리될 수 있습니다. 이것은 임의 접근 제어 ↗로 알려져 있습니다. 그러나 민감한 데이터의 경우 더 강력하고 중앙 집중화된 접근 제어 모델이 필요합니다.
우리의 예시에서는 승객의 생년월일(DOBs)을 포함하는 가상의 데이터셋이 있으며, 이는 개인 식별 정보(PII)를 구성합니다. 우리는 이 PII를 엄격하게 통제하고, 이 데이터를 PII 교육을 받은 사람들만 접근할 수 있도록 하고자 합니다. 이를 해결하기 위해 Markings를 사용할 수 있습니다.
Markings는 Foundry의 강제 접근 제어 ↗ 구현입니다. 마킹은 특정 사용자 또는 그룹 목록이 접근할 수 있는 데이터 유형(예: PII)을 나타냅니다. 데이터셋에 마킹이 적용되면, 해당 마킹에 접근 권한이 없는 사용자는 프로젝트 소유자가 공유하려고 시도하더라도 해당 데이터를 절대 접근할 수 없습니다. 중요하게도, 이 제한은 플랫폼 어디에서든 이 데이터셋에서 파생된 데이터로 전파됩니다.
이 기능은 데이터 거버넌스에 매우 강력하여, 데이터 보호 담당자가 중앙에서 누가 데이터 범주에 접근할 수 있는지를 관리하고 감사할 수 있도록 합니다.
최종 사용자에게 애플리케이션을 소개하기 전에 민감한 데이터를 보호하고자 합니다. 다시 말해, 우리의 예시에서는 데이터 파이프라인에서 승객의 생년월일(DOBs)을 잠그고자 합니다.
마킹 세트의 이름인 마킹 카테고리를 생성해야 합니다. 이 경우, "정보"라는 마킹 카테고리를 생성합니다. 이는 미래에 다른 정보 관련 마킹(예: 개인 건강 정보 또는 PHI)이 필요할 가능성이 있기 때문입니다. 카테고리를 생성한 후, PII 마킹을 생성할 수 있습니다. 그런 다음 PII 데이터를 볼 수 있는 권한이 있는 사람들을 마킹의 멤버로 추가하고, 관리자 팀을 마킹의 관리자(매니저)로 추가할 수 있습니다.
마킹은 Data Lineage를 따라 전파되는 강력한 특성을 가지고 있습니다. 따라서 기존 파이프라인에 새로운 마킹을 적용하면 다운스트림 사용자가 예기치 않게 잠길 위험이 있으므로, 항상 파이프라인에 마킹을 적용하여 어디로 전파되는지 확인하는 것이 최선의 방법입니다. 이를 위해 파이프라인의 Data Lineage를 열고 시뮬레이션 모드를 켭니다. raw/passengers 데이터셋에서 마킹을 편집하고 생성한 PII 마킹을 적용할 수 있습니다. 그러면 PII 마킹이 적용될 때 영향을 받는 모든 다운스트림 데이터셋을 볼 수 있습니다.
우리의 데이터 소비자 모두가 PII 접근 권한을 가질 필요는 없으므로, 파이프라인의 어느 시점에서 민감한 DOB 열을 제거하고자 합니다. 이를 위해 파이프라인을 클릭하여, PII 마킹을 제거하는 것이 가장 적합한 위치를 검토해야 합니다. 일반적으로 데이터셋을 선택할 때 하단의 미리보기 보기를 열어 데이터를 보고 열을 확인하는 방식으로 수행됩니다.
우리의 가상 예시에서는 PII 마킹이 온톨로지 데이터셋까지 전파되어, PII에 접근할 수 없는 모든 최종 사용자가 잠기게 됩니다. 따라서 민감한 데이터를 가능한 한 파이프라인에 유지하되, 승객 데이터의 온톨로지 버전에서 "dob" 열을 제거하는 것이 최선이라고 결정했습니다 (즉, /Sky Industries/Customer Metrics [Ontology]/passengers).
Data Lineage 보기에서 Customer Metrics [Ontology]/passengers 데이터셋을 클릭하고, 코드에서 저장소에서 보기를 클릭합니다. 이는 이 가상 데이터셋을 생성하는 데 사용된 코드 저장소를 엽니다. 코드 저장소에서 1) 브랜치를 생성하고, 2) 민감한 열(즉, dob
열)을 제거하고, 3) 입력 데이터셋에서 곧 상속될 PII 마킹을 제거한 다음, 4) 풀 리퀘스트를 생성합니다. 상속된 마킹 및 조직 제거에 대한 문서를 검토하는 것을 권장합니다.
동료가 PII 마킹 전파를 중단하는 풀 리퀘스트를 승인한 후, 이 데이터셋과 그 아래의 모든 것을 빌드하여 최신 데이터셋 트랜잭션이 곧 추가될 마킹을 모두 "전파 중단"하도록 해야 합니다. 또한 APPEND 또는 UPDATE 트랜잭션 유형에는 특별한 주의가 필요합니다. 그러나 우리의 예시에서는 모든 것이 Foundry의 기본 트랜잭션 유형인 SNAPSHOT으로 빌드되고 있습니다.
마킹을 적용하기 전에, 예상한 데이터셋에만 전파되고 다른 곳에는 전파되지 않는지 다시 확인하고자 합니다. 이를 위해 파이프라인의 Data Lineage 보기를 다시 열고, 시뮬레이션 모드를 켜고, raw/passenger 데이터셋에 마킹을 적용하고, ontology/passenger 데이터셋이 영향을 받지 않는지 확인합니다. 이는 이전 섹션의 stop_propagating 논리가 올바르게 적용되었음을 의미합니다.
이제 마킹을 적용할 준비가 되었습니다. 이를 위해, raw/passenger 데이터셋으로 이동하여 보안 도우미를 열고 마킹을 적용합니다. 저장을 클릭하면 PII 마킹이 즉시 적용되고 즉시 다운스트림으로 전파됩니다. Data Lineage를 보고 이제 마킹이 있는 데이터셋에 마킹 배지가 있는 것을 볼 수 있습니다. 민감한 PII 데이터를 성공적으로 보호했습니다.