Avviso di fine del supporto: il 30 giugno 2027, AWS terminerà il supporto per AMS Advanced. Dopo il 30 giugno 2027, non sarà più possibile accedere alla console AMS Advanced o alle risorse AMS Advanced. Per ulteriori informazioni, vedere Fine del supporto per AMS Advanced.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Fuori bordo dagli account AMS con più account sulla zona di atterraggio
Esistono due tipi di AWS account che puoi rimuovere dalla zona di destinazione multiaccount di AMS Advanced:
-
Account delle applicazioni
-
Account principali
Per eliminare tutti gli account dalla zona di Multi-account atterraggio AMS, è necessario eliminare tutti gli account dell'Applicazione prima di eliminare gli account Core.
Per gestire e continuare a gestire i carichi di lavoro negli account Application o Core esterni, assicuratevi di consultare questa documentazione con il team del vostro account AMS. Questa documentazione illustra le modifiche apportate da AMS durante il processo offboard.
Attività da completare per continuare a gestire gli account offboard
Le seguenti attività sono necessarie per continuare a gestire gli account trasferiti dalla zona di atterraggio multiaccount di AMS:
Attiva la modalità sviluppatore: per ottenere maggiori autorizzazioni per i tuoi account, attiva la modalità sviluppatore prima di rimuovere gli account dell'applicazione da AMS. Attivando la modalità Sviluppatore, è possibile apportare più facilmente le modifiche necessarie per prepararsi all'offboarding. Non tentare di rimuovere o modificare le risorse dell'infrastruttura AMS. Se elimini le risorse di infrastruttura AMS, AMS potrebbe non essere in grado di eliminare correttamente il tuo account. Per informazioni su come abilitare la modalità sviluppatore, consultaGuida introduttiva alla modalità AMS Advanced Developer.
Se non riesci a completare le modifiche necessarie per prepararti all'offboarding dopo aver attivato la modalità sviluppatore, contatta il team del tuo account AMS per discutere dei tuoi requisiti.
Scegli un metodo alternativo per l'accesso allo stack EC2: dopo aver rimosso gli account Application da AMS, non puoi utilizzare le RFC per accedere alle risorse dello stack. EsaminaModifiche all'offboarding, quindi scegli un metodo di accesso alternativo in modo da mantenere l'accesso ai tuoi stack. Per ulteriori informazioni, consulta Alternative di accesso.
Account offboard dell'applicazione AMS
Per eliminare gli account Application dal tuo ambiente di destinazione con più account, completa i seguenti passaggi per ogni account:
Verifica che non vi siano RFC aperte nell'account. Per ulteriori informazioni, consulta Crea, clona, aggiorna, trova e annulla RFCs.
Verifica di poter accedere all'indirizzo email dell'utente principale o root dell'account.
Dall'account Application, invia una RFC indicando il tipo di modifica Application Account | Confirm offboarding (ct-2wlfo2jxj2rkj). Nella RFC, specificate l'account Application su offboard.
Dall'account di gestione, invia una RFC con il tipo di modifica dell'account di gestione | Offboard Application Account (ct-0vdiy51oyrhhm). Nella RFC, specificate l'account Application su offboard. Inoltre, indica se desideri eliminare o mantenere l'allegato del gateway di transito alla zona di atterraggio.
Per assicurarti che la fatturazione con AMS venga interrotta, comunica al CSDM che hai effettuato l'offboard dell'account.
Dopo l'annullamento dell'account dell'Applicazione si verifica quanto segue:
Tutti i componenti sono dissociati dai servizi AMS, ma le risorse create rimangono nell'account. Puoi scegliere di mantenere o chiudere l'account AMS offboard.
Gli account principali e gli altri account dell'Applicazione rimanenti funzionano normalmente dopo l'offboard di un account dell'Applicazione.
La fatturazione AMS viene interrotta, ma la AWS fatturazione non viene interrotta finché non chiudi l'account. Per ulteriori informazioni, consulta Cosa devi sapere prima di chiudere l'account.
Se un account viene chiuso, l'account è visibile nella tua organizzazione nello
suspendedstato per 90 giorni. Dopo 90 giorni, l'account chiuso viene rimosso definitivamente e non è più visibile nell'organizzazione.Dopo la chiusura dell'account, puoi comunque accedere e presentare una richiesta o contattare l'assistenza Supporto per 90 giorni.
Dopo 90 giorni, tutti i contenuti rimasti nell'account vengono eliminati definitivamente e i AWS servizi rimanenti vengono interrotti.
- D: Posso utilizzare i miei ruoli IAM federati per continuare ad accedere a un account dell'Applicazione che ho trasferito dalla mia zona di destinazione con più account AMS?
Sì. I ruoli predefiniti AWS Identity and Access Management (IAM) creati da AMS rimangono disponibili nell'account dopo l'offboarding di AMS. Tuttavia, questi ruoli e policy sono progettati per essere utilizzati con la gestione degli accessi AMS. Per fornire l'accesso necessario agli utenti, potrebbe essere necessario distribuire le proprie risorse IAM.
- D: Come posso ottenere l'accesso completo a un account dell'Applicazione che ho decollato dalla mia zona di atterraggio con più account AMS?
Gli account Offboarding Application vengono spostati nell'unità organizzativa (OU) obsoleta nella struttura degli account. AWS Organizations Questa mossa elimina le restrizioni di accesso SCP che in precedenza bloccavano l'accesso degli utenti root. Per informazioni su come reimpostare le credenziali dell'utente root, vedi Reimpostazione di una password utente root persa o dimenticata.
- D: Quali modifiche vengono apportate durante l'offboarding dell'account dell'Applicazione?
Per informazioni sulle azioni intraprese da AMS quando il servizio disconnette gli account, vedereModifiche all'offboarding.
- D: Posso disconnettere un account dell'Applicazione senza scollegarlo dal gateway di transito?
Sì. Utilizza il tipo di modifica dell'account di gestione | Offboard Application Account (ct-0vdiy51oyrhhm) per inviare la RFC e specificare il parametro come.
DeleteTransitGatewayAttachmentFalse- D: Quanto tempo è necessario per disattivare un account Application?
Quando si utilizza il tipo di modifica dell'account di gestione | Offboard Application Account (ct-0vdiy51oyrhhm), le RFC vengono completate entro 1 ora.
- D: È obbligatorio chiudere l'account offboard?
No. La chiusura dell'account dopo l'offboarding da AMS non è obbligatoria. Durante il processo di offboarding, AMS rimuove l'accesso e la gestione del tuo AWS account, ma il tuo account e le tue risorse all'interno dell'account rimangono invariati. È importante notare che dopo l'offboarding da AMS, l'utente è l'unico responsabile della gestione e della manutenzione dell' AWS account e delle risorse. AMS non è responsabile per eventuali problemi, incidenti o interruzioni del servizio che potrebbero verificarsi nel tuo account dopo il completamento del processo di offboarding. Per ulteriori informazioni, vedi Come posso chiudere il mio account? AWS
. - D: Se invio una richiesta di chiusura dell'account, tutte le risorse esistenti vengono eliminate immediatamente?
No. La chiusura dell'account non comporta l'interruzione delle risorse. Le risorse dell'account terminano automaticamente 90 giorni dopo la richiesta di chiusura. La fatturazione con AMS si interrompe, ma la fatturazione AWS delle risorse non si interrompe finché non chiudi l'account. Per ulteriori informazioni, consulta Cosa devi sapere prima di chiudere l'account.
- D: Posso programmare lo sblocco di un account Application?
Sì. È possibile pianificare l'esecuzione delle RFC in un momento specifico. Tuttavia, l'Application Account | Confirm offboarding RFC deve essere completato prima di poter pianificare l'Application Account | Offboard Application Account RFC. Per ulteriori informazioni, vedere Pianificazione RFC. https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-scheduling.html
-
R: Parte responsabile. La parte responsabile del completamento dell'attività elencata.
-
A: Parte responsabile. La parte che approva l'attività completata.
-
C: Parte consultata. Parte la cui opinione è richiesta, in genere in qualità di esperti in materia, e con la quale esiste una comunicazione bilaterale.
-
I: Parte informata. Parte informata sullo stato di avanzamento, spesso solo sul completamento dell'attività o del risultato finale.
| Attività | Cliente | Servizi gestiti AWS (AMS) |
|---|---|---|
| Prerequisiti | ||
| Verifica l'accesso all'indirizzo email principale per ogni ID di AWS account che verrà trasferito | R | C |
| Consulta la documentazione di AMS sulle azioni consigliate ai clienti e prepara gli account per l'offboarding con AMS | R | C |
| Se necessario, invia una RFC per attivare la modalità Sviluppatore e preparare gli account per l'offboarding con AMS | R | I |
| Se necessario, scegli un metodo alternativo per l'accesso allo stack EC2. | R | I |
| Offboarding | ||
| Invia le RFC per confermare e richiedere lo sblocco degli account dell'Applicazione | R | I |
| Estrarre i componenti AMS dagli account delle applicazioni | I | R |
| Notifica ad AMS CSDM gli account non utilizzati per interrompere la fatturazione con AMS | R | I |
| Post-offboarding | ||
| Reimposta la password dell'account utente root e verifica l'accesso root negli account offboard | R | C |
| Chiudi l'account o segui le indicazioni di AMS sulle azioni consigliate ai clienti nella documentazione di offboarding di AMS per continuare a gestire gli account | R | C |
Account Offboard Core
Per eliminare gli account Core con più account nella zona di destinazione, completa i seguenti passaggi:
Verifica che tutti gli account Application nella zona di atterraggio siano stati allontanati da AMS.
Verificate di non avere RFC aperti negli account. Per ulteriori informazioni, consulta Crea, clona, aggiorna, trova e annulla RFCs.
Verifica di poter accedere all'indirizzo email dell'utente principale o root per tutti gli account Core. Per ulteriori informazioni, consulta Account Multi-Account Landing Zone.
Verifica di poter accedere al numero di telefono dell'utente principale o root per l'account di gestione. Usa il ruolo
AWSManagedServicesBillingRoleIAM per aggiornare il numero di telefono. Per maggiori informazioni, vedi Come posso aggiornare il mio numero di telefono associato al mio AWS account?. Accedi al tuo account di gestione della zona di atterraggio AMS e invia una richiesta di assistenza AMS. Nella richiesta di servizio, specifica di lasciare l'intera zona di atterraggio.
Dopo l'eliminazione degli account Core si verifica quanto segue:
-
Tutti i componenti sono dissociati dai servizi AMS, ma alcune AWS risorse rimangono nell'account. Puoi scegliere di mantenere o chiudere gli account Core off-board di AMS.
-
La fatturazione AMS viene interrotta, ma la AWS fatturazione non viene interrotta finché non chiudi l'account. Per ulteriori informazioni, consulta Cosa devi sapere prima di chiudere l'account.
-
Se un account viene chiuso, l'account è visibile nella tua organizzazione nello
suspendedstato per 90 giorni. Dopo 90 giorni, l'account membro chiuso viene rimosso definitivamente e non è più visibile nell'organizzazione. -
Dopo la chiusura dell'account, puoi comunque accedere e presentare una richiesta o contattare l'assistenza Supporto per 90 giorni.
-
Dopo la chiusura dell'account per 90 giorni, tutti i contenuti rimasti nell'account vengono eliminati definitivamente e i AWS servizi rimanenti vengono interrotti.
- D: Posso utilizzare i miei ruoli IAM federati per continuare ad accedere agli account Core non utilizzati?
Sì. I ruoli predefiniti AWS Identity and Access Management (IAM) creati da AMS rimangono disponibili nell'account offboard. Tuttavia, questi ruoli e policy sono progettati per essere utilizzati con la gestione degli accessi AMS. Per fornire l'accesso necessario agli utenti, potrebbe essere necessario distribuire le proprie risorse IAM.
- D: Come posso ottenere l'accesso completo all'account Management, Shared Services, Networking o ad altri account MALZ non applicativi dopo l'offboarding dalla zona di atterraggio con più account AMS?
Dopo l'offboarding, segui le istruzioni in Reimpostazione di una password utente root persa o dimenticata per utilizzare le credenziali dell'utente primario (root) per accedere agli account Core diversi dall'account di gestione. A differenza di altri tipi di account, l'account di gestione mantiene un dispositivo di autenticazione a più fattori (MFA) inaccessibile associato all'utente root per impedirne l'utilizzo. Per riottenere l'accesso root è necessario seguire la procedura di ripristino del dispositivo MFA smarrito.
- D: Quali modifiche vengono apportate durante l'offboarding dell'account Core?
Per informazioni sulle azioni intraprese da AMS quando il servizio disconnette gli account, vedereModifiche all'offboarding.
- D: Quanto tempo occorre per completare l'offboarding dell'account Core?
Il completamento del processo di offboarding dell'account Core richiede in genere fino a 30 giorni. Tuttavia, per assicurarti che tutti i passaggi richiesti siano completati correttamente, devi avviare la richiesta di offboarding almeno 7 giorni prima dell'inizio dell'offboarding. Per facilitare una transizione facile, pianifica in anticipo e invia la richiesta di offboarding in anticipo.
- D: Come posso gestire i componenti condivisi dopo l'offboarding con AMS?
AMS Managed Active Directory e altri componenti dell'infrastruttura di servizi condivisi sono progettati per l'accesso degli operatori AMS. Potrebbe essere necessario aggiornare i gruppi di sicurezza di Amazon Elastic Compute Cloud (Amazon EC2), la policy di controllo dei AWS Organizations servizi (SCP) o apportare altre modifiche per mantenere l'accesso completo a questi componenti.
- D: Posso chiudere gli account Core non utilizzati?
Per impostazione predefinita, gli account dell'applicazione hanno più dipendenze dagli account MALZ Core, come l' AWS Organizations appartenenza, la connettività di rete del gateway di transito e la risoluzione DNS tramite AMS Managed Active Directory. Dopo aver risolto queste dipendenze, è possibile disattivare e chiudere l'account Core non utilizzato. Per ulteriori informazioni, consulta Account Multi-Account Landing Zone.
-
R: Parte responsabile. La parte responsabile del completamento dell'attività elencata.
-
A: Parte responsabile. La parte che approva l'attività completata.
-
C: Parte consultata. Parte la cui opinione è richiesta, in genere in qualità di esperti in materia, e con la quale esiste una comunicazione bilaterale.
-
I: Parte informata. Una parte informata sui progressi, spesso solo sul completamento dell'attività o del risultato finale.
| Attività | Cliente | Servizi gestiti AWS (AMS) |
|---|---|---|
| Prerequisiti | ||
| Verifica l'accesso all'indirizzo email principale per ogni ID account AWS che verrà trasferito | R | C |
| Verifica l'accesso e aggiorna il numero di telefono dell'utente root per l'account di gestione | R | C |
| Consulta la documentazione AMS sulle azioni consigliate ai clienti e prepara gli account per l'offboarding con AMS | R | C |
| Offboarding | ||
| Invia una richiesta di servizio per richiedere lo sbarco dalla zona di atterraggio | R | I |
| Estrarre i componenti AMS dagli account Core | I | R |
| Post-offboarding | ||
| Reimposta la password dell'account utente root e verifica l'accesso root negli account esterni | R | C |
| Chiudi gli account o segui le indicazioni di AMS sulle azioni consigliate ai clienti nella documentazione di offboarding di AMS per continuare a gestire gli account | R | C |
Modifiche all'offboarding
La tabella seguente descrive le azioni intraprese da AMS per l'offboarding dalla zona di atterraggio con più account, i potenziali impatti e le azioni consigliate.
| Componente | Tipo di account | Azioni intraprese per uscire dalla nave | Potenziali impatti | Azioni consigliate per il cliente |
|---|---|---|---|---|
| Gestione degli accessi | Account delle applicazioni |
Dopo l'offboarding, le RFC di accesso agli stack per l'accesso just-in-time e limitato nel tempo non possono più essere inviate per accedere agli stack EC2 tramite gli host bastion di AMS AMS non gestisce più i componenti relativi all'accesso su nessuno stack di risorse EC2 esistente (agente PBIS Open, script di aggiunta al dominio) |
Non è possibile utilizzare i bastioni AMS tramite RFS per accedere alle istanze EC2 Le istanze EC2 avviate da AMI non fornite da AMS non vengono aggiunte al dominio Managed Active Directory Se non vengono rimossi, gli script di avvio di AMS negli stack di risorse esistenti potrebbero generare errori a causa della mancanza di dipendenze AMS e impedire la riconnessione a un dominio diverso |
Usa metodi alternativi per accedere all'istanza EC2 (vedi) Alternative di accesso Rimuovi gli script di avvio AMS dagli stack di risorse EC2 esistenti (vedi) Disabilita gli script di avvio di AMS EC2 |
| Gestione degli accessi (seguito) | Account principali | Se hai effettuato la migrazione da PBIS Open a PBIS Enterprise (AD Bridge), AMS non rinnova più le licenze dopo l'offboarding dell'account principale | Se la licenza PBIS Enterprise può scadere, le credenziali di Active Directory non sono valide per gli stack di istanze EC2 esistenti Linux-based | Se hai eseguito la migrazione a PBIS Enterprise (AD Bridge), decidi se mantenere la licenza o rimuoverla (vedi) PBIS Open/Enterprise (AD Bridge) |
| Registrazione, monitoraggio e gestione Incident/Event | Account applicativi e principali |
I componenti AMS da implementare Avvisi dal monitoraggio di base in AMS vengono rimossi Gli CloudWatch allarmi Amazon distribuiti esistenti rimangono ma non creano più incidenti AMS AWS Config le autorizzazioni di aggregazione di AMS e dell'account di sicurezza MALZ Core vengono rimosse AWS Config le regole rimangono implementate e Amazon GuardDuty rimane abilitato, ma non crea più incidenti AMS |
Alle risorse appena create non sono applicati il monitoraggio di base AMS e gli allarmi Gli allarmi metrici dell'infrastruttura e gli eventi di sicurezza non generano più incidenti AMS AWS Config non è più aggregato in un conto centrale |
Definisci, acquisisci e analizza le metriche operative per visualizzare gli eventi del carico di lavoro e intraprendere le azioni appropriate. Implementa qualsiasi flusso di lavoro di allerta richiesto per continuare ad applicare il monitoraggio operativo e gli allarmi richiesti sulle nuove risorse e per ricevere avvisi di sicurezza da e Amazon. AWS Config GuardDuty |
| Gestione della continuità (backup e ripristino) | Account delle applicazioni |
AMS non monitora più i processi di backup né esegue richieste di backup e ripristino Gli archivi di backup predefiniti di AMS, la chiave di crittografia del backup e il ruolo di backup rimangono |
Gli errori delle operazioni di backup potrebbero non essere notati | Monitora e rivedi le configurazioni del piano di backup |
| Gestione delle patch | Account applicativi e principali |
AMS non monitora più le operazioni di patching per verificarne la corretta esecuzione né esegue l'applicazione manuale delle patch AMS non aggiorna più i componenti dell'infrastruttura AMS Le baseline delle patch fornite da AMS vengono mantenute I runbook di automazione AWS Systems Manager delle patch forniti da AMS non sono condivisi e non sono più disponibili per l'uso |
Gli errori delle operazioni di patching potrebbero non essere notati Le configurazioni di patch esistenti che dipendono dai runbook di Systems Manager Automation forniti da AMS devono essere riconfigurate per continuare senza interruzioni |
Rivedi e riconfigura le configurazioni di patching secondo necessità |
| Gestione di rete | Account delle applicazioni | Se specificato, l'allegato del gateway di transito nell'account dell'Applicazione disconnesso viene rimosso | L'account Offboarding Application non può più utilizzare un gateway di transito per accedere a servizi condivisi, come Managed Active Directory o altri account dell'Applicazione | Specifica DeleteTransitGatewayAttachment come False mantenere la connettività del gateway di transito |
| Gestione della sicurezza | Account delle applicazioni |
L'account è scollegato dalla console centrale di Trend Micro DSM. Inoltre, gli agenti endpoint non inoltrano più avvisi tramite il processo di gestione degli incidenti AMS Gli agenti Trend Micro rimangono installati ma non sono più gestiti o aggiornati da AMS Le personalizzazioni AMI fornite da AMS che utilizzano l'agente Trend Micro non vengono più gestite o aggiornate da AMS |
I rilevamenti di malware sugli endpoint delle istanze EC2 potrebbero non essere notati L'agente Trend micro non viene distribuito su istanze EC2 avviate da AMI non fornite da AMS |
Prendi in considerazione le opzioni per continuare o interrompere Trend Micro (vedi) Trend Micro Deep Security |
| Gestione della sicurezza (seguito) | Account principali |
L'infrastruttura Trend Micro DSM viene lasciata attiva negli account Shared Services ma non è più gestita o aggiornata da AMS Trend Micro DSM non inoltra più avvisi tramite il processo di gestione degli incidenti AMS |
I rilevamenti di malware sugli endpoint delle istanze EC2 potrebbero passare inosservati La protezione degli endpoint delle istanze EC2 potrebbe essere compromessa se l'infrastruttura non viene mantenuta (aggiornamenti delle definizioni, licenze e così via) |
Decidi se continuare o interrompere Trend Micro (vedi (vedi) Trend Micro Deep Security |
| Gestione delle modifiche | Account applicativi e principali |
La console e l'API RFC AMS sono state rimosse Le policy di controllo dei servizi personalizzate (SCP) di AMS che contengono restrizioni di accesso a livello di account vengono rimosse durante l'offboarding dell'account dell'Applicazione ed eliminate durante l'offboarding dell'account principale |
È necessario utilizzare un' AWS API nativa per creare nuove risorse, modificare le risorse esistenti o aggiornare gli stack esistenti CloudFormation Le restrizioni di accesso non vengono più imposte a livello di account tramite SCP forniti da AMS |
Assicuratevi che i ruoli utente forniscano un accesso sufficiente per utilizzare i servizi AWS Crea SCP per fornire restrizioni di autorizzazione a livello di account |
| Immagini e automazioni del sistema operativo AMS per la gestione dei servizi | Account applicativi e principali |
AMS non fornisce più supporto per le personalizzazioni e gli script di avvio inclusi nelle AMI EC2 fornite da AMS Le AMI EC2 fornite da AMS rimangono disponibili negli account offboard I runbook di Systems Manager Automation forniti da AMS non sono condivisi e non sono più disponibili per l'uso |
Dopo l'offboarding, le AMI fornite da AMS sono state avviate con CloudFormation send cfn-signal a I processi operativi che dipendono dai runbook di Systems Manager Automation forniti da AMS potrebbero fallire |
Rivedi e aggiorna qualsiasi build o processo operativo che dipende dalle AMI o dai runbook di Systems Manager Automation forniti da AMS |
| Infrastruttura di servizi condivisi | Account principali | L'accesso AMS viene rimosso e AMS non gestisce più i componenti condivisi, incluso AMS Managed Active Directory AWS Transit Gateway, e AWS Organizations | Perdita di gestione sull'infrastruttura condivisa | Reimposta l'accesso amministratore ad AMS Managed Active Directory e assumi la gestione dei componenti dei servizi condivisi |
| Creazione di report | Account applicativi e principali | AMS non raccoglie più dettagli a livello di account o di risorsa per la rendicontazione aggregata | Perdita di informazioni sulle metriche operative e aziendali (copertura dei backup e delle patch, gestione delle modifiche e attività degli incidenti) | Sostituisci qualsiasi rendicontazione dei dati aggregati necessaria tra gli account con una soluzione propria |
| Account team e service desk AMS | Account applicativi e principali | L'account team di AMS (CSDM, CA) e il service desk operativo AMS non supportano più gli account offboard | Perdita del supporto operativo grazie all'esperienza nell'architettura delle zone di atterraggio multi-account progettata da AMS e nei relativi componenti | Assicuratevi che vi sia personale sufficiente e che vi sia dimestichezza con la struttura e le risorse degli account per supportare le operazioni nell'ambiente |
Alternative di accesso
Di seguito sono riportati metodi alternativi per mantenere l'accesso allo stack EC2 dopo aver eliminato gli account AMS:
Utilizzate Session Manager per accedere alle istanze EC2 con autorizzazioni elevate senza richiedere bastioni o accesso alla rete in entrata. Per ulteriori informazioni, consulta AWS Systems Manager Session Manager.
Unisci nuovamente le istanze EC2 a un dominio Active Directory diverso con nuove credenziali di dominio. Se lo usi Servizio di directory, vedi Aggiungere un'istanza EC2 alla tua directory. AWS Managed Microsoft AD
Usa gli account utente locali che hai creato tramite uno degli altri metodi di accesso o tramite AWS Systems Manager Run Command.
Disabilita gli script di avvio di AMS EC2
Sistemi operativi Linux
Usa il gestore di pacchetti della tua distribuzione per disinstallare il ams-modules pacchetto. Ad esempio, per l'utilizzo di Amazon Linux 2yum remove ams-modules.
Sistemi operativi Windows
Per disattivare gli script di avvio EC2 in Windows, completa i seguenti passaggi:
Windows 2008/2012 Server//20192012r2/2016:
Disabilita o rimuovi l'attività pianificata di avvio di Managed Services da Task Scheduler. Per elencare le attività pianificate, esegui il
Get-ScheduledTask -TaskName '*Ec2*'comando.Windows Server 2022:
Rimuovi l'attività EC2Launch v2. Questa attività viene eseguita
Initialize-AMSBootinpostReadyfase C:\\ Amazon\ EC2LaunchProgramData\ config\ agent-config.yml sull'istanza. Quanto segue è un frammento di un esempio:agent-config.yml{ "task": "executeScript", "inputs": [ { "frequency": "always", "type": "powershell", "runAs": "localSystem" } ] }(Facoltativo) Rimuovi il seguente contenuto del file:
C:\Program Files\WindowsPowerShell\Modules\AWSManagedServices.* C:\Windows\System32\WindowsPowerShell\v1.0\Modules\AWSManagedServices.Build.Utilities\*
PBIS Open/Enterprise (AD Bridge)
Per determinare se si utilizza l'edizione PBIS Open o PBIS Enterprise (AD Bridge), esegui il comando seguente in un'istanza gestita da Linux EC2:
yum info | grep pbis
Di seguito è riportato un esempio di output che mostra PBIS Enterprise (AD Bridge):
Name : pbis-enterprise From repo : pbise Name : pbis-enterprise-devel Repo : pbise Description : The pbis-enterprise-devel package includes the development
PBIS Open
PBIS Open è un prodotto obsoleto che BeyondTrust non supporta più.
AD Bridge (PBIS Enterprise)
Puoi effettuare una delle seguenti operazioni:
Rinnova le licenze e continua a utilizzare AD Bridge. Contattaci BeyondTrust per discutere di licenze e supporto.
Interrompi l'uso di AD Bridge. Esegui il seguente comando Shell per rimuovere il PBIS-Enterprise pacchetto dalle istanze gestite da Linux. Per ulteriori informazioni, consulta la BeyondTrust documentazione Leave a Domain and Uninstall the AD Bridge Agent
. $ sudo /opt/pbis/bin/uninstall.sh purge
Lasciare il dominio Active Directory gestito da AMS senza rimuovere l'agente PBIS
È possibile lasciare l'Active Directory gestito da AMS senza rimuovere l'agente PBIS. Utilizzate una delle seguenti soluzioni, a seconda del sistema operativo in uso:
Trend Micro Deep Security
Utilizza una delle seguenti opzioni per continuare o interrompere l'uso di Trend Micro Deep Security:
Continua l'utilizzo
Ricollegare gli account dell'applicazione non collegati a una nuova installazione Trend Micro DSM. Per ulteriori informazioni, vedere Attivazione e protezione degli agenti
e Attivazione dell'agente . Ricollega gli account delle applicazioni non collegati a Trend Micro Cloud One. Per ulteriori informazioni, consulta Migrare da Deep Security a Workload Security
e Migrare da un DSM locale.
Interrompi l'utilizzo
Disinstallare Trend Micro Deep Security Agents dagli account delle applicazioni non integrati. Per ulteriori informazioni, consulta Disinstallare Deep Security
.