SASE で SaaS アプリケーションへのアクセスを保護する

SaaS アプリケーションは、いまの業務に欠かせないツールになっています。SaaS は IT とインフラの負担を減らす一方で、従来アーキテクチャでは扱いづらい新しいセキュリティ課題も生みます。多くの企業はいま、Zero Trust アーキテクチャ ↗ の導入途上にあります。Zero Trust では、アプリケーションをより強く守るために、ID、デバイス、ネットワークの情報を組み合わせます。

一方で SaaS アプリケーションのセキュリティは、自社プラットフォーム側に寄ることが多いです。保存データの暗号化や、アプリケーションの脆弱性で顧客データを漏らさないことなどです。この文書では、SaaS アプリケーションの制約の一部を、Cloudflare の Secure Access Service Edge（SASE）プラットフォームで補う方法を説明します。具体的には、Zero Trust Network Access（ZTNA）と Secure Web Gateway（SWG）に、既存の ID ベンダーおよびデバイスセキュリティベンダーとの連携を組み合わせます。

SaaS 向け SASE の具体策に入る前に、次の問いを考えます。SaaS はすでに安全ではないのか。Salesforce、ServiceNow、Microsoft などの大手は、シングルサインオン（SSO）向けの ID プロバイダー連携、すべてのアプリケーション通信への SSL/TLS、保存データの暗号化、包括的な監査ログなど、堅牢なセキュリティ機能を実装しています。ただし SaaS ベンダーは、自社アプリケーション内にセキュリティプラットフォーム全体を作り直すわけではないため、現代の Zero Trust アーキテクチャに必要な機能の多くは提供できません。

SaaS アプリケーションは、接続元デバイスのセキュリティポスチャを評価できません。有効な資格情報を持つ侵害済みノート PC と、適切に管理された社用デバイスは、同じように見えます。SaaS アプリケーションからデータをダウンロードしたあとは、データの行き先も、ダウンロード先デバイスが安全かどうかも見えません。SaaS の認証は、ユーザーを ID サービスへリダイレクトして外部化することが多いため、ユーザーがどう認証したかを SaaS 側は把握できません。信頼はすべて ID プロバイダーに置かれます。

こうした課題は、ネットワークアクセス制御の弱さでさらに大きくなります。多くの SaaS アプリケーションは、任意のインターネット送信元からの接続を受け付けます。オフィスなどに紐づく特定の IP アドレス集合だけに制限できる場合もあります。しかし、在宅のリモートユーザーや、アクセスが必要なパートナー・委託先までこの粗い制御を広げるのは難しいです。

Cloudflare の SASE プラットフォームは、SaaS アプリケーションの保護をより Zero Trust 寄りに進められます。デバイスポスチャ、ID 属性、細かなネットワーク所在地に基づく集中ポリシーを、1 つまたは複数の SaaS アプリケーションに適用できます。Cloudflare が新しいコーポレートネットワークになり、インターネット上の SaaS アプリケーションへのアクセスを、Cloudflare に接続したユーザーとデバイスに限定できます。要するに、クラウド上の新しいコーポレートネットワークです。

次の図は、SaaS アプリケーションへのアクセスが必要なユーザー、デバイス、ネットワークの間に Cloudflare がどう入るかを示します。セキュリティ機能を担う主なサービスは次の 2 つです。

• Zero Trust Network Access。Cloudflare を ID プロキシにできます。さまざまな ID プロバイダーでの認証を、1 つの SaaS アプリケーションに対して簡単に有効化できます。デバイスポスチャとネットワーク所在地に基づくアクセス評価も含まれます。
• Secure Web Gateway。SaaS アプリケーションへ向かうトラフィックがすべてゲートウェイを通ると、HTTPS 接続は Cloudflare で終端され、SaaS との間を流れるデータを検査できます。機密データを安全でない場所へ持ち出さないよう遮断できます。

上の図は、トラフィックが Cloudflare にオンランプするさまざまな経路を示します。ZTNA サービスが認証を担い、Secure Web Gateway が SaaS アプリケーションとの双方向トラフィックをフィルタします。

1. SaaS アプリケーションへの最初のリクエストは、SSO フローの一部として Cloudflare へリダイレクトされます。ZTNA サービスは、既存の ID プロバイダーに対してユーザーを認証します。
2. 認証の有無にかかわらず、送信元が Cloudflare でないトラフィックは、SaaS アプリケーションへのアクセスを拒否されます。
3. 管理対象外のデバイスでは、ブラウザ分離を使えます。SaaS にアクセスするブラウザは Cloudflare のサーバー上で動き、描画結果がユーザーのローカルブラウザへ安全に届きます。
4. 管理対象デバイスはセキュアトンネルで Cloudflare に接続するため、デバイスから SaaS アプリケーションへの通信はすべてフィルタされ、保護されます。
   1. これらのデバイスからのトラフィック認可には、Cloudflare エージェントのデバイスポスチャも使えます。
5. ローカルネットワーク上のデバイスで、インターネットトラフィックをすべてセキュアな IPsec トンネル経由で Cloudflare へ送る場合も、ネットワークから SaaS アプリケーションへのトラフィックはフィルタされ、保護されます。
6. その後トラフィックは Secure Web Gateway を通り、DNS ポリシーと HTTP ポリシーを適用できます。
   1. HTTP ポリシーでは、DLP プロファイルを使って、SaaS アプリケーションへのアップロードとダウンロードの両方を検査できます。
7. トラフィックは特定の IP で Cloudflare から出ます。SaaS アプリケーションは、そのアドレスからのトラフィックだけを許可するよう設定します。

次は、Cloudflare で Salesforce へのアクセスを保護するポリシーの例です。

最初のステップは、Cloudflare Gateway の egress IP ポリシー です。Gateway でフィルタしたユーザーに、購入した特定 IP を割り当てられます。次に Salesforce 側で、egress ポリシーの送信元 IP と一致するトラフィックだけを許可します。この組み合わせで、Salesforce へ到達できる経路は Cloudflare 経由だけになります。

これは Salesforce へのアクセス保護だけでなく、利用中の内容を適切に守るためにも重要です。次に、Sales または Executives グループのメンバーにアクセスを限定するアクセスポリシーを見ます。Crowdstrike 連携を使い、社用の管理対象デバイスであることを確認します。

次のポリシーは全従業員向けですが、アクセスを許可する前に、もう数ステップを加えます。

2 つ目のポリシーには、一時認証（temporary authentication）を加えます。リクエストが Sales または Executives 以外の人からのものと Cloudflare が判断した場合、管理者が明示的に一時アクセスを許可する必要があります。文脈としては、顧客情報が機密になり得るため、営業部門以外の従業員による Salesforce アクセスを守る用途です。

この進め方が重要な理由は次のとおりです。

• リスクの高いアクセス試行に人の確認を入れ、侵害されたデバイスや安全でないデバイスからの不正アクセスの可能性を下げます。
• デバイスが最高水準のセキュリティ要件を満たさない場合でも、正当なユーザーがアプリケーションへアクセスできる余地を残します。デバイス側のセキュリティ習慣を保つ動機にもなります。
• 加えて、ユーザートラフィックはすべて Cloudflare を通るため、機密データのダウンロード防止など、Web トラフィックポリシーで追加の対策を適用できます。

Cloudflare の SASE プラットフォームを使うと、SaaS アプリケーションへのアクセスポリシーを集中管理できます。デバイスポスチャとネットワーク属性も使えます。SaaS アプリケーションへは、Cloudflare 上に構築した新しいコーポレートネットワーク経由でしか届かない、という形にもできます。

• Cloudflare で SASE アーキテクチャへ進化する
• Cloudflare Access 向け ZTNA アクセスポリシーの設計
• クライアントエージェントを配らずにプライベートアプリへアクセスする