境界型セキュリティからゼロトラストへ〜 ZTNAとCloudflare Access

酒井剛

2023.04.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

今回はCloudflare Zero Trustのサービス群の中の一つであるCloudflare Accessについて紹介したいと思います。

はじめに

以前のブログでCloudflareが提供するSASEを実現するためのプラットフォームとしてCloudflareOneの構成についてご紹介しました。Cloudflare Accessは、この中で記載させていただいていたSASEの機能の一つであるZTNAの部分を主に提供するサービスとなっています。

SASEとCloudflare Oneのサービスについてまとめてみた ~全体像~

ZTNA（Zero Trust Network Access）

上記のブログでも記載した内容ですが、ZTNAとは以下のようなものとなります。

ゼロトラストセキュリティモデル（従来の境界型セキュリティではなく、ネットワークの内側・外側の両方に脅威が存在することを前提としたITセキュリティモデル）の導入を可能にする技術
以下のような観点でアクセスするリソースが正規なものであるか確認
- アクセスしてきたデバイスが社内承認済みのものかどうか
- デバイスに最新のセキュリティ対策ソフトウェアがインストールされているか
- デバイスがマルウェアに感染していないか
- ID／パスワードは正規のユーザーが利用しているか
- デバイスが通常と違うロケーションからアクセスしていないか
- 利用しているクラウドサービスに脆弱性がないか
- 不審な振る舞いが発生していないか

つまり、「守るべきリソース（社内のリソースや契約しているSaaSサービスなど）を、社内にいても社外にいても厳密な認証とアクセス制御を担保した上で、接続できること」がポイントとなります。

社外から社内リソースへのアクセス方法においては、VPNが考えられますが、VPNとCloudflare Access（ZTNA）の違いについても見ていきたいと思います。

VPNが抱える課題

全てのトラフィックがVPNを経由する
- VPNをONにすると基本的には全ての通信がデータセンターなどに設置したVPN終端装置を通ることになります。VPN機器周辺のトラフィックの輻輳やVPN機器のキャパシティによって、大きく遅延を発生させてしまいます。
ハードウェアを運用する必要がある
- 一般的にVPNを導入するには専用のVPN機器を設置する必要があります。VPN機器の障害はリモートアクセスの全断に直結するため運用保守に大きな人的リソースと運用コストが発生します。攻撃者から簡単にアクセスされてしまうような重大な脆弱性をVPN機器が持ったまま運用を続けているケースが多くあります。また、拠点が増える場合には遠隔地でルーターを設置する必要があったり、設定変更も各拠点毎に行う必要があります。
ビジネスニーズに伴ったアクセス制御ができない
- 従業員、契約社員、ビジネスパートナーなど様々なロールごとでアクセスさせたいリソースは異なります。VPN機器では、基本的にIPアドレスベースでのみ制御することができないため、様々なビジネスニーズに対応することができません。
外部からの侵入経路として標的にされてしまう
- VPN機器と接続するために、企業のファイアーウォールにインバウンド通信の許可ルールを追加する必要があります。攻撃者は応答可能な接続ポイントを探索し、脆弱性の悪用やパスワードによるアクセス侵害を試みます。
通信ログの可視性が不十分である
- デバイスとファイアーウォールの先に設置したVPN終端装置とで通信を暗号化するため、取得できるログにはどのアプリケーションと接続したかやどんなアクションがあったかなどの十分な可視性が得られないことが多いです。
ローミングに弱く接続性が不安定
- 携帯などのモバイル端末からVPNを利用している場合、利用者が移動することによってローミングが発生します。従来のVPN（SSL-VPNなど）ではローミングに弱くトンネルの再構築を繰り返すことで通信が不安定となってしまいます。

このようにVPNではセキュリティ、利便性、スケーラビリティ、運用面で多くの課題があることが分かります。

Cloudflare Accessが解決してくれること

マネージドサービス
- Cloudflare Accessではハードデバイスを必要としません。プライベートリソースに繋がるアタックサーフェスはCloudflareのサービス側に移譲することができ、脆弱性管理や可用性の確保のために人的・金銭的コストに悩まされることもありません。
ネットワーク分離
- インターネット回線を効率的に利用し、社内リソースに不要なトラフィックが流れることがありません。
SSOの利用
- Cloudflare Zero Trustによって保護されるリソースはIdP認証のSSO（シングルサインオン）を実現します。利用者側のストレスなく、セキュアな状態でリソースに接続することができます。
セッション単位でのアクセス制御
- 接続リソースごとに、アクセスする接続元の属性や状態によってアクセスの許可やアクションを制限することができます。
インバウンド通信を許可する必要がない
- 社内リソースはアウトバウンド通信によるトンネルを構築するコネクターを経由して接続されます。一切のインバウンド通信を許可する必要がないため、攻撃者からの侵入を困難にします。
Cloudflareのエッジで高速に接続される
- CDNでも信頼性の高いCloudflareプラットフォームにマルチキャストで接続することで最適な経路でアクセスすることができます。

やってみる

少し前置きが長くなりましたが、ここからCloudflare Accessで実現するZTNAの構築をしていきます。
基本的なアーキテクチャは、サーバーからCloudflareにトンネルを張って、クライアントのリクエストはそのトンネルを使って逆方向に通っていくかたちになります。

IdPを統合するため、保護対象のリソースへセッション単位で認証やユーザー属性に伴ったアクセス制御が可能となります。

Self-hostedアプリケーションを Access で保護する時の前提

自社で管理しているアプリケーションをCloudflare Accessで保護するには、ゾーンの権威DNSをCloudflare上で管理し、ドメインを公開する必要があります。
ドメインを公開すると言っても、アプリケーションをインターネット上に公開するという意味ではありません。
Access に登録するアプリケーションのFQDNはCloudflareにプロキシされIPアドレスは隠蔽されます。また実際のアプリケーションはアウトバウンドコネクションによりトンネルを構築しているため、インバウンドの通信の一切を受け付けません。（Accessに統合された認証やデバイスポスチャによって許可された通信のみを接続させます。）

ということで、以下の2つの設定を事前にCloudflare上で行います。

Cloudflareで権威DNSを管理するための設定
Accessに接続させるドメインまたはサブドメインをサイトとして登録

それぞれ、以下のブログでやり方を紹介しているのでご参考ください。

Cloudflareで権威DNSを管理するための設定：

Accessに接続させるドメインまたはサブドメインをサイトとして登録：

また、DNSをプロキシすることに関するメリットや考え方について、こちらのブログでも紹介しています。

Cloudflare Access導入のアーキテクチャ例

今回は、AWSのリソースをプライベートリソースと見立て、以下のようなアーキテクチャでZTNAを実現していきます。

Accessグループの作成

Accessで保護するリソースにアクセスすることができるグループを設定します。
事前にIdPを統合しておく必要があります。以下のブログはAzure ADの場合の統合例ですが、このようにIdPを統合しておきます。

統合が完了した後、Access Groupsで、接続可能な条件をグループ単位で管理することができます。統合したIdP認証の通過を条件にしたり、IdPのグループ、送信元IPから割り出される国など様々な条件をつけることができます。

アプリケーションを登録する

Applicationsでアクセスするリソースを登録します。初めにアーキテクチャの図にあったブログ用のアプリケーションを作成します。

Self-hostedを選びます。

アプリケーションの名前を設定して、アクセスする時のFQDNを設定します。ドメインは前の前提の手順でCloudflareのWebsitesに登録しているドメインの中から選択できるようになっています。権威DNSの設定と、サイトとして登録する、が未実施の場合は設定しておいてください。

このアプリケーションにアクセスする時に要求される認証方法を選択します。前の手順のIdPの統合や、EメールによるOTPの認証などを選択します。

次にポリシーの名前を入力して、前の手順で作成したグループを指定します。

追加のポリシーでアクセスするための条件を追加することができます。このように、IdPグループ・アクセス元のロケーション、デバイスポスチャなどのルールを付与することができます。

そのまま設定を進めアプリケーションの作成を完了させます。

次に、SSH用のアプリケーションを作成します。途中まではブログ用のアプリケーションと同じように設定していきます。

ここまで設定したら、最後にBrowser renderingの設定でSSHを有効にします。こうすることで、ウェブブラウザでSSHをレンダリングすることが可能になります。

コネクタからCloudflareにアウトバウンドでトンネルを張る

今回の例でいくと、AWS上のコネクタとなるインスタンスからCloudflareに向けてアウトバウンドでトンネルを張ります。
GUIとCLIでの設定方法の2通りがあります。今回はGUIでやっていきます。

Tunnelsでトンネルを作成していきます。

作成するトンネル名を決めて、作成します。

コネクタとなるインスタンスのOSを選ぶと、Cloudflareとトンネルを構築するためのエージェントのインストール手順が表示されます。

インストールのためのコマンドをコピーします。この設定画面はそのままで、インスタンスにログインし、インストールコマンドを実行していきます。

curl -L --output cloudflared.rpm https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-x86_64.rpm && 

sudo yum localinstall -y cloudflared.rpm && 

sudo cloudflared service install {token}

インストールした後、再度Cloudflareのコンソールに戻って設定を続けていきます。
Public Hostnameで先程登録したアプリケーションを設定します。

ブログ用のアプリケーションのFQDNとフォワーディングする先のプライベートアドレスと接続ポートを指定します。

Protect with AccessでJWTトークンを渡すように有効化して、ブログ用のアプリケーションを選択します。

続けてSSH用のアプリケーションの設定も行っていきます。
ブログ用アプリケーションとの違いは、FQDNおよびフォワーディング先のエンドポイントと、Protect with Accessは有効化しないようにして設定します。

トンネル設定のPublic Hostnameの設定をすることで、CloudflareのDNS設定でCNAMEが自動的に登録されます。
Public Hostnameで設定したFQDNにアクセスすると、Cloudflare上のトンネルエンドポイントに到達して、トンネルに引き込まれていくようになります。

アクセスしてみる

ウェブブラウザを開いて、Public Hostnameで設定したブログ用FQDNにアクセスします。
https://blog.{website}

認証方式で設定した認証方法で認証します。

認証が通るとプライベートなブログサイトにアクセスすることができました。

続いて、SSH用のFQDNにアクセスしてみます。
https://ssh.{website}

IdPの認証は先程通しているのでSSOによって、次のSSHの認証画面が表示されます。

SSHの認証も通るとウェブブラウザにレンダリングされたSSHにアクセスすることができます。

まとめ

CloudflareのZTNAソリューションでは、セキュアなアーキテクチャと厳密なアクセス制御によって、社内外問わずセキュリティを強固なものにしてプライベートなアプリケーションにアクセスすることができるようになりました。
Cloudflare Zero TrustではさらにWarpというエージェントを導入することができます。WarpではWireguardという次世代VPN技術を使うことで、モバイルなどで従来問題となっていたローミングによる接続の不安定の解消をすることもでき、その他に多くの利点を得ることができます。
ぜひ、Cloudflare Accessによって従来のVPNの課題を解決して、企業のゼロトラスト化を進めてはいかがでしょうか。