脅威分析に関するレコメンデーション
この Power Platform Well-Architected Securityチェックリストの推奨事項に適用されます:
セ:02 | 脅威モデリングを使用してセキュリティを破る実装から保護することで、安全な設計を組み込みます。 |
---|
ワークロードの設計段階では、脅威、攻撃、脆弱性、および対策を特定するための包括的な分析が重要です。 脅威モデリングは、セキュリティ要件の定義、脅威の特定と軽減、およびそれらの軽減の検証を含むエンジニアリング練習です。 この手法はアプリケーションの開発または運用のどの段階でも使用できますが、最も効果的なのは新しい機能の設計段階での使用です。
このガイドでは、セキュリティ ギャップを迅速に特定し、セキュリティ防御を設計できるように、脅威モデリングを実行するためのレコメンデーションについて説明します。
定義
任期 | 定義 |
---|---|
ソフトウェア開発ライフサイクル (SDLC) | ソフトウェア システムを開発するための多段階の体系的なプロセス。 |
ストライド | 脅威の種類を分類するための Microsoft定義の分類法。 |
脅威モデリング | アプリケーションおよびシステムの潜在的なセキュリティ脆弱性を特定し、リスクを軽減し、セキュリティ制御を検証するプロセス。 |
主要な設計戦略
脅威モデリングは、組織が SDLC に統合する必要がある重要なプロセスです。 脅威モデリングは開発者だけのタスクではありません。 次の人々の間で共有される責任です。
- システムの技術面を担当するワークロード チーム。
- ビジネスの結果を理解し、セキュリティに関心を持つビジネス関係者。
重要なワークロードのビジネス要件に関して、組織のリーダーシップと技術チームの間に溝があることがよくあります。 この溝は、特にセキュリティ投資において、望ましくない結果につながる可能性があります。
脅威モデリング練習を行うときは、ビジネス要件と技術要件の両方を考慮してください。 ワークロード チームとビジネス関係者は、対策に適切な投資を行えるように、ワークロードのセキュリティ固有のニーズについて合意する必要があります。
セキュリティ要件は、脅威モデリングのプロセス全体のガイドとして機能します。 効果的な練習を行うには、ワークロード チームがセキュリティ思考で、脅威モデリング ツールのトレーニングを受ける必要があります。
練習の範囲を理解する
効果的な脅威モデリングには、範囲を明確に理解することが重要です。 最も重要な領域に努力とリソースを集中させるのに役立ちます。 この戦略には、システムの境界の定義、保護する必要のある資産のインベントリの作成、セキュリティ制御に必要な投資レベルの理解が含まれます。
各コンポーネントに関する情報を収集する
ワークロード アーキテクチャ図はシステムを視覚的に表現するものであるため、情報収集の開始点となります。 この図は、システムの技術面を強調しています。 たとえば、ユーザー フロー、データがワークロードのさまざまな部分をどのように移動するか、データ機密度のレベルと情報の種類、ID アクセス パスが示されています。
この詳細な分析により、設計内の潜在的な脆弱性についてのインサイトが頻繁に得られます。 各コンポーネントの機能とその依存関係を理解することが重要です。
潜在的な脅威を評価する
各コンポーネントをアウトサイドインの観点から分析します。 たとえば、攻撃者は機密データにどれほど簡単にアクセスできるでしょうか? 攻撃者が環境にアクセスした場合、横方向に移動して、他のリソースにアクセスしたり、操作したりする可能性がありますか? これらの質問は、攻撃者がワークロード資産を悪用する方法を理解するのに役立ちます。
業界の方法を使用して脅威を分類する
脅威を分類する方法の1つに、 セキュリティ開発ライフサイクルで使用されるSTRIDE があります。 Microsoft 脅威を分類すると、各脅威の性質を理解し、適切なセキュリティ制御を使用するのに役立ちます。
脅威の軽減
特定されたすべての脅威を文書化します。 脅威ごとに、セキュリティ制御と、それらの制御が失敗した場合の攻撃への対応を定義します。 ワークロード内で特定された脆弱性への露出を最小限に抑えるプロセスとタイムラインを定義し、それらの脆弱性が未対処のままにならないようにします。
違反を想定する アプローチを使用します。 これは、主要なセキュリティ制御が失敗した場合のリスクを軽減するために、設計に必要な制御を特定するのに役立ちます。 主要な制御が失敗する可能性を評価します。 失敗した場合、潜在的な組織リスクの範囲はどれくらいですか? また、補償制御の有効性はどのようなものですか? 評価に基づいて、多層防御対策を適用して、セキュリティ制御の潜在的な障害に対処します。
次に例を示します。
この質問をする | ... の制御を決定するには |
---|---|
Microsoft Entra ID を使用して接続は認証され、セキュリティ チームが承認した最新のセキュリティ プロトコルを使用していますか? - ユーザーとアプリケーションの間では? - アプリケーション コンポーネントとサービスの間では? - ユーザーと副操縦士の間でですか? |
アプリケーション コンポーネントとデータへの不正アクセスを防止します。 |
アプリケーションでデータを書き込んだり変更したりする必要があるアカウントのみにアクセスを制限していますか? | 不正なデータの改ざんや変更を防ぎます。 |
アプリケーション アクティビティは、Azure Monitor や同様のソリューションを使用して、ログに記録され、セキュリティ情報イベント管理 (SIEM) システムに送信されますか? | 攻撃を迅速に検出して調査します。 |
重要なデータはセキュリティ チームが承認した暗号化で保護されていますか? | 保存データの不正なコピーを防止します。 |
インバウンドおよびアウトバウンドのネットワーク トラフィックは、セキュリティ チームによって承認されたドメインに分離されていますか? | データの不正なコピーを防止します。 |
環境上の IP ファイアウォールを使用して、アプリケーションはコーヒー ショップなどの外部/公共の場所からのアクセスから保護されていますか? | 許可されていない公共の場所からのアクセスを防止します。 |
アプリケーションは、他のアプリケーション、データベース、またはサービスにアクセスするためのサインイン資格情報またはキーを保存しますか? | 攻撃者がアプリケーションを利用して他のシステムを攻撃できるかどうかを識別します。 |
アプリケーション制御により、規制要件を満たすことができますか? | ユーザーの個人データを保護し、コンプライアンス違反の罰金を回避します。 |
脅威モデリングの結果を追跡する
脅威モデリング ツールを使用することを強くお勧めします。 ツールを使用すると、脅威を特定するプロセスを自動化し、特定されたすべての脅威に関する包括的なレポートを作成できます。 関心のあるすべてのチームに必ず結果を伝えてください。
ワークロード チームのバックログの一部として結果を追跡し、タイムリーに説明責任を果たせるようにします。 脅威モデルによって特定されたリスクを軽減する責任を負う個人にタスクを割り当てます。
ソリューションに新しい機能を追加するときは、脅威モデルを更新し、コード管理プロセスに統合します。 セキュリティ上の問題が見つかった場合は、重大度に基づいて問題を優先順位付けするプロセスがあることを確認してください。 このプロセスは、問題をいつどのように修正するかを決定するのに役立ちます (たとえば、次のリリース サイクルやより速いリリースで)。
ビジネスクリティカルなワークロード要件を定期的に確認する
定期的にエグゼクティブ スポンサーと会って要件を定義します。 これらのレビューにより、期待を一致させ、イニシアチブへの運用リソースの割り当てを確実にする機会が提供されます。
Power Platform の促進
Power Platform は、安全設計の文化と方法論に基づいて構築されています。 文化と方法論はどちらも、 Microsoftの業界をリードする セキュリティ開発ライフサイクル (SDL) と 脅威モデリング の実践を通じて継続的に強化されています。
脅威モデリングのレビュー プロセスにより、設計段階で脅威を特定し、軽減し、検証して、軽減されたことを確認します。
脅威モデリングでは、継続的かつ定期的なレビューを通じて既に実施されているサービスへのすべての変更も考慮されます。 STRIDE モデル に依存することで、安全でない設計に関する最も一般的な問題に対処することができます。
MicrosoftのSDLは、 OWASPソフトウェア保証成熟度モデル (SAMM) と同等です。 どちらも、安全な設計が Web アプリケーションのセキュリティに不可欠であるという前提に基づいて構築されています。
詳細については、OWASP リスクの上位 10:Power Platform での軽減策を参照してください。
例
この例は、セキュリティ ベースラインを確立するためのレコメンデーションで確立された情報技術 (IT) 環境に基づいています。 このアプローチにより、さまざまな IT シナリオでの脅威の状況を幅広く理解できます。
開発ライフサイクルのペルソナ。 開発ライフ サイクルには、開発者、テスター、最終ユーザー、管理者など、多くの関係者が関与します。 これらはすべて侵害される可能性があり、意図的に作成された脆弱性や脅威によって環境が危険にさらされることがあります。
潜在的な攻撃者。 攻撃者は、脆弱性を探り、攻撃を開始するために、いつでも簡単に使用できるさまざまなツールを検討します。
セキュリティコントロール。 脅威分析の一環として、ソリューションに使用する Microsoft、Azure、 Power Platform セキュリティ サービスと、それらのソリューションの有効性を特定します。
ログ収集。 Azureリソースや オンプレミスの コンポーネントなど、ワークロードに含まれるリソースやその他のコンポーネントからのログは、開発されたソリューションの動作を理解し、初期の脆弱性を捕捉できるように、Purviewに送信される場合があります。 Power Platform Application Insights Microsoft
セキュリティ情報 イベント管理 (SIEM) ソリューション。 Microsoft Sentinelはソリューションの初期段階でも追加できるため、脅威や脆弱性を軽減するための分析クエリを構築し、実稼働時のセキュリティを予測できます 保護。
関連情報
- STRIDEモデル
- 脅威モデリング
- Power Platform セキュリティに関するよくある質問
- Microsoft アイデンティティプラットフォーム
- セキュリティ開発ライフサイクル
- Azure AD 継続的なアクセス評価
- 環境
- Azure DDoS保護
- Microsoft Intuneのコンプライアンス ポリシー設定
セキュリティ チェックリスト
完全なレコメンデーションのセットを参照してください。