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à.
Standard di gestione dei servizi: AWS Control Tower
Questa sezione fornisce informazioni su Service-Managed Standard:. AWS Control Tower
Che cos'è Service-Managed Standard:? AWS Control Tower
Questo standard è progettato per gli utenti di AWS Security Hub e AWS Control Tower. Ti consente di configurare i controlli proattivi AWS Control Tower insieme ai controlli di rilevamento di Security Hub nel AWS Control Tower servizio.
I controlli proattivi aiutano a garantire il Account AWS mantenimento della conformità perché segnalano le azioni che possono portare a violazioni o configurazioni errate delle politiche. I controlli investigativi rilevano la non conformità delle risorse (ad esempio, configurazioni errate) all'interno dell'azienda. Account AWS Abilitando controlli proattivi e investigativi per l' AWS ambiente, è possibile migliorare il livello di sicurezza nelle diverse fasi di sviluppo.
Suggerimento
Gli standard gestiti dai servizi differiscono dagli standard gestiti da AWS Security Hub. Ad esempio, è necessario creare ed eliminare uno standard gestito dai servizi nel servizio di gestione. Per ulteriori informazioni, consulta Standard di gestione dei servizi in Security Hub.
Nella console e nell'API di Security Hub, puoi visualizzare Service-Managed Standard: AWS Control Tower insieme ad altri standard di Security Hub.
Creazione dello standard
Questo standard è disponibile solo se lo si crea in AWS Control Tower. AWS Control Tower crea lo standard quando si attiva per la prima volta un controllo applicabile utilizzando uno dei seguenti metodi:
-
AWS Control Tower console
-
AWS Control Tower API (chiama l'
EnableControl
API) -
AWS CLI (esegui il
enable-control
comando)
I controlli del Security Hub sono identificati nella AWS Control Tower console come SH. ControlID
(ad esempio, SH. CodeBuild.1).
Quando crei lo standard, se non hai già abilitato Security Hub, abilita AWS Control Tower anche Security Hub per te.
Se non lo hai configurato AWS Control Tower, non puoi visualizzare o accedere a questo standard nella console Security Hub, nell'API Security Hub o AWS CLI. Anche se è stato configurato AWS Control Tower, non è possibile visualizzare o accedere a questo standard in Security Hub senza prima aver creato lo standard AWS Control Tower utilizzando uno dei metodi precedenti.
Questo standard è disponibile solo nei paesi in Regioni AWS cui AWS Control Tower è disponibile, tra cui AWS GovCloud (US).
Abilitazione e disabilitazione dei controlli nello standard
Dopo aver creato lo standard nella AWS Control Tower console, è possibile visualizzare lo standard e i controlli disponibili in entrambi i servizi.
Dopo aver creato lo standard per la prima volta, non ci sono controlli abilitati automaticamente. Inoltre, quando Security Hub aggiunge nuovi controlli, questi non vengono abilitati automaticamente per Service-Managed Standard:. AWS Control TowerÈ necessario abilitare e disabilitare i controlli per lo standard in AWS Control Tower utilizzando uno dei seguenti metodi:
-
AWS Control Tower console
-
AWS Control Tower API (chiama
EnableControl
andDisableControl
APIs) -
AWS CLI (esegui i
disable-control
comandi enable-control
and)
Quando si modifica lo stato di attivazione di un controllo in AWS Control Tower, la modifica si riflette anche in Security Hub.
Tuttavia, la disabilitazione di un controllo in Security Hub che è abilitato in AWS Control Tower comporta una deriva del controllo. Lo stato del controllo in AWS Control Tower viene visualizzato come. Drifted
È possibile risolvere questa deriva selezionando Re-register OU nella AWS Control Tower console oppure disabilitando e riabilitando il controllo AWS Control Tower utilizzando uno dei metodi precedenti.
Il completamento delle azioni di attivazione e disabilitazione in aiuta a evitare la deriva del controllo. AWS Control Tower
Quando abiliti o disabiliti i controlli in AWS Control Tower, l'azione si applica a tutti gli account e alle regioni. Se abiliti e disabiliti i controlli in Security Hub (non consigliato per questo standard), l'azione si applica solo all'account e alla regione correnti.
Nota
La configurazione centrale non può essere utilizzata per gestire Service-Managed Standard:. AWS Control Tower Se utilizzi la configurazione centrale, puoi utilizzare solo il AWS Control Tower servizio per abilitare e disabilitare i controlli di questo standard per un account gestito centralmente.
Visualizzazione dello stato di attivazione e dello stato di controllo
È possibile visualizzare lo stato di attivazione di un controllo utilizzando uno dei seguenti metodi:
-
Console Security Hub, API Security Hub o AWS CLI
-
AWS Control Tower console
-
AWS Control Tower API per visualizzare un elenco di controlli abilitati (chiama l'
ListEnabledControls
API) -
AWS CLI per visualizzare un elenco di controlli abilitati (esegui il
list-enabled-controls
comando)
Un controllo che disabiliti AWS Control Tower ha lo stato di attivazione in Security Hub Disabled
a meno che non abiliti esplicitamente tale controllo in Security Hub.
Security Hub calcola lo stato del controllo in base allo stato del flusso di lavoro e allo stato di conformità dei risultati del controllo. Per ulteriori informazioni sullo stato di attivazione e sullo stato di controllo, vedere. Visualizzazione dei dettagli di un controllo
In base agli stati di controllo, Security Hub calcola un punteggio di sicurezza per Service-Managed Standard:. AWS Control Tower Questo punteggio è disponibile solo in Security Hub. Inoltre, puoi visualizzare i risultati del controllo solo in Security Hub. Il punteggio di sicurezza standard e i risultati del controllo non sono disponibili in AWS Control Tower.
Nota
Quando abiliti i controlli per Service-Managed Standard: AWS Control Tower, Security Hub può impiegare fino a 18 ore per generare risultati per i controlli che utilizzano una regola esistente collegata al AWS Config servizio. Potresti avere regole collegate ai servizi esistenti se hai abilitato altri standard e controlli in Security Hub. Per ulteriori informazioni, consulta Pianificazione dell'esecuzione dei controlli di sicurezza.
Eliminazione dello standard
È possibile eliminare questo standard disattivando tutti i controlli applicabili utilizzando uno dei seguenti metodi: AWS Control Tower
-
AWS Control Tower console
-
AWS Control Tower API (chiama l'
DisableControl
API) -
AWS CLI (esegui il
disable-control
comando)
La disabilitazione di tutti i controlli elimina lo standard in tutti gli account gestiti e nelle regioni governate in. AWS Control Tower L'eliminazione dello standard in lo AWS Control Tower rimuove dalla pagina Standard della console di Security Hub e non è più possibile accedervi utilizzando l'API Security Hub o AWS CLI.
Nota
La disabilitazione di tutti i controlli dallo standard in Security Hub non disabilita o elimina lo standard.
La disabilitazione del servizio Security Hub rimuove Service-Managed Standard AWS Control Tower e tutti gli altri standard che hai abilitato.
Formato di campo di ricerca per Service-Managed Standard: AWS Control Tower
Quando crei Service-Managed Standard: AWS Control Tower e ne abiliti i controlli, inizierai a ricevere i risultati del controllo in Security Hub. Security Hub riporta i risultati del controllo inAWS Formato ASFF (Security Finding Format). Questi sono i valori ASFF per Amazon Resource Name (ARN) di questo standard e: GeneratorId
-
ARN standard —
arn:aws:us-east-1
:securityhub:::standards/service-managed-aws-control-tower/v/1.0.0 -
GeneratorId –
service-managed-aws-control-tower/v/1.0.0/
CodeBuild.1
Per un esempio di risultato per Service-Managed Standard: AWS Control Tower, vedere. Esempi di risultati di controllo in Security Hub
Controlli che si applicano a Service-Managed Standard: AWS Control Tower
Service-Managed Standard: AWS Control Tower supporta un sottoinsieme di controlli che fanno parte dello standard AWS Foundational Security Best Practices (FSBP). Scegli un controllo per visualizzarne le informazioni, incluse le procedure di correzione in caso di risultati non riusciti.
L'elenco seguente mostra i controlli disponibili per Service-Managed Standard:. AWS Control Tower I limiti regionali sui controlli corrispondono ai limiti regionali sui controlli corollari dello standard FSBP. Questo elenco mostra il controllo di sicurezza indipendente dagli standard. IDs Nella AWS Control Tower console, i controlli IDs sono formattati come SH. ControlID
(ad esempio SH. CodeBuild.1). In Security Hub, se i risultati del controllo consolidato sono disattivati nel tuo account, il ProductFields.ControlId
campo utilizza l'ID di controllo standard. L'ID di controllo basato su standard è formattato come CT. ControlId
(ad esempio, CT. CodeBuild.1).
-
[Account.1] Le informazioni di contatto di sicurezza devono essere fornite per un Account AWS
-
[APIGateway.3] Le fasi API REST di API Gateway devono avere la AWS X-Ray traccia abilitata
-
[APIGateway.4] API Gateway deve essere associato a un ACL Web WAF
-
[APIGateway.8] Le rotte API Gateway devono specificare un tipo di autorizzazione
-
[APIGateway.9] La registrazione degli accessi deve essere configurata per API Gateway V2 Stages
-
[AppSync.5] AWS AppSync APIs GraphQL non deve essere autenticato con chiavi API
-
[AutoScaling.2] Il gruppo Amazon EC2 Auto Scaling dovrebbe coprire più zone di disponibilità
-
[AutoScaling.9] I gruppi Amazon EC2 Auto Scaling devono utilizzare i modelli di lancio di Amazon EC2
-
[CloudTrail.2] CloudTrail dovrebbe avere la crittografia a riposo abilitata
-
[CloudTrail.4] la convalida dei file di CloudTrail registro dovrebbe essere abilitata
-
[CloudTrail.5] i CloudTrail trail devono essere integrati con Amazon Logs CloudWatch
-
[CodeBuild.3] I log CodeBuild S3 devono essere crittografati
-
[CodeBuild.4] Gli ambienti di CodeBuild progetto devono avere una durata di registrazione AWS Config
-
[DMS.1] Le istanze di replica del Database Migration Service non devono essere pubbliche
-
[DocumentDB.1] I cluster Amazon DocumentDB devono essere crittografati quando sono inattivi
-
[DocumentDB.3] Le istantanee manuali dei cluster di Amazon DocumentDB non devono essere pubbliche
-
[DynamoDB.1] Le tabelle DynamoDB dovrebbero scalare automaticamente la capacità in base alla domanda
-
[DynamoDB.2] Le tabelle DynamoDB dovrebbero avere il ripristino abilitato point-in-time
-
[DynamoDB.3] I cluster DynamoDB Accelerator (DAX) devono essere crittografati quando sono inattivi
-
[EC2.1] Gli snapshot di Amazon EBS non devono essere ripristinabili pubblicamente
-
[EC2.3] I volumi Amazon EBS collegati devono essere crittografati a riposo
-
[EC2.4] Le EC2 istanze interrotte devono essere rimosse dopo un periodo di tempo specificato
-
[EC2.6] La registrazione del flusso VPC deve essere abilitata in tutti i casi VPCs
-
[EC2.7] La crittografia predefinita di EBS deve essere abilitata
-
[EC2.8] EC2 le istanze devono utilizzare Instance Metadata Service versione 2 () IMDSv2
-
[EC2.9] EC2 Le istanze Amazon non devono avere un indirizzo pubblico IPv4
-
[EC2.15] Le EC2 sottoreti Amazon non devono assegnare automaticamente indirizzi IP pubblici
-
[EC2.16] Gli elenchi di controllo degli accessi alla rete non utilizzati devono essere rimossi
-
[EC2.17] EC2 Le istanze Amazon non devono utilizzare più istanze ENIs
-
[EC2.19] I gruppi di sicurezza non devono consentire l'accesso illimitato alle porte ad alto rischio
-
[EC2.20] Entrambi i tunnel VPN per una connessione AWS Site-to-Site VPN dovrebbero essere attivi
-
[EC2.22] I gruppi di EC2 sicurezza Amazon non utilizzati devono essere rimossi
-
[EC2.25] I modelli di EC2 lancio di Amazon non devono assegnare interfacce IPs di rete pubbliche
-
[ECR.1] Gli archivi privati ECR devono avere la scansione delle immagini configurata
-
[ECR.2] I repository privati ECR devono avere l'immutabilità dei tag configurata
-
[ECR.3] I repository ECR devono avere almeno una politica del ciclo di vita configurata
-
[ECS.2] Ai servizi ECS non devono essere assegnati automaticamente indirizzi IP pubblici
-
[ECS.4] I contenitori ECS devono essere eseguiti come non privilegiati
-
[ECS.5] I contenitori ECS devono essere limitati all'accesso in sola lettura ai filesystem root
-
[ECS.8] I segreti non devono essere passati come variabili di ambiente del contenitore
-
[EFS.2] I volumi Amazon EFS devono essere inclusi nei piani di backup
-
[EFS.3] I punti di accesso EFS devono applicare una directory principale
-
[EFS.4] I punti di accesso EFS devono applicare un'identità utente
-
[EKS.1] Gli endpoint del cluster EKS non dovrebbero essere accessibili al pubblico
-
[EKS.2] I cluster EKS devono essere eseguiti su una versione Kubernetes supportata
-
[ElastiCache.3] i gruppi di ElastiCache replica devono avere il failover automatico abilitato
-
[ElastiCache.4] i gruppi di ElastiCache replica devono essere crittografati quando sono inattivi
-
[ElastiCache.5] i gruppi di ElastiCache replica devono essere crittografati in transito
-
[ELB.3] I listener Classic Load Balancer devono essere configurati con terminazione HTTPS o TLS
-
[ELB.7] I Classic Load Balancer devono avere il drenaggio della connessione abilitato
-
[ELB.9] I Classic Load Balancer devono avere il bilanciamento del carico tra zone abilitato
-
[ELB.10] Classic Load Balancer dovrebbe estendersi su più zone di disponibilità
-
[EMR.1] I nodi primari del cluster Amazon EMR non devono avere indirizzi IP pubblici
-
[ES.1] I domini Elasticsearch devono avere la crittografia a riposo abilitata
-
[ES.2] I domini Elasticsearch non devono essere accessibili al pubblico
-
[ES.3] I domini Elasticsearch devono crittografare i dati inviati tra i nodi
-
[ES.5] I domini Elasticsearch devono avere la registrazione di controllo abilitata
-
[ES.6] I domini Elasticsearch devono avere almeno tre nodi di dati
-
[ES.7] I domini Elasticsearch devono essere configurati con almeno tre nodi master dedicati
-
[IAM.1] Le politiche IAM non dovrebbero consentire privilegi amministrativi «*» completi
-
[IAM.3] Le chiavi di accesso degli utenti IAM devono essere ruotate ogni 90 giorni o meno
-
[IAM.4] La chiave di accesso utente root IAM non dovrebbe esistere
-
[IAM.6] L'autenticazione MFA per l'hardware deve essere abilitata per l'utente root
-
[IAM.8] Le credenziali utente IAM non utilizzate devono essere rimosse
-
[Kinesis.1] Gli stream Kinesis devono essere crittografati quando sono inattivi
-
[KMS.3] AWS KMS keys non deve essere eliminato involontariamente
-
[KMS.4] la rotazione dei tasti dovrebbe essere abilitata AWS KMS
-
[Lambda.1] Le politiche delle funzioni Lambda dovrebbero vietare l'accesso pubblico
-
[Lambda.2] Le funzioni Lambda devono utilizzare runtime supportati
-
[Lambda.5] Le funzioni VPC Lambda devono funzionare in più zone di disponibilità
-
[MSK.1] I cluster MSK devono essere crittografati durante il transito tra i nodi del broker
-
[MQ.5] I broker ActiveMQ devono utilizzare la modalità di distribuzione attiva/standby
-
[MQ.6] I broker RabbitMQ dovrebbero utilizzare la modalità di distribuzione del cluster
-
[Neptune.1] I cluster Neptune DB devono essere crittografati a riposo
-
[Neptune.2] I cluster Neptune DB devono pubblicare i log di controllo su Logs CloudWatch
-
[Neptune.3] Le istantanee del cluster Neptune DB non devono essere pubbliche
-
[Neptune.4] I cluster Neptune DB devono avere la protezione da eliminazione abilitata
-
[Neptune.5] I cluster Neptune DB devono avere i backup automatici abilitati
-
[Neptune.6] Le istantanee del cluster Neptune DB devono essere crittografate quando sono inattive
-
[Neptune.7] I cluster Neptune DB devono avere l'autenticazione del database IAM abilitata
-
[Neptune.8] I cluster Neptune DB devono essere configurati per copiare i tag nelle istantanee
-
[NetworkFirewall.3] Le policy di Network Firewall devono avere almeno un gruppo di regole associato
-
[NetworkFirewall.6] Il gruppo di regole Stateless Network Firewall non deve essere vuoto
-
I OpenSearch domini [Opensearch.1] devono avere la crittografia a riposo abilitata
-
I OpenSearch domini [Opensearch.2] non devono essere accessibili al pubblico
-
I OpenSearch domini [Opensearch.3] devono crittografare i dati inviati tra i nodi
-
I OpenSearch domini [Opensearch.5] devono avere la registrazione di controllo abilitata
-
I OpenSearch domini [Opensearch.6] devono avere almeno tre nodi di dati
-
I OpenSearch domini [Opensearch.7] devono avere un controllo degli accessi granulare abilitato
-
[RDS.3] Le istanze database RDS devono avere la crittografia dei dati inattivi abilitata
-
[RDS.5] Le istanze DB RDS devono essere configurate con più zone di disponibilità
-
[RDS.6] Il monitoraggio avanzato deve essere configurato per le istanze DB RDS
-
[RDS.8] Le istanze DB RDS devono avere la protezione da eliminazione abilitata
-
[RDS.9] Le istanze DB RDS devono pubblicare i log nei registri CloudWatch
-
[RDS.10] L'autenticazione IAM deve essere configurata per le istanze RDS
-
[RDS.11] Le istanze RDS devono avere i backup automatici abilitati
-
[RDS.12] L'autenticazione IAM deve essere configurata per i cluster RDS
-
[RDS.13] Gli aggiornamenti automatici delle versioni secondarie di RDS devono essere abilitati
-
[RDS.15] I cluster RDS DB devono essere configurati per più zone di disponibilità
-
[RDS.17] Le istanze DB RDS devono essere configurate per copiare i tag nelle istantanee
-
[RDS.23] Le istanze RDS non devono utilizzare una porta predefinita del motore di database
-
[RDS.25] Le istanze del database RDS devono utilizzare un nome utente amministratore personalizzato
-
[RDS.27] I cluster RDS DB devono essere crittografati quando sono inattivi
-
[Redshift.1] I cluster Amazon Redshift dovrebbero vietare l'accesso pubblico
-
[Redshift.2] Le connessioni ai cluster Amazon Redshift devono essere crittografate in transito
-
[Redshift.4] I cluster Amazon Redshift devono avere la registrazione di controllo abilitata
-
[Redshift.7] I cluster Redshift devono utilizzare un routing VPC avanzato
-
[Redshift.9] I cluster Redshift non devono utilizzare il nome di database predefinito
-
[Redshift.10] I cluster Redshift devono essere crittografati a riposo
-
[S3.1] I bucket generici S3 devono avere le impostazioni di blocco dell'accesso pubblico abilitate
-
[S3.2] I bucket S3 per uso generico dovrebbero bloccare l'accesso pubblico in lettura
-
[S3.3] I bucket generici S3 dovrebbero bloccare l'accesso pubblico in scrittura
-
[S3.5] I bucket S3 per uso generico devono richiedere l'utilizzo di SSL
-
[S3.8] I bucket generici S3 dovrebbero bloccare l'accesso pubblico
-
[S3.9] I bucket generici S3 devono avere la registrazione degli accessi al server abilitata
-
[S3.12] non ACLs deve essere usato per gestire l'accesso degli utenti ai bucket generici S3
-
[S3.13] I bucket generici S3 devono avere configurazioni del ciclo di vita
-
[S3.17] I bucket generici S3 devono essere crittografati quando sono inattivi con AWS KMS keys
-
[SageMaker.1] Le istanze di notebook Amazon SageMaker AI non devono avere accesso diretto a Internet
-
[SageMaker.2] Le istanze di notebook SageMaker AI devono essere avviate in un VPC personalizzato
-
[SageMaker.3] Gli utenti non devono avere accesso root alle istanze di notebook SageMaker AI
-
[SecretsManager.1] I segreti di Secrets Manager devono avere la rotazione automatica abilitata
-
[SecretsManager.3] Rimuovi i segreti inutilizzati di Secrets Manager
-
[SQS.1] Le code di Amazon SQS devono essere crittografate quando sono inattive
-
[SSM.1] Le EC2 istanze Amazon devono essere gestite da AWS Systems Manager
-
[WAF.2] Le regole regionali AWS WAF classiche devono avere almeno una condizione
-
[WAF.3] I gruppi di regole regionali AWS WAF classici dovrebbero avere almeno una regola
-
[WAF.10] AWS WAF web ACLs dovrebbe avere almeno una regola o un gruppo di regole
Per ulteriori informazioni su questo standard, consulta i controlli del Security Hub nella Guida AWS Control Tower per l'utente.