【入門編】 OWASP Top 10:2021 A04:2021-Insecure Designの脅威モデリング – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！日々の開発やインフラの構築、本当にお疲れ様です。

セキュリティの世界に足を踏み入れたばかりの頃って、専門用語が次から次へと出てきて、「一体どこから手を付けたらいいんだろう……」と途方に暮れてしまいますよね。教科書を開けば「暗号化が〜」「STRIDEが〜」と難解な言葉のオンパレードで、思わずそっとタブを閉じたくなる気持ち、よく分かります。

でも、安心してください。セキュリティの本質というのは、実は私たちが普段の生活の中で何気なくやっている「防犯対策」とまったく同じなんです。

今回は、設計の段階からセキュリティの穴を見つけ出す「脅威モデリング」という手法と、データの安全を守る「暗号（共通鍵と公開鍵）」の使い分けについて、身近な例えを交えながら一歩ずつ優しく紐解いていきたいと思います。一緒に楽しく学んでいきましょう！

—

1. 家の設計図に例える「インセキュア・デザイン（A04）」の恐怖

OWASP Top 10という、Webアプリケーションの脆弱性ランキングをご存知でしょうか？その中にある「A04:2021-Insecure Design（安全ではない設計）」という項目は、新米のエンジニアだけでなく、ベテランでもうっかりハマりやすい落とし穴です。

これって、例えるなら「頑丈な鉄のドアをつけたのに、窓の鍵をかけ忘れていたり、そもそも設計図の段階で『泥棒が屋根から侵入できる』ことを見落としていた状態」なんです。

どれだけプログラムのコードを綺麗に書いても、どれだけ高価なセキュリティツールを導入しても、「そもそも設計が間違っていたら、泥棒は簡単に侵入できてしまう」のですよね。これがインセキュア・デザインの恐ろしいところです。

STRIDEモデルで「泥棒の目線」になってみる

設計段階でセキュリティの穴を見つけるために、セキュリティのプロたちは「STRIDE（ストライド）」というフレームワークを使います。難しそうな名前ですが、要するに「泥棒がどんな手口を使うか」を6つの視点に分けてチェックするリストです。

成りすまし (Spoofing): 他人の合鍵を作る、または他人の顔写真のマスクをかぶって家族のふりをして入ってくる。
改ざん (Tampering): 郵便受けに届いた手紙の中身をこっそり書き換える。
否認 (Repudiation): 「そんなもの受け取っていない！」と、郵便の受領をシラを切る。
情報漏洩 (Information Disclosure): 鍵の置き場所を書いたメモを玄関の表に貼っておく。
サービス妨害 (Denial of Service): 玄関のドアの前に大量の荷物を積み上げて、家族が外に出られなくする。
権限昇格 (Elevation of Privilege): 子供部屋の鍵だけを開けるついでに、ちゃっかり親の書斎の合鍵も作ってしまう。

このように、「自分たちのシステムにはどこに隙があるだろう？」と泥棒の目線になって設計図をチェックすることを、「脅威モデリング」と呼びます。

—

2. 秘密を守るための「暗号」の基本：共通鍵と公開鍵の使い分け

さて、設計図が安全に描けたら、次は「データをどうやって守るか」というお話です。ここで登場するのが、共通鍵暗号と公開鍵暗号（楕円曲線暗号やRSAなど）です。

これも身近な例えで考えてみましょう。

共通鍵暗号（例：金庫と全く同じ鍵）

共通鍵暗号（代表例が AES です）は、「施錠する鍵と、開錠する鍵がまったく同じ1つの鍵」です。

メリット: 処理スピードがものすごく速い！大量のデータをパパッと暗号化・復号するのに最適です。
デメリット: その「たった1つの鍵」を、通信する相手にどうやって渡せばいいのかという「鍵の受け渡し問題」が発生します。もし郵送中に鍵をスリに盗まれたら、おしまいですよね。

公開鍵暗号（例：南京錠とマスターキー）

公開鍵暗号（RSA や ECC（楕円曲線暗号） など）は、鍵が2つペアになっています。

鍵の仕組み: 誰に配ってもいい「施錠専用の鍵（公開鍵）」と、自分だけが絶対に肌身離さず持っている「開錠専用の鍵（秘密鍵）」のペアです。
例え: 誰でも街中で自由に使える「開けられない南京錠（公開鍵）」をみんなに配ります。みんなはその南京錠で大事な手紙を入れてパチンとロックし、あなたに送ります。あなたに届いた手紙は、あなただけが持っている「秘密鍵」でしか開けられません。
メリット: 鍵を安全に渡す必要がないので、インターネットの初期通信（HTTPS通信など）にぴったりです。
デメリット: 共通鍵に比べて計算が複雑で、処理に時間がかかります。

現場での賢い使い分け：「ハイブリッド暗号」

実際のシステム（Webサイトなど）では、この2つを組み合わせて使っています。
1. 最初の一歩（挨拶の部分）だけは、安全に通信するために公開鍵暗号を使って「共通の合言葉（セッションキー）」をこっそり共有します。
2. その後は、スピードの速い共通鍵暗号（AESなど）に切り替えて、ザクザクとデータをやり取りします。

この仕組みがあるおかげで、私たちは安全かつ快適にネットショッピングを楽しめるんですね。

—

3. 実装の現場で：セキュアな設計をコードに落とし込む

では、ここからは「設計と暗号」を意識した具体的なコード例を見ていきましょう。
今回は、Webアプリケーションで機密データを安全に扱う際のPHP（Laravel風のイメージ）を例に取ります。

生のタグや脆弱なコードをそのまま書くのは避け、必ず安全な関数やパラメータを設定しましょう。

<?php
/**
 * セキュアなデータ暗号化のサンプル実装
 * 共通鍵暗号（AES-256-GCM）を用いた機密情報の保護
 */

class SecureDataHandler 
{
    // 暗号化アルゴリズムの定義（AESの最新かつ安全なモードであるGCMを使用）
    private string $cipher = 'aes-256-gcm';
    private string $encryptionKey;

    public function __construct(string $secretKey)
    {
        // 鍵の長さが十分であるかチェック（設計段階での要件定義）
        if (mb_strlen($secretKey, '8bit') !== 32) {
            throw new \InvalidArgumentException('暗号化キーは32バイト（256ビット）である必要があります。');
        }
        $this->encryptionKey = $secretKey;
    }

    /**
     * データを安全に暗号化するメソッド
     */
    public function encryptData(string $plainText): string
    {
        // GCMモードでは、毎回異なる初期化ベクトル（IV / Nonce）を使用することが鉄則です
        $ivLength = openssl_cipher_iv_length($this->cipher);
        $iv = openssl_random_pseudo_bytes($ivLength);

        // 認証タグを受け取るための変数（データの改ざんを検知するために超重要！）
        $tag = '';

        // AES-256-GCMで暗号化を実行
        $cipherText = openssl_encrypt(
            $plainText,
            $this->cipher,
            $this->encryptionKey,
            OPENSSL_RAW_DATA,
            $iv,
            $tag,
            "", // 追加認証データ（AAD）が必要な場合はここに指定
            16  // タグの長さ（通常は16バイト）
        );

        if ($cipherText === false) {
            throw new \RuntimeException('暗号化処理に失敗しました。');
        }

        // IVと認証タグ、暗号文を結合してBase64エンコードして保存・送信する
        // （※設計時：IVやタグを保存し忘れると、二度と復号できなくなるので注意！）
        return base64_encode($iv . $tag . $cipherText);
    }
}

コードのポイント解説

ここで使っている AES-256-GCM という方式は、ただデータを読めなくするだけでなく、「データが途中で悪意ある第三者に書き換えられていないか（改ざん検知）」まで同時にチェックできる、現代のWeb開発における強い味方です。設計の段階で「どの暗号化アルゴリズムを使うべきか」を正しく選定することが、インセキュア・デザインを防ぐ第一歩になります。

—

4. インフラ・サーバー側での防御：セキュリティヘッダーの設定

設計や暗号化だけでなく、Webブラウザに対して「うちのサイトはこういうルールで安全に動いてね」と指示を出す「セキュリティヘッダー」の設定も忘れてはいけません。

例えば、NginxやApacheなどのWebサーバーの設定ファイルで、以下のようなヘッダーを付与します。

# Nginxでのセキュリティヘッダー設定例
server {
    listen 443 ssl;
    server_name example.com;

    # HTTP厳戒態勢（HSTS）：常にHTTPSでのアクセスを強制する
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # クリックジャッキング対策：自社サイトを他のサイトのiframeに埋め込まらせない
    add_header X-Frame-Options "DENY" always;

    # ブラウザのMIMEタイプ勝手推測（MIME-sniffing）を防ぐ
    add_header X-Content-Type-Options "nosniff" always;

    # コンテンツセキュリティポリシー（CSP）：信頼できるスクリプトの読み込み元を制限する
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-cdn.com;" always;
}

これらは、いわば「家全体の防犯カメラや自動ロックシステム」のようなものです。設計図の段階で「こういう防犯装置を組み込む」と決めておくことで、思わぬサイバー攻撃からアプリケーションを守ることができます。

—

おわりに：一歩ずつ、確実にセキュアなエンジニアへ

ここまで、脅威モデリングの考え方から、暗号の仕組み、そして実際のコードやサーバー設定まで見てきましたが、いかがでしたでしょうか？

「覚えることがたくさんあって大変そう……」と感じたかもしれません。でも、安心してください。セキュリティのプロたちも、最初からすべて完璧にできたわけではありません。

大切なのは、コードを書く前に「もし自分が泥棒だったら、どこから入るかな？」と一歩立ち止まって設計図を眺めるクセをつけることです。その小さな習慣の積み重ねが、あなた自身と、あなたが作るシステムを強力に守る盾になります。

焦らず、一歩ずつ、確実にセキュアな開発スキルを磨いていきましょう。応援しています！