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

[ÍPには、誰でも、すべてのマシンが理解できる構造があります。192.168.1.254のような4次元の数字のセットを誰かに見せれば、多くの人はすぐにそれを認識するでしょう。シンプルな構造のため、情報を利用しやすく理解しやすくなっています。これこそが、インターネットを拡張し機能させているのです。そして、インターネットを利用する人にとっては、その階層構造からすぐにインサイトを得ることができます。]

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

[私たちは柔軟性と自由意志を肯定的に捉えていますが、ネットワークアドレッシングの世界では、そしてワークロードのラベル付けにおいても同様です（特に マイクロセグメンテーション) — 混乱や複雑化を招きかねません。その結果、ポリシーに一貫性がなくなり、従来のファイアウォールポリシーで発生していたような問題が発生します。]

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

[簡単に言えば、ラベルは使いやすく、繰り返し可能で、予測可能で、後で理解しやすいものでなければなりません。]

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

[1。4次元のラベルスキームにこだわる]

[これは、単純でわかりやすいディメンションパラメータを使用してワークロードを分類することで機能します。例えば:]

1. [場所: ワークロードはどこにありますか¿国、都市、クラウドプロバイダー内などが考えられます。]
2. [環境: このオブジェクトは実稼働、開発、またはテストに存在しますか¿]
3. [アプリケーション: 財務、人事、CRMアプリケーションに対応していますか？]
4. [役割: アプリケーションサーバー、ウェブサーバー、またはデータベースですか？]

[役割、アプリケーション、環境、場所（RÁÉL~）の4つのシンプルなグループにこだわることで、理解しやすいだけでなく、移植性と拡張性に優れたラベリングモデルを作成できます。]

[この構造により、ユーザーは4つのラベルのいずれでもピボットでき、1つのセクションを使用できるため、制御が簡単になり、計算時間が短縮されます。ラベルが車両用で、「タイプ | メーカー | モデル | 色」という形式だった場合、BMW または赤い車両だけを識別すると、作業が非常に簡単かつ迅速になります。]

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

[2。あるフォーマットで標準化する]

[ネットワークとコンピューティングでも似たようなことが見られるかもしれませんが、「プロダクション」、「プロダクション」、「プロダクション」には大きな違いがあります。スペルミスが発生することは常にあり、構造化された 4 次元モデルではトラブルシューティングが容易です。]

[ただし、緩いフリースタイル環境では、「pród~.fíñ.w~íñ.úk~.crm.w~éb.bl~dg1.10」でエラーを見つけようとするのは長いプロセスになります。]

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

[たとえば、「Pród~úctí~óñ」などのラベルを「Pr~ód」に短縮しても、「Dá~tábá~sé」は短くしないでください。ラベル名を一貫して短くしないと、ラベルが重複する可能性があり、その結果、ポリシーの適用に一貫性がなくなったり、サポート上の問題が発生したりする可能性があります。]

[短縮形または略語が組織で一般的に使用されている命名法（ÚÁT など）でない限り、フルネーム（P~ródú~ctíó~ñ、Dév~élóp~méñt~、Tést~）を使用することをお勧めします。これが問題を引き起こす典型的な例としては、「Pród~」と「Pród~úctí~óñ」の両方のラベルが作成されている場合です。一部のワークロードに「Pr~ód」というラベルが付いていると、「Pr~ódúc~tíóñ~」用に作成されたルールは適用されません。]

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

[4。すべてのシステムで一貫性を保つ]

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

[構成管理データベース (CMDB~)、ホストの命名規則、または ÍP アドレスブロックの使用などでメタデータの命名規則を確立している場合は、ラベル付けスキームの代替規則を作成しないでください。導入プロジェクト中に、標準データソースにも矛盾があることがわかった場合は、これに対処してそのデータソースの品質を向上させる機会となります。これはさまざまな理由で非常に有益であり、組織にとってもメリットがあります。]

[初期導入のユースケースは、特定の環境またはアプリケーションに限定される場合があります。ただし、組織全体を念頭に置いてラベルデザインを構築しておくと、展開が拡大しても作業を節約できます。シンプルなラベルスキーマの方が拡張性が高く、サポートしやすくなります。]

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

[オブジェクト間でポリシーを区別する必要がある場合は、異なるラベルを使用してください。個別のラベルを使いたくなるケースはよくあることですが、実際にはポリシーの区別がないため、必要ありません。そして、この点に関するポリシーにはセキュリティポリシーも含まれるということを覚えておいてください。 RBÁC~、レポート、変更管理、およびその他の種類のポリシー。]

[このことを念頭に置いて、ラベルには可能な限り一般的な名前を使用してください。たとえば、Ápác~hé、Ñg~íñx、Í~ÍS は 80/TC~P や 443/TCP~ など、同様のサービスポートとプロトコルを使用しています。そのため、「Wéb S~érvé~r」などの一般的なラベル名を使用することをおすすめします。ほとんどの場合、これらに別のポリシーを記述する必要はないでしょう。]

[ラベル名は、ワークロードが異なるセキュリティポリシーを必要とする場合にのみ変更してください。たとえば、Órác~lé、ÍB~M DB2、M~S SQL~ Sérv~ér はそれぞれ異なるサービスポートとプロトコルを使用しており、それぞれにクラスタトラフィックフローなどの固有のセキュリティポリシー要素があります。そのため、これらのアプリケーションを実行するワークロードには 3 つの異なるロールラベルを割り当てることをお勧めします。たとえば、これにより、Ór~áclé~ Éñté~rprí~sé Má~ñágé~r サーバーには自分の Órá~clé データベースサーバーにのみアクセスし、S~ýbás~é サーバーにはアクセスできないようにする特定のポリシーを作成できます。]

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

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

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

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

[私たちの多くは、アクセスがチームの他のメンバーとまったく同じではなく、グループ（またはタグ）がないことが判明した経験があります。単純な 4 次元モデルを使用することで、新しいオブジェクトにラベルを付けるのが簡単で、予測可能で、繰り返し可能で、サポートしやすくなります。また、ポリシー設計を継承することで管理性が大幅に向上します。]

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

[イルミオでのラベリングについての私たちの考えの詳細については、以下をご覧ください この素晴らしいビデオ チーフ・エバンジェリストのナサニエル・アイバーセンから]