Cloudflare のドキュメントの多く（この分野のベンダー一般も同様）は、Zero Trust 製品の導入が既存環境からの移行を前提に書かれています。まだ何も構築していない場合や、チームが達成したい目標を満たすツールがない場合、この前提は分かりにくく、疎外感を生むことがあります。特に新しいスタートアップは十分な情報がありません。事業の立ち上げに全力を注いでいると、ネットワーク変革中の大企業向けに書かれたドキュメントを読むのは時間がかかり、混乱しやすいです。
本ガイドでは、セキュリティ、ネットワーキング、開発運用の実践を整える早い段階で、Cloudflare を使って Zero Trust アーキテクチャの基盤を築く方法を説明します。目標は、Zero Trust セキュリティの原則の上に、持続可能でスケールする事業を作ることです。
「事業を作る」という一般的な原則は、根本から変わっています。20 年前は、オフィス（またはガレージ）を借り、ハードウェアインフラ、サーバー、ユーザー端末を買い、構築を始める形でした。構築が進むと、ハードウェアを積み上げたファイアウォールやセキュリティアプライアンスを追加し、主に 1 か所に存在する資産を守る企業境界を作ります。ネットワーキングとセキュリティの変遷については優れた記事が多数あるため、ここでは繰り返しません。重要なのは、構築中のスタートアップにとって「新しい」モデルがなぜ重要かを認識することです。
今日、インフラの大半はパブリッククラウドプロバイダー上にある可能性が高いです。コードの大半は一般的なリポジトリ管理ツール経由で push とレビューされ、開発者の大半は macOS または Linux マシンでコードを書き、ローカル開発ではコンテナ化に大きく依存します。このモデルでも Zero Trust セキュリティの原則は同様に重要です。しかも、事業が複数の複雑な機能、部門、拡大する資産とデータへ成長するときは、達成しやすくなります。
Cloudflare Zero Trust は、スタートアップが事業とともに自然に成長する包括的な Zero Trust 戦略を組み立てる、シンプルな（場合によっては無料の）方法です。
Cloudflare には、Zero Trust 製品セットの移行と実装に関する既存コンテンツが多数あります。本ドキュメントは、最初のコード行から、現代的なセキュリティ制御を備えた現代的な企業ネットワークの枠組みを作りたい、若いスタートアップの技術創業者と創業エンジニアに直接向けています。
本ドキュメントでは次を扱います。
- 実用的な Zero Trust リモートアクセス（ZTNA）から始める
- アイデンティティとデバイスポスチャの信頼できる情報源を定め、使い方を学ぶ
- 従来型とメッシュの両方のネットワーク構築
- 社内ツールへ Zero Trust を組み込む
- インターネット上の脅威を確認する
- TLS 復号と、目標との関連
- SaaS ツール向けの Zero Trust を検討する
- 契約社員と顧客アクセスを扱う
- Infrastructure as Code で構築する
本ドキュメントで明示的に扱わない内容:
- 基本的な Zero Trust 用語と概念の入門
- 特定のサードパーティベンダーの推奨または非推奨（本ドキュメントで他ベンダーに触れる場合は例示のみであり、Cloudflare の公式推奨ではありません）
- Zero Trust セキュリティ手法を採用すべき理由の詳細（下記リンクに十分な資料があります）
- マイクロセグメンテーションと自律的な Zero Trust の概念（今後の更新で扱う可能性があります）
- パスワードレス認証（発展中の分野です。今後、推奨を追加します）
Cloudflare の基礎理解を深めるには、次の資料を推奨します。
- Cloudflare とは？ | Web サイト ↗（5 分の読み物）または 動画 ↗（2 分）
- ブログ: Zero Trust、SASE、SSE: 次世代ネットワークの基礎概念 ↗（14 分の読み物）
- リファレンスアーキテクチャ: Cloudflare で SASE アーキテクチャへ進化する（3 時間の読み物）
リモートアクセスやセキュリティの目標を考える前に、現状の資産を把握することが重要です。次の問いに答えてください。
- すでに存在し、持続可能なセキュリティモデルが必要なものは何か。
- パブリッククラウドプロバイダーでインフラ構築を始めている場合、仮想プライベートクラウド（VPC）はいくつあり、互いにどう通信しているか。さらに重要なのは、ユーザーがそれらの環境へどのように、なぜアクセスしているか。
- すべてコンソールとブラウザーベースの管理、またはターミナルツール経由か。
- 一部のサービスに HTTPS または SSH 経由のパブリック IP アクセスを設定したか。
- 完全にプライベートであるべきリソースが、インターネットからのアクセスを許しているか。
- 環境へのリモートアクセス用に従来型 VPN を導入し、どのようにゲートしているか。
次に、物理および仮想のプライベートインフラ（会社データを含むものすべて）のマップを作ります。多くのスタートアップでは、単一のクラウドプロバイダーで実装されていることがあります。その環境で、人、他のインフラ、パブリックまたはプライベート API のいずれかがアクセスするリソースをすべて記録し、定期的なトラフィックがある各サービスの目的を文書化します。その過程で、次の問いに答えてください。
- ビルドパイプラインを監視する社内 Web ツールか。
- Grafana のようなセルフホストの分析ツールか、Prometheus のような支援メトリクスサーバーか。
- ユーザーはそのサービスへ、パブリック IP、プライベート IP、ローカルパスのどれで到達しているか。
- ユーザーは他のクラウド環境や VPC からそのサービスへ到達できるか。できる場合、どのように接続されているか。
既存リソースの包括的な一覧ができたら、それが Zero Trust アーキテクチャ構築の資産インベントリになります。守る対象が分からなければ、セキュリティツールがいくらあっても守るのは困難です。
有用な第 3 ステップとして、侵害時のリスクレベルでこれらのサービスを順位付けし、後でセキュリティポリシーの粒度を決める方法があります。たとえば、ビルド状態を通知する社内ツールはレベル 3、顧客情報の本番データベースはレベル 1 とします。レベル 3 アプリケーションは、アイデンティティ制御の要件を満たせば、ユーザー自身のデバイスからのアクセスを許可できることがあります。レベル 1 アプリケーションは、会社デバイスからのアクセスと、特定の多要素認証（MFA）を要求することがあります。
Cloudflare を使う多くのスタートアップは、投資家、パートナー、ベンダー、リスクアナリスト、コンプライアンス担当者といった外部から Zero Trust セキュリティ姿勢の採用を促されます。外部主導のプロジェクトや評価であっても、測定可能で望ましい効果を出すために、共通の目標を定められます。
お客様からよく聞く目標の例:
- 社内ツールへ、ユーザーが安全に簡単にアクセスできるようにする
- 開発パイプラインへセキュリティを組み込む
- ユーザー体験と作業体験を犠牲にせず、セキュリティを強化する
- bring your own device（BYOD）戦略を定義し、実行する
- ネットワークとアプリケーションアクセスの管理を簡素化する
- SaaS アプリケーションと企業ネットワーク上のデータを保護する
- 監査可能性を確保する（「何が起きているか、誰が行っているか、問題ないかをすばやく見る」）
- 顧客とエンドユーザーへセキュリティのベストプラクティスを示す
目標がこれより単純で戦術的な場合もあります。たとえば、現代的なリモートアクセスツールの採用、社内ネットワークの安全な接続、GitLab Enterprise テナントへの会社デバイスのみの接続などです。目標が何であれ、目標設定で最も重要なのは、今必要なものと、近い将来または中期に必要になりそうなもののバランスです。大幅な成長を見込む、厳しいセキュリティレビューを求める顧客と契約する、SOC II や PCI などの新しいコンプライアンス認証を申請する、といった場合です。これを達成するには、複雑さやコストを指数関数的に増やさずに追加のセキュリティツールと機能を重ねられる Zero Trust ベンダーから始めることが重要です。
目標設定は優先順位付けにも重要です。第一の目標が すべての社内サービスにアイデンティティ認識のセキュリティを置く ことであり、今後 6 か月で BYOD の利用をレベル 3 アプリケーションに制限する つもりなら、第一の目標は第二の実行を戦略的に支える必要があります。今後数か月の優先順位（スタートアップでは状況がすぐ変わることを踏まえて）を把握すると、再アーキテクチャの議論や、短期には合うが中期には合わないベンダーとの技術的・商業的判断の巻き戻しに費やす時間を減らせます。
アイデンティティは、あらゆる Zero Trust 戦略の中核です。最終的に、ほとんどの顧客目標は、ホストされたプライベートネットワーク上の「所有」アプリケーションと SaaS アプリケーションの両方にわたり、ユーザーが行うすべての操作を認証、検証、記録するための中心的なアイデンティティ源を使うことに集約されます。アイデンティティ（たとえば SSO プロバイダー経由）は、多要素認証やフィッシング耐性のある認証といった追加のセキュリティ制御を重ねるために使えます。
早期にできる最も重要なことの 1 つは、ユーザーが多要素認証に慣れるよう指導することです。物理キー、ローカル認証器、生体認証といったフィッシング耐性のある MFA は、2022 年に Twilio や他の SaaS 企業へ影響した侵害の試みを止めた ↗大きな要因として、Cloudflare が評価しています。
Zero Trust を始める文脈では、使うアイデンティティプロバイダーの種類（最も一般的なのは Google Workspace と Microsoft Entra Identity）は、実装戦略ほど重要ではありません。安全で、フィッシング耐性のある認証方法を許可し、信頼できる情報源として指定されたディレクトリがあれば、Cloudflare のような Zero Trust ベンダーと統合し、すべての企業ツールに対してアイデンティティをセキュリティ姿勢として継続的に問い合わせるために必要な要素はそろっています。
多くのディレクトリサービスは、SaaS アプリケーションと直接統合するシングルサインオン（SSO）も提供します。これは単純で論理的な選択ですが、多くのエンタープライズアプリケーションは SSO 統合を難しくし、1 つのディレクトリサービスへ大量の SaaS アプリケーションを載せることはベンダーロックインを進めます。組織が成長するにつれ、アイデンティティ戦略は必然的に変わり成熟します。2023 年に見られたベンダー侵害のような予期しない課題へ対応するため、柔軟性を保つことが重要です。
柔軟性の課題に加え、多くの SSO プロバイダーは、デバイスポスチャの概念を「信頼できる情報源」モデルへまだ十分に組み込んでいません。Okta のような一部ベンダーは認証イベントの一部としてマシン証明を提供しますが、Okta の FastPass 製品に限定され、会社デバイスの判定を深める他ソースや他ベンダーのシグナルは含まれません。
最後に、システムへアクセスするアイデンティティを常に自社が所有するわけではありません。外部監査人が自社のアイデンティティで認証する必要がある場合があります。契約社員が既存の GitHub アイデンティティでプライベート GitHub リポジトリへアクセスすることを許可する場合もあります。新製品インターフェースのプレビューを顧客に見せるなど、メールアドレスだけで低リスクのリソースへアクセスを提供する必要がある場合もあります。そのため Zero Trust ソリューションは、中心ディレクトリ以外のアイデンティティにもアクセスを許可する必要があります。
本ドキュメントの後半では、Cloudflare Zero Trust で社内アプリケーションを保護する方法と、SaaS アプリケーションの前に Cloudflare を SSO として使い、どこでもシンプルで統一されたセキュリティ姿勢を届ける方法を説明します。
この場合に Cloudflare が 重要 な理由は、アイデンティティプロバイダーの信頼できる情報源を決めたあと、ユーザー集団に対して継続的な認証を行うツールが必要だからです。このツールは構築と維持が難しく、2023 年に社内製の Zero Trust プロキシを廃止して Cloudflare へ切り替えた著名なテクノロジー企業も複数あります。管理の複雑さと、新しいセキュリティ機能を追加できないことが理由として挙げられています。
Cloudflare は、プライベートアプリケーション、ネットワーク、開発者サービス、SaaS アプリケーションに対するアイデンティティの単一の適用点になることで、アーキテクチャを簡素化できます。Cloudflare は、Web プロキシ（レイヤー 7 サービス）、VPN 代替（レイヤー 3/4 サービス）、セキュア Web ゲートウェイとして Zero Trust 認証の概念を提供できる数少ないベンダーの 1 つです。
事業が成長し、エンドポイントをユーザー集団へ配布する運用が始まると、デバイスポスチャは強い Zero Trust 戦略の重要な要素になります。ユーザーのアイデンティティ姿勢を検証したあとも、データ侵害のリスクをさらに下げる行動があります。考えてみてください。ユーザーが正当で、有効なアイデンティティセッションを持っていても、デバイスが感染している可能性があり、攻撃者は有効なアイデンティティセッションから利益を得る（または 乗っ取る）ことができます。
企業は、接続が信頼できるデバイスから来ていることを証明するためにデバイスポスチャを使います。一般的な戦略と始め方を列挙する前に、デバイスポスチャの理論を見ます。この例では、AWS のどこかに機密データがあります。このデータは事業運営に不可欠です。アイデンティティ認識の認証の背後で（正しく）保護されているため、適切なアイデンティティ姿勢を持つユーザーだけがアクセスできると確信しています。ユーザーはすべてリモートで、選択したエンドポイント検出応答（EDR）ソフトウェアを事前設定した MacBook から AWS へ接続します。エンタープライズ EDR を設定した MacBook 上のユーザーは、個人ラップトップから会社データへアクセスする場合より侵害リスクが低くなります。では、有効なアイデンティティ姿勢を持つユーザーが、侵害リスクの低いデバイスからのみ機密データへアクセスすることを、どう証明しますか。
セキュリティ組織が成長し、データ損失防止（DLP）の戦略とツールを実装し始めると、これはさらに重要になります。アクセスに使うデバイスへ証明の負担をかけずにユーザーが機密データへ理論上アクセスできると、意図的であれ過失であれ、セキュリティツールを迂回し、持ち出しリスク、少なくとも可視化と監査の死角を作れます。
一般的なデバイスポスチャ戦略は、エンドポイント管理ツール（JAMF、Intune など）、会社証明書、デバイス上の EDR ソフトウェアなどのセキュリティツールの組み合わせに依存することが多いです。このツールの一部は、対応していれば外部検証できる方法でデバイスをフィンガープリントできます。デバイスポスチャ検証付きの Zero Trust アクセス制御を達成するには、通常、Zero Trust ベンダーのエンドポイントエージェントをデバイスへ展開する必要があります。そのうえで、ポリシーに使うデバイス状態を適用する前に、サードパーティベンダーからの主張を「独立して」検証します。ベンダーを評価するときは、状態を比較的頻繁にポーリングできるかを確認することが重要です。状態の「継続的評価」という Zero Trust ポリシーの考え方に沿うためです。
Zero Trust セキュリティの成果のためにサードパーティベンダーを使い始めると、それらのベンダーは最良のセキュリティ判断のためにファーストパーティのシグナルを取り込む必要があります。この場合、Cloudflare はアイデンティティ姿勢に加え、デバイスポスチャのポリシー適用点になります。Cloudflare デバイスエージェントは、デバイスの所有または健全性メトリクスを評価し、ユーザーアイデンティティに関するポリシーと組み合わせます。機密リソースへのアクセスが適切なアイデンティティ検証を持ち、許容できるセキュリティ制御レベルの準拠デバイスから来ていることを保証します。
「旧世界」モデル（城と堀のセキュリティアーキテクチャとしても知られる）では、インフラはほぼ均質で、ファイアウォールで保護されていました。ネットワークリソースへアクセスするには、オフィス外のユーザー（または他の第三者、ベンダーなど）は VPN とファイアウォール経由でネットワークへ接続するか、パブリック IP アドレス経由の別のネットワーク経路を使う必要がありました。現在はインフラの大半がクラウドにあり、ほとんどのスタートアップはリモートファーストで始まるため、「企業ネットワーク」の初期設計では、従来のネットワーキング概念のほとんどが明示的には関係しません。
このより従来型のネットワーキングモデルでは、インフラは次のいずれかで構成されることが多いです。
- 1 つまたは複数の VPC に存在する（クラウドプロバイダーのトランジットゲートウェイで接続されている場合とされていない場合がある）
- サービスのアドレス指定は、おそらくクラウドプロバイダーが管理する
- AWS の Route53 DNS のようなクラウドプロバイダーの内部 DNS を使う（クラウドネイティブであっても、多くの事業は何らかの形で内部 DNS に依存し続ける）
- 自前のインフラを維持する限り、プライベートにネットワークされた空間の概念を残す理由は常にある
- すべてのユーザーが内部 DNS インフラを理解し、ナビゲートする必要はない可能性がある（ただし技術ユーザーとサービスは必要とする可能性が高い）
構築するインフラのパターンが定まると、単一の主要なクラウドプロバイダーに収束することが多いです。本ドキュメントで主に扱う概念は、ユーザーが社内リソースとサービスへアクセスするためにネットワークへ接続する方法と、社内サービスが広くインターネットと通信する方法です。クラウドインフラの権限とポリシーの管理、および社内サービス同士の通信方法の認識も包括的な Zero Trust 戦略に同等に重要ですが、本ドキュメントの今後の更新で詳しく扱います。
これは、大多数のスタートアップにとって最も一般的な Zero Trust ユースケースの 1 つです。「VPN ハードウェアを管理せず、事業をリスクにさらさずに、ユーザーを社内ネットワークまたはアプリケーションへどう到達させるか」と自問することがあります。Zero Trust 原則を守りながら、ユーザーをプライベートネットワークとサービスへ接続する最良の方法を考えるときは、次の 2 点が重要です。
- 露出の制限 — Zero Trust の考え方は、ネットワークやサービスへアクセスできる経路の数を制限することを組織に促します。パブリック IP アドレスやネットワークへのイングレス経路は、望まないリスクを招きます。通常は、認証済みトラフィックだけをネットワークへプロキシし、いかなるパブリック IP アクセスも必要としない、Zero Trust ベンダーへ接続するアウトバウンド専用プロキシで実現します。
- 横移動の制限 — 潜在的なデータ侵害の範囲を減らす最良の方法の 1 つは、すべてのリソースに最小権限アクセスを適用することです。最小権限アクセスは Zero Trust アーキテクチャの中核原則です。ユーザーは役割に必要なアクセスレベルだけを受け取り、企業ネットワーク全体への無制限アクセスは得ません。Zero Trust フレームワークに最も近い概念は「マイクロトンネル」です。アクセスが必要な各アプリケーションまたはサービスが、それぞれ独自の「ルート」を持つ推奨アプローチです。マイクロトンネルと同様に、最小権限アクセスは、明示したサービスとユーザーだけが特定リソースへアクセスする実践を可能にし、将来のセキュリティ組織を有利な位置に置きます。
インフラの作成と管理の明確な戦略と、予測可能な内部 IP および DNS レコード構造を定義することは、組織が成長するにつれ資産へアクセスし保護するために非常に価値があります。本ドキュメントの後半では、選択した Zero Trust セキュリティプロバイダーとすぐに統合できるインフラを、自動化ワークフローで作る方法を広げます。存在するインフラと現在のアドレス指定を継続的に把握していれば、アクセス制御モデルの上にセキュリティポリシーを重ねるのが大幅に容易になります。
Cloudflare Zero Trust は、エンドポイントソフトウェアとクラウドネットワーキングコネクタの組み合わせで、プライベートネットワーキングの概念をエンドユーザーへ拡張できます。この場合、Cloudflare を「オーバーレイ」ネットワークとして使い、パブリック IP を露出させず、クラウド環境からのイングレスを許可せず、リモートアクセスに通常伴う追加リスクも導入せずに、社内ネットワークへの安全なアクセスをエンドユーザーへ拡張できます。
この「オーバーレイ」ネットワークでは、小さなソフトウェアがネットワーク内にあり、「ネットワーク」トンネル（社内ネットワーク上のサービスへの管理アクセスを与え、従来の露出 Bastion の概念を置き換える）と「アプリケーション」トンネル（認証済みユーザーが、トンネルで定義した単一サービスへ明示的に到達することだけを許可するマイクロトンネル）の両方を提供します。
これにより、ユーザーにプロファイル変更、設定切り替え、1 つまたは複数のクライアントからの切断と再接続を強いることなく、複数の異なるプライベートネットワーキング環境へのユーザーアクセスを大幅に管理しやすくなります。また、Zero Trust 原則を守りながら、単一のプライベートアプリケーションまたはサービスを特定の対象へ簡単に公開できます。
ほとんどのスタートアップにとって、ネットワーキングは変更したい事項の上位にはありません。通常、事業は抵抗の少ない道をたどります。AWS や GCP で接続された VPC を管理し、物理拠点への外部接続をいくつか設定する程度です。しかし多くの事業は、成長の結果としてネットワークトポロジが急速に複雑になることに気づきます。
企業ネットワークを簡素化するとき、一般的な拡張には顧客ネットワーク、パートナー、マルチクラウド、買収、災害復旧計画などが含まれます。セキュリティ組織が成熟すると、（同じクラウド環境内でも）インフラを複数の VPC に分散する理由が増えます。それらの VPC のセキュリティグループが複雑になるにつれ、異なるポリシーと、場合によっては異なる運用を持つ複数の社内ネットワークを管理していることに気づきます。
これらのネットワーク拡張が事業にとって重要になると、どの接続オプションが最も妥当かを見直し、機能的に複雑で、根本的に安全なネットワークを構築する戦略を検討する価値があります。
ネットワーク接続の従来手法は、物理環境とクラウド環境の両方で依然として大きな価値があります。ただし、効果的なセキュリティ境界を維持しながら効率よく使うのは難しいことがあります。事業が支店や補助データセンターのような物理接続要件だけを持っていたときは、枠組みははるかに単純でした。ルーターやファイアウォールのようなエッジデバイスで物理接続を終端するか、専用のヘッドエンドデバイスで拠点間に VPN（「仮想」）ネットワーク接続を構築します。本質的には、初期拠点のすべてのマシンへ新しいネットワークまたはサブネットへの新しいルートを提供し、2 つの「ネットワーク」を接続します。
WAN 接続の作成に加え、複数拠点を橋渡しする最終目標は管理の単純さです。統一ネットワークは、エッジルーティング、ゲートウェイ、DHCP によるアドレス指定などのネットワーク機能を支えやすくします。一方で、ポリシー管理が過度に広くなることがあり、複雑さと固有シナリオが増えるネットワークのセキュリティ影響を管理するのは難しくなります。
現代のスタートアップでは、問題は上記とまったく同じではないかもしれません。それでも、増大するネットワーク複雑さへの対応は必要です。最良の方法は 効果的に計画すること です。セキュリティとスケーラビリティを念頭に企業ネットワークの構築を始めれば、セキュリティと IT 組織が成長するにつれ増大する複雑さを容易に解けます。
従来のネットワーキング概念は主にネットワーク同士の接続に焦点を当てます。一方、メッシュまたはピアツーピアのネットワーキング概念は、ネットワークを資産または独立したエンドポイント（ラップトップや携帯電話などのエンドユーザーデバイス、スマートライトやセキュリティカメラなどの IoT デバイス）へ接続します。
従来ネットワークでは、10.0.0.0/8 と 192.168.0.0/24 の IP 空間の間にサイト間接続を作る VPN トンネルがあり、どちらのネットワーク内のすべてのデバイスが、もう一方のネットワーク上のデバイスとローカルに通信するゲートウェイを持つことがあります。対照的に、メッシュネットワーキングモデルでは、特定の IP 空間だけが互いに通信すればよい場合があります。たとえば、10.2.3.4 が IP アドレス 192.168.0.50 のデバイスと通信できるようにします。
「マイクロトンネル」だけ（離散した X が離散した Y にだけ到達できる）で運用すると、横移動の機会を大幅に減らせます。たとえばメッシュネットワーキングモデルでは、IP アドレス 10.2.3.4 は別の 192.168.0.0/24 アドレス上の機密データへ到達できません（従来ネットワークモデルでは到達できることがあります）。ただし、この強化されたセキュリティ姿勢は複雑さも増やします。メッシュネットワークでは通常、関連する各エンドポイント上のエージェントを管理する必要があるだけでなく、各資産と接続経路向けの離散ポリシーを構築し管理する準備も必要です。
どちらの運用モデルも複雑で不完全に聞こえるなら、それは事実だからです。そのため Cloudflare は、あらゆる規模の事業にとって、通常は 2 つの混合が正しいアプローチだと考えています。
組織がメッシュ接続を試している場合、Cloudflare は離散的な接続モデルを支えつつ、独自のアイデンティティ概念を重ね、将来の成長を支えるネットワーキング枠組みを構築するときのセキュリティとスケーラビリティのニーズを支援できます。
スタートアップに最も関連することが多い Cloudflare 製品は、ユーザーデバイス上の Cloudflare One Client、プライベートサービス公開用の Cloudflare Tunnel（cloudflared）、双方向およびサイト間接続用の Cloudflare Mesh です。これにより、リモートアクセス、メッシュ接続、従来型ネットワーキング接続を 1 つのダッシュボードから管理できます。より細かくは、デバイスポスチャ情報、アイデンティティ情報、クライアント証明書、一般的な L4 指標（ポート、IP、送信元 / 宛先プロトコルなど）を単一のポリシー適用点から設定でき、人と自律的なネットワーク操作の両方に対して堅牢なセキュリティポリシーを構築できます。
このネットワーキングモデルの混合は、幅広いユースケースを支えるよう設計されています。企業ネットワークへのリモートアクセス、クラウド環境やオンプレミス機器を含む企業ネットワークの拡張、追加リスクやオーバーヘッドを導入せずに重要インフラ間のメッシュ接続モデルの構築、のいずれでも使えます。
Cloudflare が関わってきたほぼすべてのスタートアップ（および成熟企業）で、社内ツールのセキュリティは共通の課題であり続けています。事業固有の作業をこなすためにツールを自作することも、セルフホストやオープンソースソフトウェアを選ぶこともあります。後者はサービス、監視、その他の機能向けに人気の SaaS アプリケーションとしても消費されます。
前のセクションで示した原則は、これらのリソースへのリモートアクセスの管理方法を扱い、主に認証に関わります。要約すると、実践で Zero Trust モデルを達成するには、各社内サービスへのアクセスが継続的なアイデンティティ認証プロキシで制御されることを保証する必要があります。理想的にはネットワーク境界から物理的に分離され、明確な監査可能性を持ち、必要に応じてユーザーアクセスをすばやく取り消せるものです。
しかし、Zero Trust モデルの実装を始めるときに事業が直面する最大の課題の 1 つは、認証ではなく認可です。Zero Trust モデルでユーザーをアプリケーションの玄関まで連れて行くのは（比較的）簡単です。一方、認証と認可の両方の資格情報を管理し、両者が一致することを保証し、同時に前向きで非侵襲的なユーザー体験を維持するのは非常に難しいことがあります。
理想的には、認証と認可は同じサービスが扱うべきだと考えます。これは、社内アプリケーションの保護方法を検討するとき（OAUTH 機能を直接組み込むか、SaaS アプリケーションに使う主要な SSO と直接統合するか）に、認証方法がアイデンティティ検証方法と衝突したり重複したりしないかも考える、という意味です。これらの概念を使い、認証と認可でスケールする成功へ備える主な方法は 2 つあります。
「ベンダートークン」は、すべての Zero Trust または SSE ベンダーに存在する概念ではありません。これは Cloudflare の比較的独自のアプローチによるものです。世界最大の権威 DNS プロバイダーであるため、社内アプリケーションへの「外部」経路の DNS を提供し、そのうえでユーザーアクセス用のトークンを作成します。
これらのトークンは、そのアプリケーション向けのカスタムポリシーに一致した、成功した認証イベントのあとで Cloudflare がアイデンティティプロバイダーから受け取る情報に基づきます。各トークンには、ユーザーが IdP との認証イベントで署名される内容のすべてが含まれます。名前、ユーザー名、メール、グループ所属、その他存在する値です。特定アプリケーションとの関連を示す一意のタグも付きます。
Cloudflare トークンが作成されると、社内アプリケーションへ渡され、リクエストを検証し、社内ツールへのアクセスを認可します。アプリケーションごとの追加作業は最小限で、完全な OAUTH 統合または SSO 統合が必要だったアプリケーション作成ワークフローへ組み込めます。
Cloudflare トークンを使うと、ユーザーは確立した Zero Trust プロキシ経由の 認証 と、同じ情報によるアプリケーションへの直接の 認可 の両方で、継ぎ目のない体験を得ます。
一部の Zero Trust ベンダーは、事前構築された SSO コネクタを持つアプリケーション（オープンソースまたはセルフホストのソリューションなど）と直接統合する SSO プロバイダーとして動作できます。この流れでは、SSO がアプリケーションへの認可を制御し、Zero Trust ベンダーがアイデンティティプロバイダーへ呼び出して認証判断を行います。複数の主要なディレクトリを管理する必要はありません。
Cloudflare ユーザーにとって、これは複数の利点があります。認証（AuthN）と認可（AuthZ）の合理化、特定 SSO ベンダーへの依存の低減、複数の認証プロバイダーの同時利用です。最も重要なのは、新しいアイデンティティプロバイダーへの採用または切り替えが容易になることです。事業は 25〜50 ユーザー時点と同じアイデンティティプロバイダーを 300〜500 人以上でも使うとは限りません。1 つの SSO 統合から別の統合へのハードカットオーバーには、常に大きな摩擦があります。一部アプリケーションの SSO 統合にかかる時間とストレスを考えると、この移行は特に難しいことがあります。Cloudflare を SSO プロバイダーとして使うと、アイデンティティ、デバイスポスチャ、リスク統合をすべて単一のポリシー適用点に集約し、その摩擦を和らげられます。AuthZ/AuthN を合理化し、セルフホストアプリケーションの前に追加のセキュリティ制御を置けます。
社内サービスへのリモートアクセスには、ネットワーク内の Cloudflare Tunnel ソフトウェア経由で Cloudflare Access 製品を使うことを推奨します。Cloudflare Access では、Cloudflare Access が作成する JWT を消費するか、Access for SaaS を使い、SSO 統合が事前構築されたプライベートなセルフホストアプリケーション向けの SAML または OAUTH プロキシとして動作できます。
多くの場合、アプリケーションアクセスに両方の製品を使うこともあります。たとえば、現在パブリックインターネット上にない Sentry ↗ をセルフホストしている場合、次の手順に従います。
- Cloudflare Access でパブリックホスト名を設定します（ユーザーが Sentry へ到達する先です）。
- ローカルの Sentry サービスを指す、関連付けられた Published application 付きの Cloudflare Tunnel をインストールします。
- Sentry を Access for SaaS と SSO プロバイダーとして統合します。
これで、ネットワーク外からアプリケーションへ到達するユーザーはすでに Cloudflare JWT を持ち、アプリケーションへ継ぎ目なく認証されます。
企業ユーザーのリモートアクセスとして確立し受け入れられたパターンは、異質なユーザー集合へ常に拡張できるわけではありません。通常は契約社員、サードパーティベンダー、さらには顧客が含まれます。これらのユーザーグループはすべて、プライベートリソースと関わる正当な理由を持ち得ます。ネットワークまたはアプリケーションの一部へアクセスが必要な開発または保守の契約社員を雇うことがありますが、完全なネットワークアクセスを与えると不要なリスクが入ります。
顧客が自社ネットワーク内に展開するホスト型またはマネージドサービスを提供する場合もあります。その場合、適切に管理するためにそれらのサービスへ接続する必要があります。あるいは、自社環境内で顧客向けのプライベートリソースをホストし、関連テナントだけへの安全なアクセスを与える必要がある場合もあります。
第三者ユーザーが環境へアクセスする必要があると判断したら、まず次の 3 つの属性を決めます。
- 何へアクセスする必要があるか
- そのアクセスに必要な認証レベル
- このアクセスが有効な期間
スコープを決めたら、そのユーザーグループに適した最小権限アクセスモデルを決めます。認証イベントで使う二次アイデンティティプロバイダー（顧客またはベンダーの IdP など）との統合や、メールアドレスのみに対して認証するワンタイム PIN のような一時認証方法の利用が含まれることがあります。
一部の事業は、認証を合理化し、MFA などの認証要素の利用方法を制御するために、ベンダーと契約社員ユーザーを 自社の アイデンティティプロバイダーへ追加します。最低限、複数の認証方法を同時にサポートし、特定のポリシーまたはアプリケーション経由で適用できる Zero Trust セキュリティプロバイダーと働くことを推奨します。
これにより、既存の安全なリモートアクセスの方法をすべて一貫して保てます。外部ユーザー集団はネットワークへの同じ経路を使い、すべてのセキュリティ制御の対象になります。一方、どのユーザーが何へアクセスできたか、どれだけ頻繁にアクセスしたか、ネットワーク内でどのような操作をしたかを正確に示す詳細なログと監査証跡を受け取れます。最小権限制御の割り当ては、アクセスモデルを容易に確立し、ユーザーが不要な横方向の操作やネットワーク内リソースへのアクセスをできないようにします。
このアクセスを Web ブラウザー上で確立できず、ネットワークレベルの制御が必要な場合、外部ユーザーは Zero Trust 展開で使うエンドポイントエージェントを展開する必要があることがあります。たとえば、契約社員グループは 1 台のユーザーマシンに複数のエンドポイントエージェントを接続していることが多く、ネットワークルーティングの複雑さ、さらには異なる事業間でプライベートネットワークが重なる場合の衝突を招くことがあります。
第三者アクセスを確実にする単純で管理しやすいプロセスにするには、次を検討します。
- Zero Trust ベンダーは、エンドポイントエージェント展開向けの複数プロファイルをサポートできるか。 契約社員ユーザーは、ネットワークへのアクセスを限定し、デバイス上の他エージェントとの衝突リスクを抑えるために、厳密にスコープしたルーティング制御を持つべきです。
- 第三者アクセスは、企業ユーザーアクセスと実質的に異なるか。 異ならない場合、第三者向けの機能的なアイデンティティと統合を構築し、管理作業を合理化できます。すべてを監査し区別できる限り、新しいポリシーを必ずしも作る必要はありません。
企業ユーザーが顧客環境へ安全な（永続的または一時的な）アクセスを必要とする場合や、顧客がネットワーク内の固有のホスト環境へ同様の安全なアクセスを必要とする場合があります。このプロセスには、顧客向けソフトウェアテナントのホスト、顧客ホスト型ソフトウェアの保守実行、顧客の内部ネットワークへ結びつく製品機能向けコネクタの提供が含まれることがあります。
これらのユースケースでは、従来の推奨モデルはサイト間 VPN などのネットワーキング構成でした。適切にスコープできますが、企業ネットワークと顧客ネットワークの間で過度に広い接続になり、リスクや過度に広いアクセス能力を導入することがあります。
Zero Trust セキュリティフレームワークでは、この種のアクセスは最小権限モデルで明示的にスコープすべきです。アイデンティティ認識またはサービス認識のサイト間接続を設定するか、どちらの方向にも安全なアクセスを提供する一方向コネクタモデルを使い、特定の操作にスコープできます。
Cloudflare は、Zero Trust フレームワークで第三者ユーザーへ、Web とネットワーク接続の両方にスコープした安全なアクセスを提供できます。
- Cloudflare Access は 複数のアイデンティティプロバイダーを同時に 統合し、使えます。 単一のアプリケーションと単一のポリシーにスコープでき、一部のユーザーアクセスを特定の方法で認証するよう「強制」する細かい機能を持てます。目的の正当性 のような第三者固有のワークフローも多数あり、第三者にとってアクセスを容易にし、管理者にとって文書化と制御を可能にします。
- Cloudflare Zero Trust は、契約社員と第三者ユーザー向けの柔軟なエンドポイントエージェントパラメーターと 論理グループ で展開できます。 内部アクセスが必要な外部ユーザーを、厳密にスコープし、他の外部システムとの潜在的な衝突を抑えられます。
- Cloudflare Tunnel は、スコープした顧客リソースへ企業ユーザーがアクセスするための一方向アクセスモデルとして動作できます。 軽量で展開しやすく、デプロイパッケージへ組み込み、顧客環境で管理するサービスと並べて展開することもできます。
- Cloudflare Mesh（旧 WARP Connector）は、各クライアント制御に関連する安全で拡張可能なネットワークの構築を支援します。 顧客との関わり方、アプリケーションとのやり取り、その他の管理上の懸念のために双方向（サイト間）トラフィックフローが必要なときに特に有用です。Cloudflare Mesh は、展開の他部分と同じインラインセキュリティポリシー適用と監査制御を持つため、Zero Trust セキュリティ姿勢を維持しながら顧客接続を達成できます。
従来、Zero Trust アクセスの概念は、内部または特権リソースへのユーザーまたはマシンアクセスに明示的に限定されていました。機能レベルでは、ネットワーク拡張の置き換え、過剰権限の削減、VPN リモートアクセス接続から通常届く横移動と脅威ベクトルの最小化が必要です。しかし多くの事業では、VPN はプライベートネットワークトラフィックだけをプロキシしていませんでした。インターネットトラフィックも管理し、脅威の統一ビューを維持していました。通常は、DNS クエリをクラウドプロバイダーへ送るモジュール経由か、すべてのユーザートラフィックを企業ネットワークへバックホールして企業ファイアウォールへ送る方法です。
この城と堀モデルがもたらすセキュリティと複雑さの課題は、多くのベンダーに VPN が果たす 2 つの主要な機能への対応を強いました。現在、セキュア Web ゲートウェイ（SWG）と Zero Trust アクセス（ZTNA）は同じ文脈、または同じ製品の一部として語られるのが一般的です。
この転換はセキュリティ研究者ではなくベンダーとアナリストが主導しましたが、顧客のセキュリティ管理性を改善し、スタートアップの購入と展開プロセスを簡素化したように見えます。すなわち、企業トラフィックとインターネットトラフィックの両方を扱う単一エージェントの展開は、あらゆるセキュリティツールを扱う複数のデバイスエージェントを使うより大幅に改善です。
旧世界では、境界はパブリックなエグレス IP アドレスで示され、トラフィックがインターネットへ出る前に一連のセキュリティ制御の対象であることを意味しました。ファイアウォール、IPS、IDS、その他です。そのため事業は、トラフィックが「信頼」される前に特定の送信元 IP を要求し始めました。ベンダー、第三者、SaaS アプリケーションで使われました。企業ネットワーク（会社の送信元 IP）から発信されたトラフィックは、「信頼」の最大の指標の 1 つでした。今はそれほど単純ではありません。
今日、事業には中心となる「境界」がまったくない可能性が高いです。おそらくクラウドで始まり、生または何らかの事前設定されたセキュリティ制御付きでユーザーエンドポイントを出荷し、すべてをリモートかつ非同期に動かします。このモデルは生産性とスケール能力に大きく影響します。しかし、セキュリティ組織が成長し成熟すると、新しい境界を示すベースラインのセキュリティ「姿勢」を設定する本質的な利点があります。
Zero Trust プロバイダーと SSO が、ほとんどのプライベートアプリケーション、ネットワーク、サービス、SaaS アプリケーションを保護できる世界では、ユーザーはこれまで以上にどこからでも働けるべきです。ベストプラクティスに従えば、非同期で非常に効果的な働き方を中断する必要はありません。言い換えると、「安全な」エンドポイントの定義が、新しい企業境界になります。
明確に測定できる定義済みの安全なエンドポイントは、送信元 IP アドレスと異なり、高度に対象を絞り継続的に検証されるため、セキュリティ姿勢にとって大幅に優れています。旧世界では、これはファイアウォール経由でエグレスし、セキュリティ制御の対象になることを意味しました。新世界では、通常は暗号化の検証、デバイス上のポスチャの問い合わせ、マシンからのトラフィックがセキュア Web ゲートウェイで検査されたかどうかの判定を意味します。検証方法として送信元 IP アドレスをまだ含めることはできますが、主要な制御としては使いません。
BYOD の利用をどう管理し、会社データが安全にアクセスされていることをどう保証したいかを考えるときは、安全なエンドポイント戦略を何で構成するかを決めます。次に、この戦略に準拠していることを保証するために、機密リソースへのリクエストをどう問い合わせるかを考えます。たとえば、Workday（または他の個人情報の多いシステム）へアクセスするためにユーザーが取る手順を考えます。アクセスを許可する前に、トラフィックをセキュア Web ゲートウェイへ送り、データ損失防止ポリシーを適用したい場合があります。では、これらの要件を強制するために、他にどの手順が必要ですか。
この議論では、インターネットセキュリティ（セキュア Web ゲートウェイ、DNS フィルタリング、トラフィックプロキシなど）を、機密リソース向けにより正確で粒度の高い Zero Trust ポリシーを適用できる高度なセキュリティシグナルの集合として考えています。DNS フィルタリングはできるだけ早く始めるのも良い実践です。エンドポイントからのソフトウェア展開とトラフィックプロキシは、事業とセキュリティのニーズが成長するにつれ複雑になるだけだからです。HTTP フィルタリングやデータ損失防止のような他の高度なセキュリティ制御を考え始めるときは、トラフィックを復号する前に決めるべき判断を把握するために TLS 復号の開始 を読むことを推奨します。
社内アプリケーション、ネットワークリモートアクセス、SaaS アプリケーション向けの Zero Trust セキュリティ機能に加え、Cloudflare は次の機能も提供します。
- DNS フィルタリング
- L4 ファイアウォール
- セキュア Web ゲートウェイ（SWG） — アプリケーション認識、TLS 復号、データ損失防止、CASB 機能、ブラウザー分離、Cloudflare ネットワークから直接専用エグレス IP 構造を採用する能力を含む
すべての SWG 機能は、ユーザーアイデンティティ、デバイスポスチャ、ユーザーリスクを考慮するポリシーで制御され、Zero Trust 制御と同じエンドポイントエージェントから、同じポリシーエンジンとポリシー適用機会を使って提供されます。
Cloudflare は、管理対象エンドポイントデバイス上のアウトバウンドトラフィックを識別し、ポリシーを適用し、保護することで、機能的に新しい境界を構築できます。旧来の城と堀の境界と同じ統一セキュリティ制御を達成しつつ、独立した粒度の高いセキュリティ評価を適用できます（ただしユーザートラフィックのバックホールはありません）。そのセキュリティ評価を使い、Zero Trust で保護したアプリケーションからさらに強い制御を適用できます。低、中、高リスクのユーザーを区別し、BYOD トラフィックの扱いを判断する、などが可能です。
SaaS セキュリティの概念は、人によって意味が大きく異なります。そのため、特に Zero Trust との関係では議論の多い話題です。SaaS サービスは、リモートワークの大幅な増加により、COVID の第一波のあいだにユーザー数が急増しました。ほぼ一夜にして、企業インフラ外のサービスへ接続する方が、社内サービスへ接続するより簡単で実用的になりました。
SaaS アプリケーションは 1) SSO を統合すれば本質的に安全である、または 2) 保護する機能的責任は SaaS プロバイダーにある、という主張もあります。これらの主張は、SaaS 投資へのアクセスと保護の方法に答えますが、企業が SaaS を使う理由（通常は企業情報の保存）を文脈化しません。「機密データが存在する場所」の増加は、SaaS セキュリティの判断でますます重要な要因になります。
上記はすべて、ユーザーが関わる SaaS ツールを把握していることを前提にしますが、そうでないことも多いです。まず「承認済み」SaaS の採用を扱い、次に「未承認」SaaS（シャドー IT としても知られる）に関連する概念を説明します。
セキュリティポリシーを構築する前に、エンドユーザーに求めるセキュリティ姿勢を決めることが重要な第一歩です。そのため、大量の企業データ、またはコンプライアンス法やその他の規制の対象となるデータを含むアプリケーションがある場合、前述の「境界」に合うデバイスだけに制限するのが妥当なことがあります。
これを達成する最良の方法は、シグナルの集約器（Cloudflare の Access for SaaS など）を見つけ、セキュリティポリシーの個々の要素がユーザーアクセスに対して継続的に適用されていることを保証することです。従来の SSO ベンダーですべて達成できるでしょうか。場合によっては可能です。たとえば Okta の FastPass は、ローカルデバイスにインストールされた証明書を検証し、リクエストの送信元 IP アドレスを判定することでマシンアイデンティティを決めます。しかし多くの場合、FastPass はそのユーザートラフィックに存在するセキュリティ検査イベントや、エンドユーザーデバイスの健全性について、それ以上を伝えられません。この点で、SSO プロバイダーは、ポリシー判断のために消費できるデータ量と同じだけの有用さしかありません。
会社デバイスを示すのにマシン証明書だけ、または別のシグナル尺度だけが適切だと決めた場合、事業のセキュリティ成熟度のどの段階でもそれは妥当です。実際、多くの事業はまだいかなるデバイスポスチャも採用していません。
承認済み SaaS アプリケーションを管理する別の方法は、API 経由で Zero Trust ベンダーと統合することです。そのうえで、設定ミスや予期しない機密データの存在をスキャンできます。このプロセスは従来の Zero Trust アクセス制御とは独立していますが、ほとんどの Zero Trust ベンダーが提供し、すべての SaaS ツールに必要な継続的な設定変更を単一ビューで表面化できます。
管理する SaaS アプリケーション内の機密データの存在を評価すると、ポリシー優先度の感覚を育て始められます。言い換えると、BYOD 経由でアクセスできるものと、管理対象エンドポイントからの認可済みアクセスを要求すべきものについて、考え方が変わることがあります。あるいは、ユーザーを効果的に条件付けできるよう、BYOD アクセスのリスクをどう定量化するか、という問いです。
制御できる（SSO や他のサードパーティツールと統合できる）SaaS アプリケーションから、制御できないアプリケーションへ移ると、セキュリティモデルは大きく変わります。このカテゴリに入る SaaS アプリは、しばしば「未承認」アプリケーションに分類されます。SSO をサポートしない二次ベンダーが管理しているため、または IT 組織が利用（または機密データの保存）を明示的に承認していないサービスであるためです。これらの未承認アプリはシャドー IT と呼ばれます。
これらのアプリは環境内でどう増えるのでしょうか。論理は単純で、特にスタートアップではそうです。ユーザーは迅速に動きたいと考え、作業を完了する最も便利な方法へ引き寄せられます。審査や承認を受けていないツール（または機密データを保存する可能性があるツール）を使うことを意味することがあります。
シャドー IT は、通常は一般的なインターネットセキュリティプログラムの一部として扱われ、Zero Trust 展開と同じ検討集合（または同じベンダー）に入ることがあります。未承認 SaaS アプリケーションのリスク低減は、ほぼ常に可視化を中心にします。SSO や CASB ツールがアプリケーションと統合されていない状態でできる最も重要なことは、シャドー IT 利用の幅を理解することです。
未承認アプリケーションの文書化は、通常、DNS フィルター、セキュア Web ゲートウェイ、またはメール固有のツールのようなフォワードプロキシツールを必要とします。これらのツールは、どのユーザーが未承認 SaaS アプリと関わったか、場合によってはどのように関わったか（ファイルのアップロード / ダウンロード、転送した帯域など）についての洞察を提供できます。
SaaS 利用を文書化するポリシーと戦略を実装すると、SaaS ツール内で機密データがどう保存、移動、操作されるかについて、より良い理解を形成し始められます。一部の事業は SaaS の利用を明示的に承認した企業ツールに限定し、他はより寛容です。誤ったアプローチはありませんが、利用情報を捕捉する早期の枠組みを作ると、組織にとって差し迫った問題になったときに逆算しやすくなります。
この枠組みは、IT 組織がどのツールを調達サイクルの対象にするかの指針にもなります。たとえば、重要な人数のユーザーがすでにツールを使っている場合、シャドー IT のリスクを減らすため、またはチームがセキュリティ機能を強化できるようにするため、そのツールの Enterprise 機能を得るのが妥当なことがあります。コストを大きく変えずに済む場合もあります。
Cloudflare は、シャドー IT 環境とその後の発見の可視化と管理の基盤を設定できます。インターネットへのユーザートラフィックは Cloudflare One Client と Secure Web Gateway (SWG) から監査し整理でき、機密データが企業承認の SaaS テナント外へどこへ動くかを理解できます。
これは、新たに発見したツールを明示的にブロックまたは許可し、特定のデータセキュリティ制御を設定し、または（Access for SaaS のようなものを使いセキュリティポリシーを適用して）Zero Trust ベンダーと統合することで、Zero Trust 戦略をさらに広げる機会にもなります。
話す多くのスタートアップが最終的に気にするのは、ユースケースに対して複雑または過剰に見えるセキュリティツールを管理するために必要な人数と専門性です。開発ですでに行うことの多くはオーケストレーションツール、Infrastructure as Code、API 直接で管理されています。しかし、すべての Zero Trust（および他のセキュリティツール）プロジェクトをコードとして構築、管理、維持できる DevSecOps の状態を達成したいと考えることが多いです。
これは従来のセキュリティツールにとっては発展中の概念ですが、潜在ベンダーを評価するときの重要な検討事項であるべきです。Terraform のような概念は多くの Zero Trust ベンダーがサポートしますが、製品内のすべての概念向けのプロバイダーまたは API エンドポイントをサポート（または公開）していないことがあり、管理作業の重複や分断につながります。
組織の目標がネットワーキングとセキュリティスタックをコードとして管理することなら、Zero Trust の旅の早い段階でその枠組みを始めることが重要です。乗り越える課題はあっても、ネットワーク開発を先に進めることは、事業とセキュリティのニーズが必然的により複雑で管理しにくくなるときに配当を生みます。
Zero Trust または一般的なセキュリティイニシアチブ向けのベンダーパートナーを評価し続けるときは、製品ポートフォリオと管理制御全体に対して十分に文書化された完全な API エンドポイントがあること、および Terraform のようなオーケストレーションと Infrastructure as Code ツールのドキュメントがあることを確認することを推奨します。
Cloudflare は DevSecOps の文脈での Zero Trust セキュリティに強く取り組んでいます。すべての製品の主要な理念として API ファーストで構築し、機能提供の初日から関連するすべての API エンドポイントをお客様へ提供します。広範な ドキュメント ↗ も伴います。
別に、多くのお客様はダッシュボードに一切触れずに Cloudflare Zero Trust 展開を管理します。代わりに、管理プレーン全体に Terraform または類似ツールを使います。これが該当する場合、Zero Trust as Code を達成できる包括的で完全な Terraform プロバイダー ↗ があります。
結論として、セキュリティと認証の基本への会社の取り組みについて、今日いくつかの意図的な選択をすることが、今後何年もスタートアップに恩恵をもたらします。今下す判断は、事業の成長に合わせてスムーズにスケールする現代的なセキュリティインフラの基盤になります。どの道を進んでも、十分に情報を得たいくつかの動きが、持続可能でスケールする Zero Trust セキュリティ原則の上にスタートアップを築くことを保証します。
Zero Trust の要件をより詳しく議論し、アーキテクトの 1 人とつながりたい場合は、https://www.cloudflare.com/cloudflare-one/ ↗ を開き、相談を依頼してください。