脅威分析に関するレコメンデーション

この Power Platform Well-Architected Security チェックリストのレコメンデーションに適用されます。

ワークロードの設計段階では、脅威、攻撃、脆弱性、および対策を特定するための包括的な分析が重要です。 脅威モデリングは、セキュリティ要件の定義、脅威の特定と軽減、およびそれらの軽減の検証を含むエンジニアリング練習です。 この手法はアプリケーションの開発または運用のどの段階でも使用できますが、最も効果的なのは新しい機能の設計段階での使用です。

このガイドでは、セキュリティ ギャップを迅速に特定し、セキュリティ防御を設計できるように、脅威モデリングを実行するためのレコメンデーションについて説明します。

定義

主要な設計戦略

脅威モデリングは、組織が SDLC に統合する必要がある重要なプロセスです。 脅威モデリングは開発者だけのタスクではありません。 次の人々の間で共有される責任です。

• システムの技術面を担当するワークロード チーム。
• ビジネスの結果を理解し、セキュリティに関心を持つビジネス関係者。

重要なワークロードのビジネス要件に関して、組織のリーダーシップと技術チームの間に溝があることがよくあります。 この溝は、特にセキュリティ投資において、望ましくない結果につながる可能性があります。

脅威モデリング練習を行うときは、ビジネス要件と技術要件の両方を考慮してください。 ワークロード チームとビジネス関係者は、対策に適切な投資を行えるように、ワークロードのセキュリティ固有のニーズについて合意する必要があります。

セキュリティ要件は、脅威モデリングのプロセス全体のガイドとして機能します。 効果的な練習を行うには、ワークロード チームがセキュリティ思考で、脅威モデリング ツールのトレーニングを受ける必要があります。

練習の範囲を理解する

効果的な脅威モデリングには、範囲を明確に理解することが重要です。 最も重要な領域に努力とリソースを集中させるのに役立ちます。 この戦略には、システムの境界の定義、保護する必要のある資産のインベントリの作成、セキュリティ制御に必要な投資レベルの理解が含まれます。

各コンポーネントに関する情報を収集する

ワークロード アーキテクチャ図はシステムを視覚的に表現するものであるため、情報収集の開始点となります。 この図は、システムの技術面を強調しています。 たとえば、ユーザー フロー、データがワークロードのさまざまな部分をどのように移動するか、データ機密度のレベルと情報の種類、ID アクセス パスが示されています。

この詳細な分析により、設計内の潜在的な脆弱性についてのインサイトが頻繁に得られます。 各コンポーネントの機能とその依存関係を理解することが重要です。

潜在的な脅威を評価する

各コンポーネントをアウトサイドインの観点から分析します。 たとえば、攻撃者は機密データにどれほど簡単にアクセスできるでしょうか? 攻撃者が環境にアクセスした場合、横方向に移動して、他のリソースにアクセスしたり、操作したりする可能性がありますか? これらの質問は、攻撃者がワークロード資産を悪用する方法を理解するのに役立ちます。

業界の方法を使用して脅威を分類する

脅威を分類するための方法に ストライドがあります。これは、Microsoft セキュリティ開発ライフサイクルで使用されます。 脅威を分類すると、各脅威の性質を理解し、適切なセキュリティ制御を使用するのに役立ちます。

脅威の軽減

特定されたすべての脅威を文書化します。 脅威ごとに、セキュリティ制御と、それらの制御が失敗した場合の攻撃への対応を定義します。 ワークロード内で特定された脆弱性への露出を最小限に抑えるプロセスとタイムラインを定義し、それらの脆弱性が未対処のままにならないようにします。

違反を想定する アプローチを使用します。 これは、主要なセキュリティ制御が失敗した場合のリスクを軽減するために、設計に必要な制御を特定するのに役立ちます。 主要な制御が失敗する可能性を評価します。 失敗した場合、潜在的な組織リスクの範囲はどれくらいですか? また、補償制御の有効性はどのようなものですか? 評価に基づいて、多層防御対策を適用して、セキュリティ制御の潜在的な障害に対処します。

次に例を示します。

脅威モデリングの結果を追跡する

脅威モデリング ツールを使用することを強くお勧めします。 ツールを使用すると、脅威を特定するプロセスを自動化し、特定されたすべての脅威に関する包括的なレポートを作成できます。 関心のあるすべてのチームに必ず結果を伝えてください。

ワークロード チームのバックログの一部として結果を追跡し、タイムリーに説明責任を果たせるようにします。 脅威モデルによって特定されたリスクを軽減する責任を負う個人にタスクを割り当てます。

ソリューションに新しい機能を追加するときは、脅威モデルを更新し、コード管理プロセスに統合します。 セキュリティ上の問題が見つかった場合は、重大度に基づいて問題を優先順位付けするプロセスがあることを確認してください。 このプロセスは、問題をいつどのように修正するかを決定するのに役立ちます (たとえば、次のリリース サイクルやより速いリリースで)。

ビジネスクリティカルなワークロード要件を定期的に確認する

定期的にエグゼクティブ スポンサーと会って要件を定義します。 これらのレビューにより、期待を一致させ、イニシアチブへの運用リソースの割り当てを確実にする機会が提供されます。

Power Platform の促進

Power Platform は、安全設計の文化と方法論に基づいて構築されています。 Microsoft の業界をリードする セキュリティ開発ライフサイクル (SDL) と 脅威モデリング のプラクティスにより、文化と方法論の両方が常に強化されています。

脅威モデリングのレビュー プロセスにより、設計段階で脅威を特定し、軽減し、検証して、軽減されたことを確認します。

脅威モデリングでは、継続的かつ定期的なレビューを通じて既に実施されているサービスへのすべての変更も考慮されます。 STRIDE モデル に依存することで、安全でない設計に関する最も一般的な問題に対処することができます。

Microsoft の SDL は、OWASP Software Assurance Maturity Model (SAMM) に相当します。 どちらも、安全な設計が Web アプリケーションのセキュリティに不可欠であるという前提に基づいて構築されています。

詳細については、OWASP リスクの上位 10:Power Platform での軽減策を参照してください。

例

この例は、セキュリティ ベースラインを確立するためのレコメンデーションで確立された情報技術 (IT) 環境に基づいています。 このアプローチにより、さまざまな IT シナリオでの脅威の状況を幅広く理解できます。

開発ライフサイクル ペルソナ。 開発ライフ サイクルには、開発者、テスター、最終ユーザー、管理者など、多くの関係者が関与します。 これらはすべて侵害される可能性があり、意図的に作成された脆弱性や脅威によって環境が危険にさらされることがあります。

潜在的な攻撃者。 攻撃者は、脆弱性を探り、攻撃を開始するために、いつでも簡単に使用できるさまざまなツールを検討します。

セキュリティ コントロール。 脅威分析の一環として、ソリューションを保護するために使用される Microsoft、Azure、Power Platform セキュリティ サービスと、それらのソリューションの有効性を特定します。

ログ コレクション。 Azure リソースやオンプレミスのコンポーネントなど、ワークロードに含まれる Power Platform リソースやその他のコンポーネントからのログは、Application Insights または Microsoft Purview に送信され、開発されたソリューションの動作を理解できるようになり、初期の脆弱性をキャプチャしようとします。

セキュリティ情報イベント管理 (SIEM) ソリューション。 Microsoft Sentinel はソリューションの初期段階でも追加できるため、運用時のセキュリティ環境を予測して、脅威や脆弱性を軽減するための分析クエリを構築できます。

参照

• ストライド モデル
• 脅威モデリング
• Power Platform のセキュリティに関するよくある質問
• Microsoft Identity プラットフォーム
• セキュリティ開発ライフサイクル
• Azure AD 継続的アクセス評価
• コンテンツ セキュリティ ポリシー
• Azure DDoS Protection
• Microsoft Intune のコンプライアンス ポリシーの設定

セキュリティ チェックリスト

完全な推奨事項セットを参照してください。