セキュリティ テストに関するレコメンデーション
この Power Platform Well-Architected Security チェックリストのレコメンデーションに適用されます。
| SE:09 | セキュリティ問題の防止、脅威防止の実装の検証、脅威検出メカニズムのテストのために、アプローチを組み合わせた包括的なテスト計画を確立します。 |
|---|
厳格なテストは、優れたセキュリティ設計の基礎となります。 テストは、コントロールが予定どおりに機能していることを確認するための戦術的な検証の形です。 テストは、システムの脆弱性を積極的に検出する方法でもあります。
複数の分析観点から頻度と検証を通じてテストの厳密さを確立します。 プラットフォームとインフラストラクチャをテストするインサイドアウトの視点と、外部の攻撃者のようにシステムをテストするアウトサイドインの評価を含める必要があります。
このガイドには、ワークロードのセキュリティ体制をテストするためのレコメンデーションが含まれています。 これらのテスト方法を実装すると、ワークロードの攻撃に対する耐性が向上し、リソースの機密性、整合性、可用性が維持されます。
定義
| 任期 | 定義 |
|---|---|
| アプリケーション セキュリティ テスト (AST) | ホワイトボックスおよびブラックボックスのテスト手法を使用して、コード内のセキュリティの脆弱性をチェックする Microsoft セキュリティ開発ライフサイクル (SDL) 手法。 |
| ブラックボックス テスト | テストの手法は、システムの内部を知ることなく、外部から見えるアプリケーションの動作を検証します。 |
| 青チーム | 戦争ゲーム練習で赤チームの攻撃を防御するチーム。 |
| 侵入テスト | 倫理的なハッキング技術を使用してシステムのセキュリティ防御を検証するテスト方法。 |
| 赤チーム | 戦争ゲーム練習で敵役を演じ、システムのハッキングを試みるチーム。 |
| セキュリティ開発ライフサイクル (SDL) | マイクロソフトが提供する一連のプラクティスは、セキュリティ保証とコンプライアンス要件をサポートします。 |
| ソフトウェア開発ライフサイクル (SDLC) | ソフトウェア システムを開発するための多段階の体系的なプロセス。 |
| ホワイトボックス テスト | 実行者がコードの構造を既に知っているテスト方法。 |
主要な設計戦略
テストは、特にセキュリティの場合、交渉の余地のない戦略です。 これにより、悪用される前にセキュリティ問題を発見して対処し、実装したセキュリティ制御が設計どおりに機能していることを確認できます。
テストの範囲には、アプリケーション、インフラストラクチャ、自動化されたプロセスと人間のプロセスが含まれる必要があります。
注意
このガイダンスでは、テストとインシデント応答を区別しています。 テストは、理想は運用前に問題を修正する検出メカニズムですが、インシデント対応の一環として行われる修復や調査と混同しないでください。 セキュリティ インシデントからの回復については、セキュリティ インシデント応答に関するレコメンデーションで説明されています。
テスト計画に参加してください。 ワークロード チームはテスト ケースを設計しない場合があります。 そのタスクは、多くの場合、企業内で集中管理されるか、外部のセキュリティ専門家によって完了されます。 セキュリティ保証とアプリケーションの機能を統合するには、ワークロード チームがその設計プロセスに関与する必要があります。
攻撃者の立場になって考えてみましょう。 システムが攻撃されたことを想定してテスト ケースを設計します。 そうすれば、潜在的な脆弱性を明らかにし、それに応じてテストの優先順位を決めることができます。
構造化された方法と繰り返しが可能なプロセスでテストを実行します。 テストの頻度、テストの種類、推進要因、および意図する結果に基づいてテストの厳密さを構築します。
ジョブには正しいツールを使用してください。 ワークロードで動作するように構成されたツールを使用します。 ツールがない場合は、ツールを購入してください。 ツールは構築しないでください。 セキュリティ ツールは高度に専門化されており、独自のツールを構築するとリスクが生じる可能性があります。 ワークロード チームに専門知識がない場合は、中央の SecOps チームが提供する専門知識とツールを活用するか、外部の手段を活用します。
別の環境を設定します。 テストは破壊的か非破壊的に分類できます。 非破壊的なテストは侵襲的ではありません。 これらは問題があることを示しますが、問題を修復するために機能を変更するわけではありません。 破壊的なテストは侵襲的であり、データベースからデータを削除することで機能を損傷する可能性があります。
運用環境でのテストでは最良の情報が得られますが、最大の混乱が生じます。 運用環境では非破壊的テストのみを行う傾向があります。 非運用環境でのテストは、通常、混乱は少ないですが、セキュリティにとって重要な方法で運用環境の構成を正確に表さない可能性があります。
環境コピー機能を使用して、運用環境の分離されたクローンを作成できます。 展開パイプラインが設定されている場合は、ソリューションを専用のテスト環境に展開することもできます。
常にテスト結果を評価します。 テストの結果がアクションの優先順位付けや上流の改善に使用されない場合は、テストは無駄になります。 発見したベスト プラクティスを含むセキュリティ ガイドラインを文書化します。 結果と修復計画を記録したドキュメントで、攻撃者がセキュリティを侵害しようとするさまざまな方法についてチームを教育できます。 開発者、管理者、テスターを対象とした定期的なセキュリティ トレーニングを実施します。
テスト計画を設計するときは、次の質問を考慮してください。
- テストはどのくらいの頻度で実行される予定ですか? また、それが環境にどのような影響を及ぼしますか?
- 実行する必要があるテストの種類は何ですか?
テストが実行される予定の頻度は?
ワークロードを定期的にテストして、変更がセキュリティ リスクをもたらさないこと、および後退がないことを確認します。 チームは、いつでも実施される可能性がある組織のセキュリティ検証に対応できるよう準備する必要があります。 セキュリティ インシデントに対応して実行できるテストもあります。 次のセクションには、テストの頻度に対するレコメンデーションが含まれています。
定期テスト
定期テストは、標準的な運用手順の一環として、またコンプライアンス要件を満たすために、定期的に実施されます。 さまざまなテストが異なる頻度で実行される場合がありますが、重要なのは、それらが定期的かつスケジュールに従って実行されることです。
これらのテストは各段階で徹底した防御を提供するため、SDLC に統合する必要があります。 テスト スイートを多様化し、ID、データの保存と送信、通信チャネルの保証を検証します。 ライフサイクルのさまざまな時点で同じテストを実施し、回帰がないことを確認します。 定期テストは、最初のベンチマークを確立するのに役立ちます。 しかし、それは単なる出発点に過ぎません。 ライフサイクルの同じ時点で新しい問題が発見されたら、新しいテスト ケースを追加します。 テストも繰り返し行うことで向上します。
各段階で、これらのテストでは、追加または削除されたコードや変更された構成設定を検証し、それらの変更によるセキュリティへの影響を検出する必要があります。 ピア レビューとバランスを取りながら、自動化によってテストの有効性を向上させる必要があります。
自動化されたパイプラインまたはスケジュールされたテスト実行の一部として、セキュリティ テストを実行することを検討してください。 セキュリティ問題の発見が早いほど、その原因となっているコードや構成変更を見つけることが容易になります。
自動テストのみに頼らないでください。 手動テストを使用して、人間の専門知識だけが検出できる脆弱性を検出します。 手動テストは、探索的なユース ケースや未知のリスクの発見に適しています。
即席テスト
即席テストにより、セキュリティ防御を特定の時点で検証できます。 その時点でワークロードに影響を及ぼす可能性のあるセキュリティ アラートによって、これらのテストがトリガーされます。 組織の義務では、警報が緊急事態にエスカレートした場合に防御戦略の有効性を検証するために、一時停止してテストするという考え方が必要な場合があります。
即席テストの利点は、実際のインシデントに備えることができることです。 これらのテストは、ユーザー受け入れテスト (UAT) を強制的に実行する機能となる場合があります。
セキュリティ チームはすべてのワークロードを監査し、必要に応じてこれらのテストを実行する場合があります。 ワークロード所有者として、セキュリティ チームを支援し、協力する必要があります。 準備ができるように、セキュリティ チームと十分なリード タイムを交渉します。 これらの中断は必要であることを認識して、チームと関係者に伝えます。
場合によっては、テストを実行し、潜在的な脅威に対するシステムのセキュリティ状態を報告することが必要な場合もあります。
トレードオフ: 即席テストは中断的なイベントです。タスクを再度優先順位付けするため、計画した作業の遅延が予想されます。
リスク: 不明なリスクがあります。 即席テストは、確立されたプロセスやツールなしで行われる 1 回限りの作業になる可能性があります。 しかし、主なリスクは、ビジネスのリズムが中断される可能性があることです。 それらのリスクをメリットと比較して評価する必要があります。
セキュリティ インシデント テスト
セキュリティ インシデントの原因を発生源から検出するテストがあります。 事件が再発しないようにするには、これらのセキュリティ ギャップを解決する必要があります。
インシデントにより既存のギャップが明らかになり、時間の経過とともにテスト ケースも改善されます。 チームはインシデントから学んだ教訓を適用し、定期的に改善を組み込む必要があります。
テストには何の種類がありますか?
テストは テクノロジ と テスト方法に分類できます。 これらのカテゴリと、それらのカテゴリ内のアプローチを組み合わせて、完全なカバレッジを実現します。
複数のテストとテストの種類を追加することで、次のことが明らかになります。
- セキュリティ制御または補償制御のギャップ。
- 構成ミス。
- 監視と検出方法のギャップ。
適切な脅威モデリング練習では、テストの範囲と頻度を確保するための重要な領域を特定できます。 脅威モデリングに関するレコメンデーションについては、開発ライフサイクルを保護するためのレコメンデーションを参照してください。
これらのセクションで説明されているテストのほとんどは、日常的なテストとして実行できます。 ただし、反復性によりコストが発生し、混乱が生じる場合があります。 トレードオフを慎重に考慮してください。
テクノロジ スタックを検証するテスト
ここでは、テストの種類とそのフォーカス領域の例をいくつか示します。 このリストは、包括的ではありません。 アプリケーション スタック、フロントエンド、バックエンド、API、データベース、外部統合を含むスタック全体をテストします。
- データ セキュリティ: データ暗号化とアクセス制御の有効性をテストし、データが不正アクセスや改ざんから適切に保護されていることを確認します。
- ネットワークと接続: ファイアウォールをテストして、ワークロードへの想定される許可された安全なトラフィックのみが許可されていることを確認します。
- アプリケーション: アプリケーション セキュリティ テスト (AST) 手法を使用してソース コードをテストし、安全なコーディング プラクティスに従っていることを確認し、メモリ破損や権限の問題などの実行時エラーを検出します。
- ID: ロールの割り当てと条件チェックが意図したとおりに機能するかどうかを評価します。
テスト方法
テスト方法にはさまざまな観点があります。 現実世界の攻撃をシミュレートして脅威ハンティングを可能にするテストをお勧めします。 潜在的な脅威アクター、その手法、ワークロードに脅威をもたらす手口を特定できます。 攻撃を可能な限り現実的にします。 脅威をモデル化しているときに特定した、すべての潜在的な脅威ベクトルを使用します。
実際の攻撃を使ってテストすると、次のような利点が得られます。
- 攻撃を定期的なテストの一部にすると、外部からの視点を使用してワークロードをチェックし、防御が攻撃に耐えられることを確認できます。
- 学んだ教訓に基づいて、チームは知識とスキルのレベルを向上させます。 チームは状況認識を向上させ、インシデントに対応する準備状況を自己評価できます。
シミュレーション テストの例としては、ブラック ボックス テスト、ホワイト ボックス テスト、侵入テスト、戦争ゲーム練習などがあります。
ブラックボックス テストとホワイトボックス テスト
これらのテスト タイプは、2 つの異なる観点を提供します。 ブラックボックス テストでは、システムの内部は見えません。 ホワイト ボックス テストでは、テスターはアプリケーションを十分に理解しており、実験を実行するためのコード、ログ、リソース トポロジ、構成にもアクセスできます。
侵入テストを使用して攻撃をシミュレートするテスト
組織の IT チームやアプリケーション チームに所属していないセキュリティ専門家が、侵入テスト、つまり ペンテストを実施します。 彼らは、悪意のある攻撃者が攻撃面を調査するのと同じようにシステムを調べます。 彼らの目標は、情報を収集し、脆弱性を分析し、結果を報告して、セキュリティのギャップを見つけることです。
実践者は組織全体の機密データにアクセスする必要があるかもしれません。 アクセスが悪用されないように、エンゲージメント ルールに従ってください。 参照に記載されているリソースを参照してください。
戦争ゲーム練習を使用して攻撃をシミュレートするテスト
シミュレーション攻撃の方法には、次の 2 つのチームがあります。
- 赤 チームは、現実世界の攻撃をモデル化しようとする敵対者です。 攻撃が成功した場合、セキュリティ設計のギャップが見つかり、侵入の被害範囲の封じ込めが評価されます。
- 青 チームは、攻撃を防御するワークロード チームです。 攻撃を検出し、対応し、修復する能力をテストします。 ワークロード リソースを保護するために実装された防御を検証します。
定期テストとして実施される場合、戦争ゲーム練習は継続的な可視性をもたらし、防御が設計どおりに機能することを保証できます。 戦争ゲーム練習では、ワークロード内のさまざまなレベルをテストできる可能性があります。
現実的な攻撃シナリオをシミュレートするのに人気の選択肢は、Microsoft Defender for Office 365 攻撃シミュレーション トレーニングです。
詳細については、攻撃シミュレーション トレーニングのインサイトとレポートを参照してください。
赤チームと青チームの設定に関する詳細については、Microsoft Cloud 赤チームを参照してください。
Power Platform の促進
Microsoft Power Platform 用 Microsoft Sentinel ソリューションを使用すると、顧客は次のようなさまざまな不審なアクティビティを検出できるようになります。
- 未承認地域からの Power Apps の実行
- Power Apps による不審なデータの破棄
- Power Apps の一括削除
- Power Apps を介したフィッシング攻撃
- 退職者による Power Automate フロー活動
- 環境に追加された Microsoft Power Platform コネクター
- Microsoft Power Platform データ損失防止ポリシーの更新または削除
詳細情報については、Microsoft Power Platform のための Microsoft Sentinel ソリューションの概要 を参照してください。
製品ドキュメントについては、Microsoft Sentinel のハンティング機能を参照してください。
Microsoft Defender for Cloud は、さまざまなテクノロジ分野の脆弱性をスキャンします。 詳細については、Microsoft Defender 脆弱性管理を使用して脆弱性スキャンを有効にするを参照してください。
DevSecOps の実践では、進行中かつ継続的な改善の考え方の一部としてセキュリティ テストを統合します。 戦争ゲーム練習は、マイクロソフトのビジネスのリズムに組み込まれた一般的な慣行です。 詳細については、DevOps (DevSecOps) のセキュリティを参照してください。
Azure DevOps は、継続的インテグレーション/継続的配置 (CI/CD) パイプラインの一部として自動化できるサードパーティ ツールをサポートします。 詳細については、Azure と GitHub で DevSecOps を有効にするを参照してください。
参照
最新の侵入テストとセキュリティ評価は、Microsoft サービス トラスト ポータル にあります。
マイクロソフトは Microsoft クラウド サービスの広範なテストを実行します。 このテストには侵入テストが含まれており、結果は組織の Service Trust Portal に公開されます。 組織は Microsoft Power Platform と Microsoft Dynamics 365 サービスの侵入テストを独自で実施することができます。 侵入テストについては、Microsoft Cloud 侵入テストの実施ルールに従う必要があります。 多くの場合、Microsoft Cloud は、共有インフラストラクチャを使用して顧客の資産や他の顧客に属する資産をホストすることを念頭に置くことが重要です。 すべての侵入テストを自社の資産に限定し、周囲の他の顧客に予期しない結果が及ばないようにする必要があります。
アクセスが悪用されないように、実施ルールに従ってください。 シミュレーション攻撃の計画と実行に関するガイダンスは、以下を参照してください。
Azure でサービス拒否 (DoS) 攻撃をシミュレートできます。 Azure DDoS Protection シミュレーション テストに記載されているポリシーに従ってください。
セキュリティ チェックリスト
完全な推奨事項セットを参照してください。