Cloudflare Accessで明日から必要なオンプレとクラウドへのリモートアクセス環境をいますぐ構築する
ベルリンのしがひです。COVID-19渦はヨーロッパにも広がり、いくつかの自治体で地域封鎖などの緊急防疫が実施されています。
日本では通勤時の混雑と密集がハイリスクであること、また安倍首相が今週からの学校閉鎖を要請するという発表を行ったことで会社員の在宅勤務の必要性がますます高まり、Slack、Zoomといったリモートワークツールへ注目が集まっています。
しかしながらリモートワークはコミュニケーションに使用するツールのみで事足りるものではなく、業務システムやドキュメントへのアクセスが安全に確保されていることが必要で、実際のところ、全社員にこういったリモートアクセス環境を用意することへのハードルが高いのではないでしょうか。
今回はオンプレ、クラウドにあるシステムへのリモートアクセスを即興で構築する方法を実践します。差し迫ったリモートワーク対応のヒントになればと思います。
VPNを構築している時間も予算もない
オフィスLAN等の閉域へのリモートアクセスで一般的に使われているのは、SSLを使ったクライアント - サービスルーター型のVPNです。
User to Edgeで暗号化が行われるため安全とされ、多用されるSIですが、これには多くの問題があります。
- ユーザーのデバイスにクライアントソフトウェアのインストールが必要。
- リモートアクセスをするためだけにユーザー教育、マニュアルが必要。
- ASRなどの通信機器やライセンスが高額。
- 通信機器などのメンテナンス、管理が必要で、設計も複雑になりがち。
- 多くはLAN、WANのエッジへのピア接続で、クラウドにあるリソースへのアクセスは別途用意され管理が分断される。
- プロビジョニングに柔軟性がなく、機器のサイジングから入らなければキャパシティの拡張が困難。
AWS等のクラウド、VPC内にあるリソースへもSophos等のVM UTMを使ったVPNが盛んに構築されており、それほど状況は変わりません。
一方で、こんにちのオフィスには十分な帯域のインターネット接続とスイッチがあり、アップグレードもそれほど難しくありません。ましてオフィスユースにおいて、クラウド上にインスタンスがあるWANへのネットワークリソースの心配は皆無と言って良いです。
Nearly Zero Trustなネットワーク
こういった問題を解決するため、絶対的なトポロジを置かず、侵入されていることを前提に暗号化、分散処理、例外検知・防御の自動化を統合的に運用してネットワークの安全性を確保するZero Trustネットワークのアプローチが研究され、それを構成する方法論、サービスが出始めています。まだ途上ではありますが、GoogleのBeyondcorpはかなりの部分をカバーしています。
VPNオルタナティブに関してはZscalerのZPAが先駆者ですが、ユーザークライアントのインストールが必要なこと、プロプライエタリなプロキシアクセスであることから、構築の即応性が高いとは言えません。
CDN、DNSのフリーミアムサービスであるCloudflareは、Accessというリモートアクセスシステムを以前から提供していましたが、昨年のIPOを期にエンタープライズ製品のリパッケージを開始し、最近、Cloudflare for TeamsというSaaS型セキュリティ製品をリリースしています。CDN用に世界各地に建てられた無数のエッジ、1.1.1.1 で有名なDNS技術とプロキシの統合による実現度の高いNearly Zero Trustネットワークです。
前置きが長くなりましたが、これを使ってAWS VPC内のEC2インスタンスで動いているOrangeHRM(クラウド)と、ベルリンオフィスにあるThreadripper搭載機のファイルシステム(オンプレミス)へ、モバイル回線から一元的にリモートアクセスします。
今あるものをそれほど変えずに活用する
Direct ConnectやVPNを構築せずにクラウド上のリソースにリモートアクセスするのによく使われる手法は、アクセス元のIPアドレスをファイアウォールで制限して、アプリケーション側でBasic認証をかけるというものです。AWSの場合、セキュリティグループの設定で手軽に実現可能ですが、ユーザーが多い場合やモバイル回線などIPアドレスが変わる状況ではすぐに詰みますし、ネットワーク担当者が極めてマニュアルな対応を強いられ、ヒューマンエラーのリスクを常に抱えます。
DNSをプロキシにしてしまう
CloudflareのDNSはそれ自体を多機能なプロキシとして動作させることができます。
名前解決されたトラフィックが片っ端からオリジンに到達することをシンプルに防ぎます。そしてCloudflareのIPアドレスレンジは決まっているため、セキュリティグループにはこれらを設定しておけば、リモートユーザーのIPアドレスを心配することもありません。
認証を40秒で実装する
Cloudflare for Teams Accessは、このプロキシを使ってセッション認証をかけることができます。各種IDPに対応している他、メールによるOne Time PIN認証ができるため、すぐに支度できます。
取り急ぎ、One Time PIN認証を選択します。 | 会社のドメイン宛にしか認証メールを送りません。 |
会社のメールアドレスからきた認証要求に対してPINを返すので、ユーザーがパスワードを設定することも、管理者が事前にユーザープールを作っておく必要もありません。
hrm.xx.classmethod.deにアクセスするとDNSがログインページにリダイレクト。 | メール宛にPINが届きます。 |
PINでサインイン。 | 無事、HRMシステムにアクセスできました。 |
最低限の設定なのでCookieを使ったセッションで期間を30分と短めにしていますが、ユーザークライアントとプロキシ間はHTTPSが確保されています。もう少し本腰を入れるならサイト自体をSSL化してアプリとプロキシ間も暗号化、グループポリシーの登録、マニュアルで公開鍵JWTを使ったアプリの認可も実装しておきたいです。
変えられないものを変えずになんとかする
Windows10マシンの中にある特定のフォルダをファイルサーバー的に仕立ててそれをブラウジングするには、Caddyを使うとワンライナーでできます。実際にオフィス内のファイルサーバーへVPNなしでつなぎたい場合、まずはこのようなWebブラウジング化がおすすめです。
ダウンロードしたexeファイルをディレクトリにおき、以下のコマンドでDownloadsフォルダ以下をブラウジング化します。
D:\Users\shigahi> caddy file-server --browse --listen :80 --root D:\Users\shigahi\Downloads
しかしこちらをHTTPS化して外部に公開するには、Port :80と:443の開放が必要です。
ベルリンオフィスはコワーキングスペースMindspaceの店子なので、インターネット接続用のCPEには全く手を出すことができません。内部のリソースへはいわゆるNAT越えの通信が必要になってきますが、これを安全、高速、簡単に行うにはどうしたらいいでしょうか。
CloudflareにはArgoという通信フレームワークがあり、AkamaiのSurerouteのような低ホップ・高効率通信を行うArgo Smart Routingと、プロキシエッジとアプリケーション間を暗号化するArgo Tunnelなどで構成されています。
ArgoとTeams Accessを組み合わせることで、変えられない環境を変えずに高パフォーマンスなリモートアクセスを実現します。
軽量なTunnelエージェントcloudflaredのバイナリをダウンロードして、適当なディレクトリに配置しておきます。
ディレクトリからログインコマンドを実行します。
D:\Users\shigahi> cloudflared login
ブラウザが開くので、認可するとpemファイルがローカルにインストールされます。
以下のコマンドでトンネルを張ると、自動的にDNSにCNAMEが登録されて外部公開されます。
D:\Users\shigahi> cloudflared tunnel --hostname files.xxxxx.classmethod.de http://localhost:80
AccessにOrangeHRMと同じくアプリとして登録し、ポリシーを設定します。
Facebook認証もつけてみました。 | ログインすると、HTTPSで外部公開されたファイルシステムに入れます。 |
ローカルで作業しているかと見まごうばかりのパフォーマンスです。Argoを使うことでRDPも即、安全、高速にリモーアクセスできます。
設計と設定の単純さが安全と利便につながる
Zero Trustを目指すには、監視と例外検知をしっかり行うことが重要です。CloudflareはDNSを起点にログをとるため、ダッシュボードだけでも網羅性が高いです。またS3やSumologicへのログのプッシュがテンプレート化されていて、既存の解析基盤を活用することが容易です。
今回は急を要するリモートアクセス環境を構築しましたが、後から見た際にそれが適切に設計され継続的に運用できるかを考えると、単純であればあるほど従前のネットワークとの矛盾が少なく、全体としての安全性にも寄与します。
利便性も、巨大な投資と構築時間を要しないことが前提であれば、ユーザーが今日から使えることを志向することは自然で、軌道修正コストをおさえ、継続的な改善につながります。今回はサブドメインで作業しているので叶いませんでしたが、ユーザーが二つ以上のAccessアプリを使っている場合、自動的に統合されたログインポータルが出来上がります。
リモートワークのやり方を考えるのを機に、ネットワークの考え方も少し変えてみてはいかがでしょうか。
追記: Cloudflareさんの神対応で、AccessとArgo Tunnelをしばらく無償で提供できるようになりました。こちらからお問い合わせください。