暗号化の失敗（Cryptographic Failures）とは？OWASP Top 10第2位の脆弱性と対策をわかりやすく解説

「うちのシステムでは暗号化しているから大丈夫」——そう思っていても、暗号化の実装が誤っていれば、攻撃者にとっては格好の標的になりかねません。

OWASP Top 10 2021では「Cryptographic Failures（暗号化の失敗）」が第2位に位置付けられています。フィッシングや不正ログインといった派手な攻撃と違い、暗号化の不備は「長期間気づかれない」「気づいたときには大量の機密情報が盗まれている」という厄介な特性を持ちます。

この記事では、暗号化の失敗とはどういった脆弱性なのか、現場でよく見られるパターンから具体的な防御手順まで、現場目線で解説します。

暗号化の失敗（Cryptographic Failures）とは？

「暗号化の失敗」とは、機密データを扱うシステムにおいて、暗号化の適用が不十分・誤っているために情報漏洩につながる脆弱性の総称です。以前のOWASP Top 10（2017年版）では「機密データの露出（Sensitive Data Exposure）」と呼ばれていたカテゴリが、2021年版でより根本原因に着目した「Cryptographic Failures」に改名されました。

「暗号化すればいい」という誤解が多いのですが、実際には「どのアルゴリズムを使うか」「鍵をどう管理するか」「どのデータが機密かを正しく識別しているか」という3点すべてが正しくなければ意味がありません。

攻撃者は暗号化の穴を突いて、パスワードやクレジットカード番号、個人情報、セッショントークンなどを盗み出します。被害は金銭的損害だけでなく、個人情報保護法違反・信頼失墜・業務停止といった深刻な結果に直結します。

よくある「暗号化の失敗」パターン

1. 古い・弱い暗号化アルゴリズムの使用

MD5やSHA-1は現在「衝突攻撃」に対して脆弱であることが実証されています。また、DESや3DESも鍵長が不十分で現代の計算力では解読可能です。「昔から使っているから」という理由でこれらを使い続けているシステムは少なくありません。

・NG例: パスワードをMD5でハッシュ化して保存する
・NG例: DES/3DESでデータベースを暗号化する
・OK例: パスワードはbcrypt・Argon2・scryptを使う。データ暗号化はAES-256-GCMを使う

2. 鍵管理の不備

暗号化アルゴリズムが正しくても、鍵の管理が甘ければ意味がありません。よく見られる問題として、暗号鍵をソースコードにハードコードしている、鍵を暗号化データと同じ場所（同一サーバー・同一ディレクトリ）に保存している、鍵のローテーション（定期更新）をまったく行っていない、といったケースがあります。

3. 機密データの平文転送

HTTPSを使っていない通信経路で、パスワードやセッショントークン、個人情報を送受信しているケースです。社内ネットワークだから大丈夫、と思いがちですが、内部ネットワークへの侵入後に盗聴される中間者攻撃のリスクがあります。HTTPSを使っていても、古いプロトコル（TLS 1.0・1.1）が有効になっている場合も同様の問題があります。

4. パスワードの不適切なハッシュ化

パスワードをプレーンテキスト（平文）で保存するのはもってのほかですが、単純なハッシュ（MD5やSHA-256）で保存していても、レインボーテーブル攻撃やブルートフォース攻撃でクラックされる危険があります。パスワード専用のハッシュ関数（bcrypt・Argon2）はコンピュータの計算時間を意図的に遅くすることで、この攻撃を困難にします。

5. 不要な機密データの保持

「必要ないのに機密データを長期保存している」ケースも暗号化の失敗に含まれます。保存していなければ漏洩しません。クレジットカードのCVVコードを保存すること自体がPCI DSS違反であるように、機密データは「最小限しか持たない」という設計原則が重要です。

具体的な防御手順

1. 処理すべき機密データを洗い出す

まず「自社のシステムがどの機密データを扱っているか」を棚卸しすることから始めます。パスワード、個人情報（氏名・住所・電話番号）、決済情報、健康情報、セッショントークンなどが対象です。扱うデータを把握せずに暗号化を考えることはできません。

2. 転送中データの暗号化（TLS 1.2以上）

すべての外部通信はHTTPS（TLS 1.2以上、推奨はTLS 1.3）を使います。古いプロトコルを無効化する設定例はこちらです。

# Nginxの場合 — TLS 1.0/1.1を無効化（/etc/nginx/nginx.confのhttpブロック内）
ssl_protocols TLSv1.2 TLSv1.3;  # 変更: 1.0/1.1を除外

# 古い暗号スイートを除外
ssl_ciphers HIGH:!aNULL:!MD5:!3DES;
ssl_prefer_server_ciphers on;

内部通信（マイクロサービス間・バックエンド間）も可能な限りTLSで保護します。「内部だから大丈夫」という油断が侵害時の横展開を容易にします。

3. 保存データの暗号化と鍵管理

機密データを保存する際はAES-256-GCMなど強力なアルゴリズムを使います。鍵管理のポイントは以下のとおりです。

・鍵はコードに書かない: 環境変数または専用の鍵管理サービス（AWS KMS・Azure Key Vault・HashiCorp Vault等）に格納する
・鍵とデータを分離: 暗号化されたデータと暗号鍵を同じ場所に置かない
・鍵のローテーション: 定期的（年1回以上）に鍵を更新するプロセスを設ける

4. パスワードはbcryptかArgon2でハッシュ化

パスワード保存には必ずパスワード専用のハッシュ関数を使います。PHPの例を示しますが、各言語に同等のライブラリがあります。

# PHP: パスワードのハッシュ化（推奨）
$hash = password_hash($password, PASSWORD_BCRYPT);
# または Argon2（PHP 7.2以降）
$hash = password_hash($password, PASSWORD_ARGON2ID);

# NG: 絶対にやってはいけない
$hash = md5($password);             # 弱い — 使用禁止
$hash = sha1($password);            # 弱い — 使用禁止
$hash = hash('sha256', $password);  # パスワード用途には不適切

5. HTTPS設定の確認と証明書の自動更新

Let’s Encryptを使った証明書の自動更新を設定しておくことで、「期限切れによる通信の問題」を防げます。certbotを使った自動更新はcronやsystemdタイマーで定期実行させます。

# certbot の自動更新確認（ドライラン）
sudo certbot renew --dry-run

# cron で自動更新（/etc/cron.d/certbot 等に記載済みであることを確認）
0 12 * * * /usr/bin/certbot renew --quiet

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

大規模なシステム改修が難しくても、以下の対策は比較的すぐに取り組めます。

「どこから手をつければいいかわからない」という場合は、まず「HTTPS化されているか」と「パスワードの保存方法」の2点を確認することをお勧めします。この2つだけで、暗号化の失敗による被害リスクを大きく下げられます。

よくある誤解と注意点

誤解1: 「Base64エンコードは暗号化だ」
Base64は暗号化ではなくエンコード（データ形式の変換）です。誰でも即座に復元できます。機密データをBase64にしただけで「暗号化した」と思っているケースが実際に存在します。

誤解2: 「社内ネットワークは暗号化しなくていい」
侵入した攻撃者やマルウェアが内部ネットワークで通信を盗聴するリスクがあります。ゼロトラストの考え方では「内部だから信頼する」という前提を置きません。

誤解3: 「HTTPSにすれば全部OK」
HTTPSは転送中の暗号化であり、保存データの暗号化とは別の話です。DBに平文でパスワードを保存していれば、HTTPS関係なくDB漏洩時に丸見えになります。

誤解4: 「AES-128で十分では？」
現時点ではAES-128も解読されていませんが、将来の量子コンピュータへの備えとしてAES-256を使うことが推奨されています。新規開発ではAES-256-GCMを選択しましょう。

なお、暗号化に関する記述は変化が速い分野です。最新の推奨事項については、IPA（情報処理推進機構）やNISTの公式ガイドラインを定期的に確認することをお勧めします。

本記事のまとめ

「暗号化の失敗（Cryptographic Failures）」は、派手な攻撃技術ではなく「実装の誤り」「古いアルゴリズムの使い続け」「鍵管理の甘さ」によって引き起こされます。OWASP Top 10で第2位に位置付けられている理由はまさにここにあります。

・古い・弱いアルゴリズム（MD5・DES等）は使わない
・パスワードはbcryptまたはArgon2でハッシュ化する
・転送中はTLS 1.2以上を必須とし、1.0/1.1は無効化する
・暗号鍵はコードに書かず、専用の管理サービスや環境変数で管理する
・不要な機密データは最初から保持しない

完璧な暗号化は一度設定して終わりではなく、アルゴリズムの定期見直し・鍵のローテーション・証明書の更新といった継続的な運用が伴います。まずは自社システムの「パスワード保存方法」と「HTTPS設定」の2点から確認してみてください。姉妹サイトLinuxMaster.JPでは、Linuxサーバーの暗号化設定に関する実践的なコマンド解説も公開しています。あわせてご参照ください。