Well-Architected Trust → Compliance and Regulatory Adherenceの詳細
共有責任モデル
パターン
| 参照すべき場所 | 外観 |
|---|---|
| インフラストラクチャコンプライアンス | ✅ インフラストラクチャと共有サービスのコンプライアンスの証拠として、Trust.salesforce.comおよびCompliance.salesforce.comで入手できるSalesforce Platform認定(SOC 2 Type II、ISO 27001、Government Cloud製品向けFedRAMP、HIPAA、PCI DSS)を活用します。 |
| カスタムソリューションコンプライアンス | ✅ カスタム オブジェクト、Apexコード、インテグレーション、構成を設計して、プラットフォーム認定で提供されるコンプライアンス体制を維持します。 |
| カスタムソリューションコンプライアンス | ✅ アーキテクチャコンプライアンス管理を文書化します。 |
| 責任境界 | ✅ ドキュメントを明確に示す: Salesforce は準拠インフラストラクチャ (物理、ネットワーク、プラットフォームセキュリティ、マルチテナントの分離) を提供し、アーキテクトは準拠ソリューション (データ分類、アクセス制御、暗号化設定、安全なコーディング、データ処理コンプライアンス) を設計します。 |
| コンプライアンスドキュメント | ✅ カスタム実装が規制要件をどのように満たしているかを示すアーキテクチャドキュメントをプラットフォーム認定に対応付けて管理します。 |
| コンプライアンスドキュメント | ✅ 規制 → プラットフォームコントロール → カスタムコントロールをリンクするコンプライアンスマトリックスを作成します。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| インフラストラクチャコンプライアンス | ⚠️ プラットフォーム認定を想定すると、コンプライアンスの義務はありません。 |
| インフラストラクチャコンプライアンス | ⚠️ カスタムソリューションの適切なアクセス制御、暗号化、またはデータ処理コンプライアンスを実装できない。 |
| インフラストラクチャコンプライアンス | ⚠️ プラットフォーム認定は、コンプライアンスの負担を軽減しますが、アーキテクチャ上の責任を排除しません。 |
| 責任境界 | ⚠️ Salesforce の責任がどこで終了し、顧客の責任がどこから開始されるかが不明瞭である。 |
| 責任境界 | ⚠️ カスタム実装のコンプライアンスギャップを責めるプラットフォーム。 |
| コンプライアンスドキュメント | ⚠️ 規制要件と実装された統制の対応付けが文書化されていない。 |
| コンプライアンスドキュメント | ⚠️ 監査検出中に証拠を収集するためにスクランブルします。 |
業界固有の規制要件
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ヘルスケア (HIPAA) | ✅PHI(保護された健康情報)が含まれるすべてのフィールドでShield Platform Encryptionを有効にします。 |
| ヘルスケア (HIPAA) | ✅ HIPAA の記録保存要件を満たした項目監査履歴を実装します (現在の期間と管理規制を確認します)。 |
| ヘルスケア (HIPAA) | ✅ PHI は、実行されたビジネスアソシエイト契約 (BAA) の対象となる Salesforce サービスでのみ保存および処理され、ソリューション設計と PHI データフローは BAA の範囲に対して検証されます。 |
| ヘルスケア (HIPAA) | ✅ 不正な PHI アクセスパターンを検出するようにイベントモニタリングを設定します。 |
| ヘルスケア (HIPAA) | ✅ アクセス制御、監査ログ、送信セキュリティ (TLS 1.2+、PHI インテグレーションの証明書ベースの相互認証) などの技術的な保護を実装します。 |
| 金融サービス (SOX、DORA、PCI DSS) | ✅ 権限セット設計により、1 人のユーザーが金融取引の作成と承認の両方を実行できないように職務を分離します。 |
| 金融サービス (SOX、DORA、PCI DSS) | ✅ [設定] [監査履歴] およびカスタム変更ログを使用して、変更監査履歴を管理します。 |
| 金融サービス (SOX、DORA、PCI DSS) | ✅ Salesforce に完全なプライマリ取引先番号 (PAN) を保存しないでください。PCI DSS 範囲を削減するために、支払プロセッサーを介してカード所有者データをトークン化します。PAN を保存する必要がある場合は、PCI DSS コントロールで暗号化カスタム項目を使用します。 |
| 金融サービス (SOX、DORA、PCI DSS) | ✅ 不正検出パターンの取引監視を設計します。 |
| 金融サービス (SOX、DORA、PCI DSS) | ✅ DORA には、インシデント対応やサードパーティリスク管理などのオペレーショナルレジリエンスが必要です。 |
| プライバシー規制 (GDPR、CCPA、LGPD) | ✅ GDPR と LGPD の場合は、目的固有の詳細なオプトイン同意 (マーケティング、分析、パーソナライズ) を取得する同意管理を設計し、CCPA/CPRA の場合は、個人情報の販売または共有に関するオプトアウトメカニズムを提供します。 |
| プライバシー規制 (GDPR、CCPA、LGPD) | ✅ 回答期間内にリリースの規制セットを完了するためのデータ主体の権利ワークフロー (アクセス、修正、消去、可搬性) を作成します。 |
| プライバシー規制 (GDPR、CCPA、LGPD) | ✅ 同意の有効期限が切れたときや法的根拠が終了したときにデータを消去するデータ保持の自動化を実装します。 |
| プライバシー規制 (GDPR、CCPA、LGPD) | ✅ 各データ処理活動の法的根拠を文書化します。 |
| プライバシー規制 (GDPR、CCPA、LGPD) | ✅ GDPR では、文書化した正当性、データフローの対応付け、プライバシーへの影響評価が必要です。 |
| 政府 (FedRAMP) | ✅ 規制対象の政府ワークロードには Salesforce Government Cloud を使用します。 |
| 政府 (FedRAMP) | ✅ Salesforce 設定に対応付けられた NIST 800-53 コントロールを実装します。 |
| 政府 (FedRAMP) | ✅ 政府の SIEM インフラストラクチャにルーティングされたイベントモニタリングで継続的な監視を有効にします。 |
| 政府 (FedRAMP) | ✅ FedRAMP では、最初の認証だけでなく、継続的な監視による継続的な認証が必要です。 |
| 複数管轄 | ✅ データ レジデンシー要件をHyperforceの地域展開に対応付けます。 |
| 複数管轄 | ✅ 国際データ転送の標準契約条項または拘束力のある企業ルールを実装する。 |
| 複数管轄 | ✅ 出発地、経由地、居住場所を示すドキュメントデータフローマップ。 |
| 複数管轄 | ✅ 1 つの組織内で競合するレジデンシー要件を満たすことができない場合は、マルチ組織アーキテクチャを検討します。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| ヘルスケア (HIPAA) | ⚠️ PHI は、不正アクセスを防止するためのポリシーに基づいて標準の暗号化項目に保存します。 |
| ヘルスケア (HIPAA) | ⚠️ 項目監査履歴または監査保持計画がない。 |
| ヘルスケア (HIPAA) | ⚠️ レポート、リストビュー、または Experience Cloud で適切なアクセス制御を使用せずに PHI を公開します。 |
| ヘルスケア (HIPAA) | ⚠️ PHI アクセスで SMS ベースの MFA を許可します (SIM スワップに脆弱)。 |
| 金融サービス (SOX、PCI DSS) | ⚠️ 1 人のユーザーが金融取引を作成および承認できるようにします (職務の分離なし)。 |
| 金融サービス (SOX、PCI DSS) | ⚠️ 暗号化や PCI DSS コントロールを使用せずに、完全な主取引先番号 (PAN) を標準の Salesforce カスタム項目に保存します。 |
| 金融サービス (SOX、PCI DSS) | ⚠️ 不正検出のための取引監視がない。 |
| 金融サービス (SOX、PCI DSS) | ⚠️ 財務システムの変更に関する文書化された変更監査履歴がない。 |
| プライバシー規制 (GDPR、CCPA) | ⚠️ 同意は、目的ごとの詳細な追跡ではなく、バイナリの「はい/いいえ」として扱います。 |
| プライバシー規制 (GDPR、CCPA) | ⚠️ 法務チームを介してデータ主体の要求を手動で処理するのに数か月かかり、リリースの規制セットの応答ウィンドウが欠落します。 |
| プライバシー規制 (GDPR、CCPA) | ⚠️ データ処理活動に関する文書化された法的根拠がない。 |
| プライバシー規制 (GDPR、CCPA) | ⚠️ 「念のため」文書化した目的の制限なしでデータを収集します。 |
| 政府 (FedRAMP) | ⚠️ FedRAMP コンプライアンスを必要とする政府のワークロードには、標準の Salesforce 組織を使用します。 |
| 政府 (FedRAMP) | ⚠️ 継続的な監視または NIST 800-53 コントロールマッピングがない。 |
| 複数管轄 | ⚠️ データの移行先と場所を示すデータフローの対応付けがない。 |
| 複数管轄 | ⚠️ 1 つのグローバル組織がすべての地域データレジデンシー要件を満たしているものとします。 |
| 複数管轄 | ⚠️ 国際的なデータ転送に関する法的根拠のドキュメントがない。 |
継続的なコンプライアンス監視
パターン
| 参照すべき場所 | 外観 |
|---|---|
| セキュリティ状態チェック | ✅ 組織構成を Salesforce セキュリティベースラインと比較する四半期ごとの評価を実行します。 |
| セキュリティ状態チェック | ✅ 80% 以上のスコアを維持する (非常に良いまたは良い帯域)。 |
| セキュリティ状態チェック | ✅ ベースライン以下の設定について、ビジネスの正当性と報酬に関する制御を含む例外を文書化します。 |
| セキュリティ状態チェック | ✅ 状態チェックは、セキュリティのベストプラクティスから設定のドリフトを特定します。 |
| イベントモニタリング | ✅ イベント監視を有効にして、ユーザー活動、API コール、認証イベント、データアクセスパターンの詳細なログを取得します。 |
| イベントモニタリング | ✅ イベントログファイルを外部 SIEM に転送して、ネイティブ保持制限を超える長期保持を実現します。 |
| イベントモニタリング | ✅ コンプライアンスでは、多くの場合、複数年のログ保持が必要です。リリースの規制に対する最小期間を確認してください。 |
| トランザクションセキュリティ | ✅ イベントをリアルタイムで評価し、ブロックしたり、MFA のステップアップを要求したり、ポリシー違反を通知したりできるトランザクションセキュリティポリシーを実装します。 |
| トランザクションセキュリティ | ✅ コンプライアンス違反を未然に防止する予防管理に使用します (例: 通常のパターンを超える一括データエクスポートのブロック、機密項目へのアクセスに対するステップアップ認証の要求)。 |
| 自動化されたコンプライアンス検証 | ✅ CI/CD リリースパイプラインにコンプライアンスチェックを実装して、リリースで権限モデルが弱まったり、監査設定が無効になったり、非準拠の設定が導入されたりしていないことを確認します。 |
| 自動化されたコンプライアンス検証 | ✅ コンプライアンス検証に失敗したリリースを破棄する — コンプライアンス検証は、リリース後の検出ではなくリリースゲートである必要があります。 |
| 継続的な監査準備状況 | ✅ 特定の時点での監査準備ではなく、継続的な監査準備のための設計。 |
| 継続的な監査準備状況 | ✅ コンプライアンスは、継続的な証拠の生成が必要な継続的な運用状態であり、毎年の認定のスクランブルではありません。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| セキュリティ状態チェック | ⚠️ 監査人が要求した場合にのみ状態チェックを実行します。 |
| セキュリティ状態チェック | ⚠️ 調査なしでスコアが 80% 未満になるようにします。 |
| セキュリティ状態チェック | ⚠️ ベースライン以下の設定の例外が文書化されていない。 |
| セキュリティ状態チェック | ⚠️ 特定されたリスクは決して是正しない。 |
| イベントモニタリング | ⚠️ 規制で複数年の保存が必要な場合、コンプライアンス証拠のネイティブの保存制限を使用します。 |
| イベントモニタリング | ⚠️ 外部 SIEM ルーティングがない。 |
| イベントモニタリング | ⚠️ ネイティブのイベント監視保持の有効期限が切れ、監査証拠が失われるようにします。 |
| トランザクションセキュリティ | ⚠️ リアルタイムの予防管理がない。 |
| トランザクションセキュリティ | ⚠️ ポリシー違反が発生する前にブロックするのではなく、インシデント後の調査のみに任せます。 |
| 自動化されたコンプライアンス検証 | ⚠️ リリースパイプラインにコンプライアンスチェックがない。 |
| 自動化されたコンプライアンス検証 | ⚠️ リリース後に本番環境でコンプライアンス違反を検出します。 |
| 自動化されたコンプライアンス検証 | ⚠️ レビューなしでセキュリティ体制を弱めるリリースを許可します。 |
| 継続的な監査準備状況 | ⚠️ コンプライアンスは、何ヶ月も監査の準備を乱す必要がある年次イベントとして扱います。 |
| 継続的な監査準備状況 | ⚠️ 継続的な証拠の生成がない。 |
| 継続的な監査準備状況 | ⚠️ 監査中に修正が間に合わないギャップを発見できます。 |
監査履歴アーキテクチャ
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Setup Audit Trail | ✅ 180 日間の保持で管理設定の変更を監視します (すべてのエディションに含まれます)。 |
| Setup Audit Trail | ✅ 不正な変更がないか定期的に確認する。 |
| Setup Audit Trail | ✅ 構成管理統制のコンプライアンス証拠に使用します。 |
| 項目監査履歴 | ✅ 規制記録管理が必要な [制限付き] 項目と [機密] 項目で有効にします。 |
| 項目監査履歴 | ✅ コンプライアンス要件を満たすように保持を設定し (無期限保持をサポート)、リリースの規制に対して必要な期間を確認します。 |
| 項目監査履歴 | ✅ Shield が必要です。 |
| イベント監視の長期保存 | ✅ イベントモニタリングログを外部 SIEM に転送して、ネイティブ保持制限を超えて保持します。 |
| イベント監視の長期保存 | ✅ 規制でログの複数年保存が義務付けられている場合、コンプライアンス証拠として必要です。 |
| イベント監視の長期保存 | ✅ システム間調査用のエンタープライズセキュリティテレメトリとの相関関係を設定します。 |
| トランザクションセキュリティ | ✅ ユーザーアクションのリアルタイムのポリシーベースの評価を実装します (保持なし、イベントでのトリガー)。 |
| トランザクションセキュリティ | ✅ 迅速な対応が必要な予防管理 (禁止アクションのブロック、ステップアップ認証の要求、インシデント対応ワークフローのトリガーなど) に使用します。 |
| トランザクションセキュリティ | ✅ Shield ライセンスが必要です。 |
| カスタムアプリケーションログ | ✅ プラットフォーム監査履歴で取得されないセキュリティ関連のアプリケーションイベント (ビジネスロジック認証の決定、疑わしい入力パターン、レート制限の適用、カスタム認証イベント) のカスタム Apex ログを実装します。 |
| ログの整合性 | ✅ システム管理者の Salesforce アクセス権があっても攻撃者が変更できない不変の外部ストレージに監査ログを転送します。 |
| ログの整合性 | ✅ 捜査および法的手続きの可能性を裏付けるために、法廷証拠が改ざんされていないこと。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Setup Audit Trail | ⚠️ [設定] [監査履歴] で未承認の管理変更がないか確認しないでください。 |
| Setup Audit Trail | ⚠️ 証拠の有効期限が切れた数か月後に悪意のある設定変更を検出します (保持期間は 180 日)。 |
| 項目監査履歴 | ⚠️ 規制レコード管理の対象となる制限されたデータの項目監査履歴がない。 |
| 項目監査履歴 | ⚠️ 管理規制でリリースに必要な期間よりも短い保持を設定します。 |
| イベント監視の長期保存 | ⚠️ コンプライアンスの証拠は、Salesforce ネイティブの保持期間のみに依存します。 |
| イベント監視の長期保存 | ⚠️ 監査の準備中にログがすでに期限切れになっている場合にギャップを発見できます。 |
| イベント監視の長期保存 | ⚠️ システム間調査のためのエンタープライズセキュリティテレメトリとの相関関係がない。 |
| トランザクションセキュリティ | ⚠️ 高リスクアクションのリアルタイムの保険契約評価がない。 |
| トランザクションセキュリティ | ⚠️ ポリシー違反は、発生後数日または数週間後に手動でログを確認することでのみ検出できます。 |
| カスタムアプリケーションログ | ⚠️ カスタムビジネスロジックの承認決定やセキュリティ関連のアプリケーションイベントの記録がない。 |
| カスタムアプリケーションログ | ⚠️ 証拠がないため、認証の失敗や疑わしいパターンを調査できない。 |
| ログの整合性 | ⚠️ 監査ログは、システム管理者が変更または削除できる Salesforce にのみ保存します。 |
| ログの整合性 | ⚠️ 法医学的な保存のために不変の外部コピーがない。 |
| ログの整合性 | ⚠️ 法的手続きのために管理過程を失う。 |
データレジデンシーと主権
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Hyperforceの地域展開 | ✅ 組織のプロビジョニング時に、データ レジデンシー コンプライアンスを満たす適切なHyperforceリージョンを選択します。 |
| Hyperforceの地域展開 | ✅ Hyperforceには、データを特定の地理的境界内に保持する必要がある規制のデータ レジデンシー コンプライアンスを可能にする地域ごとの導入オプションが用意されています。 |
| データフローの対応付け | ✅ データの発生源、通過場所 (インテグレーションミドルウェア、外部サービス)、および存在場所 (ストレージ領域) を示すドキュメントデータフローマップ。 |
| データフローの対応付け | ✅ GDPR 第 30 条の処理活動レコードに必要です。 |
| 国際送金 | ✅ GDPR および同様の規制で要求される場合、国際的なデータ転送の標準契約条項または拘束力のある企業ルールを実装します。 |
| 国際送金 | ✅ 越境移送ごとに法的根拠を文書化します。 |
| 要件が競合するマルチ組織 | ✅ Hyperforce地域導入では単一組織では満たすことができないレジデンシー要件が競合する複数の管轄区域にまたがって運用する場合は、マルチ組織アーキテクチャを考慮します。 |
| 要件が競合するマルチ組織 | ✅ トレードオフ: マルチ組織は強力なデータ分離を提供しますが、運用の複雑さ、ライセンスコスト、インテグレーション要件が増加します。 |
| 複数組織のガバナンス | ✅ マルチ組織アーキテクチャの場合、コードとしての設定リポジトリの共有、組織間監視、統合 ID 管理により、組織全体で一貫したセキュリティベースラインを維持します。 |
| 複数組織のガバナンス | ✅ マルチ組織は最も強力な分離を提供しますが、ガバナンス表面積を増加します。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Hyperforceの地域展開 | ⚠️ データレジデンシー要件を評価しないで、グローバル組織のデフォルトの米国地域を選択します。 |
| Hyperforceの地域展開 | ⚠️ 不適切なリージョンの選択により、GDPR、LGPD、または地域のデータ主権法に違反する。 |
| データフローの対応付け | ⚠️ 文書化されたデータフローマップがない。 |
| データフローの対応付け | ⚠️ データの移行先や場所に関する監査人の質問に回答できない。 |
| データフローの対応付け | ⚠️ GDPR 第 30 条の処理活動レコードがないこと。 |
| 国際送金 | ⚠️ 標準契約条項、拘束力のある企業ルール、または文書化された法的根拠を使用せずにデータを国際的に転送します。 |
| 国際送金 | ⚠️ GDPR 移行制限に違反する。 |
| 要件が競合するマルチ組織 | ⚠️ 競合するデータレジデンシー要件を 1 つの組織に強制してコンプライアンス違反を引き起こす。 |
| 要件が競合するマルチ組織 | ⚠️ Hyperforce地域への導入を行う1つの組織が要件を満たす場合は、複数組織アーキテクチャを実装します(不要な複雑さ)。 |
| 複数組織のガバナンス | ⚠️ 複数の組織環境でセキュリティベースラインが一貫していない。 |
| 複数組織のガバナンス | ⚠️ セキュリティの実装は組織によって異なります。 |
| 複数組織のガバナンス | ⚠️ 組織全体で一貫したコンプライアンス体制を示すことができない。 |
セキュリティポスチャ管理
パターン
| 参照すべき場所 | 外観 |
|---|---|
| 四半期ごとのセキュリティ状態チェック | ✅ Salesforce セキュリティベースライン (パスワードポリシー、セッション設定、ネットワークアクセス、機能設定) と組織設定を四半期ごとに比較して状態チェックを実行します。 |
| 四半期ごとのセキュリティ状態チェック | ✅目標スコアが80%以上（非常に良いまたは良い帯域） |
| 四半期ごとのセキュリティ状態チェック | ✅ ベースライン未満に維持された設定のビジネス上の正当性と報酬に関する制御を含む例外を文書化します。 |
| Event Monitoring の分析 | ✅ 調査が必要な行動パターン (異常なデータアクセス量、業務時間外の管理活動、API 消費の異常) を明らかにするダッシュボードを設計します。 |
| Event Monitoring の分析 | ✅ 行動分析では、シグニチャベースの検出で見逃される脅威を検出します。 |
| ドリフトの自動検出 | ✅ 承認済みベースラインからの設定ドリフトを検出するパイプラインに自動コンプライアンステストを実装します。 |
| ドリフトの自動検出 | ✅ 設定がセキュリティ標準と異なる場合にアラートを表示します。 |
| 継続的なポスチャ監視 | ✅ 設定のドリフト、権限の蓄積、新しい脆弱性の出現に伴い、アクティブな管理を行わないとセキュリティ体制が低下します。 |
| 継続的なポスチャ監視 | ✅ 特定の時点の評価ではなく、継続的な監視を目的として設計します。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| 四半期ごとのセキュリティ状態チェック | ⚠️ 監査人が要求した場合にのみ状態チェックを実行します。 |
| 四半期ごとのセキュリティ状態チェック | ⚠️ 修正なしでスコアが 80% 未満になるようにします。 |
| 四半期ごとのセキュリティ状態チェック | ⚠️ 経時的な姿勢のトレンドを追跡していない。 |
| Event Monitoring の分析 | ⚠️ イベントモニタリングを有効にしているが、ダッシュボード、アラート、異常の調査は行っていない。 |
| Event Monitoring の分析 | ⚠️ [監査ログをセキュリティテレメトリではなくコンプライアンスとして処理] チェックボックス。 |
| ドリフトの自動検出 | ⚠️ 承認されたベースラインからの設定ドリフトの自動検出がない。 |
| ドリフトの自動検出 | ⚠️ 変更の数か月後の手動監査中にのみ、弱まっている設定を検出します。 |
| 継続的なポスチャ監視 | ⚠️ セキュリティは、継続的な運用状態ではなく、特定の時点の証明として扱います。 |
| 継続的なポスチャ監視 | ⚠️ 継続的な監視が存在しないため、年次監査の準備を急いでください。 |
Architecture Review Board Security Integration (アーキテクチャレビューボードセキュリティインテグレーション)
パターン
| 参照すべき場所 | 外観 |
|---|---|
| セキュリティレビューのタイミング | ✅ 大規模な構築投資を行う前の提案フェーズでセキュリティレビューをアーキテクチャレビューボード (ARB) に統合します。 |
| セキュリティレビューのタイミング | ✅ 開発終了時のセキュリティレビューが遅すぎて、基本的な設計上の意思決定に影響しない。 |
| アーキテクチャ決定レコード | ✅ セキュリティ要件、評価された代替案、許容されるトレードオフ、残存リスク、補償制御、監視アプローチを把握する ADR でセキュリティアーキテクチャに関する意思決定を文書化します。 |
| アーキテクチャ決定レコード | ✅ ADRは、監査証拠を提供し、Knowledge Transferを有効にして、意思決定の理由を記録することでアーキテクチャの進化をサポートします。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| セキュリティレビューのタイミング | ⚠️ セキュリティレビューは、開発が完了した後に実施してください。 |
| セキュリティレビューのタイミング | ⚠️ 構築が実質的に完了したら、再アーキテクチャが必要な基本的なセキュリティ上の欠陥を発見できます。 |
| セキュリティレビューのタイミング | ⚠️ セキュリティは後付けで高価になります。 |
| アーキテクチャ決定レコード | ⚠️ セキュリティアーキテクチャの決定に関するドキュメントがない。 |
| アーキテクチャ決定レコード | ⚠️ 特定のコントロールが選択された理由、評価された代替方法、受け入れられた残存リスクを説明できない。 |
| アーキテクチャ決定レコード | ⚠️ 監査証拠とKnowledge Transferが不足している。 |
サプライチェーンとサードパーティリスク
パターン
| 参照すべき場所 | 外観 |
|---|---|
| 導入前のセキュリティ評価 | ✅ AppExchangeセキュリティ レビューの状況(範囲、最終レビュー日、セキュリティ レビューの有効期限)を確認し、権限要件を評価し(パッケージに機能の理由以上のアクセス権が必要か?)、データ処理方法を評価し(データ フローの場所、外部で保持するもの、サードパーティ サービスに送信するデータ?)、ベンダー インシデント対応機能と通知手順を確認し、終了手順とデータの可搬性を理解します。 |
| AppExchange権限の精査 | ✅ 「すべてのデータの編集」、「すべてのデータの参照」、または機密権限を要求するパッケージには、さらに詳細な調査が必要です。 |
| AppExchange権限の精査 | ✅ 権限を昇格させるためのビジネスの正当性を文書化します。 |
| AppExchange権限の精査 | ✅ パッケージ機能に本当に範囲が付与されているかどうかを評価します。 |
| サードパーティインベントリ | ✅ リスク評価、リスク許容に関する意思決定の文書化、定期的なレビューケイデンスを使用して、サードパーティの連動関係(AppExchangeパッケージ、統合サービス、ミドルウェア)のインベントリを管理します。 |
| セキュリティアドバイザリの監視 | ✅ インストール済みパッケージと統合サービスに関するセキュリティアドバイザリを登録します。 |
| セキュリティアドバイザリの監視 | ✅ 新しい脆弱性、パッチが必要なバージョン更新、環境に影響するベンダーセキュリティインシデントを監視します。 |
| 継続的な監視 | ✅ インストール後に予期しないデータアクセスパターンや API コールの異常が発生していないかイベントモニタリングでパッケージの動作を監視します。 |
| 継続的な監視 | ✅ パッケージは昇格した権限で実行され、継続的なセキュリティ監視が必要です。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| 導入前のセキュリティ評価 | ⚠️ AppExchangeパッケージは、権限範囲、データアクセスパターン、ベンダーのセキュリティプラクティス、終了手順を評価しずに、機能のみに基づいてインストールします。 |
| 導入前のセキュリティ評価 | ⚠️ 過剰な権限を持つパッケージを精査せずに受け入れる。 |
| AppExchange権限の精査 | ⚠️ 「すべてのデータの編集」または「すべてのデータの参照」を要求するパッケージを、その機能が本当にその範囲を必要とするかどうかを疑うことなく付与します。 |
| AppExchange権限の精査 | ⚠️ 権限の昇格についてビジネス上の理由が文書化されていない。 |
| サードパーティインベントリ | ⚠️ サードパーティ連動関係のインベントリがない。 |
| サードパーティインベントリ | ⚠️ サードパーティデータアクセスに関する監査人の質問に回答できない。 |
| サードパーティインベントリ | ⚠️ インストール済みパッケージのリスク評価またはレビュースケジュールがない。 |
| セキュリティアドバイザリの監視 | ⚠️ インストール済みパッケージや統合サービスに影響するセキュリティアドバイザリを監視しないでください。 |
| セキュリティアドバイザリの監視 | ⚠️ 開示から数か月または数年後も既知の悪用に対して脆弱なままである。 |
| 継続的な監視 | ⚠️ パッケージをインストールし、その動作を監視しない。 |
| 継続的な監視 | ⚠️ パッケージが侵害されていないか、元の範囲を超えるデータへのアクセスが開始されていないかを検出できない。 |
| 継続的な監視 | ⚠️ パッケージ API 活動のイベント監視がない。 |