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. Consente di configurare i controlli proattivi di AWS Control Tower insieme ai controlli investigativi di Security Hub nel AWS Control Tower servizio.
I controlli proattivi aiutano a garantire che Account AWS mantengono la 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 del Account AWS. Abilitando controlli proattivi e investigativi per i tuoi AWS in questo ambiente, puoi migliorare il tuo livello di sicurezza nelle diverse fasi di sviluppo.
Suggerimento
Gli standard gestiti dai servizi differiscono dagli standard che AWS Security Hub gestisce. Ad esempio, è necessario creare ed eliminare uno standard gestito dal servizio di gestione. Per ulteriori informazioni, consulta Standard di gestione dei servizi in Security Hub.
Nella console Security HubAPI, è possibile visualizzare Service-Managed Standard: AWS Control Tower insieme ad altri standard di Security Hub.
Creazione dello standard
Questo standard è disponibile solo se lo crei 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 il
EnableControl
API) -
AWS CLI (esegui il
enable-control
comando)
I controlli del Security Hub sono identificati nel AWS Control Tower console come SH.ControlID
(ad esempio, SH. CodeBuild.1).
Quando crei lo standard, se non hai già abilitato Security Hub, AWS Control Tower abilita anche Security Hub per te.
Se non l'hai configurato AWS Control Tower, non puoi visualizzare o accedere a questo standard nella console Security Hub, Security Hub API o AWS CLI. Anche se lo hai configurato AWS Control Tower, non puoi visualizzare o accedere a questo standard in Security Hub senza prima averlo creato in AWS Control Tower utilizzando uno dei metodi precedenti.
Questo standard è disponibile solo in Regioni AWS dove AWS Control Tower è disponibile, incluso AWS GovCloud (US).
Abilitazione e disabilitazione dei controlli nello standard
Dopo aver creato lo standard nel AWS Control Tower console, puoi visualizzare lo standard e i relativi controlli disponibili in entrambi i servizi.
Dopo aver creato lo standard per la prima volta, non ci sono controlli che vengono 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 la
EnableControl
eDisableControl
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, disabilitando un controllo in Security Hub abilitato in AWS Control Tower provoca una deriva del controllo. Lo stato del controllo in AWS Control Tower mostra comeDrifted
. È possibile risolvere questa deriva selezionando Re-register OU nel AWS Control Tower console o disabilitando e riattivando il controllo in AWS Control Tower utilizzando uno dei metodi precedenti.
Completamento delle azioni di attivazione e disabilitazione in AWS Control Tower ti aiuta a evitare la deriva del controllo.
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 si utilizza la configurazione centrale, è possibile utilizzare solo 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, Security Hub API o AWS CLI
-
AWS Control Tower console
-
AWS Control Tower APIper visualizzare un elenco di controlli abilitati (chiama il
ListEnabledControls
API) -
AWS CLI per visualizzare un elenco dei controlli abilitati (esegui il
list-enabled-controls
comando)
Un controllo in cui è possibile disattivare AWS Control Tower ha lo stato di abilitazione Disabled
in Security Hub 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 un sistema esistente AWS Config regola collegata al 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 in AWS Control Tower disabilitando tutti i controlli applicabili utilizzando uno dei seguenti metodi:
-
AWS Control Tower console
-
AWS Control Tower API(chiama il
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. Eliminazione dello standard in AWS Control Tower lo rimuove dalla pagina Standard della console Security Hub e non è più possibile accedervi utilizzando il Security Hub API oppure 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 qualsiasi altro 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 abilita i relativi controlli, inizierai a ricevere i risultati del controllo in Security Hub. Security Hub riporta i risultati del controllo inAWS Formato dei risultati di sicurezza (ASFF). Questi sono i ASFF valori per Amazon Resource Name (ARN) di questo standard eGeneratorId
:
-
Standard ARN:
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 ricerca per Service-Managed Standard: AWS Control Tower, consulta Esempi di risultati di controllo in Security Hub.
Controlli che si applicano a Service-Managed Standard: AWS Control Tower
Standard gestito dai servizi: AWS Control Tower supporta un sottoinsieme di controlli che fanno parte di AWS Standard Foundational Security Best Practices (FSBP). Scegliete un controllo dalla tabella seguente per visualizzarne le informazioni, incluse le procedure di riparazione 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 FSBP standard. Questo elenco mostra il controllo di sicurezza indipendente dagli standard. IDs Nel AWS Control Tower console, IDs i controlli 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 REST API fasi del API gateway devono avere AWS X-Ray tracciamento abilitato
-
[APIGateway.4] Il API gateway deve essere associato a un WAF sito Web ACL
-
[APIGateway.8] Le route 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 GraphQL non APIs 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 deve essere abilitata
-
[CloudTrail.5] i CloudTrail trail devono essere integrati con Amazon Logs CloudWatch
-
[CodeBuild.3] I log CodeBuild S3 devono essere crittografati
-
[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 () devono essere crittografati quando sono inattivi DAX
-
[EC2.1] Le EBS istantanee di Amazon non devono essere ripristinabili pubblicamente
-
[EC2.3] I EBS volumi Amazon collegati devono essere crittografati quando sono inattivi
-
[EC2.4] EC2 Le istanze interrotte devono essere rimosse dopo un periodo di tempo specificato
-
[EC2.6] la registrazione VPC del flusso deve essere abilitata in tutto VPCs
-
[EC2.7] la crittografia EBS predefinita 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 VPN tunnel per un AWS La connessione da sito a sito dovrebbe essere attiva VPN
-
[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] I repository ECR privati dovrebbero avere la scansione delle immagini configurata
-
[ECR.2] I repository ECR privati devono avere configurata l'immutabilità dei tag
-
[ECR.3] I ECR repository devono avere almeno una politica del ciclo di vita configurata
-
[ECS.2] ECS ai servizi non devono essere assegnati automaticamente indirizzi IP pubblici
-
[ECS.4] ECS I contenitori devono essere eseguiti come non privilegiati
-
[ECS.5] ECS I contenitori 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] EFS I volumi Amazon devono essere inclusi nei piani di backup
-
[EFS.3] i punti di EFS accesso devono applicare una directory principale
-
[EFS.4] i punti di EFS accesso devono imporre l'identità di un utente
-
[EKS.1] gli endpoint EKS del cluster non devono essere accessibili al pubblico
-
[EKS.2] EKS i cluster devono essere eseguiti su una versione di Kubernetes supportata
-
[ElastiCache.5] I gruppi di replica ElastiCache (RedisOSS) devono essere crittografati in transito
-
[ELB.3] I listener Classic Load Balancer devono essere configurati con o terminazione HTTPS TLS
-
[ELB.4] L'Application Load Balancer deve essere configurato per eliminare le intestazioni http
-
[ELB.5] La registrazione di Application e Classic Load Balancers deve essere abilitata
-
[ELB.7] I Classic Load Balancer devono avere abilitato il drenaggio della connessione
-
[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 EMR del cluster Amazon 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] IAM le politiche non dovrebbero consentire i privilegi amministrativi completi di tipo «*»
-
[IAM.2] IAM gli utenti non dovrebbero avere politiche allegate IAM
-
[IAM.3] le chiavi di accesso IAM degli utenti devono essere ruotate ogni 90 giorni o meno
-
[IAM.4] la chiave di accesso per l'utente IAM root non dovrebbe esistere
-
[IAM.6] L'hardware MFA deve essere abilitato per l'utente root
-
[IAM.7] Le politiche in materia di password per IAM gli utenti devono avere configurazioni solide
-
[IAM.8] Le credenziali IAM utente non utilizzate devono essere rimosse
-
[Kinesis.1] Gli stream Kinesis devono essere crittografati quando sono inattivi
-
[.3] KMS AWS KMS keys non deve essere cancellato involontariamente
-
[KMS.4] AWS KMS la rotazione dei tasti dovrebbe essere abilitata
-
[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] MSK i cluster devono essere crittografati durante il transito tra i nodi 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.4] I cluster Neptune DB devono avere la protezione da eliminazione abilitata
-
[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 abilitata IAM
-
[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 RDS DB devono avere la crittografia a riposo abilitata
-
[RDS.5] Le istanze RDS DB 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 RDS DB devono avere la protezione da eliminazione abilitata
-
[RDS.9] Le istanze RDS DB devono pubblicare i log in Logs CloudWatch
-
[RDS.10] IAM l'autenticazione deve essere configurata per le istanze RDS
-
[RDS.11] RDS le istanze devono avere i backup automatici abilitati
-
[RDS.12] IAM l'autenticazione deve essere configurata per i cluster RDS
-
[RDS.13] gli aggiornamenti RDS automatici delle versioni secondarie devono essere abilitati
-
[RDS.15] I cluster RDS DB devono essere configurati per più zone di disponibilità
-
[RDS.17] Le istanze RDS DB devono essere configurate per copiare i tag nelle istantanee
-
RDSLe istanze [RDS.23] non devono utilizzare una porta predefinita del motore di database
-
[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 dovrebbero utilizzare un routing avanzato VPC
-
[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 generici S3 devono richiedere l'utilizzo di richieste 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 S3 per uso generico 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 SageMaker notebook Amazon non devono avere accesso diretto a Internet
-
[SageMaker.2] le istanze di SageMaker notebook devono essere avviate in modo personalizzato VPC
-
[SageMaker.3] Gli utenti non devono avere accesso root alle SageMaker istanze dei notebook
-
[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 SQS code di Amazon devono essere crittografate quando sono inattive
-
[SSM.1] EC2 Le istanze Amazon devono essere gestite da AWS Systems Manager
-
[WAF.2] AWS WAF Le regole regionali classiche devono avere almeno una condizione
-
[WAF.3] AWS WAF I gruppi di regole regionali classici devono avere almeno una regola
-
[WAF.10] AWS WAF il web ACLs dovrebbe avere almeno una regola o un gruppo di regole
Per ulteriori informazioni su questo standard, consulta i controlli del Security Hub nel AWS Control Tower Guida per l'utente.