サポートされる Web ブラウザ
Cisco Secure Workload は、次の Web ブラウザをサポートしています。
-
Google Chrome
-
Microsoft Edge
この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
現代のネットワークには、ベアメタル、仮想化、クラウドベース、およびコンテナベースのワークロードを使用し、ハイブリッドなマルチクラウド環境で実行されるアプリケーションが含まれています。このような環境における重要な課題は、俊敏性を損なうことなくアプリケーションとデータのセキュリティを向上させることです。Cisco Secure Workload は、アプリケーションにふさわしいセキュリティを提供し、アプリケーションの動作に基づいてセキュリティ態勢を調整することで、包括的なワークロード保護を実現します。Secure Workload は、高度な機械学習および行動分析技術を使用してこの調整を達成します。次のセキュリティユースケースをサポートする、すぐに使用できるソリューションが用意されています。
ビジネス目的で必要なトラフィックのみを許可するマイクロセグメンテーション ポリシーにより、ゼロトラストモデルを実装する。
行動的ベースラインおよび分析を使用して、ワークロードの異常を特定する。
サーバーにインストールされたソフトウェアパッケージの Common Vulnerabilities and Exposures を検出する。
ポリシーを適用して通信をブロッキングした後も脆弱性が残る場合に、サーバーの隔離を推奨する。
Secure Workload のワークロードと IP アドレス
Cisco Secure Workload では、ワークロードは、エージェントワークロード(ホストまたはワークロードにインストールされたソフトウェアエージェント)またはエージェントレス クラウド ワークロード(Azure、AWS、GCP などのクラウドコネクタ)になります。IP アドレスは、エージェントワークロードまたはエージェントレス クラウド ワークロードに関連付けられていない IP を指します。
![]() 注目 |
最近の GUI の更新により、ユーザーガイドで使用されているイメージやスクリーンショットの一部に、製品の現在の設計が完全に反映されていない可能性があります。最も正確に視覚的に参照するには、このガイドを最新バージョンのソフトウェアと組み合わせて使用することを推奨します。 |
![]() (注) |
お使いの製品のエンドユーザーライセンス契約および補足エンドユーザーライセンス契約を表示するには、「エンドユーザーライセンス 契約」および「補足エンドユーザーライセンス契約」を参照してください。 |
Cisco Secure Workload は、次の Web ブラウザをサポートしています。
Google Chrome
Microsoft Edge
オプションのウィザードを使用すると、範囲ツリーの最初のブランチを作成できます。これは、選択したアプリケーションのポリシーを生成して適用するための最初のステップです。このウィザードは、ラベルと範囲の概念およびメリットを紹介します。
次のユーザーロールがこのウィザードにアクセスできます。
サイト管理者
テクニカル サポート
ルート範囲の所有者
ウィザードにアクセスするには、次のいずれかを実行します。
Cisco Secure Workload にサインインします。
青色のバナーのリンクをクリックします。青色のバナーは、すべてのページの上部に表示されます。
メインメニューから [概要(Overview)] を選択します。
![]() (注) |
でスコープがすでに定義されている場合は、ウィザードにアクセスできません。ウィザードにアクセスするには、既存の範囲を削除します。 |
次に示されている高度な手順を使用し、Secure Workload を使用してセグメンテーションとマイクロセグメンテーションのポリシーを設定してください。
セグメンテーションとマイクロセグメンテーションの目的は、ビジネスに必要なトラフィックのみを許可し、他のすべてのトラフィックをブロックすることです。
ステップ 1 |
ワークロードが実行されているプラットフォームとバージョン、およびポリシーに重要な情報を提供するシステムを Secure Workload がサポートしていることを確認します。「Cisco Secure Workload Compatibility Matrix」を参照してください。 |
ステップ 2 |
ワークロードにエージェントをインストールします。 エージェントは、ワークロードをグループ化し適切なポリシーを決定するために Secure Workload によって必要されるフローデータやその他の情報を収集します。エージェントは、承認されたポリシーも適用します。サポートされているプラットフォームと要件のリストへのリンクを含む詳細については、「ソフトウェアエージェントの展開」を参照してください。 |
ステップ 3 |
ワークロードを説明するラベルを収集するかアップロードします。 ラベルを使用すると、各ワークロードの目的を容易に把握でき、その他の重要な情報を提供できます。 この情報は、ワークロードをグループ化し、適切なポリシーを適用し、Secure Workload によって提案されたポリシーを理解するために必要です。ラベルは、ポリシー管理を簡素化するメンテナンスグループの基盤です。詳細については、「ワークロードラベル」およびカスタムラベルのインポートを参照してください。 |
ステップ 4 |
ワークロードラベルに基づいて範囲ツリーを作成します。 ラベルが作成に役立つワークロードの論理グループは「範囲」と呼ばれ、適切に選択されたラベルのセットは、範囲ツリーと呼ばれるネットワークの階層型マップの作成に役立ちます。ネットワーク上のワークロードの階層ビューは、ポリシーを効率的に作成およびメンテナンスするための鍵です。階層ビューを使用すると、ポリシーを一度作成するだけで、そのポリシーをツリーの該当するブランチの全ワークロードに自動的に適用できます。また、特定のアプリケーション(またはネットワークの一部)に関する責任を、それらのワークロードの正しいポリシーを決定するために必要な専門知識を持つ人員に委任できます。 ラベルに基づいて、ワークロードをクエリして、範囲にグループ化できます。たとえば、「Application = Email-app」および「Environment = Production」というラベルを持つすべてのワークロードを含む「Email-app」という範囲を作成できます。「Environment = Production」というクエリを使用して、「Application = Email-app」範囲の親範囲を作成できます。Production(実稼働)範囲には、実稼働 Email-app と、「Environment = Production」のラベルが付いた他のすべてのワークロードが含まれます。 詳細については、「範囲とインベントリ」を参照してください。 範囲をまだ作成していない場合は、クイックスタートウィザードを使用して範囲ツリーを作成できます。詳細については、クイックスタートウィザードを参照してください。 |
ステップ 5 |
ポリシーを作成する範囲ごとにワークスペースを作成します。 ワークスペースは、範囲内のワークロードのポリシーを管理する場所です。詳細については、「ワークスペース」を参照してください。 |
ステップ 6 |
ネットワーク全体に適用されるポリシーを手動で作成します。 たとえば、すべての内部ワークロードから NTP サーバーへのアクセスを許可し、すべての外部トラフィックを拒否するか、明示的に許可されていない限り、すべての非内部ホストからのアクセスを拒否することができます。ポリシーは、より具体的なポリシーによってオーバーライドできないことを意味する絶対ポリシー、またはより具体的なポリシーによってオーバーライドできるデフォルトポリシーに分類できます。 詳細については、ポリシーの手動作成を参照してください。 Cisco Secure Workload には、ポリシーの作成を容易にするポリシーテンプレートがあります。詳細については、ポリシーテンプレートを参照してください。 ポリシーが検出されるのを待たずに、手動で作成したポリシーを適用できます。詳細については、ポリシーの適用を参照してください。 |
ステップ 7 |
既存のトラフィックパターンに基づいて、ポリシーを自動的に検出します。 Secure Workload は、ワークロード間のトラフィックを分析し、動作に基づいてワークロードをグループ化し、組織が必要とするトラフィックを許可するための一連のポリシーを提案するため、他のすべてのトラフィックをブロックできます。 長期間にわたるデータフローの分析が増えると、より正確なポリシー提案が作成されます。 ポリシーは繰り返し検出できます(これについては、この手順で後に詳しく説明します)。
詳細については、「自動ポリシー検出」および1 つの範囲または範囲ツリーのブランチのポリシーの検出を参照してください。 |
ステップ 8 |
ポリシーを確認して分析します。 ポリシーを慎重に調べて、期待どおりの効果があり、意図していないマイナスの効果がないことを確認します。 組織内の対象分野の専門家およびアプリケーションオーナーと協力して、組織のニーズと提案されたポリシーの適切性を判断してください。 |
ステップ 9 |
必要に応じて繰り返しポリシーを検出します。 トラフィックフローが多いほど、より正確なポリシー提案が生成されます。たとえば、月次レポートの場合、3 週間分のデータがあっても、重要なすべてのトラフィックをキャプチャできない場合があります。引き続きポリシーを検出し、新しいポリシー提案を確認および分析します。検出を実行するたびに、最新のトラフィックフローに基づいてポリシーが提案されます。 また、ポリシー検出設定や承認されたクラスタにおける変更をキャプチャするためにポリシーを繰り返し検出できます。詳細については、反復的なポリシーの変更を参照してください。 自動ポリシー検出を再実行する前に、保持するポリシーとクラスタを承認していることを確認します。 ポリシーを再検出するたびに、ポリシーを再確認して再分析する必要があります。 |
ステップ 10 |
準備ができたら、ポリシーを適用します。 ワークスペース(および関連付けられた範囲)に関連付けられたポリシーが適切であり、重要なサービスを中断せずに不要なトラフィックをブロックすると判断したら、それらのポリシーを適用できます。 ポリシーは繰り返し適用できます。たとえば、最初はツリーの最上位近くの範囲で手動で作成したポリシーのみを適用し、その後、ツリーの下位の範囲で検出済みのポリシーを適用していくことができます。 詳細については、ポリシーの適用を参照してください。 |
ステップ 1 |
ネットワーク上のワークロードの IP アドレスの収集します。 ワークロードごとに、アプリケーション名、アプリケーションの所有者、環境(本番または非本番)、および適用するポリシーを決定するその他の情報(地理的地域など)も必要になります。 構成管理データベース(CMDB)がない場合は、この情報をスプレッドシートで収集できます。 開始するには、焦点を合わせることができる単一のアプリケーションを選択します。 |
ステップ 2 |
サポートされているベアメタルベースまたは仮想ワークロードにエージェントをインストールします。 詳細については、「ソフトウェアエージェントの展開」を参照してください。 |
ステップ 3 |
これらのワークロードを説明するラベルをアップロードします。 詳細については、「ワークロードラベル」およびカスタムラベルのインポートを参照してください。 必要に応じて、クイックスタートウィザードを実行して、ラベルと範囲ツリーの最初のブランチを作成できます。ウィザードの詳細については、「クイックスタートウィザード」を参照してください。 |
ステップ 4 |
必要に応じて、ラベルに基づいて範囲ツリーを作成または更新します。 詳細については、「範囲とインベントリ」を参照してください。 |
ステップ 5 |
ポリシーを適用する範囲ごとにワークスペースを作成します。 詳細については、「ワークスペース」を参照してください。 |
ステップ 6 |
ネットワーク全体に適用される手動ポリシーを作成します。 詳細については、ポリシーの手動作成を参照してください。 |
ステップ 7 |
プラットフォーム固有のポリシーの詳細については、プラットフォーム固有のポリシーを参照してください。 |
ステップ 8 |
下位レベルの範囲に関連付けられたワークスペースのポリシーを自動的に検出します。 詳細については、「自動ポリシー検出」およびサブトピックを参照してください。 |
ステップ 9 |
提案されたポリシーを確認して分析します。 詳細については、ポリシーの確認と分析とサブトピックを参照してください。 |
ステップ 10 |
必要に応じて繰り返しポリシーを検出します。 詳細については、反復的なポリシーの変更とサブトピックを参照してください。 |
ステップ 11 |
準備ができたら、ポリシーを適用します。 各ワークスペースのポリシーの動作に問題がなければ、ポリシーを適用できます。 ワークスペースとエージェント設定の両方でポリシーを適用する必要があります。 詳細については、ポリシーの適用を参照してください。 |
ステップ 1 |
必要に応じて、クラウドベースのワークロードにエージェントをインストールします。 クラウドコネクタは、ポリシーの検出と適用において VPC/VNet レベルの粒度を提供します。よりきめ細かいレベルでのポリシーの検出と適用が必要な場合は、サポートされているプラットフォームにエージェントをインストールします。 クラウドサービスが実行されているオペレーティング システムに基づいて、エージェントをインストールします。詳細については、「ソフトウェアエージェントの展開」を参照してください。 |
ステップ 2 |
Cloud Connector を設定して、ラベルとフローデータを収集します。 詳細については、以下を参照してください。 |
ステップ 3 |
コネクタによって作成された範囲のワークスペースを作成します。詳細については、「ワークスペース」を参照してください。 |
ステップ 4 |
ポリシーを自動的に検出します。 VPC/VNet で定義された範囲のポリシーを検出します(該当する場合は、より細かい範囲で検出)。 詳細については、「自動ポリシー検出」を参照してください。 |
ステップ 5 |
提案されたポリシーを確認して分析します。 「ポリシーの確認と分析」およびサブトピックを参照してください。 |
ステップ 6 |
必要に応じて繰り返しポリシーを検出します。 「反復的なポリシーの変更」およびサブトピックを参照してください。 |
ステップ 7 |
各範囲のポリシーを承認して適用します。 該当するワークスペースと各 VPC または VNet のコネクタ、および個々のワークロードにインストールされているエージェントの適用を有効にする必要があります。
|
ステップ 1 |
Kubernetes ベースのワークロードにエージェントをインストールします。要件および前提条件を確認します。 詳細については、「Kubernetes/Openshift エージェント:優れた可視性と適用」を参照してください。 エージェントは、該当する Kubernetes サービスによって今後管理されるすべてのワークロードに自動的にインストールされます。 |
ステップ 2 |
Kubernetes ベースのワークロードのラベルを収集します。 詳細については、次を参照してください。
|
ステップ 3 |
ラベルに基づいて範囲ツリーを作成または更新します。 詳細については、「範囲とインベントリ」を参照してください。 |
ステップ 4 |
ポリシーを適用する範囲ごとにワークスペースを作成します。 詳細については、「ワークスペース」を参照してください。 |
ステップ 5 |
各低レベル範囲のポリシーを自動的に検出します。 詳細については、「自動ポリシー検出」を参照してください。 |
ステップ 6 |
適用可能な追加オプションの詳細については、プラットフォーム固有のポリシーを参照してください。 |
ステップ 7 |
提案されたポリシーを確認して分析します。 詳細については、ポリシーの確認と分析を参照してください。 |
ステップ 8 |
必要に応じて、ポリシーを繰り返し検出、レビュー、分析します。 詳細については、反復的なポリシーの変更を参照してください。 |
ステップ 9 |
準備ができたら、各範囲のポリシーを承認して適用します。 ワークスペースとエージェントでポリシーの適用を有効にする必要があります。 |