によって Matei Zaharia, ジョナサン・ケラー 、 ミシェル・レオン による投稿
これまで、組織はレイクハウス環境で利用する複数のクエリエンジンやツールをまたがって、属性ベースのアクセス制御（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の外部で実行されるエンジンにはこのロジックが組み込まれておらず、一貫したセマンティクスでガバナンスポリシーを適用することができません。
その結果、レイクハウス上でどのエンジンでも自由に使える柔軟性を保ちながら、細粒度なガバナンスを失わないようにしたい、という根本的 な課題が浮き彫りになりました。
私たちのお客様からは、どんな解決策であっても次の要件を満たす必要があると言われてきました：
エンジン間できめ細かなガバナンスを拡張するには、2つのアプローチがあります：
長期的には、エコシステムは最初のアプローチ、つまり信頼できるエンジンがネイティブに適用できる共有ポリシー標準に収束すると期待しています。
しかしながら、これを正しく行うには、3 つの基本的な課題を解決する必要があります。
これらの課題を解決するには、エコシステム全体での幅広い連携が必要になります。私たちは、企業が求める高度なガバナンス要件をサポートできる共有ポリシーモデルの基盤を探るため、Apache Iceberg コミュニティで初期段階の議論をすでに開始しています。
Unity Catalog の ABAC モデルはエンタープライズレベルのセキュリティのために構築されており、複雑なサブクエリを持つ行フィルター、管理タグとユーザー属性に基づく条件付きロジック、SQL、Python、Scala の UDF を利用した高度なマスキング関数など、表現力豊かな制御をサポートしています。私たちは、これらの高度なセキュリティプリミティブをサポートし、エコシステム全体でスケールする標準を確立するために、オープンソースコミュニティとの協業にコミットしています。
一方で現時点では、外部エンジン上で細 粒度なガバナンスを実現できるアプローチは中央集約型の強制だけです。この方式により、Unity Catalog のガバナンス機能が持つ表現力を損なうことなく維持しつつ、独自のポリシー実行環境を持たないエンジンも含め、あらゆる外部エンジンで一貫したポリシー適用を保証でき、外部システムへの暗黙の信頼に依存せずに済むようになります。
エンジン間の適用を可能にするため、Unity Catalog はオープンスタンダードを基盤としています。Iceberg REST カタログ プロトコルを使用すると、エンジンは、読み取るべきデータとそのアクセス方法をサーバーに決定するよう要求できます。これは「スキャンプランニング」と呼ばれ、カタログがデータアクセスパターンを最適化し、クエリーのパフォーマンスを向上させることを可能にします。
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のアカウントチームまでお問い合わせ ください。
ブログを購読して、最新の投稿を受信トレイにお届けします。