以下の Azure Well-Architected フレームワーク セキュリティ チェックリストの推奨事項に対応します。
| SE:11 | セキュリティの問題を防ぎ、脅威防止の実装を検証し、脅威検出メカニズムをテストするアプローチを組み合わせたテストレジメンを確立します。 |
|---|
厳格なテストは、優れたセキュリティ設計の基礎です。 また、テストはシステムの脆弱性を事前に検出する方法でもあります。
周期と複数の観点からの検証を通じてテストの厳密さを確立します。 プラットフォームとインフラストラクチャをテストするインサイド アウトの視点と、外部の攻撃者のようにシステムをテストする外部の評価を含めます。
この記事の重要な戦略は、 OE:09 のテストのためのアーキテクチャ戦略で説明されている基本的なテスト プラクティスに基づいて構築されています。 最初にその記事を確認します。 このガイドでは、ワークロードのセキュリティ態勢をテストするための推奨事項を示します。 これらのテスト方法を実装して、攻撃に対するワークロードの耐性を向上させ、リソースの機密性、整合性、可用性を維持します。
用語
| 期間 | 定義 |
|---|---|
| アプリケーション セキュリティ テスト (AST) | ホワイト ボックスとブラック ボックスのテスト手法を使ってコードでのセキュリティの脆弱性をチェックする Microsoft セキュリティ開発ライフサイクル (SDL) 手法。 |
| ブラック ボックス テスト | システムの内部的な知識なしで、外部から認識できるアプリケーションの動作を検証するテスト手法。 |
| ホワイトボックステスト | 実施者がコードの構造を知っているテスト手法。 |
| レッド チーム | 戦争ゲーム演習で、敵対者の役割を演じてシステムのハッキングを試みるチーム。 |
| ブルー チーム | 戦争ゲーム演習で、レッド チームによる攻撃に対して防御するチーム。 |
| 侵入テスト | 倫理的ハッキング手法を使ってシステムのセキュリティ防御を検証するテスト手法。 |
| セキュリティ開発ライフサイクル (SDL) | セキュリティの保証とコンプライアンスの要件をサポートする、Microsoft が提供する一連のプラクティス。 |
セキュリティの専門家と共同作業してテストを設計する
テスト計画に関与します。 多くの場合、組織はこのタスクを一元化します。 セキュリティ保証がアプリケーションの機能と一致するように、チームがその設計プロセスに関与していることを確認します。
侵害想定の考え方を構築します。 システムが攻撃を受け、攻撃者が環境内で動作していることを前提として、テスト ケースを設計します。 テストをシミュレートして、侵害されたアプリケーション VM 内の横移動コンテインメントの検証などの現実的な攻撃シナリオを反映します。 これにより、潜在的な脆弱性を明らかにし、それに応じてテストに優先順位を付けることができます。
アーキテクチャ図、脅威モデル、およびその他の関連ドキュメントを共有して、ワークロードを有意義にテストします。
脅威モデリングと重要なフローに基づいてテストに優先順位を付ける
脅威モデリングは、ワークロード内の潜在的な脅威と脆弱性を特定するための重要なプラクティスです。 脅威モデルの重大度評価を使用して、テスト作業に優先順位を付け、スコープを設定します。 最も重大なフローに対する最も重大度の高い脅威は、最も多くの対象範囲に値します。
ワークロードの攻撃対象領域全体をカバーします。 ID、アプリケーション コード、インフラストラクチャ制御、サードパーティのコンポーネント、ライブラリとサービス、承認ワークフローやアクセス レビューなどの自動化された人間のプロセスを評価します。
侵害された ID はほとんどのダウンストリーム防御をバイパスするため、ID とアクセス制御から始めます。 次に、ネットワーク境界を検証し、最後にアプリケーション層の防御を検証します。
認証、機密データ、または財務トランザクションを処理するフローに優先順位を付けます。 重要なフローごとに、脅威モデルで重大度評価が最も高い脅威を特定します。 各脅威を軽減するためのコントロールにマップするリスクドリブンのテスト ケースを作成します。
適切な脅威モデリングを行うことで、テストの網羅範囲や実施頻度について重点を置くべき領域が明らかになります。 脅威モデリングに関する推奨事項については、「開発ライフサイクルのセキュリティ保護に関する推奨事項」をご覧ください。
リスク: 古い脅威モデルは、テスト作業の不整合につながる可能性があります。 ワークロードの変化と進化する脅威の状況を反映するように、脅威モデルを定期的に更新します。
サード パーティの専門知識を活用する
内部チームは盲点を持つことができます。 外部の専門家やクラウドソーシングされた研究者は、攻撃者と同じ視点でワークロードを捉えます。 専門の専門家を招き、敵対者の視点からワークロードをテストし、最新の攻撃手法と傾向に関する分析情報を提供します。
ワークロードに過度に広いアクセス権を付与しないでください。 外部テスト担当者に対して、特定のエンゲージメントに必要なアクセス権のみを付与します。 ブラックボックス侵入テストではコードや内部アクセスは必要ありませんが、ホワイトボックス レビューにはソース コード、デザイン ドキュメント、またはログが必要です。
プログラムを起動する前に、チームに外部レポートをトリアージする能力があるかどうかを評価します。 次に、バグ報奨金プログラムまたはコミュニティがセキュリティの問題を報告するためのメカニズムを確立します。 報告されたすべての検出結果をトリアージし、確認された脆弱性を脅威モデルに送り返し、任意の回帰をキャッチするテスト ケースを追加します。
コンプライアンスコントロールをテストし、監査対応の証拠を生成する
コンプライアンスは 1 回限りのレビューではありません。 各規制コントロールをテスト可能な要件として扱い、常に監査者の新しい証拠を得るようにします。
ワークロードが満たす必要がある規制を特定します。 各規制コントロールを特定のテスト ケースにマップします。 テストを定期的に実行し、すべての稼働前に実行するようにスケジュールします。 必要に応じて証拠を生成できるように、監査可能な場所にテスト出力を格納します。
トレードオフ： 規制コントロールのテストにより、操作が遅くなる可能性があります。 たとえば、デプロイ前テストではパイプラインの待機時間が追加されます。 また、これらの操作を実行するコストも追加されます。 監査とリスクへの影響が最も高いコントロールのテストに優先順位を付けます。
テスト資産を保護する
テスト資産自体が攻撃対象領域です。 機密性、整合性、可用性を保護して、テストで機密情報を公開したり、新しい攻撃ベクトルを開いたりしないようにします。
- 個人を特定できる情報 (PII) または運用データを含まないサニタイズされたデータまたは合成データを使用します。
- 必要な期間だけテスト データを保持し、安全に削除します。
- リージョンにまたがるテスト環境で、国境を越えたデータ所在地ルールが適用されていることを確認します。
- 専用のテスト資格情報、API キー、証明書を生成します。 独自のアクセス ポリシーを使用して、別のキー コンテナー インスタンスに格納します。
- ネットワーク セキュリティ グループ (NSG)、ロールベースのアクセス制御 (RBAC) ポリシー、ファイアウォール、データ損失防止 (DLP) ルールなどの運用セキュリティ制御をミラーリングする分離されたテスト環境を設定します。 運用環境と同じセグメント化ガイダンスを適用します。 詳細については、「 セグメント化戦略の推奨事項」を参照してください。
テスト資産に対して定期的な脆弱性スキャンを実施する
テスト 資産をスキャンして、テスト コード、コードとしてのインフラストラクチャ (IaC)、コンテナーと VM のイメージ、リポジトリ、パイプラインなど、運用資産と同じ周期で脆弱性をスキャンします。 開発およびデプロイ ワークフローと統合されたツールを使用して、これらのチェックを自動化します。
ワークロードの継続的なテスト のリズムを確立する
セキュリティ テストは、脅威、コード、構成が進化するにつれてワークロードのセキュリティ体制を最新の状態に保つ継続的なアクティビティとして扱います。 スケジュールに従ってテストを実行し、変更によってセキュリティ リスクや回帰が発生しないようにします。 いつでも発生する可能性のある組織のセキュリティ検証と、セキュリティ インシデントによってトリガーされるテストの準備を整える。 以下のセクションでは、計画時に考慮すべきサイクルについて説明します。
定期的テスト
定期的なテストによって、ワークロードのセキュリティ体制のベースラインが設定されます。 標準の運用手順の一部として定期的に実施し、コンプライアンス要件を満たします。 さまざまなテストをさまざまな頻度で実行することもできますが、重要なのは、定期的にスケジュールに従って実行することです。
テスト スイートを多様化して、ID、データ ストレージと送信、通信チャネルの保証を確認します。 ライフサイクルの同じ時点で新しい問題を発見したら、新しいテスト ケースを追加します。
自動テストだけに依存しないでください。 手動テストを使用して、人間の専門知識だけがキャッチできる脆弱性を見つけ、未知のリスクに対する探索的な作業を行います。
即興テスト
即興テストは、セキュリティ防御のポイントインタイム検証を提供します。 その時点でワークロードに影響を与える可能性のあるセキュリティ警告によって、これらのテストがトリガーされます。 組織的な義務によって、警告が緊急事態にエスカレートした場合に防御戦略の有効性を検証するための一時停止とテストの考え方が必要になる場合があります。
即興テストの利点は、実際のインシデントに対する準備です。 これらのテストによって、ユーザー受け入れテスト (UAT) を行うよう強制的に促すことができます。
セキュリティ チームは、すべてのワークロードを監査し、必要に応じてこれらのテストを実行する場合があります。 ワークロード所有者は、セキュリティ チームを支援し、共同で作業する必要があります。 準備できるように、セキュリティ チームと十分なリード タイムを交渉します。 これらの中断が必要であることを確認してチームや利害関係者に伝えます。
それ以外の場合では、テストを実行し、潜在的な脅威に対するシステムのセキュリティ状態を報告することが必要な場合があります。
セキュリティ インシデント テスト
ソースでセキュリティ インシデントの原因を検出するテストを使用します。 これらのセキュリティギャップを解決して、インシデントが繰り返されないようにします。
また、インシデントは、既存のギャップを明らかにすることで、徐々にテスト ケースを改善します。 チームは、インシデントから得られた経験を適用して、定期的に改善を組み込む必要があります。
注意
このガイダンスでは、テストとインシデント対応を区別します。 テストは運用環境の前に問題を理想的に修正する検出メカニズムですが、インシデント対応の一環として行われる修復や調査と混同しないでください。 セキュリティ インシデントからの復旧の側面については、インシデント対応の推奨事項に関する記事で説明されています。
攻撃対象領域全体のセキュリティコントロールを検証する
さまざまなテスト手法を使用して、完全なカバレッジを取得し、監視と検出におけるセキュリティ制御、構成の誤り、弱点のギャップを明らかにします。 このセクションで説明するほとんどのテストは、ルーチン テストとして実行できます。 ただし、再現性によってコストが発生し、中断が発生する可能性があります。 それらのトレードオフを慎重に検討してください。
暗号化コントロールをテストします。 暗号化エラーはサイレントです。 データは、侵害が明らかになるまで保護されたように見えます。
- 構成だけでなく、暗号化が適用されていることを検証します。
- キーのローテーション、証明書の更新、インフラストラクチャの変更のたびに再テストします。
ネットワーク制御をテストします。 ネットワーク境界は、セグメント化が適用される場所です。
- ネットワーク トポロジの変更後にテストします。
- 既定で拒否ルールが保持されていること、および許可されるトラフィック パスがアーキテクチャの意図と一致することを確認します。
アプリケーション コードをテストします。 アプリケーション層防御は、攻撃者がデータに到達する前の最後の境界です。
- デプロイされたアプリケーションが、ビルド時にソース コードのみをスキャンするのではなく、一般的な攻撃パターンに抵抗することを検証します。
- ソース コードでアプリケーション セキュリティ テスト (AST) 手法を実行して、セキュリティで保護されたコーディングプラクティスを確認し、メモリの破損や特権の問題などの実行時エラーをキャッチします。 詳細については、 コミュニティのリンクを参照してください。
ID ベースの攻撃をシミュレートし、検出を検証する
ID ベースの攻撃は、最も一般的な初期攻撃ベクトルです。 これらの攻撃をシミュレートして、ID コントロールが機能し、監視によってイベントがキャプチャされることを検証します。
アクセス制御は防御の第一線です。 ロールまたはポリシーが変更されるたびに、自動スケジュールでテストします。 一般的な攻撃パターンをシミュレートし、コントロールが最小限の特権を適用し、バイパス試行に抵抗することを確認します。
テストを設計するときは、次の攻撃パターンを考慮してください。
- 認可バイパス
- トークンの盗難と再生
- アカウントまたはサービス間の横移動
- 特権エスカレーション
各コントロールの両側を検証します。
- 肯定的なケース: 承認されたユーザーは成功します。
- 否定的なケース: 未承認の試行がブロックされ、ログに記録されます。
脅威の検出とアラートをテストする
アラートをトリガーしない検出では、ほとんど価値がありません。 すべてのセキュリティコントロール検証の一環として監視とアラートをテストし、攻撃を検出するように設計されたメカニズムが期待どおりに動作することを確認します。
攻撃のエンド ツー エンド シミュレーションを実行し、検出パイプラインの各ステージを確認します。
- サインイン試行、アクセス許可の変更、トークン操作などのセキュリティ イベントが十分な詳細でログに記録されることを検証します。
- セキュリティ情報およびイベント管理 (SIEM) プラットフォームまたはセキュリティ操作ダッシュボードが関連するイベントを関連付けられていることを確認します。
- アラート サービス レベル アグリーメント (SLA) を確立し、アラートが実行可能であり、その期間内に表示されることをテストします。
- 管理者以外のアカウントでログを改ざんしたり削除したりできないことを確認します。
- 各シミュレート攻撃に対して検知メカニズムが作動することを確認してください。 たとえば、有効なトラフィック パターンで分散型サービス拒否 (DDoS) 攻撃をシミュレートする場合は、レート制限によって検出されて軽減されることを確認します。
成熟したワークロードの場合は、定期的なテストとしてガバナンス ガードレールを検証します。 安全でない構成を意図的に導入し、パイプラインが検出して応答することを確認します。 Azure Policyまたはランディング ゾーンの制約によって、想定される保護が適用されていることを確認します。 通常、プラットフォームまたはセキュリティ チームは、ワークロード チームではなく、このテストを実行します。
敵対者ベースのテストを使用して防御を強化する
実際の攻撃をシミュレートして脅威ハンティングを有効にするテストを使用します。 これらのテストでは、潜在的な脅威アクター、その手法、およびワークロードに脅威をもたらす悪用を特定できます。 攻撃を可能な限り現実的にします。 脅威モデリングの間に特定したすべての潜在的な脅威ベクトルを使います。
実際の攻撃を使ってテストすると次のような利点があります。
- これらの攻撃を定期的テストの一部にする場合は、アウトサイドインの視点を使ってワークロードをチェックし、防御が攻撃に耐えられることを確認します。
- 学習した教訓に基づいて、チームは知識とスキル レベルをアップグレードします。 チームは状況認識を向上させ、インシデントへの対応の準備状況を自己評価できます。
シミュレートされたテストの例としては、ブラック ボックスとホワイト ボックスのテスト、侵入テスト、戦争ゲーム演習などがあります。
ブラック ボックスとホワイト ボックスのテスト
これらのテストの種類では、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 のページでは、一般的な脅威をカバーするアプリケーションとテスト ケースのためのセキュリティのベスト プラクティスが提供されています。
セキュリティ チェックリスト
レコメンデーションの完全なセットを参照してください。