[ゼロトラストの運用 — ステップ 6: 検証、実装、監視]

[このブログシリーズは、私が3月の投稿で紹介したアイデアを拡張したものです。」ゼロトラストは難しくありません... 現実的であれば。」]

[その記事では、ゼロトラストを実現するための6つのステップを概説しましたが、ここでは最後のステップについて詳しく説明したいと思います。 有効、実装、監視 このステップが、組織の規模に関係なく、マイクロセグメンテーションの実践者がプロジェクトをより成功させるために使用できる強固なフレームワークの実装をどのようにサポートできるかを説明します。]

[始める前に、次の 6 つのステップについて復習しておきます。]

[まとめ — ステップ 5: ポリシーを設計する]

[の中に 最終投稿 このシリーズでは、「ポリシーのデザイン」について紹介しました。そこで、アプリケーション依存関係マッピングが関連フローをどのように識別するかを示しました。]

[そして、ここから、次の一連の許可ルールが導き出されました。]

• [ルール 1:]
• [出典：ウェブサーバー、ペイメント、プロダクション、英国]
• [送信先:DÑS レスポンダー、D~ÑS インフラストラクチャ、プロダクション、英国]
• [デスティネーションサービス:53/údp]
• [宛先プロセス:名前付き]
• [ルール 2:]
• [出典：アプリサーバー、ペイメント、プロダクション、英国]
• [送信先:DÑS レスポンダー、D~ÑS インフラストラクチャ、プロダクション、英国]
• [デスティネーションサービス:53/údp]
• [宛先プロセス:名前付き]
• [ルール 3:]
• [出典：ウェブサーバー、ペイメント、プロダクション、英国]
• [送信先:アプリサーバー、決済、プロダクション、英国]
• [デスティネーションサービス:8080/tcp]
• [デスティネーションプロセス:トムキャット]

[ゼロトラストの原則を念頭に置いて、上記の許可ルールは許可されるものを正確に定義します。明示的に許可されていないものは暗黙的に削除されるため、最小限の権限のプロパティが維持されます。]

[ステップ 6: 検証、実装、監視]

[マイクロセグメンテーションルールを定義したので、これらを適用してワークロードを保護する準備が整いました。ただし、重要な課題が 1 つ残っています。支払いアプリケーションは本番環境にあり、制限をかけている間は機能を中断させたくありません。このリスクをどのように軽減しますか¿]

[どのようなセグメンテーションを行う場合でも、最大のリスクを伴う段階は、ワークロードに出入りする他のトラフィックが許可されないように作成されたポリシーを適用することです。ポリシーが間違っていると、本番環境が停止する可能性があります。そのため、あらゆる問題を迅速に検出して修正できるように、施行への移行を制御し、十分な監視の機会を設ける必要があります。]

[これがポリシーテストの出番です。Íllú~míó C~óré はこれを強力かつ簡単に実行する方法を提供します。Í~llúm~íó Có~ré プラットフォームの最も便利な機能の 1 つは、ワークロード (またはワークロードのグループ) をテストモードに移行できることです。ビルドモードと同様に、テストモードはノンブロッキングモードで、ポリシー違反を報告するという利点もあります。テストモードのワークロードの場合、PC~É はワークロードのフローデータを使用して構築された接続グラフをポリシーグラフと重ね合わせます。]

[ポリシーグラフは、特定のポートとプロトコルのセットを介して相互に通信できるワークロードの周りにバブルを置いていると考えることができます。接続グラフには、ワークロード間で試行された通信が表示されます。]

• [接続性グラフがポリシーグラフのバブル内にある場合、緑色の線が表示されます。これらのフローは、私たちが作成したポリシーと一致しています。]

• [接続性グラフがポリシーグラフのバブルを横切ると、赤い線が表示されます。これらのフローは、作成されたポリシーと一致しません。]

[テストモードでは、これらの「赤線」はフローをブロックしていませんが、ポリシーに違反する接続試行があったことを示します。アプリケーション所有者として確認すべきフローは次のとおりです。選択肢は次のとおりです。]

• [フローが必要-> ポリシーを書いてラインを緑色にする]
• [フローは不要->アクションを実行する必要はありません]

[そのため、ポリシー検証プロセスでは、これらの「赤」行をすべて繰り返し調べて、緑に変える必要があるかどうかを判断する必要があります。これらの「違反」をすべて確認して選択したら、ワークロードの保護を開始する準備が整いました。検証プロセスが完了し、実施に移ります。]

[検証、実装、監視フェーズの目的は実際にはリスクを最小限に抑えることであることを念頭に置いておくと、ワークロードにポリシーを適用する際に「ビッグバン」アプローチをとることは理想的ではありません。すでに詳細な検証を行ったとしても、この最終段階では段階的な手順を踏むことをお勧めします。繰り返しになりますが、Íllú~míó がワークロードをきめ細かく制御することで、まさにこれが可能になります。アプリケーション内の各ワークロードを個別に適用モードに移動できます。つまり、完全に検証されたポリシーを作成したら、最初に完全な保護を有効にするワークロードを選択し、ポリシーを適用した状態で実行し（つまり、ポリシーで許可されたトラフィックのみがワークロードの入出力が可能）、ある程度の「浸漬時間」後に他のワークロードを適用状態に移行できます。このアプローチの利点は、ポリシーに何らかの問題が発生した場合でも、全体ではなく一部のワークロードにのみ影響することです。また、アプリケーション全体を有効にする前に微調整する機会も得られます。]

[ワークロードがすべて適用され、アプリケーションが保護された今、当面の課題は、トラフィックイベントを継続的に監視して、予期しないこと（ドロップや受け入れ）がないかどうかを確認し、通常とは異なるものを調査することです。]

[ラッピングアップ]

[これで、ゼロトラストに向けた実践的なアプローチの6つのステップをウォークスルーできました。フォレスターが述べているように、 ゼロトラストはそれ自体が成果ではなく、セキュリティ戦略ですそして、各組織はゼロトラストの柱全体にわたる自社の成熟度を理解し、どの柱に最も焦点を当てるべきかを特定し、その成熟度を向上させるために段階的な措置を講じる必要があります。イルミオは 大手ZTXエコシステムプラットフォームプロバイダー そして、ネットワークとワークロードの可視性とセキュリティの分野でこれらのステップを実行するための完全な機能セットを提供します。]

[ゼロトラストの運用化シリーズのステップ1～5を見逃していませんか？今すぐチェックしてください。]

• [ステップ 1: 保護対象を特定する]
• [ステップ 2 と 3: どのゼロトラストピラーに焦点を当てるべきかを判断し、厳密な統制を指定する]
• [ステップ 4: 必要なデータを指定する]
• [ステップ 5: ポリシーの設計]

[ゼロトラストの詳細については、こちらをご覧ください ソリューションページ — 今日から旅を始める方法を学びましょう。]