Ansichten:
Dieser Leitfaden führt Sie durch die Aktualisierung Ihres AWS-Kontos von TrendAI™ Cloud One File Storage Security (C1FSS) zu TrendAI Vision One™ File Security Storage (V1FSS). Das Update basiert auf Koexistenz und ist ohne Ausfallzeiten: Das Tool richtet V1FSS neben Ihrem bestehenden C1FSS ein, bestätigt, dass der neue Scan funktioniert, und nimmt dann C1FSS regionenweise außer Betrieb, sodass Ihre Buckets niemals ungeschützt bleiben.
At a glance:
  1. Dry run: ausführen zeigt Vorschauen jeder Änderung an, ohne etwas zu berühren.
  2. Ausführen: run --execute stellt V1FSS neben C1FSS bereit (beide durchsuchen parallel).
  3. Verify & tear down, per region: Überprüfen Sie, ob V1FSS funktioniert, und löschen Sie dann die C1FSS dieser Region.
Sie können jederzeit vor dem Abbau mit Rollback zurücktreten.

Voraussetzungen

  • Ein TrendAI Vision One™ API-Schlüssel mit der Operator-Rolle (oder einer benutzerdefinierten Rolle mit gleichwertigen Berechtigungen und Umfang). Das Tool verwendet ihn, um Dateisicherheit zu aktivieren und die CAM-Vorlage in Ihrem AWS-Konto bereitzustellen.
  • AWS-Anmeldeinformationen für das Konto, in dem C1FSS bereitgestellt ist, die sowohl den TrendAI Vision One™ CAM-Connector / File Security Storage Feature-Stacks bereitstellen als auch die eigenen Entdeckungs-/Abbau-/Überprüfungsaktionen des Updates ausführen können. Eine Administrator-äquivalente Rolle ist am einfachsten; für eine eingeschränkte Richtlinie siehe AWS erforderliche Berechtigungen.
  • Zugriff auf AWS CloudShell (empfohlen). Es stellt AWS-Anmeldedaten bereit, sodass keine lokale Einrichtung erforderlich ist. Um es anderswo auszuführen, siehe die CloudShell FAQ.

Update ausführen

  1. Öffnen Sie CloudShell und setzen Sie Ihren API-Schlüssel.
    Öffnen Sie in dem AWS-Konto, in dem C1FSS bereitgestellt ist, CloudShell und setzen Sie:
    export V1_API_KEY="Ihr-Vision-One-API-Schlüssel"
  2. Laden Sie das Tool herunter und führen Sie einen Probelauf durch.
    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
    Jeder mutierende Schritt ist dry-run by default: Es wird nichts erstellt, geändert oder gelöscht. Dies druckt die entdeckten C1FSS-Stacks, die Buckets, die sie DURCHSUCHEN, und die genauen Aktionen, die das Tool ausführen würde, indem es durch Preflight → Entdecken → An Bord nehmen → Synchronisieren → Aktivieren → Überprüfen geht.
  3. Überprüfen Sie den Plan, dann ausführen.
    python3 -m v1fss_migrate resume --run-id <run-id> --execute
    Jeder Lauf erhält eine run-id (wird zu Beginn ausgegeben und in ~/.v1fss-migrate/state-<run-id>.json gespeichert). Wenn das Leerlauf-Timeout von CloudShell Sie unterbricht, setzen Sie fort, ohne abgeschlossene Phasen zu wiederholen:
    python3 -m v1fss_migrate resume --run-id <run-id> --execute
    Während run --execute werden Ihnen möglicherweise zwei Fragen gestellt (beide erfordern ein interaktives Terminal, CloudShell zählt dazu):
    • SWP instance selection: Wenn Ihr Mandant mehr als eine Server- und Workload Protection-Instanz hat, pausiert onboard und listet sie zur Auswahl nach Nummer auf. Überspringen Sie die Eingabeaufforderung mit --workload-instance-id <id> (finden Sie diese in der TrendAI Vision One™-Konsole unter Server- und Workload Protection).
    • Verify bucket: verify wird einmal pro Region ausgeführt und fragt nach einem Bucket, der nicht durch C1FSS geschützt ist und sich in dieser Region befindet, damit es nachweisen kann, dass V1FSS ihn dort scannt. Geben Sie einen Bucket-Namen ein oder lassen Sie das Feld leer, um die Überprüfung dieser Region zu überspringen (Überspringen ist in Ordnung; siehe die verify-FAQ). Ein Bucket, der durch C1FSS geschützt ist oder sich in einer anderen Region befindet, wird sofort abgelehnt und erneut abgefragt.
  4. Überprüfen und abbauen, eine Region nach der anderen.
    Nach Schritt 3 hat jede Region bereits verify ausgeführt (erfolgreich oder als übersprungen markiert, wenn Sie die Eingabeaufforderung leer gelassen haben), sodass alle Regionen bereit für den Abbau sind. Der Abbau hängt davon ab, dass V1FSS bestätigt hat, dass Ihre Buckets geschützt sind, nicht von der Überprüfung.
    Hinweis
    Hinweis
    Verify is optional. Führen Sie es eigenständig aus, um einen expliziten End-to-End-Durchsuchungsnachweis für eine Region zu erhalten oder um eine Region erneut zu überprüfen, deren Überprüfung fehlgeschlagen ist. Verwenden Sie einen Bucket, der nicht unter C1FSS steht und sich in der Region von --regions befindet:
    		 
    python3 -m v1fss_migrate verify \
  --run-id <run-id> --regions us-east-1 \
  --verify-bucket <bucket-not-under-c1fss> --execute
    Tear down die C1FSS-Stacks der Region:
    python3 -m v1fss_migrate teardown \
  --run-id <run-id> --regions us-east-1 --execute
Teardown ist pro Region gesperrt. Es löscht die C1FSS-Stacks einer Region, sobald die Überprüfung dieser Region bestanden oder übersprungen wurde; eine Überprüfung, die tatsächlich ausgeführt wurde und fehlgeschlagen ist, blockiert diese Region, bis Sie die Ursache beheben und sie erneut ausführen. In jedem Fall löscht Teardown nur Stacks für Buckets, die von V1FSS als geschützt bestätigt wurden, und der Status einer Region blockiert niemals eine andere. (Nach run --execute druckt das Tool den genauen teardown … --execute-Befehl, den Sie kopieren können.)
If your C1FSS is deployed in a VPC, teardown takes noticeably longer. Das Löschen eines an eine VPC angeschlossenen Scanners (oder Speichers) Lambda wartet auf die Bereinigung der AWS-Netzwerkschnittstelle (ENI), die routinemäßig 10–40 minutes per stack läuft, im Vergleich zu einer Minute oder zwei für einen Nicht-VPC-Stack. Stacks werden parallel gelöscht (die Phase wird also durch den langsamsten, nicht die Summe begrenzt), und jedes Löschen wartet standardmäßig bis zu 1 Stunde; erhöhen Sie dies bei Bedarf mit --teardown-timeout <seconds>. Dies ist zu erwarten; lassen Sie es laufen. Siehe die Teardown-FAQ.
Wenn C1FSS mehr als eine Region umfasst, wiederholen Sie beide Befehle für jede verbleibende Region:
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
Jeder teardown fordert Sie auf, DELETE C1FSS einzugeben, um die endgültige Löschung der C1FSS-Stacks dieser Region zu bestätigen. Übergehen Sie --yes, um die Eingabeaufforderung beim nicht-interaktiven Ausführen zu überspringen.
Sobald jede Region abgebaut ist, ist das Update abgeschlossen: V1FSS scannt Ihre Buckets und C1FSS wird außer Betrieb genommen.

Was nicht aktualisiert wird

Das Tool übernimmt Einstellungen, die ein direktes V1FSS-Äquivalent haben: SSE-KMS Key ARNs, Scan-Ergebnis-Tag-Format, Scanner-Ephemerer-Speichergröße, VPC Subnets/Sicherheitsgruppen/Proxy, Ziel-Buckets für die Förderung/Quarantäne und (mit einer Warnung) eine IAM-Berechtigungsgrenze. Alles andere wird entweder mit einer expliziten onboard-Warnung verworfen oder gar nicht entdeckt. Überprüfen Sie dies, bevor Sie sich auf vollständige Parität verlassen:
  • Account-Scanner topology: nicht unterstützt. discover wird sofort abgebrochen, wenn es eines findet; aktualisieren Sie dieses Konto stattdessen mit dem manuellen Handbuch.
  • Org (CAM organizational) accounts: nicht unterstützt, auch wenn Sie C1FSS auf diesem Konto noch nicht aktualisiert haben. Ihre CAM-Connector-Stacks werden von einem StackSet aus dem Verwaltungskonto Ihrer Organisation gepusht, nicht pro Konto erstellt oder aktualisiert.
  • C1 settings with no V1 equivalent (protokolliert als "NICHT übernommen" während onboard): ReportObjectKey, ScanOnGetObject, ExclusiveBucketList, EnableCrossAccountScanning, AdditionalIAMPolicies, ObjectFilterPrefix, ObjectCreatedEventFilter. Der Objekt-Schlüssel-Präfixfilter wird niemals übernommen, selbst wenn nur ein C1-Bucket ihn setzt; das Äquivalent von V1FSS ist kontenweit, nicht pro Bucket, sodass seine Anwendung das Scannen auf jeden anderen Bucket, der den Filter unter C1 nie hatte, fälschlicherweise einschränken würde.
  • Promote/quarantine inKopierenModus: Die Suchaktion von V1FSS nach dem Scan moves nur ein gescanntes Objekt; es gibt kein Äquivalent im Kopiermodus. Wenn Ihr C1-Plugin PromoteMode/QuarantineMode = copy ausführt (das Originalobjekt bleibt im Quell-Bucket), protokolliert onboard eine WARNUNG: Nach dem Umschalten wird das Quellobjekt Gelöscht, nicht behalten. Bestätigen Sie, dass dies akzeptabel ist, bevor Sie C1 abbauen.
  • Plugin object ACLs: Das C1-Plugin wendet eine benutzerdefinierte ACL erneut auf das Objekt an, das es verschiebt; die Aktion von V1FSS tut dies nicht, daher kann eine ACL-Einstellung des Plugins nicht übernommen werden (onboard protokolliert eine WARNUNG, wenn eine gefunden wird).
  • Conflicting per-region values: Wenn zwei oder mehr C1-Stacks in derselben Region unterschiedliche VPC Subnets/Sicherheitsgruppen/Proxy oder verschiedene Regionen unterschiedliche IAM-Berechtigungsgrenzen melden, werden keine der widersprüchlichen Werte übernommen (onboard protokolliert eine WARNUNG mit Nennung der betroffenen Region(en)); setzen Sie diese anschließend manuell im Connector-Stack.
  • Conflicting scan-result tag formats: the scan-result tag format (Separated tags / Merged tag / No tag) is account-wide in V1FSS, so unlike the values above it can't simply be dropped when C1 stacks disagree. If your C1 stacks use different tag formats across regions, onboard picks the majority format, applies it account-wide, and logs a WARNING listing the formats found and the one chosen. Buckets whose C1 stack used a different format will be tagged in the chosen format after cutover, a change from their C1 behavior. Set FileSecurityStorageScanResultTagFormat on the connector stack afterward if you need a different one.
  • IAM permissions boundary: standardmäßig übernommen, aber als WARNUNG markiert: C1 und V1 verwenden unterschiedliche CFN-Ressourcen/IAM-Rollen, daher kann eine Grenze, die für C1 funktionierte, V1's Bereitstellung sperren. Übergehen Sie --skip-permission-boundary, um es auszulassen.

Fehlerbehebung & FAQ

Can I run it outside AWS CloudShell?
Ja. CloudShell wird nur empfohlen, weil es AWS-Anmeldedaten automatisch bereitstellt. Jeder Host mit Python 3, der boto3-Bibliothek, AWS-Anmeldedaten für das C1FSS-Konto (Umgebungsvariablen, ein benanntes Profil oder SSO) und export V1_API_KEY=… funktioniert genauso. SSO/SAML-Sitzungen können während des Laufs ablaufen; aktualisieren Sie sie und resume --run-id <run-id> --execute.
What if my account spans multiple regions?
run scannt standardmäßig alle aktivierten Regionen und führt jede Region gemeinsam durch Onboarding/Synchronisierung/Aktivierung. Nur verify und teardown sind pro Region (Schritt 4), sodass Sie jede Region unabhängig überprüfen und umstellen.
How do I resume an interrupted run?
Überprüfen Sie, wo es gestoppt hat, und fahren Sie dann fort; abgeschlossene Phasen werden übersprungen:
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?
Nein. Zero-Downtime ist der Standard. Das Aktivieren von V1FSS fügt eine EventBridge-Benachrichtigung neben der bestehenden Lambda-Benachrichtigung von C1FSS auf demselben Bucket hinzu; C1FSS scannt und taggt Objekte weiterhin, bis sein Stack im letzten Schritt abgebaut wird.
How do I back out (rollback)?
python3 -m v1fss_migrate rollback --run-id <run-id> --execute
Rollback reverses the V1FSS onboarding: it disables the V1 scanning it turned on (removing the EventBridge notification) and either deletes the V1 connector it created or restores it to its pre-update state. It never touches C1FSS (your C1 stacks, notifications, and promote/quarantine plugin stay intact throughout), so rollback simply returns you to "C1FSS only." It's only meaningful before teardown (deleting C1 stacks is irreversible), and it deliberately won't disable V1 in a region where teardown has already started (that would leave those buckets with neither C1 nor V1).
Do I have to runüberprüfen?
Nein. Es ist optional. Teardown löscht nur die C1FSS-Stacks einer Region, sobald V1FSS bestätigt hat, dass seine Buckets geschützt sind, sodass der Übergang auch ohne sicher ist. verify ist ein zusätzlicher End-to-End-Nachweis: Es lädt ein sauberes und ein EICAR-Objekt in einen Bucket hoch, der nicht unter C1FSS steht, in der zu überprüfenden Region, und überprüft die Scan-Tags. Wenn Sie es überspringen, wird teardown trotzdem fortgesetzt, protokolliert jedoch, dass die Region ohne diesen Nachweis stillgelegt wird. Ein Verify, das ausgeführt wird und fehlschlägt, blockiert jedoch das Teardown dieser Region. Wenn Verify sein Testobjekt nicht hochladen kann (Object Lock, eine restriktive Bucket-Richtlinie oder ein erforderlicher KMS Key, den der Anrufer nicht verwenden kann), wird dies gemeldet und übersprungen: Bestätigen Sie das Scannen manuell in der V1-Konsole oder wählen Sie einen anderen Verify-Bucket. (EICAR ist der standardmäßige Anti-Malware-Teststring, keine echte Malware.)
What happens to my promote/quarantine rules?
onboard liest Ihre C1FSS Promote/Quarantäne-Plugin-Konfiguration und ordnet sie den entsprechenden V1FSS-Aktionsparametern zu, sodass Buckets nach dem Wechsel das gleiche Bereinigungs-/Quarantäneverhalten beibehalten. (Kopiermodus und Objekt-ACLs sind Ausnahmen: siehe "Was nicht aktualisiert wird.")
How long does teardown take, and can a slow stack fail it?
Normalerweise dauert es ein paar Minuten pro Stack, aber wenn Ihr C1FSS in einer VPC bereitgestellt ist, erwarten Sie, dass es viel länger dauert. Das Löschen eines an eine VPC angeschlossenen Scanners (oder Speichers) Lambda wird von der AWS-Netzwerkschnittstellenbereinigung (ENI) dominiert, die routinemäßig 10–40 Minuten pro Stack dauert. Der Abbau löscht Stacks parallel (zuerst Speicher-/Plugin-Stacks, dann Scanner), sodass die Phase durch den einzelnen langsamsten Stack begrenzt wird und nicht durch die Summe, und jedes Löschen wartet standardmäßig bis zu 1 Stunde; erhöhen Sie es mit --teardown-timeout <seconds> für einen ungewöhnlich langsamen Stack. Ein Stack, der immer noch nicht fertig wird, wird gemeldet und die Phase stoppt mit den anderen, die bereits abgebaut wurden; führen Sie denselben teardown-Befehl erneut aus, um nur diesen einen zu wiederholen.
What happens to my Scanner stacks at teardown?
Ein Scanner, der in einem All-in-One-Stack gebündelt ist, wird durch das Kaskadenlöschen des übergeordneten Stacks entfernt. Ein eigenständiger Scanner-Stack (getrennte Speicher- und Scanner-Topologie) ist eine geteilte Infrastruktur (ein Scanner kann mehrere Speicher-Stacks bedienen), daher löscht das Tool ihn automatisch nur, wenn es nachweisen kann, dass nichts anderes ihn benötigt: Jeder Speicher-Stack, der darauf verweist (abgeglichen auf ScannerSQSURL → die ScannerQueueURL des Scanners), wird in diesem Durchlauf abgebaut, die Erkennung hat Ihr gesamtes Konto abgedeckt (keine --regions), und die SQS Queue-Richtlinie des Scanners gewährt keinen anderen AWS-Konten Zugriff. Wenn dies nicht bestätigt werden kann (insbesondere ein kontenübergreifender/zentraler Scanner, der Speicher-Stacks bedient, die dieser Durchlauf nicht sehen kann), lässt das Tool den Scanner-Stack bestehen und protokolliert eine NOTIZ, die genau erklärt, warum (unter Nennung der anderen Konto-IDs im kontenübergreifenden Fall), damit Sie ihn manuell löschen können, sobald Sie bestätigt haben, dass nichts anderes ihn verwendet.
Can I run individual phases?
Ja. preflight, discover, onboard, sync, enable und verify laufen jeweils eigenständig (mit denselben Flags wie run), wenn Sie das Update manuell durchführen möchten.