---
schema_version: "1"
id: f88dd6c1d999aa583239941671752e7827d65104e1598991bb0a1d7bc6ef2455
title: ID およびアクセス管理 - パターン
collection: architect
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/architect/current/ja-jp/well-architected/guides/trust-identity-access-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/trust-identity-access-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 5b9fc242505798faa2deeda610f96ac56558cb9e322b742043b7c9c95df25563
products:
  - 適切に設計されたフレームワーク
  - Architect Site Content Repo
---
# ID およびアクセス管理 - パターン

<br>

Well-Architected [Trust](/docs/architect/ja-jp/well-architected/guide/trust.html) → [Identity and Access Management](/docs/architect/ja-jp/well-architected/guide/trust.html#identity-and-access-management)の詳細

## プライマリ境界としての ID

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| アーキテクチャ                   | ✅ アクセス制御では、ネットワークの場所やデバイスに関係なく、すべての要求で明示的に ID を検証します。                                              |
| プラットフォーム \| アーキテクチャ                   | ✅ ネットワーク ベースのTrust仮定に代わるIDベースのセキュリティ制御                                                                            |
| プラットフォーム \| 組織                            | ✅ アクセスの決定では、アクセスを要求しているユーザー (認証)、許可されている操作 (承認)、コンテキスト (デバイス、場所) が考慮されます。 |
| プラットフォーム \| ドキュメント                  | ✅セキュリティ アーキテクチャでは、ネットワーク境界ではなくプライマリTrust境界としてIDを文書化します。                                                       |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| アーキテクチャ                   | ⚠️ 企業ネットワークまたは VPN のユーザーは信頼できるとみなされ、ネットワークの位置のみに基づいてより広範なアクセス権が付与されます。 |
| プラットフォーム \| アーキテクチャ                   | ⚠️ アクセス制御は ID 検証ではなくネットワーク境界に基づく                                          |
| プラットフォーム \| 組織                            | ⚠️ アクセスの決定ではコンテキストシグナル (デバイス、場所、時間、行動パターン) が考慮されない                         |
| プラットフォーム \| ドキュメント                  | ⚠️ セキュリティ アーキテクチャでは、ネットワーク ロケーションをPrimary Trust Boundaryとして処理                                              |

## Salesforce の 4 階層アクセスモデル

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| 組織                            | ✅ ソリューションは、組織 (ライセンス、機能)、オブジェクト (CRUD)、項目 (FLS)、レコード (共有) の 4 つの Salesforce アクセスレイヤーすべてを活用します。                |
| プラットフォーム \| 組織                            | ✅ アクセスモデルはトップダウン (組織 → オブジェクト → 項目 → レコード) で設計され、ボトムアップで検証されます。                                                            |
| プラットフォーム \| 組織                            | ✅ 機密データを含むオブジェクトでは、組織の共有設定 (OWD) が \[非公開] に設定されている                                                            |
| プラットフォーム \| 組織                            | ✅ \[公開/参照のみ] に設定された OWD は、広範な可視性がリスクを露呈することなくビジネスをサポートする参照オブジェクト (商品、価格表) に制限されます。 |
| プラットフォーム \| 組織                            | ✅ 組織レベルの制約 (ライセンス、IP 範囲、ログイン時間、機能権限) でユーザー母集団のベースライン機能を定義する             |
| プラットフォーム \| 組織                            | ✅ オブジェクト権限 (プロファイルおよび権限セットを使用) は、ユーザーセグメントの各オブジェクトに対する「作成」、「参照」、「編集」、および「削除」アクセス権を制御します。                                                                  |
| プラットフォーム \| 組織                            | ✅ 項目レベルセキュリティにより、オブジェクトアクセス権が付与されていても機密項目を保護                                                                    |
| プラットフォーム \| 組織                            | ✅ レコードレベルの共有では、文書化したビジネス要件に基づいてロール階層と共有ルールが使用されます。                                                 |
| プラットフォーム \| 組織                            | ✅ アクセス権は、許容されるデフォルト後に制限されるのではなく、制限されたベースラインから意図的に拡張されます。                                                  |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| 組織                            | ⚠️ アクセスモデルでは 4 つのすべてのレイヤー (組織、オブジェクト、項目、レコード) が活用されない                                             |
| プラットフォーム \| 組織                            | ⚠️ OWD は、制限計画なしで開発中に便利なように \[公開/参照・更新可能] に設定されています。                                   |
| プラットフォーム \| 組織                            | ⚠️ 早期に設定された過剰な OWD は、データ量の増大やビジネスプロセスの結晶化に伴い、制限が急激に困難になります。 |
| プラットフォーム \| 組織                            | ⚠️ 項目レベルセキュリティが設定されておらず、オブジェクトまたはレコードレベルのアクセス制御のみに依存している                                 |

## 認証アーキテクチャ

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| 組織                            | ✅ 本番環境にアクセスするすべてのユーザーに多要素認証 (MFA) を適用 (UI アクセスで必須)                                                                      |
| プラットフォーム \| 組織                            | ✅ MFA は、一括データエクスポート、権限の変更、管理設定などの特権操作に拡張されます。                                                                   |
| プラットフォーム \| 組織                            | ✅ シングルサインオン (SSO) は SAML 2.0 または OpenID Connect プロトコルを使用します。                                                                                                                               |
| プラットフォーム \| 組織                            | ✅ セッションタイムアウトが適切に設定されている: 標準ユーザーの場合は 2 時間、制限されたデータにアクセスするシステム管理者とユーザーの場合は 15 ～ 30 分                                                |
| プラットフォーム \| 組織                            | ✅ 管理プロファイルとインテグレーションユーザーには IP 制限が適用されます。                                                                                                               |
| プラットフォーム \| 組織                            | ✅ ログイン時間は、サービスアカウントを予想される業務時間に制限します。                                                                                                                        |
| プラットフォーム \| 組織                            | ✅ ネイティブデバイスの有効化により、認識できないデバイスからのログインを検証します。MFA および IP 制限により、高権限アカウントが保護されます。                                                                                                                        |
| プラットフォーム \| 組織                            | ✅ SSO が有効になっている場合、承認された管理者ユーザーは直接ログインできます (ガラスの破損手順)。                                                                                                    |
| プラットフォーム \| 組織                            | ✅ Salesforce にログインしているユーザーとエンティティのリレーションは 1 対 1 (共有ユーザーアカウントなし)                                                                                         |
| プラットフォーム \| 組織                            | ✅ API アクセスコントロールにより、未承認の接続アプリケーションによるユーザーの認証を防止                                                                                                        |
| プラットフォーム \| 指定ログイン情報              | ✅ 指定ログイン情報と外部ログイン情報は、循環機能で認証を一元管理します。                                                                                        |
| プラットフォーム \| 指定ログイン情報              | ✅ 指定ログイン情報はコードから認証の詳細を抽象化するため、コードを変更することなくログイン情報を更新できます。                                                                                |
| プラットフォーム \| 指定ログイン情報              | ✅ 認証情報がコード、設定ファイル、バージョン管理に埋め込まれない                                                                                                              |
| プラットフォーム \| Apex                           | ✅ 認証を実行するメソッドは、指定ログイン情報を使用してユーザー名/パスワードフローを処理します。                                                                                                  |
| プラットフォーム \| Apex                           | ✅ ユーザー名やパスワードが判読可能な形式でコードに表示されない (ハードコードされた値や文字列がない)                                                                                               |
| プラットフォーム \| Aura                           | ✅ 認証を実行するメソッドは、指定ログイン情報を使用してユーザー名/パスワードフローを処理します。                                                                                                  |
| プラットフォーム \| Aura                           | ✅ 読みやすい形式でユーザー名やパスワードがコードに表示されない                                                                                                                                 |
| プラットフォーム \| LWC(Lightning Webコンポーネント) | ✅ 認証を実行するメソッドで指定ログイン情報を使用する                                                                                                                                    |
| プラットフォーム \| LWC(Lightning Webコンポーネント) | ✅ コードにユーザー名やパスワードが表示されない                                                                                                                                                     |
| インテグレーション \| API                         | ✅ OAuth 2.0 JWT ベアラーフローは、信頼できる環境でのサーバー間インテグレーションに使用されます (本番インテグレーションに推奨)                                                          |
| インテグレーション \| API                         | ✅ OAuth 2.0 Web サーバーフローは、ユーザーコンテキストを必要とするサーバー間インテグレーションに使用されます。                                                                                                   |
| インテグレーション \| API                         | ✅ OAuth 2.0デバイス フローはヘッドレス デバイスで使用され、CLIおよびCI/CDツールでWebサーバー フロー(`sf org login web`)またはJWTベアラー フロー(`sf org login jwt`)を使用します。デバイス フローは2025年8月28日以降、デフォルトのSalesforce CLI接続アプリケーションでブロックされました。 |
| インテグレーション \| API                         | ✅ ユーザー名パスワード OAuth フローは使用されません。このフローに依存する既存のインテグレーションは JWT ベアラーまたはクライアントログイン情報フローに移行されます。 |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| 組織                            | ⚠️ 本番環境へのアクセスに MFA が適用されない                                                           |
| プラットフォーム \| 組織                            | ⚠️ ログイン設定が Salesforce MFA の要件に適合していない                                                |
| プラットフォーム \| 組織                            | ⚠️ MFA は特権操作 (一括エクスポート、権限の変更、管理設定) には拡張されません。   |
| プラットフォーム \| 組織                            | ⚠️ セッションタイムアウトが設定されていないか、許容範囲を超えている (>24 時間)                                      |
| プラットフォーム \| 組織                            | ⚠️ セッションポリシーでは、標準ユーザーと、制限されたデータにアクセスする管理者/ユーザーを区別しません。 |
| プラットフォーム \| 組織                            | ⚠️ 管理プロファイルおよびインテグレーションユーザーには IP 制限が適用されません。                              |
| プラットフォーム \| 組織                            | ⚠️ サービスアカウントには、予想される業務時間に制限されたログイン時間がありません。                             |
| プラットフォーム \| 組織                            | ⚠️ 高権限アカウントは、デバイスの有効化以外には何も依存しません — MFA や IP 制限は追加されません                                                      |
| プラットフォーム \| 組織                            | ⚠️ SSO が有効になっている場合、承認されたシステム管理者は直接ログインできません (ガラスを破る手順はありません)                 |
| プラットフォーム \| 組織                            | ⚠️ ユーザーとエンティティのリレーションが 1:1 ではない (共有ユーザーアカウントが存在する)                             |
| プラットフォーム \| 組織                            | ⚠️ API アクセスコントロールが有効になっていない                                                                               |
| プラットフォーム \| 指定ログイン情報              | ⚠️ ログイン情報は、コード、設定ファイル、またはバージョン管理に直接埋め込まれます。                              |
| プラットフォーム \| Apex                           | ⚠️ ユーザー名とパスワードが読みやすい形式でコードで表示される                                                      |
| プラットフォーム \| Apex                           | ⚠️ 認証は一貫した実装なしでアドホックに処理される                                              |
| プラットフォーム \| Aura                           | ⚠️ 指定ログイン情報なしで認証がアドホックに処理される                                                      |
| プラットフォーム \| Aura                           | ⚠️ ユーザー名とパスワードがコードに表示される                                                                          |
| プラットフォーム \| LWC(Lightning Webコンポーネント) | ⚠️ 指定ログイン情報なしで認証がアドホックに処理される                                                      |
| プラットフォーム \| LWC(Lightning Webコンポーネント) | ⚠️ ユーザー名とパスワードがコードに表示される                                                                          |
| プラットフォーム \| ビジネス                       | ⚠️ ユーザーのプロビジョニングとプロビジョニング解除の SLA と要件が存在しない                                         |
| インテグレーション \| API                         | ⚠️ ユーザー名パスワード OAuth フローは、より安全な OAuth フローが使用可能な場合に使用されます。                                 |
| インテグレーション \| API                         | ⚠️ OAuth 範囲が過度に許可されている (制限された範囲で十分な場合はフルアクセス)                               |
| インテグレーション \| API                         | ⚠️ クライアントログイン情報 (クライアント ID、クライアントの秘密) がコードまたは設定ファイルに安全に保存されていない                     |

## 承認とアクセス制御

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| 組織                            | ✅ ロール階層の深さは最大 5 ～ 7 レベル (パフォーマンスオーバーヘッドとトラブルシューティングの複雑さを回避)                                                                                |
| プラットフォーム \| 組織                            | ✅ 権限セットと権限セットグループにより、プロファイルを増やさずに柔軟で追加的なアクセスを提供                                                                                |
| プラットフォーム \| 組織                            | ✅ 権限セットにより、特定の職務、アプリケーション、または一時的に昇格した権限へのアクセス権が付与されます。                                                                                  |
| プラットフォーム \| 組織                            | ✅ 権限セットグループは、関連する権限セットと例外のミュート機能を組み合わせます。                                                                                            |
| プラットフォーム \| 組織                            | ✅ すべての機能アクセス権は権限セットと権限セットグループ (プロファイルではない) で付与され、職務の変化に応じて柔軟に対応できます。                                             |
| プラットフォーム \| 組織                            | ✅ トランザクションセキュリティポリシーにより、リアルタイムのコンテキスト評価で認証を拡張                                                                                                  |
| プラットフォーム \| 組織                            | ✅ トランザクションセキュリティポリシーにより、異常な動作 (パターンを超える一括データダウンロード、予期しない地域からのログイン、変更期間外の権限変更) を検出してブロック |
| プラットフォーム \| 組織                            | ✅ 機密性の高い操作やデータアクセスに対して IP 制限が設定されている                                                                                                            |
| プラットフォーム \| 組織                            | ✅ インテグレーションごとに一意の API 専用インテグレーションユーザーが設定されている                                                                                                                   |
| プラットフォーム \| Apex                           | ✅ データにアクセスするすべてのコードは、WITH USER_MODE、WITH SYSTEM_MODE キーワード、または Security.stripInaccessible() メソッドを使用して CRUD と FLS を適用します。                                                    |
| プラットフォーム \| Apex                           | ✅ SOQL クエリでは、ビジネス要件に基づいて WITH USER_MODE または WITH SYSTEM_MODE キーワードが明示的に使用されます。                                                                                   |
| プラットフォーム \| Apex                           | ✅ DML 操作では、挿入/更新/更新/挿入操作前のアクセス適用に Security.stripInaccessible() を使用します。                                                                            |
| プラットフォーム \| Apex                           | ✅ データベース DML ステートメントは、データ操作のユーザーモードまたはシステムモードを明示的に宣言します。                                                                                                       |
| プラットフォーム \| Apex                           | ✅ データベース操作で stripInaccessible() メソッドを使用してクエリとサブクエリの結果を絞り込む                                                                                                 |
| プラットフォーム \| Apex                           | ✅ 共有キーワード (共有あり、共有なし、継承共有) がビジネスセキュリティ要件に基づいて適切に使用されている                                                       |
| プラットフォーム \| 設計標準               | ✅ 高度な権限を付与する使用事例 (「すべてのデータの編集」、「すべてのデータの参照」) がビジネス上の正当性と共に明確に文書化されている                                                           |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| 組織                            | ⚠️ ロール階層が 5 ～ 7 レベルより深いため、共有計算とトラブルシューティングの複雑さでパフォーマンスオーバーヘッドが生じる                                       |
| プラットフォーム \| 組織                            | ⚠️ ロール階層により、ビジネス上の理由なく広範なアクセス権を付与                                                                                                    |
| プラットフォーム \| 組織                            | ⚠️ プロファイルが軽微な権限のバリエーションで繰り返しコピーされ、区別があいまいなプロファイルが多数作成される                                                |
| プラットフォーム \| 組織                            | ⚠️ プロファイルにメタデータのアクセス制御が含まれている (権限セットを使用)                                                                                           |
| プラットフォーム \| 組織                            | ⚠️ 異常な動作を検出するためにトランザクションセキュリティポリシーが実装されていない                                                                                       |
| プラットフォーム \| 組織                            | ⚠️ IP 制限が機密性の高い操作やデータアクセスに対して設定されていない                                                                                    |
| プラットフォーム \| 組織                            | ⚠️ API 限定ユーザーが設定されていないか、複数のインテグレーションで共有されている                                                                                         |
| プラットフォーム \| 組織                            | ⚠️ 「すべてのデータの参照」または「すべてのデータの編集」権限が、文書化された正当性なしに付与されている                                                                            |
| プラットフォーム \| Apex                           | ⚠️ SOQL/SOSL クエリと DML 操作は、明示的なアクセスチェックなしでデフォルトのシステムモードで実行されます。                                                                       |
| プラットフォーム \| Apex                           | ⚠️ CRUD と FLS の適用が一貫していない、または欠落している                                                                                                                  |
| プラットフォーム \| Apex                           | ⚠️ SOQL は WITH SECURITY_ENFORCED に依存していますが、削除され、コンパイルエラーが発生するようになりました (WITH USER_MODE で置き換え)。 |
| プラットフォーム \| Apex                           | ⚠️ 共有キーワードが一貫していない、またはまったく使用されていない                                                                                                               |
| プラットフォーム \| 設計標準               | ⚠️ 権限を昇格させるための使用事例が明確に記載されていない                                                                                               |

## 属性ベースのアクセス制御 (ABAC) と Data 360

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| Data 360                       | ✅ RBAC (ロール、プロファイル、権限セット) はプラットフォームアクセスを制御します (Data 360 を使用できるユーザー)。ABAC はデータアクセスを制御します (属性に基づいてユーザーに表示されるデータ)。                              |
| プラットフォーム \| Data 360                       | ✅ AI エージェントは要求元のユーザーのコンテキスト (代理) で実行されるため、エージェントが生成するクエリは、システムレベルのアクセスで実行するのではなく、そのユーザーのアクセスで制約されます。         |
| プラットフォーム \| ドキュメント                  | ✅ データ分類は、属性定義、適用ルール、ビジネスの正当性と共に文書化されます。                                                                     |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| Data 360                       | ⚠️ データ分類に従う必要があるアクセス権は、属性ベースのアクセス制御にアクセスする代わりに、ロール階層と共有を介して強制されます。 |
| プラットフォーム \| Data 360                       | ⚠️ FLS バイパス: 項目レベルのアクセス権がないユーザーは、FLS を適用しない API または SOQL クエリを使用してデータを取得します。                                                    |
| プラットフォーム \| Data 360                       | ⚠️ AI エージェントは要求元のユーザーのコンテキストで実行せずにデータを照会します。エージェントが生成したクエリは、オブジェクトレベル、項目レベル、およびレコードレベルのアクセス制御をスキップします。    |
| プラットフォーム \| Data 360                       | ⚠️ エージェント実行コンテキストに代理ユーザー属性が含まれていない。エージェントはシステムレベルのアクセス権で操作する。                                               |
| プラットフォーム \| ドキュメント                  | ⚠️ データ分類が文書化されていない。一貫性のない適用を作成するチームによって属性定義が異なる                                           |

## 重大な影響のある取引先

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| 組織                            | ✅ クリティカルインパクト取引先 (システム管理者、インテグレーションユーザー、自動化プロセス取引先) が特定され、納入商品インベントリで追跡される |
| プラットフォーム \| 組織                            | ✅ 重要な影響のある取引先は、広範なプラットフォーム アクセスを提供する権限が昇格しているため、価値の高い目標を表します。                              |
| プラットフォーム \| 組織                            | ✅ MFA にはハードウェアセキュリティキーまたは認証アプリケーションが必要です (SIM スワップに脆弱な SMS ではありません)。                              |
| プラットフォーム \| 組織                            | ✅ ログイン IP 範囲は既知の管理場所に制限されます。                                                                              |
| プラットフォーム \| 組織                            | ✅ ログインアラートと権限変更通知が有効になっている                                                                                  |
| プラットフォーム \| 組織                            | ✅ 四半期ごとのアクセスレビューは文書化した証明で実施                                                                            |
| プラットフォーム \| 組織                            | ✅ 使用後監査による緊急時アクセスのためのガラス破損手順が存在する                                                                         |
| インテグレーション \| サービスアカウント            | ✅ OAuth フローはインテグレーションとサービスアカウントに使用されます (ユーザー名パスワードなし)                                                           |
| インテグレーション \| サービスアカウント            | ✅ インテグレーションユーザーに IP 制限が適用される                                                                                            |
| インテグレーション \| サービスアカウント            | ✅ 資格循環スケジュールの実施 (四半期ごとまたはポリシーごと)                                                                       |
| インテグレーション \| サービスアカウント            | ✅ イベントモニタリングで異常な API 利用パターンを監視                                                                           |
| インテグレーション \| サービスアカウント            | ✅ 各インテグレーションには、必要な最小限の権限を持つ専用のサービスアカウントがあります (広範なアクセス権を持つ共有の「インテグレーションユーザー」ではありません)。          |
| インテグレーション \| サービスアカウント            | ✅ サービスアカウントは無人で動作するため、最小限の権限を厳密に適用します。                                                               |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| 組織                            | ⚠️ 重要影響取引先 (システム管理者、インテグレーション、自動化) が特定、追跡、インベントリされていない |
| プラットフォーム \| 組織                            | ⚠️ システム管理者がハードウェアセキュリティキーや認証アプリケーションの代わりに SMS ベースの MFA を使用している       |
| プラットフォーム \| 組織                            | ⚠️ 重大な影響がある取引先には、ログイン時間や IP 制限はありません。                                        |
| プラットフォーム \| 組織                            | ⚠️ 特権アカウントのログインまたは権限の変更に関するアラートが設定されていない                       |
| プラットフォーム \| 組織                            | ⚠️ 重大な影響のある取引先アクセスは、四半期ごとではなく、定期的にレビューまたは確認されることはありません。              |
| プラットフォーム \| 組織                            | ⚠️ 緊急アクセス用のガラス破損手順はありません                                                  |
| インテグレーション \| サービスアカウント            | ⚠️ 1 つの「API ユーザー」アカウントが「すべてのデータの編集」権限を持つ複数のインテグレーションで共有されている    |
| インテグレーション \| サービスアカウント            | ⚠️ OAuth が使用可能な場合、サービスアカウントはユーザー名とパスワード認証を使用します。                         |
| インテグレーション \| サービスアカウント            | ⚠️ サービスアカウントのログイン情報では、静的なパスワードを何年も変更せずに使用します (循環なし)                    |
| インテグレーション \| サービスアカウント            | ⚠️ サービスアカウントにインテグレーションで要求される以上の権限がある                           |
| インテグレーション \| サービスアカウント            | ⚠️ サービスアカウントの異常な API 使用パターンが監視されていない                                   |

## ID ライフサイクル管理

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| プロセス                        | ✅ ID ライフサイクルには、プロビジョニング (ベースラインアクセス権で作成)、アクセス調整 (ロールの変更に応じて付与/取り消し)、定期的な再認定 (四半期ごとの検証)、プロビジョニング解除 (即時取り消し) が含まれます。 |
| プラットフォーム \| 組織                            | ✅ ID プロバイダーからの自動プロビジョニングのために SCIM (System for Cross-domain Identity Management) を実装                                                                                              |
| プラットフォーム \| プロセス                        | ✅ プロビジョニングでは、HR システムイベントによってトリガーされるベースラインアクセス一致ジョブ機能を使用して取引先が作成されます。                                                                                                           |
| プラットフォーム \| プロセス                        | ✅ アクセス調整により、ロールの拡張時に追加の権限が付与され、ロールの変更時に権限が取り消されます。                                                                                                         |
| プラットフォーム \| プロセス                        | ✅ 定期的な再認定は四半期ごとに行われ、マネージャーがチームのアクセス権をレビューおよび検証します。                                                                                                               |
| プラットフォーム \| プロセス                        | ✅ プロビジョニング解除により、雇用が終了したり、ロールで Salesforce が不要になったりすると、アクセス権がすぐに取り消されます。                                                                                                              |
| プラットフォーム \| 組織                            | ✅ 自動検出で 90 日以内にログインしていないユーザーを特定し、アクセスレビューワークフローをトリガー                                                                                                   |
| プラットフォーム \| 組織                            | ✅ ジャストインタイム (JIT) プロビジョニングでは、必要に応じて SSO からユーザーが自動的に作成されます。                                                                                                                             |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| 組織                            | ⚠️ ID プロバイダーインテグレーションがあるにもかかわらず SCIM プロビジョニングが実装されていない                    |
| プラットフォーム \| プロセス                        | ⚠️ 新規ユーザーは、標準のオンボーディング手順を使用せずに手動で作成されます。                                |
| プラットフォーム \| プロセス                        | ⚠️ 最初のユーザーアクセスが一貫していないか、既存のユーザーのコピーに基づいている                               |
| プラットフォーム \| プロセス                        | ⚠️ ロールの変更または移行のためのアクセス権の変更が遅れているか、不完全である                               |
| プラットフォーム \| プロセス                        | ⚠️ オフボーディングが遅れている。元従業員は解除後もアクセス権を保持している (同日無効化ではない) |
| プラットフォーム \| 組織                            | ⚠️ ユーザープロビジョニングの自動化はありません (手動ユーザー作成のみ)                               |
| プラットフォーム \| プロセス                        | ⚠️ アクセス権の再認定キャンペーンが存在しない (四半期または年次レビューがない)                            |
| プラットフォーム \| プロセス                        | ⚠️ 再認定時に特定された不要なアクセス権は削除されない                                  |
| プラットフォーム \| プロセス                        | ⚠️ 特権アカウント、組織間アクセス、外部ユーザーのアクセス権の再証明は厳格ではありません。     |
| プラットフォーム \| 組織                            | ⚠️ 休眠アカウント (90 日以上ログインなし) は確認や無効化なしで蓄積されます。                    |
