오픈 레이크하우스에서 엔진 및 카탈로그 전반의 거버넌스 통합

이전 포스트에서는 개방형 테이블 포맷, 개방형 API, 통합 거버넌스가 어떻게 결합하여 오픈 레이크하우스 비전을 완성하는지 보여드렸습니다. 또한 외부 엔진이 거버넌스 대상 데이터에 액세스할 때 Unity Catalog에 정의된 정책을 일관되게 적용할 수 있도록 지원하는 교차 엔진 속성 기반 액세스 제어(cross-engine attribute-based access control)를 소개해 드렸습니다.

이제 그 비전이 오픈 소스 생태계에서 구체화되기 시작했습니다. 최근 Apache Iceberg™ 커뮤니티는 Iceberg REST Catalog에 두 가지 중요한 기능인 읽기 제한(read restrictions)과 카탈로그 레이블(catalog labels)을 추가했습니다. 이 두 기능은 외부 엔진에 권한 적용을 위임하는 것과 여러 카탈로그 간에 거버넌스 컨텍스트를 이식 가능하게 만드는 것이라는 두 가지 고유한 과제를 해결합니다.

본 포스트에서는 이 사양(spec)에 새로 추가된 두 가지 기능을 작동 방식, 해결해야 할 주요 과제, 향후 혁신 기회, 사용 시기 등 다각도로 자세히 살펴보겠습니다.

읽기 제한: 위임된 권한 적용의 표준화

읽기 제한은 조직이 하나의 카탈로그에서 데이터를 관리하고 다양한 엔진이나 도구에서 이를 쿼리하려는 일반적인 엔진-카탈로그 시나리오를 해결합니다.

거버넌스가 적용된 모든 쿼리에 대해 다음 세 가지 작업이 수행되어야 합니다.

1. 카탈로그가 요청하는 ID와 주체, 그룹, 역할 또는 '지역'과 같은 ID 속성을 포함한 관련 컨텍스트를 수신합니다.
2. 정책을 평가하여 사용자가 테이블을 읽을 수 있는지 여부와 적용할 행 필터 또는 열 마스크를 결정합니다.
3. 데이터를 읽을 때 신뢰할 수 있는 컴퓨팅 레이어가 해당 결정을 적용합니다.

엔진에서 데이터에 액세스할 때 이러한 역할은 두 가지 방식으로 나눌 수 있습니다.

중앙 집중식 권한 적용(centralized enforcement)을 사용하면 세 단계가 모두 카탈로그 환경 내에서 유지됩니다. 예를 들어, Databricks는 보안 필터링 플릿을 통해 쿼리를 투명하게 라우팅함으로써 전용 컴퓨팅에서 세분화된 액세스 제어를 구현합니다. 그리고 Unity Catalog의 교차 엔진 ABAC(Cross-engine ABAC) 기능은 필터링 플릿을 Iceberg REST catalog scan/plan API 뒤에 배치하여 Spark¹이나 DuckDB와 같은 외부 엔진이 결과를 처리하기 전에 데이터를 정제함으로써 이러한 거버넌스를 다른 엔진으로 확장합니다.

위임된 권한 적용(delegated enforcement)을 사용하면 카탈로그가 요청하는 ID를 수신하고 정책을 평가한 다음, 결과로 생성된 행 및 열 제한 사항을 이를 적용할 수 있다고 신뢰하는 엔진에 반환합니다. 여기서 신뢰란 카탈로그가 엔진을 믿고 제한 사항을 적용하여 사용자가 이를 우회하지 못하도록 방지할 수 있음을 의미합니다. 사용자가 런타임을 제어하는 경우 Spark 및 DuckDB와 같은 엔진은 사용자가 임의의 코드를 실행하거나 기본 데이터에 직접 액세스할 수 있기 때문에 신뢰할 수 없는 엔진으로 분류됩니다. 안전하게 구성된 Trino 배포는 행 필터 및 열 마스크에 대한 기본 권한 적용을 제공하므로 신뢰할 수 있는 엔진의 예입니다.

위임된 권한 적용을 위해서는 카탈로그와 엔진 간의 공통 계약이 필요합니다. Iceberg 커뮤니티는 이러한 계약을 제공하기 위해 읽기 제한(read restrictions)을 도입했습니다.

읽기 제한 작동 방식

독자가 Iceberg REST Catalog를 통해 테이블을 로드하면 카탈로그는 요청하는 주체(principal) 및 요청 컨텍스트에 적용 가능한 정책을 평가합니다. 카탈로그는 필요한 열 프로젝션 작업과 행 필터 표현식을 반환할 수 있으며, 신뢰할 수 있는 엔진은 테이블을 읽을 때 이러한 제한 사항을 적용해야 합니다.

제안된 기능의 현재 범위를 이해하려면 두 가지 설계 결정 사항을 파악하는 것이 중요합니다.

첫째, 엔진은 관리자가 정의한 정책을 그대로 수신하지 않습니다. 대신 특정 주체에 대한 결과(적용해야 하는 필터링 또는 마스킹 지침으로 표현됨)를 수신합니다. 이를 통해 엔진과 카탈로그 사이에 공통된 권한 적용 계약이 생성됩니다. 초기 사양은 제한된 어휘를 정의합니다. 즉, 사전에 정의된 9가지 열 프로젝션 작업과 표준화된 행 필터 표현식(비교 또는 세트 멤버십 등)입니다. 실제 기업의 많은 정책은 하위 쿼리, 조회 테이블 또는 사용자 정의 UDF에 의존하므로 읽기 제한 어휘 내에서 표현할 수 없습니다. 이는 중요한 시사점을 가집니다. 즉, 카탈로그가 정책 결과를 표준에 정의된 어휘로 축소할 수 있는 경우에만 정책을 표현할 수 있으며, 그렇지 않으면 정책 의미 체계(semantics)가 손실됩니다.

둘째, 사양은 신뢰할 수 있는 엔진이 적용해야 하는 사항을 정의하지만, 카탈로그가 해당 신뢰를 구축하는 방법은 정의하지 않습니다. 클라이언트의 주장만으로는 충분하지 않으므로 시스템 관리자와 구현체는 해당 환경에 적합한 보안 메커니즘을 사용해야 합니다. Iceberg 커뮤니티 토론에서는 mTLS 및 OAuth와 같은 메커니즘을 고려했지만, 신뢰는 궁극적으로 프로토콜 외부의 영역으로 남아 있습니다(Iceberg 커뮤니티 토론). 

읽기 제한은 소스 카탈로그의 정책이 단순하고 신뢰할 수 있는 엔진이 결과 결정을 적용할 수 있는 직접적인 엔진-카탈로그 액세스 시나리오에 가장 적합합니다. 엔진이 최종 사용자의 ID와 속성을 안전하게 전파하는 방법, 카탈로그가 사용자와 사용자를 대신하여 작동하는 엔진을 구별하는 방법, 자격 증명이 의도된 수신자에게 바인딩되는 방법 등 많은 구현상의 질문이 아직 남아 있습니다. 구현체가 등장함에 따라 Iceberg 커뮤니티와 협력하여 이러한 과제를 해결하고 표준을 발전시켜 나갈 수 있기를 기대합니다.

카탈로그 레이블: 거버넌스 컨텍스트의 이식성 확보

카탈로그 레이블은 연동된 카탈로그(federated catalogs) 전반의 거버넌스라는 다른 시나리오를 해결합니다.

오늘날 많은 기업이 연동 및 개방형 API를 통해 Unity Catalog, Snowflake, AWS Lake Formation, Google Cloud Knowledge Catalog 등 여러 카탈로그를 연결하고 있습니다. 이는 각 카탈로그가 고유한 ID 모델, 정책 언어 및 의미 체계를 통해 자체 사용자, 애플리케이션 및 엔진을 지원하기 때문에 엔진-카탈로그 통합보다 더 복잡합니다.

엔터프라이즈 규모에서 작동하는 통합 거버넌스 솔루션은 반드시 다음을 수행해야 합니다.

• 정책 표현력 유지. 고객은 속성 기반 정책 및 복잡한 하위 쿼리를 포함한 정교한 규칙을 정의하고, 이를 이기종 시스템 전반에 걸쳐 일관되게 적용할 수 있어야 합니다.
• 명확한 감사 가능성 및 책임성 제공. 각 카탈로그는 관리자가 여러 시스템에서 감사 추적을 조정할 필요 없이 독립적으로 규정 준수를 입증할 수 있어야 합니다.
• 핵심 경로에 다른 카탈로그 서비스를 추가하지 않고 확장. 카탈로그 A의 권한 인식 검색 시 모든 사용자 및 자산에 대해 카탈로그 B를 호출할 필요가 없어야 합니다. 예를 들어, Unity Catalog의 대부분의 사용자 경험은 권한을 인식하며, 카탈로그 탐색기를 로드하거나 자동 완성 검색을 제공할 때 사용자별로 수천 개의 결정을 내려야 할 수 있습니다. 이러한 결정은 캐시하기 어렵기 때문에, 사용자 경험이 느려지고 성능과 가용성이 다른 서비스에 종속되게 만듭니다.

최근 Iceberg 커뮤니티에서 채택한 카탈로그 레이블은 이러한 비전을 향한 첫 걸음입니다. 레이블을 사용하면 카탈로그가 Open API를 통해 테이블 및 열 수준에서 경량 키-값 메타데이터를 교환할 수 있습니다. 레이블은 필드에 PII가 포함되어 있음을 나타내거나, 데이터 세트를 비즈니스 도메인과 연결하거나, AI 모델에 대한 의미론적 힌트를 제공할 수 있습니다. 이 제안은 범용적이기 때문에 레이블은 액세스 제어를 넘어 검색, 소유권, 비용 귀속, AI 컨텍스트, 데이터 품질을 포함한 많은 사용 사례를 지원할 수 있습니다.

카탈로그 레이블 작동 방식

소비 카탈로그가 카탈로그 페더레이션을 통해 제공 카탈로그로부터 테이블을 로드할 때, 제공 카탈로그는 테이블 및 열 수준의 레이블을 반환합니다. 

그런 다음 소비 카탈로그는 레이블을 자체 분류, 속성 또는 네이티브 태그 모델에 매핑합니다. 그런 다음 자체 네이티브 ID 및 정책을 사용하여 액세스를 평가하고 자체 런타임 내에서 제어를 적용합니다. 예를 들어, 제공 카탈로그가 ssn 열을 pii=ssn으로 레이블 지정하는 경우, 소비 카탈로그는 해당 레이블이 있는 열을 마스킹하는 태그 기반 정책을 적용할 수 있습니다.

정책 적용이 로컬에서 유지되므로 소비 카탈로그는 네이티브 정책의 표현력을 보존하고 각 액세스 결정에 대해 제공 카탈로그를 호출하지 않아도 됩니다. 또한 각 카탈로그는 적용 기록과 감사 추적을 독립적으로 유지 관리합니다.

레이블은 불투명한 키-값 쌍이라는 점을 염두에 두어야 합니다. 표준은 공유된 의미 체계나 안정적인 식별자를 정의하지 않으며, 레이블의 계보(lineage)는 소스 카탈로그를 벗어나 확장되지 않습니다. 소비 카탈로그는 확인된 키와 값만 수신하며, 레이블이 검색, 액세스 제어, 비용 귀속 또는 다른 목적으로 사용되도록 의도되었는지 여부는 수신하지 않습니다. 따라서 레이블은 메타데이터를 이식 가능하게 만들지만 그 의미까지 이식하는 것은 아닙니다. 기업은 레이블을 일관되게 해석하기 위해 여전히 공유된 규칙이나 명시적인 매핑이 필요합니다.

카탈로그 레이블은 소비 카탈로그가 자체 거버넌스 시스템을 가지고 있고 모든 사용자 및 요청에 대해 별도의 액세스 결정을 내리는 대신 재사용 가능한 컨텍스트가 필요한 이기종 시스템 간의 페더레이션이 있는 카탈로그 간 시나리오에 가장 적합합니다. 핵심 아이디어는 테이블 메타데이터와 마찬가지로 거버넌스 및 비즈니스 컨텍스트가 Iceberg REST Catalog API를 통해 개방되고 이식 가능해야 한다는 것입니다.

올바른 모델 선택하기

올바른 모델은 대상에 따라 다릅니다. 신뢰할 수 없는 엔진의 경우 중앙 집중식 적용, 신뢰할 수 있는 엔진의 경우 읽기 제한, 대상이 자체 거버넌스 시스템을 가진 다른 카탈로그인 경우 개방형 메타데이터 교환을 위한 카탈로그 레이블이 적합합니다.

다음 단계

읽기 제한과 카탈로그 레이블은 크로스 플랫폼 거버넌스에서 서로 다르고 중요한 두 가지 문제를 해결합니다. 읽기 제한은 카탈로그가 신뢰할 수 있는 엔진에 강제 적용을 위임할 수 있는 표준 방식을 제공합니다. 카탈로그 레이블은 데이터와 마찬가지로 거버넌스 및 비즈니스 컨텍스트를 여러 카탈로그 간에 이식할 수 있도록 지원합니다. Cross-Engine ABAC를 통한 중앙 집중식 강제 적용과 더불어, 이를 통해 기업은 여러 엔진과 카탈로그 전반에서 데이터를 일관되게 제어할 수 있는 실용적인 옵션을 확보할 수 있습니다.

두 제안을 모두 채택한 Apache Iceberg 커뮤니티에 축하를 전합니다. 아직 해야 할 일이 더 많지만, 이는 중요한 이정표입니다. 더 많은 에코시스템이 이러한 기본 빌딩 블록을 채택하는 모습을 기대하며, 오픈 레이크하우스 전반에서 통합 거버넌스를 실현하기 위해 커뮤니티와 계속 협력해 나가기를 바랍니다.

¹Apache Spark 자체 보안 지침에서는 사용자가 제출한 코드가 동작에 제한 없이 실행되며 사용자가 애플리케이션에 할당된 리소스를 제어할 수 있다고 명시하고 있습니다. Spark 확장은 읽기 제한을 구현할 수 있지만, 세분화된 액세스 제어 API는 고사하고 테이블 수준의 액세스 제어 API도 없기 때문에 관리자가 런타임을 제어하고 강제 적용을 우회하는 모든 경로를 제거해야만 배포를 신뢰할 수 있는 것으로 간주할 수 있습니다(Iceberg 커뮤니티 토론).

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)