構造化されたポリシー制御でセグメンテーションを正しく行う

最終的に、 ゼロトラストセグメンテーション は、セキュリティルールを作成して適用することです。

ゼロトラストセグメンテーションは、慎重に定義されたアクセスポリシーを確立することで、侵害がITシステムや環境全体に広がるのを防ぎます。

どの組織でも、少なくとも 1 つのエンドポイント デバイスが攻撃者によって侵害されることは避けられません。しかし、組織がゼロトラストセグメンテーションセキュリティを導入している場合、そのエンドポイントがラップトップ、デスクトップ、サーバー、さらには仮想マシンであるかどうかに関係なく、侵害は最初のエンドポイントに 限定できます 。

セグメンテーションポリシーは、マルウェアが他のミッションクリティカルなサーバーやデータセンターに自身をコピーするために必要なネットワークポートやプロトコルにアクセスしたり、貴重なデータを求めてネットワークを探索したりするのを防ぎます。セグメンテーションは、ガラスの下のハエのように攻撃を所定の位置に閉じ込めます。

ゼロトラストセグメンテーション:2つのアプローチ

ルールエンジンは、セグメンテーションルールの構文を定義するソフトウェアです。また、これらのルールが定義されると、これらのルールも適用されます。一般に、セグメンテーションソフトウェアベンダーは、顧客向けのルールエンジンを設計する際に2つの異なるアプローチを採用します。

最初のアプローチは、顧客に最大限の柔軟性を提供し、組織全体の利害関係者が好きなカテゴリやラベルでルールを定義できるようにすることです。

もう 1 つのアプローチは、 構造化ポリシー制御として知られる設計哲学を採用することです。このアプローチでは、セグメンテーションルールに使用できるラベルの数が制限されます。また、ルール制定は IT セキュリティ専門家の一元的なチームの管理下に置かれます。このアプローチを採用しているベンダーは、最終的には、オープンエンドの複雑さよりもシンプルさの方が攻撃を抑制するのに効果的であると考えています。

次に、これらのアプローチを検討し、実際の展開における利点と課題を比較します。

セグメンテーションへの最大限の柔軟性アプローチ

どの組織でも、 セキュリティ要件 は部門ごと、ユースケースごとに異なります。アプリケーションが異なれば、必要なルールも異なります。同じアプリケーションでも、実行されているデータセンター、実行されているソフトウェアのバージョン、依存しているリソースなどによって、ルールが異なる場合があります。

多くのセグメンテーションベンダーは、さまざまなユーザーやアプリケーション所有者が専門分野や責任の分野に独自のルールを設定できるようにすることで、この柔軟性のニーズに対応しています。

通常、これらのベンダーは 3 種類のルールをサポートしています。

• 特定の経路に沿った交通の移動を防ぐための「ブロック」ルール
• 特定のタイプの交通が経路を通過することを許可するための「許可」ルール
• 他のルールをプリエンプトして、特定の状況でトラフィックをブロックまたは許可するための「オーバーライド」ルール

大まかに言えば、柔軟なルール制定に対するこの分散型アプローチは有望に思えます。結局のところ、IT資産所有者は、特定のIT資産または関連資産のグループに最適なセグメンテーションルールを設定するために必要なドメイン知識を持っている必要があります。また、ブロック、許可、オーバーライドの 3 種類のルールを提供することで、IT セキュリティ チームとビジネス関係者は、IT 資産を保護するための適切なセキュリティ ポリシーを定義するために必要な精度が得られるようです。

残念ながら、ほとんどの組織、特にクラウド、オンプレミス、エンドポイント環境に数 万または数十万のワークロードが分散している大規模な組織 では、このアプローチからすぐに「西部開拓時代」が生まれます。

確かに、組織全体の利害関係者は、貴重なIT資産を保護するためのルールを定義しています。しかし、これは効果的に管理するにはあまりにも多くの種類のルールが多すぎるため、最終的には混乱につながります。

ルール作成は分散され、調整されていないため、ルールのコレクションには矛盾や脱落が生じ、攻撃者がすり抜ける機会が生まれます。一元的で一貫したガバナンスは事実上不可能です。

これらの「西部開拓時代」の条件を生み出すものは次のとおりです。

• 責任の領域は重複することがよくあります。
  たとえば、あるユーザーがビジネス・アプリケーションを担当し、別のユーザーがデータベースを担当しているとします。アプリケーションはデータベースに依存する場合がありますが、アプリケーションとデータベースに定義されているアクセス規則は独立して開発されます。その結果、特に他のアプリケーションもデータベースを使用する場合、2 つのルール セットに一貫性がなくなりがちです。
  
  別の例: 1 人が会社の顧客関係管理 (CRM) アプリケーションを担当しています。別の担当者は、CRMアプリケーションがたまたま実行されている同社のニューヨークのデータセンターを担当しています。たとえこの2人がセキュリティの哲学に同意したとしても、セグメンテーションルールの独立した実装が完璧に連携する可能性は非常に低いです。IPアドレス、ポート、プロトコルが複雑すぎて、数十または数百のルールを独立して効果的に作成することはできません。
   
• セグメンテーション制御は集中化ではなく分散されるため、テストはほとんど行われません。
  制御は非常に多くの利害関係者に分散されているため、IT 組織がすべてのセグメンテーション ルールをアクティブ化する前にテストすることは困難です。テストが不足していると、エラーや見落としのリスクが高まります。ビジネスクリティカルなトラフィックが誤ってブロックされる可能性もあります。
   
• 無制限または多数のラベルをサポートすると、混乱が生じます。
  この方法で制御を分散するセグメンテーション製品では、通常、顧客は セグメンテーション用の独自のカテゴリまたはラベルを定義できます。
  
  この柔軟性を利用して、お客様はすぐにセグメンテーションポリシーに 20 個、30 個、またはそれ以上のラベルを割り当てることができます。たとえば、顧客は PCI コンプライアンスに関係するすべての IT 資産に "PCI コンプライアンス" ラベルを付けることができます。また、特定の場所にあるすべての資産に場所名のラベルを付けたり、ビジネスユニット、アプリケーション、環境 (テストと本番など)、追加の政府規制 (GDPR など) などのラベルを付けたりすることもできます。
  
  理論的には、このラベルの急増により精度と可視性が提供されます。実際には、セキュリティモデルが複雑すぎて効果的に管理できない。
  
  チームは、ルールの順序付けを通じて、この混乱を軽減しようとすることができます (たとえば、最初にデータセンターのルールを適用し、次にアプリケーションのルールを適用し、規制やビジネスユニットに関するルールを最後に適用するようにルールセットを構造化します)。しかし実際には、この種の構造化は迷路のような政策につながり、特定の状況でどのルールが施行されているかを見分けるのが非常に困難になります。
   
• 分散型ルールは、従業員が転職すると管理が難しくなります。
  分散ルール作成のもう一つの問題は、組織のITチームやセキュリティチームが、どのようなルールがなぜ作成されたかを追跡することが難しくなることです。
  
  アプリケーション所有者などのルール作成者は、セグメンテーションルールに組み込まれた考え方を文書化していない可能性があります。その従業員が会社を辞めると、重要なセキュリティと運用の知識が失われます。

この柔軟性の高いアプローチの最大の問題は?攻撃者が悪用できる隙間が残ります。ランサムウェアは、組織がネットワークのセグメント化に時間、お金、労力を費やしてきたにもかかわらず、依然として侵入しています。

セグメンテーションへの構造化されたポリシー制御アプローチ

セグメンテーションルールを作成するための「最大限の柔軟性」アプローチとは対照的に、セグメンテーションベンダーは作成できる ラベルの数 を制限する場合があります。

許可されるラベルの数は 4 つまでで、ロール、アプリケーション、環境、場所のみをカバーできます。または、その数は少し多いかもしれませんが、上記の最大の柔軟性アプローチで許容される数には程遠いです。

ラベルを制限することは実際にはうまく機能することがわかりました。実際、ゼロトラストセグメンテーションの 最大の導入が成功している ものはすべてこのアプローチを採用しており、これらのポリシーは非常に複雑なハイブリッドIT環境を保護しているにもかかわらず、ラベルを10個以下に制限しています。

構造化されたポリシー制御アプローチが非常にうまく機能する理由は次のとおりです。

• 限られたラベルでは、事前に一元化と調整が強制されます。
  セグメンテーションポリシー管理を適切に機能させるには、組織はネットワークトラフィックを分析し、適用するセグメンテーションポリシーを共同で開発する中央チームを必要としています。
  
  アプリケーション所有者はデータベース所有者と調整し、データベース所有者はファイアウォールマネージャーと調整します。承認されたトラフィックパターンの共有分析と理解に基づいて作業しているため、必要なセキュリティを提供する一貫性のある相互に一貫性のあるセグメンテーションルールを定義できます。
   
• これは、構造化されたポリシー制御が提供できる包括的なネットワークの可視性に基づいて構築されています。
  さまざまなアプリケーション、データベース、その他のリソースにわたるルール作成を調整するために、ITチームとセキュリティチームは、組織のネットワークトラフィックを 包括的に可視 化する必要があります。そうすることで、アプリケーションとサービスが依存する正当なトラフィックを特定できます。
  
  その重要なトラフィックが特定されると、他のすべてをブロックするポリシーの作成が容易になります。また、さまざまな利害関係者が、どのトラフィックを許可すべきかについて合意しやすくなります。利害関係者がネットワークの使用状況について共通の理解に基づいて作業できれば、コラボレーションは簡単になります。
   
• ゼロトラストセキュリティのためにデフォルトですべてのトラフィックを拒否することで、さらにシンプルになります。
  構造化されたポリシーアプローチでは、トラフィックのブロック、トラフィックの許可、または先行するセグメンテーションルールの上書きのオプションを関係者に提供する代わりに、任意のシステムまたは環境に対してデフォルトですべてのトラフィックをブロックすることから始めることができます。次に、組織全体のすべての正当なトラフィックを示す視覚化マップから作業し、ITおよびセキュリティチームは、アプリケーション、データベース、またはサービスが必要とするトラフィックのみを許可するポリシーを作成できます。
  
  構造化ポリシー制御ベンダーは、デフォルトで何も信頼しないことで、 米国国立標準技術研究所 (NIST)、米国ホワイトハウスの「 国家のサイバーセキュリティ改善に関する大統領令」、およびその他のITセキュリティ当局が推奨する厳格なゼロトラストセキュリティを提供します。
   
• ルール作成は一元化されているため、IT チームとセキュリティチームはルールを適用する前にテストしてマッピングできます。
  ルール作成への集中型アプローチのもう 1 つの利点は、ルールの一貫したモデルが 1 つあるため、モデル全体をテスト モードで実行できることです。また、ルールが実装される前にワークロード間の通信経路を視覚的にマッピングし、潜在的な問題をチームに警告することができます。これにより、IT チームとセキュリティ チームは、ルールを適用する前にトラブルシューティングを行い、ルールを微調整することができます。

結論: 柔軟性と拡張性

ルールを大規模に実装する場合、これら 2 つのアプローチのどちらを選択するかは厳しくなります。

小規模な組織であっても、柔軟性の高いアプローチはすぐに維持できなくなります。セキュリティギャップは、独自に開発されたルールセットの茂みの中で必然的に持続します。統一された調整がないため、攻撃が通過したり、善意のセキュリティルールが誤ってミッションクリティカルなトラフィックをブロックしたりします。

対照的に、セグメンテーションに対する構造化されたポリシー制御アプローチは、設計規範を前もって適用することで、IT チームとセキュリティ チームが、新興企業から最大かつ最も複雑なグローバル ネットワークまで、あらゆる種類の IT 環境を簡単かつ効率的に保護するのに役立ちます。

ゼロトラストセグメンテーションのためのイルミオソリューションについて学ぶには:

• ゼロトラスト・インパクト・レポートを入手して、組織がゼロトラストにどのように取り組んでいるかに関するESG調査を学びましょう。
• 詳細なガイドをダウンロードしてください マイクロセグメンテーション戦略を5つのステップで構築する方法.
• Forrester New Wave: Microsegmentation, Q1 2022 の無料コピーを入手し、イルミオがリーダーに選ばれました。
• 義務のないデモをスケジュールし、ゼロトラストセグメンテーションの専門家との相談をしてください。