亀田さんに、ゼロトラストを改めて教えてもらう
大谷：恥ずかしながら、ゼロトラスト自体をちゃんと理解していないので、改めて教えてください。セキュリティって専門ライターさんがいることもあって、個人的には10年前くらいから知識が止まっている分野なんです。
亀田：ゼロトラストそのものはVPNに対するアンチテーゼから生まれています。オフィスのように人が一箇所に集まるのであれば、セキュリティはシンプルです。守るべきネットワークも1つでいい。でも、リモートワークが当たり前になってくると、すべての通信を1つのネットワークでまとめて管理するのがしんどくなってきます。
もちろん、どこかにVPNゲートウェイを置いて、すべてのトラフィックを経由させればできなくはないのですが、Microsoft 365やGoogle Workspaceみたいなクラウドサービスが出てくると、そもそもプライベートネットワークを経由する意味がなくなります。外（インターネット）のトラフィックをいったんプライベートネットワークに集約しても、また外に出てしまうわけですから。
大谷：だったらインターネットに直接アクセスした方が高速化しますよね。
亀田：そうなんです。その点、インターネットにアクセスするのであれば、Cloudflareを通した方が安全だよねというのが、うちのゼロトラストの考え方です。クラウドフレアのグローバルネットワークは、500以上のデータセンターで構成されており、前述した通り、インターネットトラフィックの1/4が通過するものです。
大谷：じゃあ、ゼロトラストを契約すると、アクセスポイントみたいなのが渡されるんですか？
亀田：クライアント用のエージェントが提供されます。一番近場のCloudflareのデータセンターと通信してくれます。当然、アクセス先の最寄りまでは、Cloudflareのネットワークを経由するので、セキュリティが確保されます。
大谷：変な質問ですが、「そのエージェントって、結局VPNクライアントの頭良くなった版じゃないの？」という指摘は正しいですか。
亀田：正しいですね。ただ、汎用VPNの場合は接続先が基本固定されているし、プロトコルは標準のIPsecを使います。一方で、Cloudflareのゼロトラストは、接続先はダイナミックに変わるし、IPsecは使っていません。やや技術的な話ですが、IPsecは固定長なので、オーバーヘッドが大きいですが、Cloudflareの場合は、WireguardやMASQUEという軽量プロトコルを使います。
他社は弊社のようなセキュアネットワークを持っていないことも多い。そのため、エンドツーエンドでのセキュリティが必要になり、ずっとトンネリングがかかっている状態になります。だから、一般的にはCloudflareの方が高速になります。
大谷：そもそも「ゼロトラストください」と言って、いただけるものなんですか？
亀田：われわれは「ゼロトラストネットワークアーキテクチャを売っている」ので、厳密には「ゼロトラスト」ってベンダーが言っていい表現ではない。ただ、あまりにもゼロトラストが流通しすぎているので、最近はゼロトラストと言っています。これは入社後、半年して、若干心が折れた部分ではあります（笑）。
正式にはゼロトラストは企業が持つべきコンプライアンス、セキュリティの考え方。それを支えるために企業が策定すべきネットワークのあり方がSASE（Secure Access Service Edge）になります。企業がSASEを実現させるためにベンダーが販売しているのが、CASB（Cloud Access Security Broker）。そんな関係性をゼロトラストセミナーでエバンジェリストとして話しています。今、一切かまないで言えたと思うのですが（笑）。
大谷：勉強になりました。さすが亀田さん。
セキュリティベンダーのコミュニティで成功しているところはない
大谷：亀田さんはエバンジェリストなので基本的には話す人ですが、最近はどんな話をしているんですか？
亀田：もともと自社サービスについて深く話すことってあまりなくて、興味を持った人に面白そうだなと思ってもらうため、入り口だけ話すというのは、昔からあまり変わってないですね。じゃあ、なにを話しているかというと、先ほど話したようなGoogle Core Web Vitalの課題に対してCloudflareがどのように役立つか、あるいはHTTP1.1、2、3などの進化にあわせて企業のネットワークはなにが必要になるか、などですかね。
大谷：じゃあ、基本はけっこうWeb寄りの話ですね。
亀田：はい。とはいえ、先日Interopで話したのは、CloudflareのCDNの話ですね。
実はCloudflareのCDNってNGINXをどのように改造して、どんな感じに使っているのかといった技術的な仕様が公開されています。弊社のサーバーが32台で1つのIPアドレスを共用している話をしたのですが、久々に聴衆にはポカンとされました（笑）。
大谷：インターネットのエンジニアが集まるイベントのはずですが、今年の聴衆は経営者だったのかもしれないですね。
亀田：あと、セキュリティとコミュニティに関しては、1つ課題を持っています。
実はセキュリティだけで成立しているエンジニアコミュニティって 日本にはないんです。Security-JAWSはありますけど、あれはあくまでJAWS-UGという冠があってのセキュリティ部会。セキュリティベンダーのコミュニティで成功しているところってないと思います。
私もCloudflareユーザーグループで登壇して何度もセキュリティの話をしてみましたが、どうしても営業的な要素を払拭しきれないので、コミュニティの人たちと話しあっているところです。
大谷：どこらへんが問題なんですか？
亀田：エンジニアのわくわく感をこちらから引っ張り出せないんです。セキュリティだと、最初にリスクの話をすることになります。決して未来の話ではないので、聴衆が若干引いているのを私も感じているんです。HTTPの通信が2から3になるとなぜ速くなるのかという話はみんな前のめりになるんですけど、企業の情報漏えいの話になるとすーっと（笑）。
大谷：なるほど。まあ、AWSみたいにシステムをビルドしていくわくわく感とは若干違いますよね。セキュリティ系のエンジニアって、トンカン作る側のエンジニアと若干毛色が違う気もしますしね。
亀田：私もセキュリティベンダー出身ですが、毛色が違うのはよくわかります。自分の中ではすでに結論は出ているのですが、セキュリティのエンジニアって、若いときからNoを言う権利を持って成長してきたからです。
とはいえ、Webを高速化させたり、通信を最適化させることと、本来は処理を遅くするセキュリティが両立するというのが、Cloudflareの価値。だから、セキュリティを学べる場所を作らなければならないんです。そこらへんが今年後半のチャレンジですね。だいぶ苦労しそうな気もしますけど。
大谷：半年間くらい話してきて、以前に比べて大変になったことってあります？
亀田：AWS時代に比べて、深い専門知識は要求されるようになりました。自分の学習スタイル的には、最初はちょっと苦労しましたが、もう慣れましたね。
ただ、Cloudflareを使っている、あるいは使おうとしているお客さまって、ほぼクラウドをすでに使っているんです。そのうち半分くらいは、「あれ？亀田さんですよね」から打ち合わせが始まるので、得しているなとは思います。
あと、アーキテクチャという点では以前と比べて表現を変えているところがあります。クラウドのよさって、基本的にはマイクロサービスアーキテクチャだと思うんですが、セキュリティの世界だけは、WAF、DDoS、API保護、マルウェアスキャン、暗号化、VPNなど、バラバラで提供しているのはよくないと思うんです。アーキテクチャの基本的なモデルはマイクロサービス型のクラウドの疎結合モデルがよいと思ってますが、セキュリティに関しては集約型の方がよい。これは以前に比べて、考え方が変わった部分だと思います。
