AWS 、 Azure 、 GCP 上の Unity Catalog で行フィルターと列マスクが一般提供されることをお知らせします。テーブル内の行と列に対するきめ細かなアクセス制御を管理することは、データセキュリティを確保し、コンプライアンスを満たすために不可欠です。 Unity Catalog を使用すると、標準の SQL 関数を使用して行フィルターと列マスクを定義し、行と列に対するきめ細かいアクセス制御が可能になります。 行フィルターを使用すると、組織内のグループとユーザーの階層に表示されるテーブルの行のサブセットを制御できます。 列マスクを使用すると、同じディメンションに基づいてテーブルの値を編集できます。
「Unity Catalog のおかげで、データ資産の統一されたビューを作成できるようになり、BlackBerry 内のチーム間のコラボレーションが簡素化されました。 現在、アクセス権限を管理し、レイク内のファイルまたはテーブルを監査するための標準的なアプローチがあり、行と列に対するきめ細かなアクセス制御を定義することができます。 自動化されたデータリネージにより、データの出所を確認して潜在的な脅威の発生源を正確に特定し、どの研究プロジェクトやチームが脅威検出のためにデータを活用しているかを把握できるようになりました」
— Justin Lai 氏、Blackberry 社、ディスティングイッシュト データ アーキテクト
このブログでは、行フィルターと列マスクを使用してきめ細かいアクセス制御を有効にする方法について説明します。
大まかなオブジェクトレベルのセキュリティとは?
この発表の前に、Unity Catalog はすでにオブジェクト レベルのセキュリティをサポートしていました。 たとえば、テーブルや関数などのセキュリティ保護可能なオブジェクト に対して GRANT および REVOKE SQL コマンドを使用して、それらの検査、クエリ、または変更を許可するユーザーとグループを調整できます。
account_teamへの読み取りアクセスを許可できます。
これで、account_teamはpurchase_historyテーブルをクエリするアクセス権を持ちます (ただし、変更はできません)。
異なるグループ間でデータのサブセットを共有するための従来のアプローチ
しかし、リージョンごとに別々のアカウント チームがある場合はどうなるでしょうか?
戦略の一つは、動的ビュー の使用です。 特定のユーザーまたはグループによる使用を目的としたビューを定義できます。
これにはデータのコピーは含まれませんが、ユーザーがEMEAリージョンの場合はaccounts.purchase_history_emeaに、APACリージョンの場合はaccounts.purchase_history_apacにクエリすることなどを覚えておく必要があります。
管理者の観点では、動的ビューには特定のケースに対して有効な提案価値があります。 ただし、この例では、いくつかの制約が適用されます。
クエリに制限されており、ビュー内でデータを挿入または更新できません
各リージョンに対して 多数のビューを作成および維持する必要があります
共有SQLロジックは、異なるリージョンのチーム間で再利用するのが面倒です
カタログエクスプローラが煩雑になります
上記に加えて、動的ビューでは、参照されたテーブルからスキャンされ、ビュー内でフィルター処理または集計された行の値を検出するダウンストリーム ユーザーからの保護は提供されません。 たとえば、ユーザーは、クエリ オプティマイザーがビュー評価自体内でこれらの操作をプッシュダウンすることを意図して、特定の列値に応答してエラーをスローする WHERE 句を作成できます。
最後の手段として、データのサブセットを別のテーブルにコピーし、それに応じて権限を設定する日次ジョブを作成することもできます。
このアプローチはクエリのニーズに効果的に対応しますが、欠点があります。 データを複製することで、ストレージとコンピュートの使用量が増加します。 また、重複したデータは元のデータよりも遅れるため、古くなってしまいます。 さらに、このソリューションは、ユーザー権限が制限されているため、プライマリ テーブルへの書き込みアクセスを制限し、クエリのみに対応します。
行フィルターの概要
行フィルタを使用すると、テーブルに述語を適用して、特定の条件を満たす行のみが後続のクエリで返されるようにすることができます。
各行フィルターは、SQL ユーザー定義関数 (UDF) として実装されます。 まず、ア クセスを制御するターゲット テーブルの列と同じ型のブール結果を持つSQL UDFを記述します。
一貫性を保つために、この目的のためのテーブルとして、前のaccounts.purchase_historyのregion列を引き続き使用しましょう。
このロジックをテストするには、ターゲットテーブルに対していくつかのクエリを実行し、関数を直接適用します。 accounts_team_emeaグループのユーザーの場合、次のようなクエリになります。
または、最初にアクセス制御ロジックを設定しているadminグループ内のユーザーの場合、テーブルのすべての行が返されることがわかります。
これで、このロジックをポリシー関数としてターゲット テーブルに適用し、accounts_team_emeaグループへの読み取りアクセスを許可する準備が整いました。
または、作成時にこのポリシーをテーブルに直接割り当てて、テーブルが存在するがポリシーがまだ適用されていない期間がないようにすることもできます。
その後、テーブルからクエリを実行すると、上記のテストの結果に対応する行のサブセットが返されます。 たとえば、accounts_team_emeaメンバーは次の結果を受け取ります。
しかし、テーブルに新しいデータを書き込む場合はどうでしょうか。 accounts.purchase_history動的ビューの場合、これは不可能です。 一方こちらは、行フ ィルターを持つテーブルなので、必要に応じて SQL を使用して新しい行を挿入できます。
同じaccounts.purchase_historyを共有できるようになりました データをコピーしたり、名前空間に多くの新しい名前を追加したりすることなく、異なるグループを持つテーブルを作成できます。
この情報はカタログ エクスプローラーで表示できます。 purchase_historyテーブルを見ると、行フィルターが適用されていることがわかります。
行フィルターをクリックすると、ポリシー関数名が表示されます。
「表示」ボタンに従うと、機能の内容が表示されます。
列マスクのご紹介
行フィルターを使用してテーブルにきめ細かなアクセス制御を作成して適用し、呼び出し元のユーザーがクエリ時に読み取りアクセス権を持たない行を選択的に除外する方法を示しました。 しかし、代わりに 列 へのアクセスを制御し、一部の列の値を省略し、各行内の他の列の値をそのまま残す場合はどうでしょうか。
列マスク発表!
各列マスクは、SQL ユーザー定義関数 (UDF) として実装されます。 ただし、ブール値の結果を返す行フィルター関数とは異なり、各列マスク ポリシー関数は 1 つの引数を受け入れ、この入力引数と同じ型を返します。 たとえば、次のようにポリシーを使用して列マスクを作成し 、電子メール アドレス内の PII を除外できます。
ここで実行中のaccounts.purchase_historyテーブルについて、値が1000を超える場合に購入金額の列をマスクしてみましょう。
現在、10 ドル以上の購入金額を確認する権限を持つのは管理者のみです。
では、ポリシー機能をテストしてみましょう。 管理者以外のユーザーには、次の情報が表示されます。
ただし、管理者はすべてのデータを表示するためのアクセス権を持っています。
素晴らしいですね! マスクをテーブルに適用してみましょう。
その後、テーブルからのクエリでは、上記のテストの結果に対応する特定の列の値を編集する必要があります。 たとえば、管理者以外のユーザーには、次の結果が表示されます。
正しく動作します。
また、他の列の値を検査して、マスキングの決定を下すこともできます。 たとえば、購入金額の代わりに region 列を見るように関数を変更できます。
ここで、 USING COLUMNS句を使用してマスクを適用し、ポリシー関数に渡す追加の列名を指定できます。
その後、テーブルからのクエリでは、管理者以外の特定の列の値を異なる方法で編集する必要があります。
マスクは、カタログエクスプローラーのテーブル列で確認できます。
以前と同様に、「表示」ボタンに従うと、関数の内容が表示されます。
アクセス制御リストをマッピングテーブルに保存する
行フィルターおよび列マスク ポリシー関数は、ほとんどの場合、現在のユーザーを参照して、許可されたユーザーのリストと比較するか、許可されたグループの明示的なリストに対してそのグループのメンバーシップを確認する必要があります。 これらのユーザーおよびグループの許可リストをポリシー関数自体にリストすることは、適切なサイズのリストの場合に有効です。 リストが大きい場合や、ユーザーまたはグループ自体の ID がユーザーから見えないようにさらに確実にしたい場合には、代わりにマッピング テーブルを利用できます。
これらのマッピング テーブルはパーソナライズされたゲートキーパーのように機能し、元のテーブルでユーザーまたはグループがアクセスできるデータ行を決定します。 マッピングテーブルの優れた点は、ファクトテーブルとのシームレスな統合にあり、データセキュリティ戦略をより効果的にします。
このアプローチは、さまざまなカスタム要件に対するゲームチェンジャーです。
カスタマイズされたユーザー アクセス: ユーザー グループに特定のルールを適用しながら、個々のユーザー プロファイルに基づいて制限を課すことができます。 これにより、各ユーザーには必要な内容のみが表示されるようになります。
複雑な階層の処理: 複雑な組織構造であろう と、多様なルールセットであろうと、マッピングテーブルは複雑さをナビゲートし、データアクセスが独自の階層に準拠していることを確認できます。
シームレスな外部モデルレプリケーション: 外部ソース システムからの複雑なセキュリティ モデルのレプリケーションが簡単になります。 マッピングテーブルは、これらの複雑なセットアップを手間なくミラーリングするのに役立ちます。
例をいくつかご紹介します。
これにより、ポリシー関数自体を複雑にすることなく、accounts.purchase_history_groupsテーブルを多数のグループに拡張でき、さらに、そのテーブルの行へのアクセスを、accounts.purchase_history_row_filter SQL UDFを作成した管理者のみに制限することができます。
レイクハウスフェデレーションでの行および列レベルのセキュリティの使用
レイクハウスフェデレーション により、 Unity Catalogデータ管理の重要な課題を解決し、組織が異種データ システムを処理する方法を簡素化します。 これにより、構造化データと非構造化データの両方を含むデータ資産全体の統一されたビューを作成できるようになり、データソースに関係なくすべてのユーザーが安全にアクセスして探索できるようになります。 単一のエンジンで効率的なクエリとデータの組み合わせが可能になり、データ取り込みを必要とせずにさまざまなデータ分析とAIアプリケーションを高速化します。 さらに、データ セキュリティのための一貫した権限モデルを提供し、アクセス ルールを適用して、さまざまなプラットフォーム間でコンプライアンスを確保します。
ここで発表されたきめ細かいアクセス制御は、レイクハウスフェデレーション テーブルとシームレスに連携し、さまざまなグループに対するカスタムの行および列レベルのアクセス ポリシーを使用して、組織内のフェデレーション テーブルへのアクセスの共有をサポートします。 カタログにデータをコピーしたり、重複または類似のテーブル/ビュー名を多数作成したりする必要はありません。
たとえば、既存の MySQL データベースへのフェデレーション接続を作成できます。 次に、カタログ エクスプローラーを参照してフォーリンカタログを調べます。
カタログ内には、 mysql_demo_nyc_pizza_rating テーブルがあります。
そのテーブルに行フィルターを適用してみましょう。
後でテーブルの概要を見ると、変更が反映されています。
行フィルターをクリックすると、以前と同様に関数の名前が表示されます。
これで、このフェデレーション MySQL テーブルに対するクエリは、各呼び出しユーザーの ID とグループ メンバーシップに応じて、異なる行のサブセットを返します。 私たちは、きめ細かいアクセス制御をレイクハウスフェデレーションと統合することに成功し、その結果、同じ組織内のDelta LakeとMySQLテーブルの 使いやすさと統一されたガバナンスが実現しました。
行および列レベルのセキュリティの概要
行フィルターと列マスクを使用すると、データ管理を合理化し、過剰なETLパイプラインとデータ コピーを排除できるようになります。 これは、統合データ セキュリティの新しい世界への入り口であり、制御を維持し、機密情報が保護された状態を保ちながら、複数のユーザーやグループと自信を持ってデータを共有できます。
行フィルターと列マスクの使用を開始するには、 AWS 、 Azure 、 GCP に関するドキュメントをご覧ください。 行フィルターと列マスクを使用してテーブルをクエリするワークロードを、どの UC コンピュートでも実行できます: サーバレス、共有アクセス モード、シングルユーザー アクセス モード (DBR 15.4 以降)
