金融現場から求められるガバナンスと生産性を両立する、属性ベースアクセス制御（ABAC）への挑戦

LayerX Fintech事業部から三井物産デジタル・アセットマネジメント（以下、MDM）に出向しているs.masです。

本記事では現在構築を進めている「属性ベースアクセス制御（ABAC）」の考え方についてご紹介します。

「なぜABACが必要だと考えたのか」「どのような構想を描いているのか」「どう進めようとしているのか」という、構想段階のリアルな思考プロセスを共有するものです。

MDMにおける従来のグループメンバー管理

現在、ID基盤としてMicrosoft Entra IDを利用し、SCIMによる自動プロビジョニングで各種SaaS（Google Workspace、Slack、Notion、AWS、1Passwordなど）にユーザーやグループ情報を同期させています。

しかし、組織の拡大や、MDMのグループ会社設立など複雑な役割や契約形態の増加に伴い、以下のような課題が浮き彫りになってきました。

とりわけ重要なのが「Need To Know（知る必要がある人のみアクセス可能）」の原則です。金融業界では特にこの考え方が重視されており、必要な情報に必要な人だけがアクセスできる状態を保つことが求められます。

例えば、「特定個人情報を取り扱ってはならない業種」が誤ってそのデータにアクセスできる状態や、「兼務不可な業務」を兼務してしまうような状況は絶対に避けなければなりません。

しかし、現状の運用では「正社員_A事業部_Bチーム所属」のようなグループが乱立し、管理が難しい状態に陥ってしまいます。

グループの組み合わせが増加し、誰がどの権限を持つのか、なぜその権限を持つのかを管理することが困難になりつつあります。

この課題を解決するために、今回構築を進めているのが所属部署・役職・雇用形態・職種などの属性情報に基づいて、アクセスの可否を動的に判断する「属性ベースアクセス制御（Attribute-Based Access Control）」による仕組みです。

例えば、「所属部署=コーポレートシステム部の役職=部長のユーザーは、特権管理者としてアクセスを許可する」といったポリシーを定義することで、柔軟な制御が可能になります。

今回の仕組みの特徴は「Subject Attributes（主体の属性）」を中心的な認可判断の要素として扱う点にあります。「属性」は以下のようなものです。

これらの属性情報は、SmartHRのような人事情報システムだけでなく、社内規定のドキュメントなど、社内の様々な場所に散在しています。

多様な情報源から属性情報を整理・集約し、各SaaSや社内システムが理解できる形でポリシーに基づいたアクセス制御を実行できるようにすることで、規定などが更新されたタイミングで即時に正しい状態を維持し続けることができます。

Entra IDや各SaaSが持つアクセス制御の仕組みの中での具体的なアプローチは次の通りです：

属性のモデリング： まず、どのような「属性」が認可に必要かを定義し、モデル化します。
属性情報の集約と連携： 今回作成するシステムが核となり様々な情報源（社内規定や人事情報など）からデータを取得し属性情報を集約します。
整合性の検証： 集約したデータに矛盾がないか（例：兼務不可な業務へのアクセス）を検証します。
グループ生成： 検証結果を基に、必要なメンバーを含むazuread_groupリソースのHCLファイルを生成します。
既存システムへの適用： Terraformを通じてEntra IDに適用し、Entra IDからSCIMプロトコルを通じて各システムに権限設定を伝搬させます。

このアプローチの利点は、既存の仕組みの延長で、属性ベースの柔軟なアクセス制御を実現できる点にあります。初手の実装についてもユーザーの追加・削除などの手動処理を省略できます。

また、すべての検証プロセスはログとして記録され、追跡可能な状態にします。

この仕組みは人事システムだけでなく、契約情報や社内規定といったデータも含め、より多様な情報源を扱っている点に特徴があります。これにより、人事情報だけではカバーできない、より複雑な認可要件に対応しようとしています。

一方でTerraformとEntra IDの制約に依存する形にはなるので将来的には各システムのAPIを直接利用することで、より柔軟で、きめ細かいアクセス制御を見据えています。