京都のシステム開発・ホームページ制作会社　株式会社Nextat（ネクスタット）

当ブログの更新も随分と間が空いてしまいました。 お久しぶりです。ナカエです。

本日のお題はWeb系ではなく、珍しくセキュリティとネットワークに関連する記事です。

弊社では、

• 社外（主としてリモートワーク環境）からの社内LAN内の機器へのアクセス
• 接続元のIPアドレス制限を行っているサービスへの社外からのアクセス
• 業務端末を社外のWi-Fiに接続した時の保護

などを目的としてリモートアクセスVPNを自前運用しています。

事務所内に設置しているルーターをVPNサーバーとしてリモートアクセスVPNを実現していたのですが、同時接続数の増加に伴う速度低下や接続の不安定さが目立つようになりました。 当初はルーターを入れ替えようという話になったのですが、同時接続数の上限が低く、一度頓挫しました。

昨今、VPN機器の脆弱性を突かれるセキュリティインシデントをよく見かけることもあり、ネットワークの設計自体を見直す丁度良い機会であると考えてVPNに限定せず選択肢を調査しました。

Tailscale と Cloudflare Zero Trust を候補に考えていたのですが、50ユーザーまで無料のプランがあり社での試験導入も気軽にできそうなことなどからCloudflare Zero Trustを採用することにしました。

ゼロトラスト・セキュリティやCloudflare Zero Trustの存在は以前から認識していたものの、接続元IPアドレス制限はゼロトラストの理念とはむしろ逆のものであり、両立するのは困難だろうと考えていたのが今まで手を出さなかった理由でした。

そのような偏見があったのですが、調査の結果むしろVPN利用よりリモートアクセスの負荷が下がる構成を実現できそうなことがわかったため、昨年末ごろから試験導入を行っています。

今回の記事は、Cloudflare Zero Trustを利用して固定IPアドレスによる特定のWebサイトへのアクセスを実現した方法についてが主となります。

ゼロトラスト・セキュリティ/ゼロトラスト・ネットワーク

いかなるネットワークにも信頼を置かず、利用するアプリケーションやサービスそれぞれで常にユーザーの検証（認証認可）を行うセキュリティ/ネットワークのモデルのことをゼロトラスト・セキュリティ/ネットワークと呼びます。

従来のネットワーク設計では信用してきた社内LANやVPN経由のアクセスなども信用すべきでないものとして扱われるのが特徴です。 このモデルが台頭してきた要因としては、モバイル端末の活用やリモートワークなど、従来の社内LANを中心とするモデルでは扱いづらい複雑なネットワーク構成が増えてきたことが挙げられます。

参考： ゼロトラスト・セキュリティモデル - Wikipedia

Cloudflare Zero Trust

Cloudflare Zero Trust はCDNで有名なCloudflareが提供するゼロトラストセキュリティ・ネットワークのサービスです。 トンネルを用いたプライベートネットワークへのセキュアなアクセスやDNSによるアクセス制御などを軸としています。

なお、Cloudflareのネットワークやサービスには全幅の信頼を置かないといけないので厳密にはゼロではないことには注意が必要です。セキュリティソフトのベンダーを信頼する必要があるのと同じ話で、仕方のない部分ではありますね。

Cloudflare WARP

Cloudflare WARPというアプリケーションをPCやスマートフォンなどの端末にインストールして利用することになります。VPNクライアントソフト相当ですね。

このWARPを介した通信は、例外設定したものを除きすべてCloudflareのエッジを通るようになりWireGuardプロトコルを利用したトンネルで保護されます。
WireGuardの代わりにMASQUEプロトコルも選択できますが、導入時はデフォルトになるのはもう少し先のようだったのでWireGuardのままとしています。
 

Cloudflare Tunnel

cloudflaredというソフトウェアを手持ちのサーバーにインストールすることで、固定のパブリックIPアドレスをサーバーに設定することなく、Cloudflareのエッジ経由でサーバーおよびサーバーが属するプライベートネットワークへとアクセスできるようになります。 プライベートネットワークへのセキュアなアクセスが実現できます。

このcloudflaredとCloudflareのエッジとの間で確立されるトンネルがCloudflare Tunnelです。（文脈によってはcloudflaredが稼働しているサーバー自体をトンネルと呼んでいることもあるようですが、本記事ではトンネルサーバーと呼称します）

例えば自宅のWebサーバーの公開にも使える便利なツールです。

画像は https://www.cloudflare.com/ja-jp/zero-trust/products/access/ から引用

Cloudflare Tunnelを使うことで、ルーターのファイアーウォール・クラウドのセキュリティグループなどのポートのインバウンドの通信を許可する必要がなくなるのは特筆すべき点です。

代わりにcloudflaredを常駐させるサーバーが必要となります。社内サーバーを増やすことはあまりしたくなかったのですが、接続元IPアドレス制限以外の認証認可に切り替えていくまでの繋ぎとして割り切りました。

短期的にはAWSなどのクラウドのVPCにトンネルサーバーを配置してそちらの固定IPアドレスも併用で使えるようにしようと考えています。

固定IPアドレスによるアクセスの実現方法

固定IPアドレスによるアクセスの実現方法をチェックした結果、下記3案が候補に上がりました。

案1. Cloudflare Zero Trust公式のDedicated Egress IP オプション

Cloudflare Zero Trustには、Cloudflareのエッジのネットワークからの出口となるIPアドレスを固定するDedicated Egress IP オプションが存在しました。

しかし、旧来の事務所の固定IPアドレスをそのまま利用できないことに加え、このオプションが利用可能なEnterpriseプランは気軽に試すには値が張ることで選択肢からは外しています。

案2. Cloudflare WARPの通信を、全て社内のCloudflare Tunnel経由とする

こちらは構成としてはシンプルだったのですが、全ての通信を事務所のトンネルサーバーに通すとなると、VPN機器の性能の限界と同じことが起きて根本的な解決にならないことが予想されたため、不採用となります。将来的にクラウドのVPCにトンネルサーバーを建てるとしても、ユーザー数の増加に応じて通信料も増加しそうなこともネックでした。

案3. Cloudflare WARPを使った特定のサイトへの通信のみ、社内のCloudflare Tunnel経由とする

CloudflareのGateway Policyの設定でWARP接続時に特定のサイトのDNSクエリの応答を上書きすることができます。 DNSのクエリ応答を社内のプロキシサーバーのIPアドレス（Cloudflare Tunnel経由になるのでプライベートIPアドレスでOK）に変更することで、社内のプロキシサーバーを経由する通信となり、固定IPアドレスからのアクセスとなります。

実際の構築では、cloudflaredを動かしているトンネルサーバーにTCP/UDPプロキシとなるよう設定したnginxを同居させています。

SSHの対応にやや難がある（後述）ものの、接続元IPアドレスを固定する必要のない場合は事務所のネットワークを通過しなくなり、ネットワーク機器の負荷の問題が解決できそうでした。

今回はこちらの構成を採用しました。

導入時のはまりポイントなど

実際に導入してみていくつかはまった点や現時点では解決を諦めて妥協した点がありました。

セキュリティソフトとの競合

利用しているセキュリティソフトのファイアウォール・フィルタ機能と競合してCloudflare Warpの正常動作に失敗していたため、Cloudflare WARPのアプリケーションをセキュリティソフトによるチェックの対象から除外する設定が必要でした。

Docker Desktop for Macとの競合

Docker Desktop for Macのデフォルト設定と相性が悪く、設定を変更する必要がありました。
settings > Resources > Network > “Use kernel networking for UDP” のチェックを外せば問題は解決しました。

接続元IPアドレス制限とSSH

SSHはSNIを利用している通信とは違い宛先がわからないため、HTTPSのケースのようにあらゆるSSHサーバーに対応するプロキシ設定を書くことができませんでした。SSHで接続したいサーバーとポートを1つ１つマッピングしていくことになるため、管理コストも高くユーザー体験も良くないだろうと諦めました。しばらくはVPNを併用し、Cloudflareの Access for Infrastractureを使ったSSH や AWSのSession Managerを使うサーバーへのアクセスに徐々に切り替えていこうと考えています。

Access for Infrastractureを使うSSHで多段SSHが使えれば問題なかったのですが、試した限りでは上手くいきませんでした。

TLS InspectionによるHTTPS通信のチェック

なるべくセキュアにということでHTTPSなどのTLS通信も検証する設定としていたのですが、暫定的に検証しない設定に戻しました。

暗号化されている通信の中身をチェックする場合は、Cloudflareのエッジで一度TLSを外し、再暗号化しなければなりません。 TLS Inspectionを有効にした場合は、クライアント側は元のサイトの証明書ではなくCloudflareの証明書を受け取ることになります。

一部のアプリケーションではホストOSの設定を参照せず独自に証明書のチェックを行っているため、証明書が不正であるというエラーが出て正常動作しないことがよくあります。 当初はアプリケーションやアプリケーションがアクセスするドメインを不具合があるたびに除外する設定していたのですが、網羅するのは難しいと判断しました。

まとめ

通信の速度はWARP接続時であっても十分出ており、VPN接続時より明らかに速くなりました。 ほとんどの通信が事務所のネットワーク経由ではなくCloudflareのエッジ経由となったことで、当初の問題であった社内のネットワーク機器への負荷・性能不足はほぼ解決できています。 また、Cloudflare Zero Trustの設定で、マルウェアの疑いがあるなど特定のカテゴリのサイトへのアクセスを弾くことができ、セキュリティを強化できたのは嬉しい副次効果です。

一方、事務所内にトンネルサーバーを新たに抱えたことや接続元IPアドレス制限ありのSSHへの不十分な対応などの未解決な問題もあり、完全な脱VPNやゼロトラスト・セキュリティの実現までは至っていません。 継続的に改善・移行を進めていきたいところです。

参考記事

• Cloudflare Zero Trustを利用して開発環境への安全なアクセス方法を構築する | CyberAgent Developers Blog
• Cloudflare Zero Trustで社内システムへのリモートアクセスをよりセキュアで便利にした話 - The Finatext Tech Blog
• Cloudflare WARP から自前データセンターの固定 IPv4 で抜ける
• Cloudflare を経由し、固定の IP から Internet にアクセスをする #cloudflare - Qiita
• Cloudflare Zero Trust の Dedicated Egress IP オプションについて整理 #cloudflare - Qiita
• Cloudflare ZeroTrust WARP の TLS Inspcetion と Terminationについて