脅威分析に関する推奨事項
この Azure Well-Architected Framework セキュリティ チェックリストの推奨事項に適用されます。
| SE:02 | コンプライアンス要件、業界標準、プラットフォームの推奨事項に合わせたセキュリティ ベースラインを確立します。 ワークロードのアーキテクチャと運用をベースラインに対して定期的に測定して、時間の経過と同時にセキュリティ体制を維持または改善します。 |
|---|
関連ガイド: 開発ライフサイクルをセキュリティで保護するための推奨事項
ワークロードの設計フェーズでは、脅威、攻撃、脆弱性、対策を特定するための包括的な分析が重要です。 脅威モデリング は、セキュリティ要件の定義、脅威の特定と軽減、それらの軽減策の検証を含むエンジニアリング演習です。 この手法は、アプリケーション開発または運用のどの段階でも使用できますが、新機能の設計段階で最も効果的です。
このガイドでは、セキュリティ ギャップをすばやく特定し、セキュリティ防御を設計できるように、脅威モデリングを行うための推奨事項について説明します。
定義
| 期間 | 定義 |
|---|---|
| ソフトウェア開発ライフサイクル (SDLC) | ソフトウェア システムを開発するためのマルチステージで体系的なプロセス。 |
| STRIDE | 脅威の種類を分類するための Microsoft が定義した分類。 |
| 脅威モデリング | アプリケーションとシステムの潜在的なセキュリティ脆弱性を特定し、リスクを軽減し、セキュリティ制御を検証するためのプロセス。 |
主要な設計戦略
脅威モデリングは、organizationがその SDLC に統合する必要がある重要なプロセスです。 脅威モデリングは、開発者のタスクではありません。 これは、次の間で共有される責任です。
- システムの技術的な側面を担当するワークロード チーム。
- ビジネスの成果を理解し、セキュリティに対する既得権益を持つビジネス利害関係者。
重要なワークロードのビジネス要件に関しては、組織のリーダーと技術チームの間でしばしば齟齬が発生します。 この切断により、特にセキュリティ投資に対して望ましくない結果が生じる可能性があります。
ワークロード チームが脅威モデリングの演習を行うときは、ビジネス要件と技術要件の両方を考慮する必要があります。 ワークロード チームとビジネス利害関係者は、対策に十分な投資を行うことができるように、ワークロードのセキュリティ固有のニーズに同意する必要があります。
セキュリティ要件は、脅威モデリングのプロセス全体のガイドとして機能します。 効果的な演習にするために、ワークロード チームはセキュリティマインドセットを持ち、脅威モデリング ツールでトレーニングする必要があります。
演習の範囲を理解する
スコープを明確に理解することは、効果的な脅威モデリングに不可欠です。 これは、最も重要な領域に取り組みとリソースを集中するのに役立ちます。 この戦略では、システムの境界を定義し、保護する必要がある資産のインベントリを取得し、セキュリティ制御に必要な投資レベルを理解する必要があります。
各コンポーネントに関する情報を収集する
ワークロード アーキテクチャ図は、システムの視覚的な表現を提供するため、情報を収集するための開始点です。 この図では、システムの技術的なディメンションが強調表示されています。 たとえば、ユーザー フロー、ネットワーク内でのデータの移動方法、データの秘密度レベルと情報の種類、ID アクセス パスが表示されます。
この詳細な分析は、多くの場合、設計の潜在的な脆弱性に関する分析情報を提供する可能性があります。 各コンポーネントの機能とその依存関係を理解することが重要です。
潜在的な脅威を評価する
外部から見て各コンポーネントを分析します。 たとえば、攻撃者が機密データに簡単にアクセスできるでしょうか。 攻撃者が環境にアクセスできる場合、攻撃者は横方向に移動し、他のリソースにアクセスしたり、他のリソースを操作したりする可能性がありますか? これらの質問は、攻撃者がワークロード資産を悪用する方法を理解するのに役立ちます。
業界の方法論を使用して脅威を分類する
脅威を分類する方法の 1 つは、Microsoft セキュリティ開発ライフサイクルで使用される STRIDE です。 脅威の分類は、各脅威の性質を理解し、適切なセキュリティ制御を使用するのに役立ちます。
脅威を軽減する
特定されたすべての脅威を文書化します。 脅威ごとに、セキュリティ コントロールと、それらのコントロールが失敗した場合の攻撃への対応を定義します。 ワークロード内の特定された脆弱性への露出を最小限に抑えるプロセスとタイムラインを定義し、それらの脆弱性を解決しないようにします。
侵害を 想定 するアプローチを使用します。 これは、プライマリ セキュリティコントロールが失敗した場合にリスクを軽減するために設計に必要な制御を特定するのに役立ちます。 主要な制御が失敗する可能性を評価します。 失敗した場合、潜在的な組織リスクの程度は何ですか? また、補償制御の効果は何ですか? 評価に基づいて、セキュリティ制御の潜在的な障害に対処するための多層防御対策を適用します。
次に例を示します。
| この質問をする | コントロールを決定するには... |
|---|---|
| 接続は、Microsoft Entra ID、相互認証を使用したトランスポート層セキュリティ (TLS)、またはセキュリティ チームが承認した別の最新のセキュリティ プロトコルによって認証されます。 - ユーザーとアプリケーションの間? - アプリケーション コンポーネントとサービスの間? |
アプリケーション コンポーネントとデータへの不正なアクセスを防止します。 |
| アプリケーションでデータを書き込みまたは変更する必要があるアカウントのみにアクセスを制限していますか? | 不正なデータの改ざんまたは改変を防止します。 |
| アプリケーション アクティビティはログに記録され、Azure Monitor または同様のソリューションを介してセキュリティ情報イベント管理 (SIEM) システムに送られますか? | 攻撃を迅速に検出して調査します。 |
| 重要なデータは、セキュリティ チームが承認した暗号化で保護されていますか? | 保存データが不正にコピーされないようにします。 |
| 受信と送信のネットワーク トラフィックは TLS を介して暗号化されますか? | 転送中のデータが不正にコピーされないようにします。 |
| アプリケーションは、Azure DDoS Protection などのサービスを介した分散型サービス拒否 (DDoS) 攻撃から保護されていますか? | アプリケーションをオーバーロードさせて使用不可能にするように設計された攻撃を検出します。 |
| アプリケーションには、他のアプリケーション、データベース、またはサービスにアクセスするためのサインイン資格情報またはキーが格納されますか? | 攻撃がそのアプリケーションを使用して他のシステムを攻撃できるかどうかを識別します。 |
| アプリケーションの制御を使用して、規制要件を満たすことができますか? | ユーザーのプライベート データを保護し、コンプライアンスの罰金を回避します。 |
脅威モデリングの結果を追跡する
脅威モデリング ツールを使用することを強くお勧めします。 ツールを使用すると、脅威を特定するプロセスを自動化し、特定されたすべての脅威の包括的なレポートを生成できます。 すべての関心のあるチームに結果を伝えるようにしてください。
ワークロード チームのバックログの一部として結果を追跡し、タイムリーに説明責任を果たせるようにします。 脅威モデリングによって特定された特定のリスクの軽減を担当する個人にタスクを割り当てます。
ソリューションに新しい機能を追加するときは、脅威モデルを更新し、コード管理プロセスに統合します。 セキュリティの問題が見つかる場合は、重大度に基づいて問題をトリアージするプロセスがあることを確認します。 このプロセスは、問題を修復するタイミングと方法を決定するのに役立ちます (たとえば、次のリリース サイクルやより高速なリリース)。
ビジネスクリティカルなワークロード要件を定期的に確認する
エグゼクティブ スポンサーと定期的に会い、要件を定義します。 これらのレビューは、期待を調整し、イニシアチブへの運用リソースの割り当てを確保する機会を提供します。
Azure ファシリテーション
Microsoft セキュリティ開発ライフサイクルには、脅威モデリング プロセスを支援する脅威モデリング ツールが用意されています。 このツールは、追加料金なしで利用できます。 詳細については、「 脅威モデリング」ページを参照してください。
例
この例は、 セキュリティ ベースライン (SE:01) で確立された情報技術 (IT) 環境に基づいています。 このアプローチでは、さまざまな IT シナリオにわたる脅威の状況を幅広く理解できます。
開発ライフサイクル ペルソナ。 開発ライフサイクルには、開発者、テスト担当者、最終ユーザー、管理者など、多くのペルソナが関与しています。 これらのすべてが侵害され、意図的に作成された脆弱性や脅威によって環境が危険にさらされる可能性があります。
潜在的な攻撃者。 攻撃者は、脆弱性を調査して攻撃を開始するために、いつでも簡単に使用できるさまざまなツールを検討します。
セキュリティ コントロール。 脅威分析の一環として、ソリューションの保護に使用する Azure セキュリティ サービスと、それらのソリューションの効果を特定します。
ログ収集。 Azure リソースと一部のオンプレミス コンポーネントからのログが Azure Log Analytics に送信される可能性があるため、開発されたソリューションの動作を理解し、初期脆弱性のキャプチャを試みる可能性があります。
セキュリティ情報イベント管理 (SIEM) ソリューション。 Microsoft Sentinel は、ソリューションの初期段階でも追加される可能性があるため、いくつかの分析クエリを作成して脅威と脆弱性を軽減し、運用環境のセキュリティ環境を予測できます。
Microsoft Defender for Cloud では、セキュリティ体制を改善するためにいくつかのセキュリティに関する推奨事項が作成される場合があります。
関連リンク
コミュニティ リンク
Open Web Application Security Project (OWASP) によって、アプリケーション向けの脅威モデリング アプローチが文書化されています。
セキュリティ チェックリスト
推奨事項の完全なセットを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示