ロール爆発
この記事は https://docs.evolveum.com/iam/iga/rbac/role-explosion/ の翻訳です。
ロールベースのアクセス制御（RBAC） は、多くのアイデンティティ管理デプロイメントで使われているアクセス制御モデルです。 問題は、伝統的な静的 RBAC モデルはスケールしないことです。 数十個程度のロールであれば、RBAC は問題ありません。 接続されるシステムの数が増えるにつれて、ロールの数も増えます。 従業員が1000人いる組織では、簡単に数千個のロールを抱えることになります。 1000人の従業員を管理するという難しい問題が、数千個のロールを管理するという、さらに難しい問題に変わってしまいます。
理由は理解しやすいものですが、決して明白ではありません。
- Cartesian 製品: 銀行窓口係、監督者、支店長のロールがあるとします。
ロンドン、ベルリン、ブラチスラバで業務を行うとします。
London teller、Berlin teller、... といったロールが必要になり、合計9個のロールになります。 ロールの数は非常に速く増えます。
- Atomization: Cartesian 製品は、ロールを再利用可能で再結合可能な単位に分解することで避けられる場合があります。
それらをロール階層を使って「高階」のロールへ組み合わせます。
これにより、9個ではなく6個のロールで済みます。
ただし、窓口係が清掃担当者とアクセス権の一部を共有する場合は別です。
その場合、
Basic branch office accessロール、Teller's IT accessロール、そしてその2つを組み合わせるTellerロールが必要になります。 これで8個のロールになります。 ロールの数は依然としてかなり速く増えます。
- Unique アクセス または ポリシー exceptions: 多くの従業員は、一人ひとり固有のアクセス権セットを持っています。 それらをロールに当てはめようとすると、必然的に、そのような従業員の数と同じか、それ以上の数のロールが生まれます。 これはほとんど意味がありません。
- ポリシーの欠如: RBAC はポリシーの「代替」として使われることがあります。 アクセス制御ポリシーが何であるか分からない場合、とりあえずいくつかのロールを設定して、それでよしとするのです。 これは通常、多数のロールにつながります。ロールは十分な監督や調整なしに作られることが多いからです。 重複（同じ権限セットを持つロール）もよくあります。
- Poor ロール管理: すべてのアイデンティティ管理の概念と同様に、ロールにも ライフサイクル があります。 ロールは作成され、保守され、更新され、最後には廃止されます。 ロール管理はかなり負担の大きい作業であるため、組織はしばしば手を抜きます。 必要になったときにロールが作られます。 ロールに対する更新は少しあるかもしれませんが、通常は権限を追加するだけです。 しかし、ロールを削除する動機はほとんどないため、ロールが削除されることはほぼありません。 これにより、ロールの数は増え続けます。
これは role explosion として知られています。 多くの IDM プロジェクトに見られる深刻な病です。 ユーザー管理を単純化しようという善意で始まったプロジェクトが、開始前よりもはるかに保守困難なロール構造に行き着くことになります。
静的 RBAC モデルではロール爆発 を扱えません。 多少なりとも扱える解決策はいくつかあります。
- Attribute-Based アクセス制御（ABAC）と Policy-Based アクセス制御（PBAC）: 原則は、ロールを持つ代わりに、アクセス権を計算する式を持つというものです。 式はユーザー属性をパラメータとして受け取ります。 非常に柔軟に見えます。おそらく少し柔軟すぎるほどです。 これはロールの形式的な構造をロジックで置き換えます。 つまり、設定ではなくプログラミングになります。 さらに悪いことに、ABAC/PBAC が正しく機能するには、ポリシーが既知で、明確に仕様化され、形式化されていなければなりません。 これは見た目よりもはるかに難しいことです。 また、ABAC ポリシーをプロビジョニングに直接適用することもかなり困難です。ABAC はプロビジョニング時には利用できない context データに依存することが多いからです。 ABAC/PBAC はロール管理の問題を解決できるかもしれません。しかし、ポリシーの複雑さと管理という一般的な問題も解決できるのでしょうか。
- RBAC, but forget about 最小権限: 最小権限の原則が求めるよりも「大きな」ロールを作ります。 意図的にユーザーを over-provision します。付与すべき以上の権限を付与するロールを作るのです。 これによりロールの再利用性が高まり、ロール数を管理可能に保てます。 安全性は低下しますが、一部の環境ではよいアプローチになる場合があります。
- ロールにロジックを加える: 通常これは、ロールをより汎用的にするために ルール を追加することを意味します。
たとえば
London tellerを作る代わりに、ユーザープロファイルから所在地をパラメータとして受け取り、ホームディレクトリへのパスを計算するパラメトリックなTellerロールを作ります。 これは ABAC/PBAC と静的 RBAC の中間にあります。 両方のアプローチのよい特徴を持ち、プロビジョニングシステムでは最も一般的な選択肢に見えます。 たとえば midPoint は、Policy-Driven ロールベースのアクセス制御 を非常に豊富にサポートしています。
- Manage the chaos: ユーザーにアクセス権を要求させ、他の人にそれを承認させます。 これは アクセス申請 プロセスです。 明らかな問題は、不要になった権限をどう取り消すかです。 それらをレビューし、取り消すための別のプロセスが必要になります。通常これは 認定 と呼ばれます。 しかし、認定キャンペーンには膨大な労力が必要です。 これはセキュリティと使いやすさの妥協です。なぜなら、承認または認定すべきでなかったものを承認・確認した人が常に存在するからです。 特に、承認が「ざっと見て問題なさそうなら承認する」という形で行われることが多いことを考えると、問題は深刻です。 毎日何百件もの要求を承認しなければならない人に、十分な精査を強制するのは困難です。
実用的なエンタープライズ IDM ソリューションでは、おそらくこれらの仕組みのうち1つだけではなく、すべてが必要になります。 プロビジョニングシステムでロール爆発 と戦ううえで、動的ロールと承認は最も重要な2つの機能です。