ビュー:
このガイドでは、TrendAI™ Cloud One File Storage Security (C1FSS) から TrendAI Vision One™ File Security Storage (V1FSS) へのAWS accountの更新手順を説明します。この更新は共存ベースでダウンタイムがありません。ツールは既存のC1FSSと並行してV1FSSを立ち上げ、新しいスキャンが機能することを確認した後、C1FSSを地域ごとに廃止するため、バケットが未保護のままになることはありません。
At a glance:
  1. Dry run: runは、何も触れずにすべての変更をプレビューします。
  2. 実行: run --executeはV1FSSをC1FSSの隣に展開します (両方が並行して検索します)。
  3. Verify & tear down, per region: V1FSSが機能することを確認し、その地域のC1FSSを削除してください。
rollbackを使用して、削除前にいつでも取り消すことができます。

前提条件

  • TrendAI Vision One™ APIキーは、オペレーターの役割 (または同等の権限と範囲を持つカスタム役割) を持っています。このツールはそれを使用してFile Securityを有効にし、CAMテンプレートをAWS accountにデプロイします。
  • C1FSSがデプロイされているアカウントのAWS認証情報は、TrendAI Vision One™ CAMコネクタ/File Security Storage機能スタックをデプロイし、更新の独自のディスカバー/ティアダウン/検証アクションを実行できる必要があります。管理者相当のロールが最も簡単です。スコープされたポリシーについては、AWS required permissionsを参照してください。
  • AWS CloudShellへのアクセス (推奨)。AWS認証情報を環境的に提供するため、ローカル設定は不要です。他の場所で実行するには、CloudShell FAQを参照してください。

アップデートを実行

  1. CloudShellを開いてAPIキーを設定してください。
    C1FSSがデプロイされているAWS accountでCloudShellを開き、設定します:
    export V1_API_KEY="your-vision-one-api-key"
  2. ツールをダウンロードしてテスト実行を行ってください。
    curl -sSL https://v1-file-security-storage.s3.amazonaws.com/aws/tools/v1fss-migrate.zip \
      -o v1fss-migrate.zip
    unzip -q v1fss-migrate.zip
    python3 -m v1fss_migrate run
    すべての変化する手順は[dry-run by default]です: 何も作成、変更、または削除されません。これにより、発見されたC1FSSスタック、それらが検索するバケット、およびツールが取る正確なアクションが出力されます。プリフライト → 発見 → オンボード → 同期 → 有効化 → 検証の手順を進みます。
  3. 計画を確認してから実行してください。
    python3 -m v1fss_migrate resume --run-id <run-id> --execute
    各実行にはrun-idが割り当てられます (開始時に表示され、~/.v1fss-migrate/state-<run-id>.jsonにチェックポイントされます)。CloudShellのアイドルタイムアウトが中断した場合、完了したフェーズを繰り返さずに再開してください。
    python3 -m v1fss_migrate resume --run-id <run-id> --execute
    run --executeの実行中に、2つの質問がされることがあります (どちらも対話型ターミナルが必要であり、CloudShellが該当します):
    • SWP instance selection: テナントに複数のServer & Workload Protectionインスタンスがある場合、onboardは一時停止し、番号で選択するためにそれらを一覧表示します。--workload-instance-id <id>を使用してプロンプトをスキップします (TrendAI Vision One™コンソールのServer & Workload Protectionで見つけることができます)。
    • Verify bucket: verifyは各リージョンで1回実行され、そのリージョンにあるC1FSSで保護されていないバケットを要求します。これにより、V1FSSがその場所でスキャンを行うことを証明できます。バケット名を入力するか、そのリージョンの検証をスキップするには空白のままにします (スキップしても問題ありません。詳細はverify FAQを参照してください)。C1FSSで保護されているバケットや、異なるリージョンにあるバケットはその場で拒否され、再度要求されます。
  4. 1つのリージョンずつ検証して解体します。
    手順3の後、すべてのリージョンはすでにverifyを実行しています (プロンプトを空白のままにした場合はスキップとしてマークされます)、したがってすべてのリージョンはテアダウンの準備が整っています。テアダウンは、verifyではなく、V1FSSがバケットの保護を確認したことに基づいています。
    注意
    注意
    [Verify is optional.] 単独で実行して、特定の地域に対する明確なエンドツーエンドの検索証明を取得するか、検証に失敗した地域を再検証します。C1FSSの下にない、--regionsの地域にあるバケットを使用してください。
    python3 -m v1fss_migrate verify \
      --run-id <run-id> --regions us-east-1 \
      --verify-bucket <bucket-not-under-c1fss> --execute
    [Tear down]地域のC1FSSスタック:
    python3 -m v1fss_migrate teardown \
      --run-id <run-id> --regions us-east-1 --execute
Teardownは地域ごとに制限されています。これは、地域の検証が完了したかスキップされた後に、その地域のC1FSSスタックを削除します。実際に実行されて失敗した検証は、その原因を修正して再実行するまでその地域をブロックします。いずれにせよ、teardownはV1FSSが保護されていると確認したバケットのスタックのみを削除し、ある地域のステータスが他の地域をブロックすることはありません。(run --executeの後、ツールはコピー用の正確なteardown … --executeコマンドを表示します。)
[If your C1FSS is deployed in a VPC, teardown takes noticeably longer.] VPCに接続されたスキャナー (またはストレージ) Lambdaの削除は、AWSネットワークインターフェイス (ENI) のクリーンアップを待機します。これは通常[10–40 minutes per stack]で実行され、非VPCスタックの場合は1分または2分です。スタックは並行して削除されるため、フェーズは最も遅いものに制約され、合計ではありません。各削除はデフォルトで[1時間]まで待機します。必要に応じて--teardown-timeout <seconds>で延長してください。これは予期された動作ですので、そのまま実行させてください。詳細はテアダウンFAQをご覧ください。
C1FSSが複数のリージョンにまたがる場合、残りの各リージョンに対して両方のコマンドを繰り返してください。
python3 -m v1fss_migrate verify \
  --run-id <run-id> --regions us-west-2 \
  --verify-bucket <another-bucket-not-under-c1fss> --execute

python3 -m v1fss_migrate teardown \
  --run-id <run-id> --regions us-west-2 --execute
teardownでは、そのリージョンのC1FSSスタックを完全に削除することを確認するためにDELETE C1FSSを入力するよう求められます。非対話モードで実行する際にプロンプトをスキップするには、--yesを渡してください。
すべてのリージョンが削除されると、アップデートが完了します: V1FSSがバケットをスキャンし、C1FSSは廃止されます。

更新されていないもの

このツールは、SSE-KMSキーARN、検索結果タグ形式、スキャナーの一時ストレージサイズ、VPC Subnets/セキュリティグループ/プロキシ、昇格/隔離先バケット、および (警告付きで) IAM権限境界など、V1FSSに直接対応する設定を引き継ぎます。それ以外のものは、明示的なオンボード警告とともに削除されるか、まったく検出されません。完全な互換性に依存する前にこれを確認してください。
  • Account-Scanner topology: サポートされていません。discoverはそれを見つけた場合、直ちに中止します。代わりに手動のランブックでそのアカウントを更新してください。
  • Org (CAM organizational) accounts: サポートされていません。たとえそのアカウントでC1FSSをまだ更新していなくてもです。CAMコネクタスタックは、アカウントごとに作成または更新されるのではなく、組織の管理アカウントからStackSetによってプッシュされます。
  • [C1 settings with no V1 equivalent](onboard中に「NOT carried over」として記録される): ReportObjectKeyScanOnGetObjectExclusiveBucketListEnableCrossAccountScanningAdditionalIAMPoliciesObjectFilterPrefixObjectCreatedEventFilter。オブジェクトキーのプレフィルタは、たとえ1つのC1バケットのみが設定していても、決して引き継がれません。V1FSSの同等機能はアカウント全体に適用され、バケットごとではないため、C1でフィルタが設定されていなかった他のすべてのバケットに対してスキャンを誤って狭めることになります。
  • [Promote/quarantine in][コピー][mode]: V1FSSの検索後のアクションは、[moves]されたオブジェクトにのみ適用されます。コピー・モードの同等機能はありません。C1プラグインがPromoteMode/QuarantineMode = copy(元のオブジェクトはソースバケットに残る) を実行する場合、onboardは警告をログに記録します: カットオーバー後、ソースオブジェクトは[削除]され、保持されません。C1を解体する前に、これが許容されることを確認してください。
  • Plugin object ACLs: C1プラグインは移動するオブジェクトにカスタムACLを再適用しますが、V1FSSのアクションはそうしないため、プラグインのACL設定は引き継がれません (onboardは見つかった場合にWARNINGを記録します)。
  • Conflicting per-region values: 同じリージョン内で2つ以上のC1スタックが異なるVPC Subnets/セキュリティグループ/プロキシを報告した場合、または異なるリージョンが異なるIAM権限境界を報告した場合、競合する値は引き継がれません (onboard は影響を受けたリージョンを名前付きでWARNINGをログに記録します); その後、コネクタースタックで手動で設定してください。
  • Conflicting scan-result tag formats: 検索結果タグ形式 (Separated tags / Merged tag / No tag) はV1FSSで[account-wide]ですので、上記の値とは異なり、C1スタックが一致しない場合に単純に削除することはできません。C1スタックが[different]タグ形式を地域全体で使用している場合、onboard[majority]形式を選択し、アカウント全体に適用し、見つかった形式と選択された形式をリストしたWARNINGをログに記録します。C1スタックが異なる形式を使用していたバケットは、切り替え後に選択された形式でタグ付けされ、C1の動作から変更されます。異なる形式が必要な場合は、その後にコネクタースタックでFileSecurityStorageScanResultTagFormatを設定してください。
  • IAM permissions boundary: デフォルトで引き継がれますが、WARNINGとしてフラグが立てられます。C1とV1は異なるCFNリソース/IAMロールを使用しているため、C1で機能した境界がV1のデプロイを妨げる可能性があります。--skip-permission-boundaryを渡して除外してください。

トラブルシューティングとFAQ

Can I run it outside AWS CloudShell?
はい。CloudShellはAWS認証情報を環境的に提供するために推奨されています。Python 3、boto3ライブラリ、C1FSSアカウント用のAWS認証情報 (環境変数、名前付きプロファイル、またはSSO)、およびexport V1_API_KEY=…を備えたホストであれば同様に動作します。SSO/SAMLセッションは実行中に期限切れになることがあります。それらを更新し、resume --run-id <run-id> --executeを実行してください。
What if my account spans multiple regions?
runはデフォルトで有効なすべてのリージョンをスキャンし、すべてのリージョンをオンボード/同期/有効化を一緒に実行します。verifyteardownのみがリージョンごとに行われる (手順4) ため、各リージョンを個別に検証し、切り替えを行います。
How do I resume an interrupted run?
停止した場所を確認してから続行してください。完了したフェーズはスキップされます。
python3 -m v1fss_migrate status --run-id <run-id>
python3 -m v1fss_migrate resume --run-id <run-id> --execute
Is there downtime during the switch?
いいえ。ゼロダウンタイムがデフォルトです。V1FSSを有効にすると、EventBridge通知がC1FSSの既存のLambda通知と同じバケットに統合されます。C1FSSは最後の手順でスタックが解体されるまでオブジェクトのスキャンとタグ付けを続けます。
How do I back out (rollback)?
python3 -m v1fss_migrate rollback --run-id <run-id> --execute
ロールバックはV1FSSのオンボーディングを逆転させます: 有効にしたV1スキャンを無効にし (EventBridge通知を削除)、作成したV1コネクタを削除するか、更新前の状態に戻します。C1FSSには一切触れません (C1スタック、通知、プロモート/隔離プラグインはそのままです)、したがってロールバックは単に「C1FSSのみ」に戻します。これはテアダウン前にのみ意味があります (C1スタックの削除は不可逆です)、そしてテアダウンがすでに始まっているリージョンではV1を無効にしないように意図されています (それはC1もV1もないバケットを残すことになります)。
[Do I have to run]検証?
いいえ。それは任意です。Teardownは、V1FSSがバケットの保護を確認した後にのみ、リージョンのC1FSSスタックを削除するため、cutoverはそれなしでも安全です。verifyは追加のエンドツーエンドの証明です: C1FSSに属さないバケットにクリーンなオブジェクトとEICARオブジェクトをアップロードし、検索タグを確認します。これをスキップしても、teardownは進行しますが、その証明なしでリージョンが廃止されることをログに記録します。ただし、verifyが実行されて失敗した場合、そのリージョンのteardownはブロックされます。verifyがテストオブジェクトをアップロードできない場合 (オブジェクトロック、制限的なバケットポリシー、または呼び出し元が使用できない必要なKMS Key)、それを報告してスキップします: V1コンソールで手動で検索を確認するか、別のverifyバケットを選択してください。(EICARは標準の不正プログラム対策テスト文字列であり、実際の不正プログラムではありません。)
What happens to my promote/quarantine rules?
onboardは、C1FSSのプロモート/隔離プラグイン設定を読み取り、それを同等のV1FSSアクションパラメータにマッピングします。これにより、バケットはカットオーバー後も同じクリーン/隔離動作を維持します。(コピーモードとオブジェクトACLは例外です。「更新されないもの」を参照してください。)
How long does teardown take, and can a slow stack fail it?
通常、スタックごとに数分かかりますが、C1FSSがVPCにデプロイされている場合は、さらに時間がかかると予想してください。VPCに接続されたスキャナー (またはストレージ) Lambdaを削除する際、AWSのネットワークインターフェース (ENI) のクリーンアップが支配的で、通常スタックごとに10~40分かかります。テアダウンはスタックを並行して削除します (最初にストレージ/プラグインスタック、次にスキャナー)、そのためフェーズは合計ではなく、最も遅いスタックによって制限されます。各削除はデフォルトで最大1時間待機します。異常に遅いスタックの場合は--teardown-timeout <seconds>で時間を延長してください。まだ完了しないスタックは報告され、他のスタックがすでに削除されている状態でフェーズが停止します。同じteardownコマンドを再実行して、そのスタックのみを再試行してください。
What happens to my Scanner stacks at teardown?
All-in-Oneスタック内にバンドルされたスキャナーは、親スタックのカスケード削除によって削除されます。スタンドアロンのスキャナースタック (ストレージ+スキャナートポロジーの分割) は共有インフラストラクチャであり、1つのスキャナーが複数のストレージスタックにサービスを提供できるため、ツールは他に必要なものがないことを証明できる場合にのみ自動削除します。それにポイントしているすべてのストレージスタック (ScannerSQSURL → スキャナーのScannerQueueURLで一致) がこの実行で解体され、ディスカバリーがアカウント全体をカバーしている (--regionsなし)、かつスキャナーのSQS Queueポリシーが他のAWS accountsに権限を付与していない場合です。これらのいずれかが確認できない場合 (特にこの実行でストレージスタックにサービスを提供しているクロスアカウント/中央スキャナーが見えない場合)、ツールはスキャナースタックをそのままにし、他のアカウントIDを名前付きで説明するNOTEをログに記録し、他に使用されていないことを確認した後に手動で削除できるようにします。
Can I run individual phases?
はい。preflightdiscoveronboardsyncenableverifyは、それぞれ単独で実行されます (runと同じフラグ) ので、手動で更新を進めたい場合に使用できます。