そのVPN接続、ほんとに安全ですか?
こんにちは
在宅勤務時のテーブルは愛媛みかんの箱🍊
システムソリューション部のかわいです。
少しずつ冬を感じる季節になってきましたね。
筆者も寒かったり天気の悪い日はもっぱらリモートワークしがちで家に籠もることが多いです。
原点回帰的な出社に戻す風潮はありながらも、コロナ禍以降リモートワークの導入、または推進されている企業はまだまだ根強くあるんじゃないでしょうか。
それに伴い自宅からのリモートアクセスVPN利用も増えたと思いますが、そもそもその運用って安全なんでしょうか?
本記事ではリモートアクセスVPNの仕組みや課題について書きたいと思います。
リモートアクセスVPNのメリットとデメリット
まずは、リモートアクセスVPNの基本的なメリット/デメリットについて整理します。
リモートアクセスVPNの用途ですが、自宅や外出先から社内への接続を安全に行いたい、という目的がメインになると思います。
次いでカフェ等の公衆Wi-Fiに繋ぐ際、WPA等の安全でない無線規格に接続する場合の安全面確保の用途があると思います(こっちに関してはそもそも繋がないという選択肢が理想ですが..)。
(Evil Twins攻撃とかもあるので) ※無線接続におけるプロトコルの種類については以下Kasperskyさんの記事が簡潔で詳しいです
参照:https://www.kaspersky.co.jp/resource-center/definitions/wep-vs-wpa
■メリット
主なメリットとしては「データの暗号化」が挙げられます。
VPNではカフェ等の公衆ネットワークを利用してもVPNサーバ(社内ルータなど)までの通信が暗号化されるため、傍受のリスクが低くなります。
また、前述のようにオフィス内に置かれているローカル環境のファイルサーバや社内システムに安全にアクセスでき、業務に必要な情報が実質どこからでも取得できます。
他にもルーティング設定によって、IP制限をしている環境に対し、外からであってもオフィスIPを送信元とした接続(いわゆるゼロルート)が可能になったりします。便利。
■デメリット
ただしデメリットとして頭に置いておかないといけないのは、VPN接続を行ったとしてもすべてが安全になるわけではないという点です。
メリットの裏返しになりますが、VPNで暗号化されるのはあくまでも自宅から会社までの経路です。
その先のインターネットへのアクセスは、HTTPS等で別途暗号化が行われていないと、VPN経由でも安全性が確保されません。
また、通信速度や接続安定性への懸念点もあります。
VPN接続には通信の暗号化や経路の迂回が伴うため、通常に比べ接続が不安定になる場合があります。
暗号化されたパケットの復号化/再暗号化処理も加わるとVPNサーバとなるルータへの負荷も増加し、場合によってはローカル側のインターネット接続にも影響が出るケースもあります。
リモートアクセスVPNの仕組みと種類
リモートアクセスVPNにはいくつかの方式があり、それぞれ異なるメリット・デメリットがあります。
この段落では、そのなかでもよく使われるものを簡単に紹介します。
(各方式名の部分に「SEの道標」さんの記事をハイパーリンク化しています。詳しく知りたい方は参考に見てみてください。)
【IPsec/L2TP】
IPsec(Security Architecture for Internet Protocol または Internet Protocol Security)は、データパケットの認証と暗号化を行うプロトコルで、L2TP(Layer2 Tunneling Protocol)と組み合わせて使用されます。
認証方法:事前共有鍵または証明書
メリット:高いセキュリティを提供し、多くのOSで標準サポートされています。
デメリット:暗号化処理がNAT環境での接続に制限があるため、環境によっては設定が難しい場合があります。
挙動としてはまずパケットをL2TPによりカプセル化し、データリンク層をトンネリングする役割を担います。
L2TPは暗号化機能を持たず、単独ではセキュリティが不十分なため、このパケットをIPsecで保護することで機密性/完全性を確保、AHやESPといったIPプロトコルを使用して暗号化/認証を提供します。
【SSL VPN】
SSL VPNは、HTTPSを利用してVPNトンネルを作成する方式です。
Webブラウザ上から利用可能で、SSL/TLSプロトコルを利用してデータを暗号化します。
認証方法:ID/パスワード、ワンタイムパスワード、証明書など
メリット:標準的なWebブラウザで動作するため、NAT環境でも接続しやすい。
デメリット:Webトラフィックに依存しているため、対応できるアプリケーションが制限される(ことがある)。
一般的にTCP/443が使用できるためシンプルです。また、IPsec/L2TPに比べ処理が少なく通信速度も安定することが期待できます。
他サービスと重複する場合はポート番号をずらす必要がある点注意です。
【IKEv2】
IKEv2では、IPsecと組み合わせることで特にモバイル環境に適したVPNを提供します。
認証方法:証明書認証、EAP(拡張認証プロトコル)
メリット:接続の再確立が迅速で、移動中の接続にも強い。
デメリット:他方式に比べ、サポートしていない機器が多い。
VPNはほんとに安全なのか? ~多層防御の考え方を添えて~
前置きが長くなりましたがメイン部分です。
VPNはリモートアクセスのセキュリティを強化する一つの選択肢となりますが、もちろん単独で完全な防御を提供するものではありません。
重要なデータやシステムを守るためには、ゼロトラストの考え方を取り入れた多層/多段防御が必要です。
■実際のVPN機器が侵入口となってしまったケース
記憶に新しい事例として、2022年 大阪急性期・総合医療センターのインシデントを紹介します。
この攻撃により病院システムが停止、すべて手動での対応となり、完全復旧まで約1年を要したというケースです。
調査報告書によると、https://www.gh.opho.jp/pdf/report_v01.pdf
今回の侵入経路は、E 社の給食センターを経由したサプライチェーン攻撃であった。侵入経路となった
ファイアウォール Z のファームウェア更新は行われておらず、当該機器の ID とパスワードの漏洩も確
認された。また、病院は C 社の依頼にしたがって、ファイアウォール Y において、E 社の情報システム
からの RDP 通信(ポート番号:3389)を常時接続可能にし、その後、運用状況の確認や改善を怠ったた
め、E 社への攻撃が病院に波及した。
上記は報告書内「4.2.3. 技術的発生要因のサマリー」の引用ですが、侵入口となるのは本社だけではない、というのが本ケースからはわかると思います。
いわゆるサプライチェーン攻撃となり、支社や関連会社のVPN機器から侵入▶閉域網経由で本社へ拡大 といった事例は頻繁に発生しています。
このことから、入口部分をどれだけ固めても一度侵入されるとイントラネットワークは非常に脆弱という点が浮き彫りになりました。
なので、そもそもリモートアクセスVPNで通信が暗号化されていたとしても、接続元のクライアントが既に感染している場合、VPNは何ら意味をなさないということが分かります。
■ゼロトラストの考え方
ゼロトラストとは「信頼しない」という原則に基づき、ネットワークにアクセスするすべての通信や端末、ユーザを検証し、認証を行うという考え方です(性悪説)。
VPN接続に加え、アクセス制御や通信内容の確認、さらに二要素認証などを組み合わせることで、リスクを最小限に抑えます。
具体的なソリューションとしては、Azure Active Directory(Azure AD)などの認証サービスを活用する方法があります。
Azure ADを使ってユーザのデバイス/アプリケーションごとに認証ポリシーを設定し、社外からのアクセスを詳細に制御することができます。
詳細:https://learn.microsoft.com/ja-jp/azure/security/fundamentals/zero-trust
■エンドポイントでの防御や検知
加えて、どれだけ認証や前段部分を防御しても、残念ながらPC等クライアント側へのマルウェアの侵入を完全に防ぐことはできません。
そのため万一の侵入・感染時に備え、資産管理ソフト等でのログの収集・監視や、エンドポイントセキュリティ製品の導入もほぼ必須になってきています。
※エンドポイントセキュリティの概要については過去記事で紹介しています▼
まとめ
VPNは確かに便利で強力ですが、「VPNを使っているから安全」という考えは危険です。
リモートアクセスVPNにおいては自宅から会社ルータまでの通信が暗号化されるだけであり、その先のインターネット通信が守られているわけではありません。
適切なセキュリティを担保するには多層防御の考え方やゼロトラスト、認証基盤を取り入れる柔軟な設計が重要です。
ちなみに気になる動きとしてMicrosoft社が2024年10月の記事で、将来的にPPTPとL2TP方式を非推奨とする内容を公開しました。
※PPTPはそもそも脆弱すぎるので使わない方がいい
今後本記事では紹介していないSSTPと、前述のIKEv2への移行の流れが進んでいくかもしれません。
https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/pptp-and-l2tp-deprecation-a-new-era-of-secure-connectivity/4263956
https://ascii.jp/elem/000/004/227/4227428/#:~:text=%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%BD%E3%83%95%E3%83%88%E3%81%AF%E3%80%812024%E5%B9%B410,%E3%82%92%E6%8E%A8%E5%A5%A8%E3%81%97%E3%81%A6%E3%81%84%E3%81%8F%E3%80%82
完