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