Unity Catalogにおけるデータ権限モデルとアクセス制御のためのヒッチハイカーズガイド

The Hitchhiker's Guide to data privilege model and access control in Unity Catalog

翻訳： junichi.maruyama 

データの量、速度、多様性が増すにつれ、組織は、中核となるビジネス成果を適切に満たすために、確固たるデータガバナンスの実践にますます頼るようになっています。Unity Catalogは、Databricks Lakehouseを支えるデータとAIのためのきめ細かなガバナンス・ソリューションです。データアクセスを管理・監査するための一元的なメカニズムを提供することで、企業のデータ資産のセキュリティとガバナンスを簡素化することができます。

Unity Catalogがファイル、テーブルの権限モデルを統一し、すべての言語をサポートするようになる以前、お客様はレガシーワークスペースレベルのテーブルACL（TACL）を使用してDatabricksできめ細かいデータアクセス制御を実施していましたが、これは特定のクラスタ構成に限定され、PythonとSQLに対してのみ機能しました。Unity CatalogとTACLはどちらも、カタログ、スキーマ（データベース）、テーブル、ビューなどのセキュリティで保護されたオブジェクトへのアクセスを制御できますが、それぞれのアクセスモデルがどのように機能するかには、いくつかのニュアンスがあります。

Unity Catalogを使って大規模にデータガバナンスを実施するには、オブジェクトアクセスモデルをよく理解することが必要です。すでにテーブルACLモデルを導入しており、Unity Catalogにアップグレードして、多言語対応、集中アクセス制御、データリネージなどの最新機能を活用しようとしている場合は、なおさらです。

Unity Catalogアクセスモデルの公理

1. Unity Catalogの権限は、メタストアで定義されます - Unity Catalogの権限は常にアカウントレベルの ID を参照し、hive_metastore カタログ内で定義された TACL 権限は常にワークスペースのローカル ID を参照します。
2. 特権の継承 - Unity Catalogのオブジェクトは階層化されており、権限は下へ下へと継承されます。権限が継承される最上位のオブジェクトはカタログです
3. オブジェクトの所有権が重要 - 特権は、メタストア管理者、オブジェクトの所有者、またはオブジェクトを含むカタログやスキーマの所有者のみが付与することができます。オブジェクトの所有者、またはオブジェクトを含むカタログやスキーマの所有者のみが、オブジェクトをドロップできます。
4. 境界のためのUSE特権 - カタログ/スキーマ内のオブジェクトと対話するには、USE CATALOG/SCHEMAが必要です。しかし、USE権限では、カタログ/スキーマ内に収容されているオブジェクト・メタデータを参照することはできません。
5. 派生オブジェクトのパーミッションが簡略化される - Unity Catalogでは、ビューの所有者にはSELECT権限と、ビューの親スキーマのUSE SCHEMA、親カタログのUSE CATALOGが必要なだけです。TACLとは対照的に、ビューの所有者は参照されるすべてのテーブルとビューの所有者である必要があります。

より複雑な公理をいくつか紹介

6. デフォルトでセキュア -  Unity-Catalog固有のaccess modes（共有またはシングルユーザー）を持つクラスタのみが、Unity Catalogデータにアクセスできます。TACLを使用すると、非共有クラスタではすべてのユーザーがすべてのデータにアクセスすることができます
7. シングルユーザークラスタの限界 - シングルユーザークラスターは、ダイナミックビューをサポートしていません。ビューから読み込むには、参照するすべてのテーブルとビューに対してSELECTを持つ必要があります。
8. ANY FILE、ANONYMOUS FUNCTIONをサポートしていません。- Unity Catalogは、これらの権限をサポートしません。なぜなら、これらの権限は、特権を持たないユーザーが特権コードを実行できるようにすることで、アクセス制御の制限を回避するために使用される可能性があるからです。

興味深いガバナンスパターン

Unity Catalogのアクセスモデルを使って実現できるガバナンスパターンはたくさんあります。

Example 1 - ワークスペース間で一貫した権限設定

公理1では、製品チームが自分のワークスペース内でデータ製品の権限を定義し、それを他のすべてのワークスペースに反映させ、消費者がどこから来るかに関係なく強制することができます。

Example 2 - データ共有の境界を設定する

公理2 では、カタログ/スキーマの所有者がデータに対するデフォルトのアクセスルールを設定することができます。たとえば、次のコマンドは、機械学習チームがスキーマ内でテーブルを作成し、互いのテーブルを読み取ることを可能にします：

さらに興味深いことに、公理4ではカタログ/スキーマの所有者が、個々のスキーマおよびテーブルの所有者が生成するデータを共有できる範囲を制限できるようになりました。テーブルの所有者が他のユーザーにSELECTを付与しても、そのユーザーが親カタログのUSE CATALOG権限と親スキーマのUSE SCHEMA権限を付与されていない限り、そのテーブルへの読み取りアクセスは許可されません。

以下の例では、sample_catalogはユーザーAが所有し、ユーザーBはsample_schemaスキーマを作成し、テーブル42を作成しました。アナリストチームにUSE SCHEMAとSELECT権限が付与されていても、ユーザーAが設定した権限境界のために、アナリストチームはテーブルを照会することができません。

 

Example 3 - ビジネスロジックの共有が容易に

データ・コンシューマは、その作業や変換ロジックを共有する必要があり、それを行うための再利用可能な方法は、ビューを作成して他のコンシューマに共有することです。

公理5 は、データコンシューマがテーブルの所有者と手動でやり取りすることなく、シームレスにこれを実行できるようにする機能を提供します。

Example 4 - 情報漏えいを防ぐ

公理6のおかげで、データ所有者は、クラスタの誤設定によるデータへの不正アクセスがないことを確信することができます。正しいアクセスモードが設定されていないクラスタは、Unity Catalogのデータにアクセスすることができません。

ユーザーは、クラスタの作成ページでこの便利なツールチップを使用して、自分のクラスタがUnity Catalogのデータにアクセスできることを確認できます。

データ所有者がデータ権限モデルとアクセス制御を理解できるようになったことで、Unity Catalogを活用し、大規模なアクセスポリシー管理を簡素化することができます。

今後、データ管理者やデータ所有者がより複雑なアクセスポリシーを作成できるようにするための機能が追加される予定です：

• 行フィルタリングと列マスキング: 標準SQL関数を使用して行フィルタと列マスクを定義し、行と列に対するきめ細かなアクセス制御を可能にします。
• 属性に基づくアクセス制御: データ資産のタグ（属性）に基づいて、アクセスポリシーを定義します。