ImmutaでSnowflake連携の初期設定(Native Integrationの設定)をしてみた

さがらです。

データセキュリティプラットフォームであるImmutaはSnowflakeと非常に親和性が高く、Immuta上で各種セキュリティ設定を行えば、SnowflakeのRow Access PolicyやMasking Policyが動的に作られ、SnowflakeのユーザーはImmutaの存在を気にせずともクエリを実行すれば勝手に各種Policyが適用されるという連携が可能です。（Immuta上ではこの連携の仕組みを「Native Integration」と呼んでいます。）

今回はImmutaにおいて、Snowflake連携の初期設定(Native Integrationの設定)をしてみたので本記事でその内容をまとめてみます。

※Immuta自体の概要に関しては、下記のブログをご覧ください。

参考ページ

基本的に以下のドキュメントの手順に沿って設定を行っていきます。

使用するSnowflakeアカウント情報の登録

ImmutaのConsoleにログイン後、画面左のメニュー一覧からApp Settingsを押します。

4 Native Integrationsから、+ Add Native Integrationを押します。

Native Integration Typeから、Snowflakeを選択します。

HostとDefault Warehouseを入力します。Immuta Database欄はImmutaによって各種ポリシーが作られるデータベースとなりますが、デフォルトの「IMMUTA」以外の名称が良い場合は変更しましょう。

また、チェックボックスが３つありますが、それぞれの内容は下記になります。

• Enable Impersonation
  • 有効化すると、指定した「Impersonation Role」で別のロールになりすますことができるようです。※詳細は試してみないとわからないのでどこかで試したい…
  • ただし、有効化するとImmutaでの管理対象のテーブル全てにRow Access Policyを適用することになるので、パフォーマンスが悪くなるリスクもあるとのことなので注意です。
  • 私個人の考えとしては、SnowflakeにはPOLICY CONTEXTで別のロールやユーザーになりすまして実行する機能もありますし、パフォーマンスが懸念されるならば無理に有効化する必要はないという印象です。
• Enable Native Query Audit
  • 有効化すると、SnowflakeのACCOUNT_USAGEのQUERY_HISTORYとACCESS_HISTORYを定期的にスキャンし、Immuta上にクエリログとして保持ができるようになります。
• Automatically ingest Snowflake object tags
  • 有効化すると、ImmutaのExternal Catalog機能を有効化し、対象のSnowflakeアカウント上のオブジェクトタグを自動でImmutaへIngestするようになります。

続いて、ImmutaのNative Integrationを対象のSnowflakeアカウントに適用させるため、Immuta用の各種オブジェクトをSnowflakeに作る必要があります。

この方法はImmutaにSnowflakeの認証情報を渡したら自動でオブジェクトを作成してくれるAutomaticと、ユーザー側で必要なスクリプトを実行するManualがあるのですが、基本Automaticで進めるのが楽ですしおすすめです。

ここではAutomaticにした上で、Select Authentication MethodをUsername and Passwordとして、認証情報と使用するロールを入力します。必要な権限はドキュメントにも記載があるのですが、このオブジェクト作成に使う認証情報はImmuta側に永続保持されるものではないですし、ACCOUNTADMINロールを使用するのが手っ取り早いと思います。

次のExcepted Roles/Users Listですが、Immutaで定義したポリシーが適用されないロールとユーザーを入力することが出来ます。

最後に、Test Snowflake Connectionを押します。

すると、少し画面が暗転した後、Successfully Connectedと表示されます。

接続が成功したらSaveを押し、表示されたポップアップではConfirmを押します。

すると、Immutaの画面が暗転し、対象のSnowflakeアカウントでImmuta用のオブジェクトが作られ始めます。私が試したときには、1分程度で完了しました。

この後でSnowflakeを見ると、指定した名前(今回はIMMUTA)でSnowflake上にデータベースが作られ、中には各種UDFやPolicyなどを保持するスキーマが作られていました。

これで、ImmutaとSnowflake連携の一番最初に必要なNative Integrationの設定は完了です！

おまけ：Default Subscription Policyの設定について

これはNative Integrationの設定とは関係ないのですが、今後Data Sourceを新しく追加する前にDefault Subscription Policyの設定を確認することをImmutaのGetting Startedのドキュメントでも推奨しています。

手順としては、App Settingsを押して、7.5 7Default Subscription Policyで設定が確認可能です。

この設定ですが、すでにSnowflakeを運用していてデータを一定数使用するユーザーがいる場合には影響がないようにNoneを選択することをImmutaもドキュメントで推奨しています。

それぞれのオプションの違いを以下に記します。

• None
  • 今後新しいData Sourceを追加した際に、何もSubscription Policyを設定した際に、誰でもデータを見れる状態となっている
  • ユーザー側で閲覧制限をかけたい場合は、別途Subscription Policyの定義が必須となる
• Allow individually selected users
  • 今後新しいData SourceをImmutaで追加すると、Immuta上で個別のユーザーを選択して、選択したユーザーだけがデータを使用できるようになるSubscription Policyが自動で適用されます。
  • つまり、Immuta導入前に使用していたデータを使用していたユーザーは、サブスクライブされるまで使用できなくなってしまいます（突然ユーザーがデータを使えなくなるリスクが生じる）

最後に

Immutaにおいて、Snowflake連携の初期設定(Native Integrationの設定)をしてみました。

これだけではImmutaを使っているとは言えないため、近日中にData Sourceの定義、Policyの定義、などについて書いていこうと思います。