スタートアップにおけるゼロトラストアーキテクチャの構築
Cloudflareのドキュメントのほとんど（および、一般的にこの分野のほとんどのベンダーによるドキュメント）は、ゼロトラスト製品を採用するには何かからの移行が必要であるという前提で書かれています。何も構築されていないシナリオや、チームが達成しようとしている目標を満たすツールが存在しない場合、これは時に混乱を招き、疎外感を生むことがあります。新しいスタートアップは特にサービスが行き届いていません。ビジネスを立ち上げるために全エネルギーを注いでいるとき、ネットワーク変革を進める企業向けに角度をつけたドキュメントを読むのは時間がかかるか、混乱を招くことがあります。
このガイドでは、Cloudflareを使用して、セキュリティ、ネットワーキング、開発運用の実践の早期にゼロトラストアーキテクチャの基盤を確立する方法を説明します。これは、ゼロトラストセキュリティ原則に基づいた持続可能でスケーラブルなビジネスを構築することを目指しています。
「ビジネス」を構築するための一般的な原則は根本的に変わりました。20年前、これはオフィススペース（またはガレージ）を取得し、ハードウェアインフラストラクチャ、サーバー、ユーザーマシンを購入して構築を始めることのように見えたかもしれません。構築が続くにつれて、ハードウェアスタックのファイアウォールやセキュリティアプライアンスを追加して企業の周辺を作り、主に一箇所に存在するものを保護します。ネットワーキングとセキュリティの実践の進化に関する良い文献はたくさんあるので、ここでその点を強調することはしません。重要な詳細は、スタートアップを構築する際に「新しい」モデルがどのように重要であるかを認識することです。
今日、あなたのインフラストラクチャのほとんどがパブリッククラウドプロバイダーに存在する可能性が高いです。ほとんどのコードは一般的なリポジトリ管理ツールを介してプッシュされ、レビューされ、ほとんどの開発者はMacOSまたはLinuxマシンでコードを書き、ローカル開発のためにコンテナ化の形式に大きく依存するでしょう。このモデル内では、ゼロトラストセキュリティ原則は同様に関連性があり、ビジネスが複数の複雑な機能、部門、拡大する資産とデータのセットに成長する際には、達成がはるかに容易になります。
Cloudflare Zero Trustを使用することは、スタートアップがビジネスと共に有機的に成長する包括的なゼロトラスト戦略を開発するためのシンプルで（時には無料の！）方法です。
Cloudflareには、ゼロトラスト製品セットの移行と実装に関連する多くの既存のコンテンツがあります。このドキュメントは、若いスタートアップ組織の技術的な創業者や創業エンジニアに直接語りかけ、彼らが最初のコードラインから現代の企業ネットワークのフレームワークを開発することを目指しています。
このドキュメントでは、以下のことを探ります：
- 実用的なゼロトラストリモートアクセス（ZTNA）機能の開始
- アイデンティティ、デバイスポスチャーの真実の源を確立し、それらを使用する方法を学ぶ
- 伝統的およびメッシュのネットワーク構築
- 内部ツールへのゼロトラストの組み込み
- インターネット上の脅威のレビュー
- TLS復号とその目標への関連性
- SaaSツールのためのゼロトラストの探求
- 契約者と顧客のアクセスのナビゲート
- コードとしてのインフラストラクチャでの構築
このドキュメントで明示的にカバーされていないいくつかのこと：
- 基本的なゼロトラスト用語と概念の紹介
- 特定のサードパーティベンダーの使用に対する推奨または反対（他のベンダーがこのドキュメントで言及されていますが、これは純粋に例示的であり、Cloudflareからの正式な推奨として受け取るべきではありません）
- ゼロトラストセキュリティ手法の採用を探るべき理由の詳細（その詳細については、以下のリンクに良いリソースがあります）
- マイクロセグメンテーションと自律的ゼロトラストの概念（これらは今後の更新でカバーされる可能性があります）
- パスワードレス認証（これはクールで新興の分野であり、将来的にここでいくつかの推奨を提供します）
Cloudflareの基礎的な理解を強化するために、以下のリソースをお勧めします：
- Cloudflareとは？ | ウェブサイト ↗（5分の読み物）または ビデオ ↗（2分）
- ブログ: ゼロトラスト、SASE、SSE: 次世代ネットワークのための基礎概念 ↗（14分の読み物）
- 参照アーキテクチャ: Cloudflareを使用したSASEアーキテクチャへの進化（3時間の読み物）
リモートアクセスやセキュリティの目標を考える前に、現在の資産を把握することが重要です。以下の質問に対する答えを考えてみてください：
- 何がすでに存在し、持続可能なセキュリティモデルが必要ですか？
- パブリッククラウドプロバイダーでインフラストラクチャの構築を始めた場合、すでにいくつの異なる仮想プライベートクラウド（VPC）を確立し、それらはどのように相互に通信していますか？ さらに重要なのは、ユーザーがそれらの環境にどのようにアクセスしているか、なぜですか？
- すべてコンソールやブラウザベースの管理またはターミナルツールを通じてですか？
- 一部のサービスに対してHTTPSまたはSSH経由でパブリックIPアクセスを設定しましたか？
- インターネットからのアクセスを許可するリソースがあり、それは完全にプライベートであることを意図していますか？
- 環境へのリモートアクセスを許可するために従来のVPNを確立しましたか？ それはどのようにゲートされていますか？
次に、物理的および仮想プライベートインフラストラクチャのマップを作成します（本質的に、会社データを含むもの）。多くのスタートアップにとって、これは単一のクラウドプロバイダーを介して実装されるかもしれません。その環境内でアクセスされるすべてのリソースを記録し、人間のユーザー、他のインフラストラクチャ、またはパブリックまたはプライベートAPIによってアクセスされるものを記録します — その後、定期的にトラフィックを受ける各サービスの目的を文書化します。そうする際に、以下の質問に答えようとしてください：
- これはビルドパイプラインを監視するために構築された内部ウェブベースのツールですか？
- Grafanaのような自己ホスト型の分析ツール、またはPrometheusのようなサポートメトリクスサーバーですか？
- ユーザーはそのサービスにどのようにアクセスしていますか — パブリックIP、プライベートIP、またはローカルパスを介してですか？
- ユーザーは他のクラウド環境やVPCからそのサービスにアクセスできますか？ もしそうなら、どのように接続されていますか？
既存のリソースの包括的なリストを作成したら、これはゼロトラストアーキテクチャの開発のための資産インベントリとして機能します。何を保護する必要があるかを知らなければ、どれだけ多くのセキュリティツールを持っていても、それを保護するのは難しいでしょう。
価値のある第三のステップは、侵害の際のリスクレベルによってこれらのサービスをスタックランク付けし、後でセキュリティポリシーの特異性を決定することかもしれません。たとえば、ビルドステータスを警告するための内部ツールはレベル3かもしれませんが、顧客情報のための本番データベースはレベル1です。レベル3のアプリケーションは、ユーザーがアイデンティティ制御要件を満たすことができれば、自分のデバイスからアクセスできるかもしれませんが、レベル1のアプリケーションは企業デバイスからのアクセスと特定の種類の多要素認証（MFA）の使用を必要とするかもしれません。
Cloudflareを使用する多くのスタートアップは、投資家、パートナー、ベンダー、リスクアナリスト、またはコンプライアンス担当者などの外部のソースからゼロトラストセキュリティ姿勢を採用するよう奨励されています。たとえこれが外部の関係者によって推進されるプロジェクトや評価であっても、測定可能で望ましい影響をもたらすために共通の目標を確立することができます。
顧客から聞く共通の目標のいくつか：
- 内部ツールをユーザーが安全にアクセスしやすくする
- 開発パイプラインにセキュリティを組み込む
- ユーザーと作業体験を犠牲にすることなくセキュリティを強化する
- 自分のデバイスを持ち込む（BYOD）戦略を定義し実行する
- ネットワークとアプリケーションアクセスの管理を簡素化する
- SaaSアプリケーションと企業ネットワーク内のデータを保護する
- 監査可能性を確保する（「何が起こっているのか、誰がそれを行っているのか、そしてそれが許可されているのかの迅速なビュー」）
- 顧客やエンドユーザーにセキュリティのベストプラクティスを示す
あなたの目標がこれよりもシンプルまたは戦術的である可能性もあります。たとえば、現代のリモートアクセスツールを採用する、内部ネットワークを安全に接続する、または企業デバイスのみがGitlab Enterpriseテナントに接続できるようにするなどです。どんな目標であれ、目標設定において最も重要な要素は、今必要なものを確立し、近い将来または中期的に必要になるかもしれないものとのバランスを取ることです。大幅に成長するつもりであれば、要求の厳しいセキュリティレビューを持つ顧客を獲得することを期待するか、SOC IIやPCIなどの新しいコンプライアンス認証を申請する準備をする必要があります。これを達成するためには、ゼロトラストベンダーから始めることが重要であり、追加のセキュリティツールや機能を重層的に追加するのに役立ち、複雑さやコストを指数関数的に増加させることなく実現できます。
目標設定は優先順位付けのための重要な演習でもあります。あなたの主要な目標がすべての内部サービスの前にアイデンティティを意識したセキュリティを特定し配置することであることがわかっている場合、しかし次の6か月でBYODの使用をレベル3のアプリケーションに制限するつもりであれば、最初の目標は2番目の実行を戦略的にサポートする必要があります。今後数か月の優先順位のスタックランクを理解すること（スタートアップでは物事が急速に変化することを知っている！）は、再アーキテクチャの議論や、短期的にはニーズに合うが中期的には合わないベンダーとの技術的または商業的決定を解決するために費やす時間を節約できます。
アイデンティティはすべてのゼロトラスト戦略の中心です。最終的に、ほとんどの顧客の目標は、中央のアイデンティティソースを使用して、ユーザーによって行われたすべてのアクションを認証、検証、ログすることに関連しています。これは「所有された」（ホストされた、プライベートネットワーク）アプリケーションとSaaSアプリケーションの両方にまたがります。アイデンティティ（たとえばSSOプロバイダーを通じて）は、その後、多要素認証やフィッシング耐性のある認証のような追加のセキュリティ制御を重層的に追加するために使用できます。
早期に行うことができる最も重要なことの1つは、ユーザーが多要素認証を使用することに慣れるよう指導することです。物理キー、ローカル認証、バイオメトリック認証のようなフィッシング耐性のあるMFAオプションは、2022年にTwilioや他のSaaS企業に影響を与えた侵害の試みを阻止する ↗のに重要な要因としてCloudflareによって評価されています。
ゼロトラストを始める際のアイデンティティプロバイダーの種類（Google WorkspaceやMicrosoft Entra Identityが最も一般的）は、実装戦略よりも重要ではありません。安全で、フィッシング耐性のある認証方法を許可し、真実の源として指定されたディレクトリがあれば、Cloudflareのようなゼロトラストベンダーと統合し、すべての企業ツールに対してそのアイデンティティをセキュリティ姿勢として継続的に調査するために必要なコンポーネントを持っています。
多くのディレクトリサービスは、SaaSアプリケーションと直接統合するためのシングルサインオン（SSO）ソリューションも提供しています。これはシンプルで論理的な選択ですが、多くのエンタープライズアプリケーションはSSO統合を難しくし、任意の1つのディレクトリサービスに対して重要な質量のSaaSアプリケーションをオンボーディングすることはベンダーロックインを引き起こす可能性があります。組織が成長し続けるにつれて、アイデンティティ戦略は必然的に変化し成熟し、予期しない課題に対処するための柔軟性を維持することが重要です。2023年に見られたベンダーの侵害のいくつかのように。
柔軟性に関連する課題に加えて、多くのSSOプロバイダーは、まだ「真実の源」モデルにデバイスポスチャーの概念を完全に統合していません。Oktaのような一部のベンダーは、認証イベントの一部としてマシン認証を提供していますが、これはOktaのFastPass製品に限定されており、企業デバイスを構成するものをよりよく判断するために他のソースやベンダーからの信号を含んでいません。
最後に、システムにアクセスするために使用されるアイデンティティを常に所有するわけではありません。外部監査人を雇い、彼ら自身の会社のアイデンティティを使用して認証する必要があるかもしれません。契約者が既存のGitHubアイデンティティを使用してプライベートGitHubリポジトリにアクセスすることを許可することを決定するかもしれません。リスクが低いリソースにアクセスするために、単にメールアドレスを持つ誰かにアクセスを提供する必要がある場合もあります。したがって、ゼロトラストソリューションは、中央ディレクトリを超えたアイデンティティがアクセスできるようにする必要があります。
このドキュメントの後半では、Cloudflare Zero Trustを使用して内部アプリケーションを保護する方法と、SaaSアプリケーションの前にCloudflareをSSOとして使用して、どこでもシンプルで統一されたセキュリティ姿勢を提供する方法について説明します。
Cloudflare は重要です この場合、なぜなら、アイデンティティプロバイダーの真実のソースを決定したら、ユーザーポピュレーションに対して継続的な認証を行うためのツールが必要だからです。このツールは構築と維持が難しく、多くの著名なテクノロジー企業が内部で構築したゼロトラストプロキシを廃止し、2023年にCloudflareに切り替えたことがその証拠です。管理の複雑さや新しいセキュリティ機能を追加できないことが理由として挙げられています。
Cloudflareは、プライベートアプリケーション、ネットワーク、開発者サービス、SaaSアプリケーションに対するアイデンティティの単一の強制ポイントとなることで、アーキテクチャを簡素化できます。Cloudflareは、ウェブプロキシ（レイヤー7サービス）、VPNの代替（レイヤー3/4サービス）、およびセキュアウェブゲートウェイとしてゼロトラスト認証の概念を提供できる数少ないベンダーの一つです。
ビジネスが成長し、ユーザーポピュレーションへのエンドポイントの配布を運用化し始めると、デバイスポスチャーは強力なゼロトラスト戦略の重要な要素となります。ユーザーのアイデンティティポスチャーを検証したら、データ侵害のリスクをさらに減らすために取ることができる他のアクションがあります。考えてみてください：ユーザーが有効でアクティブなアイデンティティセッションを持っていても、理論的にはそのデバイスが感染している可能性があり、攻撃者はその有効なアイデンティティセッションを利用（またはハイジャック）することができます。
企業はデバイスポスチャーを使用して、接続が信頼できるデバイスから来ていることを証明します。デバイスポスチャーの理論を見てから、いくつかの一般的な戦略とアプローチをリストアップしましょう。この例では、AWSのどこかに機密データがあります。このデータはビジネスの運営にとって重要です。アイデンティティを意識した認証の背後で（正当に）保護されているため、適切なアイデンティティポスチャーを持つユーザーのみがアクセスできると自信を持っています。ユーザーはすべてリモートで、選択したエンドポイント検出および応答（EDR）ソフトウェアで事前に構成されたMacbookからAWSに接続します。企業のEDRソフトウェアで構成されたMacbookのユーザーは、個人のラップトップを使用して会社のデータにアクセスする場合よりも、潜在的な侵害のリスクが低くなります。しかし、どのようにして有効なアイデンティティポスチャーを持つユーザーがのみリスクの低いデバイスから機密データにアクセスしていることを証明しますか？
セキュリティ組織が成長し、データ損失防止（DLP）戦略やツールを実装し始めると、これは二重に重要になります。ユーザーがアクセスに使用するデバイスに対して証明の負担を適用せずに機密データにアクセスできる場合、ユーザーは意図的または偶然にセキュリティツールを回避し、情報漏洩のリスクを生じさせる可能性があります。少なくとも、可視性と監査可能性の盲点を作成する可能性があります。
一般的なデバイスポスチャー戦略は通常、エンドポイント管理ツール（JAMF、InTuneなど）、企業証明書、およびデバイス上に存在する可能性のあるEDRソフトウェアのようなセキュリティツールの組み合わせに依存します。これらのツールの一部は、サポートされている場合に外部で検証できる方法でデバイスをフィンガープリンティングできます。デバイスポスチャー検証を使用してゼロトラストアクセス制御を実現するためには、ゼロトラストベンダーのエンドポイントエージェントをデバイスに展開する必要があります。その後、ポリシーで使用するためにそのデバイスの状態を適用する前に、サードパーティベンダーからの主張を「独立して」検証するために使用されます。ベンダーを評価する際には、状態を比較的頻繁にポーリングする能力を評価することが重要です。これにより、状態の「継続的評価」に対するゼロトラストポリシーの哲学に従うことができます。
ゼロトラストセキュリティの成果のためにサードパーティベンダーを使用し始めると、それらのベンダーは最良のセキュリティ決定を下すためにファーストパーティシグナルを取り込む必要があります。この場合、Cloudflareはデバイスポスチャーのポリシー強制のポイントとなります — アイデンティティポスチャーに加えて。Cloudflareデバイスエージェントは、デバイスの所有権または健康メトリックを評価し、それをユーザーアイデンティティに関するポリシーと組み合わせて、機密リソースへのアクセスが適切なアイデンティティ検証を持ち、受け入れ可能なセキュリティ制御レベルを持つ準拠したデバイスから来ていることを確認します。
「古い世界」のモデル（城と堀のセキュリティアーキテクチャとも呼ばれる）では、インフラストラクチャはおそらく均質でファイアウォールによって保護されていました。ネットワークリソースにアクセスするには、オフィスにいないユーザー（または他の第三者、ベンダーなど）は、VPNとファイアウォールを介してネットワークに接続する必要があるか、パブリックIPアドレスを介して他の利用可能なネットワークルートを使用する必要がありました。現在、ほとんどのインフラストラクチャはクラウドに存在し、ほとんどのスタートアップはリモートファーストで始まるため、従来のネットワーキングの概念は、あなたの「企業ネットワーク」の初期段階を設計する際に明示的に関連することはほとんどありません。
このより従来のネットワーキングモデルでは、インフラストラクチャはおそらく以下のいくつかの方法で構成されます：
- 1つまたは複数のVPCに存在する（クラウドプロバイダーのトランジットゲートウェイで接続されている場合もあれば、そうでない場合もある）
- サービスのアドレッシングはおそらくクラウドプロバイダーによって管理される
- AWSのRoute53 DNSのようなクラウドプロバイダーからの内部DNSを使用する（ほとんどの企業は、どれだけクラウドネイティブであっても、ある程度内部DNSに依存している）
- 自分のインフラストラクチャを維持する限り、プライベートネットワーク空間の概念を維持する理由が常にあるかもしれない
- すべてのユーザーが内部DNSインフラストラクチャを理解したりナビゲートしたりする必要がない可能性がある（ただし、技術的なユーザーやサービスはおそらくそうする）
インフラストラクチャにパターンを確立し始めると、単一の主要なクラウドプロバイダーに集約される可能性が高いです。この文書に関連する主な概念は、ユーザーが内部リソースやサービスにアクセスするためにネットワークに接続すること、そして内部サービスがインターネット全体と通信する方法に焦点を当てます。クラウドインフラストラクチャの権限とポリシーの管理、ならびに内部サービスが相互に通信できる方法の認識も、包括的なゼロトラスト戦略にとって同様に重要ですが、この文書の今後の更新で詳しく説明されます。
これはおそらく、ほとんどのスタートアップにとって最も一般的なゼロトラストのユースケースの1つになるでしょう。あなたは自問しているかもしれません。VPNハードウェアを管理したり、ビジネスをリスクにさらしたりせずに、ユーザーに内部ネットワークやアプリケーションへのアクセスをどのように提供できますか？ユーザーをプライベートネットワークやサービスに接続する最良の方法を模索する際に、ゼロトラストの原則に従いながら考慮すべき重要な点が2つあります：
- 露出の制限 — ゼロトラストの哲学は、組織がネットワークやサービスにアクセスできる方法の数を制限することを奨励します。パブリックIPアドレスやネットワークへの侵入経路を持つことは、望ましくないリスクをもたらす可能性があります。これは通常、ゼロトラストベンダーに接続するアウトバウンド専用プロキシを使用して、認証されたトラフィックのみをネットワークにプロキシし、いかなるパブリックIPアクセスも必要としないことで達成されます。
- 横の移動の制限 — 潜在的なデータ侵害の半径を減らす最良の方法の1つは、すべてのリソースに対して最小特権アクセスを実践することです。最小特権アクセスは、ユーザーが役割に必要なアクセスレベルのみを受け取るゼロトラストアーキテクチャの核心的な原則です。ゼロトラストフレームワークに関連する最も類似した概念は「マイクロトンネル」であり、アクセスが必要な各アプリケーションやサービスが独自の明確な「ルート」を受け取ることを推奨するアプローチです。マイクロトンネルと同様に、最小特権アクセスは、明示的なサービスとユーザーのみが特定のリソースにアクセスできるようにするプラクティスを構築することを可能にし、将来のセキュリティ組織を非常に有利に位置づけるのに役立ちます。
インフラストラクチャの作成と管理に関する明確な戦略を定義し、予測可能な内部IPおよびDNSレコード構造を持つことは、組織が成長し続ける中で資産にアクセスし、保護するために非常に価値があります。文書の後半では、選択したゼロトラストセキュリティプロバイダーと即座に統合できるインフラストラクチャを作成するために自動化されたワークフローを使用する方法について詳しく説明します。インフラストラクチャが存在し、現在どのようにアドレスされているかについての明確な感覚があれば、アクセス制御モデルにセキュリティポリシーを重ねることがはるかに容易になります。
Cloudflare Zero Trustは、エンドユーザーにプライベートネットワーキングの概念を拡張するために、エンドポイントソフトウェアとクラウドネットワーキングコネクタの組み合わせを使用できます。この場合、Cloudflareを「オーバーレイ」ネットワークとして使用して、パブリックIPを公開せずにエンドユーザーに内部ネットワークへの安全なアクセスを拡張し、クラウド環境からの侵入を許可し、通常リモートアクセスに伴うリスクを導入しないことができます。
この「オーバーレイ」ネットワークでは、小さなソフトウェアの部分がネットワーク内に存在し、「ネットワーク」トンネル（内部ネットワーク上のサービスへの管理者アクセスをユーザーに提供し、従来の公開バスチオンの概念を置き換える）と「アプリケーション」トンネル（認証されたユーザーのみがトンネル内で定義された単一のサービスに明示的に到達できるマイクロトンネル）を提供します。
これにより、ユーザーがプロファイルを変更したり、設定を切り替えたり、複数のクライアントから常に切断または再接続したりすることなく、複数の異なるプライベートネットワーキング環境へのアクセスを管理することが大幅に容易になります。また、ゼロトラストの原則に従いながら、特定のオーディエンスに単一のプライベートアプリケーションやサービスを簡単に公開する能力も提供します。
ほとんどのスタートアップにとって、ネットワーキングは変更すべき最優先事項ではありません。通常、企業は最も抵抗の少ない道を選び、通常は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は通常、両者のブレンドがすべての規模のビジネスにとって正しいアプローチであると考えています。
組織がメッシュ接続を試みている場合、Cloudflareは独自のアイデンティティ概念を重ね合わせ、将来の成長を支えるネットワーキングフレームワークを構築する際に、セキュリティとスケーラビリティのニーズをサポートするための個別の接続モデルを支援できます。
スタートアップにとって通常最も関連性の高いCloudflare製品は、WARPクライアント（cloudflared経由）とCloudflare Tunnel（WARP Connector経由）の組み合わせです。これにより、リモートアクセス、メッシュ接続、および従来のネットワーキング接続を単一のダッシュボードから管理できます。より詳細には、デバイスポスチャ情報、アイデンティティ情報、クライアント証明書、および一般的なL4指標（ポート、IP、送信元/宛先プロトコルなど）を単一のポリシー施行ポイントから構成でき、人的および自律的なネットワークインタラクションのための堅牢なセキュリティポリシーを構築できます。
このネットワーキングモデルのブレンドは、企業ネットワークへのリモートアクセスを提供したり、企業ネットワークをクラウド環境やオンプレミス機器に拡張したり、追加のリスクやオーバーヘッドを導入することなく重要なインフラストラクチャ間のメッシュ接続モデルを構築し続けたりするなど、幅広いユースケースをサポートするように設計されています。
Cloudflareが関わったほぼすべてのスタートアップ（および成熟した企業）において、内部ツールのセキュリティは依然として普遍的な課題です。ビジネス特有のタスクを達成するために必要なツールを構築することもあれば、自己ホスティングやオープンソースソフトウェアを使用することもあります。これらは、サービス、監視、またはその他の機能のための人気のあるSaaSアプリケーションとしても利用されることがあります。
前のセクションで概説された原則は、これらのリソースへのリモートアクセスを管理する方法を扱い、主に認証に関するものです。要約すると、実際にゼロトラストモデルを達成するには、各内部サービスへのアクセスが継続的なアイデンティティ認証プロキシによって制御されることを確認する必要があります。理想的には、これはネットワークの境界から物理的に分離されており、明確な監査可能性を持ち、必要に応じてユーザーアクセスを迅速に取り消す機能を提供します。
しかし、ゼロトラストモデルを実装し始める際に企業が直面する最大の課題の1つは、認証ではなく、認可です。ゼロトラストモデルでアプリケーションの玄関口にユーザーを到達させることは（比較的）簡単ですが、認証と認可の両方のために彼らの資格情報を管理し、両者が一致することを確認し、同時にポジティブで非侵襲的なユーザーエクスペリエンスを維持することは非常に難しい場合があります。
理想的な世界では、認証と認可は同じサービスによって処理されるべきだと考えています。これは、内部アプリケーションを保護する方法を検討する際に、OAUTH機能を直接組み込むか、SaaSアプリケーション用の主要なSSOと直接統合するかを検討する際に、認証方法がアイデンティティ検証方法と衝突したり重複したりする可能性を考慮することを意味します。これらの概念を使用して、認証と認可のスケーラブルな成功を確保するための2つの主な方法があります。
「ベンダートークン」は、すべてのゼロトラストまたはSSEベンダーに存在する概念ではありません。これは、Cloudflareの比較的ユニークなアプローチによるものです。私たちは世界最大の権威あるDNSプロバイダーであるため、内部アプリケーションへの「外部」パスのDNSを提供し、ユーザーアクセスのためのトークンを作成します。
これらのトークンは、成功した認証イベント後にCloudflareがアイデンティティプロバイダーから受け取る情報に基づいており、そのアプリケーションのカスタムポリシーに対して一致します。各トークンには、ユーザーの認証イベントで署名されるすべてのコンテンツが含まれています：名前、ユーザー名、メールアドレス、グループメンバーシップ、および他の値が含まれます。また、特定のアプリケーションに関連することを示すためのユニークなタグも付与されます。
Cloudflareトークンが作成されると、それは内部アプリケーションに渡され、リクエストを検証し、内部ツールへのアクセスを認可します。これは、アプリケーションごとに最小限の追加作業で済み、完全なOAUTH統合やSSO統合が必要な場合にアプリケーション作成ワークフローに組み込むことができます。
Cloudflareトークンを使用することで、ユーザーは確立されたゼロトラストプロキシを通じてシームレスに認証され、同じ情報でアプリケーションに認可されます。
一部のゼロトラストベンダーは、SSOプロバイダーとして機能する能力を提供し、オープンソースまたは自己ホスティングソリューションと直接統合します。これには、事前に構築されたSSOコネクタが付属しています。このフローでは、あなたのSSOがアプリケーションへの認可を制御し、ゼロトラストベンダーがアイデンティティプロバイダーに呼び出して認証の決定を行います。これにより、複数の主要ディレクトリを管理する必要がなくなります。
Cloudflareユーザーにとって、これにはいくつかの利点があります：認証（AuthN）と認可（AuthZ）を合理化し、特定のSSOベンダーへの依存を減らし、複数の同時認証プロバイダーを使用できるようにします。最も重要なのは、新しいアイデンティティプロバイダーを簡単に採用または切り替えることができることです。企業は、25-50ユーザーの時に使用するアイデンティティプロバイダーと、300-500+ユーザーの時に使用するアイデンティティプロバイダーが異なることがあり、1つのSSO統合から別のSSO統合に移行するために必要な厳しい切り替えには常に大きな摩擦があります。この移行は、いくつかのアプリケーションのSSO統合における時間とフラストレーションを考慮すると、特に困難です。CloudflareをSSOプロバイダーとして使用することで、すべてのアイデンティティ、デバイスポスチャ、およびリスク統合を単一のポリシー施行ポイントに集約することで、その摩擦を軽減し、AuthZ/AuthNを合理化し、自己ホスティングアプリケーションの前に追加のセキュリティコントロールを配置できます。
内部サービスへのリモートアクセスには、Cloudflare Access製品を使用することをお勧めします（ネットワーク内のCloudflare Tunnelソフトウェアを介して）。Cloudflare Accessを使用すると、Cloudflare Accessによって作成されたJWTを消費したり、SaaS用のAccessを使用して、プライベートな自己ホスティングアプリケーション（SSO統合が事前に構築されている）に対してSAMLまたはOAUTHプロキシとして機能させたりできます。
多くの場合、アプリケーションアクセスのために両方の製品を使用することもできます。たとえば、現在パブリックインターネット上で利用できない Sentry ↗を自己ホスティングしている場合、次の手順に従ってください。
- Cloudflare Accessでパブリックホスト名を設定します（ユーザーがSentryにアクセスするためのもの）。
- Cloudflare Tunnelをインストールし、ローカルSentryサービスを指す関連するパブリックホスト名ルートを設定します。
- SentryをSaaS用のAccessと統合し、SSOプロバイダーとして機能させます。
これで、ネットワーク外からアプリケーションにアクセスするユーザーはすでにCloudflare JWTを持っており、シームレスにアプリケーションに認証されます。
企業ユーザーのリモートアクセスに関する確立されたパターンは、通常、請負業者、サードパーティのベンダー、さらには顧客を含む異種のユーザーセットには拡張されません。これらのユーザーグループは、プライベートリソースに関与する正当な理由を持つことがあります。開発やメンテナンスの請負業者を雇い、ネットワークやアプリケーションの一部にアクセスする必要があるかもしれませんが、彼らに完全なネットワークアクセスを提供することは不必要なリスクをもたらします。
また、顧客にホストまたは管理されたサービスを提供し、彼らが自分のネットワーク内で展開することも可能です。その場合、適切に管理するためにそれらのサービスと接続する必要があるかもしれません。また、顧客のためにプライベートリソースを自社環境内でホストし、関連するテナントにのみ安全にアクセスできるようにする必要があるかもしれません。
第三者ユーザーが環境にアクセスする必要があると判断した場合、最初に3つの属性を決定する必要があります。
- 彼らがアクセスする必要があるもの
- そのアクセスに必要な認証レベル
- このアクセスがどのくらいの期間関連するか
スコープを決定した後、ユーザーグループに適切な最小特権アクセスモデルを決定する必要があります。これは、認証イベントで使用するために二次的なアイデンティティプロバイダー（顧客またはベンダーのIdPかもしれません）と統合することを意味するか、または一時的な認証方法（例えば、一回限りのPIN）を使用して、彼らのメールアドレスに対してのみ認証することを意味するかもしれません。
一部の企業は、認証を合理化し、MFAや他の認証要素の使用などの方法を制御するために、自社のアイデンティティプロバイダーにベンダーや請負業者のユーザーを追加することもあります。少なくとも、複数の同時認証方法をサポートし、特定のポリシーやアプリケーションを介してそれらを適用できるゼロトラストセキュリティプロバイダーと連携することをお勧めします。
これにより、すべての既存の安全なリモートアクセス方法を一貫して維持できます。外部ユーザーグループは、ネットワークへの同じ経路を使用し、すべてのセキュリティコントロールの対象となります。一方で、どのユーザーがアクセスできたか、どのくらいの頻度でアクセスしたか、ネットワーク内でどのような行動を取ったかを正確に示す詳細なログと監査トレイルを受け取ります。最小特権コントロールを割り当てることで、アクセスモデルを簡単に確立し、ユーザーが不必要にネットワーク内のリソースに対して横移動したりアクセスしたりできないようにすることもできます。
このアクセスがWebブラウザを介して確立できず、ネットワークレベルの制御が必要な場合、外部ユーザーはゼロトラスト展開に使用されるエンドポイントエージェントを展開する必要があるかもしれません。たとえば、請負業者グループは、単一のユーザーマシンに接続された複数のエンドポイントエージェントを持つことが多く、これがネットワークルーティングの複雑さを引き起こす可能性があります。また、異なる企業間でプライベートネットワークが重複する場合、競合が発生する可能性もあります。
第三者アクセスを確保するためのシンプルで管理可能なプロセスを確保するために、次の点を考慮してください。
- あなたのゼロトラストベンダーは、エンドポイントエージェント展開のために複数のプロファイルをサポートできますか？ 請負業者ユーザーは、ネットワークへのアクセスを制限し、デバイス上の他のエージェントとの競合のリスクを制限するために、厳密にスコープされたルーティング制御を持つべきです。
- 第三者アクセスは企業ユーザーアクセスと実質的に異なりますか？ そうでない場合、機能的なアイデンティティと第三者の統合を構築することで、管理業務を合理化できます。すべてが監査可能で区別できる限り、新しいポリシーを作成する必要はないかもしれません。
企業のユーザーは、顧客環境への安全な（永続的または一時的な）アクセスが必要な場合や、顧客がネットワーク内のユニークなホスティング環境への同様の安全なアクセスを必要とする場合があります。このプロセスには、顧客のためのソフトウェアテナントのホスティング、顧客がホストするソフトウェアのメンテナンスの実行、または顧客の内部ネットワークに結びつく製品機能のためのコネクタの提供が含まれることがあります。
これらのユースケースに対して、従来の推奨モデルは、サイト間VPNや類似のオプションのようなネットワーク構成でした。これらは適切にスコープを設定できますが、しばしば企業ネットワークと顧客ネットワーク間の接続が過度に広がり、リスクや過度のアクセス能力を引き起こす可能性があります。
ゼロトラストセキュリティフレームワークでは、この種のアクセスは明示的に最小特権モデルでスコープを設定する必要があります。これは、アイデンティティ認識またはサービス認識のサイト間接続を設定することや、一方向コネクタモデルを使用して特定のアクションにスコープを設定した安全なアクセスを提供することで達成できます。
Cloudflareは、ゼロトラストフレームワーク内で、サードパーティユーザーへのウェブおよびネットワーク接続のためのスコープされた安全なアクセスを提供するのに役立ちます。
- Cloudflare Accessは、複数のアイデンティティプロバイダーを同時に統合して使用できます。 これは単一のアプリケーションと単一のポリシーにスコープを設定でき、特定の方法で認証するように一部のユーザーアクセスを「強制」するための詳細な機能を持つことができます。また、ユーザーアクセスがサードパーティにとって簡単であり、管理者にとって文書化され制御可能であることを保証するための多くのサードパーティ特有のワークフロー（目的の正当化など）もあります。
- Cloudflare Zero Trustは、契約者およびサードパーティユーザーのための柔軟なエンドポイントエージェントパラメータと論理グループで展開できます。 内部アクセスの必要がある外部ユーザーがいる場合、彼らは厳密にスコープを設定でき、他の外部システムとの潜在的な競合を制限できます。
- Cloudflare Tunnelは、一方向アクセスモデルとして機能し、企業ユーザーにスコープされた顧客リソースへのアクセスを提供できます。 軽量で展開が簡単で、顧客環境で管理するサービスと一緒に展開パッケージに組み込むこともできます。
- Cloudflare WARP Connectorは、各クライアントコントロールに関連する安全で拡張可能なネットワークを構築するのに役立ちます。 これは、双方向（サイト間）トラフィックフローが顧客との関わり方、アプリケーションとの相互作用、または他の管理上の懸念に必要な場合に特に役立ちます。WARP Connectorは、他の展開と同様に、インラインセキュリティポリシーの適用と監査可能性の制御を持っているため、顧客接続を達成しながらゼロトラストセキュリティ姿勢を維持できます。
従来、ゼロトラストアクセスの概念は、内部または特権リソースへのユーザーまたはマシンアクセスに明示的に制限されていました。機能的には、これはネットワーク拡張の置き換え、過剰な権限の削減、VPNリモートアクセス接続から通常提供される横移動や脅威ベクトルの最小化を必要とします。しかし、多くの企業にとって、彼らのVPNは単にプライベートネットワークトラフィックをプロキシするだけではありませんでした。それはまた、インターネットトラフィックを管理し、脅威の統一的なビューを維持することを可能にしました — 通常は、DNSクエリをクラウドプロバイダーに送信するモジュールを介して、または単にすべてのユーザートラフィックを企業ネットワークにバックホールして企業ファイアウォールを通過させることによってです。
この城と堀のモデルによって導入されたセキュリティと複雑さの課題は、多くのベンダーにVPNが果たす2つの主要な機能に対処させることを余儀なくしました。現在、セキュアウェブゲートウェイ（SWG）とゼロトラストアクセス（ZTNA）が同じ文で議論されることや、同じ製品の一部として言及されることは一般的です。
このシフトは、セキュリティ研究者ではなく、ベンダーやアナリストによって推進されましたが、顧客にとってセキュリティ管理の向上をもたらし、スタートアップの購入および展開プロセスを簡素化したようです。つまり、企業トラフィックとインターネットトラフィックの両方を処理するために単一のエージェントを展開することは、すべての種類のセキュリティツールを処理するために複数のデバイスエージェントを使用することに比べて大きな改善です。
古い世界では、あなたの周辺は公開の出口IPアドレスによって示され、トラフィックがインターネットに出る前に一連のセキュリティコントロールの対象となることを示していました。おそらくそれはファイアウォール、IPS、IDS、または他の何かでした。そのため、企業はトラフィックが「信頼される」前に特定のソースIPを要求し始めました。これはベンダー、サードパーティ、およびSaaSアプリケーションで使用されました。企業ネットワークから発信されるトラフィック（企業のソースIPを持つ）は、「信頼」の最大の指標の1つでした。もはやそれほど単純ではありません。
今日、あなたのビジネスには中央の「周辺」がまったくない可能性があります。おそらくクラウドで始まり、ユーザーエンドポイントを生のまままたはいくつかの事前設定されたセキュリティコントロールと共に出荷し、すべてをリモートで非同期に実行しています。このモデルは、生産性とスケール能力に大きな影響を与えます。しかし、セキュリティ組織が成長し成熟するにつれて、新しい周辺を示すベースラインセキュリティ「姿勢」を設定することには固有の利点があります。
ゼロトラストプロバイダーとSSOが、ほとんどのプライベートアプリケーション、ネットワーク、サービス、およびSaaSアプリケーションを保護できる世界では、ユーザーはどこからでも作業する力を持つべきです — そして、あなたの非同期で非常に効果的な作業スタイルは、ベストプラクティスに従う限り中断される必要はありません。言い換えれば、「安全な」エンドポイントの定義は、新しい企業の周辺になります。
明確な測定可能性を持つ定義された安全なエンドポイントは、ソースIPアドレスとは異なり、非常にターゲットを絞ったものであり、継続的に検証されるため、セキュリティ姿勢にとってはるかに優れています。古い世界では、これはファイアウォールを通過し、セキュリティコントロールの対象となることを意味していました。新しい世界では、これは通常、暗号化の検証、デバイスの姿勢の調査、およびマシンからのトラフィックが安全なウェブゲートウェイによって検査されたかどうかを判断することを意味します。検証の方法としてソースIPアドレスを含めることもできますが、決して主要なコントロールとしては使用しません。
BYODの使用を管理する方法や、企業データが安全にアクセスされることを保証する方法について考えるとき、あなたは単に安全なエンドポイント戦略を構成するものについて決定を下す必要があります。その後、敏感なリソースへのリクエストをどのように調査して、この戦略に準拠していることを確認するかを考慮してください。たとえば、ユーザーがWorkday（または他のPIIが多いシステム）にアクセスするために必要な手順について考えてみてください。アクセスを許可する前に、彼らのトラフィックを安全なウェブゲートウェイを通過させ、データ損失防止ポリシーを適用したいかもしれません。今、これらの要件を強制するために他にどのような手順を踏む必要があるか自問してください。
この議論の中で、私たちはインターネットセキュリティ（例：安全なウェブゲートウェイ、DNSフィルタリング、トラフィックプロキシなど）を、敏感なリソースに対してより正確で詳細なゼロトラストポリシーを適用できる高度なセキュリティシグナルのセットとして考えています。また、ソフトウェアを展開し、エンドポイントからトラフィックをプロキシするプロセスは、ビジネスとセキュリティのニーズが成長するにつれてますます複雑になるため、できるだけ早くDNSフィルタリングを開始することが良いプラクティスです。他の高度なセキュリティコントロール（HTTPフィルタリングやデータ損失防止など）について考え始めるときは、TLS復号化の開始 ↗を読むことをお勧めします。トラフィックを復号化する前に行うべき決定についての感覚を得るためです。
内部アプリケーション、ネットワークリモートアクセス、SaaSアプリケーションのためのゼロトラストセキュリティ機能を提供することに加えて、Cloudflareは以下の機能も提供しています：
- DNSフィルタリング
- L4ファイアウォール
- セキュアウェブゲートウェイ（SWG） — アプリケーション認識、TLS復号化、データ損失防止、CASB機能、ブラウザの隔離、およびCloudflareネットワークから直接専用の出口IP構造を採用する能力を備えています
すべてのSWG機能は、ユーザーのアイデンティティ、デバイスの姿勢、ユーザーリスクを考慮したポリシーを介して制御され、ゼロトラストコントロールと同じエンドポイントエージェントから提供されます — 同じポリシーエンジンとポリシー適用の機会を使用しています。
Cloudflareは、管理されたエンドポイントデバイスのアウトバウンドトラフィックを特定し、ポリシーを適用し、保護することによって、新しい周辺を機能的に構築することを可能にします。古い城と堀の周辺と同じ統一されたセキュリティコントロールを達成しながら、独立した詳細なセキュリティ評価を適用できます（ただし、ユーザートラフィックをバックホールすることはありません）。その後、そのセキュリティ評価を使用して、ゼロトラスト保護されたアプリケーションからさらに強力なコントロールを適用し、低、中、高リスクのユーザーを区別し、BYODトラフィックの取り扱いについての判断を行うことができます。
SaaSセキュリティの概念は、多くの人にとって多くの意味を持ちます。そのため、これはやや物議を醸すトピックであり、特にゼロトラストに関連しています。SaaSサービスは、COVIDの最初の波の間にユーザー人口の急増を見ましたが、これは主にリモートワークの大幅な増加によるものです。ほぼ一晩で、ユーザーが企業インフラストラクチャの外に存在するサービスに接続する方が、内部サービスに接続するよりも簡単で実用的になりました。
一部の人々は、SaaSアプリケーションは1）SSOを統合した場合に本質的に安全であるか、または2）SaaSプロバイダーが安全にする機能的責任を負うと主張します。これらの議論は、SaaS投資がどのようにアクセスされ、保護されるかに対処していますが、企業がSaaSを使用する理由を文脈化していません — 通常は企業情報を保存するためです。「あなたの敏感なデータが存在する可能性のある場所」の普及は、SaaSセキュリティの決定においてますます重要な要素となるでしょう。
上記の声明はすべて、ユーザーがどのSaaSツールを利用しているかを知っていることを前提としていますが、実際にはそうでないことがよくあります。まず、「承認された」SaaSの採用について説明し、その後「未承認」SaaS（シャドウITとも呼ばれる）に関連する概念について説明します。
必要なセキュリティ姿勢を決定することは、セキュリティポリシーを構築する前にエンドユーザーにとって重要な最初のステップです。したがって、企業データやコンプライアンス法やその他の規制の対象となるデータを含むアプリケーションがある場合、それらを前述の「周辺」に適合するデバイスに限定することが理にかなっているかもしれません。
これを達成する最良の方法は、ユーザーアクセスのためにセキュリティポリシーの個々の部分が継続的に適用されることを保証できるシグナルの集約者（CloudflareのSaaS用Accessなど）を見つけることです。これを従来のSSOベンダーで実現できますか？おそらく。たとえば、OktaのFastPassは、ローカルデバイスにインストールされた証明書を検証することによってマシンのアイデンティティを決定し、その後リクエストのソースIPアドレスを判断します。しかし、ほとんどの場合、FastPassはそのユーザーのトラフィックに存在するセキュリティ検査イベントやエンドユーザーデバイスの健康状態についての詳細を提供することはできません。この点で、あなたのSSOプロバイダーは、ポリシー決定を行うために消費できるデータの量に応じてのみ有用であることに注意する価値があります。
マシン証明書のみ、または別のシグナルの測定のみが企業デバイスを示すのに適切であると判断した場合、これはビジネスのセキュリティ成熟度のどの段階でも完全に適切です — 実際、多くの企業はまだ何らかのデバイス姿勢を採用していません。
承認されたSaaSアプリケーションを管理する別の方法は、APIを介してゼロトラストベンダーと統合することです。次に、誤設定や予期しない敏感なデータの存在をスキャンできます。このプロセスは従来のゼロトラストアクセスコントロールとは独立していますが、ほとんどのゼロトラストベンダーによって提供されており、すべてのSaaSツールに対する継続的に必要な構成変更を単一のビューで表示できます。
管理するSaaSアプリケーションにおける敏感なデータの存在を評価することによって、ポリシーの優先順位を開発し始めることができます。言い換えれば、BYODを介してアクセスできるべきものと、管理されたエンドポイントからの承認されたアクセスを必要とするべきものについての考え方が変わるかもしれません。または、逆に、ユーザーが効果的に条件付けされるようにするために、BYODアクセスのリスクをどのように定量化できますか？
セキュリティモデルは、制御可能なSaaSアプリケーション（つまり、SSOや他のサードパーティツールと統合できるアプリケーション）から制御できないアプリケーションに移行する際に大きく変わります。このカテゴリに該当するSaaSアプリは、しばしば「未承認」アプリケーションとして分類されます。これは、SSOをサポートしない二次ベンダーによって管理されている場合や、IT組織によって使用が明示的に承認されていないサービスであるためです。これらの未承認アプリはシャドウITと呼ばれます。
これらのアプリは、どのようにしてあなたの環境内で増殖するのでしょうか？論理はシンプルです。特にスタートアップでは、ユーザーは迅速に動くことを好み、作業を完了させるための最も便利な方法に引き寄せられることがあります。時には、使用が検証されていないツールや（機密データを保存する可能性のある）ツールを使用することを意味することもあります。
シャドウITは通常、一般的なインターネットセキュリティプログラムの一部として対処されます。これは、ゼロトラストの展開と同じ考慮セット（または同じベンダー）に含まれることがあります。未承認のSaaSアプリケーションのリスクを軽減することは、ほぼ常に可視性に焦点を当てています。最も重要なことは、SSOやCASBツールがアプリケーションと統合されていなくても、シャドウITの使用範囲を理解することです。
未承認アプリケーションを文書化するには、通常、DNSフィルター、セキュアウェブゲートウェイ、または特定のメールツールのようなフォワードプロキシツールを使用する必要があります。これらのツールは、どのユーザーが未承認のSaaSアプリに関与しているか、さらにはどのように関与しているか（ファイルをアップロード/ダウンロードしたか、どれだけの帯域幅を転送したかなど）についての洞察を提供できます。
SaaSの使用を文書化するためのポリシーや戦略を実施することで、機密データがSaaSツール内でどのように保存、移動、または操作されているかをより良く理解し始めることができます。一部の企業は、SaaSの使用を明示的に承認された企業ツールに制限していますが、他の企業はより寛容です。間違ったアプローチはありませんが、使用情報をキャプチャするための初期のフレームワークを構築することで、組織にとって重要な問題が発生した場合に逆算するのに役立ちます。
このフレームワークは、IT組織にどのツールを調達サイクルで考慮すべきかの方向性を提供することもできます。たとえば、重要なユーザーの集団がすでにツールを使用している場合、そのツールのエンタープライズ機能を取得することが、シャドウITのリスクを軽減したり、チームがセキュリティ機能を強化したりするために意味を持つことがあります。
Cloudflareは、シャドウIT環境の可視性と管理の基盤を設定し、その後の発見を支援します。WARPクライアントと当社のセキュアウェブゲートウェイ（SWG）からインターネットへのユーザートラフィックを監査し整理することで、機密データが企業が承認したSaaSテナントの外でどのように移動するかを理解できます。
これにより、新たに発見されたツールが明示的にブロックされるか、明示的に許可されるかを確保し、それに特定のデータセキュリティコントロールを設定したり、ゼロトラストベンダーと統合したりすることで、ゼロトラスト戦略をさらに拡大する機会となります（SaaS用のアクセスを使用してセキュリティポリシーを適用するなど）。
私たちが話す多くのスタートアップは、最終的にセキュリティツールを管理するために必要な人員と専門知識について懸念しています。これらのツールは、彼らのユースケースに対して複雑または過剰に提供されているように見えます。彼らがすでに開発のために行っている多くのことは、オーケストレーションツール、インフラストラクチャをコードとして、APIを介して直接管理されていますが、すべてのゼロトラスト（および他のセキュリティツール）プロジェクトをコードとして構築、管理、維持したいと考えています。
これは、従来のセキュリティツールにとっては新興の概念ですが、潜在的なベンダーを評価する際には依然として重要な考慮事項であるべきです。Terraformのような概念が多くのゼロトラストベンダーによってサポートされていることを考慮してくださいが、これらのベンダーは製品のすべての概念に対してプロバイダーやAPIエンドポイントをサポート（または公開）していない場合があり、管理努力の重複や分割を引き起こす可能性があります。
組織としての目標がネットワークとセキュリティスタックをコードとして管理することであるなら、ゼロトラストの旅の初期にそのフレームワークを開始することが重要です。ナビゲートする際に課題があるかもしれませんが、ネットワーク開発に早めに着手することで、ビジネスとセキュリティのニーズが避けられないほど複雑で管理が難しくなるにつれて、利益を得ることができます。
ゼロトラストや一般的なセキュリティイニシアチブのためにベンダーパートナーを評価し続ける際には、彼らが製品ポートフォリオ全体と管理コントロールのために十分に文書化され、完全なAPIエンドポイントを持っていることを確認することをお勧めします。また、オーケストレーションやインフラストラクチャをコードとしてのツール（Terraformのような）に関する文書も必要です。
Cloudflareは、DevSecOpsの文脈におけるゼロトラストセキュリティに非常に情熱を注いでいます。私たちは、すべての製品に対してAPIファーストを主要な理念として構築し、機能の利用可能性の初日からすべての関連APIエンドポイントを顧客に提供し、広範な文書 ↗を提供しています。
別に、多くの顧客は、私たちのダッシュボードに触れることなくCloudflareのゼロトラスト展開を管理しています。代わりに、彼らはTerraformや類似のツールを使用して、管理プレーン全体を管理しています。これがあなたの場合であれば、ゼロトラストをコードとして実現するための包括的で完全なTerraformプロバイダーがあります。
結論として、セキュリティと認証の基本に対する会社のアプローチについて、今日いくつかの意図的な選択を行うことは、あなたのスタートアップに何年にもわたって利益をもたらします。今行う決定は、ビジネスが成長するにつれてスムーズにスケールする現代のセキュリティインフラストラクチャの基盤を築きます。どのように前進するにせよ、いくつかの十分に情報に基づいた動きが、あなたのスタートアップが持続可能でスケーラブルなゼロトラストセキュリティ原則に基づいて構築されることを保証します。
ゼロトラストの要件について詳しく話し合い、私たちのアーキテクトの一人とつながりたい場合は、https://www.cloudflare.com/cloudflare-one/ ↗を訪れて、相談をリクエストしてください。