■ゼロトラストセキュリティとは？
テレワークブームでオフィスのPCやNASへのリモートアクセスニーズが高まっている今日この頃、皆さんいかがお過ごしでしょうか。リモートワークといえばVPNが主流だと思いますが、昨今「ゼロトラストセキュリティ」とか「ゼロトラストネットワーク」という言葉が流行りだしているのを耳にされたことはありますでしょうか？VPNはファイアウォールの境界で認証をして、一旦くぐり抜けてしまえばあとは社内ネットワークに直接つないでいるかのようにLAN内のリソースにアクセスできる、というものです。一方ゼロトラスト（信頼）は社内ネットワークの端末や利用者も基本的に信用しないぞ、って考え方に基づいたセキュリティポリシーです。実際、情報漏洩事件の多くは社内LANへのアクセスが可能な人の犯行が最も多いんだとか。同じ社内につながっていても、各ファイルやWebアプリケーション（例えば経費申請とか人事管理とか）へのアクセス権は人それぞれで、結局そこでまた認証があったりして二度手間ですしね。またVPNがあることで、利用者に要求される手間やリテラシーやトラブルも増えますし、そもそもクラウドサービスとか使った社内システムだと社内LANにあるわけでもないし、とか、VPNは色々と時代にそぐわなくなってきているといえるのかも知れません。
ゼロトラストセキュリティの厳密な定義はググっていただくとして、今回はその考え方に基づいた実装の1つであるCloudflare Accessの紹介をしてみたいと思います。ゼロトラストはあくまで考え方なので、他社製品だと実装方法からして異なる場合もあるかと思うのでご了承ください。
利用者目線での価値としては、
社内リソースにアクセスするたびにVPN接続操作や使用後の切断操作がいらない
全てのデータを暗号化する負荷がない分、軽い、速い
会社ネットワークのファイアウォールに内向きのポート開放をしなくて良い
個人的な追加ポイントとして、
固定IPアドレスが1つでも複数のWebサービスを（80番ポートで）公開できる
v6プラスのような使えるポートが制限されているサービスでも（80番ポートで）サーバー公開できる
などかなと思います。特に2番目はルーターや自分の端末の性能がボトルネックになりがちで、せっかく速い回線を使っていても頭打ちになったりします。そもそも昨今の通信はHTTPS/TLSなどアプリケーションレベルで暗号化されていることがほとんどなので、それをさらにVPNの入口と出口で暗号化するのも無駄といえば無駄。雑な設定でZoomなどのクラウドサービスを利用するにもVPNを通って一旦社内LANを経由とかしてたらヒドいものです。
■Cloudflare Access
サービスを知ったきっかけはInternet Watchのこちらの記事です。
CloudflareといえばCDNの大手ですね。普通の人は直接意識することはないかもですが、世界中のコンテンツを世界中でキャッシュしていて、地理的に遠いサーバーの情報でも近所の複製サーバーからデータをもってきてあたかも近くのサーバーにアクセスしているかのように快適にしてくれるものです。動画配信サービスやゲームソフトのダウンロードなどが快適に利用できる下支えをしてくれるCDNの業者のひとつ。Akamaiほど老舗ではないけど、個人サーバーでも比較的手軽に利用できる無料サービスなどが充実している（ここポイント！）会社です。あと個人レベルだとオープンなDNSサービスとしてGoogleの8.8.8.8と並んで有名な1.1.1.1を無償提供しているのがCloudflareですね。
さて、このローエンド向けの無料サービスが得意な Cloudflare が提供しているゼロトラストセキュリティサービスが Cloudflare Accessを含むCloudflare Teamsとなります。50ユーザまで使える無料プランが提供されていて気軽に試して見ることができます。
以下、ある程度サーバ－構築をしたことある人向けですが設定手順に基づいて動作原理がイメージできるように解説していきたいと思います。前提として、いくつかのWebアプリケーションを社内または自宅内LANで運用しており、外からのアクセスにVPNまたはポート開放で賄っているとします。これをVPNを使わず、ポートに穴も開けず、より手軽に使えるようにできる というのが主旨です。ぶっちゃけゼロトラストセキュリティ云々は二の次 です（笑）。
ポイントはDNSを委譲するところ
Cloudflareにアカウントを作り、最初にする作業は自ドメインのネームサーバー管理を Cloudflareに移すことです。 Cloudflareがドメインレコードを自由に書き換える権限を持つことで、様々なサービスを実現しているのです。
例えば、hogehoge.comという自ドメインがあったとして、こんなドメインレコードが登録してあるとします。
hogehoge.com 123.123.123.1 mail.hogehoge.com 123.123.123.2 private.hogehoge.com 123.123.123.3
ネームサーバーをCloudflareに移すことで、Cloudflareはこれを自由に書き換えたり、新しいホスト名を追加できるようになります。ただし、Cloudflareのサービスをバイパスしたいレコードについては個別にロック指定しておくことができますので、メールサーバーは触らないで欲しい、みたいなことは可能です。こちらがCloudflare TeamsのDNS管理画面です。
「プロキシステータス」の列で「DNSのみ」というのが勝手にプロキシ（後述）を割り込ませないでねという意味になります。
逆に「プロキシ済み」となってるサーバーでアクセス制限の設定をすると、IPアドレスが別のものに差し換えられます。つまり利用者がホスト名でアクセスをしようとすると、一旦Cloudflareが用意するプロキシサーバーにつながります。そこに然るべき認証画面を割り込ませることでアクセス制限を実現するわけです。認証はホスト単位ではなく、パス毎に設定できます。例えば、「private.hogehoge.com/calendar/」を指定してやると、/calendar以下へのアクセスだけが対象になりますが、private/hogehoge.com/index.htmlなどは素通しのままです。1つのサーバーの異なったディレクトリに異なったWebサービスを動かしている場合、それぞれに別個の認証ポリシーを割り当てることができます。
実際にアクセス制限をしたページを開こうとすると、こんな認証画面が立ち塞がります。
ロゴや配色はカスタマイズ済み
認証方法も色々選べます。標準で一番簡単なのはワンタイムパスコードをメールに送る方式（Get a login code emailed to youのとこ）。メールアドレスを入れて「Send me a code」すると1回使い切りの数字列がメールで届きます。そのメールアドレスを受信できる人ならそれを読み取って次の画面に貼り付けて送信すれば認証完了です。これだけだと自分のメアドをもっている人なら誰でも入れてしまうので、設定画面で制限するメールアドレスやドメインを指定しておきます。例えばhogehoge.comドメインで制限すれば、なんちゃら@hogehoge.comのメアドをもつ人にしかコードが届かないということになります。ただこれだと毎回メールを開く必要があったり、下手するとVPNより面倒くさいですね。
なので私はMicrosoft 365の法人アカウントを作っているので、Azure ADが利用可能でしたので、それを設定しました。これで（企業や学校向け）Microsoftアカウントでログインすることができます。そちらで二要素認証などをしていれば当然ここでも要求されます。認証方法は他にもGoogle、Facebook、GitHub、G-Suiteなど名だたるSSO（シングルサインオン）システムが並んでいます。GoogleやFacebookが個人アカウントで使うかは不明。G-Suiteが別にあるからできるのかな？
ここまで元からあるサーバーにはなにも手を加えてないのに、サクっとMicrosoftの強固な認証システムを実装できてしまうというのがスゴいところです。ログインの有効時間も設定できるので、一度ログインしておけば一定時間はこの認証をバイパスして、あたかもVPNに入った状態かのようにサービスを利用することができます。またアクセス元のIPアドレスや国で制限することも可能です。Apacheのディレクティブでしていたような制限もGUIで簡単にできちゃうわけですね。
内向きポートを開放せずに実現する
さて、既存ホスト名でアクセスしようとした場合に、Cloudflareが書き換えたプロキシサーバーに転送され、そこで認証手続きを代行してくれる、ということがわかりました。社内のあらゆるシステムに共通の認証基盤を簡単に実装できるという点でも素晴らしいです。
しかし鋭い方ならお気づきでしょう。元のIPアドレスを直接叩かれた場合のアクセスについてはなにも防御されていない、と！Cloudflare側で認証してくれるから二度手間になると、元のサーバーの認証を切ってしまったりしたらエラいことになります。元サーバーへは常にCloudflareのプロキシーサーバーのIPアドレスからのアクセスだけを受け付けるようにアクセス制限をかけるのも手かも知れませんが、IPアドレスだけを条件にするのは危険でしょう。そもそもCloudflareのプロキシサーバーのIPアドレスブロックについても記述は見当たりませんでした。 サーバー証明書などの類も同様です。しっかり探せばあるかも知れませんが。
2022.11.24追記: IPアドレスブロックはたぶんこれ ですね。
で、これには別の対処方法があります。Impressの記事でも紹介されているcloudflaredというトンネリングプログラムを使う方法です。Linux、Windows、Macなどなんらかのローカルネット内部で可動するPCで起動させておく必要がありますが、社内サーバーの出力情報をCloudflareのプロキシーサーバーに中継してくれます。Cloudfrareのプロキシーがこちらにデータを取りに来る場合、待ち受け（IN方向）ポートを開放してやる必要がありますが、cloudflaredならそれが不要になります。社内に連絡員を常駐させるようなものですが、門は閉じておくことができるというわけです。
この方式を使う場合、Cloudflare上のDNSレコードに仮想ホストのレコードが割り当てられます。例えば、社内にプライベートIPでアクセスできるカレンダーシステム（192.168.0.200/calendar）をvirtual.hogehoge.com/calendarみたいなURLで公開できます。virtualというホスト名のホストマシンは実在せず、常にcloudflaredが中継するデータを（認証を通した上で）見せる専用のホスト名となり、CloudflareがDNS編集権を握っていることで、cloudflared側からの設定ひとつで簡単に追加することができるのです。
■待ち受けポートがいらないことの副次効果がスゴい！
さて、長々とCloudflare Accessの概要を書いてきましたが、ここからは個人的な副次効果についてです。先に書いてしまうと、
グローバルアドレスが1つかないような環境でも複数のWebサービスをポート番号指定なしで公開できる
v6プラスのような使用ポートに制限がある環境でも任意のポートで公開できる
というところです。
ウェルノウンポートを使う難しさ
ウェルノウン（well known）ポートとは、主要サービスがデフォルトとするポートです。例えばhttpなら80番、httpsなら443番などと決まっています。本来、URLでは「http://hogehoge.com:80」とか「https://hogehoge.com:443」などとコロンで区切ってポート番号を指定することでウェルノウンポート以外を使うことは可能です。省略した場合にウェルノウンポートが使われるのです。しかし世の中ポート番号の指定などという事例は認知度が低く使ってもらいづらかったり、実際問題としてスマホのキーボードだと記号や数字の切り替えが面倒だったりします。
例えば、社内にプライベートIPでアクセスできるカレンダーシステム（192.168.0.200/calendar）と経費精算システム（192.168.0.201/keihi）があったとします（別々のホストで運用）。外向けのIPアドレスが1つしかない場合、80番ポートも1つしかないので、片方をhogehoge.com:8080/keihiなどとすることになります（若い番号は他のサービスでウェルノウンポートに指定されてることが多いので、ケタが多くなりがち）。これを回避してすべてを80番ポートでアクセスさせたいと思えば、リバースプロキシサーバーを建てて、内部で振り分けるなどの工夫が必要になります。Cloudflare Accessはまさにこれを外注できるという見方もできるでしょう。別々のホスト名を割り当てることも簡単です。オープンソースのApacheなどで動いてVirtualHostなどを簡単にいじれるものなら1台で済ますこともできますが、例えば市販のネットワークカメラを複数公開したいなんて時はそれもできません。外部のプロキシならこれも簡単です。
次にフレッツ系の光回線とかで最近主流になっているIPv6 over IPoEをについて考えてみてみます。IPoEでIPv6通信をできるようにし、なおかつMAP-EやDS-LiteなどでIPv4 over IPv6が利用可能になると、従来のPPPoEを使ったIPv4よりも幾分高速になります（IPoEも利用者が増えてきて以前ほどPPPoEと比べて劇的に速いということもなくなってきてはいるようですね）。我が家のプロバイダはMAP-E方式のv6プラスです。この方式は自宅側のIPv4に変わってプロバイダ側でIPv4通信を受け取るIPアドレスが共有されている為、65536個あるポートの全てを自由に使うことができず、4096～65536番のうちの割り当てられた240個しか利用できません。ウェルノウンポートを含む4098番以下は公平に誰も利用できません。なので、どうしてもウェルノウポートを使いたい場合、通常、
設備側でも専有の固定IPv4アドレスが付与されるプランを使用する（高い）
別にPPPoEで固定IPv4アドレスが付与されるプランを使用する（遅い）
のどちらかを選ぶことになります。ウチが使っているプロバイダでは前者は+3,000円ほど。後者は1,000前後で契約可能なので、我が家は速度を妥協して後者にしています。ちなみに後者の場合、通常の内から外へのインターネット利用にはIPoEを使い、外向けサーバーの通信はPPPoE経由というより振り分けができるYAMAHAなど業務用の機能を備えたルーターを使ったりする必要もでてきます。
Cloudflare Accessを使えば、80/443番ポートのサービスがいくつでも
私はこのブログも含め一般向けのWebサイトはConoHaのレンタルサーバーに置いています。自宅のIPアドレスではあくまで自分や身の回り向けの非公開サービスを運用するのみです。それでもできれば80/443番ポートにしてURLをシンプルにしたいし、せっかくあるIPoE側に速いスピードで使えるようにしたい。またごく簡単な自作サービスにBASIC認証だけでない強固なセキュリティも装備したい。そんな事情にこのCloudflare Accessがカチっとハマった気がします。あらためてまとめると、
自宅のファイアウォールはIN方向のポート開放が必要ない
異なるホストでもすべて80/443番ポートで公開できる
IPoE経由でPPPoEより高速な経路を使って公開できる
SSO、IP制限など高度な認証システムを付与できる
LAN内アクセスとWAN経由でブックマークを共通化できる
無料
という感じ。とはいえ3つ目についてはまだ評価段階なのでなんとも。PPPoEを経由しなくていい代わりにCloudflareのプロクシサーバー（地理的位置は不明）を経由するので差し引きで本当に速くなるかは微妙。それでも時間帯で数Mbpsに落ちることもあるPPPoEよりはマシのはず、という現時点での想定です。またCloudflare側は当然IPv6に対応しているので、自宅からのトンネルがIPv4 over IPv6ではなく直接IPv6同士で通信したらさらに効率的なんだろうと思うんですが実際にどうなっているかは不明。cloudflaredのステータスだと相手先サーバーとしてはIPv4アドレスが見えているのでIPv6かどうかはなんとも。OSの優先設定やルーターのIPv6の外向きフィルターでブロックしていないかとか、cloudflaredにIPv6経路を強制するオプションがないかなど追々検証／調査していく予定です。とりあえず現状で使っている限りでは、「海外サーバー経由してんな」ってレベルの遅延は全く感じられません。様子見てよさげなら順次Cloudflare経由にして、PPPoEサービスは解約できたら1,000円／月浮かせられるなという感じ。
ブックマークの共通化についても補足します。例えばネットワークカメラにLAN内からアクセスするのに192.168.0.200だったとします（ポートは80から変更不可）。これを外からも見られるようポート開放するとすると、ルーターのIPマスカレード機能でグローバルIPアドレス:8080を192.168.0.200:80に変換します。ポート番号が違うので、仮に内向きDNSでprivate.hogehoge.comをいうホストを192.168.0.200に振り向けたとしても、LAN内では80番ポート、外からは8080番ポートを指定することになり、ノートPCやスマホなど内でも外でも使う端末ではそれぞれをブックマークして使い分けることになります。しかしすべてCloudflareのプロキシを使ってポート番号を共通化することで、この問題も解決します。内向きDNSでローカルIPを指すレコードを作っておけば、内部アクセスなのに一旦Cloudflareを回ってくる、といった経路になることもありません。
80/443番ポート以外は？
とりあえずWebサービスは使えそうだということがわかりました。では他のSSH（22番）とかRDP、VNC、SMBといったプロトコロルはどうなんでしょう？Internet Watchの記事によるとRDPはできるっぽいけど、接続元の側にもcloudflaredを入れて接続先LAN上のローカルIPアドレスも指定してやる必要がありそう。接続元も固定のネットワーク（例えば実家とか）ならRaspberry Piとかにゲートウェイ運用とかさせればヨサゲですが、ノートPCをモバイルルーターや公衆Wi-Fiで使うなんてことを考えるとやはりPC上にcloudflaredを稼働させて、localhostに向けてRDPする、みたいな形になりそう。それだとVPNの方が簡単じゃね？って感じになるような気もします。コロナ禍ではあまりノマドや帰省をしないので、RDPやVNCでリモートデスクトップ接続をする機会自体がほぼないのでこちらは保留。どちらかというとSMB（ファイル共有）くらいはしたいかもですが、これはローカルのファイル共有とポートがかぶるのでちょっとややこしいようです。たぶん次に試すとしたらSSHかなと。今は1つだけ外から入れるホストにSSHで入って、そこを踏み台に別PCにSSHするという感じ。まぁそれであんまり困ってないですが、個別ホスト名で直接入れるとやはり内外同じ感覚で使えるので便利かなと。ただまぁSSHは侵入を許すと危険なので、もともとウェルノウンポートで運用しないのが鉄則みたいなところもありますし、どうでしょうね。
そもそもWebアクセス時にWeb認証画面が出るのは手間として違和感ないですが、RDPやSSHする時都度認証するとしたらどうなんだろ。Web認証の必要な公衆Wi-Fiみたいな煩わしさはないんでしょうかね？
■まとめ
背景説明もしたのでかなり長くなってしまいましたが、とりあえずクローズドなWebアプリケーションをより使いやすく安全にすることが、アプリケーションに手を加えることなく実現できるので非常に有用なサービスだなと感じています。まだまだ機能がたくさんあり、もっと便利な使い方もきっとあるんだろうなと思いますが、何分公式も解説記事も日本語によるものがあまりなくて、少しずつ試していこうかなというところです。また続報などあればお知らせしていきたいと思います。オススメの使い方などあれば是非教えていただければ幸いです。
