【入門編】 安全でない暗号アルゴリズム(DES/MD5/SHA-1)の特定と移行 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！セキュリティチームのエンジニアです。
日々の開発やインフラの管理、本当にお疲れ様です。「セキュリティの勉強を始めなきゃいけないけれど、専門用語ばかりで難しそう……」そんな風に感じていませんか？

今回は、システムの裏側でひっそりと使われている「古い暗号（レガシー暗号）」をテーマに、なぜそれが危ないのか、そしてどうやって新しい安全な仕組みにバトンタッチしていけばいいのかを、身近な例えを交えながら一歩ずつ優しく紐解いていきたいと思います。

難しく考えず、まずはコーヒーでも飲みながらリラックスして読んでいってくださいね！

—

1. 家の鍵で例える「暗号」の仕組みとレガシー暗号の危険性

セキュリティの話題でよく出てくる「暗号化」ですが、難しく考えず、私たちの身近な「家の鍵」に例えてみましょう。

あなたが大切な宝物をしまうために、頑丈なロッカーを作ったとします。

  • 昔の鍵（レガシー暗号 / DESやMD5など）： 昔の職人さんが作った、ちょっと作りが甘い合鍵でも簡単に開いてしまう鍵や、ピッキングに数秒で負けてしまうような古い錠前です。
  • 今の鍵（モダン暗号 / AES-GCMやSHA-256など）： 最先端の技術で作られ、特殊な工具を使っても絶対にピッキングできない、現代の頑丈なセキュリティロックです。

システムの世界でもこれと全く同じことが起きています。
昔に作られた古い暗号アルゴリズムである DES や MD5、SHA-1 といった方式は、今のコンピューターの性能から見ると「数秒〜数分で破られてしまうガタガタの鍵」になってしまっているのです。

攻撃者は、この「古い鍵の隙」を狙って、通信をのぞき見したり、パスワードを強引に暴いたり（クラック）して侵入してきます。「昔作ったシステムだから大丈夫」と油断していると、いつの間にか泥棒に入られている……なんてことになりかねません。

—

2. 攻撃者はどうやって「古い鍵」を見つけ出すのか？

ペネトレーションテスト（攻撃者の視点でシステムの弱点を探すテスト）の現場では、私たちはまずターゲットのシステムが「どんな鍵を使っているか」を調べます。

例えば、Webサイトの通信をチェックしたり、サーバーの設定を覗き見たりすると、そのシステムが今でも DES や SHA-1 といった古い暗号化方式を許可しているかどうかが一発で分かります。

攻撃者は、自動化されたツールを使って、次のような古い通信規格（暗号スイート）をあえて要求します。
「ねえ、古い SHA-1 の証明書でも通信できるよね？」
これに対してサーバーが「いいよ！」と答えてしまった瞬間、攻撃者はその古い隙を突いて通信データを解読してしまうのです。これが、レガシー暗号が放置されているシステムで起きる典型的なシナリオです。

—

3. 今すぐ移行しよう！「AES-GCM」と「SHA-256/3」へのバトンタッチ

それでは、具体的にどうやって古い鍵を新しい頑丈な鍵に交換していけばいいのでしょうか？
目指すべきゴールはシンプルです。

1. データの暗号化（データの保護）： 古い DES や 3DES から、現代の標準である AES-GCM（あるいは AES-256）へ移行する。
2. ハッシュ化（データの改ざん検知）： 古い MD5 や SHA-1 から、より安全な SHA-256 や SHA-3 へ移行する。

言葉だけだとなんだか難しそうに見えますよね。それでは、実際の開発現場でどのように設定を見直せばいいのか、サンプルコードを見てみましょう！

実装例：安全なハッシュ化（PHPの例）

パスワードや重要なファイルを扱う際、古い md5() 関数を使っていませんか？ これは絶対NGです。以下のように、安全な password_hash()（内部で強力なアルゴリズムを使用）や hash() を使いましょう。

<?php
// 【NGな例】古いMD5やSHA-1は絶対に使わない！
// $dangerousHash = md5($userPassword); 

// 【OKな例】パスワードの保存には標準の強力なハッシュ関数を使用する
// password_hash関数は自動的に安全なソルトとストレッチングを適用してくれます
$securePasswordHash = password_hash($userPassword, PASSWORD_DEFAULT);

// ファイルの整合性確認などでSHA-256を使う場合の例
$fileData = "大切なデータの中身";
$secureFileHash = hash('sha256', $fileData);

echo "安全なハッシュ値: " . $secureFileHash;
?>

設定例：Webサーバー（Nginx）での古い暗号スイートの無効化

次に、インフラ側（Nginxの例）で、古い TLS のバージョンやレガシーな暗号スイートをバッサリと拒否する設定を見てみましょう。設定ファイルを少し書き換えるだけで、古い鍵をシャットアウトできます。

server {
    listen 443 ssl;
    server_name example.com;

    # SSL証明書のパス設定
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    # 【重要】古いTLSバージョン（TLSv1, TLSv1.1）は危険なので無効化し、安全なTLSv1.2とTLSv1.3のみを許可する
    ssl_protocols TLSv1.2 TLSv1.3;

    # 【重要】安全でモダンな暗号スイート（AES-GCMなど）のみを指定する
    # 古いDESやRC4、SHA-1を使用する暗号スイートはすべて除外します
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';

    # サーバー側の暗号スイートの優先順位を強制する
    ssl_prefer_server_ciphers on;

    location / {
        root /var/www/html;
        index index.html index.htm;
    }
}

このように、設定ファイルの一行を書き換えるだけで、システム全体のセキュリティレベルをグッと引き上げることができます。

—

4. 一歩ずつ、確実に安全なシステムへ

いかがでしたでしょうか？
「レガシーな暗号の特定と移行」と聞くと、なんだか専門家しか触れないような果てしない作業に思えるかもしれません。しかし、基本の考え方は「古い、危なくなった鍵を新しい頑丈な鍵に取り替える」という、お家の防犯と全く同じです。

まずは今ご自身が関わっているプロジェクトやサーバーで、MD5 や SHA-1、古い暗号設定が残っていないか、コードや設定ファイルをそっと覗いてみることから始めてみませんか？

「ここはどう直したらいいんだろう？」と迷ったときは、いつでも周りの先輩やセキュリティエンジニアに相談してくださいね。一歩ずつ、安全なシステム作りを楽しんでいきましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました