Software Design 202512

ID管理の基本

実体(Entity)とは、現実世界に存在する個人、組織、デバイスなどを指す。 アプリやAIエージェントなどの電子的な存在も含まれる。

属性(Attribute)とは、実体の特徴や性質を表す情報のこと。 氏名、生年月日、組織名など。

デジタルID(デジタルアイデンティティ)とは、ある実体に関する属性の集合である。 現実世界の様々な実体をデジタル空間上で表現し、区別できるようにするために使う。

デジタルIDの管理には、ライフサイクル管理とアクセス管理の大きく2つの柱がある。

ライフサイクル管理

ISO/IEC 24760-1 に標準が定義されている。 unknown/established/active/suspended/archivedなどの状態が定義されている。

身元確認・ID発行機能は、IDの申請者から必要な情報を集め、実在性を確認後、IDを発行する機能。 求められる身元確認保証レベルに応じて、自己申告からeKYCまで様々な確認方法がある。 また、システムの特性によって必要な属性は大きく異なる。

ライフサイクルマネジメント機能は、各種のイベントに応じてIDの状態を変更したり、 実体の変化にあわせて属性を更新したりする機能。 属性には、パスワード等のクレデンシャル、認可情報、その他(名前や連絡先など)が含まれる。 ビジネス要件に応じて独自性が必要になりがちな部分である。 アカウントリカバリーもここに含まれる。

アクセス管理

誰が、何に、どの条件で、どこまでアクセスしていいかを管理する。 なお、ライフサイクル管理によりIDが最新化されているのが前提となる。

当人認証機能は、その人がIDの所有者であることを確認する機能。 要件に応じて強度や利便性は変わる。 独自性はほぼ必要ない部分なので、独自実装せずにIDaaSやSSO製品を使うのがよい。 個々のシステムではなく、専用のID管理システムで一括して当人認証を行う方法をフェデレーションモデルという。

認可・アクセスコントロール機能は、認可情報に基づき、 利用者が特定のリソースにアクセスすることができるか判断する機能。 認可情報の管理自体はライフサイクルマネジメント機能で行うのに対し、 ここでは実際に使えるかどうかの判定を行っている点に注意。 方法には以下の3つがある。

• IBAC / Identity-based access management / 実体で判定
• RBAC / Role-based access management / 実体に割り当てたロールで判定
• ABAC / Attribute-based access management / 属性で判定

認証連携機能は、前述の2つの機能の結果を他のシステムに伝える機能。 イントラネットではSSO製品の備える独自の連携方式を手軽に使い、 クラウドサービスとの連携ではSAML/OIDCなどを使うのがよさげ。

共通機能

証跡管理機能は、ID管理システム内で発生した各種イベントを記録・保存・検索する機能。 インシデント対応や内部統制監査に必要となる。

ガバナンス機能は、利用が適切に行われているか随時確認し、適正化する機能。 不正アクセス、過大な権限付与、管理者権限乱用などを検出する。

EIAMとCIAM

ID管理には大きく2つのカテゴリがある。

• EIAM (Enterprise Identity and Access Management)
• CIAM (Customer Identity and Access Management)

項目	EIAM（Enterprise IAM）	CIAM（Customer IAM）
対象	企業内の従業員やパートナー	顧客や一般ユーザー
基本方針	内部統制とリスク管理を重視	利便性とセキュリティのバランス
ID発行時の身元確認	対面や公式証明書などによる厳格な確認	最低限の確認のみ
ライフサイクル管理	管理者が管理し、最小権限のみを付与	プログレッシブプロファイリング（段階的に属性を追加）
プライバシー	−	プライバシー保護やポリシー同意が重要
当人認証	多要素認証が一般的	利便性と安全性のバランスを考慮
認証連携	SSO・フェデレーションが多用	OIDCなど標準規格を使用
認可・アクセスコントロール	RBAC・ABACにより細かく制御	粒度はおおざっぱ
証跡管理	必須	認証の成否に加え、認証後の操作ログも重要
ガバナンス	必須	一定期間未利用アカウントの削除など

CIAMの技術

身元確認は、eKYCが代表的。身分証＋顔写真か、マイナカードによるJPKIを使う。

当人認証については、NIST SP800-63B に基づくレベル分類がある。 AAL(Authentication Assurance Level) 1〜3まで。

• AAL1: 単一要素認証 / パスワードのみ認証など
• AAL2: 多要素認証 / パスワード＋ワンタイムパスワード、パスキー(クラウド同期)など
• AAL3: ハードウェアベースの多要素認証 / パスキー(デバイス固有)など

認可とID連携

認可とは、特定のリソースに対するアクセス権限を制御する仕組みのこと。

OAuth 2.0は、認可(データへのアクセスを許すか)を扱うための標準的なフレームワークである。 目的は、ユーザーがサードパーティーアプリに対して、 自身のIDやパスワードなどの認証情報を渡すことなく、 自身の保護されたリソースへの限定的なアクセス権を付与すること。 クライアント（e.g. 写真アプリ）、認可サーバー（e.g. Google）、リソースサーバー（e.g. Google Photo API）で構成される。 クライアントは認可サーバーから受け取ったアクセストークンを用いて、リソースサーバーにアクセスする。 RFC 6749 に基礎となる仕様が定義されているほか、多くの拡張仕様が存在する。

OpenID Connect(OIDC) は、OAuth 2.0をベースに、 認証(ログインしたユーザーが誰であるか)を扱うための機能を追加した技術仕様である。 認可サーバーがクライアントにアクセストークンを返す際に、 ユーザーの認証結果や属性を含むIDトークンもあわせて返すことで実現される。 OIDCにも多くの拡張機能が存在する。

SAML(Security Assertion Markup Language)は、 主に企業間のシングルサインオン(SSO)に使用されるXMLベースの標準規格である。 OIDCに比べて仕様が複雑で、モバイルフレンドリーでない。

高度なユースケースに対応するための拡張仕様として以下のようなものがある。

• OpenID Connect for Identity Assurance
  • 身元確認の検証プロセスもメタデータとして返す
  • 医療や金融など高い身元確認保証レベルが求められる分野で使われる
• FAPI (Financial-grade API)
  • 金融分野向けにOAuth 2.0とOIDCを拡張
  • 通信の安全性と否認防止を強化
• Device Authorization Grant
  • 入力手段が限られたデバイス(スマートTVなど)向けにOAuth 2.0を拡張
  • 別のデバイスで認可を行うフローを提供
• CIBA (Client-Initiated Backchannel Authentication)
  • ユーザーが直接操作しない状況での認証を可能にするOIDCの拡張
  • 店頭端末で操作したのち、スマホで認証を行えるなど

アカウントリカバリ

アカウントリカバリはセキュリティの抜け穴になりがちなので、最新の注意が必要。 そもそもリカバリが必要な自体にならないよう、MFAを複数化したり、パスキーを推奨するのもよい。

認証基盤の選び方

種類は以下の3つである。

• IDaaS (Identity as a Service)
• OSS・パッケージ製品
• 自前実装

IDaasは、運用負荷が低く、サービスインまでの時間が短いのが利点。 セキュリティや法規制なども任せられるし、MFAや外部認証プロバイダーとの連携も容易。 一方で、サービスの規模によってはコストが高くなる可能性がある。 また、カスタマイズ性が低かったり、ベンダーロックインのリスクがある。

OSS・パッケージ製品は、IDaaSよりもカスタマイズ性が高い。自社インフラでの運用も可能。 一方で、運用負荷が高く、人件費やインフラコストを考慮するとTCOは高くなる可能性もある。

自前実装は、最も柔軟に要件を満たせるが、開発・運用コストが非常に高い。

認証基盤を選ぶ際には、機能要件だけでなく、スケーラビリティ、信頼性、可用性、 パフォーマンス、セキュリティ、コンプライアンスといった非機能要件も重要である。

要件が定まったらFit&Gap分析を行い、対応策を考えていくとよい。

IDaaSとは

Auth0の例

Auth0は、OIDC, OAuth 2.0, SAMLなどをサポートするIDaaSである。

• サポートする方式
  • 単純なID/Pass
  • GoogleやGitHubなどのソーシャルログイン
  • Active DirectoryやLDAPなどのエンタープライズ方式
• 多要素認証(MFA)
  • OTP
  • WebAuthn(FIDO2)
• 対応アプリ
  • SPA
  • MPA
  • ネイティブアプリ
• SLA: 99.99% (ダウンタイムは年間1時間未満)

ログイン体験の提供方法として以下の3つがある。

• Hosted Login (Universal Login) 👈推奨
  • Auth0がホストするログインページを利用
  • 共通IDで複数のサービスにログインすることを簡単に実現できる
  • カスタマイズ性は低いが、メンテナンス不要で機能追加が早くセキュリティも高い
• Hosted Login (Classic Login)
  • 従来のホスト型ログインページ
  • デザインのフルカスタマイズが可能
  • 利用者自身で機能追随やセキュリティ対応が必要
• Embedded Login
  • アプリケーション内に組み込むログインフォーム
  • すでに非推奨

Actionsは、Auth0の各種イベントにフックして、 サーバーレスなNode.js環境でカスタムコードを実行できる仕組み。 以下のようなユースケースに使える。

• システム固有のユーザーIDをカスタムクレームとして追加する
• ログイン後に利用規約を承諾するためのページにリダイレクトする
• IPによるアクセス制御を行う

Auth0 Organizationsは、複数の顧客組織を管理するための仕組み。 各組織ごとに独自のログイン方式、ブランディングなどを提供できる。

IaCのためにTerraform Auth0 Providerが提供されている。

IDaaS選定時のポイント

• UI/UXや認証フローのカスタマイズに一定の制約があるが、問題ないか
• マネジメントAPIのレートリミット等があるか、またそれは許容できるか
• ログと監査機能は要件に合致しているか

ユーザー情報をIDaaS側で管理する(一元管理モデル)か、 自社DBで管理する(ハイブリッドモデル)かも重要なポイント。

• IDaaS側にデータ型やサイズに制約がないか
• IDaaS側の検索機能だけで要件を満たせるか
• (特にtoCサービスで)アクセス急増時にIDaaSのAPIレートリミットにかからないか

IDaaSの移行

IDaaSから別のIDaaSや自前実装に乗り換える場合、移行が必要になる。 この際、ユーザーデータの移行とクレデンシャルデータ(パスワード等)の移行が必要になる。 前者はデータを移すだけなので比較的容易である。 後者はいくつかの戦略が考えられる。

• 初期パスワードをメール等で送り、初回ログイン時に変更させる
• 初回アクセス時に、メールや電話を使ったパスワードリセットフローに乗せる (toBだとこれがよさそう)
• 並行稼働でリアルタイムに移行する (toCだと離脱防止のためこの選択があり得るが、コストがネック)