Skip to content

---The fractured state of enterprise identity

エンタープライズ・セキュリティにおいて、Identity は引き続き最大の脆弱性です。侵害の大半はいまだに漏えいした資格情報に起因していますが、多くの組織は断片化され一貫性のない Identity システムに苦しんでいます。企業は複数の Software as a Service (SaaS) アプリケーションに依存しており、それぞれが Single Sign-On (SSO)、プロビジョニング、セッション管理に対して独自のやり方を採っています。開発者はしばしば、プロトコルや任意機能、プロバイダー固有の要件が寄せ集めになった状況に直面し、統合はミスが起きやすく、ガバナンスも困難になります。この複雑さが Identity の無秩序な増殖を招き、運用上の負荷を増大させ、アクセス制御に危険な隙間を残します。

Why standardization is needed now

Identity セキュリティに共通の枠組みがないことは、長らく弱点でした。Security Assertion Markup Language (SAML)、OpenID Connect (OIDC)、System for Cross-domain Identity Management (SCIM) のようなプロトコルは構成要素を提供しますが、その柔軟性は諸刃の剣です。任意要素が多すぎると実装が分岐し、相互運用性の問題やセキュリティ上の死角が生まれます。企業は、安全なプロビジョニング、予測可能なセッション・ライフサイクル、信頼できるシグナル共有といった一貫した成果を実現するのに苦労します。開発者は統合のたびに個別対応の作業を繰り返すことになり、セキュリティ担当は、実運用で制御が本当に強制されているのか確信を持てません。

こうした状況を背景に、OpenID Foundation のワーキンググループが統一的な標準の提供を目指しています。Okta、Microsoft、Ping Identity、Beyond Identity、SGNL、Capital One、Cisco の Duo Security 部門などに支えられたこの取り組みは、エンタープライズ Identity セキュリティを簡素化し、強固にすることを約束しています。

What IPSIE is and why it matters

OIDF の Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) ワーキンググループは、複雑さを減らして相互運用性を保証するために、既存標準のプロファイルを策定します。新しいプロトコルを発明するのではなく、IPSIE は任意要素を削ぎ落とし、安全なデフォルトを強制する、指向性のある仕様を提供します。目的は、Identity 標準を実装・テスト・認証しやすくすることです。

主な注力領域は次のとおりです。

  • SSO: ログインを集約し、安全なセッション処理を確実にする
  • Account Lifecycle (AL): 孤立したアカウントを防ぐため、ユーザーのプロビジョニングとプロビジョニング解除を自動化する
  • Entitlements: 最小権限を徹底し、システム間でのロール同期を支援する
  • Risk Signal Sharing: 脅威やデバイス状態に関するアラートを交換し、対応力を高める
  • Session Termination and Token Revocation: 侵害されたセッションを即時に遮断することを保証する

IPSIE は、実運用で安全な実装がどのようなものかを定義するために成熟度レベルを導入します。たとえば Session Lifecycle Level 1 (SL1) は、US National Institute of Standards and Technology (NIST) Special Publication 800-63-4 の Federation Assurance Level 2 (FAL2) への準拠を要求し、Multifactor Authentication (MFA) を強制します。さらに、アプリケーション（relying parties）がセッション継続時間を、federation assertion で定義された有効期間に基づいて設定することを求めます。より高いレベルでは、アプリと Identity Provider 間でのセッション状態の通信などの機能が追加されます。同様に、AL レベルも基本的なユーザー・プロビジョニング（AL1）から、アプリケーションのロールと entitlements の完全同期（AL3）へと段階的に進みます。

最初のドラフト・プロファイルはすでに流通しており、OIDC SL1 は、IPSIE が既存プロトコルを具体的な運用動作へどのように対応付けるかを示す初期の実例となっています。

この構造化されたアプローチは、今日の曖昧さがあるところに明確さをもたらします。「SSO をサポートする」といった漠然とした要件ではなく、IPSIE は測定可能でテスト可能な基準を提示します。適合性テストと認証により、企業はアプリケーションが一貫したセキュリティ期待を満たしていると信頼できるようになります。

The promise and the limits of IPSIE

IPSIE は現実的で根強い課題に取り組んでいます。選択肢を絞り、安全なデフォルトを強制することで、弱い実装や不統一な実装の可能性を下げます。企業は可視性の向上と制御の強化という恩恵を受けます。SaaS プロバイダーも、統合を予測可能にし、コストのかかる個別のエンジニアリング対応を減らす共通標準の恩恵を受けます。

しかし IPSIE のスコープは、明確に人間中心です。対象は、従業員ユーザーに紐づく SaaS の Identity フローであり、認証、ライフサイクル、entitlements、ログアウトを含みます。IPSIE の憲章には、非人間の Identity が含まれていません。たとえば、サービスアカウント、CI/CD トークン、API キー、IoT デバイスの資格情報、machine-to-machine のワークロードなどです。これらの Identity は急速に増殖しており、しばしば管理されないまま、現在の最大級の攻撃面の一つとなっています。IPSIE がこれらを含むようにモデルを拡張しない限り、NHI の問題は大部分が未解決のままでしょう。

また、IPSIE は広範すぎて、ログインから entitlements、ログアウトまでを一度に扱おうとしているという懸念も指摘されています。別の見方では、初期の FIDO Alliance と比較され、まずは狭く明確に定義された問題に焦点を当てることで前進し、その後に拡大したという点が引き合いに出されます。IPSIE の長期的な成功は、野心と現実性のバランスを取り、ベンダー間での採用を確実にできるかにかかっています。

A step toward solving the NHI challenge

IPSIE は non-human identity ガバナンスの完全な答えではありませんが、重要な一歩です。SaaS の Identity に対して、標準化され相互運用可能で安全なデフォルトのプロファイルが整備されれば、Identity の無秩序な増殖が抑えられ、企業の制御が強化されます。しかしスコープを machine Identity に拡張しなければ、IPSIE は問題の一部しか解決しないリスクがあります。完全な解決のためには、企業は、人間・非人間を問わずすべての Identity を対象に、ライフサイクル・ガバナンス、自動化されたシークレットのローテーション、最小権限の強制、継続的な発見（ディスカバリー）を依然として必要とします。

How KuppingerCole can help

KuppingerCole Analysts は、この進化する領域を理解する支援ができます。Identity fabrics、Zero Trust 戦略、machine identity 管理に関する当社の調査は、人間と非人間の両方の Identity 課題に取り組むための枠組みを提供します。私たちは non-human identity ガバナンスに関する Advisory Notes を公開しており、また Privileged Access Management に関する Leadership Compass レポートでは、machine Identity に対する一貫したライフサイクル制御の重要性を強調しています。

IPSIE は前進を示しています。エンタープライズ SaaS の Identity に明確さと相互運用性をもたらすことで、喫緊のセキュリティ上の欠落を埋めます。しかし non-human identity というより広い課題は、依然として大きく立ちはだかっています。組織は IPSIE を解決策の一部として歓迎すべきですが、同時に、やるべきことがまだ多く残っていることも認識すべきです。