脅威モデリング：アーキテクチャ、攻撃シナリオ、対策

Sytance · 更新日 2026年9月15日

脅威モデリングは、製品がどのように攻撃され得るかを体系的に特定し、リスクを低減する対策を選ぶ方法です。分析は製品アーキテクチャから始め、攻撃がどのように成功し得るか、何に影響するか、提案した保護策をどのように確認するかを説明します。

製品バージョンと導入環境

脅威モデルは、特定の製品バージョンと導入環境に適用されます。インターネットに接続されたゲートウェイと、同じゲートウェイを隔離された保守ネットワークで使用する場合とでは、エントリーポイントや運用上の前提条件が異なる可能性があります。

アーキテクチャ、開発、製品の使用方法、セキュリティに詳しい人を参加させます。セッションの前に、通常の運用を最初から最後まで説明できる資料を十分に集めてください。

データフロー図（DFD）は、外部エンティティ、プロセス、データストア、データの移動を示します。信頼境界は、信頼または権限が変化する地点を示します。たとえば、ブラウザーとAPI、2つのオペレーティングシステムアカウント、デバイスとリモートサービスの間に存在します。

各フローに方向、データの説明、保護メカニズムを示してください。複数のサービスでIDと権限が異なる場合、「クラウド」というラベルの箱だけでは情報が不足します。その違いによって分析が変わるときは、箱を分けてください。

産業用ゲートウェイの例では、オペレーターのブラウザー、ゲートウェイ管理API、ローカル構成ストア、ローカルコントローラー、テレメトリーサービス、更新サービスから始めます。管理接続とテレメトリー接続にはTLSを示します。実装が確認されるまでは、更新署名の検証を提案中の対策として扱います。

STRIDEは、脅威をなりすまし、改ざん、否認、情報漏えい、サービス拒否、権限昇格の6つに分類します。これらのカテゴリを使い、関連する各プロセスとフローについて検討してください。カテゴリ名だけでは攻撃の説明になりません。

たとえば、読み取り専用アクセス権を持つユーザーが、構成変更リクエストを管理APIに直接送信します。APIがログイン状態だけを確認し、操作権限を確認しない場合、そのユーザーはゲートウェイの構成を変更できます。この例では、攻撃者、エントリーポイント、欠落している対策、影響を特定できます。

各シナリオを、図の関連するインターフェース、プロセス、またはフローに関連付けます。攻撃条件または対策が異なるシナリオは、分けて分析する必要があります。コントローラーのインターフェースの認証など、条件が不明な場合は確認事項として記録してください。

リスクの優先順位は、攻撃者に必要なアクセス権と能力、成功可能性、製品への影響によって決まります。合意したリスク評価手法により、判断の一貫性を保てます。スコアの根拠を記録すれば、他の人がその判断をレビューできます。

チームが実装できる対応を選んでください。構成変更の例では、すべての書き込み操作でAPIが呼び出し元の権限を確認するよう求めます。担当者、対象リリース、対策の有効性を示す確認方法を定めます。

既存のTLSは通信接続を保護しますが、ログイン済みユーザーが構成を変更する権限を持つことを証明するものではありません。対策が阻止すべき具体的な攻撃手順に照らして確認してください。チームが残留リスクを受容する場合は、その理由と判断権限を持つ人を記録します。

提案中の対策と検証済みの対策は異なる状態です。実装された対策を、関連する変更と検証結果に関連付けてください。APIの例では、読み取り専用ユーザーとして書き込みリクエストを送り、拒否されることと構成が変更されないことの両方を確認します。

インターフェース、権限、コンポーネント、導入環境、更新メカニズムが変わったときは、モデルを見直してください。新しい脆弱性情報によって以前の前提条件が無効になる場合もあります。判断が適用されたリリースをチームが説明できるよう、以前のモデルも保持します。