さがらです。
ImmutaのABACとGlobal Subscription Policyを用いて特定のグループのユーザーだけにデータのアクセス権を付与してみたので、その内容を本記事でまとめてみます。
ABACとは
ABACとはAttribute-based access controlの略で、ユーザー、データなどに紐づく複数の属性(Attribute)の情報を元にデータアクセスを許可・制限するアプローチです。
Snowflakeなどでも採用されているRBAC(Role-based access control)は、１つのロールごとに固有の権限を持たせてアクセス権を管理する手法ですが、ユーザーの属性情報(部署・役職・etc)など複数の情報に基づいてアクセス権を管理しようとすると、１つのロールでアクセス権を管理することがつらくなってしまい多くのロールを作らなければいけないケースが発生しうると思います。
その点、Immutaで採用しているABACでは、ユーザーの属性情報、データのタグ、など複数の情報を用いてアクセス権の制御を行えるようになるため、より複雑なセキュリティ要件であってもロールをたくさん作ることが発生せず運用が楽になるメリットがあります。
ImmutaのABACについては以下の記事でも説明がされているため、こちらも併せてご覧ください。
Global Subscription Policyとは
Immutaでは「対象のデータソースをどのユーザーに見せるか」という条件をSubscription Policyとして定義しますが、Immutaで管理しているデータソース全体に適用されるSubscription Policyが「Global Subscription Policy」です。
Global Subscription Policyについて詳しくは下記のブログでまとめられていますので、実際にどのような条件で設定が出来るか知りたい場合はこちらのブログをご覧ください。
本検証で行うこと
組織の中にHRグループとSalesグループがあり、HRグループにしか見せたくないCOMPANY_EMPLOYEESテーブルがSnowflake上にあるとします。
ここで以下２名のユーザーについて、HRグループに属するIMMUTATEST_SAGARA2にだけCOMPANY_EMPLOYEESテーブルを見せることができるよう、Immuta上で設定をしてみます。
IMMUTATEST_SAGARA2：HRグループに属するため、COMPANY_EMPLOYEESテーブルを見せたいIMMUTATEST_SAGARA3：Salesグループに属するため、COMPANY_EMPLOYEESテーブルを見せたくない
事前準備
Snowflake上でのユーザーの作成
まず今回の検証にあたり、連携先となるSnowflake上でユーザーIMMUTATEST_SAGARA2とIMMUTATEST_SAGARA3を作成しておきます。
この時点ではPUBLICロールしか付与されておらず、サンプルデータのDBしか見えない状態です。
Immuta上でのユーザーの作成
続いて、Immuta Accounts上でもIMMUTATEST_SAGARA2とIMMUTATEST_SAGARA3のメールアドレスを用いて、ユーザー作成しておく必要があります。
今回はAdd Multiple Usersを用いて下図のように作成しました。
この上で、使用するImmutaのインスタンス上でもこれらのユーザーを追加しておきます。Sync IAM Usersを押せば、新しく追加したユーザーをImmutaインスタンスに追加することが出来ます。
また、各ユーザーをImmutaインスタンスに追加した後、ImmutaとSnowflakeを紐付けるためにSnowflakeのUsernameを変更しておきます。
Immuta上のユーザーの画面から、左上の名前の横の点々を押し、Change Snowflake Usernameを押します。
ここで、SnowflakeのユーザーのProfileで確認できるUsernameを、表示されたポップアップのSnowflake Usernameに入力し、Saveを押します。
Immuta上でのGroupの定義
今回はImmutaのGroup機能を用いて、HRグループとSalesグループの作成を行います。
ImutaのPeopleメニューから、Groupsタブを押し、+ New Groupを押します。
Group NameやGroup Descriptionを入力し、Saveを押します。
続いて、+ Add Membersから対象のユーザーを追加します。
Search by Member Name or EmailからImmutatest sagara2を探し、選択します。下図の状態になっていれば、対象のグループにメンバーが追加された状態となっています。
同じ手順で、Salesグループを作成し、Immutatest sagara3を追加しておきます。作成後の対象グループの画面が下図になります。
参考：Groupに対するAttributesの定義
また、Groupに対してAttributesという形で属性情報を付与することが出来ます。
この機能を使うと、１つのGroupに対して別の属性情報を複数付与することが可能となり、後述するGlobal Subscription Policyの定義時にこのAttributesを用いて条件設定することも可能です。
複数Groupに共通する属性情報などがあれば、このAttributesを使うことでより効率よくGlobal Subscription Policyの定義ができそうですね。
Immuta上でデータソースにタグを紐付ける
続いて必須の設定ではないのですが、データソースに対してグループ毎のタグを設定すると今後もHRグループ専用のデータが作成されたときに自動的にアクセス権を付与することができるため、データソースに対するタグの紐づけを行っていきます。
タグの作成
まずはタグを作成するところからです。
ImmutaのGovernanceメニューから、Tagsタブを押し、+ Add Tagsを押します。
今回は部署に関するタグを作成するため、Enter tag nameのところにdepartmentと入れます。
続いてAdd Child Tagを押し、hrとsalesという部署名に当たるタグを追加します。同じ階層でタグを作りたい場合は、Add Sibling Tagを押せばOKです。
下図のように、departmentタグの子タグとしてhrとsalesができていればOKです。この状態になったらSaveを押せば、タグの作成は完了です。
タグをデータソースに紐付ける
続いて、作成したタグをデータソースに紐づけていきます。
対象となるCOMPANY_EMPOLOYEESテーブルの画面を開き、Overvuewタブで+ Add Tagsを押します。
Search by Tag Nameから、先程作成したdepartment.hrを探し、クリックします。
選択したら、Addを押します。これでデータソースへのタグの紐づけは完了です！
Global Subscription Policyの作成
これまでに定義したグループやタグの情報を用いて、どのユーザーにデータのアクセス権を付与するのかの条件を定義するGlobal Subscription Policyを作成していきます。
ImmutaのPoliciesメニューから、Subscription Policiesタブにおいて+ Add Subscription Policyを押します。
まず、What is the name of this policy?に作成するポリシーの名称を入力します。
続いて、How should this policy grant accesses?では作成したグループに属するユーザーにアクセス権を付与したいので、Allow users with specific groups/attributesを選択します。
すると、具体的にどのグループに対してアクセス権を付与する(Subscribeする)かの条件を定義するWho should be allowed to subscribe?が出てきます。
最上部のチェックボックスはCreate using plain languageのままにしておくことでGUいベースで条件の定義ができます。
次のAllow users to subscribe when userでは、select conditionでis a member of groupを選択します。これで特定のグループに属しているユーザーを対象と出来ます。
続いてsearch for groupでは、作成したグループであるsagara_hrを選択します。
また、Allow Data Source Discovery３つチェックボックスがあると思います。こちらのブログからの引用ですが、このような意味合いを持っていますので必要に応じてチェックしてください。
- Allow Data Source Discovery
- 条件に該当しなくても、そのデータソース自体の表示は許可します（存在がわかる）。
- Require Manual Subscription
- 条件に該当していても、サブスクリプションはユーザー側が手動で行う必要があります（Allow Anyoneの時のチェックボックスと同じ）。
- Request Approval to Access
- 条件に該当しなくても、アクセスのリクエストを行うことができるようになります。
- この設定をONにする場合、リクエストが来た時の承認者を決める必要があります。
次の項目Should this policy always be required or share responsibility?ですが、これは対象のデータソースに対して複数のGlobal Subscription Policyが設定されている場合の挙動を決めることができます。
Always Required：他のGlobal Subscription Policyの条件も満たしていないと、対象のデータソースを見ることができません。Share Responsibility：他のGlobal Subscription Policyの条件含め、１つでも条件を満たしていれば対象のデータソースを見ることができます。
最後のWhere should this policy be applied?ですが、このポリシーを適用するデータソースを決める設定です。
先程hrタグを設定したデータソースのみに絞り込みたいため、On data sourcesを押します。
select circumstanceですが、taggedを選択します。
search for tagsで、作成したdepartment.hrのタグを選択します。
この設定後、対象となるデータソースの数が表示されます。department.hrのタグを紐づけたのは１つだけなので、合っていますね。
あとはCreate Policyを押して、すぐに有効化するためActivate Policyを選択すれば、Global Subscription Policyの作成は完了です！
挙動確認
では、実際に連携先のSnowflakeでどうなっているかを見てみます！
HRグループに属しているユーザーの場合
まず、HRグループに属しているIMMUTATEST_SAGARA2でみてみます。
IMMUTATEST_SAGARA2でSnowflakeにログインしてみると、Immutaにより作られたロールがあることがわかります。IMMUTA_POLICY_...で始まるロールは各ポリシーごとのロールとなるので、IMMUTA_USER_...で始まるロールを選択すればOKです。
この上で、IMMUTA_USER_...で始まるロールを選択すると、データの内容を無事に確認することが出来ました！
HRグループに属していないユーザーの場合
続いて、HRグループに属していないIMMUTATEST_SAGARA3でみてみます。
IMMUTATEST_SAGARA3でログインしてみると、このユーザーに対してImmuta経由でSubscribeしているデータがないため、Immutaで作られたロールも付与されていませんでした。
おまけ１：新しくHRグループのユーザーを追加するとどうなるか？
ここからはおまけですが、まずは新しくHRグループにユーザーを追加するとどうなるかを確認してみます。
これまでの検証ではHRグループに属していなかったIMMUTATEST_SAGARA3を、sagara_hrグループに新しく追加してみます。
この上でSnowflakeにIMMUTATEST_SAGARA3でログインしてみると、Immutaで作られたロールが付与され、COMPANY_EMPLOYEESテーブルが見れるようになっていました！
おまけ２：HRグループからユーザーを除外するとどうなるか？
次は逆に、HRグループからユーザーを除外するとどうなるか見てみます。
さきほどおまけ１でHRグループに追加したIMMUTATEST_SAGARA3を、sagara_hrから除外してみます。
この上でSnowflakeでIMMUTATEST_SAGARA3でログインしてみると、IMMUTA_POLICY_...で始まるロールが使えなくなり、COMPANY_EMPLOYEESテーブルが見れなくなっていました。
グループから除外した際のアクセス権の削除も即座に行ってくれるのはありがたいですね！！
おまけ３：新しくHRタグを紐づけたデータソースを追加するとどうなるか？
おまけの最後に、新しくHRのタグを紐づけたデータソースを追加するとどうなるかを確認しておきます。
適当なデータソースに対して、department.hrタグを追加します。
この上で、HRグループに属しているIMMUTATEST_SAGARA2でログインしてみると、department.hrタグを追加したUSERS_COL_EN_DATA_ENを見ることができるようになっていました！
最後に
ImmutaのABACとGlobal Subscription Policyを用いて特定のグループのユーザーだけにデータのアクセス権を付与してみました。
一度タグやグループなどを用いてGlobal Subscriptionポリシーを設定しておけば、部署の異動などでユーザーが所属するグループが変わったときに即座に自動的にアクセス権を付与したり削除したりできるので、データアクセス権を管理する運用が非常に楽になると感じました！
7
