ゼロトラスト 2022.12.16

目指せ！理想のID管理#2 ユーザ認可の落とし穴、権限付与の２つのポイント

IDaaS
IGA

3行でわかる本記事のサマリ

ID管理の領域と機能は、IAM（認証部分の強化）、IGA（ID管理・ガバナンス）、PAM（特権アクセス管理）の3つに分けられる。
企業がID管理やガバナンスを実施する必要がある理由は、承認ワークフローの形骸化や棚卸の不備によって、内部不正やセキュリティ事故が発生するリスクがあるため。
リスクベースの承認ワークフローと棚卸を導入することで、最小権限の付与やリスクの可視化が可能となり、形骸化を予防し、セキュリティを強化できる。

1. はじめに

本シリーズ「目指せ！理想のID管理」では、企業のID管理を見直す必要のあるお客様を支援するべく、
ID管理に必要な観点を段階的に記事にしていきます。

前回はID管理の理想像について説明しました。
　前回の記事を読む>>目指せ！理想のID管理#1 「ID管理の理想像」とは？

IDaaSで実現可能な認証強化やユーザビリティの向上以外にも考慮しなくてはならない重要な観点がある、
ということがお分かりいただけたかと思います。

本記事ではIDaaSでは不十分な「認可」の観点に絞って、
ユーザに権限を付与する際にどのような点を考慮する必要があるのか考えていきたいと思います。

2.IDaaS以外のID管理の領域と機能とは？

ID管理を担うソリューション領域は主に３つあります。

　①認証部分の強化：IAM(Identity Access Management)
　②ID管理・ガバナンス：IGA(Identity Governance & Administration)
　③特権アクセス管理：PAM(Privileged Access Management)

これら３つのソリューション領域の機能を簡単にまとめると下図となります。

図１.png 図１. 各ID管理ソリューションと機能

各機能の内容については#1の記事で記載したとおりですが、
なぜ、ソリューションを導入してまでID管理やガバナンスを実施する必要があるのでしょうか。

アクセス要求/承認やそれを回すためのワークフローは、既存の製品(ITSMなど)でまかなえている部分もありますし、
棚卸も年に一回もしくは内部監査のタイミングで現在も行っているかと思います。

実は、その答えに「ユーザ認可」において、企業が見落としがちな重大な課題があるのです。

3.ユーザ認可において企業が陥りがちなポイント

下図のような、一般的な企業における承認ワークフローを見ていきましょう。

図２.png
図2. 一般的な企業における承認ワークフロー

申請者（エンドユーザ）：
　新しく利用したいサービスのアカウントの新規作成・権限の付与を申請
　合わせて、そのサービスを利用したい理由をコメントで記載

承認者１（課長）：
承認者２（部長）：
　申請を受けて、承認・否認の判断
　申請内容が本当に必要なのかどうかコメント内容から妥当性を判断し、承認の場合は次の承認者へ申請を回す

最終承認者（システム責任者）：
　申請を受けて、承認・否認の判断
　承認の場合はアカウントが作成、権限が付与され、ユーザがサービスを利用できる

しかし、実際に行われている承認ワークフローは、このような理想的な判断が行われていないことが多々あります。

エンドユーザや利用するサービスが増えるほど申請の数も肥大化し、承認者の負荷が高まってしまい、
結果として申請の内容を詳細に判断しきれず承認してしまう恐れがあります。

上述の例だと、申請内容が適切かどうかを判断する基準が、ユーザのコメントに限定されている点も問題です。

承認者はいちいちコメントの内容を詳細に確認する必要がありますし、
部長、システム責任者と承認フローが進むほど、エンドユーザとの関係性が遠くなり、
コメントの内容が適切かどうかの判断がしづらくなります。

このように承認ワークフローのが形骸化し、
不必要な権限をユーザへ付与してしまうことやリスクの高い権限を知らずに渡してしまうといったミスに繋がり、
最終的には、思わぬところから内部不正やセキュリティ事故が発生してしまうといった恐れがあるのです。

図3-3.png 図3. 形骸化した承認ワークフロー

ユーザやサービスの棚卸も同様に形骸化が起こりがちです。

最小権限を持続するために、ユーザがどのようなサービスにアカウントを持ち、
そのアカウントにはどのようなアクセス権限が紐づいているか、定期的に見直すことが大切です。

棚卸の対象範囲は、主にユーザが所持するアカウント・権限やアプリケーション、
時にはユーザの属性や職務に基づいたロール、と利用用途によって多種多様な棚卸を実施する必要があります。

図４.png 図4. 棚卸の対象範囲

しかし、ユーザ数や利用サービスが増え続けると棚卸の実施工数が増え、
ユーザの所持するアカウントや権限をすべて見直すことはほとんど不可能に近いです。

結果的に棚卸も形骸化してしまい、本来剥奪すべき権限を見直せず、
不必要な権限を永遠と保持してしまう恐れがあるのです。

4.リスクベースで判断する承認ワークフロー

承認ワークフローの形骸化の予防策として、申請内容に紐づくリスクに基づいて承認・否認を判断する
「リスクベースの承認ワークフロー」が、IGAソリューションにはあります。

申請に含まれるアカウントやアクセス権限が、高リスクな権限かどうか、職務分掌違反を起こしていないかなど、
アプリケーションごとに存在する様々なリスクに基づいて承認決定を行うことができます。

リスクに基づいて承認判断を行うことによるメリットは主に２点あります。

１つは、本当に承認が必要な申請のみ承認を行い、承認が不必要な申請は自動承認とすることができる点です。

リスクの低い権限や誰もが持っている権限などは、逐一承認者の判断を仰がずとも付与して良い権限とみなして自動承認とします。
そうすることで、ユーザの申請の総数自体が削減され、承認者の負荷が減ります。
承認者は本当に判断が必要な権限に絞って、承認決定を行うことができます。

図５.png 図5. リスクに基づいた承認ワークフローのイメージ図

次に、承認者は申請内容に紐づくリスクを見ることができる点です。

ユーザが申請時に記載したコメントだけではなく、
リスクが高いか低いかを確認することで、申請者と直接関わりがない承認者も適切な判断を行うことができるのです。

リスクが"Critical"や"High"と非常に高い評価になっていた場合、
少なくとも何も考えずに承認してしまうといったことなくなるでしょう。

図６.png
図6. 承認者目線での申請内容に紐づくリスクの見え方（IGAソリューション：Saviynt）
　　リスクの低い権限はSafe、高いものはRiskyと確認することができる

このように、あらゆる機能を組み合わせてアカウントや権限のリスクを可視化し、
承認ワークフローに取り入れることで権限付与における形骸化を予防し、
最小権限の付与を実現することができるのです。

5.棚卸しにもリスクベースの考え方

棚卸も同様にリスクに基づいて判断を行うメリットがあります。

下図のように、承認ワークフローと同様にユーザの所持するアカウントやアクセス権限に
どのようなリスクがあるのかが可視化されます。

図７.png 図7. リスクベースの棚卸（IGAソリューション：Saviynt）

例えば、"High Risk"と表記されているものだけ見直しを行う、
SoD（職務分掌）やOut of Band（管理対象外で付与された権限）、外れ値分析などの結果を基に
権限の見直しを行うことで、最低限のリスク維持を担保することができます。

「権限の許可/否認」「一時的に許可」「他の人に確認を求める」など
様々なアクションを実施することができ、柔軟に棚卸を行うことができます。

全てのユーザ、全てのアカウント/アクセス権限を見直すことは不可能であっても、
最低限リスクがないように権限付与状況を見直すことが、IGAソリューションでは実現できるのです。