こんにちは！インフラやクラウドのセキュリティを担当していると、「専用線やVPNでクラウドと繋いだんだから、セキュリティはもう万全だよね！」という声をよく耳にします。
新人エンジニアの皆さんや、これからセキュリティの勉強を始める開発者の方なら、なおさらそう思いますよね。「専用線」という言葉の響きだけでも、なんだか要塞のように安全で、誰も侵入できない強固なパイプがつながったような安心感があります。
ですが、ホワイトハッカーの視点から現場の現実をお伝えすると、実はここに「大きな盲点」が潜んでいます。今回は、オンプレミス（社内のサーバー室など）とクラウドを結ぶVPNゲートウェイや専用線（AWSのDirect ConnectやAzureのExpressRoute）の暗号化要件について、身近な防犯の例えを交えながら、優しく、そして徹底的に紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょう！
—
1. 「専用線＝安全」という思い込みの罠
まずは、よくある勘違いから解きほぐしていきましょう。
クラウドと会社を繋ぐ方法には、インターネット回線を使う「VPN」と、通信キャリアが提供する専用の回線を使う「専用線（Direct Connect / ExpressRoute）」があります。
ここで、次のような例えを考えてみてください。
- VPN（インターネット経由）：一般道を使って、荷物を運ぶイメージです。道中には一般の車がたくさん走っているので、荷物をそのまま積んでいると中身を覗き見られる危険があります。だから、頑丈なトランクケース（暗号化）に入れて鍵をかける必要がありますよね。
- 専用線（Direct Connect / ExpressRoute）：あなたの会社とクラウド事業者の間だけに敷かれた「専用の地下トンネル」をイメージしてください。一般の人は誰も入れません。
この地下トンネルのイメージを持つと、「おっ、誰も入れないんだから、わざわざ重たいトランクケース（暗号化）に入れなくても、段ボール箱のままで荷物（データ）を運んでも安全だよね！」と思ってしまいがちです。これが、現場で一番恐ろしい「思い込みの罠」なんです。
攻撃者は「物理的なトンネル」の途中にいるかもしれない
現実のITインフラにおいて、「誰も入れない完全な一本道」を維持するのは至難の業です。
専用線と言っても、その物理的なケーブルは、通信事業者のビルを経由し、海底ケーブルを通り、様々な中継機器を渡ってクラウドのデータセンターへと届きます。もし、その途中のどこかで、悪意ある攻撃者にネットワーク機器を不正に操作されたり、スリッパを履いた内部の人間が不正にパケットをキャプチャ（盗聴）していたとしたらどうでしょう？
地下トンネルだからといって、中身を丸裸（平文）で流していたら、覗き見られた瞬間に会社の機密データや顧客情報がすべて盗まれてしまいます。
だからこそ、「どんなに信頼できそうな通信経路であっても、流れるデータ自体には必ず鍵をかける（暗号化する）」というゼロトラスト（誰も信用しない）の考え方が、現代のインフラセキュリティでは絶対的な常識になっているのです。
—
2. IPsec（アイピーセック）ってなに？ 身近な鍵に例えて解説
通信に鍵をかける仕組みとして、インフラの世界で最も広く使われているのが IPsec（Security Architecture for Internet Protocol） という技術です。
名前は難しそうですが、仕組みはとてもシンプルです。郵便配達の例えで考えてみましょう。
1. あなたは社内の機密書類を封筒に入れます。
2. その封筒を、さらに頑丈な鉄の金庫に入れて鍵をかけます（これがIPsecによる暗号化です）。
3. 宛先が書かれた外側の封筒（IPパケットのヘッダー）はそのままにしておき、配達員はどこに運べばいいか分かりますが、万が一途中で封筒を開けられても、中の金庫は開きません（中身の機密データは守られます）。
4. クラウド側の受け取り口に到着すると、同じ鍵を持っているゲートウェイだけが金庫を開け、中の書類を取り出します。
VPNゲートウェイや専用線（MACsecなどのレイヤー2暗号化や、AWS/Azure上でIPsec VPNを二重化する構成など）では、この「金庫の鍵のかけ方」をしっかりとルール通りに設定することが、要塞化の第一歩になります。
—
3. 実務で使える！暗号化要件の具体的な設定とチェックポイント
それでは、ここから少しだけ実践的な話をしましょう。
クラウド（ここでは例としてAWSやAzure、一般的なLinuxベースのVPNルーターを想定）でIPsecを設定する際、セキュリティ担保のために必ず確認すべきポイントと設定のサンプルを見ていきます。
古い暗号化方式（例: 3DESやSHA-1など）は、現在のコンピュータの計算能力では数分で破られてしまいます。そのため、「現在推奨されている強力なアルゴリズム（AES-GCMやAES-256、SHA-2など）」を強制することがハーデニングの基本です。
実際のIPsec設定ファイル（strongSwanなどのLinuxルーターの例）のイメージ
インフラエンジニアがよく使うオープンソースのVPNソフトウェア strongSwan の設定ファイル（ipsec.conf）を覗いてみましょう。
# /etc/ipsec.conf
# オンプレミスとクラウド（AWS/Azure）を安全に結ぶためのIPsec設定例
conn aws-direct-connect-backup-vpn
# IPsecのバージョン（IKEv2を使用し、より安全なハンドシェイクを行う）
ikev2=yes
# 接続が切れた時に自動で再接続を試みる
auto=start
# 自社側のIPアドレス
left=203.0.113.10
leftid=203.0.113.10
leftsubnet=192.168.10.0/24 # 社内ネットワークの範囲
# クラウド側のVPNゲートウェイのIPアドレス
right=198.51.100.20
rightid=198.51.100.20
rightsubnet=10.0.0.0/16 # クラウド上のVPC/VNetの範囲
# 【重要】暗号化と認証のアルゴリズム（強固なものを指定する）
# 暗号化: AES 256ビット (GCMモードなど認証付き暗号が推奨)
# 認証ハッシュ: SHA-256以上
# Diffie-Hellmanグループ: 堅牢なグループ14以上（例: 2048ビット以上のMODPや曲線暗号）
esp=aes256gcm16-prfsha256-modp2048
ike=aes256-sha256-modp2048このように、設定ファイルの中で aes256gcm16 や sha256 といった、現代の基準で「破られにくい頑丈な鍵」を明示的に指定することが、セキュリティホールの発生を防ぐ強力な盾となります。
—
4. 現場のプロが教える「陥りがちなミス」と対策
最後に、現場のインフラ構築で新人の皆さんがやりがちなミスと、その対策をいくつかシェアしておきますね。
① 「とりあえず動く」古い設定をそのままコピペしてしまう
ネット上の古いチュートリアル記事を参考にすると、暗号化方式に古い 3DES や MD5 が指定されていることがあります。これらはすでに安全性が崩れているため、必ず最新のセキュリティ基準（AES-256やSHA-2以上）に書き換える癖をつけましょう。
② 事前共有鍵（Pre-Shared Key: PSK）の管理不足
IPsecの認証によく使われる「事前共有鍵」ですが、社内のチャットツールに適当に貼り付けたり、ソースコード管理リポジトリ（GitHubなど）にうっかりコミットしてしまったりするインシデントが後を絶ちません。鍵は必ずパスワードマネージャー等で厳重に管理し、定期的にローテーション（変更）を行いましょう。
③ 暗号化しているからと安心しきって、ファイアウォール設定をサボる
IPsecで通信が暗号化されていても、万が一クラウド側のサーバー設定にミスがあり、不要なポート（22 や 3389 など）が世界中に公開されていたらどうなるでしょうか？ 侵入者は暗号化されたトンネルを通って、あるいは別の経路から不正アクセスを試みるかもしれません。
「VPNの暗号化」と「サーバーOSやクラウドのセキュリティグループ（ファイアウォール）によるアクセス制限」は、両輪でセットで守ることが鉄則です。
—
まとめ
いかがでしたでしょうか？
「専用線やVPNを使っているから安全」という思い込みを捨て、通信経路の途中に潜むリスクを想像すること。そして、IPsecなどの暗号化設定でしっかり「頑丈な金庫」を使うこと。この2つを意識するだけで、あなたの守るシステムはグッと要塞化されます。
セキュリティ対策に「完璧」はありませんが、一歩ずつ正しい知識を積み重ねていくことで、攻撃者にとって「おいしくない、面倒くさいターゲット」に変えていくことができます。
日々のインフラ構築、大変なこともあるかと思いますが、一緒に日本のITの安全を守るエンジニアとして頑張っていきましょう！それではまた次の記事でお会いしましょう。
コメント