【入門編】 IPsecにおけるハッシュ・認証アルゴリズム（SHA-2, HMAC）の役割 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

ゼロトラスト時代のVPNの守り方：IPsecの「SHA-2とHMAC」で通信を信頼するってどういうこと？

皆さん、こんにちは！技術メディア「パケットのささやき」主筆ライターのケンです。
今日は、私たちのビジネスを支えるセキュアな通信の要、VPNの中でも「IPsec」という技術にスポットを当てて、ちょっと深掘りしてみたいと思います。特に、通信が「本当に正しい相手から送られてきたのか？」「途中で誰かに書き換えられていないか？」という、とっても大事な部分を守る仕組みについて、わかりやすく解説していきますね。

インフラやネットワークの学習を始めたばかりの皆さんにとって、SHA-2とかHMACなんて聞くと、ちょっと難しそうに聞こえるかもしれません。でも大丈夫！郵便配達の流れや身近な例えを交えながら、一歩ずつ一緒に理解を深めていきましょう。

—

🔒 IPsecって何だっけ？おさらいしよう！

まずは基本から。IPsecは、インターネットプロトコル (IP) の層で通信を安全にするための技術の集まりです。主に以下の2つの「安全」を提供してくれます。

1. 暗号化 (Confidentiality): 通信内容を第三者に見られないようにする「目隠し」です。郵便で言えば、手紙を読めない暗号で書いたり、中身が見えない頑丈な封筒に入れるイメージですね。
2. 認証と完全性 (Authentication & Integrity): 「この通信は本当に正しい相手から送られてきたものなのか？」「途中で誰かに内容を書き換えられていないか？」を確認する仕組みです。これこそが、今日の主役であるSHA-2とHMACが活躍するフィールドになります。

特にゼロトラストの考え方では、「社内ネットワークだから安全」という前提はもうありません。すべての通信は「信用できないもの」として扱い、「誰が」「何を」「どこへ」送っているのか、そして「その内容は改ざんされていないか」を常に検証することが求められます。IPsecの認証と完全性の仕組みは、まさにこのゼロトラストの根幹を支えるものなんですよ！

—

🕵️‍♂️ 「通信が改ざんされていないか？」をどうやって見破るの？

想像してみてください。大切な情報が書かれた手紙を遠い取引先に送るとします。郵便配達の途中で、誰かがこっそり封筒を開けて内容を書き換え、また封をして送り返したらどうでしょう？受け取った取引先は、それが改ざんされたものだとは気づかずに信じてしまうかもしれません。これは大変危険ですよね！

デジタル通信の世界でも同じです。パケットという情報のかけらがインターネットを旅する途中で、悪意のある第三者によって内容が書き換えられてしまう可能性があります。これを「改ざん」と呼びます。

IPsecは、この改ざんを見破るために、ある賢い仕掛けを使います。それが、ハッシュ関数とメッセージ認証コード (MAC) の組み合わせなんです。

手紙の「要約」が改ざんを見破るヒント！

ハッシュ関数とは、どんなに長い文章でも、それを「固定の短い文字列（要約）」に変換する魔法のような関数のことです。例えば、分厚い本の全ページを読んで、たった数行の「あらすじ」を作るイメージですね。

この「要約」には、いくつかのすごい特徴があります。

一方向性: 要約から元の文章を復元することは、ほぼ不可能です。あらすじから本全体を書き起こせないのと同じです。
入力が変われば出力もガラリと変わる: 元の文章がたった一文字でも変わると、要約は全く別のものになります。まるで指紋のように、元の情報に少しでも違いがあれば、要約（指紋）も全く別物になるんです。
同じ入力からは必ず同じ出力: 同じ文章を何回要約しても、必ず同じあらすじ（要約）が生成されます。

この「要約」を、デジタル通信の世界では「ハッシュ値」とか「メッセージダイジェスト」と呼びます。

—

✨ ハッシュ関数 SHA-2 ってどんな魔法？

IPsecでよく使われるハッシュ関数の一つが、SHA-2（Secure Hash Algorithm 2）です。これはアメリカの標準技術として採用されている、とても信頼性の高いハッシュ関数になります。

SHA-2にはいくつかのバリエーションがあって、よく目にするのは次のようなものです。

SHA-256：256ビット長のハッシュ値を生成します。
SHA-384：384ビット長のハッシュ値を生成します。
SHA-512：512ビット長のハッシュ値を生成します。

数字が大きいほど、生成されるハッシュ値が長くなり、より安全性が高まると考えられます。なぜなら、ハッシュ値が長ければ長いほど、「全く違う内容なのに同じハッシュ値ができてしまう（これを衝突と呼びます）」という可能性が極めて低くなるからです。

さて、このSHA-2がどのように改ざんを見破るのか、具体的に見ていきましょう。

1. 送信者側: 送信したいデータ（例：「明日の会議は10時です」）を用意します。
2. ハッシュ値の計算: このデータ全体をSHA-256などのハッシュ関数に通し、そのデータ固有の「ハッシュ値」（例えば、a1b2c3d4...のような文字列）を計算します。
3. データと一緒に送信: 元のデータにこのハッシュ値を添えて、受信者に送ります。

4. 受信者側: 元のデータと、添えられてきたハッシュ値を受け取ります。
5. 再計算: 受け取った元のデータだけを、送信者と同じSHA-256ハッシュ関数に通し、もう一度ハッシュ値を計算します。
6. 比較: 受信者自身が計算したハッシュ値と、送信者が送ってきたハッシュ値を比較します。

もし、途中でデータが改ざんされていたらどうなるでしょう？
例えば、「明日の会議は10時です」が「明日の会議は12時です」に書き換えられていたとします。
受信者が「明日の会議は12時です」をハッシュ関数に通すと、SHA-2の特性により、送信者が計算したa1b2c3d4...とは全く異なるハッシュ値（例えば、x9y8z7w6...）が生成されます。

この「計算したハッシュ値が違う！」という事実をもって、「あ、このデータは途中で改ざんされたな！」と瞬時に判断できるわけです。すごいですよね！

—

🔑 HMAC (Hash-based Message Authentication Code) はなぜ必要なの？

「あれ？SHA-2だけで十分じゃないの？」と思った方もいるかもしれませんね。実は、純粋なハッシュ関数だけだと、まだセキュリティ上の課題が残ってしまうんです。

前述の例では、もし悪意のある第三者が、データを改ざんした上で、改ざん後のデータで新しいハッシュ値を計算し直して、それを添えて送ってしまったらどうでしょう？
受信者は、改ざんされたデータから計算したハッシュ値と、第三者が新しく添えたハッシュ値が一致するので、「改ざんされていない！」と騙されてしまいますよね。

この問題を解決するのが、HMAC（Hash-based Message Authentication Code）です。HMACは、ハッシュ関数に「秘密の鍵」という要素を組み合わせることで、この問題を解決します。

「秘密の印鑑」で封印するイメージ

HMACは、イメージとしてはこうです。

1. 送信者側:

送信したいデータを用意します。
そのデータと、あらかじめ送信者と受信者の間でだけ共有されている「秘密の鍵」を使って、HMACアルゴリズムに基づいて「メッセージ認証コード（MAC）」を計算します。
このMACは、単なるハッシュ値ではなく、「秘密の鍵」で封印されたハッシュ値のようなものです。
データにこのMACを添えて受信者に送ります。

2. 受信者側:

データと、添えられてきたMACを受け取ります。
受け取ったデータと、自分たちが知っている「秘密の鍵」を使って、送信者と同じHMACアルゴリズムでMACを再計算します。
受信者自身が計算したMACと、送信者が送ってきたMACを比較します。

この仕組みのミソは、「秘密の鍵」を知っている人しか正しいMACを生成できない、という点です。もし第三者がデータを改ざんしたとしても、その第三者は「秘密の鍵」を知らないため、改ざん後のデータで正しいMACを計算して添えることができません。

したがって、受信者が再計算したMACと、送られてきたMACが一致しなければ、「データが改ざんされたか、あるいは正規の送信者からのものではない」と判断できるわけです。
まさに、郵便配達の例で言えば、「特定の印鑑が押されていないと、たとえ封筒が閉じられていても本物ではない」と判断できるようなものですね。

—

🤝 IPsecの世界での SHA-2 と HMAC の連携プレイ

IPsecでは、このHMACとSHA-2のようなハッシュ関数を組み合わせて、データの認証と完全性を保証します。具体的には、HMAC-SHA256やHMAC-SHA384といった形で利用されます。

IPsecには、主に2つのプロトコルがあります。

AH (Authentication Header): IPパケット全体（ヘッダー含む）の認証と完全性を保証します。暗号化は行いません。
ESP (Encapsulating Security Payload): IPパケットのペイロード（中身）の暗号化と、認証・完全性を保証します。現在はこちらが主流です。

ESPモードで通信を確立する際、データの認証部分でこのHMAC-SHA256などが活躍します。

通信の流れ（例：ESPモードでの認証）

1. 事前共有鍵の合意: まず、通信を開始する前に、送信側と受信側で「秘密の鍵」（事前共有鍵、Pre-Shared Key: PSKなどと呼ばれます）を共有しておきます。
2. 送信側での処理:

送りたいデータ（TCP/UDPセグメントなど）を準備します。
そのデータを暗号化します（これは今日の本題ではありませんが、ESPの一部です）。
暗号化されたデータと、あらかじめ共有しておいた「秘密の鍵」を使って、HMAC-SHA256アルゴリズムでMACを計算します。
計算されたMACは、暗号化されたデータの後ろに付加されます。
この一連のパケットをインターネットに送り出します。

3. 受信側での処理:

IPsecで保護されたパケットを受け取ります。
パケットから暗号化されたデータとMACを取り出します。
受け取った暗号化されたデータと、自分たちで共有している「秘密の鍵」を使って、送信者と同じHMAC-SHA256アルゴリズムでMACを再計算します。
計算したMACと、パケットに付加されていたMACを比較します。
両者が一致すれば、「データは改ざんされておらず、秘密の鍵を知っている正当な送信者から送られてきたものだ」と判断し、データを復号化してアプリケーション層に渡します。
もし一致しなければ、そのパケットは破棄され、エラーが通知されます。

このように、SHA-2のようなハッシュ関数と「秘密の鍵」を組み合わせたHMACは、IPsec通信の信頼性を担保する上で、まさに縁の下の力持ちのような存在なんですね！

—

💻 実際のIPsec設定で見てみよう！

では、実際のネットワーク機器の設定で、この認証アルゴリズムがどのように指定されるか見てみましょう。今回は、LinuxのstrongSwan（オープンソースのIPsec実装）と、Ciscoルータの簡単な設定例をご紹介します。

例1: Linux (strongSwan) の設定ファイル (ipsec.conf)

strongSwanでは、conn（接続定義）の中で認証アルゴリズムを指定します。

# /etc/ipsec.conf の設定例 (一部抜粋)
config setup
  # strongSwanの基本的な設定

conn my_vpn_tunnel
  leftsubnet=192.168.1.0/24  # 自拠点側のネットワークアドレス
  left=10.0.0.1             # 自拠点側のグローバルIPアドレス
  rightsubnet=192.168.2.0/24 # 対向拠点側のネットワークアドレス
  right=20.0.0.1            # 対向拠点側のグローバルIPアドレス
  auto=start                # strongSwan起動時に自動で接続を開始

  # フェーズ1 (IKEv1/v2のSA確立) の設定
  ikelifetime=8h            # フェーズ1のSAの有効期限
  keyexchange=ikev2         # IKEv2を使用
  ike=aes256-sha256-modp1024! # 暗号化アルゴリズム(AES256)、認証アルゴリズム(SHA256)、DHグループ(MODP1024)

  # フェーズ2 (IPsec SA確立) の設定
  lifetime=1h               # フェーズ2のSAの有効期限
  esp=aes256-sha256!         # 暗号化アルゴリズム(AES256)、認証アルゴリズム(SHA256)
  authby=psk                # 認証方式は事前共有鍵 (PSK)
  # leftauth=psk             # 自拠点側の認証方式（PSK）
  # rightauth=psk            # 対向拠点側の認証方式（PSK）

上記のike=aes256-sha256-modp1024!やesp=aes256-sha256!の部分に注目してください。
ここでsha256と指定されているのが、まさにHMAC-SHA256を使って認証を行う、という意味になります。もしより高い安全性を求めるなら、sha384やsha512を指定することも可能です。

例2: CiscoルータのIPsec設定 (CLI)

Ciscoルータでも、crypto isakmp policy（フェーズ1）とcrypto ipsec transform-set（フェーズ2）で認証アルゴリズムを指定します。

! フェーズ1 (ISAKMP Policy) の設定
crypto isakmp policy 10
  encryption aes 256        ! 暗号化アルゴリズムはAES256
  hash sha256               ! ★ここが認証アルゴリズムの指定！SHA256を使用
  authentication pre-share  ! 認証方式は事前共有鍵
  group 14                  ! Diffie-Hellmanグループは14 (MODP2048)
  lifetime 86400            ! フェーズ1のSA有効期限 (秒)

! フェーズ2 (IPsec Transform-Set) の設定
crypto ipsec transform-set MY_TRANSFORM_SET esp-aes 256 esp-sha256-hmac
  mode tunnel               ! トンネルモードを使用

! 暗号マップへの適用
crypto map MY_CRYPTO_MAP 10 ipsec-isakmp
  set peer 20.0.0.1         ! 対向ルータのIPアドレス
  set transform-set MY_TRANSFORM_SET ! フェーズ2の設定を適用
  match address 101         ! アクセスリスト101で定義されたトラフィックを保護

Ciscoルータの設定では、hash sha256でフェーズ1の認証アルゴリズムを、esp-sha256-hmacでフェーズ2の認証アルゴリズムをそれぞれ指定しています。どちらもHMAC-SHA256が使われることを意味しています。

このように、裏側では複雑な処理が行われていますが、設定自体は非常にシンプルに「どのハッシュ関数を使うか」を指定する形になっているのがわかりますね。

—

🚀 まとめ：信頼できる通信は SHA-2 と HMAC から！

今日の話をまとめてみましょう。

SHA-2 は、データから一意の「要約」（ハッシュ値）を生成する魔法の関数です。これ単体でも改ざん検知には使えますが、悪意のある第三者による「改ざん後のハッシュ値再計算」には対応できません。
HMAC は、このSHA-2のようなハッシュ関数に「秘密の鍵」を組み合わせることで、本当に正規の送信者からの通信であること、そして途中で改ざんされていないことを強力に保証する仕組みです。
IPsec では、このHMAC-SHA256やHMAC-SHA384といったアルゴリズムが、VPN通信の「認証」と「完全性」を担っています。これにより、私たちは「この通信は信頼できる！」と安心してデータをやり取りできるわけです。

ゼロトラストの時代において、すべての通信を検証し、疑わしきは罰するという考え方は不可欠です。IPsecのSHA-2とHMACは、まさにその「検証」の最前線で活躍し、私たちのデータを守ってくれている番人と言えるでしょう。

初めてIPsecの仕組みに触れる皆さんにとって、少しでも理解の助けになれば嬉しいです。ネットワークの世界は奥深く、知れば知るほど面白くなります。これからも一緒に学んでいきましょう！

それでは、また次回の記事でお会いしましょう！
ケンでした！