新規システムの設計レビューやアーキテクチャ検討会で「セキュリティ観点も見ておいて」と言われたとき、何から手を付けるか困った経験はないでしょうか。
本記事は、マイクロサービスやAPI基盤の設計を担うアーキテクトやリードエンジニアに向けて、STRIDE（脅威モデリングの分類手法）を設計判断にどう組み込むかを整理します。STRIDEは1999年にMicrosoftのLoren KohnfelderとPraerit Garg が考案した手法で、脅威を6種類に分類して漏れなく検討するためのチェックリストのような枠組みです。
設計フェーズでSTRIDEを使う最大の利点は、脆弱性診断やペネトレーションテストのような「実装後の発見」ではなく、「実装前の予防」に効くことです。アーキテクチャ図の段階で弱点を潰せれば、後工程での手戻りコストを大きく下げられます。
STRIDEの6分類と対応する非機能要件
STRIDEという名前は6つの脅威カテゴリの頭文字から来ています。それぞれが侵害するセキュリティ特性が1対1で対応している点が、この手法の使いやすさの理由です。
- Spoofing（なりすまし）→ 認証（Authentication）の破綻。盗まれたOAuthトークンで別ユーザーを装う攻撃が典型例です
- Tampering（改ざん）→ 整合性（Integrity）の破綻。API リクエストやDB レコード、通信中のメッセージが不正に書き換えられます
- Repudiation（否認）→ 否認防止（Non-repudiation）の破綻。ユーザーが「その操作はしていない」と主張しても証拠がない状態です
- Information Disclosure（情報漏えい）→ 機密性（Confidentiality）の破綻。マルチテナントAPIが他社の顧客データを返してしまうケースです
- Denial of Service（サービス拒否）→ 可用性（Availability）の破綻。過剰なリクエストで正規利用者がサービスを使えなくなります
- Elevation of Privilege（権限昇格）→ 認可（Authorization）の破綻。一般ユーザーがロールクレームを書き換えて管理者エンドポイントに到達する例です
この対応関係を覚えておくと、設計レビューの際に「このコンポーネントは可用性の要件を満たしているか」という非機能要件のチェックが、自然と「DoS耐性はどう設計されているか」というSTRIDEの問いに変換できます。
データフロー図に当てはめて考える手順
STRIDEは単体で使う分類表ではなく、データフロー図（DFD、システム内のデータの流れを図示したもの）に対して適用するのが基本の使い方です。
手順は次の3段階です。まず対象システムを「プロセス」「データストア」「データフロー」「外部エンティティ」「信頼境界（Trust Boundary）」に分解します。信頼境界とは、権限や信頼レベルが変わる境目のことで、たとえば「インターネットからロードバランサーへ入る箇所」や「アプリ層からDB層へ渡る箇所」が該当します。
次に、各要素に対して6つの脅威カテゴリを総当たりで問いかけます。たとえばAPIゲートウェイという「プロセス」に対しては、Spoofing（偽装リクエストは通るか）、Tampering（リクエストボディの改ざんは検知できるか）、DoS（レート制限はあるか）を順に確認します。
最後に、見つかった脅威それぞれに対して既存の対策で十分かを判定し、不足があれば設計変更のバックログに積みます。マルチテナントAPIの例で言うと、テナントIDをリクエストボディに含める設計はTamperingのリスクが高く、JWTのクレームからサーバー側で強制的に取得する設計に変更する、といった判断がここで生まれます。
他の脅威モデリング手法との位置づけ
STRIDEと並んで語られる手法に、リスクの大きさを数値化するDREAD（Damage、Reproducibility、Exploitability、Affected users、Discoverabilityの頭文字）や、攻撃者視点で攻撃木を作るAttack Treeがあります。
STRIDEは「どんな種類の脅威があるか」を網羅的に洗い出す発見フェーズに強く、DREADは洗い出した脅威の優先順位付けに向いています。実務では、STRIDEで脅威をリストアップしたあとにDREADや共通指標であるCVSS（共通脆弱性評価システム）でスコアリングし、対応順序を決める組み合わせがよく使われます。
OWASP（Webアプリケーションセキュリティの国際コミュニティ）が公開するThreat Modeling Cheat Sheetでも、STRIDEはDFDベースの手法として、PASTA（攻撃者中心のリスク分析手法）と並んで紹介されています。どちらを選ぶかは、開発チームの規模や脅威モデリングにかけられる時間で判断する形になります。小規模チームで設計レビューに1〜2時間しか取れないなら、STRIDEの6分類を総当たりするだけでも十分な効果があります。
今日から設計レビューに組み込む方法
実際に自分のプロジェクトに適用できるかを判断するには、まず対象システムのアーキテクチャ図を確認してください。すでにDFDやシーケンス図があるなら、それを流用できます。
図がない場合は、主要なコンポーネント（APIゲートウェイ、認証サービス、DB、キャッシュ層など）と、それらの間のデータの流れを箱と矢印で書き出すところから始めます。信頼境界（インターネットとの境目、社内ネットワークとクラウドの境目など)を点線で囲むと、どこが攻撃の入口になりやすいかが見えやすくなります。
各コンポーネントに対して、次の6つの問いを順に当てます。
1. このコンポーネントになりすませるか(Spoofing)
2. やり取りするデータは改ざんされ得るか(Tampering)
3. 操作の実行者を後から追跡できるか(Repudiation)
4. 権限のない相手に情報が見えないか(Information Disclosure)
5. 過負荷や障害でサービスが止まらないか(Denial of Service)
6. 意図しない権限に到達できないか(Elevation of Privilege)洗い出した脅威は、対応済み・対応予定・許容(リスクを受け入れる)の3種に分類して記録します。対応予定に振り分けたものはそのままアーキテクチャの技術的負債として扱い、他の負債と同じ優先順位付けの土台に乗せるのが現実的です。
すでにレビュー体制がある組織では、既存の設計レビューのテンプレートにこの6項目のチェックリストを1セクション追加するだけで導入できます。Microsoftが提供する無料ツール「Microsoft Threat Modeling Tool」はDFDを描きながらSTRIDEの脅威を自動的に提示してくれるので、手作業での総当たりが負担なら試す価値があります。
まとめ
STRIDEは6種類の脅威分類と、それぞれが対応する非機能要件(認証・整合性・否認防止・機密性・可用性・認可)を結びつけて考える枠組みです。
実践する際は、既存のアーキテクチャ図やシーケンス図をベースに信頼境界を洗い出し、各コンポーネントに6つの問いを当てるところから始めてみてください。
見つかった脅威は対応済み・対応予定・許容の3分類で管理し、対応予定分は技術的負債の一部としてバックログに載せておくと、後工程での手戻りを防ぎやすくなります。