「家を建てた後に鍵を変えるのは無理がある」— 安全でない設計（Insecure Design）を防ぐための脅威モデリング入門
こんにちは。セキュリティの世界で泥臭いインシデントと向き合い続けている筆者です。
今日は、プログラミングを始めたばかりの方や、セキュリティの第一歩を踏み出した皆さんに、「安全でない設計（Insecure Design）」という、ちょっと耳慣れないけれど実は一番怖い落とし穴についてお話しします。
よくある誤解として、「セキュリティは、コードを書き終えた後にチェックすればいい」というものがあります。ですが、これを家の建設に例えるとどうでしょう？ 「頑丈な家を建てたあとに、窓が全部地面にあることに気づいて、あとから格子の鉄柵を必死で溶接する」ようなものです。これでは見た目も悪いし、何よりコストが莫大ですよね。
セキュリティも同じです。設計図の段階で「どこから泥棒が入るか？」を考えること。 これが「脅威モデリング」の正体です。一緒に一歩ずつ学んでいきましょう！
—
1. そもそも「安全でない設計」って何？
実装のミス（バグ）とは違い、「設計そのものの欠陥」を指します。
例えば、銀行のアプリで「送金ボタンを連打すると、残高がマイナスになっても無限に送金できてしまう」という仕様があったとします。コード自体は正しく動いていますが、「ビジネスロジック（ビジネスのルール）」として破綻していますよね。
このように、プログラムの書き間違いではなく、「そもそもの仕組みが泥棒に優しい状態」になっていることを「安全でない設計」と呼びます。
—
2. 脅威モデリングで「泥棒の視点」をシミュレーションしよう
脅威モデリングは難しく考える必要はありません。以下の3つの質問を、企画段階のメモ帳に書き出すだけでOKです。
1. 何を守るの？（例：ユーザーの預金残高、個人の住所データ）
2. 誰が狙うの？（例：悪意のあるユーザー、競合他社、あるいはミスをした社内の人間）
3. どうやって侵入する？（例：ログイン画面を突破する？ サーバーの裏口を見つける？）
これを図に描くと、どこを重点的に守ればいいかが見えてきます。家の防犯と同じで、「玄関の鍵」だけでなく「裏口の勝手口」や「2階のベランダ」まで意識を向けるのがポイントです。
—
3. 実践！ビジネスロジックの欠陥を見つけるコツ
開発現場でよくある失敗の一つに、「信頼しすぎ」があります。
悪い例：クライアント側のチェックだけを信じる
例えば、Webサイトで「年齢制限」を設けるとき、HTMLの入力フォームだけで制限をかけて安心していませんか？
泥棒は、このHTMLを自分のパソコンで書き換えて、18歳未満でも送信してきます。「玄関の鍵が壊れているのに、ドアの前に『入るな』という張り紙をしている」のと同じ状態です。
良い例：サーバー側で必ず「再検証」する
サーバー側では、送られてきたデータが本当に正しいか、常に疑ってください。
サーバー側の処理（安全な設計）
def process_payment(user_age, amount):
# クライアントが何と言おうと、サーバー側で再度チェックする！
if user_age < 18:
return "エラー：未成年には販売できません"
# 決済処理を実行
execute_transaction(amount)
---
4. なぜ「防御ヘッダー」が必要なの？
Webサイトを守るための「防御ヘッダー」というものがあります。これは、「家を建てる際に、あらかじめ備え付けの警備システムを設置しておく」ようなものです。
例えば、`Content-Security-Policy (CSP)` というヘッダーを設定しておくと、ブラウザに「このサイトは外部の怪しいスクリプトを実行してはいけないよ」と指示できます。
サーバー設定のサンプル（Apache/Nginx等の設定）:
信頼できない外部サイトからのスクリプト実行をブロックする
Header set Content-Security-Policy “default-src ‘self’;”
クリックジャッキング（偽ボタンへの誘導）を防ぐ
Header set X-Frame-Options “DENY”
ブラウザの勘違いによるセキュリティ低下を防ぐ
Header set X-Content-Type-Options “nosniff”
これらを設定しておくだけで、万が一プログラムの一部に隙があっても、ブラウザ側が「それは怪しい動きだから止めるよ！」と守ってくれます。
—
最後に：完璧を目指さなくていい
セキュリティは「終わりのない旅」です。完璧な設計図なんてこの世にはありません。でも、「もし自分が泥棒だったら、どこから入るかな？」と、設計図を眺めながら少し立ち止まるだけで、あなたの作るアプリケーションは格段に強固になります。
まずは、自分の作っている機能の「一番大事なところ（鍵）」がどこにあるのかを確認することから始めてみてください。それが、あなたを守り、ユーザーを守る、最高の一歩になります。
また現場でお会いしましょう！応援しています。
コメント