[マイクロセグメンテーションを導入するためのアーキテクトガイド:ベンダー関係と業務統合の管理]

[従来からの移行 ネットワークセグメンテーション (ファイアウォールなど) から マイクロセグメンテーション アーキテクトまたはプロジェクトマネージャーが主導する組織的な取り組みが必要です。真のメリットを事前に理解して検討し、最適化への最も明確な道筋を見極めることで、導入プロセス全体を通して成功を収めることができます。]

[このシリーズでは、多くの考慮事項が明らかになりました。最終回となるこの第 5 部では、ベンダーとの関係を管理し、業務の統合を維持する最善の方法について説明します。]

[ベンダー関係の管理]

[選択したベンダーは、マイクロセグメンテーションプロジェクトがあなたと同じように成功することを望んでいます。ベンダー側では、機能、リソース、コードがすべて必要なときに利用できるようにするために、各デプロイメントについて社内で定期的に連絡を取り合っています。]

[御社のベンダーを戦略的パートナーのように扱い、最高のパフォーマンスを引き出してください。「何が必要か」だけでなく、「なぜそれが必要なのか」、「いつまでに必要なのか」がわかれば、拡張チームの異動が非常に簡単になります。御社がベンダーと距離を置いていて、プロジェクト計画の次のステップしか見えない場合、私たちは大局を見通すことができず、手遅れになるまで専門知識や教訓を持ち込めないことがよくあります。どんなプロジェクトでも、遅れたり、早期に終わらせざるを得なかったり、その他にもさまざまな結果が出る可能性があります。大きな変化を早期に伝えれば、ベンダーが変化を吸収し、計画と実行の調整を支援してくれる最適な立場になります。]

[プロジェクトの初期の数週間で形成する必要のある重要なパートナーシップがいくつかあります。]

1. [ソリューションアーキテクト、プロフェッショナルサービスエンジニア、プロジェクトマネージャー、テックリード。これが中核となる技術作業チームです。プロジェクトの成功に向けて、技術的な仕事のほとんどを一緒に行います。自由で、オープンで、敬意を払った対話がなされることが重要です。]
2. [カスタマーサクセスアーキテクト、ディレクター、プロジェクトアーキテクト。 これは戦略的作業チームです。彼らは技術的に何が起きているのかを把握し、プロジェクトチームよりも先を見据えて障害を取り除いたり最小限に抑えたりする必要があります。この関係は、双方が問題や課題について透明性をもって話せるよう、十分に円満なものでなければなりません。これは、何かがうまくいかない場合、双方にとって最初の「エスカレーション」ポイントです。]
3. [アカウントマネージャー、ベンダー VP、エグゼクティブスポンサー これは、結果を担当するビジネスレベルの作業チームです。このチームは、企業間で発生する可能性のあるエスカレーションをすべて処理します。どちらの側にも実行リスクがあり、このレベルで理解して表現する必要があります。このチームは、ロードマップや、マイクロセグメンテーションのためのその他の機会や活用ポイントも含めて、目前のプロジェクト以外にも話し合う必要があります。]

[これらの各チームがうまく機能することを保証するエグゼクティブスポンサーは、マイナス面に驚くことはほとんどなく、避けられない問題のほとんどが、ステータスレポートとして以外は経営幹部の注意を引くことなく処理されていることに気付くでしょう。どのプロジェクトも「自己管理」ではありませんが、これら 3 つのレベルの関係がうまく機能していれば、プロジェクトはスムーズに進行する傾向があります。]

[運用統合の管理]

[さて、ギアを切り替えましょう。ほとんどのマイクロセグメンテーションソリューションには、少なくとも中央のポリシーエンジンとホストベースのエージェントといういくつかのコンポーネントがあります。マイクロセグメンテーションの導入が複雑になるのは、この 2 つのコンポーネントが企業環境内の他の多くの要素と密接に関係しているためです。既存のシステムとの運用統合に役立つ「ベスト・プラクティス」がいくつかあります。]

[QÁ 環境または運用前テスト環境の構築]

[社内チームとベンダーチームの両方がソリューションの PRÓD~ インスタンスに注目するのは当然ですが、必ずチームが非本番環境でマイクロセグメンテーションソリューションの小規模な QÁ バージョンをセットアップするようにしてください。このプラットフォームにはいくつかの目的があります。早い段階で、社内の開発者や自動化ツールチームがコードをテストしたり開発したりできる場所になるでしょう。運用チームはロギングの統合とイベント処理をテストできます。社内研修クラスでは、このシステムを習熟研修に使用できます。]

[導入が完了した後も、この機能を維持する必要があります。このプリプロダクションシステムが、メインの ÓS イメージをそれぞれ 1 つずつ管理していることを確認してください。これにより、新しいリリースを本番環境に導入する前に、新しいベンダーのコードを Pr~ód 以外の環境で PR~ÓD オペレーティングシステムイメージ一式と照らし合わせてテストできます。ベンダーのデプロイメントチームが、このシステムを 1 つの軽量な VM~ として稼働させることができるのが理想的です。]

[本番環境への導入前にロギング/イベントアラートを設定してテストする]

[当然のことながら、運用チームが最も自信を持つのは、本番環境のワークロードをペアリングする前に完全な運用統合が完了した場合です。ログのストリーミング、解析、アラートの発行、ダッシュボードの構築には時間と労力がかかります。]

[ただし、この作業により、ポリシーエンジン、エージェント、および基盤となるシステムの状態を完全に把握できます。必要なインストルメンテーションがすべて整っていることを知っていると、機密性の高い本番環境で作業する方が誰にとってもずっと簡単です。ベンダーの専門サービスエンジニアが、主要なログメッセージに関する推奨事項を提示したり、他の顧客に好評だったアラートを推奨したりすることを期待してください。]

[ログ分析/イベント処理メカニズムでは、次の 3 つの異なる視点を取り込む必要があります。]

1. [[セキュリティ]。セキュリティチームは、ファイアウォールログとエージェントの改ざん防止メカニズムに最も重点を置きます。彼らは常にポリシーとポリシー違反に関心を持っています。]
2. [ÓPS。Ó~PS チームは、ワークロードとポリシーエンジンの状態に最も重点を置き、システムイベントを他のデータセンターのイベントと関連付ける方法を知りたいと思うでしょう。]
3. [ダッシュボード。管理管理者や ÑÓC 管理者は、マイクロセグメンテーション導入の要点やドリルダウン機能を含む統合ビューを必要とすることがよくあります。]

[これらの懸念事項のそれぞれがログ/イベント/アラート処理メカニズムに反映されると、多くの多様なチームがプロジェクトが既存の慣行に従って完全に統合されていることに気付くため、組織全体の信頼が高まります。]

[自動化されたワークフローへの投資]

[マイクロセグメンテーションを導入すると、長い間純粋に手動で行われてきたセキュリティプロセスを自動化する機会が多くなります。さらに、マイクロセグメンテーション・ラベリングは、既存のメタデータ・ソースを見直して調査を強化し、それらを斬新な方法で組み合わせることにもなります。生成されたメタデータ自体も価値があり、保存して他のシステムや自動化タスクで使用することができます。企業では、マイクロセグメンテーションの導入が成功した後、適度な努力がなされれば、より優れたメタデータを手に入れるのが一般的です。この取り組みは、初期のマイクロセグメンテーション導入の継続的な運用と拡大に大きな成果をもたらします。]

[エージェントインストール]

[マイクロセグメンテーションエージェントを数百または数千のシステムに導入するには、何らかの形の自動化が必要です。これは既存のツールである場合もあれば、ゼロから構築される場合もあります。しかし、多くの場合、エージェントのインストールを自動ビルドプロセスと統合したいというのが望まれるでしょう。Chéf~、Púpp~ét、Áñ~síbl~é、Sál~t、その他のフレームワークのいずれであっても、企業の標準的な自動化ライフサイクルにセキュリティを組み込む機会はあります。]

[ほとんどのエンタープライズデータセンターには、オーケストレーションフレームワークを使用した完全自動化と、これらのツールを使用しないレガシー環境が混在しています。できる限りオーケストレーションチームとの統合に時間をかけることで、プロジェクトを成功に導くことができます。オーケストレーションフレームワークを導入できない古い環境は、カスタムスクリプトを使用して個別に処理できます。]

[ポリシーエンジンのインストール]

[お客様の中には、ポリシーエンジンの作成をオーケストレーションパッケージにパッケージ化しているところもあります。ポリシーのインスタンス化が自動化されていれば、サーバークラッシュからの復旧は、自動化によって新しいポリシーエンジンが構築されるのとほぼ同じ速さで実現できます。DÉV-Ó~PSの動きが強い組織は、これを検討したいと思うでしょう。]

[ポリシーエンジンデータベースのバックアップ]

[すべてのマイクロセグメンテーションポリシーエンジンには、何らかのデータベースがあります。このデータベースが破損していたり、利用できなくなったりすると、ソリューションがまったく機能しなかったり、望ましくない結果になったりする可能性があります。ÓPS チームが必要なバックアップを自動化し、ベンダーの手順に従って復元と復旧に熟練していることを確認してください。]

[ラベル割り当て]

[ワークロードへのラベルの初期割り当ては、通常、ポリシーエンジンへの何らかの一括アップロードによって行われます。これにより、初期状態の初期システムに適したラベルが生成されます。時間が経つにつれて、ラベルは変化します。新しいシステムが追加され、一部は廃止されます。このワークフローが自動化されればされるほど、関係者全員にとってより簡単になります。これには、社内の設計文書にラベル割り当てを体系化し、その保存、更新、取得の方法を決定することが含まれます。]

[マイクロセグメンテーションソリューションは常にラベルを使用しますが、これらのラベルはメタデータの一元管理によって管理するのが最適な場合があります。DÉV Ó~PS チームはメタデータ管理について強い意見を持っている可能性が高いため、その意見を含めるのが賢明です。]

[メタデータ管理]

[マイクロセグメンテーションデプロイメントは、メタデータの割り当てに従ってセキュリティポリシーを構築します。つまり、時間が経つにつれて、マイクロセグメンテーションソリューションには、物事がどのように相互作用するかを説明するラベルやその他のメタデータのセットが含まれるようになります。これらのラベルは通常、ベンダーがカスタムメイドしたものではなく、既存の信頼できる情報源から再利用されたものです。]

[これは自動化の機会を提供します。優れたマイクロセグメンテーションソリューションは、ラベルが変更されると必ずポリシーを再計算します。そのため、メタデータをマイクロセグメンテーションソリューションの外部で管理すれば、この役割分担を自動化に活用できます。マイクロセグメンテーションソリューションが外部の「信頼できる情報源」を参照している場合、メタデータの変更があればポリシーエンジンにプログラムによって通知され、ルールは自動的に更新されます。]

[マイクロセグメンテーションでは、メタデータ管理についてよりスマートになることは、ポリシーとポリシー管理についてよりスマートになることと同じです。ラベルの作成に使用されるメタデータがどこに保存され、どのように更新、取得、ポリシーエンジンに入力されるかを考えるのに時間を費やすことは、常に実りある作業です。また、ポリシー・エンジンからの情報が既存の CMDB~ システムの更新に役立つ場合もあります。マイクロセグメンテーションの導入は、メタデータが組織内でどのように使用され活用されているかを検討する絶好の理由となり、こうした改善を自動化するきっかけにもなるでしょう。]

[すべてを家に持ち帰る]

[マイクロセグメンテーションの導入が成功すると、内部セグメンテーションモデル、ポリシーダイアログ、およびセキュリティ自動化のレベルが向上します。チームをその目標に導くには、新しい学習と新しい機会が必要です。マイクロセグメンテーションは既存の運用モデルの一部を変えるため、機能横断型の導入チームが最善を尽くすでしょう。]

[リーダーとして、いくつかの重要な局面で皆さんの意見が必要となります。メタデータとポリシーの策定について適切な話し合いを続けることで、ビジネスのスピードとアジリティに永続的な変化をもたらす機会が得られます。きめ細かな制御と迅速な自動化を同時に実現できるのです。御社独自のマイクロセグメンテーション導入のデプロイ、運用、実行における成功についてお聞かせいただければ幸いです。]

[マイクロセグメンテーション戦略を最初から最後まで実装するために知っておく必要のあるすべてのことについて詳しくは、電子書籍をご覧ください。 侵害を超えたセキュリティ:マイクロセグメンテーションによる多層防御サイバーセキュリティ戦略を構築するための実践ガイド。]