Sitemap
The Finatext Tech Blog

THE Finatext Tech Blog

Follow publication

Cloudflare Zero Trustで社内システムへのリモートアクセスをよりセキュアで便利にした話

--

こんにちは、Finatextの @s_tajima です。

弊社のこれまでのリモートアクセスの環境は、Pritunl というOpenVPNベースのソフトウェアで構築されていました。( 詳しくは、こちらの記事で以前紹介させていただいています。https://techblog.finatext.com/vpn-pritunl-on-aws-68619eda6b36 )

今回は、このPritunlベースの従来のVPNを Cloudflare Zero Trustに置き換え、社内システムへのリモートアクセスをよりセキュアで便利にした話です。(“社内” という表現を使っていますが、”オフィスにある” という意味ではなく、”社内メンバー向けの” という意味です。)

Cloudflare Zero Trust とは

Cloudflareと聞くと、CDNの会社というイメージが強いと思います。しかし昨今ではCDN向けに整備したグローバルなエッジ環境を生かして、 1.1.1.1 や WARP といったセキュアなネットワークアクセスのためのサービスも提供しています。 Cloudflare Zero Trustはその企業向け版のサービスで、企業の保有するシステムへの安全なリモートアクセスを実現するためのものです。

一般的な機能・仕様については公式サイトを見ていただくのがよいかと思うので簡単な紹介に留めますが、

  • クライアントに Cloudflare WARP をインストール
  • 社内システム(ネットワーク)にCloudflare Tunnel (cloudflared) をインストール
  • クライアントは、Cloudflare WARPを使って通信をCloudflareのEdge Serverにルーティングされる
  • CloudflareのEdge Serverに到達したトラフィックは、事前に設定されたルールに基づきトラフィックをその先にルーティングされる
  • すべての通信は、Cloud Accessによって設定したポリシーに基づき処理内容(許可・ブロック等)を制御

という形で、Cloudflare Zero Trustという単体の製品があるというよりは、いくつかのモジュールを組み合わせることで社内システムへの安全なリモートアクセスを実現できます。

さらに、Cloudflare Zero Trustは50ユーザーまで無料で使えます。
ログの保持期間が短い、サポート窓口が使えない等の制約はありますが、機能面での制約はほぼないので、トライアルがしやすいのも嬉しいところです。(弊社は50ユーザーを超えていることもあり有償プランで利用しています。)

システム構成

この後の説明の内容をイメージしやすくするために、まずはCloudflare Zero Trustを導入した状態の構成図をお見せします。

特筆すべきポイントは、Pritunlを稼働させているのと同じVPCにてCloudflare Tunnelを稼働させ、デフォルト(0.0.0.0/0)の通信をそこにルーティングしているところです。
こうすることで、今までのVPN環境であるPritunlと、新しく作ったCloudflare Zero Trustの環境で、同一のグローバルIPを使うことができます。

それとは別のプライベートなネットワークでもCloudflare Tunnelを稼働させ、あるIPアドレスレンジの通信がそちらにルーティングされるようにしています。

導入の決め手

Cloudflare Zero Trustは様々な機能・特徴がありますが、その中で僕たちがこれを導入するに至った背景をご紹介します。

結局まだ固定されたグローバルIPアドレスは必要

Pritunlの紹介の記事において、VPNを必要とする理由として、

固定されたグローバルIPアドレスを利用するため (インターネットには公開されているが、接続元のIPアドレスを制限したクラウドやSaaSへの接続のため)

というのを挙げました。
当時から2年以上が経った現時点でも、認証の一定の強度を実現するためにはIPアドレスによる制限を利用せざるをえないシステムが残っていて、この要件をなくすことはできていません。

前述の通りCloudflare Tunnel をAWS上で稼働させ、NAT Gateway + Elastic IPでIPアドレスを固定することでこの要件を実現しています。また、PritunlのVPNと同じVPC上にシステムを構築したことで、同じグローバルIPを使えるようにしてあります。弊社においてはPritunlとの互換性のためにこのような構成にしていますが、こういった制約がなければ Magic NAT を使うこともできると思います。

複数のプライベートネットワークに接続可能

既存のとあるシステムの運用の効率化のため、複数の独立したプライベートネットワークにアクセスしたいという要件もありました。
従来のVPNの場合、基本的にはその複数のプライベートネットワークごとにVPNサーバーを構築し、アクセスするネットワーク合わせてVPNの接続を切り替える必要があります。Cloudflare Zero Trustの場合はそれぞれのプライベートネットワークにCloudflare Tunnelを起動させるだけで、同じWARPのセッションでそれぞれのネットワークを使い分けることができます。

柔軟なアクセスポリシー管理

ポリシーを設定することで、アクセスの様々なコンテキストにもとづき通信の許可・拒否等をコントロールできます。
コントロールのレイヤーも、DNS・Network・HTTPと、目的に合わせて柔軟に選択できます。

ポリシーは、「接続先のIP・Port・ホスト名(SNI含む)」といった一般的なファイアーウォールにあるような項目だけでなく、「Device Posture」「Security Categories」「Content Categories」「Application」といった特別な項目を利用することもできます。

クライアント端末の管理がしやすい

Cloudflare WARPがクライアントの情報を収集してくれることで、管理画面から誰がどんな端末で接続しているかを簡単に確認でき、必要に応じてRevoke等することができます。

また、収集した情報は「Device Posture」として扱うことができ、この結果を使ったアクセスポリシーを書くことができます。
Device Postureというキーワードを聞き慣れない方もいるかもしれませんが、具体的には、

  • OSのバージョン
  • シリアル
  • ディスク暗号化の状態
  • ローカルのファイアーウォールの状態
  • EDR等のアプリケーションのインストールの状態
  • 特定のファイルの有無

といった項目をチェックし、「会社で所有する端末のシリアルにマッチしない端末や、ディスクが暗号化されていない端末からの通信をすべてブロックする」といったことができるのです。

組織管理外のデバイスや、セットアップが不完全な端末が意図せずCloudflare Zero Trustに接続されてしまっていることを検知するのに役立ちます。なお、未検証ですが当然これらの情報はクライアントによって偽装はできるはずなので、あくまで “悪意のないミスを防ぐ” 程度の位置づけにする必要はあります。

高いネットワークパフォーマンス・利便性

内部的なプロトコルとしてはWireGuardを利用しているため、

  • 軽量なプロトコルであり通信のパフォーマンスが出やすい
  • クライアントのネットワーク環境が変わってもローミングによって接続が維持される

といった利点があります。(当然通信の暗号化もされます。)

導入してみて

良かったところ

  • 私は検証も含めて半年程度このシステムを使っていますが、管理者としても利用者としてもユーザビリティが高く、生産性が大きく向上したのを感じています。全社展開後、社内メンバーからも「快適になった」という声が多く上がっています。
  • アクセスポリシーやクライアント端末の管理の仕組みによって、リモートアクセスの安全性も向上しました。

改善が必要なところ

  • 現時点では、Cloudflare WARPによるクライアント端末の収集はWindows・macOS・Linuxのみの対応のため、スマートフォンではDevice Postureを使うことができません。(Windows・macOS・Linuxにおいても若干の不安定さがあります。)
  • 現時点では、Cloudflare WARPがWSL2をサポートしていません。このため、現時点ではWSL2ユーザーにはPritunlを併用してもらう必要があります。

最後に

以上、Cloudflare Zero Trustの導入のお話でした。
今回の記事を読んで、もっと詳しい話を聞きたいと思っていただけた方は、ぜひTwitterやMeetyにてご連絡ください!

--

--

No responses yet