お疲れ。最近、クラウドとオンプレミスを直結するハイブリッド環境の設計相談がやたらと増えているが、君たちは「とりあえずAWSのマネージドVPNだから安全だろ」「Direct Connectだから閉域網で暗号化不要」なんて甘い考えで構成していないだろうか？
何度でも言う。「閉域網だから安全」という神話は、現代のサイバーセキュリティにおいては完全に破綻している。
通信事業者のバックボーンやデータセンターの物理配線、さらにはクラウドのテナント境界に至るまで、攻撃者はあらゆるレイヤーで「盗聴」と「中間者攻撃（MitM）」のチャンスを虎視眈々と狙っている。
今回は、オンプレミスとクラウド間の命綱であるVPNゲートウェイ（IPsec）の暗号化スイートの選定ミスが招く現実の脅威と、物理層を守るMACsecの本質について、現場の泥臭い知見を交えて徹底的に解説しよう。
—
1. 攻撃者が狙うVPNゲートウェイとDirect Connectの盲点
多くのジュニアエンジニアは、「AWS Client VPNやSite-to-Site VPNを有効にした」「Direct Connect（DX）で専用線を引いた」ということで満足しがちだ。しかし、そこに潜むリスクを見落としている。
IPsecトンネルにおける「古い暗号スイート」の悪夢
IPsecのIKE（Internet Key Exchange）フェーズやIPsecフェーズにおいて、互換性のために古いアルゴリズム（3DESやSHA-1、さらには脆弱なDiffie-Hellmanグループなど）を残している環境を非常によく見かける。
攻撃者が社内ネットワークの一部（あるいはVPN終端の周辺セグメント）に侵入した場合、彼らはまずダウングレード攻撃（Cryptographic Downgrade Attack）を仕掛ける。意図的に弱い暗号化アルゴリズムを強制させ、リアルタイムでトラフィックをキャプチャし、オフラインの総当たり攻撃やプレシード攻撃によってセッション鍵をクラックするのだ。これが成功すれば、オンプレミスとクラウドを行き交うDBの認証情報や機密データは丸裸になる。
Direct Connectは本当に「暗号化されている」か？
「Direct Connectは専用線だから暗号化しなくていい」——これは最悪の誤解だ。DXの標準接続は、物理回線レベル（レイヤー2/3）では暗号化されていない。
通信事業者のルーターからAWSのルーターに至るまでの物理経路のどこかで、高度なハードウェアタップや不正なスプライシングが行われた場合、平文のトラフィックはすべてキャプチャされる。
特に金融や医療、政府系システムにおいて、コンプライアンス要件（PCI DSSやISO 27001など）を満たすためには、論理層（IPsec）または物理層（MACsec）でのエンドツーエンドの暗号化が必須となる。
—
2. 堅牢なIPsec VPN設定（StrongSwan / Libreswan用）の実装
では、具体的にどう設定すべきか。実務でそのまま使える、モダンで妥協のないIPsecの設定ファイルを提示しよう。
ここでは、破られやすい古いアルゴリズムを一切排除し、AES-GCMによる認証付き暗号（AEAD）を採用したStrongSwan用の設定 (ipsec.conf) のサンプルを共有する。
# /etc/ipsec.conf - セキュアなサイト間VPN設定サンプル
config setup
uniqueids = never # 同一IDでの複数接続を禁止し、セッション乗っ取りを検知する
strictcrlpolicy = yes # 証明書失効リスト（CRL）のチェックを強制
conn %default
keyexchange = ikev2 # 脆弱なIKEv1を完全に排除し、IKEv2のみを強制
ike = aes256gcm16-prfsha384-ecp384! # 暗号: AES-GCM 256bit, PRF: SHA-384, DHグループ: ECP 384bit (第2世代PFS)
esp = aes256gcm16-ecp384! # ESP暗号・完全性保護: AES-GCM 256bit, PFS有効
dpdaction = restart # デッドピア検出時に自動で再接続
dpddelay = 30s
dpdtimeout = 120s
auto = start
conn aws-direct-connect-backup-vpn
type = tunnel
left = <オンプレミスルーターのグローバルIP>
leftsubnet = 10.100.0.0/16 # オンプレミスのプライベートセグメント
right = <AWS VPNゲートウェイのIP>
rightsubnet = 172.16.0.0/16 # クラウド側のプライベートセグメント
authby = psk # 事前共有鍵（PSK）認証（※可能であれば証明書認証を推奨）この設定のポイント
ike = aes256gcm16-prfsha384-ecp384!: 末尾の感嘆符（!）に注目してほしい。これは「このアルゴリズム以外の一切の妥協を許さない（Strict）」という強い意志表示だ。弱いアルゴリズムへのダウングレードを防ぐ。- AES-GCMの採用: 従来のAES-CBC + HMACの組み合わせは、パディングオラクル攻撃などの脆弱性の温床になりやすい。暗号化と完全性検証を同時に行うAEAD（AES-GCM）を使用することで、処理の高速化と安全性の両立を図っている。
—
3. 物理層の要塞：AWS Direct ConnectにおけるMACsecの実装
レイヤー2レベルでの盗聴や改ざんを防ぐ究極の手段が MACsec（Media Access Control Security / IEEE 802.1AE） だ。
Direct ConnectにおいてMACsecを有効化すると、AWSのルーターとお客様側のルーターの間を結ぶ物理リンクそのものが暗号化される。万が一、回線経由でパケットをキャプチャされても、中身は完全にランダムなノイズにしか見えない。
現場でAWS Direct ConnectにMACsecを適用する際の設定パラメータ（JSON形式のイメージ）を以下に示す。インフラ構築の自動化スクリプトやTerraformの変数設計の参考にしてほしい。
{
"DirectConnectConnectionId": "dxcon-jj123456",
"MacsecConfig": {
"State": "enable",
"PrimaryCak": "a1b2c3d4e5f67890123456789abcdef0123456789abcdef0123456789abcdef0",
"Ckn": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210",
"AssociationId": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:dx-macsec-key"
},
"CipherSuite": "gcm-aes-256-xfn"
}運用時の注意点（現場の泥臭い教訓）
- CAK（Connectivity Association Key）とCKN（Connectivity Association Key Name）の管理: MACsecの鍵管理は非常にシビアだ。AWS Secrets Managerなどのセキュアなストレージで厳重にバージョン管理し、定期的なローテーション計画を立てておくこと。手動運用で有効期限切れを起こすと、ある日突然通信が途絶えて大規模な障害になる。
- MTU（Maximum Transmission Unit）の考慮: MACsecヘッダが付加されることで、パケットのオーバーヘッドが増加する。ルーター側のインターフェースでジャンボフレーム（MTU 9001など）が正しく設定されていないと、フラグメンテーションが発生し、パフォーマンスが著しく低下するか、通信不能に陥る。構築後の
ping -M do -s 1472による疎通確認とサイズ調整は絶対にサボるな。
—
4. セキュリティチーフからの総括
ネットワークの暗号化は、「動けばいい」ものではない。「攻撃者がコストをかけてでも突破しようとしたときに、どこまで耐えられるか」というリスクベースで設計するものだ。
「閉域網だから」「専用線だから」というエンジニアの怠慢が、一たびインシデントが起きたときの致命傷になる。今回紹介したStrongSwanの厳格な暗号スイート設定や、Direct ConnectにおけるMACsecの導入を、君たちのインフラストラクチャの標準（Baseline）として組み込んでほしい。
セキュリティは細部に宿る。妥協のない設計と実装を、チーム全員で徹底していこう。
コメント