Framing
多くの組織で利用される新しい業務アプリケーション（B2B SaaS application とも呼ばれます）を開発する開発者として、私は次のことを行う必要があります。
- 顧客のワークフォース IdP と自社アプリケーションの間で、ユーザーとグループのプロビジョニングおよびプロビジョニング解除を設定する
- 顧客のワークフォース IdP とのフェデレーション関係を通じてユーザー認証を設定する
- いかなる時点でも、エンドユーザーが自社アプリケーション内で必要なものにのみアクセスできるようにする
- 顧客の IdP に対して、特定の認証レベルが必要であること、追加認証が必要であること、または再認証が必要であることを伝えられるようにする（例：RP におけるポリシー適用のため）
- サインインの際に、その認証レベルが IdP で満たされたかどうかを把握する
- 顧客の IDP に対して、特定の本人確認レベルが必要であること、そして／または追加のアイデンティティ属性が必要であることを伝えられるようにする（例：RP におけるポリシー適用のため）
- 要求した本人確認が IDP で満たされたかどうかを把握する
- トークンが失効したときに通知を受ける
- セッションが無効化されたときに通知を受ける
- アカウントの状態（posture）または完全性（integrity）の変化に関するリアルタイムのシグナルを受け取る
- デバイスの状態（posture）または完全性（integrity）の変化に関するリアルタイムのシグナルを受け取る。
- 新しい業務アプリケーションが強制しなければならない、企業が要求するポリシーを受け取る（例：企業 IDP によって認証されたアイデンティティは、VPN 経由で RP にアクセスしてはならない）
- 企業 IDP で認証されたユーザーに対してのみ、企業が定義したポリシーを適用する
それを実現するために、私は次を把握する必要があります。
- どのプロトコルを使用すべきか
- それらのプロトコルを大規模に、安全に実装・展開する方法
- それらのプロトコルを相互運用可能な形で実装する方法
User Authentication via Workforce IdP
顧客のワークフォース IdP とのフェデレーション関係を通じてユーザー認証を設定する
User Provisioning and Deprovisioning
顧客のワークフォース IdP と自社アプリケーションの間でユーザーのプロビジョニングおよびプロビジョニング解除を設定する
Group Provisioning and Deprovisioning
顧客のワークフォース IdP と自社アプリケーションの間でグループのプロビジョニングおよびプロビジョニング解除を設定する
Ensure Least Privileged Access
いかなる時点でも、エンドユーザーが自社アプリケーション内で必要なものにのみアクセスできるようにする
Convey Required Authentication Level to the IdP
顧客の IdP を通じて、アプリケーションが特定の認証レベルを要求していること、追加認証を求めていること、またはユーザーの再認証を求めていることを、顧客の IdP に伝えられるようにする
Know whether Required Authentication Level was Met at the IdP
サインイン、追加認証、または再認証のイベントにおいて、その認証レベルが IdP で満たされたかどうかを把握する
Receive Notifications of Revoked Tokens
トークンが失効したときに通知を受ける
Receive Notifications of Invalidated Sessions
セッションが無効化されたときに通知を受ける
Receive Signals about Account Posture or Integrity Changes
アカウントの状態（posture）または完全性（integrity）の変化に関するリアルタイムのシグナルを受け取る
Receive Signals about Device Posture or Integrity Changes
デバイスの状態（posture）または完全性（integrity）の変化に関するリアルタイムのシグナルを受け取る（例：デバイス管理サービス、EDR などから）
1. Authentication
- B2B SaaS の開発者として、顧客の IdP とのフェデレーション関係を通じてユーザー認証を設定し、エンドユーザーが企業の認証情報でログインできるようにしたい。
- B2B SaaS の開発者として、各エンタープライズ・テナントが認証用に自分たちの IdP を設定できるようにし、マルチテナントの顧客がユーザーを独立して管理できるようにしたい。
- B2B SaaS の開発者として、アプリケーションが特定の認証レベルを要求していることを顧客の IdP に伝え、MFA のようなアクセス・ポリシーを強制できるようにしたい。
- B2B SaaS の開発者として、サインインの際に指定した認証レベルが IdP で満たされたかどうかを把握し、セキュリティ要件への準拠を確実にしたい。
- B2B SaaS の開発者として、顧客の uuid と IdP エンティティを内部 UUID に関連付ける必要がある。これにより、複数の顧客 IdP が設定されている場合でも、偶発的なユーザーなりすましが発生しないようにしたい。
2. Authorization
- B2B SaaS の開発者として、いかなる時点でもエンドユーザーが自社アプリケーション内で必要なものにのみアクセスできるようにし、最小権限の原則を維持したい。
- B2B SaaS の開発者として、ユーザー属性に基づいてロールを動的に割り当てられるようにし、アクセス権限が組織変更に追従するようにしたい。
- B2B SaaS の開発者として、特定の権限にスコープされたトークンを発行し、ユーザーまたはサービスが必要なアクセスのみを持つようにしたい。
- B2B SaaS の開発者として、エンタープライズが特定の権限に対してポリシーを動的に割り当てられるようにし、アクセス割り当てに柔軟性を持たせたい。
3. User and Group Lifecycle Management
- B2B SaaS の開発者として、顧客のワークフォース IdP と自社アプリケーションの間でユーザーのプロビジョニングおよびプロビジョニング解除を設定し、ユーザーアカウントが自動的に管理されるようにしたい。
- B2B SaaS の開発者として、顧客のワークフォース IdP と自社アプリケーションの間でグループのプロビジョニングおよびプロビジョニング解除を設定し、ユーザーのグループ所属が同期されるようにしたい。
- B2B SaaS の開発者として、認証が成功した時点でユーザーアカウントを動的にプロビジョニングし、オンボーディングを円滑にしたい。
- B2B SaaS の開発者として、権限が変更された場合やユーザーが企業を離れた場合に、ユーザーアカウントを自動的に無効化し、アクセスが安全に保たれるようにしたい。
- B2B SaaS の開発者として、エンタープライズが独自のアクセス・ポリシーを定義して割り当てられるようにし、自社アプリケーションの権限に対して必要なときだけ（just-in-time）アクセスを動的に許可できるようにしたい。
4. Identity Federation
- B2B SaaS の開発者として、エンタープライズ IdP とのフェデレーション・メタデータの交換と更新を自動化し、顧客がシームレスに統合できるようにしたい。
- B2B SaaS の開発者として、テナントごとに複数 IdP の構成をサポートし、複雑な構造を持つエンタープライズが複数のディレクトリを接続できるようにしたい。
- B2B SaaS の開発者として、フェデレーション・フローをデバッグおよび監視するためのツールを提供し、エンタープライズ・クライアントが問題を効果的に切り分けできるようにしたい。
- B2B SaaS の開発者として、私がサポートする属性の entity categories（またはドメインや主題領域）を提示し、エンタープライズ・クライアントが標準の属性やグループをより容易に自社アプリケーションへ統合できるようにしたい。
- B2B SaaS の開発者として、要素名、許容値、機能説明、データ型、データ利用、バージョニングを含むデータ・カタログを定義し、エンタープライズ・クライアントが自社の標準をシステムへより容易に統合できるようにしたい。
5. Risk Signal Sharing and Posture Updates
- B2B SaaS の開発者として、アカウントの状態（posture）または完全性（integrity）の変化に関するリアルタイムのシグナルを受け取り、アプリケーションを保護するための対応を取れるようにしたい。
- B2B SaaS の開発者として、リアルタイムのリスク・シグナルに基づく条件付きアクセス・ポリシーをサポートし、エンタープライズが動的なアクセス制御を強制できるようにしたい。
- B2B SaaS の開発者として、アカウントの状態（posture）または完全性（integrity）の変化に関するリアルタイムのシグナルを送信し、エンタープライズ顧客がデータ保護のための対応を取れるようにしたい。
6. Session Management
- B2B SaaS の開発者として、トークンが失効したときに通知を受け取り、影響を受けるセッションのアクセスを終了できるようにしたい。
- B2B SaaS の開発者として、セッションが無効化されたときに通知を受け取り、アプリケーションがセッション終了を強制することを確実にしたい。
7. Protocols and Standards
- B2B SaaS の開発者として、どのプロトコル（例：SAML、SCIM、OIDC、OAuth 2.0）を使用すべきかを特定し、エンタープライズ顧客の要件を満たしたい。
- B2B SaaS の開発者として、コミュニティ主導の SDK を通じて、これらのプロトコルを大規模に安全に実装・展開し、アイデンティティの専門家にならずともアプリケーションの信頼性と安全性を維持したい。
- B2B SaaS の開発者として、相互運用可能な形でプロトコルを実装し、多様なエンタープライズ IdP 構成でも自社アプリケーションが動作するようにしたい。
8. Security and Compliance
- B2B SaaS の開発者として、トークンとセッションを失効させる API を提供し、エンタープライズがインシデントに即座に対応できるようにしたい。
- B2B SaaS の開発者として、IAM に関連する活動を記録して報告し、エンタープライズ顧客がコンプライアンス要件を満たせるようにしたい。
- B2B SaaS の開発者として、エンタープライズ顧客が自社アプリケーションのログをエンタープライズ SIEM に取り込めるようにし、コンプライアンス要件を満たせるようにしたい。
- B2B SaaS の開発者として、自社アプリケーションとエンタープライズ顧客が複数の署名鍵および暗号化鍵をサポートできるようにし、大きな運用影響なしに、それぞれ独立してローテーションできるようにしたい。
9. Tenant Management and Customization
- B2B SaaS の開発者として、テナント間でデータと構成が安全に分離されるようにし、エンタープライズ顧客が安全に運用できるようにしたい。
- B2B SaaS の開発者として、顧客管理鍵でデータと構成を保護し、エンタープライズ顧客が安全に運用できるようにしたい。
- B2B SaaS の開発者として、エンタープライズ・クライアントがアプリケーションのインターフェースとログインページを自社ブランドに合わせてカスタマイズできるようにし、アプリケーションが顧客のアイデンティティに沿うようにしたい。
- B2B SaaS の開発者として、エンタープライズがユーザー向けに独自の IAM ポリシーを定義して強制できるようにし、セキュリティ要件を満たせるようにしたい。
10. Developer and Client Support
- B2B SaaS の開発者として、IAM 統合を簡素化するために SDK と API を利用し、エンタープライズ・クライアントが自社アプリケーションへ迅速に統合できるようにしたい。
- B2B SaaS の開発者として、IAM 構成をテストするためのサンドボックス環境を提供し、クライアントが本番移行前に設定を検証できるようにしたい。
- B2B SaaS の開発者として、IAM 構成をテストするためにサンドボックス環境を利用し、クライアントの設定を本番移行前に検証できるようにしたい。
- B2B SaaS の開発者として、分かりやすいエラーメッセージとデバッグツールを提供し、クライアントが統合上の問題を迅速に切り分けられるようにしたい。
Additional Security Operations Related Stories
1. Secure Authentication Mechanisms
- 開発者として、特権的な操作の際に、より強い認証情報でユーザーの再認証を強制し、テナント設定変更時に顧客に追加のセキュリティ層を提供したい。
- 開発者として、適応型認証を実装し、状況シグナルに基づいてアクセス・ポリシーを動的に調整できるようにしたい。
- 開発者として、認証情報の強度を分類し、その分類を容易に比較できる形で伝えられる必要がある。（NIST AAL 1、2、または 3 で止まるなら、我々は失敗している）
2. Session and Token Management
- 開発者として、トークンを安全に保管し、長期間有効なトークンの利用を防止し、盗まれたトークンが悪用されないようにしたい。
- 開発者として、短命な Access Token と Refresh Token の自動ローテーションを実装し、トークンの悪用を最小化したい。
- 開発者として、不審な IP アドレスからのセッションを検知して終了し、セッション・ハイジャックを防止したい。
- 開発者として、トークンを特定のデバイスまたはセッションに紐付け、トークンのリプレイ攻撃を軽減したい。
- 開発者として、不審な IP アドレスの使用、デバイス管理の不遵守、エンドユーザーのデバイス上のマルウェアの存在などの変化を検知し、それをアプリケーションのリスク評価に反映できるようにしたい。さらに、その同一ユーザー、またはそのデバイス／場所からの全ユーザーに対して、当該 IP アドレスやデバイス等からの継続アクセスを遮断する／セッションを終了する、といった対応まで行えるようにしたい。
3. Identity Governance and Compliance
- コンプライアンス担当者として、すべてのアイデンティティ関連イベントについて、詳細で改ざん不能なログを維持し、規制および監査要件を満たしたい。
- 管理者として、現在のユーザープロファイル、グループ所属、エンタイトルメントを定期的に取得し、アクセス制御が組織のニーズに整合し続けるようにしたい。
- 開発者として、転送中および保存時のすべてのデータを暗号化し、機密情報が不正アクセスから保護されるようにしたい。
4. Account Security and Threat Mitigation
- セキュリティ担当者として、異常なログインパターンや挙動を検知し、潜在的なアカウント侵害を検知・通知できるようにしたい。
- ユーザーとして、自分のアカウントで不審な活動があった場合に通知を受け取り、迅速に是正措置を取れるようにしたい。
5. Advanced Identity Management
- 開発者として、非人（non-person）エンティティ（NPE）の認証をサポートし、サービスや API が安全にリソースへアクセスできるようにしたい。
- 開発者として、きめ細かな属性ベースのアクセス制御を提供し、エンタープライズ顧客が非常に具体的な権限を作成できるようにしたい。（上記と重複の可能性あり）
- 開発者として、動的なエンタイトルメントを実装し、状況の変化に応じてユーザーのアクセスをリアルタイムに適応させたい。（上記と重複の可能性あり）
7. Defense Against Identity-Based Cyber Attacks
- 開発者として、強力な TLS による HTTPS を強制し、中間者攻撃を防止したい。
- セキュリティ担当者として、特権アカウントの活動を監視し、内部不正を検知して軽減できるようにしたい。
8. Monitoring and Incident Response
- セキュリティ担当者として、重要なアイデンティティ関連イベントについてリアルタイムのアラートを受け取り、潜在的な脅威に迅速に対応できるようにしたい。
- コンプライアンス担当者として、エンタープライズ SIEM システムと連携し、すべてのログを集中管理して分析しやすくしたい。
- 管理者として、インシデント対応ワークフローを自動化し、侵害されたアカウントが直ちに保護されるようにしたい。
9. Development and Testing Best Practices
- 開発者として、安全な開発プラクティスに従い、定期的に Threat model を実施して、潜在的な脆弱性を早期に特定したい。
- 開発者として、自分が利用するコミュニティ提供の SDK や API に対して CVE が作成された場合に、先回りして通知を受け取り、潜在的な脆弱性を早期に特定したい。
- 開発者として、自分が利用するコミュニティ提供の SDK や API に対して CVE が作成された場合に、侵害指標（indicator of compromise）が先回りして提供され、潜在的な侵害指標を早期に特定したい。
- 開発者として、認証と入力バリデーションで API を保護し、不正アクセスやインジェクション攻撃を防止したい。
10. Customer and Admin Controls
- エンタープライズ管理者として、ユーザー向けのカスタム IAM ポリシーを定義し、自組織固有のセキュリティ要件を強制できるようにしたい。
- 管理者として、チームリードにアクセス権とポリシーのレビュー責任を委任し、大規模でも効率的に権限を管理できるようにしたい。
- ユーザーとして、データ利用に関する同意を管理し、GDPR のようなプライバシー規制に準拠できるようにしたい。