Insecure Designは「コード」ではなく「思考」の欠陥である：脅威モデリングによる防御的設計の深淵
多くのエンジニアが「セキュアコーディング」という言葉に踊らされ、WAFや最新のライブラリに頼り切っている間に、攻撃者はその遥か上流、つまり「設計図」の欠陥を突いている。OWASP Top 10の筆頭に躍り出た「Insecure Design」は、パッチで埋められる脆弱性ではない。これは、システムが意図した通りに動くことと、攻撃者の思惑通りに動くことの境界線を見誤った結果だ。
今日は、小手先の対策ではなく、STRIDEモデルを武器に、インフラの深淵からプロンプトインジェクションのガードレイルに至るまで、我々セキュリティアーキテクトが「何を考えなければならないか」を語ろう。
—
1. STRIDEの再定義：プロトコルとメモリの視点から
STRIDEは教科書的なフレームワークだが、これを実戦で活かすには、より低レイヤの観点が必要だ。
- Spoofing (なりすまし): APIゲートウェイでJWTを検証するだけでは不十分だ。TLSハンドシェイク時にクライアント証明書（mTLS）を強制し、L7の認証とL4のトランスポート層で二重のアイデンティティを確立せよ。
- Tampering (改ざん): 通信プロトコルのパケット構造に注目せよ。例えば、gRPCのバイナリフレームを解析し、意図しないフィールドが含まれていないか、あるいはシリアライザの脆弱性（例：FastjsonやJacksonのポリモーフィック型逆シリアライズ）を突く入力をゲートウェイで弾く設計が必要だ。
- Information Disclosure: メモリリークを伴う例外ハンドリングは致命的だ。スタックトレースが応答に含まれることは論外だが、ヒープダンプから秘密鍵が漏洩しないよう、メモリのゼロクリア（
mlockやmemzero_explicit）を徹底するアーキテクチャが求められる。
2. 生成AI時代の脅威モデリング：ガードレイルの設計
現代の設計レビューには、LLMという「ブラックボックス」の考慮が不可欠だ。プロンプトインジェクションは、従来のSQLインジェクションの論理的進化形に過ぎない。
我々が実装すべきは、「入力のサンドボックス化」と「出力の検証レイヤ」の分離だ。
LLMへの入力（プロンプト）に対するガードレイルの簡易実装イメージ
def guardrail_input(user_input):
# 1. 入力の正規化（エスケープではない、構造の強制）
normalized_input = sanitize_and_tokenize(user_input)
# 2. 意図しない指示の検出（プロンプトインジェクション検知）
# 構造化されたスキーマ以外を拒否する
if not is_conforming_to_schema(normalized_input, expected_schema):
raise SecurityException(“不正な指示構造を検知”)
return normalized_input
3. 出力に対するフィルタリング（PII漏洩防止）
def guardrail_output(raw_response):
# 出力から機密情報や、LLMが生成した悪意あるコードを抽出・遮断する
return scan_for_sensitive_data(raw_response)
この設計の核心は、LLMを信頼せず、入力と出力の両端で「型」と「構造」を強制することにある。これがInsecure Designを回避する現代的なアプローチだ。
3. 耐量子暗号（PQC）への移行を見据えた設計
「今の暗号が解かれないから良い」という設計は、インフラの寿命が5年を超えるプロジェクトでは破綻する。現在、設計段階で意識すべきは「暗号アルゴリズムの抽象化」だ。
特定のライブラリにハードコードせず、暗号モジュールをインターフェース経由で呼び出す設計にせよ。将来、ポスト量子暗号（KyberやDilithiumなど）へ移行する際、コードベース全体を書き換えるのではなく、設定ファイルとプロバイダーの入れ替えだけで対応可能な「暗号の疎結合化」こそが、アーキテクトに求められる先見性である。
4. 現場の教訓：監査は「想定外」を追う
筆者が過去に担当した重大インシデントの多くは、開発者が「そんなことする人はいないだろう」と性善説に基づいた設計をした箇所に集約される。
脅威モデリングのセッションで、私はあえて開発チームに問う。「このAPIを、ブラウザからではなく、攻撃者がPythonスクリプトで100万回叩いたらどうなる？」と。
- レート制限の境界値: ユーザー単位ではなく、IPセグメント単位、あるいはセッションIDのライフサイクル単位で動的にスロットリングを調整しているか？
- メモリの境界条件: 巨大なJSONペイロードをパースする際、メモリオーバーフローでサービスが停止する（DoS）リスクを、バッファ制限で防いでいるか？
結論：設計の美しさは、防衛の堅牢さに宿る
セキュリティとは、製品が完成してから「付与する機能」ではない。設計図の段階で、攻撃者が通るであろうすべての道に、論理的なバリケードを築く作業だ。
コードを一行書く前に、脅威モデルを描け。STRIDEで思考し、最悪のシナリオを設計に組み込め。それこそが、技術負債ならぬ「セキュリティ負債」を極限まで減らすための、我々エンジニアの唯一にして最大の責務である。
次回のブログでは、具体的に「CI/CDパイプラインに組み込むべき静的解析の境界線」について、より実践的なツールチェーンの話を深掘りしよう。諸君のコードが、堅牢であることを願っている。
コメント