Cisco Secure Workload オンプレミスクラスタから SaaS への移行

この章では、Cisco Secure Workload SaaS 展開への Cisco Secure Workload オンプレミスクラスタの移行について重点的に説明します。このシナリオでは、各オンプレミス クラスタ テナントが SaaS 上の専用テナントに移行されます。オンプレミスのアプライアンスに複数のテナントがある場合は、各テナントを SaaS 上の対応する専用テナントに移行し、移行した新しい各 SaaS テナントに一意の URL を使用してアクセスできるようにします。

この章は、次の項で構成されています。

オンプレミスクラスタから SaaS 展開へのデータ移行の概要

オンプレミスクラスタから Cisco Secure Workload の SaaS 展開にデータを移行する場合は、API を使用して移行プロセスを自動化します。ただし、オーケストレータ、コネクタ、仮想アプライアンス、およびユーザーアカウントの証明書とキーは手動で設定する必要があります。ユーザーは、ユーザーアカウントの移行中に、新しい Cisco Secure Workload インスタンスでパスワードをリセットする必要があります。


(注)  


構成データ、フローデータ、監査ログ、会話、および ADM 履歴は、アカウントの移行には含まれません。


エンドツーエンドの移行ワークフロー

スムーズな移行を確保するには、オンプレミスアプライアンスから SaaS 展開にデータと構成を移行するために必要な手順の概要が示されている次のエンドツーエンドのワークフローに従います。移行アクティビティを最大化するには、各手順を順番に実行することが重要です。

図 1. 移行の準備

移行の準備

一般的な要件、前提条件、および制限事項を含む移行の準備。

スクリプトを使用した構成コンポーネントの移行

移行スクリプトをダウンロードしたら、ReadMe.txt ファイルを見つけて、テキストファイルの手順を確認します。クライアントマシンに Python 環境と移行スクリプトに必要なライブラリがインストールされていることを確認します。

構成とエージェントの移行

移行前チェックリストを作成したら、構成とソフトウェアエージェントの移行を続行します。

移行後の検証

自動構成項目と手動構成項目を移行したら、チェックリストスクリプトを再実行して移行状況を確認します。

前提条件

このマニュアルは、読者が Cisco Secure Workload ソリューションに精通していることを前提としており、移行プロセスに関するその他の前提条件を提供します。前提条件は次のとおりです。

  • 移行プロセスに関与するオンプレミスクラスタがある場合は、単一のテナントが存在するか、オンプレミスクラスタの各テナントが専用の SaaS テナントに個別に移行されます。

  • 適切なライセンスが移行先テナントで使用可能であり、SaaS への移行に管理者アクセスを使用できます。

  • 移行期間中、オンプレミスクラスタ環境の構成は変更されません。

  • 移行期間中、オンプレミスクラスタ環境での構成変更はフリーズします。

  • オンプレミスのアプライアンスとサービスは期待どおりに動作し、正常です。

  • オンプレミスのアプライアンスからの重大または警告レベルのアラートがないことを確認します。

  • リリース 3.8 では、次の機能が廃止されています。

    • ハードウェアセンサーとユニバーサルエージェント。

    • データプラットフォーム:Tetration Lookout アプリケーション([編成(Organize)] > [Look Out]

    • [ダッシュボード(Dashboard)]:[フロー(Flows)]([Investigate] > [トラフィックダッシュボード(Traffic Dashboard)])。

    • [パフォーマンス ダッシュボード(Performance Dashboard)]([Investigate] > [パフォーマンス ダッシュボード(Performance Dashboard)])。

    • ネイバーフッド アプリケーション([Investigate] > [ネイバーフッド(Neighborhood)])。

    • [ワークスペース(Workspace)] 内のポリシーコードビュー。

移行の準備

一般的な要件

  • オンプレミスクラスタとソフトウェアエージェントは、バージョン 3.8 以降である必要があります。オンプレミスのアプライアンスで古いバージョンを実行している場合は、クラスタとソフトウェアエージェントを 3.8 バージョンにアップグレードしてから、移行を続行することを推奨します。

    アップグレード方法の詳細については、『Cisco Secure Workload アップグレードガイド』を参照してください。

  • Cisco Secure Workload プラットフォーム API と通信する外部システムのリストを作成します。移行が完了したら、新しい SaaS テナントで適切な Cisco Secure Workload API ログイン情報を作成し、新しいキーを使用して外部システムを更新してください。

  • 移行中にエージェント適用の一時的な中断が予想されるため、メンテナンス期間を適宜計画してください。

前提条件

  • 手動 API または自動化された API を使用して SaaS テナントを作成する場合は、ローカルユーザーをオンプレミス環境から SaaS テナントに移行します。

    外部認証には次の 2 つのタイプがあります。

    • Lightweight Directory Access Protocol(LDAP):SaaS 環境でサポートされていないローカルユーザーを移行するには、最初にユーザーを ID プロバイダー(IdP)に移行する必要があります。ユーザーを IdP に移行するには、ユーザーとロールの手動移行の要求を SaaS プラットフォームで送信します。

    • シングルサインオン(SSO):SSO の移行では、カスタマー IdP とのフェデレーションを使用します。このタイプの外部認証では、SaaS プラットフォームと IdP 間の信頼関係を確立する必要があります。ユーザーとロールの手動移行の要求を SaaS プラットフォームで送信します。

  • Cisco Secure Workload テナントにアクセスするための URL を変更します。

  • CMDB エントリと保持の側面(オンプレミスと SaaS)を確認します。

    データの保持と削除の詳細については、「Cisco Secure Workload as a Service」を参照してください。

  • オンプレミスから SaaS に移行する場合、オンプレミスアプライアンスの[プラットフォーム(Platform)] > [トラブルシュート(Troubleshoot)]セクションにある Cisco Secure Workload UI オプションは使用できません。また、SaaS 展開では外部インフラストラクチャのモニタリングは不要です。

    • SaaS 展開では、HTTP アウトバウンド/プロキシ構成は不要です。

    • [使用状況分析(Usage Analytics)] オプションは、SaaS 展開では使用できません。

  • エンタープライズ アウトバウンド ファイアウォール ルールで、Cisco Secure Workload SaaS の移行先へのアウトバウンドアクセスが許可されていることを確認します。SaaS のウェルカム電子メールには、許可リストに含める必要がある IP の詳細なリストがあります。

  • 移行ワークフローの実行中に、検証の出力を文書化してください。

  • 新機能の詳細については、リリースノートを参照してください。リリース 3.8 では、次の機能が廃止されています。

    • ハードウェアセンサーとユニバーサルエージェント

    • データプラットフォーム:Tetration Lookout アプリケーション([編成(Organize)] > [Look Out]

    • [ダッシュボード(Dashboard)]:[フロー(Flows)]([Investigate] > [トラフィックダッシュボード(Traffic Dashboard)])。

    • [パフォーマンス ダッシュボード(Performance Dashboard)]([Investigate] > [パフォーマンス ダッシュボード(Performance Dashboard)])。

    • ネイバーフッド アプリケーション([Investigate] > [ネイバーフッド(Neighborhood)])。

    • ワークスペース内のポリシーコードビュー

制限事項

  • 次のデータ項目は移行されません。

    • 履歴フローデータ

    • 変更ログ

    • API キー(再作成して外部システムに追加)

  • ワークスペース内では、次のデータ項目は移行されません。

    • アクティビティログとポリシーバージョン履歴

    • ADM カンバセーションと ADM 結果の履歴と変更履歴

    • ポリシーの最新バージョンのみが移行されます。移行が完了したら、ポリシー分析を再度有効にします。

  • 次のデータ項目は、SaaS 展開では使用できず、サポートされていません。

    • エージェントのリモート VRF 構成とインターフェイス構成のインテント

    • [ログイン(Login)] ページのメッセージと SSL 証明書のオプション

    • STIX-TAXII

    • [連携(Federation)]

  • 移行中、SaaS 展開では以下の内容は使用できないか、または不要です。

    • オンプレミスのアプライアンスでは、GUI オプションの[プラットフォーム(Platform)] > [トラブルシュート(Troubleshoot)]は使用不可。

    • [使用状況分析(Usage Analytics)] オプションは使用不可。

    • 外部インフラストラクチャのモニタリングの回避。

    • HTTP アウトバウンドまたはプロキシ構成の回避。

スクリプトを使用した構成コンポーネントの移行

手順


ステップ 1

移行スクリプトをダウンロードしたら、ReadMe.txt ファイルを見つけて手順を確認し、Python 環境を作成し、移行スクリプトに必要なライブラリをクライアントマシンにインストールします。

(注)  

 

TAC ケースをオープンし、オンプレミスから SaaS への移行スクリプトへのアクセスを要求します。実際のコマンドの使用方法と出力は、このマニュアルとは異なります。移行時に提供される詳細については、README マニュアルを参照してください。

ステップ 2

移行元と移行先の両方のクラスタテナントで、サイト管理者として Cisco Secure Workload テナントにログインします。

ステップ 3

Cisco Secure Workload UI で、人間のアイコン > [APIキー(API Keys)]の順に選択します。

ステップ 4

API キーを作成するには、[APIキーの作成(Create API Key)] を選択し、次のリストにある少なくとも 1 つの API 機能をオンにします。

図 2. API キー機能

ステップ 5

API キーファイルをダウンロードし、移行スクリプトと同じ場所に保存します。

ステップ 6

オンプレミステナントでチェックリストスクリプトを実行して、移行する構成項目のリストを準備します。チェックリストスクリプトからの出力は必ず記録してください。

ステップ 7

移行のさまざまな段階で新しい SaaS テナントに対してチェックリストスクリプトを再実行して、すべての構成項目が適切に移行されるようにします。

図 3. チェックリストスクリプトの出力

(注)  

 

移行スクリプトを使用すると、一部の構成項目は自動化されますが、一部の項目は自動化されない可能性があります。現時点では API がサポートされていないため、最後の一連の構成項目は手動で移行する必要があります。

次の表に、移行対象構成項目の完全なリストを示します。

表 1. 移行対象構成コンポーネント

構成コンポーネント

移行方法

手動ラベル

自動

スコープ

自動

インベントリフィルタ

自動

エージェントプロファイル

自動

エージェントインテント

自動

ワークスペース

自動

ワークスペースポリシー(最新バージョン)

自動

ワークスペースクラスタ

自動

ロール

自動

ユーザー

自動

除外フィルタ:デフォルトおよびワークスペース

自動

外部オーケストレータ

自動(ログイン情報が必要)

クライアントサーバーの構成(サーバーポート)

自動

フォレンジック:プロファイルとインテント

自動

ポリシーテンプレート(カスタムテンプレート)

手動(API 利用可能、未自動化)

収集ルール

自動

デフォルトの ADM 構成

自動

アラート設定/パブリッシャ

自動

セキュアコネクタ

手動(API 利用不可)

仮想アプライアンス(Ingest または Edge)

手動(API 利用不可)

コネクタ

手動(API 利用可能、未自動化)

データタップの構成

手動(API 利用不可)

(注)  

 

外部オーケストレータコネクタを使用している場合は、次の移行フェーズに進む前に、ログイン情報を用意してください。


構成とソフトウェアエージェントの移行

構成とエージェントを移行する最初のステップとして、移行前チェックリストを準備します。移行前チェックリストの準備ができたら、構成とエージェントの移行を開始します。依存関係のない一部の構成を並行して移行する場合は、エージェントの移行、移動、インストール、アンインストール、およびカットオーバー アクティビティの適用など、中断を伴うアクションのメンテナンス期間をスケジュールすることを推奨します。

顧客体験(CX)エンジニアとパートナーが、ご使用の環境と特定の要件を考慮した移行プロセス全体の詳細を記載した計画を作成します。

構成の移行

始める前に

仮想アプライアンス(Injest および Edge)とセキュアコネクタがすでに使用されている場合、移行を続行するにはそれらを再展開することを推奨します。

詳細については、『Cisco Secure Workload ユーザーガイド』の「Virtual Appliances for Connectors」を参照してください。

オンプレミスクラスタからのみ外部オーケストレータやコネクタにアクセスでき、SaaS テナントに移行する場合は、SaaS とオンプレミス インフラストラクチャ間の接続のために、オンプレミスのアプライアンスにセキュアコネクタを展開することを推奨します。

詳細については、『Cisco Secure Workload ユーザーガイド』の「Secure Connectors」を参照してください。

手順


ステップ 1

移行スクリプトを実行して構成を移行します。

図 4. ラベルの移行
図 5. 範囲ツリーの移行

(注)  

 

オーケストレータとコネクタ、またはエージェントのラベルに基づくフィルタ、範囲、およびインテントのクエリはすべて、新しい SaaS テナントに移行されますが、ステータスに「不明な注釈」と表示される場合があります。新しい SaaS テナントへのエージェント、コネクタ、およびオーケストレータの移行が完了すると、GUI に警告が表示されなくなります。

図 6. 不明な注釈

(注)  

 

移行スクリプトは、SaaS テナント内のワークスペースの適用を無効にするため、エージェントの移行完了後に適用を再度手動で有効にする必要があります。

ステップ 2

サマリー スクリプト オプションを実行して、各自動構成項目を移行前に記録された出力と比較します。特定の項目の不一致については、オンプレミスのテナント構成と SaaS テナント構成の比較を実行して、構成項目を特定します。

(注)  

 

TAC および SRE チームと協力して、移行の失敗原因をさらに調査します。

ステップ 3

共有自動化スクリプトを使用してコネクタの移行は自動化できませんが、自動化された移行には API を使用できます。コネクタの API キー、シークレット、またはログイン情報を再作成し、以降先 SaaS テナントの新しい構成に追加します。詳細については、『Cisco Secure Workload ユーザーガイド』の「Secure Connectors」を参照してください。


ソフトウェアエージェントの移行

始める前に

オンプレミスクラスタとソフトウェアエージェントが同じバージョン(Cisco Secure Workload 3.8.xx)で実行されていることを確認します。

移行プロセスを開始する前に、必要なアプリケーションに対する機能テストのリストを準備します。テストを実行し、期待どおりの結果が得られ、結果が記録されていることを確認します。

手順


ステップ 1

移行のために選択した一連のエージェントの適用を無効にします。移行計画に応じて、すべてのエージェントを移行するための単一のアプローチまたは段階的なアプローチを選択します。

ステップ 2

ナビゲーションウィンドウで、[管理(Manage)] > [エージェント(Agents)]の順に選択し、[エージェントのリホーム(Agent Rehoming)] オプションを選択して、 エージェントのリホーム構成を追加します。

[範囲アクティベーションキー(Scope Activation Key)]:ナビゲーションウィンドウで、[メニュー(Menu)] > [ワークロード(Workloads)] > [エージェント(Agents)] > [インストーラ(Installer)] タブ > [エージェント イメージ インストーラ(Agent Image Installer)]の順に選択します。

[移行先センサーCA証明書(Destination Sensor CA Cert)]:移行先クラスタのナビゲーションウィンドウで、[メニュー(Menu)] > [プラットフォーム(Platform)] > [クラスタ構成(Cluster Configuration)]の順に選択します。

[移行先センサーVIP(Destination Sensor VIP)]:移行先クラスタのナビゲーションウィンドウで、[メニュー(Menu)] > [プラットフォーム(Platform)] > [クラスタ構成(Cluster Configuration)]の順に選択します。

(注)  

 

SaaS 展開の場合は、センサー VIP:「wss<cluster_name>.tetrationcloud.com」および「cluster_name」をエージェント インストーラ スクリプト名から取得します。インストーラスクリプトのファイル名の形式は、tetration_installer_<tenant_name>_<agent_type>_<os>_<cluster_name> です。

図 7. エージェントのリホーム

ステップ 3

エージェントのリホームについては、すべてのエージェントまたは移行に必要な一連のエージェントのみを選択し、[エージェントのリホーム(Re-home Agents)] をクリックします。

ステップ 4

Cisco Secure Workload UI の[管理(Manage)] > [エージェント(Agents)] > [エージェントリスト(Agent list)]の下に各エージェントが正しく登録されていることを確認します。

ステップ 5

エージェントを移行したら、関連するワークスペースでの適用を有効にします。

ステップ 6

ワークスペースでポリシーをプロビジョニングしていることを確認します。ナビゲーションウィンドウで、Cisco Secure Workload UI の[防御(Defend)] > [適用ステータス(Enforcement status)]の順に選択して、以下の点を確認します。

  • [同期している具体的なポリシー(Concrete Policies in Sync)] ステータスが緑色で [はい(Yes)] と表示されている。

  • [同期している具体的なポリシー(Concrete Policies in Sync)] ステータスが 赤色で [いいえ(No)] と表示されている。

    ナビゲーションウィンドウで、指定されたワークロードの [ワークロードプロファイル(Workload profile)] を選択し、[ログのダウンロード(Download logs)] > [ログ収集の開始(Initiate log collection)]でエラーを探します。

(注)  

 

必要なすべてのチェックを完了してから、検証チェックに進みます。


移行後の検証

自動構成と手動構成を移行したら、チェックリストスクリプトを再実行し、SaaS テナントの構成項目(エージェントの数を含む)がオンプレミステナントの項目と一致していることを確認します。
図 8. 移行後の検証