こんにちは。株式会社FLINTERSの津布久です。
今回の投稿はFLINTERSブログ祭りの記事になりまして、Snowflake上で行アクセスポリシーを適用したテーブルのデータシェアリングで失敗したことについて記載します。
テーマとしては#技術 #データ #DWHです。
行アクセスポリシーとは
Snowflakeのテーブルやビューといったオブジェクトに、条件や関数を設定したポリシーをアタッチすることで見せるデータを制御する仕組みとなります。
オブジェクトごとでロールに対して閲覧権限や編集権限を設定することはできますが、テーブルの中身までは制御できないため上記の仕組みが必要になってきます。
イメージとしては、1つのテーブルに会社情報を格納している状況で、ユーザーが在籍する部署情報のみ閲覧できる状態にすることができます。
もちろん、そのほかの部署のデータを閲覧・活用できないため、セキュリティのリスクというのも低くなりますね。
データシェアリングとは
アカウントAに存在するデータベースやテーブルをアカウントBが利用できるようにするといった仕組みになります。
もちろん、アカウントBからアカウントAにデータを共有して利用することも可能です。
データを共有する側はプロバイダーと呼ばれ、共有オブジェクトを作成しそこにデータベース・スキーマ・テーブルといった各オブジェクトの権限を付与します。
共有オブジェクトを別アカウントに対して公開することで、そのアカウントは共有オブジェクトから権限が付与されたオブジェクトを作成することができます。
データを共有される側をコンシューマーと呼ばれ、共有されたオブジェクトに対するINSERTやUPDATEといった編集を行えないといった制限があります。
私が利用したことがあるのはアカウントを指定して共有する方法のみですが、そのほかにもSnowflake Marketplaceでより範囲を広くした共有というのも可能なようです。
行アクセスポリシーを適用したテーブルのデータシェアリングで失敗した話
1つ目の失敗は行アクセスポリシー適用によるデータシェアリングへの影響の把握ができていなかったことです。マッピングテーブルを利用する行アクセスポリシーの適用を行なったあと、コンシューマー側で以下のようなエラーが発生し一時的にデータの利用ができなくなってしまいました。
エラー発生後すぐに適用前の状態に戻してから色々確認を行ったところ、共有オブジェクトにマッピングテーブルが存在するデータベースのREFERENCE_USAGE権限の付与が必要であることがわかりました。この権限は共有オブジェクトにおいて、オブジェクトが別データベースにあるオブジェクトを参照する場合に利用を許可するような権限です。
2つ目の失敗がREFERENCE_USAGE権限を付与する共有オブジェクトを勘違いしていたことです。マッピングテーブル用に別途共有オブジェクトを作成し、そこにREFERENCE_USAGE権限を付与していました。
// 失敗パターン // access_policyデータベース用の共有オブジェクトにaccess_policyデータベースのREFERENCE_USAGE権限を付与 GRANT USAGE, REFERENCE_USAGE ON DATABASE access_policy TO SHARE access_policy_share;
そのためエラーが解消せず、再度確認を行ったところ、アクセスポリシーを適用したテーブルが存在する共有オブジェクトに対して権限追加が必要であることがわかりました。
上記を踏まえて、共有オブジェクトに権限付与を行ったところ、無事にコンシューマー側でデータを利用できることを確認しました。
// 成功パターン // aaaデータベース用の共有オブジェクトにaccess_policyデータベースのREFERENCE_USAGE権限を付与 GRANT USAGE ON DATABASE aaa TO SHARE aaa_share; GRANT REFERENCE_USAGE ON DATABASE access_policy TO SHARE aaa_share;
また、ブロバイダー側は以下クエリで共有オブジェクトに付与した権限一覧を見ることができるので、今どんな権限を設定しているか確認したい時は便利だなと思いました。
SHOW GRANTS TO SHARE aaa_share;
失敗談については以上で、新機能を利用する際は既存システムへの影響を確認することは重要だなと今回の件で実感しましたね。幸いSnowflakeはドキュメントが豊富に整備されているので、調査の際も調べやすかったなと思いました。
今後も利用できる機能は増えていくので、うまく吸収していきたいですね。
