Controlli standard in AMS Accelerate - Guida utente di AMS Accelerate

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 Accelerate

I seguenti sono i controlli standard di AMS:

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 timeout della sessione RDP per Microsoft Windows Server è impostato su 15 minuti e può essere esteso in base al caso d'uso.
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 Le chiavi di accesso per l'account root non devono essere create.
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 o 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 Sui server Microsoft Windows, è necessario creare solo l'account di servizio gestito (gMSA) del gruppo Microsoft.
4.0 Politiche, azioni e APIs
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.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.8 Le azioni, quali 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 la procedura prevista 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 AWS Secrets Manager all'interno dello stesso account.
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 L'accesso all'ARN del bucket S3 che non è ancora stato creato negli account dei clienti può essere fornito limitando l'accesso ai bucket agli account dei clienti specificando il numero di account utilizzando la chiave di condizione S3 specifica del servizio s3:. ResourceAccount
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 il AWS servizio come principio affidabile deve inoltre essere in linea con gli 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 La policy IAM non dovrebbe consentire la lettura di oggetti (ad esempio, S3:GetObject) in tutti i bucket S3 dell'account.
4.21 Tutte le autorizzazioni IAM per il tipo di risorsa «savingsplan» possono essere concesse ai clienti.
4.22 Il tecnico AMS non è autorizzato a copiare o spostare manualmente i dati dei clienti (file, oggetti S3, database ecc.) in nessuno dei servizi di storage dati come Amazon S3, Amazon Relational Database Service, Amazon DynamoDB e così via, o nel file system del sistema operativo.
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 f 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.4 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 risorse del cliente devono essere configurate con politiche basate sulle risorse con privilegi minimi, a meno che il cliente non specifichi esplicitamente una politica diversa.

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

ID Standard tecnico
Reti
1.0 Riservato per il controllo futuro
2.0 L'IP elastico sulle EC2 istanze è consentito
3.0 È necessario utilizzare il piano di controllo AMS e, per estensione, nel piano dati TLS 1.2+.
5.0 Un gruppo di sicurezza non deve avere come sorgente 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 tramite DX, VPC-Peer o VPN tramite 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 farà riferimento agli standard ogni volta che viene richiesta l'associazione di un gruppo di sicurezza a un'istanza.
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 richiesta ICMP in entrata ad Amazon EC2 dall'infra del cliente richiederà una notifica del rischio.
24,0 È 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.
25.0 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.
26.0 È consentita la richiesta ICMP in uscita EC2 da Amazon verso qualsiasi destinazione.
27.0 Condivisione di gruppi di sicurezza
27.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.

27.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 X004 - 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 X005 - GuardDuty

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

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

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

Di seguito è riportato il controllo standard per X007 - 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,7 Registri delle applicazioni: i clienti possono abilitare la registrazione nelle proprie applicazioni e archiviarli nel gruppo di log CloudWatch Logs o in un bucket S3.
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.3 I bucket S3 obbligatori 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 dai gruppi di CloudWatch log Logs non devono essere eliminati senza l'approvazione esplicita del contatto di sicurezza autorizzato dal cliente.
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 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. Ciò significa configurare la «convalida dei file di registro» negli AWS CloudTrail itinerari 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 (confermando che si tratta dello stesso AWS Organizations account o associando il dominio e-mail al nome dell'azienda del cliente e all'account collegato a PAYER) utilizzando strumenti interni.