メインコンテンツまでスキップ

Unity Catalog の属性ベースのアクセス制御 (ABAC)

備考

プレビュー

この機能は パブリック プレビュー段階です。

このページでは、Unity Catalog の属性ベースのアクセス制御 (ABAC) について説明します。

ABACとは?​

ABACは、 Databricks全体で柔軟でスケーラブルで一元化されたアクセス制御を提供するデータバナンスモデルです。 ABAC は、データ資産に適用される管理されたタグに基づいてポリシーを定義できるようにすることで、Unity Catalog の既存の特権モデルを補完します。これにより、ガバナンスが簡素化され、セキュリティが強化されます。

MANAGE権限またはオブジェクト所有権を持つユーザーは、ポリシーを一度定義するだけで、多くのデータアセットに一貫してポリシーを適用できます。ポリシーは、カタログ、スキーマ、またはテーブルレベルでアタッチされ、そのスコープ内のすべてのテーブルに自動的に適用されます。上位レベルで定義されている場合、ポリシーは子オブジェクトに下位に継承されます。データアセットの管理されたタグによって、適用されるポリシーが決定され、アクセス制御が動的に適応できるようになります。

ABACの利点​

  • スケーラビリティ: アクセス制御を大規模に管理するには、個々の権限ではなくタグを活用します。
  • 柔軟性： 各データアセットを変更せずにタグやポリシーを更新することで、ガバナンスを簡単に調整できます。
  • 一元化されたガバナンス: カタログ、スキーマ、テーブルにまたがる統合モデルにより、ポリシー管理を簡素化します。
  • セキュリティの向上: データ属性に基づいて動的にきめ細かなアクセス制御を実施します。
  • 監査可能性: 包括的な監査ログを通じて、データアクセスのリアルタイムの可視性を維持します。

ABACの仕組み​

Unity Catalog の ABAC は、管理されたタグ、ポリシー、ユーザー定義関数 (UDF) を使用して、動的な属性ベースのアクセス制御を適用します。ABACの中心となるのは、以下のコンポーネントとメカニズムです。

  • Governed タグ: 管理タグは、タグポリシーを使用してアカウントレベルで定義されます。 これらのタグは、データの機密性、分類、ビジネス ドメインなどの属性を表し、Unity Catalog のテーブル、スキーマ、またはカタログに割り当てられます。これらは、ポリシーの適用を促進する属性として機能します。「 管理タグ」 および「 Unity Catalog セキュリティ保護可能なオブジェクトにタグを適用する」を参照してください。

  • ポリシー: ポリシーは、 Unity Catalog内の3つの階層レベルで作成および管理されます。

    • カタログレベル: 含まれているすべてのスキーマとテーブルに影響を与える広範なポリシーを適用します。
    • スキーマ レベル: スキーマとそのテーブルに固有のポリシーを適用します。
    • テーブルレベル: きめ細かなポリシーを個々のテーブルに直接適用します。

    ポリシー 継承モデル に従う: ポリシーがカタログまたはスキーマレベルで定義されている場合、そのポリシーは、そのスコープ内のすべての子オブジェクト、スキーマ、およびテーブルに自動的に適用されます。 これにより、管理者は、大規模なデータ資産セットを管理する単一のポリシーを適用することで、効率的なガバナンスを実装できます。継承されたポリシーは冗長性を減らし、データ階層全体で一貫した適用を促進します。Databricks では、ガバナンスの効率を最大化し、管理オーバーヘッドを削減するために、適用可能な最高レベル (通常はカタログ) でポリシーを定義することをお勧めします。属性 ベースのアクセス制御 (ABAC) ポリシーの作成と管理を参照してください。

  • ユーザー定義関数 (UDF): UDF は、スキーマ レベルで定義されたカスタム関数であり、Unity Catalog 名前空間全体でグローバルに参照できます。UDFs は、行のフィルタリングや属性に基づく列値のマスキングなど、複雑なロジックを表現するためにポリシー内で使用されます。たとえば、 filter_region という名前の UDF を行フィルタポリシーで使用して、 region = 'EMEA'.「Unity Catalog のユーザー定義関数 (UDF)」を参照してください。

  • 動的強制: ユーザーがタグ付けされたデータ資産にアクセスしようとすると、Unity Catalog はタグに基づいて適用可能なポリシーを評価し、定義されたアクセス制御を適用します。

    ポリシーから明示的に除外されたユーザーは、基礎となるデータに対してディープおよびシャローのクローン作成やタイムトラベルなどのアクションを引き続き実行できます。 ただし、ABAC ポリシーから除外されていないユーザーには、専用コンピュートのきめ細かいアクセス制御に適用されるのと同じ制限が適用されます。

  • 監査ログ: タグ付けされたデータ資産に対するすべての操作は、監査ログシステムテーブルにキャプチャされて記録されるため、包括的な可視性とコンプライアンス追跡が可能になります。監査ログを参照してください。

ABAC の設定方法については、「 チュートリアル: ABAC の設定」を参照してください。

ABAC の構成のデモについては、「 Unity Catalog を使用した属性ベースのアクセス制御 (ABAC) の検出」を参照してください。

ポリシーの種類​

次の 2 種類の ABAC ポリシーがサポートされています。

  • 行フィルタポリシーは 、テーブル内の個々の行へのアクセスをその内容に基づいて制限します。フィルター UDF は、各行をユーザーに表示するかどうかを評価します。これらのポリシーは、アクセスがデータ特性に依存する場合に便利です。

    使用例: 顧客トランザクションテーブル内の行は、region 列が region=EMEAなどの管理タグと一致する行のみを表示します。これにより、地域チームは地域に関連するデータのみを表示できます。

  • 列マスク ポリシーは、 特定の列でユーザーに表示される値を制御します。マスキング UDF は、管理されたタグに基づいて、実際の値または編集されたバージョンを返すことができます。

    使用例: テーブルに sensitivity=low のタグが付けられている場合、または要求元のユーザーがコンプライアンス グループに属していない限り、電話番号を含む列をマスクします。アクセス権のないユーザーには、null 値またはプレースホルダ値 ( XXX-XXX-XXXXなど) が表示されます。

属性ベースのアクセス制御 (ABAC) ポリシーの作成と管理を参照してください。

制限事項​

  • ユーザーは、必要なDelta Sharing権限を持ち 、 ABAC ポリシーから免除されている場合、ABAC ポリシーによって保護されたテーブルをDeltaできます。ポリシーは受信者のアクセスを管理しません。共有プロバイダーについては、「 ABAC ポリシーによって保護されたテーブルとスキーマを共有に追加する」を参照してください。共有受信者については、「 ABAC ポリシーによって保護されたデータ資産の読み取り」を参照してください。
  • ビューはサポートされていません。
  • マテリアライズドビューおよびストリーミングテーブルに関するポリシーは、パイプライン所有者がポリシーから免除されている場合にのみサポートされます。
  • 特定のテーブルに適用できる行フィルターは 1 つだけです。これにより、複数の行フィルターの不明確な構成を回避できます。複数の行フィルターが検出されると、Databricks はアクセスをブロックし、エラーをスローします。複数のフィルターまたはマスクのトラブルシューティングを参照してください。
  • 特定の列に適用できる列マスクは 1 つだけです。これにより、複数のマスキング関数を適用する順序が不明確になることを回避できます。ただし、同じポリシー内で、異なる列にそれぞれ異なるマスクを適用できます。同じ列に複数の列マスクが検出されると、Databricks はアクセスをブロックし、エラーをスローします。複数のフィルターまたはマスクのトラブルシューティングを参照してください。
  • ABAC ポリシーのMATCH COLUMNS句には最大 3 つの列条件を含めることができます。
  • ABAC によって保護されたテーブルにアクセスするには、 Databricks Runtime 16.4 以降でコンピュートを使用するか、サーバレス コンピュートを使用する必要があります。 ポリシーの対象ではないユーザーは、任意のランタイムを使用できます。
  • 専用コンピュートでの ABAC の制限については、 「制限」を参照してください。

行フィルターと列マスクの制限については、 「制限事項」を参照してください。

に最終更新