Controlli standard in AMS Advanced - Guida per l'utente avanzato di AMS

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à.

Controlli standard in AMS Advanced

I seguenti sono i controlli standard di AMS:

Di seguito è riportato il controllo standard per 001 - Tagging Configuration.

  1. Tutte le AWS risorse richieste dal team AMS per scopi operativi e gestionali devono avere la seguente coppia chiave-valore.

    • AppId= AMSInfrastructure

    • Ambiente= AMSInfrastructure

    • AppName = AMSInfrastructure

    • AMSResource=Vero

  2. Tutti i tag richiesti dal team AMS diversi da quelli elencati in precedenza devono avere i prefissi indicati nell'elenco dei prefissi AMS (vedi Nota).

  3. I valori dei tag richiesti dal team AMS (AppId, Environment and AppName) possono essere modificati su qualsiasi risorsa creata dall'utente in base alle richieste di modifica.

  4. Qualsiasi tag sugli stack richiesto da AMS non deve essere eliminato in base alle richieste di modifica.

  5. Non è possibile utilizzare la convenzione di denominazione dei tag AMS per la propria infrastruttura, come indicato al punto 2.

  6. È possibile creare tag personalizzati nelle risorse richieste da AMS (in genere per casi di utilizzo relativi alla fatturazione e alla rendicontazione dei costi). I tag personalizzati vengono mantenuti se le risorse vengono aggiornate tramite l'aggiornamento dello stack e non mediante l'aggiornamento del modello.

Nota

Elenco dei prefissi AMS

  1. ams-*

  2. AWSManagedServizi*

  3. /ams/ *

  4. ams*

  5. MASSA*

  6. Nome*

  7. cm*

  8. MC*

  9. Mc*

  10. sentinella*

  11. Sentinella*

  12. Servizi gestiti*

  13. Nuovo AMS*

  14. AWS_*

  15. aws*

  16. VPC_*

  17. CloudTrail*

  18. Sentiero nuvoloso*

  19. /aws_riservato/

  20. INGERI*

  21. EPSDB*

  22. MMS*

  23. TemplateId*

  24. StackSet-ams*

  25. StackSet-AWS - Zona di atterraggio

  26. IAMPolicy*

  27. cliente-mc-*

  28. Radice*

  29. LandingZone*

  30. StateMachine*

  31. codedeploy_service_role

  32. host di gestione

  33. sentinel.int.

  34. EPS

  35. UnhealthyInServiceBastion

  36. ms-

ID Standard tecnico
1.0 Durata del timeout
1.1 Una sessione di timeout predefinita per utenti federati è di un'ora e può essere aumentata fino a quattro ore.
1.2 Il tempo di accesso allo stack predefinito è di 12 ore.
2.0 AWS Utilizzo dell'account root
2.1 Se viene utilizzato un account root per qualsiasi motivo, Amazon GuardDuty deve essere configurato per generare risultati pertinenti.
2.2 Per gli account single-account landing zone (SALZ) e gli account di gestione multi-account landing zone (MALZ) (precedentemente noto come account), l' Master/Billing account utente Root deve avere l'MFA virtuale abilitata e il soft token MFA viene scartato durante l'onboarding dell'account, in modo che né AMS né i clienti possano accedere come root. La procedura standard di perdita della password AWS root deve essere seguita insieme a AMS Cloud Service Delivery Manager (CSDM). Questa configurazione deve rimanere valida durante il ciclo di vita degli account gestiti da AMS.
2.3 Non è necessario creare chiavi di accesso per l'account root.
3.0 Creazione e modifica degli utenti
3.1 È possibile creare IAM users/roles con accesso programmatico e con autorizzazioni di sola lettura senza alcuna politica limitata nel tempo. Tuttavia, l'autorizzazione a consentire la lettura di oggetti (ad esempio, S3:GetObject) in tutti i bucket Amazon Simple Storage Service dell'account non è consentita.
3.1.1 Gli utenti umani IAM per l'accesso alla console e con autorizzazioni di sola lettura possono essere creati con la politica limitata nel tempo (fino a 180 giorni), mentre la removal/renewal/extension politica limitata nel tempo comporterà la notifica del rischio. Tuttavia, l'autorizzazione a consentire la lettura di oggetti (ad esempio, S3:GetObject) in tutti i bucket S3 dell'account non è consentita.
3.2 Gli utenti e i ruoli IAM per l'accesso da console e programmatico con autorizzazioni che modificano l'infrastruttura (scrittura e gestione delle autorizzazioni) nell'account del cliente non devono essere creati senza l'accettazione del rischio. Esistono eccezioni per le autorizzazioni di scrittura a livello di oggetto S3, consentite senza l'accettazione del rischio, purché i bucket specifici rientrino nell'ambito di applicazione e per le operazioni di etichettatura su tag non correlati ad AMS.
3.3 Gli utenti IAM con accesso programmatico, denominati customer_servicenow_user e customer_servicenow_logging_user necessari per ServiceNow l'integrazione nell'account dell'applicazione SALZ o MALZ e negli *account principali* possono essere creati senza alcuna politica limitata nel tempo.
3.4 È possibile creare utenti IAM con accesso programmatico, utilizzo customer_cloud_endure_policy e customer_cloud_endure_deny_policy (con accesso in sola lettura) necessari per l' CloudEndure integrazione negli account SALZ e MALZ, ma necessitano di una policy limitata nel tempo per il periodo della migrazione pianificata. Il limite di tempo può essere di un periodo massimo di 180 giorni senza RA. L'SCP è inoltre autorizzato a modificare gli account MALZ per consentire a queste politiche di funzionare per il periodo richiesto. È possibile definire le finestre di migrazione appropriate per le proprie esigenze e modificarle in base alle esigenze.
4.0 Politiche, azioni e APIs
4.1 Tutti gli utenti e i ruoli IAM negli account SALZ devono avere la Customer Deny Policy (CDP) predefinita allegata per proteggere l'infrastruttura AMS da danni accidentali o intenzionali.
4.2 AMS SCPs deve essere abilitato in tutti gli account gestiti da AMS in MALZ.
4.3 Le identità in grado di eseguire azioni amministrative sulle chiavi KMS, ad esempio, e PutKeyPolicyScheduleKeyDeletion, devono essere limitate solo agli operatori AMS e ai responsabili di automazione.
4.4 Una policy non deve fornire all'amministratore un'istruzione equivalente a «Effect»: «Allow» con «Action»: «*» su «Resource»: «*» senza l'accettazione del rischio.
4.5 La policy IAM non deve includere alcuna azione che includa l'azione Allow S3: *** su qualsiasi bucket senza accettazione del rischio.
4.6 Le chiamate API contro le politiche chiave KMS per le chiavi dell'infrastruttura AMS nelle politiche IAM del cliente non devono essere consentite.
4.7 Le azioni che aggirano il processo di gestione delle modifiche (RFC) non devono essere consentite, come l'avvio o l'arresto dell'istanza, la creazione di un bucket S3 o di un'istanza RDS e così via.
4.8 Le azioni che apportano modifiche ai record DNS dell'infrastruttura AMS in Amazon Route 53 non devono essere consentite.
4.9 Gli utenti umani IAM con accesso alla console, creati dopo aver seguito il giusto processo, non devono avere alcuna policy collegata direttamente, ad eccezione della policy trust, assume role e time limited policy.
4.10 È possibile creare profili di EC2 istanze Amazon con accesso in lettura a un segreto o uno spazio dei nomi specifico Gestione dei segreti AWS all'interno dello stesso account.
4.11 Le autorizzazioni di AWS Managed Services Change Management (AMSCM) o AWS Managed Services Service Knowledge Management System (AMSSKMS) possono essere aggiunte a qualsiasi ruolo (possibilità di aprire). SR/Incident/RFC
4.12 La politica IAM non deve includere alcuna azione che includa l'azione Allow logs: DeleteLogGroup e logs: DeleteLogStream su qualsiasi gruppo di CloudWatch log AMS Amazon.
4.13 Le autorizzazioni per creare chiavi multiregionali non devono essere consentite.
4.14 Per fornire l'accesso ai bucket S3 ARNs che non sono ancora stati creati nei tuoi account, utilizza la chiave s3:ResourceAccount di condizione S3 specifica del servizio per specificare il numero di account.
4.15 Puoi visualizzare, creare, elencare ed eliminare l'accesso alla tua dashboard personalizzata, ma solo l'accesso alla visualizzazione e all'elenco sulle CloudWatch dashboard di Amazon.
4.15.1 Puoi visualizzare, creare, elencare ed eliminare l'accesso alla dashboard personalizzata di S3 Storage Lens.
4.16 È possibile concedere autorizzazioni complete relative a SQL Workbench per roles/users lavorare sui database Amazon Redshift.
4.17 Qualsiasi AWS CloudShell autorizzazione può essere concessa ai ruoli del cliente in alternativa alla CLI.
4.18 Un ruolo IAM con un Servizio AWS responsabile affidabile deve inoltre essere conforme agli standard tecnici IAM.
4.19 I Service Linked Roles (SLRs) non sono soggetti agli standard tecnici AMS IAM, in quanto sono creati e gestiti da IAM Service Team.
4.20 Le policy IAM non devono consentire l'accesso illimitato in lettura agli oggetti bucket Amazon S3 (ad esempio, Amazon S3GetObject:) su tutti i bucket di un account:

  • Negli account in modalità sviluppatore: le violazioni generano una notifica di rischio

  • Negli account in modalità non sviluppatore: le violazioni richiedono l'accettazione del rischio

4.21 Tutte le autorizzazioni IAM per il tipo di risorsa «savingsplan» possono essere concesse ai clienti.
4.22 I tecnici AMS non sono autorizzati a copiare o spostare manualmente i dati dei clienti (file, oggetti S3, database) in nessuno dei servizi di storage dei dati, come Amazon S3, Amazon Relational Database Service, Amazon DynamoDB e così via, o nel file system del sistema operativo.
4.23 La politica SCP non deve essere modificata per consentire accessi aggiuntivi in nessuno degli account gestiti da AMS.
4.24 Non devono essere consentite modifiche alla politica SCP che potrebbero compromettere l'infrastruttura o le capacità di gestione di AMS. (Nota: le risorse AMS hanno il tag AppId= AMSInfrastructure e seguono l'AMS Protected Namespace).
4.25 La funzionalità AMS Automated IAM Provisioning deve essere abilitata nei tuoi account come funzionalità opzionale.
4.26 I ruoli o gli utenti di AMS assunti da persone non devono avere accesso ai contenuti dei clienti in S3, RDS, DynamoDB, Redshift, Elasticache, EFS e. FSx Inoltre, qualsiasi accesso a contenuti nuovi e noti APIs rilasciati da altri Servizi AWS che garantiscono l'accesso ai contenuti dei clienti deve essere esplicitamente negato nei ruoli di operatore.
5.0 Federazione
5.1 L'autenticazione deve essere configurata utilizzando la federazione nell'account gestito da AMS.
5.2 Deve esserci un solo trust in uscita unidirezionale da AMS AD all'Active Directory (AMS AD si affida ad on-premise).
5.3 Gli archivi di identità utilizzati per l'autenticazione su AMS non devono esistere negli account delle applicazioni gestite da AMS.
6.0 Politiche trasversali agli account
6.1 È possibile configurare le politiche di fiducia dei ruoli IAM tra account AMS che appartengono allo stesso cliente in base ai record dei clienti.
6.2 Le politiche di fiducia dei ruoli IAM tra account AMS e non AMS devono essere configurate solo se l'account non AMS è di proprietà dello stesso cliente AMS (confermando che si trovano sotto lo stesso AWS Organizations account o abbinando il dominio e-mail al nome dell'azienda del cliente).
6.3 Le politiche di fiducia dei ruoli IAM tra account AMS e account di terze parti non devono essere configurate senza l'accettazione del rischio.
6.4 È possibile configurare politiche su più account per accedere a qualsiasi account AMS gestito dal cliente CMKs tra account AMS dello stesso cliente.
6,5 È possibile configurare politiche tra account per accedere a qualsiasi chiave KMS all'interno di un account non AMS tramite un account AMS.
6.6 Le politiche relative all'accesso a qualsiasi chiave KMS all'interno di un account AMS da parte di un account di terze parti non devono essere consentite senza l'accettazione del rischio.
6.6.1 Le politiche tra account per l'accesso a qualsiasi chiave KMS all'interno di un account AMS tramite un account diverso da AMS possono essere configurate solo se l'account non AMS è di proprietà dello stesso cliente AMS.
6.7 È possibile configurare policy tra più account per accedere a qualsiasi dato o risorsa del bucket S3 in cui i dati possono essere archiviati (come Amazon RDS, Amazon DynamoDB o Amazon Redshift) tra account AMS dello stesso cliente.
6.8 È possibile configurare policy tra account per accedere a tutti i dati o le risorse del bucket S3 in cui i dati possono essere archiviati (come Amazon RDS, Amazon DynamoDB o Amazon Redshift) in un account non AMS da un account AMS con accesso in sola lettura.
6.9 Le policy tra account per accedere a tutti i dati o le risorse del bucket S3 in cui i dati possono essere archiviati (come Amazon RDS, Amazon DynamoDB o Amazon Redshift) con autorizzazioni di scrittura da AMS a un account non AMS (o da un account non AMS a AMS) devono essere configurate solo se l'account non AMS è di proprietà dello stesso cliente AMS (confermando che si trovano sullo stesso account o abbinando dominio email con il nome dell' AWS Organizations azienda del cliente).
6,10 È possibile configurare policy tra account per accedere a tutti i dati o le risorse del bucket S3 in cui i dati possono essere archiviati (come Amazon RDS, Amazon DynamoDB o Amazon Redshift) in un account di terze parti da un account AMS con accesso in sola lettura.
6.11 Le policy tra account per accedere a qualsiasi dato o risorsa del bucket S3 in cui i dati possono essere archiviati (come Amazon RDS, Amazon DynamoDB o Amazon Redshift) in un account di terze parti da un account AMS con accesso in scrittura non devono essere configurate.
6.12 Le politiche interaccount di account di terze parti per accedere a un bucket S3 o alle risorse in cui è possibile archiviare i dati (come Amazon RDS, Amazon DynamoDB o Amazon Redshift) non devono essere configurate senza l'accettazione del rischio.
7.0 Gruppi di utenti
7.1 I gruppi IAM con autorizzazioni di sola lettura e non mutative sono consentiti.
8.0 Policy basate su risorse
8.1 Le risorse dell'infrastruttura AMS devono essere protette dalla gestione da parte di identità non autorizzate mediante l'aggiunta di politiche basate sulle risorse.
8.2 Le tue risorse devono essere configurate con politiche basate sulle risorse con privilegi minimi, a meno che tu non specifichi esplicitamente una politica diversa.
9.0 Servizi forniti in modalità self-service (SSPS)
9.1 Il ruolo o la policy IAM predefiniti di AMS (inclusi profilo di istanza, SSPS, pattern) non devono essere modificati con o senza alcuna accettazione del rischio. Sono consentite eccezioni (senza accettazione del rischio) per le politiche di fiducia. L'etichettatura del ruolo, della politica o delle modifiche dell'utente è consentita anche nei ruoli SSP predefiniti.
9.3 La policy SSPS per il ruolo della console Systems Manager Automation non può essere associata a nessun ruolo personalizzato oltre al ruolo predefinito. Le altre policy SSPS devono essere associate ai ruoli IAM personalizzati solo dopo aver verificato che l'associazione della policy a un ruolo personalizzato non fornisca autorizzazioni aggiuntive al di fuori della progettazione prevista per il servizio SSPS predefinito.

Di seguito è riportato il controllo standard per 003 - Network Security:

ID Standard tecnico
Reti
1.0 È necessario accedere a tutte EC2 le istanze tramite SSH o RDP solo tramite gli host Bastion, l'intervallo CIDR VPC VPC dell'host bastion o dall'intervallo CIDR VPC della stessa istanza.
2.0 L'IP elastico sulle istanze è consentito EC2
3.0 È necessario utilizzare il piano di controllo AMS e, per estensione, nel piano dati TLS 1.2+.
4.0 Tutto il traffico in uscita deve passare utilizzando l'account IGW o TGW.
5.0 Un gruppo di sicurezza non deve avere l'origine 0.0.0.0/0 nella regola in entrata se non è collegato a un sistema di bilanciamento del carico come previsto dalla versione 9.0
6.0 Il bucket o gli oggetti S3 non devono essere resi pubblici senza l'accettazione del rischio.
7.0 L'accesso alla gestione dei server sulle porte SSH/22 o SSH/2222 (non SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 o 1604, LDAP/389 o 636 e RPC/135, NETBIOS/137-139 non deve essere consentito dall'esterno del VPC tramite gruppi di sicurezza.
8.0 L'accesso alla gestione del database sulle porte (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) o sulla porta personalizzata non deve essere consentito dal pubblico non indirizzato a VPC su DX, VPC-Peer o VPN tramite un gruppo di sicurezza. IPs
8.1 Qualsiasi risorsa in cui è possibile archiviare i dati dei clienti non deve essere esposta direttamente alla rete Internet pubblica.
9.0 L'accesso diretto alle applicazioni tramite le porte HTTP/80, HTTPS/8443 e HTTPS/443 da Internet è consentito solo ai sistemi di bilanciamento del carico, ma non direttamente alle risorse di calcolo, ad esempio istanze, contenitori, ecc. EC2 ECS/EKS/Fargate
10.0 È possibile consentire l'accesso alle applicazioni tramite le porte HTTP/80 e HTTPS/443 dall'intervallo IP privato del cliente.
11.0 Qualsiasi modifica ai gruppi di sicurezza che controllano l'accesso all'infrastruttura AMS non deve essere consentita senza l'accettazione del rischio.
12.0 AMS Security fa riferimento agli standard ogni volta che viene richiesto di collegare un gruppo di sicurezza a un'istanza.
13.0 L'accesso al bastione dei clienti sulle porte 3389 e 22 deve essere consentito solo da intervalli di IP privati instradati nel VPC tramite DX, VPC-Peer o VPN.
14.0 L'associazione tra account di zone private ospitate VPCs da un account AMS a un altro account AMS (o da un account non AMS a AMS) deve essere configurata solo se l'account non AMS è di proprietà dello stesso cliente AMS (confermando che si trovano sullo stesso account AWS Organization o abbinando il dominio e-mail al nome dell'azienda del cliente) utilizzando strumenti interni.
15.0 È possibile consentire connessioni peering VPC tra account che appartengono allo stesso cliente.
16.0 La base AMS AMIs può essere condivisa con account non AMS a condizione che entrambi gli account siano di proprietà dello stesso cliente (confermando che appartengono allo stesso AWS Organizations account o abbinando il dominio e-mail al nome dell'azienda del cliente) utilizzando strumenti interni.
17.0 La porta FTP 21 non deve essere configurata in nessuno dei gruppi di sicurezza senza un'accettazione del rischio.
18.0 La connettività di rete tra account tramite gateway di transito è consentita a condizione che tutti gli account siano di proprietà del cliente.
19.0 Non è consentito rendere pubblica una sottorete privata
20.0 Le connessioni peering VPC con account di terze parti (non di proprietà del cliente) non devono essere consentite.
21.0 L'allegato Transit Gateway con un account di terze parti (non di proprietà del cliente) non deve essere consentito.
22.0 Qualsiasi traffico di rete necessario ad AMS per fornire i servizi ai clienti non deve essere bloccato al punto di uscita della rete del cliente.
23.0 La condivisione delle regole del resolver con quelle Account AWS di proprietà dello stesso cliente è consentita con una notifica del rischio
19.0 ICMP
19,1 La richiesta ICMP in entrata ad Amazon EC2 dall'infra del cliente richiederà una notifica del rischio.
19.2 È consentita la richiesta in entrata proveniente da un IPs instradamento pubblico verso Amazon VPC tramite DX, VPC-Peer o VPN tramite un gruppo di sicurezza.
19.3 Le richieste in entrata provenienti da un pubblico IPs non indirizzato ad Amazon VPC tramite DX, VPC-Peer o VPN tramite un gruppo di sicurezza richiederebbero l'accettazione del rischio.
19.4 È consentita la richiesta ICMP in uscita EC2 da Amazon verso qualsiasi destinazione.
20.0 Condivisione di gruppi di sicurezza
20.1

Se un gruppo di sicurezza soddisfa questo standard di sicurezza, può essere condiviso tra VPCs lo stesso account e tra account della stessa organizzazione.

20.2

Se un gruppo di sicurezza non soddisfa questo standard e in precedenza era richiesta l'accettazione del rischio per tale gruppo di sicurezza, l'uso della funzionalità di condivisione dei gruppi di sicurezza tra VPCs lo stesso account o tra account della stessa organizzazione non è consentito senza l'accettazione del rischio per quel nuovo VPC o account.

Di seguito è riportato il controllo standard per 004 - Penetration Testing

  1. AMS non supporta l'infrastruttura pentest. È responsabilità del cliente. Ad esempio, Kali non è una distribuzione Linux supportata da AMS.

  2. I clienti devono attenersi ai test di penetrazione.

  3. AMS deve ricevere una notifica preventiva con 24 ore di anticipo nel caso in cui il cliente desideri eseguire test di penetrazione dell'infrastruttura all'interno degli account.

  4. AMS fornirà al cliente l'infrastruttura di pentesting in base ai requisiti del cliente esplicitamente indicati nella richiesta di modifica o nella richiesta di assistenza da parte del cliente.

  5. La gestione delle identità per l'infrastruttura di pentesting del cliente è responsabilità del cliente.

Di seguito è riportato il controllo standard per 005 - GuardDuty

  1. GuardDuty deve essere abilitato in tutti gli account dei clienti in ogni momento.

  2. GuardDuty I risultati del Customer Managed Application Account (CMA) in MALZ non genereranno allarmi per il team operativo.

  3. GuardDuty gli avvisi devono essere archiviati nello stesso account o in qualsiasi altro account gestito dalla stessa organizzazione.

  4. La funzionalità di elenco IP affidabile di non GuardDuty deve essere utilizzata. In alternativa, è possibile utilizzare l'archiviazione automatica, utile per scopi di controllo.

  5. GuardDuty la delega dell'amministratore non deve essere abilitata in MALZ poiché l'amministratore delegato sarebbe in grado di eseguire azioni con privilegi elevati come disabilitarle GuardDuty negli altri account senza accettare il rischio.

  6. GuardDuty I filtri di archiviazione automatica devono utilizzare l'ambito minimo per il rendimento massimo. Ad esempio, se AMS rileva più dati imprevedibili IPs in diversi blocchi CIDR e se esiste un ASN aziendale appropriato da utilizzare, utilizza l'ASN. Tuttavia, se puoi limitarti a intervalli o indirizzi /32 specifici, allora limitati a quelli.

Di seguito è riportato il controllo standard per 006 - Host Security

  • Un agente antivirus deve essere sempre in esecuzione su tutte le EC2 istanze. (ad esempio, Trend Micro DSM).

  • Il modulo antimalware deve essere abilitato.

  • L'agente EPS deve includere tutte le directory e i file per la scansione.

  • I file messi in quarantena dalla soluzione antivirus possono essere condivisi con l'utente su richiesta.

  • Non è necessario installare una soluzione di sicurezza degli endpoint di terze parti.

  • La frequenza di aggiornamento delle firme antivirus deve essere impostata su almeno una volta al giorno.

  • La frequenza di scansione pianificata deve essere impostata su almeno una volta al mese.

  • La scansione in tempo reale (in accesso) deve essere abilitata e in esecuzione in qualsiasi momento.

  • AMS non deve eseguire sulle tue istanze alcuno script personalizzato che non sia di proprietà o creato da AMS. (Nota: è possibile farlo utilizzando l'accesso Stack Admin tramite Stack Admin access CT o utilizzando AWS Systems Manager Automation (AMS SSPS).

  • L'autenticazione a livello di rete (NLA) non deve essere disabilitata sull'host Windows.

  • Il sistema operativo host deve essere aggiornato con le ultime patch di sicurezza in base al ciclo di patch configurato.

  • Un account gestito AMS non deve contenere un'istanza non gestita nell'account.

  • La creazione di account di amministratore locale sull'istanza da parte di AMS non deve essere consentita.

  • La coppia di chiavi non EC2 deve essere creata.

  • Non è necessario utilizzare sistemi operativi dichiarati come End of Life (EOL) e non è previsto alcun ulteriore supporto di sicurezza fornito dal fornitore o da terze parti.

Quello che segue è il controllo standard per 007 - Logging

ID Standard tecnico
1.0 Tipi di registro
1.1 Registri del sistema operativo: tutti gli host devono registrarsi in base al numero minimo di eventi di autenticazione dell'host, eventi di accesso per tutti gli utilizzi di privilegi elevati ed eventi di accesso per tutte le modifiche alla configurazione degli accessi e dei privilegi, comprese quelle relative all'esito positivo e negativo.
1.2 AWS CloudTrail: CloudTrail la registrazione degli eventi di gestione deve essere abilitata e configurata per inviare i log a un bucket S3.
1.3 Registri di flusso VPC: tutti i registri del traffico di rete devono essere registrati tramite VPC Flow Logs.
1.4 Amazon S3 Server Access Logging: i bucket S3 obbligatori di AMS che archiviano i log devono avere la registrazione degli accessi al server abilitata.
1.5 AWS Config Istantanee: AWS Config devono registrare le modifiche alla configurazione per tutte le risorse supportate in tutte le regioni e consegnare i file degli snapshot di configurazione ai bucket S3 almeno una volta al giorno.
1.6 Registri dell'Endpoint Protection System (EPS): la registrazione della soluzione EPS deve essere abilitata e configurata per inviare i log a un gruppo di log Logs. CloudWatch
1,7 Registri delle applicazioni: i clienti possono abilitare la registrazione nelle proprie applicazioni e archiviarli nel gruppo di log Logs o in un bucket S3. CloudWatch
1.8 Registrazione a livello di oggetto S3: i clienti hanno la possibilità di abilitare la registrazione a livello di oggetto nei propri bucket S3.
1.9 Registrazione dei servizi: i clienti hanno la possibilità di abilitare e inoltrare i log per i servizi SSPS come qualsiasi altro servizio di base.
1.10 Log Elastic Load Balancing (Load Classic/Application Load Balancer/Network Balancer): le voci dei log di accesso e degli errori devono essere archiviate nei bucket S3 gestiti da AMS 2.0.
2.0 Controllo degli accessi
2.1 Non è necessario disporre dell'accesso in scrittura o eliminazione nei bucket S3 richiesti da AMS che memorizzano log e CloudWatch Logs; gruppi di log.
2.2 È necessario disporre dell'accesso in sola lettura a tutti i log dei propri account.
2.3 I bucket S3 obbligatori di AMS che archiviano i log non devono consentire l'utilizzo di account di terze parti, come previsto dalle politiche relative ai bucket.
2.4 I log dei gruppi di CloudWatch log Logs non devono essere eliminati senza l'approvazione esplicita del contatto di sicurezza autorizzato.
3.0 Conservazione dei log
3.1 I gruppi di log CloudWatch Logs obbligatori da AMS devono avere un periodo minimo di conservazione dei log di 90 giorni.
3.2 I bucket S3 obbligatori da AMS che archiviano i log devono avere un periodo di conservazione minimo di 18 mesi sui log.
3.3 AWS Backup le istantanee dovrebbero essere disponibili con una conservazione minima di 31 giorni sulle risorse supportate.
4.0 Encryption (Crittografia)
4.1 La crittografia deve essere abilitata in tutti i bucket S3 richiesti da AMS Teams che archivia i log.
4.2 Qualsiasi inoltro dei log dagli account dei clienti a qualsiasi altro account deve essere crittografato.
5.0 Integrità
5.1 Il meccanismo di integrità dei file di registro deve essere abilitato. La «convalida dei file di registro» deve essere configurata nei AWS CloudTrail percorsi richiesti dai team AMS.
6.0 Inoltro dei log
6.1 Qualsiasi registro può essere inoltrato da un account AMS a un altro account AMS dello stesso cliente.
6.2 Qualsiasi registro può essere inoltrato da AMS a un account diverso da AMS solo se l'account non AMS è di proprietà dello stesso cliente AMS.
6.3 I registri di un account cliente non devono essere inoltrati a un account di terzi (che non è di proprietà del cliente).

Di seguito è riportato il controllo standard per 008 - AMS-MAD

ID Standard tecnico
1.0 Gestione degli accessi
1.1 Solo gli utenti con privilegi AMS con accessi interattivi e attività di automazione devono essere autorizzati ad accedere all'host di gestione per l'amministrazione dell'AD gestito negli account dei clienti.
1.2 Gli amministratori AD devono avere solo privilegi di amministratore delegato (gruppo di amministratori delegati AMS).
1.3 I tecnici che accedono agli ambienti AD del cliente (host o istanze di gestione) devono disporre di un accesso limitato nel tempo.
1.4 I clienti hanno accesso in sola lettura agli oggetti AD utilizzando Remote Server Administrator Tools in un'istanza. EC2
1.5 I diritti amministrativi per l'utente o il gruppo di Active Directory non devono essere consentiti.
1.6 AWS La condivisione della directory con il Account AWS proprietario dello stesso cliente è consentita con una notifica del rischio.
2.0 Account di servizio
2.1 Gli account di servizio gestiti di gruppo (gMSA) devono essere utilizzati ovunque siano supportati dalle applicazioni anziché gli account di servizio standard.
2.2 Tutti gli altri account di servizio devono essere creati dopo il processo di accettazione del rischio.
2.3 I gruppi di sicurezza AD non devono essere riutilizzati a meno che non sia esplicitamente richiesto dal cliente. È necessario creare nuovi gruppi AD. Gli oggetti del computer che richiedono l'accesso all'account del servizio devono essere aggiunti al nuovo gruppo di sicurezza.
2.4 Qualsiasi account di servizio gMSA deve essere aggiunto all'unità organizzativa (OU) «Account di servizio gestito».
2.5 Tutti gli account di servizio non GMSA devono essere aggiunti nell'unità organizzativa «Users→Account di servizio».
3.0 Oggetti di policy di gruppo (GPO)
3.1 Le impostazioni del GPO «Impostazioni di Windows > Impostazioni di sicurezza» non devono essere modificate se riducono in qualche modo il livello di sicurezza dell'account rispetto allo stato corrente.
3.2 In MALZ, RFCs inviato da un account dell'applicazione che richiede la creazione di un GPO, il GPO deve essere collegato all'unità organizzativa corrispondente all'account dell'app. Qualsiasi elemento GPOs che influisca su tutti gli account deve provenire dall'account Shared Service.
3.3 Il timeout predefinito della sessione di inattività RDP deve essere impostato su 15 minuti per tutti i server del dominio Active Directory.
4.0 Active Directory Trust
4.1 La fiducia in uscita unidirezionale (da directory ospitata da AMS a Customer Directory) è consentita se i server IPs di inoltro condizionali vengono indirizzati a VPC tramite DX, VPC-Peer o VPN.
5.0 Altri
5.1 Il meccanismo di integrità dei file di registro deve essere abilitato. La «convalida dei file di registro» deve essere configurata nei AWS CloudTrail percorsi richiesti dai team AMS.
6.0 Inoltro dei log
6.1 Gli utenti, i gruppi, gli oggetti informatici, le unità organizzative o altre entità del cliente non devono utilizzare la convenzione di denominazione AMS secondo la convenzione di denominazione AMS.
6.2 Tutto OUs deve essere gestito da AMS.

Di seguito è riportato il controllo standard per 009 - Varie

  • Se la crittografia è abilitata in una risorsa, oggetto, database o file system, non deve essere disabilitata.