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