SaaS アプリケーションは、今日のビジネス環境、とくにハイブリッドワークフォースの拡大において不可欠になっています。組織が柔軟な働き方を採用するなか、分散したチームの生産性を維持し、コラボレーションを促すには、SaaS アプリがシームレスでグローバルなアクセスを提供できることが重要です。
SaaS アプリケーションは、基盤インフラを管理する必要がなくなるため、IT チームの負担を大きく下げます。これらの責任を SaaS プロバイダーに委ねることで、組織はハードウェアとソフトウェアのライフサイクル管理やスケーラビリティの課題を気にする必要がなくなります。さらに、SaaS アプリケーションのサブスクリプションモデルは初期費用を抑え、導入の障壁を下げます。最終的には、レガシーアプリケーションと比べて総所有コスト（TCO）も低くなります。
これらの利点と同時に、SaaS アプリケーションは新たな課題とセキュリティリスクをもたらします。インターネットからアクセスできるため、不正アクセスとデータ漏えいを防ぐには、ユーザーとデバイスのセキュリティにより注力する必要があります。ユーザーのプロビジョニング（オンボーディング／オフボーディング）、適切なアクセス制御、デバイスセキュリティの制御と可視化は、信頼できるデバイス上の認可されたユーザーだけが社内アプリケーションにアクセスするために不可欠です。さらに、IT チームは SaaS アプリケーションの設定ミスを監視し、リスクの高いユーザー活動を可視化する必要があります。従業員が機微情報を含むファイルを公開共有したり、管理対象の SaaS アプリケーションを未承認のサードパーティアプリと連携したりすることが、IT チームの知らないところで起き得ます。
ユーザーが新しい SaaS サービス、とくに無料で人気のあるものに簡単に登録できるため、IT チームは従業員が使うすべてのアプリケーションを把握できないことがよくあります。この傾向は シャドー IT ↗ と呼ばれます。これらの非管理 SaaS アプリケーションは、意図的であれ偶発的であれ従業員に誤用され、IT チームの管理下にないアプリケーションへ機微データがアップロードされることで、データ漏えいにつながる可能性があります。
従来のキャッスルアンドモート（城と堀）セキュリティモデル ↗ を使おうとしても、SaaS アプリケーションには向きません。サービスとそのデータは、企業ネットワーク内のオンプレミスデータセンターに閉じなくなっているためです。この古いアプローチでは、セキュリティとパフォーマンスのトレードオフを強いられます。
- セキュリティを高めるために組織が取る戦略の 1 つは、IP 許可リストを実装し、セキュリティポリシーに従って検査・フィルタできる組織のデータセンター経由でトラフィックをルーティングすることで、SaaS アプリケーションをより広いインターネットから遮蔽することです。ただし、この方法はユーザー体験を損ないます。すべてのトラフィックを単一のデータセンター経由でルーティングすると、レイテンシが増え、帯域が下がります。
- 逆に、スプリットトンネリングでローカル VPN クライアントを迂回し、ユーザートラフィックをインターネットへ直接送ると、企業ネットワークの制御が迂回されるため（IP 許可リストも使えなくなります）、セキュリティと可視性が損なわれます。
ここで、Zero Trust フレームワークを実装する SASE（Secure Access Service Edge）アーキテクチャ が不可欠になります。グローバルなクラウドネットワークにセキュリティを集約することで、セキュリティとパフォーマンスのトレードオフがなくなります。ユーザートラフィックを、セキュリティのために単一の遠隔データセンター経由でルーティングする必要はありません。Cloudflare では、ユーザートラフィックは数百あるうち最も近いデータセンターでサービスへ入り、必要なセキュリティ制御を受けます。これらのセキュリティ制御は、不要なレイテンシを加えないようシングルパスアーキテクチャで実装され、Cloudflare ネットワーク全体で一貫して適用されます。
このデザインガイドでは、Cloudflare の SASE アーキテクチャが、SaaS アプリケーションへのユーザーアクセスと、その中のデータを、より効果的かつ効率よく保護できる方法に焦点を当てます。組織の Zero Trust 取り組みに Cloudflare をどう使えるかのより広い理解は、SASE リファレンスアーキテクチャ を参照してください。
このガイドは、良好なユーザー体験を維持しつつ、組織内で SaaS アプリケーションを安全に採用・導入したい IT およびセキュリティ担当者向けです。ID プロバイダー（IdP）、ユーザーディレクトリ、シングルサインオン（SSO）、データ損失防止（DLP）技術などの概念に慣れていることを前提とします。
学べること:
- 管理対象 SaaS アプリケーションへのアクセスを保護し、そのデータを守る方法
- クラウドメールソリューションを使うときの主な考慮事項
- 非管理 SaaS アプリケーションを可視化し、統制を取り戻す方法
このガイドは、次を含む Cloudflare の Enterprise 契約があることを前提とします。
- オンボード予定のユーザー数分の Cloudflare Zero Trust ライセンス
- クラウド受信箱のメールをフィルタするユーザー数分の Cloudflare Cloud Email security ライセンス
Cloudflare の理解を深めるための推奨資料:
- Cloudflare とは？ | Web サイト ↗（5 分で読めます）または 動画 ↗（2 分）
- ブログ: Zero Trust, SASE, and SSE: Foundational Concepts for Your Next-Generation Network ↗（14 分で読めます）
- リファレンスアーキテクチャ: Evolving to a SASE Architecture with Cloudflare（3 時間で読めます）
管理対象 SaaS アプリケーションは、IT が調達・承認し、従業員が業務に使う公式ツール群の一部です。IT は通常これらのアプリケーションを管理し、次の責任を持ちます。
- アクセスの保護: 認可されたユーザーとデバイスだけが SaaS アプリケーションにアクセスできるようにします。ユーザーのオンボーディングとオフボーディングの管理も含みます。たとえば、従業員が組織を離れたとき、アクセスは自動で取り消されます。通常は、SaaS アプリケーションを会社の ID 管理ソリューションと連携します。
- データ保護: SaaS アプリケーション内部からのデータ漏えいを防ぎ、データ侵害につながる可能性のあるユーザーの危険な行動を先回りして緩和します。
- 設定の監視: SaaS アプリケーション内の設定ミスを特定し、迅速に修正して、安全かつ効率よく動作するようにします。
- クラウドメールセキュリティ: クラウドメールの SaaS ソリューションを扱うときは、IT チームはとくに注意する必要があります。メールは攻撃の主要な標的であるため、フィッシングやその他のメールベースの脅威からユーザーを守るには、専用のアプローチが必要です。
このドキュメントの後半では、非管理アプリケーションの可視化と統制の方法を扱います。たとえば、マーケティング部門が IT やセキュリティ部門と連携せずに新しい CRM システムに登録して使い始める場合です。
SaaS アプリケーションへのアクセスを保護する簡単な方法の 1 つは、特定の IP アドレス集合からのアクセスだけを許可することです。これにより、ユーザーは特定のネットワークに接続し、そのネットワークからトラフィックを送出する必要があり、そのネットワーク上のアクセス制御がそのトラフィックに適用されます。
すでに IP 許可リストで SaaS アプリケーションへのアクセスを保護している組織は、専用 egress IP を使って Cloudflare へ容易に移行できます。ユーザートラフィックは Cloudflare からインターネットへ出て SaaS アプリケーションへ向かい、送信元は組織固有の IP アドレス集合になります。このアプローチは、SaaS アプリケーションへアクセスする前にユーザーが Cloudflare へ接続する、次のようなさまざまな方法をサポートします。
- ハイブリッド従業員: Zero Trust クライアントである WARP を使って Cloudflare に接続します。
- オフィス勤務のユーザー: ローカルネットワークに接続し、インターネット向けトラフィックを GRE または IPsec の Cloudflare WAN（旧 Magic WAN）トンネル経由で Cloudflare へルーティングします。
- 契約社員と外部ユーザー: Cloudflare データセンターでホストされる リモートブラウザ 経由で SaaS アプリケーションにアクセスします。
組織は、Cloudflare 起点のトラフィックが SaaS アプリケーションへ入れるよう、既存の SaaS IP 許可リストに新しい専用 egress IP を追加します。これにより、レガシーな接続方法を Cloudflare と並行して維持し、ユーザーを段階的に移行できます。すべてのユーザーが Cloudflare 経由のアクセスへ移行したら、レガシーインフラに対応する IP を削除して SaaS IP 許可リストを更新できます。
オンプレミスインフラの IP を使う場合と比べて、Cloudflare の専用 egress IP にはいくつかの利点があります。
- 専用 egress IP は地理的に配置できます。既存のインターネットブレイクアウトデータセンターの地理的場所に縛られず、選んだ地域の 1 つ以上の Cloudflare データセンターに置けます。
- ユーザーは常に 最も近い Cloudflare データセンター経由で Cloudflare に接続し、Cloudflare が SaaS アプリケーションへの経路を最適化します。
- 専用 egress IP は、Zero Trust の原則に従うポリシーでユーザートラフィックに割り当てます。Egress ポリシー を定義し、正しい IdP グループに所属し、かつ／または デバイスポスチャ チェックに合格したユーザーにだけ専用 egress IP を割り当てられます。そうでなければ、トラフィックは Cloudflare のパブリック IP 範囲から送出されます。その範囲が SaaS の IP 許可リストに含まれていなければ、SaaS アプリケーションへのアクセスは防ぎつつ、インターネット利用は継続できます。
- 専用 egress IP は、SaaS アプリケーションに到達する前にトラフィックが Cloudflare を通ることを意味します。そのため、ユーザーが認証したあとに、SaaS アプリケーション内のデータを守るセキュア Web ゲートウェイポリシーを追加しやすくなります。
Cloudflare では、管理対象 SaaS アプリケーションに Zero Trust Network Access (ZTNA) ↗ を適用できます。このシナリオでは、Cloudflare がアプリケーションの シングルサインオン（SSO） ↗ サービスとして動作し、ユーザー認証リクエストを組織の既存 ID プロバイダー（IdP）へプロキシします。これにより、アクセスを許可する前に、多要素認証 ↗ の要求、デバイスポスチャチェック の実装、リクエスト元の国の評価 など、追加の制限を重ねられます。
ほとんどの組織は、最初はセルフホストアプリケーション向けに Cloudflare の ZTNA サービス を使います。これを SaaS アプリケーションへ広げることで、セルフホストアプリと SaaS アプリの両方で次のように IT 管理が簡素化されます。
- 同じアクセスポリシーを使う
- 同じ IdP とデバイスポスチャ連携を活用する
- アクセスリクエストを一貫して監査する
IT チームは、アプリケーションからのユーザーのオンボーディングとオフボーディングでも、一貫した自動化プロセスの恩恵を受けます。すべてのアクセスポリシーが既存 IdP からの認証を使うため、ユーザー状態の変更は、セルフホストアプリケーションと SaaS の両方のアクセスリクエスト結果に自動で影響します。
組織内でユーザーが別のグループまたはチームへ移るシナリオを考えます。IdP 上のユーザーグループ情報が更新されるとすぐに、Cloudflare の ZTNA ポリシーがこれらの変更を動的に適用し、新しい役割に基づいてユーザーの SaaS アプリケーションへのアクセスがすぐに調整されます。これは SaaS アプリケーションのライセンス最適化にも役立ちます。たとえば、従業員が Salesforce を使う営業チームから、Salesforce へのアクセスが不要なチームへ異動した場合、ZTNA ポリシーはそのアプリケーションへのアクセスを取り消します。この自動化プロセスにより、以前ユーザーに割り当てられていたライセンスを回収でき、実際に必要な人だけがアプリケーションにアクセスできます。
最後に、SaaS アプリケーションはインターネット経由でアクセスできるため、ユーザーが認証に成功すればどのデバイスからでもアクセスできます。ただし、Cloudflare の ZTNA サービスを使うと、IT チームは ID チェックに加えてデバイスポスチャチェックを適用し、管理対象デバイスだけが SaaS アプリケーションにアクセスできるようにできます。よくあるユースケースは、アプリケーションアクセスを許可する前に IT が配布したデバイス証明書の存在を確認する ことです。
SSO をサポートしない SaaS アプリケーションや、すでに IP 許可リストで SaaS アプリケーションへのアクセスを保護している組織では、専用 egress IP の導入が、ユーザー体験を損なわずに SaaS アプリケーションのアクセスセキュリティを高める最も簡単な方法です。
アプリケーションへのユーザーのオンボーディング／オフボーディングを簡素化し、ZTNA ポリシーを標準化したい組織は、セルフホストと SaaS の両方に Cloudflare の ZTNA ソリューションを導入することを検討してください。そのような場合でも、重要な一部の SaaS アプリケーションには専用 egress IP が依然として有効なことがあります。egress ポリシーはネットワーク層とトランスポート層で動作するため、適用はほぼリアルタイムです。たとえば、外部エンドポイント管理ソリューションのポスチャ状態を考慮する、特定の SaaS アプリケーション向け egress ポリシーを考えます。デバイスが侵害され、ポスチャ状態が非準拠になると、egress ポリシーは一致しなくなります。その結果、そのデバイスのユーザーは SaaS アプリケーションへのアクセスを失います。トラフィックが専用 egress IP から送出されなくなるためです。
最後に、すでにすべての SaaS アプリケーションを SSO 用 IdP と連携している組織でも、同じ理由で一部のアプリケーションに専用 egress IP 付きの IP 許可リストを追加することを検討できます。
管理対象 SaaS アプリケーションへ ZTNA の原則を広げることで、適切なユーザーとデバイスだけがこれらのアプリケーションにアクセスできるようになります。一方で、アクセスしたあとに認可済みユーザーがデータを漏えいするリスクにも対処することが重要です。
これらのリスクを緩和するには、転送中のデータと保存時のデータの両方に制御を実装する必要があります。
前述のとおり、すべてのトラフィックはデバイスエージェント、Cloudflare WAN（CWAN）トンネル、またはリモートブラウザを使って Cloudflare 経由にできます。これにより、セキュア Web ゲートウェイ ポリシーで、SaaS アプリケーションへのアップロードまたはダウンロード時のデータを管理・保護できます。よくあるユースケースは次のとおりです。
- 管理対象 SaaS アプリケーションから、組織内の特定グループへ すべてのファイル または 一部のファイル のダウンロードを制限する。
- データ損失防止（DLP） プロファイルを使い、管理対象 SaaS アプリケーションからの機微情報を含むデータのダウンロードを制限する。
転送中のデータの保護について詳しくは、リファレンスアーキテクチャセンター を参照してください。
Cloudflare の Cloud Access Security Broker (CASB) は、API 経由で 主要な SaaS アプリケーション と連携します。連携後、Cloudflare はこれらのアプリケーションを継続的にスキャンし、セキュリティリスクを検出します。これにより、IT チームは、認可済みユーザーがインターネット上でファイルを公開共有するなど、データを過剰共有しているインシデントを検出できます。Google Workspace、Microsoft 365、Box、Dropbox では、API CASB は DLP プロファイルを使い、機微データの共有も検出できます。保存時のデータの保護について詳しくは、リファレンスアーキテクチャセンター を参照してください。
前述の対策に加え、IT チームは User Entity and Behavior Analytics (UEBA) ↗ 制御の導入も検討してください。Cloudflare は、組織にリスクをもたらし得る活動や行動を検出したときに、ユーザーに リスクスコア を割り当てられます。これらのリスク行動には、ユーザーが異常に多い DLP ポリシー一致を引き起こすシナリオが含まれます。これらの対策を実装することで、認可済みユーザーによるものであっても、管理対象 SaaS アプリケーションからのデータ漏えいリスクを大きく下げられます。
このデザインガイドはこれまで主に SaaS アプリケーションのユーザーに焦点を当ててきましたが、今日の SaaS データ漏えいの多くは、ユーザー行動ではなく IT チームによる設定ミスが原因であることに注意してください。これらの設定ミスが見過ごされると、SaaS アプリケーションと組織の両方が深刻なセキュリティリスクにさらされます。
これらのリスクは、Cloudflare の CASB で緩和できます。API CASB は設定ミスを継続的にスキャンして特定し、迅速な是正を可能にします。露出した認証情報、ローテーションが必要なキー、二要素認証（2FA）が無効なユーザー、SaaS アプリケーションへアクセスする未承認のサードパーティアプリなど、さまざまな問題を検出できます。
デバイスを乗っ取り、社内データへアクセスするためのフィッシング攻撃やマルウェア拡散キャンペーンは、通常メールを攻撃経路として使います。今日、大多数の企業は、オンプレミスサーバーからクラウドホストサービスへメールを移行しています。Microsoft 365 や Google Workspace などの組み込みセキュリティは優れていますが、攻撃手法の絶え間ない進化には追いつけません。そのため、多くの組織は既存のメールプラットフォームと連携する高度なメールセキュリティソリューションを導入します。
すでに説明したとおり、メールプラットフォームを保護するために ZTNA を導入すると、多くの利点があります。重要な利点の 1 つは、クラウドベースのメールサービスを使う場合でも、信頼できる管理対象デバイスだけにメールアクセスを制限できることです。通常は、Cloudflare で クライアント証明書 の存在を確認し、Crowdstrike や SentinelOne などの外部エンドポイント管理ソリューションでリスクが検出されていないことを確認します。
コンプライアンスまたは規制上の理由、運用管理または説明責任、あるいはデータ漏えいの可能性を下げるためにメール通信に厳しい要件がある組織は、自組織以外のメールテナントへのアクセスをブロックできます。これは Cloudflare Gateway の SaaS テナント制御 で実現できます。Cloudflare はトラフィックフローにカスタム HTTP ヘッダーを挿入し、Microsoft 365 と Google Workspace に、ユーザーが認証してよい特定のテナントを伝え、ほかのテナントへのアクセス試行をブロックします。
SaaS メールソリューションはネイティブのセキュリティ機能を提供しますが、その人気のため、攻撃者は受信フィルタ機能の脆弱性と限界を突こうとする高価値の標的になります。このリスクを緩和するため、IT チームはクラウドメールソリューションのネイティブ機能を、受信メールフィルタリング向けの専用ソリューションで補うことを検討してください。
Cloudflare の Email security ↗ は、メール内の悪意あるコンテンツや添付ファイルをスキャンし、攻撃者インフラと攻撃配信メカニズムをインターネット上で先回りして監視します。計画された攻撃の一部として悪意あるコンテンツをホストするために使われる、プログラムで作成されたなりすましドメインを特定します。このデータは、ビジネスメール詐欺およびベンダーメール詐欺（BEC ↗/VEC ↗）からの保護にも役立ちます。これらはペイロードがなく、正当なメールトラフィックに似ているため検出が非常に難しく、レガシーなメールセキュリティプラットフォームの弱点です。
既存のメールインフラへの Cloudflare の統合は柔軟で簡単です。インライン と API の導入オプションがあります。
インライン導入では、Cloudflare の Email security はメールがユーザーの受信箱に届く前に評価します（メールドメインの MX レコードを Cloudflare へ向けることで）。これにより、Cloudflare はメッセージを 隔離 してユーザーの受信箱に届かないようにしたり、メールヘッダーでメッセージをタグ付け してメールプロバイダーに扱い方を伝えたりできます（例: 大量メールを直接スパムフォルダへリダイレクトする）。Cloudflare は、疑わしいメールにより注意するようユーザーへ伝えるために メールの件名と本文を変更 したり、メール内のリンクを書き換え、リモートブラウザの背後でそれらのリンクを隔離 したりもできます。
API 導入では、Cloudflare の Email security は、メールプロバイダーで Journaling／BCC ルールを設定するか、API スキャンを通じて、メールがユーザーの受信箱に届いたあとでメッセージを確認します。その後、メールプロバイダーとの連携により、Cloudflare はユーザーの受信箱から フィッシングメールを撤回 できます。インラインモードと異なり、この導入方法はメールの隔離やメッセージの変更をサポートしません。ただし、既存のメールフロー運用を変えずに、複雑なメールインフラへ保護を追加する簡単な方法です。
これらのモードは同時に使い、メールセキュリティを強化できます。インラインモードは、メールがユーザーの受信箱に届く前に Cloudflare の Email security がスキャンとフィルタを行うことを保証します。最初は脅威としてフラグされずに通過したメールについては、Cloudflare が 定期的に再評価 します。これらのメールが後からフィッシングキャンペーンの一部と特定されると、API で自動撤回されます。この先回りのアプローチは、攻撃者が一見無害なリンク付きメールを送り、配信後に武器化して初期検出を回避する、遅延型フィッシング攻撃から組織を守ります。
Cloudflare は、クラウドメールサービスの可用性の確保にも役立ちます。TCP 接続と SMTP トラフィックを自動スケールしてメッセージスパイクを処理し、組織をメール DoS 攻撃から守ります。サービスはメッセージを自動でプールし、長時間キューに入れ、スパイク後は下流メールサービスの容量に応じて配信をスロットルします。このプールとキューの機能は、クラウドメールサービスの障害時にも有益です。
Microsoft 365 を使う組織は、環境に Cloudflare アドインを統合することで、メール経由の機微情報漏えいへの保護を強化できます。この統合により、IT 管理者は、セキュア Web ゲートウェイ（SWG）および API Cloud Access Security Broker（CASB）と同じ DLP プロファイルを活用する 送信データ損失防止（DLP）ポリシー を設定できます。
さらに、機微文書の分類と保護に Microsoft Purview Sensitivity Labels を使う組織は、これらのラベルを Cloudflare の DLP プロファイルに組み込めます。これにより、Microsoft Outlook で「Highly Confidential」とマークされた Microsoft Office 文書を含むメールを外部受信者へ送ることをブロックする、といった対象を絞ったポリシーを作成できます。これらの DLP プロファイルは、SWG と API CASB にも適用できます。
非管理 SaaS アプリケーションは、IT の承認や把握なしに従業員が使うもので、一般に シャドー IT ↗ と呼ばれます。この拡大する課題は、無料または低コストの SaaS アプリケーションの普及によって加速しています。これらのアプリは従業員の満足度と生産性を高められますが、次のような重大なリスクももたらします。
- データ侵害: 従業員は、セキュリティ制御なしにこれらのアプリケーションへ機微データをアップロードできます。シングルサインオン（SSO）や強力なパスワードプロトコルがなければ、データ損失や盗難のリスクは大幅に高まります。
- コンプライアンス違反: 規制対象の業界では、未承認の SaaS ツールの利用が法的・業界標準への非準拠につながり、罰金、法的措置、評判の損害につながる可能性があります。
- コストの増加: IT は通常、事業全体で SaaS サブスクリプションを管理することで有利な価格を確保できます。しかし、従業員が個人のクレジットカードで独自にサブスクリプションを購入すると、管理されないシャドー IT 支出と、組織全体のコスト増加につながります。
これらのリスクを緩和する最初のステップは、従業員がどの SaaS アプリケーションを使っているかを発見することです。従業員デバイスからのすべてのトラフィックが Cloudflare を通ると、一般的な SaaS アプリケーションの利用状況を示す レポートが生成されます。
この情報をもとに、IT チームは各非管理 SaaS アプリケーションの扱いを分析し、判断できます。
- アプリケーションを許可する: 組織にリスクがない場合、従業員の利用は許容され、追加対応は不要です。
- データ保護制御付きでアプリケーションを許可する: アプリケーションは許容できるがデータ漏えいリスクがある場合、適切なデータ保護対策を実装する必要があります。
- 管理対象 SaaS アプリケーションとして採用する: 組織にとって有益な場合は、IT 管理下に置く必要があります。
- アプリケーションをブロックする: 許容できない場合は、Cloudflare Gateway の DNS および／または HTTP ポリシーでブロックする必要があります。
非管理 SaaS アプリケーションのデータ保護は、管理対象 SaaS アプリケーションと似ていますが、焦点はデータのダウンロード緩和から、機微情報のアップロード防止へ移ります。これらのリスクに対処するポリシーは、Cloudflare Gateway で設定できます。よくあるユースケースは次のとおりです。
- SaaS アプリケーションへの 特定のファイル種類のアップロード を制限し、この機能を組織内の特定グループに限定する。
- データ損失防止（DLP）プロファイルを使い、機微情報を含むデータのアップロードをブロックする。
これらの対策に加え、非管理 SaaS アプリケーションには リモートブラウザ分離 も検討できます。このアプローチでは、ユーザーが特定の非管理 SaaS アプリケーションにアクセスしつつ、誤用を防ぐために それらのアプリケーション内での操作を制限 できます。
多くの SaaS アプリケーションは、ユーザーが業務に組み込みやすくするために、ビジネスモデルの一部として無料版を提供します。これによりアプリケーションの有用性が示され、企業レベルでの採用が促進されます（Cloudflare もこのモデルに従っています ↗）。以前は非管理だった SaaS アプリケーションを組織が正式に採用すると、IT チームがその管理を引き継ぎ、適切なサポートとベストプラクティスの遵守を確保します。これには、新しい SaaS アプリケーションを「管理対象 SaaS アプリケーションの保護」セクションで述べたすべての側面に合わせることが含まれます。
新しい SaaS アプリケーションを完全に採用したあと、コンシューマー版へのアクセスを制限できます。企業向け SaaS 版に一意のドメインがある場合、ほかのテナントドメインまたはコンシューマードメインへのアクセスは、Cloudflare の DNS および／または HTTP ポリシーでブロックできます。一部の SaaS ソリューションは、HTTP ヘッダーによる ネイティブのテナント制御 を提供します。Cloudflare Gateway の HTTP ポリシーで転送中のデータにこれらのヘッダーを挿入して適用できます。
このデザインガイドでは、SASE アーキテクチャ内で Zero Trust フレームワークを実装することで、組織が SaaS アプリケーションのセキュリティをどう高められるかを説明しました。Cloudflare を使うと、管理対象と非管理の両方の SaaS アプリケーションがもたらす課題に対処する包括的なソリューションを利用できます。ZTNA、専用 egress IP、CASB、堅牢なメールセキュリティ対策などの手法により、良好なユーザー体験を維持しつつ、安全なアクセス、機微データの保護、シャドー IT の統制を確保できます。これらの手法と、いつ適用するかは、下の図にまとめています。
