マイクロセグメンテーションを展開するためのアーキテクトガイド:ベンダー関係と運用統合の管理

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

このシリーズでは、多くの考慮事項を解き明かしました。この最後の第 5 部では、ベンダーとの関係を管理し、運用統合を維持する最善の方法について説明します。

仕入先関係の管理

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

ベンダーを戦略的パートナーのように扱い、最高のパフォーマンスを発揮します。「何が必要か」だけでなく、「なぜ必要なのか」「なぜいつまでに必要なのか」もわかれば、拡張チームの移動が非常に簡単になります。ベンダーを手に留めて、プロジェクト計画の次のステップしか見えないと、手遅れになるまで全体像を把握できず、専門知識や教訓を生かすことができないことがよくあります。プロジェクトは遅延したり、早期終了を要求されたり、その他さまざまな結果が生じたりする可能性があります。大きな変更を早期に伝えれば、ベンダーは変更を吸収し、計画と実行の調整を支援するのに最適な立場に立つことができます。

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

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

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

運用統合の管理

さて、ギアを変えましょう。ほとんどのマイクロセグメンテーションソリューションには、少なくとも中央ポリシーエンジンとホストベースのエージェントといういくつかのコンポーネントがあります。マイクロセグメンテーションの展開に付随する複雑さは、これら 2 つのコンポーネントがエンタープライズ環境の他の多くのことに触れているという事実から生じます。既存のシステムとの運用統合を支援する「ベストプラクティス」がいくつかあります。

QA または本番前テスト環境を構築する

社内チームとベンダーチームの両方が当然、ソリューションのPRODインスタンスに焦点を当てますが、チームは非本番環境でマイクロセグメンテーションソリューションの小規模なQAバージョンをセットアップしてください。このプラットフォームはいくつかの目的に役立ちます。早い段階では、社内の開発者と自動化ツール チームがコードをテストおよび開発できる場所になります。運用チームは、ログ統合とイベント処理をテストできます。社内研修では、このシステムを習熟研修に利用できます。

デプロイが完了した後も、この機能を保持する必要があります。この本番前システムが、メインOSイメージのそれぞれを1つ管理していることを確認します。このようにして、新しいベンダーコードを、新しいリリースを本番環境にロールする前に、PROD オペレーティングシステムイメージのフルセットに対して非本番環境でテストできます。理想的には、ベンダーのデプロイ チームがこのシステムを 1 つの軽量 VM として立ち上げることができます。

本番環境のデプロイ前にログ/イベントアラートを設定してテストする

当然のことながら、OPS チームは、本番ワークロードをペアリングする前に完全な運用統合が完了したときに最も高い信頼度を持っています。ログのストリーミング、解析、アラートの発生、ダッシュボードの構築には時間と労力がかかります。

ただし、この作業により、ポリシーエンジン、エージェント、および基盤となるシステムの健全性を完全に可視化できます。必要なすべての計装が整っていることを知って、誰もが機密性の高い本番環境で作業するのがはるかに簡単です。ベンダーの専門サービス エンジニアが、主要なログ メッセージに関する推奨事項を提供し、他の顧客に人気のあるアラートを推奨することを期待してください。

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

1. セキュリティ。セキュリティチームは、ファイアウォールログとエージェントの改ざん防止メカニズムに最も重点を置きます。彼らは常にポリシーとポリシー違反に関心を持っています。
2. OPSです。OPS チームは、ワークロードとポリシー エンジンの健全性に最も重点を置き、システム イベントを他のデータセンター イベントと関連付ける方法を知りたいと考えています
3. ダッシュボード。管理管理者またはNOC管理者は、多くの場合、ハイライトとドリルダウン機能を含むマイクロセグメンテーション展開の統合ビューを必要とします

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

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

マイクロセグメンテーションの導入により、長い間純粋に手作業であったセキュリティプロセスを自動化する多くの機会が提供されます。さらに、マイクロセグメンテーションのラベル付けは、既存のメタデータソースの調査をレビューおよび強化し、それらを新しい方法で組み合わせます。結果のメタデータはそれ自体が価値があり、他のシステムや自動化タスクで使用するために保存できます。企業にとって、マイクロセグメンテーションの導入が成功した後、適度な努力をすれば、より良いメタデータが得られるのが一般的です。この取り組みは、継続的な運用と最初のマイクロセグメンテーション展開の拡大に大きな利益をもたらします。

エージェントのインストール

マイクロセグメンテーションエージェントを数百または数千のシステムに展開するには、何らかの形の自動化が必要です。これは既存のツールである場合もあれば、ゼロから構築される場合もあります。しかし、多くの場合、エージェントのインストールを自動ビルドプロセスと統合することが望まれます。Chef、Puppet、Ansible、Salt、その他のフレームワークのいずれであっても、企業の標準的な自動化ライフサイクルにセキュリティを組み込む機会があります。

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

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

一部のお客様は、ポリシー エンジンの作成をオーケストレーション パッケージにパッケージ化します。ポリシーのインスタンス化が自動化されている場合、サーバーのクラッシュからの回復は、自動化によって新しいポリシーエンジンが構築されるのとほぼ同じ速さで実行できます。強力な DEV-OPS 動議を持つ組織は、これを検討する必要があります。

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

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

ラベルの割り当て

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

マイクロセグメンテーションソリューションは常にラベルを使用しますが、これらのラベルはメタデータの一元管理によって最もよく維持される場合があります。DEV OPS チームはメタデータ管理について強い意見を持っている可能性が高く、彼らの声を取り入れるのが賢明です。

メタデータ管理

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

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

マイクロセグメンテーションでは、メタデータ管理をより賢くすることは、ポリシーとポリシー管理をより賢くすることと同じです。ラベルの作成に使用されるメタデータがどこに保存され、それがどのように更新され、取得され、ポリシーエンジンに供給されるかについて考えることに費やす時間は常に実りある作業です。また、ポリシーエンジンからの情報が既存のCMDBシステムの更新に役立つ場合もあります。マイクロセグメンテーションの展開は、組織内でメタデータがどのように使用および活用されるかを検討する優れた理由を提供し、これらの改善を自動化する推進力を提供する可能性があります。

すべてを家に持ち帰る

マイクロセグメンテーションの導入が成功すると、内部セグメンテーションモデル、ポリシーダイアログ、セキュリティ自動化のレベルが向上します。チームをその目的地に導くには、新しい学びと新しい機会が必要です。マイクロセグメンテーションは既存の運用モデルの一部を変更し、部門横断的な展開チームによって最もよく提供されます。

リーダーとして、いくつかの重要な局面であなたの意見が必要になります。メタデータとポリシー開発に関する適切な会話を主張することで、ビジネスのスピードと俊敏性に永続的な変化をもたらす機会が得られます。きめ細かな制御と高速自動化を同時に行うことができます。独自のマイクロセグメンテーション展開の展開、運用化、実行に成功したことについてお聞かせください。

マイクロセグメンテーション戦略を最初から最後まで実装するために知っておくべきことをすべて詳しく知りたい場合は、電子書籍「 Secure Beyond Breach: A Practical Guide to Building a Defense-in-Depth Cybersecurity Strategy Through MicroSegmentation」を必ずご覧ください。