メインコンテンツまでスキップ
に最終更新

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) ポリシーの作成と管理を参照してください。

制限事項​

  • ABAC によって保護されたテーブルにアクセスするには、 Databricks Runtime 16.4 以降でコンピュートを使用するか、サーバレス コンピュートを使用する必要があります。 ポリシーの対象ではないユーザーは、任意のランタイムを使用できます。

  • ABAC ポリシーをビューに直接適用することはできません。ただし、ABAC ポリシーが設定されたテーブルに基づくビューをクエリする場合は、ビュー所有者の ID と権限を使用してポリシーが評価されます。これはつまり：

    • ビューの所有者は、基礎となる ABAC で保護されたテーブルに対する適切な権限を持っている必要があります。
    • データ アクセスは、ビュー所有者の権限に基づいて評価されます。ユーザーがビューをクエリすると、ビューの所有者に表示されるとおりに、フィルター処理またはマスクされたデータが表示されます。
    • 動作はコンピュートの構成によって異なる場合があります。 詳細については、 「ビューのクエリ要件」を参照してください。

  • マテリアライズドビューおよびストリーミングテーブルに関するポリシーは、パイプライン所有者がポリシーから免除されている場合にのみサポートされます。

  • ユーザーは、必要なDelta Sharing権限を持ち 、 ABAC ポリシーが免除されている場合、ABAC ポリシーによって保護されたテーブルをDelta共有できます。 このポリシーは受信者のアクセスを管理するものではありません。共有プロバイダーについては、 「ABAC ポリシーによって保護されたテーブルとスキーマを共有に追加する」を参照してください。共有の受信者については、 「ABAC で保護されたデータを読み取り、ABAC ポリシーを適用する」を参照してください。

  • 特定のテーブルおよび特定のユーザーに対して、実行時に解決できる個別の行フィルターは 1 つだけです。 複数の行フィルタ ポリシーを定義できますが、ユーザーがテーブルにクエリを実行するときは、1 つのポリシーの条件のみが一致する必要があります。 複数の異なる行フィルターが同じユーザーとテーブルに適用される場合、Databricks はアクセスをブロックし、エラーをスローします。複数のポリシーが同じフィルター (同じ引数を持つ同じ UDF など) を生成する場合は、複数のポリシーが許可されます。複数のフィルターまたはマスクのトラブルシューティングを参照してください。

  • 特定の列と特定のユーザーに対して解決できるのは、1 つの個別の列マスクのみです。 複数の列マスク ポリシーを定義できますが、ユーザーがテーブルをクエリする場合、各列に対して 1 つのポリシーの条件のみが一致する必要があります。 同じユーザーの同じ列に複数の異なる列マスクが適用されると、Databricks はアクセスをブロックし、エラーをスローします。同じマスク (たとえば、同じ引数を持つ同じ UDF) が生成される場合、複数のポリシーが許可されます。複数のフィルターまたはマスクのトラブルシューティングを参照してください。

  • ABAC ポリシーのMATCH COLUMNS句には最大 3 つの列条件を含めることができます。

  • ABAC ポリシーの情報スキーマ テーブルはありません。information_schema.row_filtersテーブルとinformation_schema.column_masksテーブルには、テーブルに直接適用された行フィルターと列マスクのみが表示されます。ABAC ポリシーの定義や、ランタイム時に ABAC ポリシーから派生したフィルターやマスクは表示されません。

  • 専用コンピュートでの ABAC の制限については、 「制限事項」を参照してください。

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