Important
この機能は パブリック プレビュー段階です。
このページでは、Unity カタログの属性ベースのアクセス制御 (ABAC) について説明します。
ABAC とは
ABAC は、Azure Databricks 全体で柔軟でスケーラブルで一元的なアクセス制御を提供するデータ ガバナンス モデルです。 ABAC は、データ資産に適用される管理タグに基づいてポリシーを定義できるようにすることで、Unity Catalog の既存の特権モデルを補完します。 これにより、ガバナンスが簡素化され、セキュリティが強化されます。
MANAGEアクセス許可またはオブジェクトの所有権を持つユーザーは、ポリシーを 1 回だけ定義するだけでよく、多くのデータ資産に対して一貫して適用できます。 ポリシーはカタログ、スキーマ、またはテーブル レベルでアタッチされ、そのスコープ内のすべてのテーブルに自動的に適用されます。 上位階層で定義すると、ポリシーは子オブジェクトに継承されます。 データ資産の管理タグによって、適用されるポリシーが決まります。これにより、アクセス制御を動的に適応できます。
ABAC の利点
- スケーラビリティ: 個々のアクセス許可ではなくタグを利用して、大規模なアクセス制御を管理します。
- 柔軟性： 各データ資産を変更せずにタグまたはポリシーを更新することで、ガバナンスを簡単に調整できます。
- 一元化されたガバナンス: カタログ、スキーマ、およびテーブルにまたがる統合モデルを使用して、ポリシー管理を簡略化します。
- セキュリティの強化: データ属性に基づいて、きめ細かいアクセス制御を動的に適用します。
- 監査可能性: 包括的な監査ログを使用して、データ アクセスをリアルタイムで可視化します。
ABAC のしくみ
Unity カタログの ABAC は、管理されたタグ、ポリシー、およびユーザー定義関数 (UDF) を使用して、動的な属性ベースのアクセス制御を適用します。 ABAC の中心となるコンポーネントとメカニズムを次に示します。
管理タグ: 管理タグは、タグ ポリシーを使用してアカウント レベルで定義されます。 これらのタグは、データの機密性、分類、ビジネス ドメインなどの属性を表し、Unity カタログのテーブル、スキーマ、またはカタログに割り当てられます。 これらは、ポリシーの適用を促進する属性として機能します。 「管理タグ」および「Unity カタログのセキュリティ保護可能なオブジェクトにタグを適用する」を参照してください。
檄： ポリシーは、Unity カタログ内の 3 つの階層レベルで作成および管理されます。
- カタログ レベル: 含まれるすべてのスキーマとテーブルに影響を与える広範なポリシーを適用します。
- スキーマ レベル: スキーマとそのテーブルに固有のポリシーを適用します。
- テーブル レベル: 個々のテーブルにきめ細かいポリシーを直接適用します。
ポリシーは 継承モデルに従います。ポリシーがカタログまたはスキーマ レベルで定義されている場合、そのスコープ内のすべての子オブジェクト、スキーマ、およびテーブルに自動的に適用されます。 これにより、管理者は、大規模なデータ資産のセットを管理する単一のポリシーを適用することで、効率的なガバナンスを実装できます。 継承されたポリシーにより、冗長性が低下し、データ階層全体で一貫した適用が促進されます。 Databricks では、ガバナンス効率を最大化し、管理オーバーヘッドを削減するために、適用可能な最高レベル (通常はカタログ) でポリシーを定義することをお勧めします。 属性ベースのアクセス制御 (ABAC) ポリシーの作成と管理を参照してください。
ユーザー定義関数 (UDF): UDF はスキーマ レベルで定義されたカスタム関数であり、Unity Catalog 名前空間全体でグローバルに参照できます。 UDF は、行のフィルター処理や属性に基づく列値のマスクなど、複雑なロジックを表すためにポリシー内で使用されます。 たとえば、
filter_regionという名前の UDF を行フィルター ポリシーで使用して、region = 'EMEA'行のみを返すことができます。 「Unity Catalog のユーザー定義関数 (UDF)」を参照してください。動的強制: ユーザーがタグ付けされたデータ資産にアクセスしようとすると、Unity Catalog はタグに基づいて適用可能なポリシーを評価し、定義されたアクセス制御を適用します。
ポリシーから明示的に除外されたユーザーは、ディープ 複製や浅い複製、基になるデータの時間移動などのアクションを引き続き実行できます。 ただし、ABAC ポリシーから除外されていないユーザーには、 専用コンピューティングでのきめ細かなアクセス制御に適用されるのと同じ制限が適用されます。
監査ログ: タグ付けされたデータ資産に対するすべての操作がキャプチャされ、監査ログ システム テーブルに記録されるため、包括的な可視性とコンプライアンス追跡が可能になります。 監査ログを参照してください。
ABAC を構成する方法については、「 チュートリアル: ABAC を構成する」を参照してください。
ABAC の構成のデモについては、 Unity カタログを使用した Attribute-Based アクセス制御 (ABAC) の検出に関するページを参照してください。
ポリシーの種類
次の 2 種類の ABAC ポリシーがサポートされています。
行フィルター ポリシーでは、 その内容に基づいてテーブル内の個々の行へのアクセスが制限されます。 フィルター UDF は、各行をユーザーに表示するかどうかを評価します。 これらのポリシーは、アクセスがデータ特性に依存する場合に便利です。
ユース ケースの例: リージョン列が
region=EMEAなどの管理タグと一致する顧客トランザクション テーブルの行のみを表示します。 これにより、地域チームは自分の地域に関連するデータのみを表示できます。列マスク ポリシーは、 ユーザーが特定の列に表示する値を制御します。 マスク UDF は、管理タグに基づいて、実際の値または編集済みのバージョンを返すことができます。
ユース ケースの例: テーブルが
sensitivity=lowタグ付けされているか、要求しているユーザーがコンプライアンス グループに含まれている場合を除き、電話番号を含む列をマスクします。 アクセス権のないユーザーには、XXX-XXX-XXXXなどの null 値またはプレースホルダー値が表示されます。
属性ベースのアクセス制御 (ABAC) ポリシーの作成と管理を参照してください。
制限事項
- ユーザーは、必要な差分 共有アクセス許可 を持ち、ABAC ポリシーから除外されている場合、ABAC ポリシーによってセキュリティ保護されたテーブルを差分共有できます。 このポリシーでは、受信者のアクセスは管理されません。 共有プロバイダーについては、「 ABAC ポリシーによってセキュリティ保護されたテーブルとスキーマを共有に追加する」を参照してください。 共有受信者については、 ABAC ポリシーによって保護されたデータ資産の読み取りを参照してください。
- ビューはサポートされていません。
- 具体化されたビューとストリーミング テーブルのポリシーは、パイプライン所有者がポリシーから除外されている場合にのみサポートされます。
- 特定のテーブルに適用できる行フィルターは 1 つだけです。 これは、複数の行フィルターの不明確な構成を回避するのに役立ちます。 複数の行フィルターが検出された場合、Azure Databricks はアクセスを制限し、エラーを発生させます。 複数のフィルターまたはマスクのトラブルシューティングを参照してください。
- 特定の列に適用できる列マスクは 1 つだけです。 これは、複数のマスク関数を適用する順序が不明確にならないようにするのに役立ちます。 ただし、列ごとに異なるマスクを同じポリシーに適用できます。 同じ列で複数の列マスクが検出された場合、Azure Databricks はアクセスをブロックし、エラーをスローします。 複数のフィルターまたはマスクのトラブルシューティングを参照してください。
- ABAC ポリシーは、
MATCH COLUMNS句に最大 3 つの列条件を含めることができます。 - ABAC によってセキュリティ保護されたテーブルにアクセスするには、Databricks Runtime 16.4 以降のコンピューティングまたはサーバーレス コンピューティングを使用する必要があります。 ポリシーの対象ではないユーザーは、任意のランタイムを使用できます。
- 専用コンピューティングでの ABAC の制限事項については、「制限事項」を参照してください。
行フィルターと列マスクの制限事項については、「 制限事項」を参照してください。