--- schema_version: "1" id: 80f601845747dac5081b52a29982d5296abd9262d721a3908776d7701553c6c0 title: 安全な開発ライフサイクル - パターン collection: architect version: current locale: ja-jp portal_url: https://docs.salesforce.com/architect/current/ja-jp/well-architected/guides/trust-secure-development-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/trust-secure-development-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 932a1e30aae4d5197e91872ec3d546b940b257cac31223f035f7a8a7a67360f7 products: - 適切に設計されたフレームワーク - Architect Site Content Repo --- # 安全な開発ライフサイクル - パターン Well-Architected [Trust](/docs/architect/ja-jp/well-architected/guide/trust.html) → [Secure Development Lifecycle](/docs/architect/ja-jp/well-architected/guide/trust.html#secure-development-lifecycle)の詳細 セキュリティは、初期設計からリリース、運用まで、開発ライフサイクル全体で統合する必要があります。これらのパターンにより、シフトなしのセキュリティプラクティスが可能になり、一般的な脆弱性に対処し、リリースパイプラインを保護できます。 ## シフト左のセキュリティ **パターン** | 参照すべき場所 | 外観 | | --- | --- | | 開発 \| Tooling | ✅ 開発者ワークフローに統合された IDE セキュリティスキャン | | 開発 \| 設計 | ✅ STRIDE 手法を使用した設計フェーズでの脅威モデリング | | 開発 \| 要件 | ✅ ユーザーストーリーと受け入れ条件に含まれるセキュリティ要件 | | 開発 \| ソース管理 | ✅ 事前確定フックはセキュリティポリシーを適用します (シークレットスキャン、コード分析) | | 開発 \| トレーニング | ✅ 進化する脅威を反映するために定期的に更新される開発者セキュリティトレーニング | | 開発 \| CI/CD | ✅ CI/CDパイプラインでの自動セキュリティ テストで重要な所見に基づくビルドが失敗する | | 開発 \| コードレビュー | ✅ 認証、承認、データアクセスコードに必要なセキュリティピアレビュー | | 開発 \| コード分析 | ✅ リンターと静的解析による安全なコーディング基準の適用 | | 開発 \| 連動関係 | ✅ すべての確定で連動関係脆弱性スキャンが実行される | | 開発 \| テスト | ✅ ペネトレーションテスト範囲には、正式リリース前の新機能が含まれます。 | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | 開発 \| テスト | ⚠️ セキュリティテストはリリース前の手動レビューに延期 | | 開発 \| トレーニング | ⚠️ オンボーディング中に 1 回のみ実施されるセキュリティトレーニング | | 開発 \| コードレビュー | ⚠️ セキュリティチームがマージ後にコードを確認する | | 開発 \| 設計 | ⚠️ アーキテクチャが変更されたときに脅威モデルが更新されない | | 開発 \| ソース管理 | ⚠️ 偽陽性を減らすためにシークレットスキャンが無効になっている | | 開発 \| CI/CD | ⚠️ リリース期限が近づいたときに無視されるセキュリティ上の発見 | ## Salesforce の OWASP トップ 10 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | インジェクション | ✅ SOQL クエリではバインド変数を使用してインジェクションを防止 | | インジェクション | ✅ SOQL、SOSL、動的クエリで使用する前に検証およびサニタイズされたユーザー入力 | | インジェクション | ✅ 動的 SOQL は信頼できる入力のみに制限 | | アクセス制御 | ✅ Security.stripInaccessible() を使用して適用される CRUD および FLS 権限 | | XSS | ✅ LightningコンポーネントがUIレンダリングでユーザー生成コンテンツをエスケープ | | インジェクション | ✅ 外部 API インテグレーションによるすべての入力の検証とサニタイズ | | アクセス制御 | ✅ ゲストユーザーアクセスの最小化と大幅な制限 | | 認証 | ✅ 外部認証に使用される指定ログイン情報 (ハードコードされたログイン情報ではない) | | 認証 | ✅ PKCE で正しく実装された OAuth 2.0 フロー | | セッション管理 | ✅ セッションセキュリティポリシーでタイムアウトと IP 制限を適用 | | 設定 | ✅ セキュリティ状態チェックは四半期ごとにレビューされ、リスクの高い指摘は是正されます。 | | アクセス制御 | ✅ 過剰な権限を防止するために監査されたカスタムメタデータと権限 | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | インジェクション | ⚠️ ユーザー入力との文字列連結を使用して作成された SOQL クエリ | | アクセス制御 | ⚠️ 「作成」、「更新」、または「削除」権限が付与されたゲストユーザープロファイル | | XSS | ⚠️ Lightning コンポーネントがテンプレートでエスケープされていない式を使用している | | 認証 | ⚠️ 外部インテグレーションでは、コードでハードコードされたログイン情報が使用されます。 | | ロギング | ⚠️ デバッグログには、パスワードや PII などの機密データが含まれます。 | | アクセス制御 | ⚠️ FLS および CRUD チェックは「すべてのユーザーを制御」するため省略 | | 設定 | ⚠️ Security Health Check の結果が無視または無期限に延期される | ## 安全なパイプライン設計 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | パイプライン \| ソース管理 | ✅ 支店保護ルールにより、必要なレビューと状況確認を実施 | | パイプライン \| アクセス制御 | ✅ リリースパイプラインでは、必要最小限の権限を持つサービスアカウントが使用されます。 | | パイプライン \| 秘密 | ✅ 安全な保管庫に保存されている秘密 (ソース制御や環境変数には決して保存されていない) | | パイプライン \| リリース | ✅ 本番リリースでは、承認された担当者による手動承認ゲートが必要 | | パイプライン \| 監査 | ✅ 承認履歴を使用して、誰がいつ何をリリースしたかを取得 | | Pipeline \| Validation (パイプライン \| 検証) | ✅ リリース前検証には、セキュリティスキャンとコンプライアンスチェックが含まれます。 | | パイプライン \| アクセス制御 | ✅ パイプライン管理者アクセスに必要な多要素認証 | | パイプライン \| 監視 | ✅ パイプライン設定の変更により、セキュリティチームへの通知がトリガーされる | | Pipeline \| Validation (パイプライン \| 検証) | ✅ 導入後の自動検証により、予想されるセキュリティ コントロールが有効になっていることを確認 | | パイプライン \| 連動関係 | ✅ リリース前にセキュリティ インパクトを評価する連動関係の更新 | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | パイプライン \| 秘密 | ⚠️ バージョン管理にコミットされた秘密 (後で削除した場合でも) | | パイプライン \| ソース管理 | ⚠️ レビューなしで誰でもメイン/本番ブランチにマージ可能 | | パイプライン \| アクセス制御 | ⚠️ リリースパイプラインは管理者権限で実行される | | パイプライン \| リリース | ⚠️ 承認ゲートのない完全自動化された本番リリース | | パイプライン \| 監査 | ⚠️ リリースログでは誰が変更を開始したか、または誰が変更を承認したかは取得されません。 | | Pipeline \| Validation (パイプライン \| 検証) | ⚠️ 失敗したセキュリティスキャンは無視されるか、期限に間に合うようにスキップされる | | パイプライン \| 監視 | ⚠️ パイプライン構成の変更が追跡またはレビューされていない | | Pipeline \| Validation (パイプライン \| 検証) | ⚠️ リリース後の検証では、機能の正しさのみがチェックされます。 | ## セキュリティテスト戦略 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | テスト \| 静的分析 | ✅ Salesforce Code Analyzer を開発者 IDE で実行してすぐにフィードバックを返し、CI/CD パイプラインで自動化ゲートとして実行 | | テスト \| 侵入テスト | ✅ 信頼できないユーザーに公開されたカスタムアプリケーション (特に Experience Cloud サイトと公開 API) に対して実施された侵入テスト | | テスト \| 単体テスト | ✅ セキュリティに重点を置いたApex単体テストは、異なる権限プロファイルを持つユーザーとして実行されます。 | | テスト \| 連動関係 | ✅ 連動関係スキャンで AgentExchange パッケージと JavaScript ライブラリの既知の脆弱性を監視 | | テスト \| セキュリティレビュー | ✅ AppExchangeExchange または AgentExchange セキュリティレビュー申請ごとに作成される静的分析レポート | | テスト \| セキュリティレビュー | ✅ ソリューションがサードパーティの Web アプリケーションまたはサービスを統合するときに作成される動的スキャン (侵入テスト) レポート | | テスト \| 連動関係 | ✅ 登録および監視されているインストール済みパッケージのセキュリティアドバイザリ | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | テスト \| 対象範囲 | ⚠️ セキュリティテストは静的分析などの 1 つの技術のみに依存します。 | | テスト \| 単体テスト | ⚠️ Apexテストは機能動作を検証しますが、権限の低いユーザーとして実行されることはありません。 | | テスト \| セキュリティレビュー | ⚠️ AppExchange または AgentExchange の提出書類 (必要な静的分析または動的スキャンレポートなし) | | テスト \| 侵入テスト | ⚠️ 公開されている Experience Cloud サイトおよび API のペネトレーションテストのスキップ | ## 関連パターン 関連トピック: - [コンプライアンスと規制](https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/trust-compliance-patterns.md)パターン — プラットフォームのガバナンスと監査の制御 - [ID およびアクセス](https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/trust-identity-access-patterns.md)管理パターン — 認証と承認 - [インシデント応答パターン](https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/trust-incident-response-patterns.md) — セキュリティイベントの検出と応答 - [エージェントパターン](https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/trust-agentic-patterns.md) — エージェント固有のセキュリティ制御