🔐

Data Security Platform のImmuta について

2024/06/17に公開

Security

本記事の背景

本記事は、某所でデータアクセス管理ポリシーの一種である ABAC (Attribute-Based Access Control) を SaaS と提供している　Immuta の導入是非を検討する際に作った議論メモです。実際には見送りとなり、トライアルアカウントを作成しての PoC も行いませんでしたので、ドキュメントベースでの調査です。

（注）ABAC の概要については後述。

Immuta 製品の概要

以下の Product Tourは、Immutaの製品概要を知る上で最初にみると良い。製品の主な機能分野としてDiscover、Secure、Detectの3つがある。

Discover - データのカテゴリを自動検出し、タギングする

主にアメリカ市場向けに作られていると思うので、どの程度、日本企業のデータ分類に対応できるかは不明。カスタムのポリシーも作成できる。

Secure - データアクセスポリシーを自然な英語で記述できる

https://www.immuta.com/product/secure/

UI 上で、 ABAC に対応したデータのマスキングポリシーやアクセスポリシーを自然な英語のようなフォーマットで作れる（日本語対応は不明）。コードを書く必要はない。データプラットフォーム外部のセキュリティポリシー担当者にポリシーを作ってもらうことができる。

IdP やガバナンスツール（Collibra など）と連携できるので、ユーザの属性は IdP などから、テーブルの属性はガバナンスツールから取り込むことができる。

以下はポリシービルダーでポリシーを作成中の例

ポリシー名 Mask PII - PII・個人情報をマスクする
How should this protect data? どのようにデータを保護するか?
Mask column - カラムをマスクする
- tagged Discovered > PII - そのカラムは “Discovered > PII” のタグ付けがされている。（注: このタグは Immuta の機能によって PII (個人情報)と判断されたコラムに自動で付与される）
- using hashing - ハッシュを使って
- for everyone except - 以下の条件の人以外全員
  - when user is acting under purpose Fraud Detection - ユーザが Fraud Detection （不正行為の検出）の目的でアクセスしている
  - and possesses attribute in Department Finance - そしてそのユーザがファイナンス部署の属性がついている

Snowflake と Immuta を連携することで、Immuta がアクセスポリシーやマスキングポリシーを Snowflake 側に作ってくれる。

Detect - ユーザの利用履歴を監視し、リスクを事前に検出

https://www.immuta.com/product/detect/

ユーザの利用履歴を監視し、リスクを事前に検出してくれる。

Secure のユースケース

テーブルアクセスポリシーの決定を自動化したい

RBAC の課題は、データアクセスポリシーがロールに紐づけられているため、アクセスのパターンが増えるたびにロールが増えていく、いわゆるロール爆発（アクセスロースの数が爆発的に増えてしまう）という現象が起きる点。またユーザとロールの関係が固定的。

Immuta の採用する ABAC の場合、ユーザの属性（メタデータ）とデータの属性（メタデータ）によってアクセスの可否が動的に決まる。この属性によるアクセスの可否は、アクセスコントロールポリシーによって記述される。これにより、データアクセス可否申請などの人間の介在（ human-in-the-loop ）の余地を減らすことができ、データアクセスのスピードを加速できる。

ABAC の定量的な恩恵

同じユースケースに対してRBACより75%少ないポリシーで対応できる。
データアクセスポリシーの管理に携わる人員の数を70%減らせる。

データメッシュやセルフサービスのデータアクセスのための Federation 型ガバナンス

Federated Governance は連合型ガバナンスともいう。各ドメインごとにデータを管理してて、それぞれガバナンスポリシーを持って、各自責任を持ってデータを管理しており、それらが連携し合う。

ドメイン単位でデータを分割統治でき、それぞれのドメインでポリシーを作成できる。

ABAC (Attribute Based Access Control)

ABACの概要

より一般的に用いられている RBAC はシステムのリソースに対応するアクセス権限をロールに付与し、そのロールをユーザに付与することで、ユーザに対するシステムのリソースアクセス権限を管理する方式。古くからある方式で、あらゆるサービスが RBAC を採用している方式のため、システム管理者にとっては馴染みのある方式。一方で、アクセスパターンが多様化すると、用意する必要のあるロールの種類が爆発的に増加するため、アクセス要件が複雑な組織では管理が困難になるケースもある。

一方、 ABAC データとユーザの属性に着目し、アクセス可否を動的に判断する方式。 RBAC に対してより柔軟なポリシー記述が可能であり、一般的には RBAC でのロール数より ABAC のポリシー数の方が少なくなる傾向にあると言われている。

RBACとABACの比較

ABACの例

Microsoft Entra ID

Microsoft Entra ID は ABAC に対応している。

製薬企業 Roche での分散型データ管理

Roche という製薬企業がデータメッシュ型に移行し、アクセスコントロールの仕組みも変更した。元々、生産拠点にエンジニアやデータサイエンティストが在籍して、分散型の組織体制になっていたため、データメッシュ型に移行する合理性があった。
元々は RBAC でアクセスコントロールを行おうとしたが、ロール爆発が起こり、管理不能に陥り、　ABAC への移行を検討し、　Immuta を導入した。
ABAC では、データには属性があり、ユーザにも属性があり、サブクスリプションポリシーとして、ユーザがデータにアクセスできる際のデータの属性とユーザの属性の組み合わせを記述する。
データの属性はデータプロダクトの開発者がデータプロダクトの設定として記述しておき、マーケットプレイスにリリースする際に、 CICD パイプラインによってタグづけされる。
データの利用者はマーケットプレイスでデータのサブスクリプションのリクエストを行う。データオーナが許可すると、それ以降は同じ属性の人はデータにアクセスできるようになる。
重要な点は間にデータプラットフォームチームが介在しないこと。

Snowflakeとの連携の仕組み

Snowflake連携での機能対応具合は以下を参照

Immuta と Snowflake を連携すると、 Immuta が Snowflake 内に専用のデータベースを作り、そこに管理情報を入れる。また Snowflake の行レベルのアクセスポリシーとマスキングポリシーを管理する。 Snowflake に管理された状態で、ユーザーは Snowflake に直接クエリできる。

Immuta は、 memorizable UDF を利用し、関数のキャッシュを保存する。ユーザがポリシーの適用されたコラムにアクセスする際、キャッシュを利用してクエリのパフォーマンスを向上させる。

導入にあたっての注意事項

Immuta のメリットとしては、 Databrics や Snowflake など複数のサービスのアクセスポリシーを一元管理できる点、または非技術者でもコーディングなしでポリシーを書ける点などがある。後者についてはプラットフォーム管理者の介在なく、アクセス管理ポリシーを整備できる可能性もあり、プラットフォーム管理者の負荷軽減につながる。

一方で、 Immuta を導入するとアクセス管理ポリシーはほぼプロプライエタリ製品である Immuta で管理することになる。これはベンダーロックインにつながる。また、ポリシーの数が増えたときに、ポリシー同士の整合性はどう担保するのかを考える必要がある。また、プラットフォームの十分な知識なくアクセスポリシーを書くのは不可能であり、結局は、プラットフォーム管理者がポリシーをレビューする必然性が出てくる可能性があり、必ずしも Immuta の導入がプラットフォーム管理者の負荷軽減につながらない可能性も考えうる。

おわりに

以上、 Immuta の調査内容でした。
もしすでに導入済みで、こういうところいいよという方、いらっしゃればコメントいただけると助かります。