セキュアな開発計画の必須事項を取り入れる

この記事では、 開発セキュリティ規範の一部として、セキュリティを開発プラクティスに統合するための重要な命令を定義します。

最新の組織は、イノベーションを提供し、ビジネス要件を満たし、競争上の優位性を維持し、変化するビジネス ニーズに対応するために、迅速なソフトウェア開発に依存しています。 DevOps は、この機敏性を実現しますが、コード、インフラストラクチャ、デプロイ プロセスの進化に伴い、新しいセキュリティ リスクも導入されます。

DevOps プラクティスを安全に導入するには、組織は開発戦略、ワークフロー、および配信プロセスにセキュリティを統合し、ライフサイクル全体にわたってアプリケーションの配信をセキュリティで保護する DevSecOps プラクティスを採用する必要があります。

結果

この記事で計画の命令を採用することで、組織は次のことが可能になります。

  • 運用環境のワークロードへのセキュリティの弱点の導入を減らします。
  • 運用準備の決定の一貫性を向上させます。
  • 開発、セキュリティ、運用の間の摩擦を軽減します。
  • アプリケーションと配信インフラストラクチャの回復性を向上させます。
  • セキュリティと運用上のリスクを管理しながら、イノベーションの速度を維持します。

開発セキュリティのスコープを認識する

開発セキュリティは、アプリケーション コード以外にも適用されます。 組織は、ワークロードの設計、構築、デプロイ、運用に関連するすべてのコンポーネントでセキュリティ要件とアクティビティを定義する必要があります。

組織は、次のセキュリティ リスクを考慮する必要があります。

  • アプリケーション ロジックとサービス
  • インフラストラクチャの自動化/コードとしてのインフラストラクチャ (IaC) のデプロイ
  • パイプラインのビルドとリリース
  • デプロイ構成と運用スクリプト
  • 開発者環境とサービス ID
  • サード パーティの依存関係とサプライ チェーン コンポーネント

この完全な範囲を認識すると、組織は、ライフサイクルの後半でアプリケーション コード レビューにセキュリティを制限するのではなく、最新のワークロードの提供方法を反映するセキュリティ要件を定義するのに役立ちます。

重要なリスクを考慮する

組織は、要件を定義するときに、次のリスクを明示的に含める必要があります。

リスク領域 影響の例
アプリケーション設計の欠陥 不正アクセス、データ公開、永続的なロジックの欠陥。
パイプライン侵害 ビルド成果物への悪意のあるコードの挿入。
開発環境の侵害 資格情報の盗難または特権の昇格。
DevOps ツールの誤用 自動化または統合による未承認の変更。
サプライ チェーンの脆弱性 悪意のある依存関係または脆弱な依存関係の導入。

これらのリスクは、この記事で定義されている計画上の要件に直接反映されており、設計、プロセス、ガバナンスに関する意思決定を通じて対処する必要があります。

これらのリスクは、アプリケーション ワークロードと、それらを構築して運用するために使用されるインフラストラクチャの両方に影響します。

戦略/ライフサイクルにセキュリティを統合する

セキュリティは開発戦略に組み込む必要があります。リリース後のコントロールとしては適用されません。

組織は、機能要件と共にセキュリティ要件を定義し、次の要件に合わせる必要があります。

  • 開発戦略
  • アーキテクチャの計画
  • 配信ワークフロー
  • 運用サポート モデル

セキュリティの成果は、エンジニアリングと運用の役割によって所有される共同責任であり、セキュリティ スペシャリストによってサポートされます。

セキュリティによってイノベーションが可能になります。これは、配信後に適用されるゲートではありません。

組織は、以下を含む継続的なセキュア開発ライフサイクル (SDL) アプローチを採用する必要があります。

  • 設計の早い段階でセキュリティ要件を定義する。
  • アーキテクチャと実装に関するセキュリティ要件の調整。
  • セキュリティとインフラストラクチャの自動化の統合。
  • 継続的なセキュリティ検証の実行。
  • セキュリティ検出結果の追跡。
  • 修復の優先順位付け。
  • 必要に応じてセキュリティ上の問題を本番リリースの阻害要因として扱えるように、セキュリティ上の検出事項をリリース可否の判断に反映すること。

アプリケーション アーキテクチャ、リスク、配信モデルの進化に伴い、セキュリティを継続的に評価し、改善する必要があります。

最小限の生産の実行可能性基準を定義する

ワークロードは、運用環境のリリース前に最小限の実行可能条件を満たす必要があります。 次の条件は、ワークロードが安全で、準拠しており、運用上、3 つのディメンションにわたって運用環境で使用できる状態であるかどうかを定義します。

  • 開発 (開発): 開発関係者は、ビジネス ニーズと顧客/ユーザーの価値を満たすために必要な最小限の機能要件を定義します。
  • セキュリティ (秒) : セキュリティ関係者は、規制上の義務を満たし、組織のセキュリティ体制を維持し、アクティブな脅威の検出と対応をサポートするために必要な最小要件を定義します。
  • 運用 (運用): 運用関係者は、運用環境でワークロードを確実に運用するために必要な最小限のパフォーマンス、品質、およびサポート性の要件を定義します。

生産の実行可能性の基準:

  • 運用環境でワークロードを安全にデプロイして運用できるようにします。
  • リリース決定の入力として機能し、開発ワークフロー全体で一貫して適用する必要があります。

運用環境の実行可能性の基準は、次の変更に基づいて進化します。

  • アプリケーション配信モデル。
  • 脅威の状況。
  • 組織のリスク許容度。
  • コンプライアンス要件。

開発ワークフローにセキュリティを統合する

セキュリティは、開発および配信プロセスに直接埋め込む必要があります。 組織は次のことが必要です。

  • 開発ワークフロー内でセキュリティ要件を定義します。
  • セキュリティ活動を次に組み込みます:
    • 設計プロセス
    • パイプラインをビルドする
    • デプロイ ワークフロー (CI/CD)
  • 次のようなセキュリティ検証メカニズムを実装します。
    • コード スキャン
    • 依存関係の検証
    • 構成の確認

セキュリティの結果は、運用環境の欠陥と同じように扱い、リリースの決定に組み込む必要があります。

セキュリティ検証は、リリース チェックポイントだけでなく、配信を通じて継続的に行われる必要があります。

要件のバランスと調和

組織は、ソフトウェアの配信に関する決定において、開発、セキュリティ、運用の要件のバランスを定義する必要があります。 運用環境のワークロードは、次の要件を満たす必要があります。

  • ビジネス機能。
  • セキュリティの回復性。
  • イノベーションのスピード。
  • 運用の信頼性とパフォーマンス。

組織は、共有配信の目標とパフォーマンス メトリックを定義する必要があります。

  • 開発、セキュリティ、運用全体で共有されるパフォーマンスと配信の目標に合わせて調整します。
  • 1 つのドメインによる支配を避けます。
  • 次に基づいて結果に優先順位を付けます。
    • 組織のリスク許容度。
    • 規制上の義務。
    • ビジネスアカウンタビリティ。

脅威の状況の進化、配信モデルの変更、組織の優先順位の変化に合わせてバランスを調整する必要があります。

共有アカウンタビリティを確立する

効果的なDevSecOpsを実現するには、開発、セキュリティ、運用の各チームが共同で責任を担い、次の点を見据える必要があります:

  • 生産の実行可能性基準の所有権を調整する。
  • 複数の規範にわたって配信目標を調整する。
  • セキュリティ上のギャップ、リリースの遅延、運用の不安定化を招くサイロ化や不健全な摩擦を減らすこと。

ポリシー駆動型セキュリティ ガードレールを適用する

ポリシー駆動型のガードレールでは、過度の摩擦を発生させずに制御を適用する必要があります。 ガードレールには次のものが含まれている必要があります。

  • ID とアクセスの要件。
  • 構成とコンプライアンスの標準。
  • 展開とリリースのコントロール。

ガードレールは次のようになります。

  • プラットフォーム基盤 (ランディング ゾーンなど) に統合されています。
  • 開発/デプロイ ワークフローに埋め込まれます。
  • 可能な場合は自動的に適用されます。

このアプローチにより、配信速度を維持しながら、セキュリティ要件が一貫して適用されます。

セキュリティとイノベーションのスピードのバランスのとれたアプローチについては、 ポリシー駆動型ガードレールを使用して導入を確認します。

維持と改善

セキュリティは、静的な一連のコントロールのままで有効であり続けることはできず、時間の経過とともに進化していく必要があります。

組織は、次の変更に対応して、開発のセキュリティ プラクティスを継続的に評価し、更新する必要があります。

  • 脅威の状態と攻撃者の動作。
  • アプリケーション アーキテクチャと配信モデル。
  • 規制上の義務。
  • 組織のリスク許容度。
  • 生産の実行可能性の基準。
  • 開発デリバリープロセス。
  • セキュリティ ガバナンスのプラクティス。

セキュリティ プラクティスは、保護するシステムと共に進化する必要があります。

アラインメント手法

チームは以下に沿う必要があります。

  • 共通の目標を定義する: 開発、セキュリティ、運用のリーダーは、一貫したリリース計画をサポートするために、ワークロード配信の配信目標とパフォーマンス メトリックを共同で定義する必要があります。
  • 単一ドメインの意思決定の支配を防ぐ: ワークロードの信頼性、コンプライアンス、またはビジネス機能に悪影響を与える可能性のある不均衡を回避するために、開発、セキュリティ、運用の要件に対して配信の決定を考慮する必要があります。
  • 静的リリース条件よりも継続的な改善に優先順位を付ける: アプリケーション配信モデル、脅威条件、組織の優先順位が進化するにつれて、開発のセキュリティ プラクティスを時間の経過と同時に繰り返し改善する必要があります。
  • 利害関係者の役割間で共有配信コンテキストを確立する: 開発、セキュリティ、運用チームは、次の共通の理解を維持する必要があります。
    • ビジネスの緊急性と配信のタイムライン
    • 関連する脅威の状態とリスクの露出
    • 運用上の可用性とサポートの要件
  • セキュリティ要件によって導入された配信の摩擦を監視する: セキュリティ要件では、配信の摩擦が発生する可能性があります。 リーダーは、この摩擦がリスクの軽減 (たとえば、脆弱性の早期識別を可能にするなど) に寄与するか、または運用環境の回復性を大幅に向上させることなくワークロードの配信を不必要に遅らせるかを評価する必要があります。
  • 開発セキュリティを計画とリソース割り当てに組み込む: アプリケーション ワークロードのセキュリティ要件は、機能と運用サポート要件と共に、開発計画とリソース割り当てに組み込む必要があります。
  • 共有配信のパフォーマンス目標を定義する: アプリケーション ワークロードのパフォーマンスと成功のメトリックは、開発、セキュリティ、運用上の配信結果を反映する必要があります。

ワークフローをセキュリティ要件に合わせる

開発ワークフローを通じてセキュリティを運用化する必要があります。 組織は、次の目的でワークフローを定義して調整する必要があります。

  • アーキテクチャ設計アクティビティ。
  • ビルドとデプロイのプロセス。
  • 問題の追跡と修復のワークフロー。

セキュリティ検出結果は、次の条件を満たしている必要があります:

  • 優先順位付けと追跡。
  • 生産上の欠陥と共に管理されます。
  • リリース準備の決定に組み込まれます。

ワークフローの配置により、セキュリティ要件が配信全体で一貫して適用されます。

次のステップ

ゼロ トラスト原則を使用した開発の概要

  • Last updated on