安全でない設計（Insecure Design）とは？OWASP A04の概念・設計欠陥パターン・脅威モデリングで防ぐ実践ガイド

パスワードの保存方法を誤る、SQLを直接組み立てる——こういった「実装ミス」はコードを書き直せば直せます。しかし、そもそも「認証フロー全体の設計に抜け穴があった」「センシティブな処理にレート制限をかけることを設計段階で考えていなかった」という場合、コードのパッチではなく設計の見直しが必要になります。

OWASP Top 10 2021の第4位「安全でない設計（Insecure Design）」は、実装の問題ではなく設計そのものに起因する脆弱性を指します。修正コストが最も高く、インシデント発生後では取り返しがつきにくいカテゴリです。

この記事では、OWASP A04の定義・典型的な設計欠陥のパターン・脅威モデリングを使った予防策を、現場で使えるレベルで解説します。インフラエンジニアから開発者・情シス担当者まで、設計レビューの観点として活用できる内容です。

安全でない設計（Insecure Design）とは？OWASP A04の定義

OWASP（Open Web Application Security Project）がまとめるWebアプリケーションの重大リスク一覧「OWASP Top 10」は2021年版で大きくリニューアルされ、それまでのリストに存在しなかった「Insecure Design（安全でない設計）」がA04として加わりました。

以前のOWASP Top 10は、具体的な脆弱性（SQLインジェクション・XSS等）の「実装上のミス」を中心に構成されていました。A04はその枠組みを一段上に広げ、「そもそも安全でない設計」から生まれる問題を独立したカテゴリとして定義しています。

OWASP A04が指す設計上の問題には、次のようなものが含まれます。

・セキュリティコントロールが設計に組み込まれていない
・脅威モデリング（潜在的な攻撃シナリオの洗い出し）が行われていない
・参照アーキテクチャやセキュリティデザインパターンが使われていない
・ビジネスロジックの制約が設計段階で定義されていない

A04の本質は「実装が正しくても、設計に欠陥があれば安全にならない」という点にあります。コードを丁寧に書いても、設計レベルの欠陥はパッチでは修正できません。

【整理】A04と他のOWASP項目との違い

「設定ミス」を扱うA05（セキュリティミスコンフィグレーション）は、正しい設計のシステムを誤った設定でデプロイしたケースを指します。一方、A04は「正しく設定・実装されたとしても、設計自体が問題」という状況です。たとえばパスワードリセット機能に「秘密の質問方式」を採用している場合、実装がどれだけ堅牢でも、その設計方針そのものが弱いためリスクが残ります——これがA04の典型です。

なぜ「実装バグ」より修正コストが高いのか

バグは通常、コードの特定箇所を修正するだけで対処できます。しかし設計の欠陥は、システム全体のアーキテクチャに関わるため、修正には次のようなコストが伴います。

・影響範囲の広さ: 設計に根ざした問題は複数のモジュール・機能にまたがって現れる
・リグレッションリスク: 設計を変えると既存の正常動作が壊れる可能性がある
・開発工程の大幅な手戻り: 要件定義・設計・実装・テストをやり直す場合がある
・本番リリース後の発覚: 攻撃者に発見されるまで問題に気づかないことが多い

一般的には、設計段階で発見した問題を1の修正コストとすると、リリース後に攻撃で発覚した場合は数十倍の対応コストになるとも言われています。この観点から、A04は「早期発見」が最も効果的な対策です。セキュアコーディングの原則がコードレベルの防線であるのに対し、A04対策は設計段階から始まります。

安全でない設計の典型的なパターン

1. レート制限・リソース制限の欠如

レート制限とは、「一定時間内に同一ユーザー・IPからリクエストできる回数の上限」を設けることです。これが設計段階で考慮されていないと、次のリスクが生まれます。

・クレデンシャルスタッフィング（漏洩済みID/パスワードの大量試行）
・SMSワンタイムパスワードの総当たり攻撃
・APIエンドポイントを使った情報の列挙（ユーザーIDの存在確認等）

想定例として: 4桁のSMS認証コードに試行制限がない設計だった場合、10,000通りのコードをスクリプトで送信すれば理論上突破できます。設計段階で「N回失敗したらロック」「再送間隔の最低保証」を要件に含めることが必要です。

2. 難読化による安全性の誤信

「内部だけで使うURLだから認証不要」「そのパスを知っている人だけがアクセスできる」という設計思想は、”Security through obscurity（難読化による安全性）”と呼ばれます。URLや識別子を推測しにくくするだけでは、アクセス制御の代替にはなりません。

セキュリティは「隠しているから安全」ではなく「アクセス制御が正しく機能しているから安全」でなければなりません。OWASP A01（アクセス制御の不備）と並んで、この誤信が原因のインシデントは後を絶ちません。

3. ビジネスロジックの欠陥

EC系システムやSaaSでは、業務フロー上のルール（ビジネスロジック）が設計時に不完全なことがあります。

・クーポンの重複使用が可能な設計
・カートに負の数量を入力すると金額がマイナスになる
・決済後の注文内容を変更できるAPIが残っている

これらは「コードが正しく動いている」状態でも悪用可能です。自動スキャンツールでは発見が困難で、設計レビュー段階での「ビジネスルールの明文化」と「悪用ケースの洗い出し」が唯一の対策です。

4. 過剰なデータ保持と不要なデータアクセス

設計段階でデータの保持期間・アクセス範囲を定義しないと、後から次のような問題が発覚します。

・本来不要な個人情報がアプリケーションログに記録されている
・退会済みユーザーのデータが削除されずに残っている
・内部APIが必要以上の情報フィールドを返している（過剰なデータ露出）

「最小限のデータのみ収集・保持する」設計原則（データ最小化）を設計段階から組み込むことで防げます。個人情報保護法対応の観点からも、この設計判断は重要です。

5. 信頼境界の不明確さ

「このAPIは内部からしか呼ばれない前提なので認証不要」という設計で、後にそのAPIがインターネット経由でアクセス可能だったと判明するケースがあります。これが信頼境界の設計ミスです。

ゼロトラストの観点では「内部ネットワークからのアクセスでも信頼しない」が原則です。設計段階でネットワーク境界と認証の要否を明文化し、「このエンドポイントは誰からでも呼べる状態が想定内か」を問い続けることが重要です。

脅威モデリングで設計段階から防ぐ方法

OWASP A04に対する最も効果的な対策は「脅威モデリング」です。脅威モデリングとは、設計段階でシステムへの攻撃シナリオを洗い出し、設計変更で対処する手法です。コードを書く前に行うことで、修正コストを大幅に下げられます。

1. STRIDE分析の活用

STRIDEは、脅威の種類を6つに分類してシステムを評価するフレームワークです。各頭文字が脅威の種類を示します。

設計段階でSTRIDEの各項目に答えられない箇所がある場合、A04に該当するリスクが潜んでいる可能性があります。

2. データフロー図（DFD）で信頼境界を可視化する

DFD（データフロー図）はシステム内でデータがどのように流れるかを可視化する設計ドキュメントです。脅威モデリングでは、DFDの各「信頼境界（異なる権限・ネットワーク境界をまたぐ箇所）」を起点に脅威を洗い出します。

・外部からの入力はすべてバリデーションされているか
・信頼境界を越えるときに認証・認可が行われているか
・センシティブデータはどこで暗号化・マスキングされているか

DFDを1枚書くだけでも、「このデータはどこを通っているのか」が可視化され、設計の見落としが見つかることがあります。

3. 悪用ケース（Misuse Case）の定義

要件定義で「ユーザーが〇〇できる」というユースケースを洗い出すのと並行して、「攻撃者がこの機能をどう悪用できるか」という悪用ケースも定義します。

# ユースケース例
ユーザーはパスワードをリセットできる

# 悪用ケース（Misuse Case）
攻撃者は対象ユーザーのメールアドレスを入力してリセットリンクを大量送信できる
→ 対策: 送信頻度の制限・CAPTCHAの導入を設計に含める

攻撃者はリセットリンクのトークンを推測または総当たりで試行できる
→ 対策: トークンの十分な長さ・有効期限・使い捨て設計を要件に明記する

中小企業でも今日からできること

大規模なシステムでなくても、A04の考え方は中小企業のWebシステムや業務ツールにも当てはまります。情シス1人体制でも実践できるアプローチを紹介します。

1. 既存システムの設計見直しチェック

・認証が不要なAPIエンドポイントが存在していないか確認する
・パスワードリセット・メールアドレス変更などの重要操作に試行回数制限があるか確認する
・アプリケーションログに個人情報（メールアドレス・電話番号等）が記録されていないか確認する
・退会・削除処理でデータが本当に消えているか確認する（物理削除か論理削除か）

2. 新規開発・外部委託時の要件明示

外部ベンダーに開発を委託する際も、A04の観点を要件仕様書に含めることが重要です。

・「セキュリティ要件」を機能要件と同列に記載する
・認証・認可方式を設計書に明示させる
・レート制限・入力バリデーション・ログ設計を納品物に含める
・受入テストにセキュリティ観点のテストケースを含める

セキュリティバイデザインの考え方を外部委託仕様書に盛り込むことで、納品後に発覚する設計欠陥を減らせます。

3. WordPressやSaaSを使う場合の注意点

自社開発ではなくWordPressや市販SaaSを使っている場合も、A04の観点は必要です。

・管理者画面のURLが推測しやすい位置にあり認証が薄い設定になっていないか
・不要なユーザー登録機能が有効になっていないか
・APIキーや管理者権限が過剰に付与されたサービスアカウントが存在していないか

よくある誤解と注意点

【誤解1】「A04はOWASPの新しい概念だから自分には関係ない」

OWASP Top 10 2021で新設されたカテゴリですが、設計レベルの問題自体は以前から存在していました。「これまで名前がなかった」だけです。Webシステムやアプリケーションを運用するすべての組織が対象となります。

【誤解2】「ペネトレーションテストで発見できるはず」

設計レベルの欠陥はペネトレーションテストで発見できる場合とできない場合があります。特にビジネスロジックの欠陥は、テスターがその業務フローを深く理解していないと見逃されます。「ペネトレーションテストに通ればA04は問題なし」とはなりません。

【誤解3】「設計書を作れば対策できる」

設計書があっても、そこにセキュリティの観点が含まれていなければ意味がありません。A04の対策は「セキュリティ観点を持った設計」であり、形式的なドキュメント作成とは異なります。脅威モデリングや悪用ケースの定義が設計書に含まれていることが重要です。

本記事のまとめ

「安全でない設計」は目に見えにくい脆弱性です。コードスキャンや脆弱性スキャナーでは検出できず、設計段階での意識的な取り組みだけが有効な防御手段となります。新規開発のたびに「どう使われるか」だけでなく「どう悪用されるか」を問う習慣が、OWASP A04への最大の対策です。