レイクハウスビジョンの完成: オープンストレージ、オープンアクセス、統合ガバナンス

これまで、組織はレイクハウス環境で利用する複数のクエリエンジンやツールをまたがって、属性ベースのアクセス制御（ABAC）ポリシーを統一的に適用する手段を持っていませんでした。本日、外部エンジンに対するきめ細かなアクセス制御のプレビュー提供を発表できることを嬉しく思います。 この発表により、Unity Catalogは、クロスエンジンABACをサポートする初めてにして唯一のカタログとなり、チームはタグベースの行フィルタと列マスクを一度定義すれば、データにアクセスするあらゆる場所でそれを適用できるようになります。

Unity Catalog による統合ガバナンスは、レイクハウスに残された最大の課題の 1 つである、さまざまなエンジンにまたがる断片化されたガバナンスを解消します。Apache Iceberg REST カタログ APIs 上に構築された Unity Catalog は、きめ細かなポリシーによって完全に管理されながら、データが外部エンジンに対してオープンな状態を維持することを保証します。

レイクハウスビジョンの完成

組織がレイクハウス・アーキテクチャを採用するにつれ、データはプロプライエタリなウェアハウス・システムからオープン・ストレージとオープン・テーブル・フォーマットへと移行し、重複やロックインなしにSpark、Trino、DuckDBといった複数のエンジンからアクセスできるようになりました。

しかし、この新しいレベルのオープン化は難しい問題をもたらしました。それは「データにアクセスできるあらゆる場所でガバナンスを機能させる必要がる」という点です。従来のデータウェアハウスでは、行レベルと列レベルの制御が単一のエンジンの中で実施されていました。一方、オープンなレイクハウスでは、データは多くのエンジンからアクセスできるようになり、すべてのエンジンで一貫したポリシーの実施を保証することが新たな課題となりました。

このため、セキュリティチームは、次のような複雑またはリスクの高いアプローチのいずれかを選択せざるを得ませんでした。：

• 複数のシステムにまたがるアクセス制御ポリシーを手作業で複製しているため、運用の負担が増大し、ポリシーの不整合（ドリフト）が発生するリスクを抱える。
• エンジンやリージョンごとに個別のフィルタ済みビューやテーブルコピーを維持する必要があり、データの重複と一貫性の欠如を招く。
• あるいは、下流のツールに対してテーブルレベルで広範なアクセス権を付与してしまい、きめ細かなガバナンス自体を迂回してしまう。

顧客からは一貫して、オープンフォーマットによって共有データ上での柔軟なコンピュートが実現されたものの、そのビジョンを完全に実現するにはガバナンスも統一する必要がある、とのお声をいただいていました。

複数のエンジンにまたがるきめ細かなガバナンスの課題

Unity Catalogは、資格情報ベンディングを通じて複数のエンジンにわたるユニバーサルなテーブルレベルのアクセス制御をすでに提供しており、これはレイクハウスにおけるガバナンスの統合に向けた大きなステップです。しかし、テーブルレベルのアクセスだけでは、ユーザーが行や列のサブセットだけを見るべきシナリオには対応しきれません。センシティブなデータには、多くの場合、地域制限や PII のマスキングなど、よりきめ細かい制御が必要になることが多くあります。

きめ細かい適用は、通常コンピュート エンジンの内部で行われます。Databricks Runtimeでは、サーバーサイド フィルタリングを使用してこの問題を解決します。きめ細かい適用が必要なクエリーは、安全なフィルタリング フリート経由で透過的にルーティングされるため、許可されたデータのみが処理されます。しかし、DuckDB、Trino、SparkといったDatabricksの外部で実行されるエンジンにはこのロジックが組み込まれておらず、一貫したセマンティクスでガバナンスポリシーを適用することができません。

その結果、レイクハウス上でどのエンジンでも自由に使える柔軟性を保ちながら、細粒度なガバナンスを失わないようにしたい、という根本的な課題が浮き彫りになりました。

主要原則

私たちのお客様からは、どんな解決策であっても次の要件を満たす必要があると言われてきました：

• DuckDB、Python、pandasなど、ネイティブのガバナンス機能を持たないものを含め、あらゆるエンジンやツールで動作すること
• 属性ベースのアクセス制御（ABAC）やカスタム行・列マスキングロジックなど、Unity Catalogポリシーの表現力を損なわずに維持できること
• 高いレイテンシや複雑な運用負荷を招くことなく、大規模環境でも効率的に動作すること

私たちのアプローチ

エンジン間できめ細かなガバナンスを拡張するには、2つのアプローチがあります：

1. ポリシー交換 – ベンダー同士が共通のポリシー言語と強制モデルに合意し、すべてのエンジンがそれを実装する。
2. 一元的な適用 – カタログ側がガバナンスの中枢としてポリシーを評価し、データが外部エンジンに届く前にポリシーを適用する。

長期的には、エコシステムは最初のアプローチ、つまり信頼できるエンジンがネイティブに適用できる共有ポリシー標準に収束すると期待しています。

しかしながら、これを正しく行うには、3 つの基本的な課題を解決する必要があります。

• システム間で共通のポリシー言語とセマンティクスを開発する - アイデンティティモ デル、ポリシーのセマンティクス、および実行環境は、システム間で大きく異なります。初期のベンダー横断標準は、属性ベースのアクセス制御、複雑なサブクエリなどの高度なポリ シーをサポートできない最小公倍数の言語に収束する危険性があります。
• ポリシー・コンテキストの安全な送信 -カタログは、機密性の高い ID や属性情報を漏らすことなく、ポリシー・コンテキストを外部エンジンと共有できなければなりません。
• エンジン間の信頼と検証可能なエンフォースメントの確立 - カタログ側は、各エンジンがポリシーを安全かつ一貫した形で強制していることを信頼し、かつ検証できる状態を担保しなければなりません。

これらの課題を解決するには、エコシステム全体での幅広い連携が必要になります。私たちは、企業が求める高度なガバナンス要件をサポートできる共有ポリシーモデルの基盤を探るため、Apache Iceberg コミュニティで初期段階の議論をすでに開始しています。

Unity Catalog の ABAC モデルはエンタープライズレベルのセキュリティのために構築されており、複雑なサブクエリを持つ行フィルター、管理タグとユーザー属性に基づく条件付きロジック、SQL、Python、Scala の UDF を利用した高度なマスキング関数など、表現力豊かな制御をサポートしています。私たちは、これらの高度なセキュリティプリミティブをサポートし、エコシステム全体でスケールする標準を確立するために、オープンソースコミュニティとの協業にコミットしています。

一方で現時点では、外部エンジン上で細粒度なガバナンスを実現できるアプローチは中央集約型の強制だけです。この方式により、Unity Catalog のガバナンス機能が持つ表現力を損なうことなく維持しつつ、独自のポリシー実行環境を持たないエンジンも含め、あらゆる外部エンジンで一貫したポリシー適用を保証でき、外部システムへの暗黙の信頼に依存せずに済むようになります。

オープンスタンダードを採用

エンジン間の適用を可能にするため、Unity Catalog はオープンスタンダードを基盤としています。Iceberg REST カタログ プロトコルを使用すると、エンジンは、読み取るべきデータとそのアクセス方法をサーバーに決定するよう要求できます。これは「スキャンプランニング」と呼ばれ、カタログがデータアクセスパターンを最適化し、クエリーのパフォーマンスを向上させることを可能にします。

Unity Catalog はこのモデルを拡張し、ユーザーの権限情報に基づいて、行フィルター・カラムマスク・属性ベースルールといった細粒度ポリシーを適用した「フィルタ済みスキャンプラン」を生成します。 これにより、外部エンジン側は追加のポリシーロジックを実装することなく、すでにガバナンスが適用されたデータだけを取得できるようになります。

外部エンジンからガバナンス対象テーブルへのアクセス要求が来たときの流れは次のとおりです: 

• 外部エンジンはIceberg RESTカタログAPIを使用してスキャンリクエストを発行します
• Unity Catalogはそのリクエストに対して適用されるきめ細かなポリシーを評価します
• Unity Catalogは必要な行フィルタと列マスクを適用し、フィルタリングされたスキャンプランを外部エンジンに返却します

許可されたデータのサブセットだけが、処理のためにエンジンへ公開されます。 ポリシーの強制はサーバーサイドのプランニングの一部として実行されるため、エンジン側に独自のポリシーロジックを実装する必要はありません。

Databricks は、このフィルタリングを実行するために高度に最適化されたサーバーレスコンピュートを利用しており、Databricks Runtime 内部のセキュリティを担保しているものと同じ基盤インフラを活用しています。 この仕組みの中では、Databricks の宣言型パイプラインを支える技術を用いて、フィルタ後のデータが増分的かつ効率的に処理されるため、低コストかつ低レイテンシで結果を返すことができます。

Iceberg REST カタログ APIs を基盤とすることで、Unity Catalog は、単一のデータコピーに対してエンジン間でポリシーが効率的かつ一貫して適用される、オープンでクロスエンジンなガバナンスの基盤を築きます。

ポリシーを一度定義すれば、あらゆる場所で適用できる

外部エンジンでのきめ細かな適用により、顧客は、Delta Lake や Iceberg を含むすべての Unity Catalog マネージドテーブルに対して、単一でスケーラブルなセキュリティモデルを採用できます。

ABAC を用いることで、管理者は行フィルターや列マスキングロジックを一度定義するだけでよく、ポリシーはガバナンスされたタグやユーザー属性に基づいて動的に適用されます。この統合されたポリシーレイヤーは、いまや Databricks の外側にも広がりつつあり、まずは Apache Spark から対応が始まり、オープンなエコシステムが Iceberg REST Catalog Scan API を採用するにしたがって、さらに対象が拡大していきます。

オープンレイクハウスのエコシステムにとって、これは何を意味するのか？

外部エンジンに対するきめ細かなガバナンスは、オープンレイクハウスの重要なマイルストーンとなります。オープン・テーブル・フォーマットは、共有されたデータで複数のエンジンを実行する柔軟性を顧客に与えました。Unity Catalogは対応するガバナンス・レイヤーを提供し、データにアクセスする場所に関係なくABACポリシーを実施できるようになります。

これにより、オープンレイクハウスにおける新たな相互運用性の土台が築かれます。 すなわち、「データのためのオープンフォーマット」「アクセスのためのオープン API」「エコシステム全体に一貫して適用される単一のガバナンスシステム」という三位一体の構成です。

次のステップ

外部エンジン向けのきめ細かいアクセス制御をお試しいただくため、一部の顧客を対象にオンボーディングを実施しています。今後、追加のエンジンが Iceberg REST catalog scan APIs を採用するのに合わせてサポートを拡大する予定です。プレビューへの参加をご希望の場合は、こちらのフォームにご記入いただくか、Databricksのアカウントチームまでお問い合わせください。