マイクロセグメンテーションのワークロードラベリングを簡素化するための5つのヒント

IPは、すべての人、すべてのマシンが理解できる構造を持っています。192.168.1.254のような4次元の数字の集合を誰かに見せると、多くの人がすぐにこのことに気付くでしょう。シンプルな構造により、情報は簡単に理解できます。それがインターネットの規模と機能を実現するものです。そして、それを使って働く人々にとって、その階層は即座に洞察を提供します。

代替案、つまり人々が任意の構造を定義する世界を想像してみてください。ある分に192.179.134.56.245.23が表示され、次の分に24.87が表示されたらどうなるでしょうか?これらが互いにどのように関連しているかをどのように理解すればよいでしょうか?

柔軟性と自由意志はポジティブなものと考えていますが、ネットワークアドレス指定の世界では、そしてワークロードのラベリング(特に マイクロセグメンテーション)においても同様に、混乱と複雑さが生じる可能性があります。最終的には、従来のファイアウォールポリシーで経験するような一貫性のないポリシーや問題が発生します。

ここ数年、私たちは資産を識別してグループ化するために、さまざまな属性を持つオブジェクトにタグを付けてきましたが、これにより、規模と管理性に何度も課題が生じてきました。構造がなければ、耐えられるアーキテクチャを作成することは、時間の経過とともにますます問題になります。イルミオでは、このことを早期に認識し、構造とシンプルさが任意のオブジェクトタグ付けよりも運用上大きなメリットをもたらすと判断しました。

簡単に言えば、ラベルは使いやすく、再現性があり、予測可能で、後で理解しやすいものでなければなりません。

そこで、このことを念頭に置いて、ワークロードのラベル付けを簡素化するための 5 つのヒントを次に示します。

1. 4 次元ラベリング スキームに固執する

これは、いくつかの単純で明白なディメンションパラメータを使用してワークロードを分類することで機能します。例えば：

1. 場所： ワークロードはどこにありますか?これは、国、都市、クラウドプロバイダーなどです。
2. 環境： このオブジェクトは、本番、開発、またはテストにありますか?
3. アプリケーション： 財務、人事、またはCRMアプリケーションを提供していますか?
4. 役割： それはアプリケーションサーバー、ウェブサーバー、またはデータベースですか?

ロール、アプリケーション、環境、場所(RAEL)の4つの単純なグループに固執することで、理解しやすいだけでなく、移植性と拡張性を備えたラベリングモデルを作成できます。

この構造により、ユーザーは 4 つのラベルのいずれかにピボットし、1 つのセクションを使用して制御を簡素化し、計算時間を短縮できます。私たちのラベルが車両用で、「タイプ |メーカー |モデル |色」と入力し、BMWまたは赤い車だけを識別することで、演習が非常に簡単かつ迅速になります。

また、オブジェクトのラベル付けは、オブジェクトとその主な目的を定義するためではなく、その関係を定義するために最も単純に使用されることを覚えておいてください。この原則に固執し、ポリシーを使用して人間関係を定義することが幸福への道です - これについては私を信じてください。

2. フォーマットを標準化する

ネットワーキングとコンピューティングでも同様のことが見られるかもしれませんが、「本番環境」、「本番環境」、および「本番環境」には大きな違いがあります。スペルミスが発生する場合は常にありますが、構造化された 4 次元モデルでは、トラブルシューティングが簡単です。

しかし、緩いフリースタイル環境では、"prod.fin.win.UK.CRM.web.bldg1.10"のエラーを見つけようとします。長いプロセスになります。

3. ラベル名を短くするときは注意してください

たとえば、"Production" などのラベルを "Prod" に短縮しますが、"Database" は短縮しません。ラベル名を一貫して短縮すると、ラベルが重複する可能性があり、その結果、ポリシーの適用やサポート性の課題に一線性が欠ける可能性があります。

短縮バージョンまたは頭字語が組織で一般的に使用される命名法 (UAT など) でない限り、フルネーム (運用、開発、およびテスト) を使用することをお勧めします。これが問題を引き起こす可能性がある典型的な例は、「Prod」ラベルと「Production」ラベルの両方が作成されている場合です。一部のワークロードに「本番環境」というラベルが付けられている場合、「本番環境」用に作成されたルールは適用されません。

命名基準を定義することは新しい概念ではなく、これには十分な理由があります。

4. すべてのシステムで一贯性を保つ

マイクロセグメンテーションのラベリングスキーム内の一貫性に加えて、メタデータの外部ソースとの一貫性を維持することをお勧めします。

構成管理データベース (CMDB)、ホスト命名規則、または IP アドレス・ブロックの使用など、メタデータの命名規則を確立している場合は、ラベル付けスキームの代替規則を作成しないでください。デプロイ プロジェクト中に、標準データ ソースにも不整合があることが判明した場合は、これに対処し、そのデータ ソースの品質を向上させる機会です。これはさまざまな理由から非常に有益であり、組織は恩恵を受けるでしょう。

最初のデプロイのユースケースは、特定の環境またはアプリケーションに限定される場合があります。ただし、組織全体を念頭に置いてラベルデザインを構築すると、展開が拡大した場合に作業を節約できます。ラベルスキーマが単純になるほど、スケーラブルでサポートしやすくなります。

5. ラベルを使用してオブジェクトを区別できるようにする

オブジェクト間でポリシーを区別する必要がある場合は、異なるラベルを使用します。別個のラベルを使いたくなる場合もしばしばありますが、実際には政策の差別化がないので不要です。また、この点に関するポリシーには、セキュリティポリシーだけでなく、 RBAC、レポート、変更管理、その他の種類のポリシーも含まれることに注意してください。

このことを念頭に置いて、可能な限りラベルに共通名を使用してください。たとえば、Apache、Nginx、IIS は、80/TCP や 443/TCP などの同様のサービス ポートとプロトコルを使用します。そのため、「Web サーバー」などの共通のラベル名を使用することをお勧めします。ほとんどの場合、これらに対して異なるポリシーを作成する必要はありません。

ワークロードに異なるセキュリティポリシーが必要な場合にのみ、ラベル名を変更します。たとえば、Oracle、IBM DB2、MS SQL Server は異なるサービス ポートとプロトコルを使用し、それぞれにクラスター トラフィック フローなどの固有のセキュリティ ポリシー要素があります。したがって、これらのアプリケーションを実行するワークロードに 3 つの異なるロールラベルを割り当てることをお勧めします。たとえば、これにより、Oracle Enterprise ManagerサーバがSybaseサーバではなく、Oracle Databaseサーバにのみアクセスできるようにする特定のポリシーを記述できます。

イルミオがどのように役立つか

Illumio Coreは、ポリシーオブジェクトを識別する4つのラベルの組み合わせを備えた多次元設計を使用しています。タグ付けを使用する他の製品では、タグをいくつでも作成できる場合があります。これによりラベル付けがより柔軟になるように見えるかもしれませんが、時間の経過とともに課題がより顕著になります。

異なるラベルディメンションを追加し続けると、特定のタグが一意のポリシーアプリケーションを示す単一次元モデルにすぐになります。これによく似たのはディレクトリサービスで、新しい要件ごとに新しいグループ (タグ) を作成し、ユーザーに適用できます。これらのグループは数が急速に増加し、多くの場合、同じオブジェクトに関連付けられているため、重複が発生します。ユーザーよりもグループが多いシナリオが存在することも珍しくありません。同様に、タグベースのソリューションでは、オブジェクトよりも多くのタグがあり、各オブジェクトが多数のタグに関連付けられている場合があります。

次に、管理者は、すべてのオブジェクトを必要なすべてのタグに関連付ける義務があります。その結果、新しいオブジェクトが作成されるたびに、必要なアクセス権を取得するために、増え続けるタグのコレクションでタグ付けする必要があります。このシナリオでは、スケーラビリティが困難になり、一貫性が低下し始めます。

私たちの多くは、自分のアクセスがチームの他のメンバーとまったく同じではないという状況に陥ったことがあり、グループ (またはタグ) が欠けていることが判明しました。単純な 4 次元モデルを使用することで、新しいオブジェクトのラベル付けは簡単で、予測可能で、反復可能で、サポート可能であり、ポリシー設計での継承により管理性が大幅に向上します。

スケーラブルで一貫性のあるラベル付けスキームを定義するには、ポリシー設計に対する考え方を変える必要がありますが、一度理解すれば、そのシンプルさによりポリシーの管理がより効果的になります。

イルミオでのラベリングについてどのように考えているかの詳細については、チーフエバンジェリストであるナサナエル・アイバーセンによる この素晴らしいビデオ をご覧ください。