次の方法で共有

開発ライフサイクルのセキュリティ保護に関する推奨事項

  • [アーティクル]

以下の Azure Well-Architected フレームワーク セキュリティ チェックリストの推奨事項に対応します。

SE:02 セキュリティで保護され、大部分が自動化された、監査可能なソフトウェア サプライ チェーンを使用することで、安全な開発ライフサイクルを維持する。 セキュリティを低下させる実装に対する保護を提供する脅威モデリングを使用することで、安全な設計を取り入れる。

関連ガイド: 脅威分析

このガイドでは、開発サイクル全体でセキュリティのベスト プラクティスを適用することで、コード、開発環境、ソフトウェア サプライ チェーンを強化するための推奨事項について説明します。 このガイダンスを理解するには、DevSecOps に関する知識が必要です。

セキュリティ サイクルの図。

DevSecOps は、以下の方法でセキュリティを DevOps のプロセスに統合します。

  • セキュリティ テストと検証の自動化

  • セキュリティ パイプラインなどのツールを実装することで、コードやコードとしてのインフラストラクチャ (IaC) の脆弱性をスキャン

ワークロードの中核となるのは、ビジネス ロジックを実装するアプリケーション コードです。 機密性、整合性、可用性を確保するため、コードとコードの開発プロセスにはセキュリティ上の欠陥がないようにする必要があります。

ID やネットワークを制御するなどの手段を使用して、インフラストラクチャ プレーンのみをセキュリティで保護するだけでは不十分です。 全体的なセキュリティ態勢を強化するためには、コードやセキュリティ侵害されたコード ブロックの不適切な実装を防止します。 使用プレーン、つまりアプリケーション コードも強化する必要があります。 開発ライフサイクルにセキュリティを統合するプロセスは、本質的にはセキュリティ強化プロセスです。 リソースの強化と同様、コード開発の強化もコンテキストに依存しません。 アプリケーションの機能要件ではなく、セキュリティの強化に重点を置きます。 セキュリティ強化に関連する情報については、「リソースの強化に関する推奨事項」を参照してください。

定義

相談 定義
セキュリティ開発ライフサイクル (SDL) セキュリティ保証とコンプライアンス要件をサポートする、Microsoft が提供する一連のプラクティス。
ソフトウェア開発ライフサイクル (SDLC) ソフトウェア システムを開発するためのマルチステージの体系的なプロセス。

主要な設計戦略

セキュリティ対策を複数のポイントにおいて既存のソフトウェア開発ライフサイクル (SDLC) に統合して、以下を確実にする必要があります。

  • 設計の選択によってセキュリティにギャップが生じない。

  • 悪用可能な実装と不適切なコーディング方法によってアプリケーション コードと構成に脆弱性が生じない。

  • サプライ チェーンを介して取得されたソフトウェアによって、セキュリティ上の脅威が発生しない。

  • アプリケーション コード、ビルド、デプロイのプロセスが改ざんされない。

  • インシデントによって明らかになった脆弱性が軽減される。

  • 使用されていない資産は適切に使用停止される。

  • コンプライアンス要件が侵害されたり損なわれたりしない。

  • 監査ログが開発環境に実装されている。

次のセクションでは、一般的に実践される SDLC のフェーズにおけるセキュリティ戦略について説明します。

セキュリティ要件を収集して文書化する

要件フェーズの目的は、アプリケーションまたはアプリケーションの新機能について、機能要件と非機能要件を収集して分析することです。 このフェーズは、アプリケーションの目的に合致したガードレールの作成を容易にするために重要です。 アプリケーションのデータと整合性を保護することは、開発ライフサイクルのあらゆるフェーズを通じて中核となる要件である必要があります。

たとえば、ユーザーがデータをアップロードして操作できるようにする重要なユーザー フローをサポートする必要があるアプリケーションについて考えてみましょう。 セキュリティ設計の選択では、ユーザー ID の認証と承認、データに対する許可されたアクションのみの許可、SQL インジェクションの防止など、ユーザーによるアプリケーションの操作に関する保証をカバーする必要があります。 同様に、可用性、スケーラビリティ、保守容易性などの機能以外の要件もカバーします。 セキュリティの選択には、セグメント化の境界、ファイアウォールのイングレスとエグレス、およびその他の横断的なセキュリティ上の懸念事項が含まれている必要があります。

これらすべての決定事項は、アプリケーションのセキュリティ態勢の適切な定義につながります。 合意された仕様でセキュリティ要件を文書化し、バックログに反映します。 セキュリティ投資と、その投資がビジネスの利害関係者によって承認されていない場合に、ビジネスで引き受ける覚悟があるトレードオフとリスクを明示的に示す必要があります。 たとえば、Azure Front Door や Azure Application Gateway など、アプリケーションの前面で Web アプリケーション ファイアウォール (WAF) を使用する必要性を文書化します。 WAF を実行するための追加コストを受け入れる準備ができていないビジネスの利害関係者は、アプリケーションがアプリケーション レイヤー攻撃の標的にされるリスクを受け入れる必要があります。

セキュリティ要件の収集は、このフェーズの重要な部分です。 この作業がなければ、設計と実装のフェーズは暗黙の選択に基づいて行われることになり、セキュリティのギャップにつながる可能性があります。 セキュリティに対応するため、後で実装を変更することが必要になる場合があります。これにはコストがかかります。

セキュリティ要件を技術的な要件に変換する

設計フェーズでは、セキュリティ要件が技術的要件に変換されます。 技術仕様では、実装時のあいまいさを防ぐために、設計上の決定事項をすべて文書化します。 一般的なタスクは次のとおりです。

システム アーキテクチャのセキュリティ ディメンションを定義する

アーキテクチャをセキュリティ制御でオーバーレイします。 たとえば、セグメント化戦略、アプリケーションのコンポーネントに必要な ID の種類、使用する暗号化方法の種類に基づく分離境界上で実用的な制御などです。 アーキテクチャの例については、ID とアクセスの管理やネットワークに関する記事中の「例」のセクションにある図を参照してください。

プラットフォームによって提供されるアフォーダンスを評価する

お客様とクラウド プロバイダーとの責任分担を理解することが重要です。 たとえば、Azure のネイティブ セキュリティ制御との重複を避けます。 セキュリティ カバレッジが向上し、開発リソースをアプリケーションのニーズに再割り当てできるようになります。

たとえば、設計に Web アプリケーション ファイアウォールがイングレスで必要な場合は、その任務を Application Gateway や Azure Front Door などのロード バランサーに任せることができます。 アプリケーションにおいてカスタム コードとして機能をレプリケートしないようにします。

信頼できるフレームワーク、ライブラリ、サプライ チェーン ソフトウェアのみを選びます。 設計では、安全なバージョン管理も指定する必要があります。 アプリケーションの依存関係は、信頼できるパーティからのものにします。 サード パーティ ベンダーは、セキュリティ要件を満たし、責任ある情報開示計画を共有できる必要があります。 セキュリティ インシデントが発生した場合は、必要な措置を講じられるよう、速やかに報告される必要があります。 また、組織によっては特定のライブラリが禁止されている場合もあります。 たとえば、ソフトウェアにセキュリティ上の脆弱性がなくても、ライセンスの制限によって許可されていない場合があります。

ソフトウェアのすべての共同作成者がこのガイダンスに確実に従うよう、承認済み/未承認のフレームワーク、ライブラリ、ベンダーのリストを保持するようにします。 可能な場合は、開発パイプラインにガードレールを配置して、このリストをサポートします。 可能な限り、脆弱性がないか依存関係をスキャンするツールの使用を自動化します。

アプリケーション コードで実装する必要があるセキュリティ設計パターンを決定します。

パターンは、セグメント化と分離、強力な認証、均一なアプリケーション セキュリティ、最新のプロトコルなどのセキュリティに関する懸念事項をサポートできます。 検疫パターンなどの一部の運用パターンは、セキュリティの脆弱性を引き起こす可能性があるソフトウェアの使用を検証してブロックするのに役立ちます。

詳細については、「セキュリティをサポートするクラウド設計パターン」を参照してください。

アプリケーション シークレットの安全な格納

アプリケーションで使用するアプリケーション シークレットと事前共有キーの使用を安全に実装します。 資格情報とアプリケーション シークレットは、絶対にソース コード ツリーに格納しないでください。 Azure Key Vault などの外部リソースを使用し、潜在的な攻撃者がソース コードを利用できる状態になった場合でも、それ以上アクセスできないようにします。 基本的には、シークレットを回避できる方法を探します。 その目標を達成するための 1 つの方法として、可能な場合はマネージド ID を使用します。 詳細については、「アプリケーション シークレットの管理に関する推奨事項」を参照してください。

テスト計画を定義する

セキュリティ要件の明確なテスト ケースを定義します。 パイプラインにおいてこれらのテストを自動化できるかどうかを評価します。 チームに手動テストのプロセスがある場合は、それらのテスト用のセキュリティ要件を含めます。

Note

脅威モデリングはこのフェーズで行います。 脅威モデリングによって、設計の選択がセキュリティ要件に合っていることを確認し、軽減すべきギャップを明らかにすることができます。 ワークロードで機密性の高いデータが処理される場合は、脅威モデリングの実施を支援できるセキュリティ専門家に依頼します。

最初の脅威モデリングの演習は、ソフトウェアのアーキテクチャと概要設計が定義される設計フェーズで行う必要があります。 このフェーズでこれを行うことで、システムの構造に組み込まれる前に潜在的なセキュリティの問題を特定することができます。 ただし、この演習は 1 回限りのものではありません。 これは、ソフトウェアの進化を通じて続ける必要がある継続的なプロセスです。

詳細については、「脅威分析に関する推奨事項」を参照してください。

安全な開発とテストのプラクティス

開発とテストのフェーズでは、コード、ビルド、およびデプロイ パイプラインのセキュリティ上の欠陥と改ざんを防ぐことが目標になります。

安全なコーディング プラクティスについて十分なトレーニングを受ける

開発チームは、安全なコーディング プラクティスに関する正式で専門的なトレーニングを受ける必要があります。 たとえば、Web および API 開発者は、クロスサイト スクリプティング攻撃から保護するための特定のトレーニングを必要とする場合があります。バックエンド開発者には、SQL インジェクション攻撃などのデータベースレベルの攻撃を回避するための詳細なトレーニングが役立つかもしれません。

開発者には、運用環境のソース コードにアクセスする前にこのトレーニングを修了することを義務付けるようにします。

また、継続的な学習を促進するため、社内でピア コードのレビューを行いましょう。

セキュリティ テスト ツールを使用する

脅威モデリングを実行して、アプリケーションのアーキテクチャのセキュリティを評価します。

静的アプリケーション セキュリティ テスト (SAST) を使用し、コードの脆弱性を分析します。 この手法を開発環境に統合して、リアルタイムで脆弱性を検出します。

動的アプリケーション セキュリティ テスト (DAST) をランタイム中に使用します。 このツール チェーンにより、セキュリティ ドメインにエラーがないか確認し、一連の攻撃をシミュレートして、アプリケーションのセキュリティ回復性をテストできます。 可能な場合は、このツールをビルド パイプラインに統合します。

安全なコーディング プラクティスについては、業界標準に従います。 詳細については、この記事の「コミュニティのリソース」セクションを参照してください。

リンターとコード アナライザーを使用して、資格情報がソース コード リポジトリにプッシュされないようにします。 たとえば、.NET Compiler Platform (Roslyn) アナライザーはアプリケーション コードを検査します。

ビルド プロセス中に、パイプラインのアドオンを使用してソース コード内の資格情報を取得します。 継続的インテグレーション プロセスの一環として、サードパーティのライブラリやフレームワーク コンポーネントなどのすべての依存関係をスキャンします。 ツールによってフラグが設定された、脆弱性のあるコンポーネントを調査します。 このタスクを、コード チャーン、テスト結果、カバレッジを検査する他のコード スキャン タスクと組み合わせます。

複数のテストを組み合わせて使用します。 セキュリティ テスト全般の詳細については、「セキュリティ テストに関する推奨事項」を参照してください。

必要十分なコードのみ書く

コードのフットプリントを減らすと、セキュリティ上の欠陥が発生する可能性も減らすことができます。 コードを複製するのではなく、既に使用されており、セキュリティ検証を通過しているコードとライブラリを再利用するようにします。

Azure の機能を活用することも、不要なコードを避けるのに役立ちます。 マネージド サービスを使用する、という手もあります。 詳細については、「サービスとしてのプラットフォーム (PaaS) オプションを使用する」参照してください。

既定ですべてを拒否するアプローチでコードを記述します。 アクセスが必要なエンティティに対してのみ、許可リストを作成します。 たとえば、特権操作を許可するかどうかを判断する必要があるコードがある場合は、"拒否" という結果が既定のケースになり、コードによって明示的に許可されている場合にのみ "許可" という結果が発生するように書く必要があります。

開発環境を保護する

露出を防ぐために、強力なネットワークと ID 制御を使用して、開発者ワークステーションを保護する必要があります。 セキュリティ更新プログラムが確実に適用されていることを確認します。

ビルド エージェントは高い特権を持ち、ビルド サーバーとコードにアクセスできます。 これらは、ワークロード コンポーネントと同じ厳格さで保護する必要があります。 つまり、ビルド エージェントへのアクセスは認証・承認される必要があり、ファイアウォール制御でネットワーク セグメント化したり、脆弱性スキャンの対象にしたりする必要があります。 Microsoft でホストされるビルド エージェントは、セルフホステッド ビルド エージェントよりも優先される必要があります。 Microsoft がホストするエージェントは、パイプラインの実行ごとにクリーンな仮想マシンのような利点を提供します。

カスタム ビルド エージェントは、管理の複雑さを増加させ、攻撃ベクトルになる可能性があります。 ビルド マシンの資格情報は安全に保存する必要があり、一時的なビルド成果物はファイル システムから定期的に削除する必要があります。 ネットワークを分離するには、ビルド エージェントからの送信トラフィックのみを許可します。これは、Azure DevOps との通信のプル モデルを使用しているためです。

また、ソース コード リポジトリも保護する必要があります。 必要な限度でコード リポジトリへのアクセスを許可し、脆弱性の露出をできるだけ減らすことで攻撃を回避します。 セキュリティの脆弱性がないかコードを徹底的に確認するプロセスを設けます。 この目的のためにセキュリティ グループを使用し、業務上の正当な理由に基づく承認プロセスを実装します。

デプロイ パイプライン内のコードを保護する

コードをセキュリティで保護するだけでは不十分です。 悪用可能なパイプラインで実行される場合、すべてのセキュリティ対策は不完全で無益になります。 不正なアクターがパイプラインで悪意のあるコードを実行しないよう、ビルド環境とリリース環境も保護する必要があります。

アプリケーションに統合されているすべてのコンポーネントの最新のインベントリを維持する

アプリケーションに新しいコンポーネントが統合されるたびに、攻撃面は増します。 新しいコンポーネントが追加または更新されたときに適切なアカウンタビリティとアラートが確実に実施されるようにするには、これらのコンポーネントのインベントリが必要です。 これはビルド環境の外部に保存します。 マニフェストがビルド プロセスの内容と一致していることを定期的に確認します。 これにより、バック ドアやその他のマルウェアを含む新しいコンポーネントが予期せず追加されないようにすることができます。

パイプラインのタスク

  • Azure Marketplace など、信頼できるソースからパイプライン内のタスクをプルします。 パイプライン ベンダーによって書かれたタスクを実行します。 GitHub タスクまたは GitHub Actions が推奨されます。 GitHub ワークフローを使用する場合は、Microsoft が作成したタスクを優先します。 また、タスクはパイプラインのセキュリティ コンテキストで実行されるため、検証するようにします。

  • パイプライン シークレット。 パイプライン内で実行されるデプロイ資産は、そのパイプライン内のすべてのシークレットにアクセスできます。 不要な露出を回避するために、パイプラインの各ステージに適切なセグメント化を配置します。 パイプラインに組み込まれているシークレット ストアを使用します。 状況によってはシークレットの使用を避けられる場合があることに留意してください。 ワークロード ID (パイプライン認証用) やマネージド ID (サービス間認証用) の使用も検討します。

異なる環境を個別に保持する

異なる環境で使用されるデータは、個別に保持する必要があります。 運用環境が持つ厳密なセキュリティ制御を持たない可能性があるため、運用環境のデータは下位環境では使用しないでください。 非運用アプリケーションから運用データベースへの接続は避け、非運用コンポーネントを運用ネットワークに接続しないようにします。

段階的公開

選択した条件に基づいてユーザーのサブセットに機能をリリースするには、段階的な公開を使用します。 問題が生じた場合、影響はそれらのユーザーのみに最小限に抑えられます。 このアプローチは、攻撃可能な領域を狭められるため、リスク軽減戦略として一般的です。 機能が成熟し、セキュリティ保証に対する信頼度が高まったら、徐々に広範なユーザーにリリースします。

運用環境でのコードの保護

運用フェーズは、セキュリティ ギャップを修正するラスト チャンスです。 運用環境でリリースされたゴールデン イメージの記録を保持しましょう。

バージョン管理された成果物を保持する

デプロイされたすべての資産とそのバージョンのカタログを保持します。 この情報は、インシデントをトリアージするとき、問題を軽減するとき、およびシステムを動作状態に戻すときに役立ちます。 バージョン管理された資産は、公開されている共通脆弱性識別子 (CVE) の通知と比較することもできます。 これらの比較を実行するには、自動化を使用する必要があります。

緊急修正

自動化されたパイプラインの設計には、通常と緊急の両方のデプロイをサポートする柔軟性が必要です。 この柔軟性は、迅速で責任あるセキュリティ修正をサポートするために重要です。

通常、リリースは複数の承認ゲートに関連付けられます。 セキリュティ修正を高速化する緊急プロセスを作成することを検討してください。 このプロセスには、チーム間のコミュニケーションが必要になる場合があります。 このパイプラインは、定期的なデプロイ ライフサイクル以外で発生するセキュリティ修正プログラム、クリティカルなバグ、およびコードの更新プログラムに対応する迅速なロールフォワードとロールバックのデプロイを可能にするものである必要があります。

Note

利便性よりも、常にセキュリティ修正を優先します。 セキュリティ修正によって回帰やバグが発生しないようにしてください。 緊急パイプラインを通じて修正を加速したい場合は、どの自動テストを省略できるかを慎重に検討してください。 各テストの値を実行時間で評価します。 たとえば、単体テストは通常、迅速に完了します。 統合またはエンドツーエンドのテストは時間がかかる場合があります。

コードのセキュリティをライフサイクル全体にわたって維持する

このフェーズの目的は、セキュリティ態勢が時間の経過と共に減衰しないようにすることです。 SDLC は、継続的なアジャイル プロセスです。 要件は時間の経過と共に変化するため、前述のフェーズで説明した概念はこのフェーズにも適用されます。

更新プログラムの管理。 セキュリティ パッチと更新プログラムを使用して、ソフトウェアやライブラリ、インフラストラクチャ コンポーネントを最新の状態に保つようにしましょう。

継続的な改善。 コード レビュー、フィードバック、得られた経験、進化する脅威を考慮して、ソフトウェア開発プロセスのセキュリティを継続的に評価し、改善します。

古い、または使用されなくなったレガシ資産は使用を停止します。 これにより、攻撃可能な領域が狭まります。

メンテナンスには、インシデントの修正も含まれます。 運用環境で問題が見つかった場合は、再発しないように、これらはすぐにプロセスに統合される必要があります。

脅威ランドスケープに対応できるよう、安全なコーディング プラクティスを継続的に改善するようにします。

Azure ファシリテーション

Microsoft セキュリティ開発ライフサイクル (Security Development Lifecycle: SDL) では、開発ライフサイクルに適用できる安全なプラクティスが推奨されています。 詳細については、「Microsoft セキュリティ開発ライフサイクル」を参照してください。

Defender for DevOps と SAST ツールは、GitHub Advanced Security または Azure DevOps の一部として含まれています。 これらのツールによって、組織のセキュリティ スコアを追跡することができます。

以下のリソースで説明されている Azure のセキュリティに関する推奨事項に従います。

ソース コード内の資格情報を見つけるために、GitHub Advanced Security や OWASP ソース コード分析ツールなどのツールを使用することを検討します。

アプリケーション内のオープンソース コードのセキュリティを検証します。 以下の無料のツールとリソースは、評価の際に役立ちます。

セキュリティ チェックリスト

レコメンデーションの完全なセットを参照してください。

セキュリティ チェックリスト