[レポート] ImmutaでSnowflakeに対するデータガバナンスの自動化を実現 #devio2022

大阪オフィスの玉井です。

2022年7月26日〜28日に、当社が開催したオンラインイベントの DevelopersIO 2022 において、Immuta社よりビデオセッションの形で登壇して頂きました。

本記事では、セッション内容の概要レポートと補足情報等をお届けします。詳細は、ぜひ動画本編をご覧ください。

前提知識

下記を先に読んでおくことを推奨します。

動画

セッション概要

登壇者

• Sam Carroll
  • Immuta社のSolutions Architect

超概要

Snowflake内のデータガバナンスを、Immutaを使って（Snowflake単体で行うよりも）効率良く実現する、という内容です。

セッションレポート

「※」がついているのは、私が補足として付け加えている情報となります。

イントロダクション

• Immutaはデータアクセス・データガバナンスのプラットフォームである
  • データアクセス・データガバナンスを自動化・合理化し、データを倫理的・法的に問題なく使用できるようにする
  • データを一貫した形で保護できる

Immutaの基本的なデモ

• Snowflakeにクレジットカードの取引テーブルがある

• 上記テーブルをImmutaに登録する
• 画面右側にテーブルのメタデータが表示されている
  • Snowflakeから自動的に引っ張ってきている
  • この情報を元にデータへのアクセスポリシーを作成できる
  • AlationやCollibra等のデータカタログと連携して、カタログ側のタグを使用することもできる

• テーブルの各カラムについて見る（データディクショナリ）
• Sensitive Data Detectionという機能によって、各カラムに自動的にタグが付与されている
  • Immuta Sensitive Data Detectionを使用して機密データを自動で把握する | DevelopersIO
  • このタグを用いてポリシーを作成することで、、今後新しいテーブルが登録されるたびに、「自動タグ付け→そのタグに関連するポリシーが適用」という風に、新しいデータに対して動的にポリシーを効かせることができる
  • 例：個人情報に該当するカラムは常にマスキングを行う

• ポリシー作成画面を見る（ポリシービルダー）
• Sam氏（登壇者）がすでに作成済の「Flaud Analytics Dataset Access」を使って説明する
  • ユーザー属性のDepartmentがFinance又はAnalyticsとなっているユーザー（要するに部署が経理部か分析部の社員）がSnowflakeにログインすると、冒頭に紹介したクレジットカードの取引テーブルにアクセスできるようにしている
  • Snowflake側でアクセスコントロールする場合、GRANT文を用いる必要がある
  • Immuta側は、画面の通り、簡単な操作・設定でアクセスコントロールができる
• 作ったポリシーは（条件が該当すれば）新しいデータ/新しいユーザーに対しても自動的に適用される
  • 新しくテーブルやビュー等ができたとき、Snowflake単体で管理する作業と比較すると、Immuta（を使った管理）はかなり楽になる

ユーザー属性を用いたアクセスコントロールのデモ

• 機密データをマスキングするポリシーを作成する
  • このポリシーでは、具体的には、クレジットカード番号（というタグがついた）カラムをマスキングする
  • 全データが対象
• ユーザー属性を用いてアクセス制御を行う
  • Okta等のIdPと連携できるため、IdP側のユーザータグを用いて、動的にポリシーを適用させることができる
• このポリシーは、Purpose（後述）がFraud DetectionかつDepartmentがFinance（部署が経理部）の人以外に適用される（経理部の人以外はクレジットカード番号が閲覧できないようにしている）

• Snowflakeで実際にクエリを実行してみる
• 一般的な部署のメンバーでクエリしているので、個人情報はマスキングされている
  • ※セッションでは紹介されていないが、他のポリシーでクレジットカード番号以外の機密データもマスキングされている模様

Purposeを用いたアクセスコントロールのデモ

• さっきとは別のデータポリシーを作成する
• （そのユーザーは）ユーザー属性のAuthorized Countriesに入っている国名のデータしか参照できないようにしている
  • ※いわゆる行レベルのセキュリティ
• ただし、PurposeがFraud Detectionのユーザーが適用外としている
  • Purposeとは「データにアクセスする（筋の通った）目的」のこと
  • ※ImmutaにはProjectという概念があり、PurposeはProjectに紐付いている
  • ※ユーザーはProjectに参加する

• Snowflakeで国別にグルーピングするクエリを実行する
• クエリ実行者のユーザー属性に存在する国のデータのみしか参照できない

• Immuta側で所属Projectを変更してみる
  • ※PurposeがFraud DetectionのProjectに変更する

• Snowflakeに戻って、先程と同じクエリを実行する
• 実行ユーザーのPurposeがFraud Detectionのため、全ての国のデータが参照できる

バージョン2021 4.1の新機能

• 別のユーザーに「なりすまし」ができる
• 例：DWH + BIツールを大規模に使っている場合
  • BIツールでダッシュボードを閲覧するユーザーが数千人規模の場合、ユーザーやグループ毎にアクセスポリシーを設定するのは、作業量的に非現実的
  • BIツール側には（DWHのデータに大体アクセスできる）パワーユーザーの認証情報をセットしておく
  • ImmutaのImpersonation機能を使うと、↑のパワーユーザーを、実際にBIツールを使っている一般ユーザーになりすますことができる
  • これにより、DWH側で数千人単位のアクセスコントロールの設定をせずに、数千人規模のデータガバナンスが実現できる
• ※公式情報
  • User Impersonation
  • How to Enable User Impersonation from Tableau to Snowflake | Immuta

おわりに

「なりすまし」機能は知らなかったので、どこかで検証してブログにしたいと思います。