VPN Gateway でSSL-VPN を使用する#6 業務利用を考える

今回はAlibaba Cloud VPN Gateway のSSL-VPN 機能、業務利用にどこまで応えることが出来るか機能要件・非機能要件の視点で整理してみました。

結論から言うと、在宅勤務やリモートワークなどエンドユーザ向けの用途には適していません。 主となる利用シナリオは管理者によるAlibaba Cloud への管理目的のアクセス、そしてオンプレミスのサーバのAlibaba Cloud への接続の2つとなりました。

1. SSL-VPN の機能

一般的なSSL-VPN の機能要件とAlibaba Cloud の対応状況を整理してみます。

1.1. SSL-VPN 方式

SSL-VPN 自体は2000年初頭には一般化していた記憶があります。当時はもちろんオンプレミスでFirepass などを提案・導入した記憶があります。 

そんなSSL-VPNですが、IPsecと異なりVPNトンネルの確立を様々な方式で可能です。以下の3つが主要な方式でしょうか。   

項目対応状況
リバースプロキシN/A
ポートフォワードN/A
クライアントインストール対応
(OpenVPN)

クライアントレスで利用出来るリバースプロキシやポートフォワードは未対応です。 もちろんクライアントレスはアプリケーションとの接続性で限定的、条件ありという課題もありますが。

Alibaba Cloud VPN Gateway ではもっとも接続性のあるクライアントインストールに対応している点では特に困ることは無いと考えます。

1.2. 対応クライアント

OpenVPN に対応するクライアントの対応OSとイコールとなるのですが、純正のOpenVPN Connect の対応状況は以下の通りです。

一般的なクライアントOSに対応していると言っていいでしょう。

項目対応状況
Windows対応
Linux対応
Mac対応
iOS対応
Android対応

なお、公式サイトを見る限りMACOSとWINDOWS はBETA 提供のようです。

https://openvpn.net/

1.3. 認証方式

Alibaba Cloud VPN Gateway の対応する認証方式は”証明書”1つだけです。 また、外部認証リポジトリ連携は行えません(証明書認証しか利用出来ないのであまり問題にならないかもしれません)。

項目対応状況
ID/パスワードN/A
証明書対応
多要素認証
※OTP、Matrix など
N/A
条件付きアクセス
※送信元クライアントのIP、
サブネットの指定など
N/A
外部認証リポジトリ連携
※RADIUS、LDAPなど
N/A
SAML連携N/A
CAPTCA
※接続元が人間かどうかの識別
N/A

証明書1つで接続出来る単純さはメリットでもありますが、証明書と接続先が漏れてしまうと誰でもアクセス出来てしまう点は注意が必要です。 また、VPN Gateway への接続に関するアクセス制限機能(IPアドレスやサブネットを指定した制限)を持たない現状、証明書を厳重に管理出来ない場合、利用を控えた方がよいかもしれません。

1.4. SSL-VPN の高度な機能

SSL-VPN の基本機能は外部から内部へのアクセス経路(VPN)の確立です。 既存のSSL-VPN ソリューションでは単純なVPN の確立以外に様々な機能を提供しています。

項目対応状況
検疫
※OSバージョン、パッチチェック
※マルウェアバージョンチェック
※その他レジストリキーなどのチェック
N/A
特定アプリーケーション特化
※VDI (ICA/PCoIP/RDPなど)
※Exchange
N/A
サンドボックス
※VPN確立中、使い捨ての環境でのみ操作
N/A
エンドユーザ向けUI・プロファイル
※お気に入り、接続先情報などの保管
N/A

残念ながらAlibaba Cloud VPN Gateway のSSL-VPN 機能では上記に挙げたような機能は未提供です。

2. SSL-VPN の非機能要件への対応

業務システムの導入では単純な機能の有無だけではなく、非機能要件の検討も必要となります。

非機能要件の主な項目は以下でしょうか。

  • 性能
  • 容量
  • 信頼性
  • 拡張性
  • 稼働スケジュール
  • 監視
  • バックアップ
  • システム更新
  • セキュリティ

それぞれの項目についてAlibaba Cloud VPN Gateway のSSL-VPN 機能について

2.1. 性能

一般的にSSL-VPN の性能というとベンダー、機器のアーキテクチャにもよりますが大きく以下の3つでしょうか。

  1. SSL/TLSのスループット
  2. システム全体のスループット
  3. NIC の物理的な仕様(10/100/1000Mbpsなど)

SSL/TLSのスループットのよくある指標は1秒間あたりのSSL/TLSのセッション開始能力です。 あとはSSL/TLSのスループットもあります。  過去、SSL/TLS の処理はCPU負荷が高い、重たい処理として位置づけられ、数百、数千のコネクションの処理には専用のハードウェアチップを利用することも一般的でした。

また、クラウドやSaaS が一般化する前は、物理機器によりSSL-VPN 機能を実現する必要があったため、このような性能指標の確認は必須でした。 物理機器はクラウドやSaaSほど性能に関する拡張性に自由度がありません。 従って、必要な性能を持つ機器を選定する必要があり、そのために上記のような指標があったわけです。 上記の通り専用のハードウェアチップを利用した構成の場合、後から性能をスケールすることも出来ないということがありました。

Alibaba Cloud VPN Gateway における性能の指標はスループットの1つのみです。しかも”10Mbps” と”100Mbps” の2種類のみです。 考えることが少なくて良いと思いつつ、実際、どれくらいの性能を提供出来るのか見えずらいとも言えます。

というわけで実際に性能を測定してみることにします。

まず、テストするネットワーク環境自体がボトルネックとならないか、VPN を確立する前の素のネットワークスループットを確認します。

自宅のインターネット接続環境はカタログスペック 1Gbps です。 今回はWifi 接続なので有線ほどのスループットは出ませんが、Alibaba Cloud VPN Gateway の10/100Mbpsというスペックのテストには十分です。

10Mbps のVPN Gateway インスタンス

大体となりますが、最大で8Mbps 位のスループットでした。

100Mbps のVPN Gateway

100Mbps のインスタンスのVPN Gateway ですが最大で7Mbps 程度でした。 スペック通りの100Mbps とは言わないまでも、10Mbps をこえるスループットに期待しのたですが結果は10Mbps のインスタンスと違いないものでした。

このVPN インスタンスですが10Mbps で購入したものを100Mbps へアップグレードしたものです。 VPN のセッションは一度切断し、接続していますが、反映までに時間がかかるのかもしれません。 または、1接続あたりの性能は10Mbps 程度が上限で複数セッションだとスループットが向上する動作なのかもしれません。 もちろん、クライアントとVPN Server 間のネットワークに原因がある可能性もあります。  原因究明にはテストケースを増やして、さらに詳細な調査が必要となりそうです。 

2.2. 容量

一般的なサーバやデータベースの場合、容量はディスクやメモリなどわかりやすいものが検討対象です。 SSL-VPN の場合の容量は利用可能なユーザ数・接続数となると考えます。

Alibaba Cloud VPN Gateway のSSL-VPN 機能では同時接続数は課金単位として管理されています。 5/10/20/50/100/500/1000 の7つのプランが提供されています。 最小で同時5接続、最大で1000接続です。

各ユーザごとのプロファイルを管理できる他社プロダクトなどではそのプロファイルに関する容量の要件を検討する必要がありますが、Alibaba Cloud では接続数の1点だけとなります。

2.3. 信頼性

次は信頼性についてです。 可用性として定義されることもあります。

Alibaba Cloud VPN Gateway のインスタンスは冗長構成です。

高可用性: アクティブ/スタンバイホットバックアップアーキテクチャを使用すると、VPN Gateway は1秒以内に自動的にフェイルオーバーモードになります。 クライアントデータ処理への影響を最小限にすることができます。

https://jp.alibabacloud.com/help/doc-detail/64960.htm?spm=a21mg.l28256.b99.2.6ba11a63WUnyGV

ただし、SLBやRDSのように2つのゾーンにまたがった冗長構成という記述は特に見当たりません。  ゾーン障害に対応出来るかどうかはサポートチケットによる確認が必要となりそうです。

以下はVPN Gateway のインスタンスの詳細画面ですが、ゾーンに関する情報は見当たりません

2.4. 拡張性

Alibaba Cloud VPN Gateway のSSL-VPN 機能の拡張性についてです。 

まず、スケールアウトを自動的に行うような機能は提供していません。 言い換えると手動でVPN インスタンスを追加することでスケールアウトすることが可能です。ただし、この場合、VPN クライアントから見た接続先は1つではありません。 証明書認証ということでロードバランサーによる接続先の統合も出来ません。 

スケールアップですがスループット(10Mbps or 100Mbps)とSSL-VPN接続数( 5 or 10 or 20 or 50 or 100 or 500 or 1000)の2点で構成変更が可能です。 基本はアップグレードのみでダウングレードは出来ません。

2.5. 稼働スケジュール

VPN Gateway のインスタンスは基本的に24/365の稼働です。 逆に特定時間帯だけ停止する、再起動するという機能はありません。

業務要件などで例えば特定時間帯だけ利用を停止したい場合、VPN Gateway の標準にはそのような機能は持たないため、SSL クライアントの構成やインスタンスを削除・追加するような処理を別途スケジュール実行することになります。 

2.6. 監視

Alibaba Cloud VPN Gateway のサービスの正常性をどう監視するかという話になります。

調べる前はCloud Monitor からアラームルールを作成し、監視なり通知が出来ると考えたのですが、Cloud Monitor ではVPN Gateway が未対応のようです。

どうしても監視と通知が必要な場合は、別のVPCや別のリージョンにてECSでZabbix なりの監視システムを立ち上げる必要がありそうです。 L4 レベルのポートの監視のみであればFunction Compute でもいけるとは思います。 が、せっかくのマネージド提供のVPN Gateway なわけで監視と通知機能が無いのは残念なところで、早期対応が望まれます。

2.7. バックアップ

VPN Gateway のSSL-VPN 機能の構成情報のバックアップですが、VPN Gateway としては構成上のエクスポートとインポートの機能は未提供です。少なくともAlibaba Cloud コンソールのGUIからは該当機能は確認出来ません。API のマニュアルにも見当たりません。 IPsec の構成のエクスポート機能はあったのですが。

基本的にはGUIからの作成ではなくAPIから作成を基本としスクリプト化しておくことで、万が一の再作成にも最短時間で対応可能です。 しかし、クライアントに配布した証明書の考慮が必要です。 証明書の再作成となるとクライアントに証明書の再配付が必要となるためです。 VPN Gateway のAPI のマニュアルも確認しましたが既存の証明書をインポート出来るAPIは見つかりません。

結論、VPN Gateway 構成のエクスポート/インポートは出来ず、VPN Gateway の再作成となります。 結果、証明書も再作成となりクライアントへ構成情報(VPNサーバの接続先)と証明書の再配付が必要となります。 この点、エンドユーザ向けの環境としてはかなり厳しいかなと思いました。

2.8. システム更新

VPN Gateway はマネージド提供のため、VPN Gateway 側の管理はすべてAlibaba Cloud 側に任せておくことが可能です。

一転気にする点があるとすれば、エンドユーザに影響があるSSL-VPN機能の仕様変更でしょうか。 クラウドサービスの常としてサービスは常にバージョンアップ、機能向上していきます。 まあ、ポジティブにとらえフレキシブルに対応していくことになるでしょう。

2.9. セキュリティ

非機能要件のセキュリティ、観点は複数あります。

まずはVPN Gateway 自体のセキュリティ対策です。 VPN Gateway を安全な状態に保つ、言い換えるとインターネット上の不特定多数からの攻撃に備えるということになります。 この点はシステム更新と同様にAlibaba Cloud 側に任せておくことになります。

VPN Gateway を利用する側のセキュリティという面では、監査に関する要件にどこまで対応できるかが検討ポイントになります。 監査とは言いましたが簡単にいうと誰がいつログインに成功したのか、また、失敗したのかのログの取得は基本的な要件となっていることが多いと思います。

Alibaba Cloud VPN Gateway のSSL-VPN 機能ですが、GUI 上にログ表示機能を備えていますが、今現在有効に機能しません。 10分ごとに表示できるようなのですが表示されません。 中国とのタイムゾーンの1時間差が違いなのかと思いい時間ずらしても表示されません。

また、Alibaba Cloud VPN Gateway ではこの接続ログを別の場所に転送する機能は持っていません。 OSSやLog Service に保管できるオプションがあると実運用にも耐えうるものとなると思いました。

3. まとめ

機能要件と非機能要件について長々と書いてきましたが以下の3つの利用シーンについて独断で評価します。

  1. エンドユーザ向けリモート接続環境
  2. 管理者向けリモート接続環境
  3. サーバの接続 (IPsec の代わり)

3.1. エンドユーザ向けリモート環境

出張者用や在宅勤務などエンドユーザ向けのリモート環境を想定しています。エンドユーザといっても社員向けといった方がイメージしやすいかもしれません。

総合評価
コメント認証機能と運用管理機能が弱く、大規模なエンドユーザ向け環境には向かない
メリット・OpenVPN 互換となりクライアントの接続性に優れる
・フルマネージドを従量課金で利用可能
デメリット・証明書認証にしか対応していない
・ログ機能が弱い
・VPN Gateway を再考した場合、証明書含めてクライアントに設定の再配布が必要

3.2. 管理者向けリモート環境

Alibaba Cloud 上のパブリックIPを持たないECS などの管理する場面を想定しています。 情報システム部門の管理者がVPN経由でパブリックIPを持たないサーバにログインするイメージです。

総合評価
コメント・冗長化されたマネージドシステムという点では管理用途のリモート環境として十分利用可能
メリット・フルマネージド
デメリット・アクセス制限の機能が弱い
・ログ機能が弱い

3.3. サーバの接続(IPsecの代わり)

Alibaba Cloud VPN Gateway のSSL-VPN 機能ではトンネルを確立後、双方向に通信が可能です。この特性を生かして例えば、オンプレミスのWindows ファイルサーバをSSL-VPN 接続でリージョンに接続し、Alibaba Cloud 上のサーバのバックアップをこのWindows ファイルサーバに取得するなどの運用も可能です。

総合評価
コメントルータの準備、既存ルータの変更などIPsec での接続が難しい場合の代替策として有用
メリット社内のサーバとAlibaba Cloud 上の各システムを簡単に接続出来る
デメリット社内のサーバに割り振られるIPアドレスは接続のたびに変わる(Dynamic DNS などIPアドレスに頼らない運用が必要)

3.4. さいごに

一般的な機能要件と非機能要件の視点でAlibaba Cloud VPN Gateway を整理してみました。 このアプローチは、要件の捉え方およびその実現方式・実装に違いはあれど従来型のシステムもクラウドサービスにおいても変わらないものです。また、従来からのアプローチをとることでよりクラウドサービスとの違いをより認識できる点は良いことだとも思います。

今、現状、不足する機能も多いAlibaba Cloud VPN Gateway のSSL-VPN 機能でしたが無理にこのプロダクトを利用する必要はありません。 Marketplace ではForitgateやCheckPoint社のUTMのイメージも提供しておりライセンスをBYOLすることで利用可能です。

Fortigate のSSL-VPNはF5ほど多機能ではありませんが、ID/パスワード認証や多要素認証、他認証リポジトリとの連携も可能です。 リバースプロキシ方式や検疫機能も利用可能でまた、接続数に依存しないライセンス形態なことも特長です。 適材適所で要件にあうソリューションを利用することがもっとも重要だと考えます。