SASE - 自前の VPN サービスをやめる

企業ネットワークは、従業員が機密情報にアクセスするために使われることが多く、

社内 wiki などのプライベートなセルフホストアプリケーション、

HR システム、ソースコードリポジトリなどです。

一部のアプリケーションは SaaS としてクラウドへ移行していますが、

IT が運用・保守しているアプリケーションも残っています。

最近では、こうしたセルフホストアプリケーションの多くは Web サーバー上で動き、

プライベートデータセンターか、AWS などのパブリッククラウド、

Azure、Google Cloud にデプロイされます。これらのアプリケーションへのアクセスは通常、社内の

従業員に限られますが、パートナーや

業務委託先に制限付きアクセスを許可することも一般的です。従来のやり方では、ユーザーは物理的な

オフィスに来るかか、VPN でリモート接続して企業ネットワークに入り、

アプリケーションにアクセスしていました。

しかし、こうした VPN ソリューションはオンプレミスのハードウェアアプライアンスを使い、すべてのユーザー

リクエストがそこを通るため、ボトルネックとセキュリティリスクになります。

実際、最近は Cisco などの多くのオンプレミス VPN ベンダー、

Check Point、Fortinet が幅広い脆弱性を報告しており、IT

とセキュリティチームはシステムの更新に追われています。

ただし、別の方法もあります。

Cloudflare を使えば、これらの

セルフホストアプリケーションへの安全なアクセスを、当社の SASE プラットフォームで簡単に作れることをご存じですか。

これは Connectivity Cloud の一部です。

従来の VPN と似ていますが、はるかに

新しいクラウドのアプローチを使います。

従来のやり方をどう改善するかを見ていきましょう。

アプリケーションアクセスのセキュリティも強化します。

最初の目的は、ユーザーのブラウザーと

アプリへの接続と、ユーザーとCloudflare の間の接続です。

Cloudflare はその中間に入り、セキュリティポリシーを適用し、広大な

ネットワークでアプリケーションを保護し、応答時間も改善します。

まず、Cloudflare からアプリへの接続を作るために、

トンネルを使います。使える方法はいくつかあります。

オンプレミスネットワークは、IPsec やGRE トンネルで Cloudflare に接続できます。

既存のネットワーク機器を使うのが一般的です。

あるいは、アプリケーションが、Cloudflare がすでにサーバーを置いているデータセンターで動いている場合は、

同じデータセンター内で、お客様のサーバーから当社のサーバーへ直接

接続できます。ただしこの例では、ソフトウェア

エージェントを使います。小さなデーモンで、アプリケーションサーバーに直接インストールするか、

同じローカルネットワーク上の専用サーバーで動かします。

このソフトウェアが、Cloudflare への安全なトンネルを作ります。

そのため常に利用でき、トラフィックは

Cloudflare のネットワークとアプリケーションの間を流れます。

次に、ユーザーを Cloudflare に接続する必要があります。

この例では、公開 DNS を使います。

アプリケーションに公開ホスト名を紐付けます。

このホスト名へのリクエストはCloudflare に解決され、

Cloudflare がプロキシし、トンネル経由でアプリケーションへルーティングします。

ただし、少し待ってください。公開 DNS レコードと、サーバーへの直接トンネルですか。

ここで止めれば、この内部アプリケーションに

新しい公開ホスト名へ行くだけで、どこからでもアクセスできてしまいます。

ここで必要なのは、認証と認可を加えることです。

Cloudflare がアプリケーションへのアクセスの手前に入ったので、

既存の会社の ID プロバイダーと統合できます。

アクセスしようとする人は、まずID プロバイダーへリダイレクトされ、

認証します。ここが面白いところで、同じアプリケーションの前に複数の

ID プロバイダーを置けます。

たとえば、従業員アカウントがすべて入っているメインの会社ディレクトリを使い、

業務委託先、パートナー、その他の第三者ユーザー向けに、別の ID サービスも

統合できます。

Facebook、

Google、GitHub などのコンシューマー向けID プロバイダーもサポートします。実際、SAML や OAuth の ID サービスなら

どれでも使えます。こうした ID 連携は、認証だけではありません。

ユーザーとグループの情報も取り込みできます。

次のステップにつながります。

ユーザーが認証されたことを確認できたので、

ID 情報やその他のデータを使い、

誰がアプリケーションにアクセスでき、誰ができないかを定義するアクセスポリシーを作れます。

ここで、ポリシーをリアルタイムで作ってみましょう。

アクセスを許可または拒否する対象を定義するために、さまざまな属性を使えます。

まず ID プロバイダーを追加したので、ユーザーは最初に認証が必要です。

もう少し進めて、同じ ID

サービスからグループ情報を使います。正社員グループのユーザーだけが

社内 wiki にアクセスできる、とできます。ID サービスは、どう認証したかも教えてくれます。

それをポリシーに追加しましょう。

要件として、MFA（多要素

認証）で認証している必要があります。さらに、具体的に

FIDO 認定キーなどのハードウェアトークンを使う必要があるとしましょう。

最後に、カナダ、

米国、ドイツから作業しているユーザーだけにアプリケーションへのアクセスを許可します。

ポリシーに、これらの国に位置するIP アドレスからの

トラフィックだけを許可すると追加します。これで、カナダのどこかで働いている正社員で、

強力な認証情報で認証した人は、

会社の wiki にアクセスできます。実際の動きを見てみましょう。

ユーザーは公開ホスト名にアクセスし、

認証するだけです。これで完了です。

ブラウザーだけで、世界中のどこからでも、プライベートにホストされた

アプリケーションにアクセスできます。シンプルです。従来のやり方とは大きく違います。

また、ブラウザーからアプリケーションまでのすべてのトラフィックは、

標準の TLS と SSL 暗号化で保護され、アプリケーションデータは安全です。

次に、パフォーマンスに少し目を向けましょう。

Cloudflare は従来の VPN よりはるかに効率的だと、すでに述べました。

ドイツから wiki にアクセスしようとする人を考えてみましょう。

Cloudflare は Anycastネットワーキングを使います。

つまり、ホスト名へのリクエストは、最も近い Cloudflare データ

ユーザーからアプリケーションまでの高速な接続を確保できます。

ドイツのユーザーは、ベルリンのデータセンターで Cloudflare に接続し、

カナダのユーザーはバンクーバーで接続するかもしれません。

リクエストの認証とポリシー評価は、すべてエンドユーザーの近くで行われ、

許可されれば、最も効率的なネットワーク経路で、

アプリケーションに最も近いCloudflare データセンターへルーティングされます。

パフォーマンスをさらに上げるために、できることはほかにもあります。

Cloudflare の既存のパフォーマンスサービスとネットワークの利点は、すべて

アプリケーションのトラフィックに適用されます。たとえば、Cloudflare の

キャッシュ技術を使い、wiki の画像、

ファイル、動画などの静的データを、ユーザーがアクセスしているデータセンターにローカルキャッシュできます。

従来の VPN ではできなかったことです。

企業全体の内部アプリケーション基盤の移行も、

長くはかかりません。VPN と違い、各アプリケーションへのアクセスでは、その

特定のサービスだけが公開されます。SSH や RDP をファイアウォールで遮断する心配は不要です。

Cloudflare は HTTPS 経由で、特定のアプリケーションへのアクセスだけを許可するからです。

これをネットワークのマイクロセグメンテーションと呼び、横方向の移動で

アクセスが広がる懸念を大きく減らせます。認証ポリシーの変更はダッシュボードで簡単にでき、

わずか数秒で、グローバルネットワーク全体が更新されます。

ご視聴ありがとうございました。

この動画は、新しい企業ネットワークをCloudflare の SASE プラットフォームで構築する方法を

説明するシリーズの一部です。

詳しくは、このシリーズのほかの動画もご覧ください。

こんにちは。Cloudflare の Simon です。

この動画を見つけていただき、おめでとうございます。

アプリケーションセキュリティなど、幅広いトピックも扱っています。

企業ネットワーキングや、インターネット上のあらゆる開発者向けコンテンツです。

オンラインでフォローしてください。ご視聴ありがとうございました。