オープンレイクハウスにおける、エンジンとカタログを横断したガバナンスの統合

前回の記事では、オープンなテーブルフォーマット、オープンなAPI、そして統合されたガバナンスがどのように連携して、 Open Lakehouseのビジョンを実現するかをご紹介しました。また、Unity Catalogで定義されたポリシーを、外部エンジンがガバナンス対象データにアクセスする際に一貫して適用できるようにする、 エンジン間での属性ベースのアクセス制御（ABAC）についても紹介しました。

現在、そのビジョンはオープンな環境で具体化し始めています。Apache Iceberg™コミュニティは最近、Iceberg REST Catalogに対する2つの重要な追加機能を進めました。それが読み取り制限（read restrictions）とカタログラベル（catalog labels）です。これらは連携して、外部エンジンへのポリシー適用の委譲と、カタログ間でのガバナンスコンテキストのポータビリティの確保という、2つの異なる課題に対処します。

本記事では、仕様に追加されたこれら2つの新機能について、その仕組み、解決する主な課題、今後のイノベーションの機会、そしてどのような場合に使用すべきかについて詳しく解説します。

読み取り制限：委譲されたポリシー適用の標準化

読み取り制限は、組織が1つのカタログでデータを管理し、さまざまなエンジンやツールからそのデータをクエリしたいという、一般的な「エンジンからカタログへのアクセス」シナリオに対応します。

ガバナンス対象のクエリを実行するには、次の3つのプロセスが必要です。

1. カタログが、リクエスト元のアイデンティティと、サブジェクト、グループ、ロール、さらには「リージョン」などのアイデンティティ属性を含む関連コンテキストを受け取ります。
2. カタログがポリシーを評価し、ユーザーがテーブルを読み取れるかどうか、またどの行フィルターや列マスクを適用すべきかを決定します。
3. データが読み取られる際に、信頼されたコンピュートレイヤーがその決定を適用します。

エンジンからデータにアクセスする場合、これらの役割は2つの方法で分担できます。

一元化されたポリシー適用（centralized enforcement）では、3つのステップすべてがカタログの環境内で行われます。たとえば、Databricksは、安全なフィルタリングフリートを介して透過的にクエリをルーティングすることにより、専用コンピュート上で細かい粒度のアクセス制御を実装しています。そして、Unity Catalogの Cross-engine ABAC機能は、フィルタリングフリートをIceberg REST catalog of scan/plan APIの背後に配置することで、このガバナンスを他のエンジンにも拡張します。これにより、Apache Spark¹やDuckDBなどの外部エンジンが結果を処理する前にデータをサニタイズします。

一方、委譲されたポリシー適用（delegated enforcement）では、カタログがリクエスト元のアイデンティティを受け取ってポリシーを評価し、その結果得られた行および列の制限を、その適用を信頼するエンジンに返します。ここでの「信頼」とは、カタログがそのエンジンを信頼して制限を適用し、ユーザーがそれをバイパスするのを防ぐことができることを意味します。ユーザーがランタイムを制御できる場合、Apache SparkやDuckDBなどのエンジンは信頼されません。ユーザーが任意のコードを実行したり、基盤となるデータに直接アクセスしたりできるためです。安全に構成されたTrinoのデプロイは、行フィルターや列マスクのネイティブな適用を提供するため、信頼されたエンジンの好例です。

委譲されたポリシー適用には、カタログとエンジンの間の共通の契約が必要です。Icebergコミュニティは、その契約を提供するために読み取り制限（read restrictions）を採用しました。

読み取り制限の仕組み

リーダーがIceberg REST Catalogを介してテーブルをロードすると、カタログはリクエスト元のプリンシパルとリクエストコンテキストに適用可能なポリシーを評価します。カタログは、必要な列プロジェクションアクションと行フィルター式を返すことができ、信頼されたエンジンはテーブルを読み取る際にそれらの制限を適用しなければなりません。

この提案の現在の範囲を理解する上で、2つの設計上の決定が重要です。

第一に、エンジンは管理者が定義した通りのポリシーを受け取るわけではありません。 代わりに、特定のプリンシパルに対する結果を、適用すべきフィルタリングまたはマスキングの指示として受け取ります。これにより、エンジンとカタログの間に共通の適用契約が作成されます。初期の仕様では、限定されたボキャブラリが定義されています。具体的には、 事前に定義された9つの列プロジェクションアクションと、 標準化された行フィルター式（比較やセットメンバーシップなど）です。実際の企業のポリシーの多くは、サブクエリ、ルックアップテーブル、またはカスタムUDFに依存していますが、これらは読み取り制限のボキャブラリ内では表現できません。これには重要な意味があります。ポリシーを表現できるのは、カタログがその結果を標準で定義されたボキャブラリに還元できる場合に限られ、そうでない場合はポリシーのセマンティクスが失われます。

第二に、仕様は信頼されたエンジンが適用しなければならない事項を定義していますが、カタログがどのようにその信頼を確立するかは定義していません。 クライアントからの主張だけでは不十分であるため、システム管理者や実装は、それぞれの環境に適したセキュリティメカニズムを使用する必要があります。Icebergコミュニティの議論では、mTLSやOAuthなどのメカニズムが検討されてきましたが、信頼の確立は最終的にプロトコルの範囲外となります（Icebergコミュニティの議論）。 

読み取り制限は、ソースカタログのポリシーがシンプルで、信頼されたエンジンがその結果の決定を適用できるような、直接的な「エンジンからカタログへのアクセス」シナリオに最適です。エンジンがエンドユーザーのアイデンティティや属性を安全に伝播する方法、カタログがユーザーとユーザーに代わって動作するエンジンを区別する方法、資格情報が意図した受信者にどのようにバインドされるかなど、多くの実装上の疑問が残されています。実装が登場するにつれて、私たちはIcebergコミュニティと協力してこれらの課題に取り組み、標準を進化させていくことを楽しみにしています。

カタログラベル：ガバナンスコンテキストのポータビリティの確保

カタログラベルは、別のシナリオである「フェデレーションカタログ間のガバナンス」に対応します。

現在、多くの企業が、フェデレーションやオープンなAPIを介して、Unity Catalog、Snowflake、AWS Lake Formation、Google Cloud Knowledge Catalogなどの複数のカタログを接続しています。これは、各カタログが異なるアイデンティティモデル、ポリシー言語、およびセマンティクスを介して、独自のユーザー、アプリケーション、およびエンジンに対応するため、エンジンからカタログへの統合よりも複雑です。

エンタープライズ規模で機能する統合ガバナンスソリューションは、以下の要件を満たす必要があります。

• ポリシーの表現力を維持する。お客様は、属性ベースのポリシーや複雑なサブクエリを含む高度なルールを定義し、それらを異種システム間で一貫して適用できる必要があります。
• 明確な監査可能性と説明責任を提供する。各カタログは、管理者が複数のシステム間で監査証跡を照合することなく、単独でコンプライアンスを証明できる必要があります。
• 別のカタログサービスをクリティカルパスに配置することなくスケールする。カタログAでの権限を考慮した検出において、すべてのユーザーやアセットに対してカタログBを呼び出す必要があってはなりません。例えば、Unity Catalogにおけるほとんどのユーザー体験は権限を考慮したものであり、カタログエクスプローラーの読み込みや予測入力（タイポヘッド）検索の提供には、ユーザーごとに数千もの判断が必要になる場合があります。これらは キャッシュが難しいため、ユーザー体験が遅くなり、パフォーマンスと可用性が別のサービスに依存することになります。

最近Icebergコミュニティに採用されたカタログラベルは、このビジョンに向けた第一歩です。ラベルを使用すると、カタログはOpen APIを介して、テーブルおよび列レベルで軽量なキー値メタデータを交換できます。ラベルは、フィールドにPIIが含まれていることを示したり、データセットをビジネスドメインに関連付けたり、AIモデルにセマンティックなヒントを提供したりできます。この提案は汎用的であるため、ラベルはアクセス制御にとどまらず、検出、所有権、コスト配分、AIコンテキスト、データ品質など、多くのユースケースをサポートできます。

カタログラベルの仕組み

コンシューマー側のカタログがカタログフェデレーションを介してプロデューサー側のカタログからテーブルを読み込むと、プロデューサー側のカタログはテーブルおよび列レベルのラベルを返します。 

次に、コンシューマー側のカタログは、ラベルを独自の分類、属性、またはネイティブのタグモデルにマッピングします。その後、ネイティブのアイデンティティとポリシーを使用してアクセスを評価し、独自のランタイム内で制御を適用します。例えば、プロデューサー側のカタログがssn列にpii=ssnというラベルを付けている場合、コンシューマー側のカタログは、そのラベルを持つ列をマスクするタグベースのポリシーを適用できます。

ポリシーの適用はローカルで行われるため、コンシューマー側のカタログはネイティブポリシーの表現力を維持し、アクセス判断のたびにプロデューサー側のカタログを呼び出す必要がなくなります。また、各カタログは適用記録と監査証跡を個別に維持します。

ラベルは不透明なキー値ペアであることに留意する必要があります。標準では共有セマンティクスや安定した識別子は定義されておらず、ラベルのリネージはソースカタログの範囲を超えません。コンシューマー側のカタログは、解決されたキーと値のみを受け取り、そのラベルが検出、アクセス制御、コスト配分、またはその他の目的を意図したものかどうかは受け取りません。したがって、ラベルによってメタデータのポータビリティは向上しますが、その意味までは引き継がれません。企業がラベルを一貫して解釈するには、依然として共有の規約や明示的なマッピングが必要です。

カタログラベルは、異種システム間でフェデレーションを行うカタログ間シナリオに最適です。このシナリオでは、コンシューマー側のカタログが独自のガバナンスシステムを持ち、ユーザーやリクエストごとの個別のアクセス判断ではなく、再利用可能なコンテキストを必要とします。核心となる考え方は、テーブルメタデータと同様に、ガバナンスとビジネスコンテキストもIceberg REST Catalog APIを通じてオープンでポータブルであるべきだということです。

適切なモデルの選択

適切なモデルは、宛先によって異なります。信頼できないエンジンの場合は「中央集権的な適用」、信頼できるエンジンの場合は「読み取り制限」、宛先が独自のガバナンスシステムを持つ別のカタログである場合はオープンなメタデータ交換のための「カタログラベル」となります。

今後の展望

読み取り制限とカタログラベルは、クロスプラットフォームガバナンスにおける2つの異なる重要な課題を解決します。読み取り制限により、カタログは信頼できるエンジンに制御の適用を委任する標準的な方法を得ることができます。カタログラベルは、データと同様に、ガバナンスとビジネスコンテキストをカタログ間でポータブルにします。 Cross-Engine ABACによる一元化された制御の適用と組み合わせることで、これらは企業に対して、エンジンやカタログ全体で一貫してデータを管理するための実用的な選択肢を提供します。

両方の提案を採用したApache Icebergコミュニティにお祝いを申し上げます。今後もさらなる取り組みが必要ですが、これは大きなマイルストーンです。より多くのエコシステムがこれらの基盤となるビルディングブロックを採用すること、そしてオープンなレイクハウス全体で統合されたガバナンスを実現するためにコミュニティと協力し続けることを楽しみにしています。

¹Apache Spark独自のセキュリティガイダンスでは、ユーザーが送信したコードはその動作に制限なく実行され、ユーザーはアプリケーションに割り当てられたリソースを制御できると述べられています。Spark拡張機能は読み取り制限を実装できますが、テーブルレベルのアクセス制御API（きめ細かなアクセス制御用のAPIは言うに及ばず）を欠いているため、管理者がランタイムを制御し、制御の適用を回避するすべての経路を排除した場合にのみ、そのデプロイメントは信頼できるとみなされます（Icebergコミュニティのディスカッション）。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事