セキュリティ テストに関する推奨事項
この Azure Well-Architected Framework セキュリティ チェックリストの推奨事項に適用されます。
| SE:11 | セキュリティの問題を防ぎ、脅威防止の実装を検証し、脅威検出メカニズムをテストするアプローチを組み合わせた包括的なテスト計画を確立します。 |
|---|
厳格なテストは、優れたセキュリティ設計の基礎です。 テストは、コントロールが意図したとおりに動作することを確認するための戦術的な検証形式です。 テストは、システムの脆弱性を事前に検出する方法でもあります。
複数の観点から、周期と検証を通じてテストの厳しさを確立します。 プラットフォームとインフラストラクチャをテストするインサイドアウトの視点と、外部の攻撃者のようにシステムをテストする外部の評価を含める必要があります。
このガイドでは、ワークロードのセキュリティ体制をテストするための推奨事項を示します。 これらのテスト方法を実装して、攻撃に対するワークロードの耐性を向上させ、リソースの機密性、整合性、可用性を維持します。
定義
| 期間 | 定義 |
|---|---|
| アプリケーション セキュリティ テスト (AST) | ホワイトボックスとブラックボックスのテスト手法を使用して、コードのセキュリティの脆弱性をチェックする Microsoft セキュリティ開発ライフサイクル (SDL) 手法。 |
| ブラックボックス テスト | システムの内部を知らなくても、外部から見えるアプリケーションの動作を検証するテスト手法。 |
| ブルー チーム | 戦争ゲームの演習で赤いチームの攻撃から防御するチーム。 |
| 侵入テスト | 倫理的なハッキング手法を使用してシステムのセキュリティ防御を検証するテスト手法。 |
| 赤いチーム | 敵対者の役割を果たし、戦争ゲームの演習でシステムをハッキングしようとするチーム。 |
| セキュリティ開発ライフサイクル (SDL) | セキュリティの保証とコンプライアンスの要件をサポートする Microsoft によって提供される一連のプラクティス。 |
| ソフトウェア開発ライフサイクル (SDLC) | ソフトウェア システムを開発するためのマルチステージで体系的なプロセス。 |
| ホワイトボックス テスト | コードの構造が実践者に知られているテスト手法。 |
主要な設計戦略
テストは、特にセキュリティに関して、ネゴシエーション不可能な戦略です。 これにより、セキュリティの問題を悪用する前に事前に検出して対処し、実装したセキュリティ制御が設計どおりに機能していることを確認できます。
テストのスコープには、アプリケーション、インフラストラクチャ、自動化されたプロセスと人間のプロセスが含まれている必要があります。
注意
このガイダンスでは、テストとインシデント対応を区別します。 テストは、運用環境の前に問題を修正するのが理想的な検出メカニズムですが、インシデント対応の一環として行われる修復や調査と混同しないでください。 セキュリティ インシデントからの復旧の側面については、「 インシデント対応の推奨事項」を参照してください。
SDL には、コードの脆弱性をキャッチし、ランタイム コンポーネントを検証し、倫理的なハッキングを使用してシステムのセキュリティ回復性をテストする、いくつかの種類のテストが含まれています。 SDL は、キーシフト左アクティビティです。 開発プロセスの早い段階で、静的コード分析やコードとしてのインフラストラクチャの自動スキャン (IaC) などのテストを実行する必要があります。
テスト計画に関与する。 ワークロード チームは、テスト ケースを設計しない可能性があります。 多くの場合、このタスクは企業で一元化されるか、外部のセキュリティ専門家によって完了されます。 セキュリティ保証がアプリケーションの機能と確実に統合されるように、ワークロード チームはその設計プロセスに関与する必要があります。
攻撃者のように考えてください。 システムが攻撃されたことを前提として、テスト ケースを設計します。 これにより、潜在的な脆弱性を明らかにし、それに応じてテストに優先順位を付けることができます。
反復可能なプロセスを使用して、構造化された方法でテストを実行します。 周期、テストの種類、要因、意図した結果に関するテストの厳しさを構築します。
ジョブに適したツールを使用します。 ワークロードを操作するように構成されているツールを使用します。 ツールがない場合は、ツールを購入します。 ビルドしないでください。 セキュリティ ツールは高度に特殊化されており、独自のツールを構築するとリスクが発生する可能性があります。 中央 SecOps チームによって提供される専門知識とツールを利用するか、ワークロード チームがその専門知識を持っていない場合は外部手段で利用します。
個別の環境を設定します。 テストは、破壊的または非破壊的として分類できます。 非破壊的なテストは侵襲的ではない。 問題があることを示しますが、問題を修復するために機能は変更されません。 破壊的なテストは侵入性が高く、データベースからデータを削除することで機能が損なわれる可能性があります。
運用環境でテストすると、最適な情報が得られますが、中断が最も多く発生します。 運用環境では非破壊的なテストのみを実行する傾向があります。 非運用環境でのテストは通常、中断が少なくなりますが、セキュリティにとって重要な方法で運用環境の構成を正確に表さない場合があります。
IaC と自動化を使用してデプロイする場合は、テスト用に運用環境の分離クローンを作成できるかどうかを検討してください。 ルーチン テストの継続的なプロセスがある場合は、専用環境を使用することをお勧めします。
常にテスト結果を評価します。 結果を使用してアクションに優先順位を付け、アップストリームで改善を行わない場合、テストは無駄な作業です。 明らかにするセキュリティ ガイドライン (ベスト プラクティスを含む) を文書化します。 結果と修復計画をキャプチャするドキュメントでは、攻撃者がセキュリティを侵害しようとするさまざまな方法についてチームを教育します。 開発者、管理者、テスト担当者向けの定期的なセキュリティ トレーニングを実施します。
テスト計画を設計するときは、次の質問について考えてください。
テストの実行頻度と環境への影響
実行する必要があるさまざまなテストの種類は何ですか?
テストの実行頻度はどれくらいですか?
ワークロードを定期的にテストして、変更によってセキュリティ リスクが発生せず、回帰がないことを確認します。 また、チームは、いつでも実行できる組織のセキュリティ検証に対応する準備ができている必要があります。 セキュリティ インシデントに対応して実行できるテストもあります。 次のセクションでは、テストの頻度に関する推奨事項を示します。
ルーチン テスト
定期的なテストは、標準の運用手順の一部として定期的に実施され、コンプライアンス要件を満たします。 さまざまなテストは異なる頻度で実行される場合がありますが、重要なのは、定期的かつスケジュールに従って実行されることです。
これらのテストは、各段階で多層防御を提供するため、SDLC に統合する必要があります。 ID、データ ストレージと送信、および通信チャネルの保証を検証するために、テスト スイートを多様化します。 ライフサイクルのさまざまなポイントで同じテストを実行して、回帰がないことを確認します。 ルーチン テストは、初期ベンチマークの確立に役立ちます。 ただし、これは出発点にすぎません。 ライフサイクルの同じポイントで新しい問題を明らかにすると、新しいテスト ケースを追加します。 テストも繰り返しで改善されます。
これらのテストでは、各ステージで、追加または削除されたコード、または変更された構成設定を検証して、それらの変更のセキュリティへの影響を検出する必要があります。 ピア レビューとバランスを取って、自動化によってテストの有効性を向上させる必要があります。
自動パイプラインまたはスケジュールされたテスト実行の一部として、セキュリティ テストを実行することを検討してください。 セキュリティの問題が検出されるのが早ければ早いほど、原因となるコードまたは構成の変更を簡単に見つけることができます。
自動テストだけに依存しないでください。 手動テストを使用して、人間の専門知識だけがキャッチできる脆弱性を検出します。 手動テストは、探索的なユース ケースや不明なリスクの検出に適しています。
即興テスト
即興テストは、セキュリティ防御のポイントインタイム検証を提供します。 その時点でワークロードに影響を与える可能性があるセキュリティ アラートによって、これらのテストがトリガーされます。 組織の義務では、アラートが緊急事態にエスカレートした場合に、防御戦略の有効性を検証するために一時停止とテストの考え方が必要になる場合があります。
即興テストの利点は、実際のインシデントに対する準備です。 これらのテストは、ユーザー受け入れテスト (UAT) を実行するための強制関数である可能性があります。
セキュリティ チームは、すべてのワークロードを監査し、必要に応じてこれらのテストを実行する場合があります。 ワークロード所有者は、セキュリティ チームを促進し、共同作業を行う必要があります。 準備できるように、セキュリティ チームと十分なリード タイムを交渉します。 これらの中断が必要であることをチームと利害関係者に確認し、伝えます。
それ以外の場合は、テストを実行し、潜在的な脅威に対してシステムのセキュリティ状態を報告する必要があります。
トレードオフ: 即興テストは破壊的なイベントであるため、タスクのリプリタイズを期待します。これにより、他の計画作業が遅れる可能性があります。
リスク: 不明なリスクがあります。 即興テストは、プロセスやツールが確立されていない 1 回限りの作業である可能性があります。 しかし、主なリスクは、ビジネスのリズムの潜在的な中断です。 これらのリスクは、利点に関連して評価する必要があります。
セキュリティ インシデント テスト
ソースでセキュリティ インシデントの原因を検出するテストがあります。 インシデントが繰り返されないようにするには、これらのセキュリティ ギャップを解決する必要があります。
また、インシデントは、既存のギャップを明らかにすることで、時間の経過と同時にテスト ケースを改善します。 チームはインシデントから学んだ教訓を適用し、日常的に改善を組み込む必要があります。
さまざまな種類のテストは何ですか?
テストは、 テクノロジ と テスト手法によって分類できます。 これらのカテゴリ内でこれらのカテゴリとアプローチを組み合わせて、完全なカバレッジを取得します。
複数のテストと種類のテストを追加することで、次の情報を明らかにできます。
セキュリティ コントロールまたは補正コントロールのギャップ。
構成の誤り。
可観測性と検出方法のギャップ。
優れた脅威モデリングの演習では、テストカバレッジと頻度を確保するために重要な領域を指すことができます。 脅威モデリングに関する推奨事項については、「 開発ライフサイクルをセキュリティで保護するための推奨事項」を参照してください。
これらのセクションで説明するほとんどのテストは、ルーチン テストとして実行できます。 ただし、繰り返し性により、場合によってはコストが発生し、中断が発生する可能性があります。 これらのトレードオフを慎重に検討してください。
テクノロジ スタックを検証するテスト
テストの種類とそのフォーカス領域の例をいくつか次に示します。 この一覧はすべてを網羅したものではありません。 アプリケーション スタック、フロントエンド、バックエンド、API、データベース、外部統合など、スタック全体をテストします。
データ セキュリティ: データの暗号化とアクセス制御の有効性をテストして、データが不正なアクセスや改ざんから適切に保護されていることを確認します。
ネットワークと接続: ファイアウォールをテストして、ワークロードへの予想される、許可された、安全なトラフィックのみを許可するようにします。
アプリケーション: アプリケーション セキュリティ テスト (AST) 手法を使用してソース コードをテストし、セキュリティで保護されたコーディングプラクティスに従っていることを確認し、メモリの破損や特権の問題などのランタイム エラーをキャッチします。 詳細については、次の コミュニティ リンクを参照してください。
ID: ロールの割り当てと条件付きチェックが意図したとおりに機能するかどうかを評価します。
テスト方法
テスト手法には多くの観点があります。 実際の攻撃をシミュレートして脅威ハンティングを有効にするテストをお勧めします。 潜在的な脅威アクター、その手法、ワークロードに脅威をもたらす悪用を特定できます。 攻撃を可能な限り現実的にします。 脅威モデリング中に特定するすべての潜在的な脅威ベクトルを使用します。
実際の攻撃によるテストの利点を次に示します。
これらの攻撃を定期的なテストの一部にする場合は、外部からの視点を使用してワークロードをチェックし、防御が攻撃に耐えられるようにします。
彼らが学んだ教訓に基づいて、チームは知識とスキルレベルをアップグレードします。 チームは状況認識を向上させ、インシデントに対応するための準備状況を自己評価できます。
シミュレートされたテストの例としては、ブラックボックステストとホワイトボックステスト、侵入テスト、戦争ゲーム演習などがあります。
ブラックボックスおよびホワイトボックステスト
これらのテストの種類では、2 つの異なるパースペクティブが提供されます。 ブラックボックス テストでは、システムの内部は表示されません。 ホワイトボックス テストでは、テスト担当者はアプリケーションを十分に理解しており、コード、ログ、リソース トポロジ、および実験を実施するための構成にもアクセスできます。
侵入テストを通じて攻撃をシミュレートするテスト
organizationの IT チームやアプリケーション チームの一員ではないセキュリティ専門家は、侵入テストまたはペンテストを実施します。 悪意のあるアクターが攻撃対象範囲を指定する方法でシステムを確認します。 彼らの目標は、情報を収集し、脆弱性を分析し、結果を報告することによってセキュリティギャップを見つけることです。
専門家は、organization全体の機密データにアクセスする必要がある場合があります。 エンゲージメントの規則に従って、アクセスが誤用されないようにします。 関連リンクに記載されているリソースを参照してください。
戦争ゲームの演習を通じて攻撃をシミュレートするテスト
シミュレートされた攻撃のこの手法には、次の 2 つのチームがあります。
赤いチームは、現実世界の攻撃をモデル化しようとする敵対者です。 成功した場合は、セキュリティ設計のギャップを見つけ、侵害の爆発半径封じ込みを評価します。
ブルー チームは、攻撃から防御するワークロード チームです。 攻撃を検出、対応、修復する能力をテストします。 ワークロード リソースを保護するために実装された防御を検証します。
定期的なテストとして実施されている場合、戦争ゲームの演習では、防御が設計どおりに機能することを継続的に可視化し、保証することができます。 戦争ゲームの演習では、ワークロード内のレベル間でテストする可能性があります。
現実的な攻撃シナリオをシミュレートするための一般的な選択肢は、Microsoft Defender for Office 365攻撃シミュレーション トレーニングです。
詳細については、「攻撃シミュレーション トレーニングの分析情報とレポート」を参照してください。
red-team と blue-team のセットアップの詳細については、「 Microsoft Cloud Red Teaming」を参照してください。
Azure ファシリテーション
Microsoft Sentinel は、セキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション自動応答 (SOAR) 機能を組み合わせたネイティブ コントロールです。 接続されたさまざまなソースからのイベントとログが分析されます。 Microsoft Sentinel は、データ ソースとそのアラートに基づいてインシデントを作成し、脅威分析を実行して早期検出を行います。 インテリジェントな分析とクエリを使用すると、セキュリティの問題を事前に探すことができます。 インシデントがある場合は、ワークフローを自動化できます。 また、ブック テンプレートを使用すると、視覚化を通じてすばやく分析情報を得ることができます。
製品ドキュメントについては、「 Microsoft Sentinel のハンティング機能」を参照してください。
Microsoft Defender for Cloud では、さまざまなテクノロジ領域の脆弱性スキャンが提供されます。 詳細については、「Microsoft Defender 脆弱性の管理 - Microsoft Defender for Cloud を使用して脆弱性スキャンを有効にする」を参照してください。
DevSecOps のプラクティスは、継続的かつ継続的な改善マインドセットの一部としてセキュリティ テストを統合します。 戦争ゲームの演習は、Microsoft のビジネスのリズムに統合される一般的なプラクティスです。 詳細については、「 Security in DevOps (DevSecOps)」を参照してください。
Azure DevOps では、継続的インテグレーション/継続的デプロイ パイプラインの一部として自動化できるサードパーティ製ツールがサポートされています。 詳細については、「 Azure と GitHub - Azure DevOps で DevSecOps を有効にする」を参照してください。
関連リンク
エンゲージメントのルールに従って、アクセスが誤用されていないことを確認します。 シミュレートされた攻撃の計画と実行に関するガイダンスについては、次の記事を参照してください。
Azure でサービス拒否 (DoS) 攻撃をシミュレートできます。 必ず、 Azure DDoS Protection シミュレーション テストに示されているポリシーに従ってください。
コミュニティ リンク
アプリケーション セキュリティ テスト: ツール、種類、ベスト プラクティス - GitHub リソースでは、 アプリケーションのビルド時とランタイムの防御をテストできるテスト手法の種類について説明します。
侵入テスト実行標準 (PTES) で、一般的なシナリオと、ベースラインの確立に必要なアクティビティに関するガイドラインが提供されています。
OWASP トップテン |OWASP Foundation は、一般的な脅威をカバーするアプリケーションとテスト ケースのセキュリティのベスト プラクティスを提供します。
セキュリティ チェックリスト
推奨事項の完全なセットを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示