Databricks、外部エンジンからのUnity Catalog制御をABACで強化

Databricks は 2026年5月28日付の May 2026 platform release notes で、cross-engine attribute-based access controls のベータを公開しました。外部エンジンから Unity カタログ managed テーブル を読む場合でも、ABAC、row filters、column masks を server-side で適用できるようにする更新です。

要点

• 外部エンジンから Unity カタログ managed テーブル を読む際の ABAC enforcement がベータになった
• Delta と Iceberg の managed テーブル に対し、row filters と column masks を server-side で適用する方向の更新
• Databricks 内部だけでなく、外部 query engine からの読み取りにも Unity カタログ の統制を広げる
• Iceberg / Delta を複数エンジンで共有する組織では、ポリシー の解釈と監査を確認したい

今回のリリースノートで語られていること

今回の更新は、Databricks を単体の分析環境ではなく、複数エンジンから参照される lakehouse control plane として使う組織に関係します。Unity カタログ managed テーブル を外部エンジンから読む場合でも、attribute-based access controls、row filters、column masks を server-side で enforcement できるようになったと説明されています。

この意味は大きいです。Delta や Iceberg のテーブルを複数の query engine から読む構成では、データ本体は共有できても、権限、行制御、列マスク、監査をどこで一貫させるかが難しくなります。Databricks 内の SQL やノートブックでは ポリシー が効いていても、外部エンジン経由では別の設定や別の解釈になると、ガバナンス boundary が崩れます。

server-side enforcement が効く範囲が広がると、外部エンジン連携を許可しやすくなる一方で、検証すべき項目も増えます。どの外部エンジンでサポートされるのか、ポリシー の条件式が同じように解釈されるのか、row filter と column mask が組み合わさる場合の結果はどうなるのか、監査ログに誰のアクセスとして残るのかを確認する必要があります。

実務で確認したいポイント

まず、外部エンジンから読ませている Unity カタログ managed テーブル を棚卸ししてください。特に Iceberg / Delta を複数エンジンで共有している場合、代表テーブルで row filters、column masks、ABAC 条件が期待通りに効くかをテストするべきです。

次に、Databricks 内部のアクセス結果と外部エンジン経由のアクセス結果を比較します。ポリシー interpretation、監査ログ、権限エラー、キャッシュ、メタデータ refresh の挙動がずれると、セキュリティレビューで説明しにくくなります。

結局、この更新をどう見るべきか

Databricks の cross-engine ABAC ベータは、lakehouse を複数エンジンで使うための ガバナンス 更新です。外部エンジン連携を便利にするだけでなく、Unity カタログ を本当に共通の統制面として使えるかを検証するきっかけになります。