次の方法で共有

DevSecOps の制御

  • [アーティクル]

この記事では、継続的 SDL セキュリティ プラクティスをサポートするためにセキュリティ制御を適用する方法について説明します。 これらのセキュリティ制御は、人、プロセス、テクノロジーにまたがる DevSecOps 戦略 の不可欠な部分です。 このドキュメントでは、各コントロールについて説明し、これらのコントロールを 3 種のセキュリティ プロファイルに適用する方法を説明します。 これらのプロファイルは、ほとんどの組織で共通のビジネス シナリオの一般的なセキュリティ要件を満たしています:

セキュリティ制御対時間および影響のダイアグラム。

セキュリティ コントール プロファイル

この記事で参照される制御プロファイルに 3 レベルあります。

一時的な最小 – リスクの低いワークロードの迅速なプロトタイプ作成をサポートするための、一時的な例外状態 に対し省略されたセキュリティ プロファイル。 このプロファイルは、重要なビジネス ニーズを満たすために高速タイムラインでリリースする必要がある一時的な例外に対してのみ使用する必要があります。 このプロファイルを使用するアイテムは、標準プロファイルに迅速に設定する必要があります。

Standard - ほとんどの場合に大部分のワークロードに適用されるバランスの取れたアプローチ。

高いセキュリティ – ビジネスと人間の安全に大きな影響を与える可能性のあるワークロードの厳格なセキュリティ。

DevSecOps のセキュリティ制御

このセクションでは、ワークロードの種類ごとに推奨されるセキュリティ制御のリファレンスを説明します。 このリファレンスをそのまま採用するか、既存のソフトウェア開発およびソフトウェア セキュリティ プロセスに適合させることができます。 ほとんどの組織では、これらのコントロールの一部をまだ実行していない場合、これらのすべてのコントロールをすぐに実装することはできません。 多くの場合、継続的な改善アプローチを採用することが最善の方法です。つまり、コントロールの優先順位付け、最初のコントロールの実装、次のコントロールへの移行、その実装などです。 ほとんどの組織は、最初に 重要な基盤 を優先する必要があります。

詳細については、「DevSecOps 体験」を参照してください。

この図は、セキュリティ制御と、それらを各ワークロード セキュリティ プロファイルに適用する方法をまとめたものです。

計画に関する主要な考慮事項は次のとおりです:

  • 左シフト。 ただし、ダブルチェックします - このリファレンスは、できるだけ早く問題を検出して修正するように設計されており、問題を修正する方が簡単かつ安価な場合に修正ができるようになります (左シフトと呼ばれることもあります)。ただし、エラーを想定して、プロセスの後半にはダブル チェックが含まれます。 CI/CD プロセスのセキュリティ制御を常にチェックし、回避可能な問題が運用システムに入らないようにします。 この概念は、"多層防御" と "フェイル セーフ" の原則に従います。
  • 人工知能 (AI) – 人工知能の 2 つの主な影響は次のとおりです:
    • 書いたのが人間か生成 AI かに関係なく、すべてのコードをセキュリティで保護する
    • セキュリティに両方を使用する - 使用可能な標準的な制御と AI 制御の両方を適用して、セキュリティの問題 (コード分析ツールなど) の可視性とコンテキストを向上させます

セキュリティ コントロール

このコントロールは、適用する開発段階と、すべての開発ステージとコントロール プロファイルに適用される共通のコントロール (重要な基盤) にグループ化されます:

これらのアイテムのそれぞれについて次のセクションで定義します:

重要な基盤を確立します

このコントロールは、継続的 SDL プラクティス 1 - セキュリティ標準、メトリック、ガバナンスの確立、プラクティス 2 – 実証済みのセキュリティ機能、言語、フレームワークの使用の要求、プラクティス 10 – セキュリティ トレーニングの提供をサポートします。

Standard - これらのコントロールは、すべての開発ステージとコントロール プロファイルに適用されます。

セキュリティ トレーニングの提供

このコントロールは、開発ライフサイクルを通じてセキュリティの問題を認識して解決するためのトレーニングを開発者とセキュリティ チームに提供することに重点を置いています。 セキュリティ トレーニングがなければ、チームは、アプリケーションの有効期間中にセキュリティ侵害につながる主要なセキュリティの弱点を見逃す可能性があります。

結果として、すべてのロール (ユーザー、開発者、製品ライン マネージャー、テスト担当者など) に対してセキュリティ トレーニングを実装することが不可欠です。 各ロールには、セキュリティ リスクに関する教育と、アプリケーションの安全を維持する役割が必要です。 このトレーニングの形式が取るのは、正式またはオンデマンドのトレーニング、シミュレーション演習、脅威モデリング、メンタリング/アドバイザー、セキュリティ チャンピオン、アプリケーション セキュリティ サポート チーム、紫色のチーム アクティビティ、ポッドキャスト、ビデオ、またはその他の学習方法です。

最終的に、各ロールは次の内容を理解する必要があります:

  • セキュリティ リスクに対処することが重要な理由
  • 自分の役割におけるセキュリティのために必要な操作
  • セキュリティを自分の日常の役割の一部にする方法

攻撃者の視点、目標、およびそれが実際のセキュリティ インシデントにどのように現れるかを理解しているユーザーは、セキュリティを回避するのではなく、すぐさまセキュリティの味方になります。

セキュリティとは、脅威、テクノロジー、保護すべきビジネス資産が常に変化し、脅威アクターが決してあきらめることのない、終わりのないゲームです。 セキュリティ トレーニングのアプローチは進行中かつ継続的に進化している必要があります。 効果的なトレーニングは、セキュリティ ポリシー、ソフトウェア開発ライフサイクル (SDL) プラクティス、標準、およびソフトウェア セキュリティ要件と協調して、強化します。 トレーニング資料は、データから導かれた分析情報と、新しく利用可能な技術的な機能を基にしている必要があります。

セキュリティは全員が取り組む仕事ですが、全員がセキュリティのエキスパートになったり、熟練した侵入テスト要員になったりする必要はないということに注意することが重要です。 全員がセキュリティの基本を理解し、ソフトウェアとサービスにセキュリティを組み込む際の自身の役割にその基本を適用する方法を確認することが不可欠です。 このトレーニングには、ワークステーション、アプリケーション、ID、アカウントの安全な使用を含める必要があります。

特に、システムを構築する開発者やエンジニアは、通常、セキュリティの専門家ではありません。 脅威モデリングの技術的側面と概念的側面を効果的にするには、その両方のトレーニングが必要で、このように、セキュリティで保護されたシステムを設計によって構築できるようになります。 このトレーニングは、開発者がセキュリティ専門家よりはるかに多い組織で、脅威モデリングのプロセスが大規模に機能するために不可欠です。 脅威モデリングは、すべての開発者とエンジニアが少なくとも基本技能として持っている必要がある基本的なエンジニアリング スキルと考える必要があります。 そのため、開発チームとエンジニアリング チームは、オンボーディングの一環として、また定期的な再訓練講座を使用して脅威モデリングに対応できるようにトレーニングする必要があります。

非難のない事後分析にセキュリティを含めます

非難のない事後分析とは、チームにとって、責任を負わされることでチームメンバーが守りに入ってしまうことなく、効果的かつ効率的に間違いから学びを得るための非常に重要な方法です。 セキュリティ学習は、チームがセキュリティ学習も最大化できるように、非難のない事後分析プロセスに明示的に含める必要があります。

セキュリティ標準、メトリック、ガバナンスを確立します

組織は、これらのセキュリティ標準、メトリック、ガバナンスを確立する必要があります。これらがイノベーションの能力を支えているからです。 これにより、組織の資産を保護するだけでなく、事業目標に合わせた強力なセキュリティ プログラムが可能になります。 セキュリティ標準は、組織のシステム、データ、プロセスを安全に保つためのベースライン要件とベスト プラクティスです。

これらの標準は、コンプライアンスの監視や、現在の脅威、ツール、およびその他の要因について定期的に確認および更新することを含めて、測定および管理する必要があります。 このプロセスでは、初期の観念からアプリケーションの使用停止までのライフサイクル全体、およびサポートする開発環境をカバーする必要があります。

メトリックは、セキュリティ制御とプロセスの効果を確認するために使用される測定値です。 重要なメトリックの 1 つは、アプリケーションが脆弱である期間を追跡するための平均修復時間 (MTTR) です。 この測定により、セキュリティ修正プログラムの発行に戦略的かつより迅速に投資することができます。

Note

この概念は、組織の資産への敵対者によるアクセスを排除するまでの時間に重点を置いたセキュリティ オペレーションにおける MTTR とは異なります。

セキュリティ ガバナンスはセキュリティ チームの指針として機能し、多くの場合、組織が情報セキュリティの管理と制御に使用するフレームワークとプロセスに基づいて構築されます。 これには、ポリシー、処置、コントロール、およびリスク管理が含まれます。 メトリックは、リスクの露出を数値化するのに役立ちます。 それらがなければ、組織は脆弱性と潜在的な影響を十分に理解していない可能性があります。

セキュリティ要件がこれまでなかった可能性があるため、コーディング標準を理想的な状態に徐々に常用させる段階的なアプローチを取る機会があります。 このアプローチにより、チームは監視とコントロールを学び、自動化する時間を得られます。

実証済みのセキュリティ機能、言語、フレームワークを使用する必要があります

承認済みツールの一覧と、それに関連付けられているセキュリティー チェックを定義して公開します。 セキュリティで保護されたソリューションの構築は非常に困難であるため、よく確立された実証済みのセキュリティ ソリューションを使用することは、一般的な間違いを避けるために重要です。 セキュリティ ソリューションを新たに考案しようとすると、ほとんどの場合、セキュリティ リスクが高まり、時間と労力が無駄になってしまいます。

開発者とエンジニアが新しいセキュリティ分析機能と保護を利用していることを確認します。 セキュリティで保護された実行可能ファイルを生成するには、常に最新のコンパイラ、リンカー、ライブラリ、および適切なコンパイラおよびリンカー フラグを使用する必要があります。

組織は、統合コンポーネントのセキュリティを検証するためのレビューと承認プロセスを実装する必要があります。 適用され、監視されるビルドおよびデプロイ プロセスで承認されたコンポーネントのみを使用するポリシーを確立する必要があります。

基本的な ID セキュリティ

ID の使用と統合が、確立されたセキュリティのベスト プラクティスに従っていることを確認します。 脅威アクターは、運用システムと開発プロセスの両方に対して ID 攻撃手法を頻繁に使用します。 一般的に言われているのは、これを「攻撃者は侵入しているのではなく、ログインしているだけだ」と捉えています。

ID セキュリティは、開発のために次の 2 通りの形式を使用します。

  • 開発プロセスの ID セキュリティ - 開発プロセスのすべての参加者が、日々の作業に対して強力な認証方法を使用し、ジョブ タスクを実行するために必要な特権のみを持っていることを確認します。 詳細については、「ID/アプリケーションの Access Control」セクション を参照してください。
  • システムとアプリケーションの ID セキュリティ - 設計および構築しているシステムが、認証および承認方法のベスト プラクティスに従っていることを確認します (また、実証済みで維持されている ID システムを模倣した脆弱なシステムを独自に構築していないことを確認します)。

次のリソースのガイダンスに従って、システムとアプリケーションに ID セキュリティを適用します:

暗号化標準

暗号のすべての使用に健全な暗号化プラクティスを適用します。 「継続的 SDL プラクティス 4 – 暗号化標準の定義と使用」に記載されているすべてのガイドラインに従ってください。

詳細については、「Microsoft SDL 暗号化の推奨事項」を参照してください。

開発環境のセキュリティ保護

このコントロールは、継続的 SDL プラクティス 6 – エンジニアリング環境のセキュリティ保護をサポートします。

このコントロールは、セキュリティで保護されたワークステーションと統合開発環境 (IDE) を使用して開発環境をセキュリティで保護することに重点を置いています。 このコントロールは、ソフトウェア開発ライフサイクルでゼロ トラスト アプローチを使用する利点を強調しています。

現在の状況では、攻撃者は自分の操作を拡張して開発者のマシンをターゲットにし、ビルド プロセスを改ざんします。 この攻撃の極めて重要な例に、SolarWinds が経験した攻撃があります。その攻撃者は、ソフトウェア ビルドの最終段階の前に悪意のある DLL を挿入しました。 実質的に、これはアプリケーションをバックドアし、サプライ チェーンを介して世界中の何千もの顧客に拡散された標的型攻撃を引き起しました。 SolarWinds 攻撃の詳細については、「Solorigate の分析、複雑なサイバー攻撃を始めた侵害された DLL ファイル、および Microsoft Defender がお客様の保護にどのように役立つか」に関する Microsoft ブログを参照してください。

開発されたアプリケーションの整合性を確保するために、ワークステーション、ビルド環境、ID、およびその他の開発システムを強化することが不可欠です。 そうしないと、ソース コード管理 (SCM) システムまたは開発者ワークステーションを介して攻撃者がアプリケーションを侵害する経路が作成されます。

このプラクティスは、開発ライフサイクルの重要な基盤であり、すべてのプロファイルに対して確立される必要があります。

このプラクティス全体を通じて、ゼロ トラスト アプローチを取る必要があります。 根本的に、ゼロ トラスト モデル は、要求の送信元やアクセスするリソースに関係なく、信頼されていないネットワークから送信されたかのように各アクセス要求 (ユーザー、サービス、またはデバイス) を検証する必要があります。 利用可能なすべてのデータポイントのこの「常に認証および承認」ポリシーを基準にします。 Just-In-Time ポリシーと Just-Enough-Access (JIT/JEA) ポリシーを使用してユーザー アクセス (特に特権のあるユーザー) を制限し、違反がある場合に生じる可能性のある損害を最小限に抑えるために、アクセスをセグメント化する必要があります。

開発環境の強化はさまざまな方法で実現できますが、まずは開発者ワークステーションを検討することをお勧めします。 GitHub Codespaces や Microsoft DevBox などのテクノロジを利用することで、開発環境を SaaS アプリケ―ションに移行し、セキュリティとネットワークの設定または組織方針を使用して管理できます。

開発者ワークステーションをさらにロックダウンするには、特権アクセス ワークステーション/セキュリティで保護されたアクセス ワークステーション (PAW/SAW) を発行します。 これらのワークステーションは、脅威ベクトルを減らし、標準化および制御された開発者デバイスを確保するのに役立ちます。

安全な設計

脅威モデリングの実行 (セキュリティ設計レビュー)

このコントロールは、継続的な SDL プラクティス 3 – 脅威モデリングの実行をサポートします。

このコントロールは、セキュリティ インシデントやビジネス上の損害を引き起こす可能性がある設計のセキュリティ上の弱点を特定します。 設計のセキュリティ上の弱点は、設計の実装後では軽減するのが難しい場合があるため、ライフサイクルの初期にこれらの弱点を見つけて修正することが非常に重要です。

脅威モデリングは、セキュリティ設計レビュー プロセスとして機能し、セキュリティをシステムまたはアプリケーションの設計に統合します。

脅威モデリングは、ソフトウェア システム内のセキュリティ リスクを体系的に識別、評価、優先度付け、軽減します。 ソフトウェア アプリケーションの設計とアーキテクチャを分析するためのこの構造化されたアプローチにより、開発プロセスの早い段階で潜在的な脅威と脆弱性を特定します。

最終的な目標は、システムを理解し、何が問題になる可能性があるかを把握することです。 脅威モデリングは、システム自体と潜在的な攻撃者の見方の両方を深く理解することで、その目標を達成するのに役立ちます。

通常、このプロセスは脅威検出ワークショップの形式で行われます。このワークショップでは、システムとセキュリティの専門家に関する専門家のチームが連携してリスクを検出して文書化します。 このプロセスは非公式に開始される可能性がありますが、構築されるサービスの各側面、使用方法、システム インターフェイスについて検討する構造化されたプロセスにすばやく進化する必要があります。

脅威モデリングの段階は次のとおりです:

  1. ユース ケース、シナリオ、資産を特定する – まず、あらゆるシステム侵害の潜在的なビジネスへの影響を評価し、従う必要があるディスカッションを通知するのに役立てるためにシステムが有効化するビジネス機能とユース ケースについて理解します。
  2. アーキテクチャの概要を作成する – アプリケーションの視覚的な概要を作成 (または既存のものを使用) して、システムとそのしくみを明確に理解します。 この概要には、ビジネス プロセス マップ、コンポーネントとサブシステム、信頼境界、認証および承認メカニズム、外部インターフェイスと内部インターフェイス、アクターとコンポーネント間のデータ フローが含まれている必要があります。
  3. 脅威を特定する - STRIDE モデル や OWASP 脅威モデリング などの潜在的なセキュリティ脅威を列挙するための一般的な手法を使用します。
  4. 軽減策を特定し追跡する - 既存の開発プロセスとツールを使用して、検出された設計上の欠陥を監視および追跡し、修正策が実装および文書化されていることを確認します。 このプロセスでは、チームが最初に最重要の作業に時間を費やすことができるように、第一に実行すべき軽減策を優先する必要があります。 このプロセスはリスクに基づいて進められるものなので、最初のサイクルですべてのリスクを完全に軽減するためのリソースがない可能性があります。 防御コストとリソースを最小限に抑え、攻撃者のコストを上げる軽減策 (部分的な軽減策を含む) を慎重に検討します。 セキュリティの目的は攻撃者を失敗させることです。これは、攻撃手法を完全にブロックし、防御者が対応できるようにその手法を検出し、攻撃を遅延させて防御者が応答する時間を稼ぎ、損害の範囲を制限することなどの形式で行うことができます。

脅威モデルは、多くの場合、すべての関連ユーザーの教育プロセスとして機能し、他のセキュリティ計画、実装、テストに重要なコンテキストを提供します。

人工知能 (AI) コンポーネントの使用を含むアプリケーションでは、従来のアプリケーションとは異なる、AI に関連付けられた特定のリスクの種類を評価する必要があります。

脅威モデルを作成して分析するには、システムのセキュリティ設計について伝達し、実証済みの手法を使用して潜在的なセキュリティ問題の設計を分析し、セキュリティ問題の軽減策を提案および管理します。

セキュリティで保護されたコード

コード分析

このコントロールは、継続的 SDL プラクティス 7 – セキュリティ テストの実行をサポートします。

このコントロールは、開発者がコードを統合開発環境 (IDE) に書き込み/入力したり、コードを登録したりする際に、コードのセキュリティを強化することに重点を置いています。 このコントロールは、攻撃者がたびたび悪用する脆弱性に直接対処する DevSecOps プラクティスの基礎となります。

このコントロールがないと、開発者によってアプリケーションに直接コード化された脆弱性が見つからない可能性があります。 開発者は悪意を持っていませんが、コード化された内容が安全でない理由を特定するために必要なスキルが不足している可能性があります。

このコントロールは、ツールを IDE に直接統合することで、左シフト アプローチの生産性とセキュリティの利点を得るための鍵となります。 このプロセスにより、最も早く最もコスト効率の高い状況で脆弱性を迅速に検出して修復できます。 このプロセスは、セキュリティ上の弱点を特定し、後で修正することで 、既に開発されたアプリケーションにさかのぼって適用できます (ただし、費用と難易度が高くなります)。

このプロセスは、通常、静的分析セキュリティ テスト (SAST) ツールセットと動的分析セキュリティ テスト (DAST) ツールセットを使用してコードをスキャンする IDE プラグインまたは専用のスキャン ツールの形式になります。

SAST ツールは、既存のコードベースをスキャンし、コードへのフル アクセス権を持ちます。 SAST ツールは、コード自体の主要な弱点を特定できます。 一方、DAST はデプロイされたアプリケーションで実行されます。 その結果、コードにアクセスすることなく、実行時のセキュリティの弱点をシミュレートして特定するために実行されます。

Note

AI アプリケーションには、従来のアプリケーションとは異なる種類の脆弱性 (バイアスや幻覚など) があり、それらのアプリケーションに焦点を当てるツールが必要です。

品質制御が重要! これらのツールを実行する際の重要な考慮事項は、誤検知によるノイズと無駄な労力を減らすために調整することです。 これらのツールを調整するには、通常、組織の開発プロセスを理解している開発者経験を持つセキュリティ プロフェッショナルが必要です。 同じ専門家が、個々の検出に関するトリアージ ガイダンスと専門知識を開発者向けに提供することもできます。 真陽性と偽陽性、実際の問題と誤ったアラームを区別するのに役立ちます。 開発者がこれらのエキスパートにアクセスするためのプロセスは、多くの場合、チャンピオン プログラム、アプリケーション セキュリティ サポート チームなどの セキュリティ トレーニングの提供 に密接に関連しています。

一時的な最小値 – ビルトイン IDE セキュリティ機能を有効にし、リポジトリ全体で最小レベルの SAST スキャンを実装して、アプリケーション全体の脆弱性を特定します。 検出された問題を適切な時間内に修復するための文書化されたプロセスが必要ですが、どの欠陥を修正する必要があるかに関する "バグ バー" 標準は、アプリケーションが標準のバランスの取れたプロファイルまたは高いセキュリティ プロファイルに達するまで制限されます。

Standard - 該当するすべての SAST/DAST ツールを使用してすべてのコンポーネントを完全にスキャンし、弱点を特定します。 アプリケーション コードに対する完全なセキュリティ カバレッジを確保します。 文書化された修復プロセスに従っており、組織のリスク許容度と一致する "バグ バー" 標準があることを確認します。

高セキュリティ – 適用されるすべてのアプリケーションで、すべてのセキュリティの脆弱性に対処する詳細で文書化されたプロセスが適用されていることを確認します。 ビルドまたはリリース アクティビティの前に修正プログラムを適用します。 文書化された修復プロセスに従っていることを確認し、組織の高いセキュリティ ビジネス クリティカルなワークロードに対するリスク許容度に一致する、非常に制限の厳しい "バグ バー" があることを確認します。

静的分析に使用できるツールは多数あります。 詳細については、「Microsoft セキュリティ開発ライフサイクル」の一覧を参照してください。

CI/CD パイプラインをセキュリティ保護します

サプライ チェーン/依存関係管理

このコントロールは、継続的 SDL プラクティス 5 - ソフトウェア サプライ チェーンのセキュリティ保護をサポートします。

このコントロールでは、ソフトウェア コンポジション分析 (SCA) ツールやセキュア サプライ チェーン消費フレームワーク (S2C2F) などのフレームワークを使用して、開発サプライ チェーンをセキュリティで保護することに重点を置いています。 これらのプロセスは、Microsoft 以外のコードによる侵害のリスクを軽減するのに役立ちます。

今日の状況では、ほとんどのアプリケーションは、これらのコンポーネントのコンシューマーからの監視や制御がほとんどないオープンソースソフトウェア (OSS) に依存しています。 このコントロールでは、OSS を安全に取り込み、消費、使用、およびメンテナンスするための主要な戦略、手法、テクノロジーが強調されています。 また、内部依存関係のセキュリティ保護にも重点を置き、どのユーザーがソフトウェアをコーディングしたかに関係なく、完全なエンド ツー エンドのライフサイクルを確保します。

ソフトウェア サプライ チェーンを制御できないと、制御されていないコードによって発生した重大な脆弱性が発生します。 悪評の高い例は log4J/Log4Shell の脆弱性であり、このパッケージを使用した任意のシステムまたはアプリケーションで、リモートでコードを実行できてしまいます。 このような脆弱性は、誤ってまたは悪意を持って発生する可能性があります。

サプライ チェーンのセキュリティ保護は、セキュリティで保護された開発ライフサイクルを確保するうえで不可欠な部分であり、すべてのプロファイル状態で考慮する必要がありますが、あらゆる状態は、依存関係を取り込む同じ標準化されたプロセスに従う必要があります。

一時的な最小値 – OSS の脆弱性がアプリケーションに与える影響を理解できるように、すべての依存関係をインベントリします。 このインベントリは、Dependabot または他のソフトウェアコンポジション分析 (SCA) ツールを使用して作成できます。 これらのツールは、ソフトウェア部品表 (SBOM) の生成にも役立ちます。

Standard - すべての OSS の脆弱性を分析し、自動 pull request で自動的に修正します。 このコントロールは、Dependabot と GitHub 依存グラフ/レビューを使用して実現することもできます。

高セキュリティ - アプリケーションで使用されている悪用可能な脆弱性を持つ安全でないパッケージをすべてアクティブにブロックします。

このコントロールの詳細を確認し、OSS セキュリティの成熟度を測定するには、「OSS サプライ チェーン フレームワーク」と、「開発ライフサイクルのセキュリティ保護に関する GitHub のベスト プラクティス ドキュメント」を確認してください。

セキュリティ コード レビュー

このコントロールは、潜在的なセキュリティ上の欠陥を特定するために、セキュリティ専門家によるコードのレビューに重点を置いています。 これは、検出を自動化するのが困難なセキュリティの問題を見つけるのに役立ちます。

このレビューは、アプリケーション セキュリティの専門知識を持つ同じチームのピア、組織内のセキュリティ チャンピオン、中央アプリ セキュリティ チームのアプリケーション セキュリティ専門家、または外部パーティによって実行できます。

このレビューは常に、コードを記述した開発者とは別のユーザーが行う必要があります。 このレビューは、自動コード分析が完了した後に、別のアクティビティとして行う必要があります。

一時的な最小値 – このコントロールには、このプロファイルをお勧めします。

Standard - このコントロールには、このプロファイルをお勧めします。

高セキュリティ – このコントロールは、すべての高セキュリティ アプリケーションに必要であり、多くの場合、複数の専門家が関与します。

資格証明とシークレットのスキャン

このコントロールは、継続的 SDL プラクティス 7 – セキュリティ テストの実行をサポートします。

このコントロールは、認証キーやその他のシークレットがコードで公開されていることによるリスクを軽減することに重点を置いています。 脅威アクターには、コード内の埋め込みシークレットを見つけて悪用するための専門知識があり、自動化しています。

最善の方法は、可能であればキーとシークレットの代わりにマネージド ID と先進認証プロトコルを使用することです。 API キーとシークレットの使用は従来、コーディングとテストの手法ですが、セキュリティとライフサイクルの管理機能が向上するため、推奨される方法は常にリソースに対する ID ベースの認証である必要があります。 このコントロールの実装は、Azure リソース用マネージド ID などのマネージド ID を使用する形式になります。

シークレットの使用が必要な場合は、作成、使用、定期的なローテーション、失効など、ライフサイクル全体を通じてシークレットをセキュリティで保護する必要があります。 コードでシークレットを直接使用しないようにし、必要に応じて、Azure Key Vault やハードウェア セキュリティ モジュール (HSM) などのセキュリティで保護されたキー/シークレット ストレージ システムにのみ格納します。 いかなる状況でも、たとえ一時的であっても、プレーンテキストキーとシークレットをコードに格納するべきではありません！ 攻撃者はこれらのシークレットを見つけて悪用します。

重要

内部ソース コード リポジトリは安全ではありません!

内部リポジトリは、脅威アクターがフィッシングやその他の方法で環境にアクセス権を取得すると、リポジトリ内のシークレットとキーを頻繁に検索するため、公開されているリポジトリと同じ要件を受ける必要があります。 これは、侵害を想定し、それに応じてセキュリティ制御を設計するゼロ トラスト アプローチに必要です。

Standard - 適切なシークレットの検疫が不可欠であり、すべてのプロファイルで必要です。

Note

これらのシークレットはチームまたは攻撃者によって検出されるため、マネージド ID などのより安全なアクセス方法にメカニズムを変更するだけでなく、鍵を使用してリソースにアクセスできないようにする必要があります (リソースの種類によって異なります)。

詳細とリソースは次のとおりです:

Note

Azure Key Vault などのシークレット ストレージ ソリューションでワークロードごとに鍵を使用することを強くお勧めします。

安全なパイプライン

このコントロールは、継続的 SDL プラクティス 5 - ソフトウェア サプライ チェーンのセキュリティ保護をサポートします。

このコントロールは、DevOps パイプラインと、アプリケーションのビルド プロセス中に作成されたすべての成果物をセキュリティで保護することに重点を置いています。

パイプラインは、DevSecOps ライフサイクル内の主要な反復可能なアクティビティを自動化する上で不可欠な部分です。 CI/CD では、チームが開発者のコードを中央のコードベースと定期的に統合し、セキュリティ ツールセットを含む標準のビルドとテストのプロセスを自動的に実行します。

パイプラインを使用してスクリプトを実行したり、コードを運用環境にデプロイしたりすることにより、独特なセキュリティの課題が生じる恐れがあります。 CI/CD パイプラインが、悪意のあるコードの実行や認証情報の盗難のための手段になったり、攻撃者が外部からアクセスするための入口になったりしないようにします。 また、確実にチームが意図したコードだけがリリースされ、デプロイされるようにする必要があります。 このプロセスには、CI/CD パイプラインの成果物、特に攻撃の一部として使用できるさまざまなタスク間で共有される成果物が含まれます。

ソフトウェア部品表 (SBOM) の生成をビルド プロセスに自動化して、開発者の手動操作を必要とすることなく、この非常に重要なコード実証成果物を作成する必要があります。

パイプラインで使用されるリソースへの適切なアクセス制御を確保し、コア依存関係/スクリプトを定期的に検証/更新することで、パイプラインのセキュリティを確保できます。 CI/CD パイプラインで使用されるスクリプトもコードであり、プロジェクト内の他のコードを扱うのと同じ方法で扱う必要があることに注意してください。

Note

パイプラインのセキュリティは、基になるインフラストラクチャのセキュリティと、プロセスに使用されるアカウント/ID によって異なります。 詳細については、開発環境のセキュリティ保護とセキュリティで保護された操作制御 (ID/アプリ のアクセス制御、ホスト/コンテナー制御、ネットワーク アクセス制御) を参照してください

Standard - このコントロールは、プロジェクト内のすべてのリソースへのアクセス レベルで評価する必要があります。これは、すべての DevSecOps プロファイル レベルで必要なコントロールです。

パイプラインのセキュリティの詳細については、「Azure Pipelines のセキュリティ保護」を参照してください。

安全なオペレーション

ライブ サイト侵入テスト

このコントロールは、継続的 SDL プラクティス 7 – セキュリティ テストの実行をサポートします。

プロのアプリケーション侵入テスト担当者が、完全なワークロードのライブ インスタンスを侵害しようと試みます。 このテストでは、ワークロードのセキュリティ制御が効果的で一貫性があることを検証します。 侵入テストは、攻撃者がアプリケーションを悪用し、ビジネスを侵害するために使用できる最も抵抗力の少ないパスを見つけて強調するのに役立ちます。 侵入テストは、適切なタイミングで行われると非常に価値があります。 以前のスキャンで見つかった低コストで簡単に悪用できる脆弱性を軽減したら、それらを使用します。

DevSecOps セキュリティ プロファイルのすべてのレベルでこのテストを行うことをお勧めします。

一時的な最小値 – すべてのアプリケーションで侵入テストを行うことをお勧めします。 時間的な制約により、攻撃者が悪用する可能性があるアプリケーション内のより簡単な方法しか特定できない場合があります。 これを少なくとも標準レベルまで迅速に引き上げる計画を立ててください。

Standard - 標準プロファイルでは、侵入テストを行うことをお勧めします。 この場合、開発プロセスの早い段階で特に注意が払われるため、より複雑な脆弱性が発見される可能性があります。

高セキュリティ – 基幹業務アプリケーションと重要なワークロードの場合、侵入テストを完了することが要件です。 これらのアプリケーションの脆弱性は、特に注意を払って慎重に扱う必要があります。

これらのアクティビティの結果とフィードバックを統合して、セキュリティ プロセスとツールを改善します。

ID/アプリケーションのアクセス制御

このコントロールは、継続的な SDL プラクティス 8 - 運用プラットフォームのセキュリティとプラクティス 6 の確保- エンジニアリング環境のセキュリティ保護をサポートします。

開発環境、CI/CD パイプライン、運用ワークロード、およびその他の開発システムのすべての技術的要素について、特権アクセスのセキュリティ保護 を含む ID およびアクセス管理のセキュリティのベスト プラクティスに従っていることを確認します。 脅威アクターには、運用システムと開発プロセスの両方に対して頻繁に使用される ID 攻撃の複雑な方法があり、自動化しています。 ID およびアクセス管理は、Microsoft が推奨するゼロ トラスト モデルの基本的な柱です。

すべての開発システムと、それらをホストしているインフラストラクチャ (VM、コンテナー、ネットワーク デバイスなど) について、セキュリティのベスト プラクティスに従っていることを確認します。

一時的な最小値 – すべてのユーザーが多要素認証を使用し、毎日のタスクを実行するために必要なシステムにのみアクセスできるようにします。

Standard - ワークロードをホストするインフラストラクチャ コンポーネント (VM、コンテナー、ネットワーク、ID システムなど) が、特権アクセスのセキュリティ保護など、ID とアクセス管理のセキュリティのベスト プラクティスを満たしていることを確認します。

高セキュリティ – MFA、ID 脅威の検出と対応、クラウド インフラストラクチャエンタイトルメント管理 (CIEM) を組み込んだ完全なゼロ トラスト戦略を実装します。 各高セキュリティ ワークロードをサポートする ID システムとコンポーネントの ワークロード固有の脅威モデルを実行します。

マネージド ID は、可能な限り、より安全で推奨される認証方法です。 トークンとシークレットの使用は、アプリケーション層で格納および取得する必要があるため、安全性が低くなります。 さらに、マネージド ID は、手動による介入を必要とせずに自動的にロールオーバーされます。

詳細とリソースは次のとおりです:

ホスト/コンテナー/環境コントロール

このコントロールは、継続的な SDL プラクティス 8 - 運用プラットフォームのセキュリティとプラクティス 6 の確保- エンジニアリング環境のセキュリティ保護をサポートします。

開発ライフサイクルのすべての技術的要素に関するすべてのコンピューティング リソースとホスティング環境対して、セキュリティのベスト プラクティスに従っていることを確認します。 脅威アクターには、運用システムと開発プロセスの両方に対して頻繁に使用されるインフラストラクチャおよびユーザー エンドポイント攻撃に対する高度な方法があり、自動化しています。 インフラストラクチャ セキュリティは、Microsoft が推奨する ゼロ トラスト モデル の基本的な柱です。

このコントロールには、開発および運用ライフサイクルのすべての要素を含める必要があります。これには以下が含まれますが、これらに限定されません:

  • 一般的な IT/運用ワークステーションと環境
  • 専用の開発ワークステーションと環境
  • CI/CD パイプライン インフラストラクチャ
  • ワークロード ホスティング環境
  • その他の開発システム。

このコントロールには、どんなコードも実行できるリソースが含まれますが、これらに限定されません:

  • 仮想マシン (VM) ホストと VM
  • コンテナーとコンテナーインフラストラクチャ
  • アプリケーション、スクリプト、およびコード ホスティング プラットフォーム
  • クラウド サブスクリプション/アカウントと加入契約
  • 開発者、ユーザー、IT 管理 ワークステーション

セキュリティ更新プログラム (パッチ)、ベースライン セキュリティ構成など、インフラストラクチャ コンポーネントにセキュリティのベスト プラクティスを適用してください。

一時的な最小値 – ホストとサブスクリプションに標準のエンタープライズ構成を適用します。

Standard - Microsoft Cloud Security Benchmark (MCSB) で概説されているセキュリティのベスト プラクティスをインフラストラクチャが満たしていることを確認します。

高セキュリティ – MCSB 標準を厳格に適用し、各高セキュリティ ワークロードをサポートするインフラストラクチャの ワークロード固有の脅威モデルを実行します。

詳細とリソースは次のとおりです:

ネットワーク アクセス制御

このコントロールは、継続的な SDL プラクティス 8 - 運用プラットフォームのセキュリティとプラクティス 6 の確保- エンジニアリング環境のセキュリティ保護をサポートします。

開発環境、CI/CD パイプライン、運用ワークロード環境、およびその他の開発システムのすべての技術的要素について、ネットワーク アクセス管理のセキュリティのベスト プラクティスに従っていることを確認します。 脅威アクターには、運用システムと開発プロセスの両方に対して頻繁に使用される ID 攻撃の複雑な方法があり、自動化しています。 ネットワーク セキュリティは、Microsoft が推奨する ゼロ トラスト モデル の基本的な柱です。

ネットワーク セキュリティには、次のものが含まれている必要があります:

  • 外部ネットワーク保護 – 未承諾の外部/インターネット トラフィックからの分離と、既知の種類の攻撃の軽減。 この分離は、通常、インターネット ファイアウォール、Web Application Firewall (WAF)、API セキュリティ ソリューションの形式になります。
  • 内部ネットワーク保護 – (他の企業ネットワークの場所からの) 未承諾の内部トラフィックからの分離。 この分離では、外部ネットワーク保護と同様の制御が使用される場合があり、ワークロードや特定の個々のコンポーネントと IP アドレスに対してきめ細かく制御できます。
  • サービス拒否の軽減策 – 分散型サービス拒否 (DDoS) やその他のサービス拒否攻撃に対する保護。
  • Security Service Edge (SSE) – クライアント側のマイクロセグメント化を使用して、ゼロ トラスト ポリシーの適用など、リソースへの安全なアクセスを直接提供します。

すべての開発システムと、それらをホストしているインフラストラクチャ (VM、コンテナー、ネットワーク デバイスなど) について、セキュリティのベスト プラクティスに従っていることを確認します。

一時的な最小値 – ワークロードに標準のエンタープライズ構成を適用します。

Standard - すべてのシステムに外部ネットワーク保護、DDoS 保護、およびワークロードごとの最小限の内部ネットワーク保護を確保します。

高セキュリティ – すべての標準保護に加え、内部ネットワーク保護の高い粒度、外部ネットワーク保護メカニズムを介した送信サーバー トラフィックの強制トンネリング、各高セキュリティ ワークロードをサポートするネットワーク インフラストラクチャの ワークロード固有の脅威モデル。

詳細とリソースは次のとおりです:

監視、応答および回復

このコントロールは、継続的な SDL プラクティス 9 - セキュリティの監視と対応の実装をサポートします。

セキュリティ運用 (SecOps/SOC) チームが、ワークロード (API とアプリ) およびそれらをホストするインフラストラクチャの可視性、脅威検出、対応手順を確実に持っていることを確認します。 SecOps チームとインフラストラクチャ/ワークロード チーム間のチーム間のプロセスとツールによって、攻撃後の迅速な復旧が可能であることを確認します。

このコントロールは、ワークロードが運用環境に入り、組織でアクティブに実行されると、ワークロードのセキュリティを維持します。 このプロセスは、セキュリティ インシデントを検出して対応する既存の セキュリティ オペレーション 機能と統合する必要があります。

カスタム ワークロードのセキュリティ監視では、ログやその他のアプリケーション データを分析して潜在的なセキュリティの脅威を検出して調査することで、一般的なコンポーネントの拡張検出と対応 (XDR) ソリューションを組み合わせます。 カスタム アプリケーション データには、多くの場合、ユーザー要求、アプリケーション アクティビティ、エラー コード、ネットワーク トラフィック、アプリケーション、データベース、ネットワーク エンドポイント、およびその他のシステム コンポーネントからの関連するその他の詳細に関する情報が含まれます。

このデータは、リアルタイムの脅威インテリジェンスからの分析情報を使用して強化され、ネットワークに侵入しようとする可能性のある異常な動作パターンを特定します。 集約、関連付け、正規化されると、XDR およびセキュリティ情報イベント管理 (SIEM) プラットフォームは修復アクションを提供します。

一時的な最小値 – 環境内に XDR 機能をデプロイして、エンド ユーザー デバイスのトラフィックを監視します。

Standard - 環境全体に対する異常な動作を識別する XDR とカスタム SIEM 検出をデプロイします。 このプロファイルには、個々のワークロードのカスタム検出が含まれる場合があります。

高セキュリティ – 標準コントロールに加えて、ワークロードの脅威モデリングからの分析情報に基づくカスタムワークロードごとの検出。 このプロファイルを AI と組み合わせて、修復に関する推奨事項にコンテキスト認識を提供します。

次のステップ

これらのセキュリティ コントロールを採用し、組織のリスク許容度と生産性要件に合わせて調整します。 理想的な状態に向けて継続的に構築する持続的な改善アプローチを使用する必要があります。

コントロールと最小限の理想的なターゲット レベルに優先度を付けることから始めます。 最初に、セキュリティへプラスの影響があり、摩擦が少ない変更があることを確認します。 最初のコントロールに優先度を付け、実装し、統合してから、このプロセスを次のコントロールで繰り返します。

最初に広範で肯定的な影響があるため、重要な基盤 を優先し、次に、影響が大きく、攻撃者が頻繁に使用する 資格情報とシークレット スキャン を優先する必要があります。