Zero Trustセキュリティの導入が困難なプロセスであることは、よく知られています。いろいろな意味で、そのような評判が立つのも無理はありません。Zero Trustには、セキュリティ・IT担当者が慎重になるのもうなずけるほどの作業が必要になります。リクエストをデフォルトで許可するポリシーと境界ベースのネットワークアーキテクチャの見直しや、職務上異なるチームとの協力が必要ですし、新しいセキュリティサービスに確信が持てなければなりません。企業は、次のようなさまざまな理由でこの変革を先送りするかもしれません。
他のプロジェクトとの兼ね合いで十分な人手が割けない
Zero Trustベンダーが提供するサービスが多岐にわたる
さまざまなアプリケーションやリソースがネットワーク上のどこにあるかが不明確である
従業員の生産性への影響
Zero Trustフレームワークは全体的にかなり複雑になっています。Zero Trustアーキテクチャへの完全ロードマップは、28の包括的プロジェクトで構成されています。ただし、プロジェクトによっては、時間の限られた小規模チームでも、比較的少ない労力で済みます。
ネットワーキングについていうと、Zero Trustセキュリティを達成するには、企業ネットワークを出入りしたり内部で 行き来するリクエストをすべて検査、認証、暗号化し、ログに記録しなければなりません。これは、「送信元や送信先を問わず、いかなるリクエストも暗黙に信頼してはならない」という考え方に基づいています。
Zero Trust導入の初期は、それらの機能を現在ないところに確立する作業です。ゼロから始める企業にとっては、多くの場合、機能を1つの「ネットワーク境界」を超えて拡張することを意味します。
ここで紹介するのは、ユーザー、アプリケーション、ネットワーク、インターネットトラフィックの安全確保に重点を置いたごくシンプルな5つのZero Trust導入プロジェクトです。これだけで包括的なZero Trustを実現することはできませんが、すぐにメリットが得られ、広義の変革に向けた取り組みに早い段階で弾みをつけることができるでしょう。
Zero Trustのアプローチでは、信頼できる主体から実際に送信されたリクエストであることを、ネットワークが確信できなければなりません。企業は、フィッシングやデータ漏洩によりユーザー資格情報が盗まれることに対して安全対策を確立する必要があります。多要素認証(MFA)は、そうした資格情報盗難に対する最善の保護策です。MFAの完全ロールアウトにはかなりの時間を要するかもしれませんが、最もクリティカルなアプリケーションに重点を置けば比較的簡単に進められ、効果を出すことができます。
既にIDプロバイダーを持っている企業は、ワンタイムコードやプッシュ通知アプリを従業員のモバイル端末へ送るなどして、そのプロバイダー内にMFAを直接セットアップすることができます。現行IDプロバイダー(IdP)と直接統合されないアプリケーションの場合は、アプリケーションの前面にアプリケーションリバースプロキシを配してMFAを適用するやり方を検討しましょう。
IDプロバイダーを持たない企業は、MFAに関して異なるアプローチをとることができます。Google、LinkedIn、Facebookなどのソーシャルプラットフォームや、ワンタイムパスワード(OTP)を使用すると、ユーザーIDを再確認するのに役立ちます。これらは、サードパーティの請負業者を企業IDプロバイダーに追加登録せずにアクセス権を自製する一般的な方法です。こうした戦略は社内にも適用できます。
Zero Trustの適用は、単にユーザーIDを確認するだけではありません。アプリケーションは、リクエストを常に検証し、さまざまな挙動と背景となる要素を考慮した上で認証し、アクティビティを継続的に監視するポリシーで保護する必要があります。プロジェクト1と同様に、まずはクリティカルなアプリケーションを一覧にし、それにポリシーを実装すればシンプルでしょう。
このプロセスは、取り扱うアプリケーションのタイプによって異なります。
プライベートなセルフホスト型アプリケーション(企業ネットワーク上でのみアドレス指定可能)
パブリックなセルフホスト型アプリケーション(インターネット上でアドレス指定可能)
クラウドベースのアプローチ
メールは企業の通信手段の筆頭であり、最もよく使われるSaaSアプリであり、攻撃者が最もよく使う侵入口でもあります。企業は標準的な脅威フィルターや検査を補完するために、メールにZero Trustの原則を適用する必要があります。
さらに、セキュリティチームは、完全にブロックするほど疑わしいものではないリンクを検疫するために、分離したブラウザを使用することを検討する必要があります。
開放されたインバウンドネットワークポートはよく使われる攻撃ベクトルであり、既知のソース、信頼されたソース、検証済みのソースからのトラフィックのみを受け入れるZero Trust保護を適用する必要があります。
これらのポートはスキャニング技術で検出できます。次に、Zero Trust リバースプロキシで、受信ポートは一切開放せずに、Webアプリケーションをパブリックインターネットに安全に公開することができます。アプリケーションの一般公開レコードはDNSレコードだけで、これはZero Trust認証とロギング機能で保護できます。
セキュリティの追加レイヤーとして、Zero Trustネットワークアクセスソリューションを使い、内部DNSやプライベートDNSを利用することができます。
DNSフィルタリングとは、悪性であることがわかっていたり、その疑いが濃いWebサイトやインターネット上の他のリソースに、ユーザーがアクセスしないようにすることです。トラフィックの検査もログ記録もないため、Zero Trustの議論で必ずしも話題に上るとは限りません。しかし、ユーザー(またはユーザーグループ)によるデータの転送やアップロードの宛先を究極的に制御できるという点で、広義のZero Trustの考え方によく合致しています。
DNSフィルタリングは、ルーターの設定によって、またはユーザーマシンで直接適用することができます。
これら5つのプロジェクトの導入により、Zero Trustへの移行が比較的スムーズに進められます。当該プロジェクトを完遂した企業は、より良い最新セキュリティの実現に向けて大きく前進したことになります。
広義のZero Trust導入はまだまだ複雑です。そこで、当社はベンダーニュートラルなZero Trust移行の全工程ロードマップを作成しました。上記の5つのプロジェクトと類似のプロジェクトを取り上げています。中には数日より遥かに日数がかかるプロジェクトもありますが、このロードマップでZero Trust移行の意味が明確になるでしょう。
これらのサービスはすべて、Cloudflareコネクティビティクラウドに組み込まれます。コネクティビティクラウドは、企業がIT環境のコントロールを取り戻すのに役立つよう設計された、クラウドネイティブなサービスの統合プラットフォームです。Cloudflareは、コネクティビティクラウドのリーディングカンパニーです。企業が場所を問わず従業員、アプリケーション、ネットワークの速度と安全性を高め、簡略化とコスト削減を実現できるよう支援しています。世界最大級で相互接続数も最多級のネットワークを誇るCloudflareは、お客様のために日々何十億件ものオンライン脅威をブロックしています。
この記事は、技術関連の意思決定者に影響を及ぼす最新のトレンドとトピックについてお伝えするシリーズの一環です。
本記事では、次の内容について解説しています。
Zero Trustロードマップにおける28のプロジェクト
比較的少ない労力でできる5つのZero Trust導入プロジェクト
実装を可能にするサービスの種類
自社で導入ロードマップを作成する際の最初の一歩
完全ガイド『Zero Trustアーキテクチャへのロードマップ』でZero Trustの詳細を学び、お客様の組織のロードマップ作成を始めましょう。
利用開始