クラウド全盛の昨今、ひときわ異彩を放つのが Cloudflare だ。元々が CDN 事業者であることもあり、各クラウド事業者と競合するのではなく、各クラウド事業者の苦手とするところを補完する存在であったが、今ではむしろ機能的に他社を侵食している状況にある。
Cloudflare の提供する機能は大きく２つに分けられる。ひとつは公開されたWebシステムの効率化と前さばき、もうひとつはイントラ／バックオフィス向けのプライベートアクセスである。Cloudflare はWebシステム機能自体はメインターゲットとせず、（基本的には）外界との繋ぎこみに特化した機能群を提供している。昨今では、Workers のように繋ぎこみ機能が高度になりすぎて、単独でアプリケーションを構築できることすらできるようになってきている（スーパークラウド）が、そこに主眼を置くと Cloudflare の事業を誤解することになる。
公開Webシステムの効率化と前裁き
Cloudflare と言えば、やはり有名なのは CDN (Content Delivery Network) である。CDNとはクライアントとサーバーを繋ぐネットワーク経路を効率化したり、クライアントに近い場所にキャッシュを置くことで配信を速くする仕組みのことを指す。ただ、やはりこの分野の先駆者は Akamai であるし、各クラウド事業者も独自のCDNを運用している（AWS だと Cloudfront）。
Cloudflare の優れているところはやはりエッジコンピューティングで、サーバーの直前に Workers と呼ばれるプログラミング可能なコンピューティング環境を用意することで、サーバーの振り分けやセッション管理といった様々な付加機能を提供できる。Workers はそれ単体では非力であるものの、SSR（サーバーサイドレンダリング）すら可能なレベルとなっており、フロントエンドの実行環境としては十分すぎる状況にある。
その他にも、DDoS対策、WAF、待合室（Waiting Room）、ボット対策、ロードバランサなどひと通りの機能が揃っており、システム提供に必要なのはバックエンドにあたるAPIサーバやDBサーバのみではないかという状況になっている。少なくとも、今後はフロントエンドはエッジに置き、クラウドやオンプレに置くのはロジックとデータのみという構成が Cloudflare に限らず主流になるのではないかと思われる。
イントラ／バックオフィス向けのプライベートアクセス
昨今、イントラ／バックオフィスと言えば、ゼロトラストセキュリティが主題となることが多い。ゼロトラストセキュリティ自体は曖昧模糊とした概念だが、端的に言えば外部と内部を分ける境界型セキュリティへのアンチテーゼであり、実装としては各システムと各利用者の組み合わせそれぞれに個別の境界型検査を設けましょう以上の話ではない。内部に入ればあとは素通りという牧歌的な時代が終わっただけのことで、「ゼロトラスト」という語にはさほど重要な意味があるとは思えない。本当にゼロトラストと言うのであればネットワークを切断して金庫にしまっておけと思うのだが、そういう意味ではない。*1
Cloudflareは、このようなイントラ／バックオフィス向けのプライベートアクセスにも強い。Cloudflare ではこのような用途に主にふたつの手段（とひとつの経過措置）を用意している。
まず、サーバー用途には cloudflared というトンネリング機能を使う。これは AWS で言えば Systems Manager の SSM Agent と同じような仕組みで、それぞれのシステムが cloudflared 経由で Cloudflare ネットワークに繋ぐことで、外部へのポート公開を避けながら、相互に通信を行うことができるようになる。インターネットを通ることにはなるが少なくとも通信はセキュアに行われる（AWSなどと直結したい場合は、Network Interconnectを使うこともできる）。この cloudflared は IPv6 をサポートしているのも大きい。Egress-Only インターネットゲートウェイを経由することで外部からアクセス不能なセキュアな構成を実現できる。
一方のクライアント側は、Cloudflare WARP という Cloudflare ネットワーク専用の VPN クライアントを使うことで接続できる。
これによりクライアントからサーバーまで一貫して Cloudflare 管理下で通信を行うことができるようになる。ここに Cloudflare ACCESS と呼ばれるSSO兼アクセス制御機構が介入することでゼロトラストセキュリティを可能にするという仕掛けになっている。さらに、占有エグレスIPを契約することで各種 SaaS への接続制限すら可能になる。
既存システムがどうしても移行できないという場合にはMagic WANというVPN機器とCloudflareを繋ぐ方法も用意されているがこれはあくまで移行措置と思ったほうがよいだろう。
Cloudflare にできないこと
[2024/8/14 追記] Cloudflare はDNSに介入することでシステムへのアクセスを制御する仕組みだ。そのため、Outbound すなわちシステム側から外部に接続する通信には介入できない。そのため、以前あった log4j2 の脆弱性のように、アプリケーション内部から外部サイトに直接つながれて情報を漏洩させるような攻撃には対応できない。
セキュアな情報を保管するバックエンド機能は、エッジ側ではなくクラウドサービス側に置き、外部通信を Forward Proxy で制御する必要性があることを意味する（AWS ならば金額は高いが Network Firewall が使える。ただ、Squid をマネージドサービス側に置いた方が使い勝手はよいとは思う）。
Cloudflare に死角はないのか
Cloudflare により提供される高度な機能は大変便利な反面、Cloudflare が死んだら何もできなくなる危険性をはらんでいる。実際、昨年大規模障害が発生している。
障害の発生はAWSだろうとGoogleCloudでも同じだろうと思われるが、単独のシステムがアクセスできなくなるのと社内ネットワーク全域が使えなくなるのではだいぶ話が違う。
先日のcrowdstrikeの事故やVMWareの買収による混乱をみれば特定のベンダに依存することは極力避けるべきなのは間違いなく、少なくとも一ヶ月以内に別の方式に切り替えられるようにはしておきたい。
Cloudflare側からこれに対する回答は期待できないことを考えるとなかなかの難問に思える。
*1:サーバーレスと言い、ゼロトラストと言い、実態と乖離した用語が普及する昨今の風潮はいかがなものか
