1.はじめに
2.「SSOの導入」を例に考える
例えば、企業内の複数の業務アプリケーションや自社で提供する複数のコンシューマ向けアプリケーションに対してSSO（Single Sign On）の仕組みを導入することで、「アプリごとに実施していたユーザ認証の回数を減らしたい」、「様々なサービスのIDを紐づけて消費者の行動を見える化し、マーケティングに活用したい」といった要望は多く聞かれます。
SSOとは、一度の当人認証を行うことで複数のアプリケーションにログインできるようにする仕組みであり、ユーザ利便性の向上だけでなく、ID/パスワードのアプリケーションごとの分散管理を不要とするなどセキュリティ面でのメリットも期待されます。SSOの仕組みを導入するということを考えると、もちろん自社開発も可能ですが、パッケージ製品やサービス（IDaaS）の利用を選択される方も多いかと思います。基本的にはそれらパッケージ製品・サービスを導入し、パッケージ製品・サービスが提供するSSOの方式に基づいて設定やSSO対象アプリケーションの仕様変更を行うことでSSOの仕組みは導入することが可能です。それでは、「SSOの導入」を考えるということは自社の要件にフィットするパッケージ製品やサービスの選定のみを行えばよいのでしょうか。
図1：SSOはIAMの氷山の一角
残念ながら、それだけでは「SSOの導入」後の状態として思い描いていた姿には至らないことが多いです。SSOを実現するためには「ユーザを管理するリポジトリを一つに統合できるか、分散管理とするか」、「SSO対象アプリID連携をどのように実施するか」、「認証後のアプリごとのアクセス制御はどのようなルールで実施するか」など、見えづらいですが検討すべき内容が様々存在します。次のセクションにてIAMの仕組みを導入する際に検討いただきたい観点と内容、いくつかの具体例を紹介します。
3.IAMの検討に必要な観点
前セクションではSSOの方式だけを気にしてパッケージ製品やサービスの選定のみを行うという極端な例を示していたため、それだけでは検討が不十分である点は自明であったかもしれません。ただし、ある程度の検討を行った場合でも、「SSOの導入を検討していたが、ID管理がアプリケーションごとの個別管理となっており、その統合から検討が必要になった」、「SSOの要件からIDaaSの導入を検討していたが、IDのライフサイクル管理機能が不足しており、サービスの見直しが必要になった」、「運用時に想定していたユーザによるセルフサービスの機能が不足していた」などのギャップは発生する可能性があります。これら検討内容の抜け漏れを少しでも減らすための整理軸の一例として下表を示します。
| 観点 | 主な検討内容 | 具体例 | |
|---|---|---|---|
| EIAM | CIAM | ||
| 身元確認 （Proofing） | サービス上のアカウントを作成するにあたりユーザの身元、登録属性情報の確認手法を検討する。提供するサービスにおけるセキュリティリスクとユーザ利便性に合わせた身元確認手法が求められる。身元確認手法としては、オンライン上での自己申告で完結するものから、対面での身分証による確認によるものまで様々な選択肢が考えられる。 | 協力会社社員、アルバイト従業員用のアカウント発行にあたり、一定程度の身元確認は行いたいが、対面での身元確認が困難な状況が想定される。そこで、非対面で一定程度の身元確認を行える手法として、eKYCの利用を検討する。 | 改正犯収法などを考慮し、自社サービスに必要と考えられる身元確認の厳密さの要件を確認する（SMSの送達確認で十分とするのか、対面での身分証確認を求めるか等）。 アカウントの初期登録時だけでなく、パスワード忘れ時などアカウントリカバリの対応に必要と考えられる身元確認の厳密さの要件も確認する。 |
| ライフサイクル管理 （Life Cycle Management） | ユーザのアカウントが作成されてから削除されるまでの管理方法や周辺系システムへのアカウント情報の集配信の要件や仕組みを検討する。また、利用者識別子の体系や種類、管理方針についても検討を行う。運用者による作業、システムによる自動処理、ユーザによるセルフサービスなどを適切に組み合わせて管理を行うことが期待される。 | 入社、退社、異動、昇格/降格、出向などの人事イベントに応じてアカウントの状態（有効/無効）やそのアカウントが持つ属性やロール/権限がどのような変化すべきかを整理する。 アカウントの状態変更の連携先となるシステムやその連携方式を整理する。 複数のIDが存在する場合、ID統合や紐づけの方法について検討する。 | ユーザが自身の属性情報を更新するための仕組み（セルフサービス機能）の要否を確認する。 |
| 当人認証 （Authentication） | ユーザ当人によるアクセスであることを確認するための認証方式を検討する。検討にあたっては、セキュリティ上考慮すべき脅威（フィッシング、リスト型攻撃など）の洗い出しを行った上で必要な認証方式を採用する。対策の必要性に応じて、多要素認証やリスクベース認証の要否、FIDO2（WebAuthn）への対応検討も本項目で実施する。 | 機密情報へのアクセスに対して、社員間でのID/パスワードの貸し借りなどによる不正利用の可能性を考慮し、ID/パスワードだけでなくセキュリティトークンや社員証を用いた追加認証の実装要否を確認する。 | リバースブルートフォース攻撃や中間者攻撃型のフィッシングへの対策としてWebAuthnの実装を行うか検討する。 |
| ID（認証）連携 （Federation） | 認証が必要なシステムの洗い出しを行った上で、システム間でのシングルサインオン、シングルログアウトの要否や認証のタイミングで各システムに連携すべきユーザ属性情報を整理する。また、システムに対する認証結果の連携にあたっての接続要件（システムへの接続経路や認証結果の連携に利用可能なプロトコル）に注意する必要がある。認証結果の連携に利用可能なプロトコルとしては、OpenID Connect, SAMLなどがある。 | お客様や協力会社の認証基盤との連携要否を検討する。 グループ会社間の認証基盤の連携要否を確認する。 社内で用いるSSOのプロトコルや連携する属性情報の種類やフォーマットを検討する。 | ソーシャルログインなど外部IDとの連携要件を確認する。 自身のサービス上にユーザが保持している情報を他社サービスにも開放することを想定して、認証結果の連携に加えて、ユーザによる権限移譲の機能を持つOpenID Connectをシングルサインオンのプロトコルとして使うことを検討する。 |
| 認可 （Authorization） | ユーザに紐づくロールや属性に応じてシステムへのアクセスを制限する、ユーザからの同意に基づき権限が委譲されていることを確認してシステム上のリソースへのアクセスを許可する、などシステムに必要なアクセス制御のモデルを整理し、検証の仕組みを検討する。 | 所属組織やプロジェクトグループ、役職などを基にしたアクセス制御のルールを検討する。 | 有料会員のみ閲覧可能なコンテンツを設けるため、認証基盤でのユーザ認証後にユーザ属性として会員種別を改ざんできない形で連携させ、コンテンツへのアクセス制御機構での認可に利用する仕組みを検討する。 |
- Enterprise向けのIAM（EIAM）とConsumer向けのIAM（CIAM）については共通点はあるもののそれぞれ個別に検討すべき内容が存在するため、列を分けて記載します。
- 本稿ではIDプロビジョニングに関する観点はライフサイクル管理に含めて考えることとしています。
4.おわりに
IAMにおいて上表で述べた観点についてはどれか一つでも検討が漏れていたり不十分であったりした場合、結果としてサービスに対して不正アクセスや不正ログインが行われてしまう可能性があります。IAM導入検討の初期段階から各観点に関して網羅的な検討を行っていただき、IAMの仕組みが便利で安全なサービス提供の下支えとして機能していくことを期待しています。
