Sicurezza all'avanguardia - AWS Guida prescrittiva

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

Sicurezza all'avanguardia

Nel Cloud AWS, la sicurezza è la massima priorità. Man mano che le organizzazioni adottano la scalabilità e la flessibilità del cloud, le AWS aiuta ad adottare sicurezza, identità e conformità come fattori aziendali chiave. AWS integra la sicurezza nella sua infrastruttura principale e offre servizi per aiutarti a soddisfare i tuoi requisiti di sicurezza cloud unici. Quando espandi l'ambito della tua architettura in Cloud AWS, trai vantaggio dall'integrazione di infrastrutture come Local Zones e Regioni AWS Outposts in. Questa integrazione consente di AWS estendere un gruppo selezionato di servizi di sicurezza di base all'edge.

La sicurezza è una responsabilità condivisa tra te AWS e te. Il modello di responsabilitàAWS condivisa distingue tra la sicurezza del cloud e la sicurezza nel cloud:

  • Sicurezza del cloud: AWS è responsabile della protezione dell'infrastruttura che gira Servizi AWS nel Cloud AWS. AWS fornisce inoltre servizi che è possibile utilizzare in modo sicuro. I revisori esterni testano e verificano regolarmente l'efficacia della AWS sicurezza nell'ambito dei programmi di AWS conformità.

  • Sicurezza nel cloud: la tua responsabilità è determinata dal materiale Servizio AWS che utilizzi. L'utente è anche responsabile di altri fattori, tra cui la riservatezza dei dati, i requisiti dell'azienda e le leggi e le normative applicabili.

Protezione dei dati

Il modello di responsabilità AWS condivisa si applica alla protezione dei dati in AWS Outposts e Zone locali AWS. Come descritto in questo modello, AWS è responsabile della protezione dell'infrastruttura globale che gestisce il Cloud AWS (sicurezza del cloud). L'utente è responsabile del mantenimento del controllo sui contenuti ospitati su questa infrastruttura (sicurezza nel cloud). Questo contenuto include le attività di configurazione e gestione della sicurezza per Servizi AWS ciò che utilizzi.

Ai fini della protezione dei dati, ti consigliamo di proteggere Account AWS le credenziali e configurare i singoli utenti con AWS Identity and Access Management (IAM) o AWS IAM Identity Center. Ciò concede a ciascun utente solo le autorizzazioni necessarie per adempiere alle proprie mansioni lavorative.

Crittografia dei dati inattivi

Crittografia nei volumi EBS

Con AWS Outposts, tutti i dati sono crittografati quando sono inattivi. Il materiale chiave è racchiuso in una chiave esterna, la Nitro Security Key (NSK), archiviata in un dispositivo rimovibile. L'NSK è necessario per decrittografare i dati sul rack Outpost. Puoi utilizzare la crittografia Amazon EBS per i tuoi volumi EBS e gli snapshot. La crittografia Amazon EBS utilizza AWS Key Management Service (AWS KMS) e chiavi KMS.

Nel caso delle Local Zones, tutti i volumi EBS sono crittografati per impostazione predefinita in tutte le Local Zones, ad eccezione dell'elenco documentato nelle Zone locali AWS FAQ (vedi la domanda: Qual è il comportamento di crittografia predefinito dei volumi EBS nelle Local Zones? ), a meno che la crittografia non sia abilitata per l'account.

Crittografia in Amazon S3 su Outposts

Per default, tutti i dati memorizzati in Amazon S3 su Outposts vengono crittografati utilizzando la crittografia lato server con chiavi di crittografia gestite di Amazon S3 (SSE-S3). È possibile specificare la crittografia lato server con chiavi di crittografia fornite dal cliente (SSE-C). Per utilizzare SSE-C, specifica una chiave di crittografia come parte delle richieste API sull'oggetto. La crittografia lato server viene applicata solo ai dati dell'oggetto, non dei metadati dell'oggetto.

Nota

Amazon S3 on Outposts non supporta la crittografia lato server con chiavi KMS (SSE-KMS).

Crittografia in transito

Infatti AWS Outposts, il link al servizio è una connessione necessaria tra il server Outposts e la regione prescelta Regione AWS (o la regione di residenza) e consente la gestione dell'Outpost e lo scambio di traffico da e verso il. Regione AWS Il collegamento al servizio utilizza una VPN AWS gestita per comunicare con la regione d'origine. Ogni host interno AWS Outposts crea una serie di tunnel VPN per dividere il traffico del control plane e il traffico VPC. A seconda della connettività del service link (Internet o AWS Direct Connect) AWS Outposts, questi tunnel richiedono l'apertura di porte firewall affinché il service link crei l'overlay su di esso. Per informazioni tecniche dettagliate sulla sicurezza AWS Outposts e sul link di servizio, consulta Connettività tramite link di servizio e Sicurezza dell'infrastruttura AWS Outposts nella AWS Outposts documentazione.

Il collegamento al AWS Outposts servizio crea tunnel crittografati che stabiliscono la connettività del piano di controllo e del piano dati con il piano principale Regione AWS, come illustrato nel diagramma seguente.

Considerazioni su Anchor VPC.

Ogni AWS Outposts host (elaborazione e archiviazione) richiede questi tunnel crittografati su porte TCP e UDP note per comunicare con la regione madre. La tabella seguente mostra le porte e gli indirizzi di origine e destinazione per i protocolli UDP e TCP.

Protocollo

Porta di origine

Indirizzo di origine

Porta di destinazione

Indirizzo di destinazione

UDP

443

AWS Outposts link di servizio /26

443

AWS Outposts Percorsi pubblici della regione o ancoraggio VPC CIDR

TCP

1025-65535

AWS Outposts collegamento di servizio /26

443

AWS Outposts Percorsi pubblici della regione o ancoraggio VPC CIDR

Le Local Zones sono inoltre collegate alla regione madre tramite la dorsale privata globale ridondante e ad altissima larghezza di banda di Amazon. Questa connessione offre alle applicazioni in esecuzione in Local Zones un accesso rapido, sicuro e senza interruzioni ad altre Servizi AWS. Finché le Local Zones fanno parte dell'infrastruttura AWS globale, tutti i dati che fluiscono sulla rete AWS globale vengono automaticamente crittografati a livello fisico prima di lasciare le strutture AWS protette. Se hai requisiti specifici per crittografare i dati in transito tra le tue sedi locali e AWS Direct Connect PoPs per accedere a una zona locale, puoi abilitare MAC Security (MACsec) tra il router o lo switch locale e l'endpoint. AWS Direct Connect Per ulteriori informazioni, consulta il post del AWS blog Aggiungere MACsec sicurezza alle connessioni. AWS Direct Connect

Eliminazione dei dati

Quando si arresta o si termina un' EC2 istanza AWS Outposts, la memoria ad essa allocata viene cancellata (impostata su zero) dall'hypervisor prima di essere allocata a una nuova istanza e ogni blocco di storage viene reimpostato. L'eliminazione dei dati dall'hardware Outpost implica l'uso di hardware specializzato. L'NSK è un piccolo dispositivo, illustrato nella foto seguente, che si collega alla parte anteriore di ogni unità di elaborazione o archiviazione di un Outpost. È progettato per fornire un meccanismo per impedire che i dati vengano esposti dal data center o dal sito di colocation. I dati sul dispositivo Outpost sono protetti avvolgendo il materiale di codifica utilizzato per crittografare il dispositivo e archiviando il materiale avvolto su NSK. Quando restituisci un host Outpost, distruggi l'NSK girando una piccola vite sul chip che schiaccia l'NSK e distrugge fisicamente il chip. Distruggendo l'NSK, i dati del tuo Outpost vengono distrutti crittograficamente.

Dispositivo NSK in Outposts.

Gestione dell'identità e degli accessi

AWS Identity and Access Management (IAM) è un dispositivo Servizio AWS che aiuta un amministratore a controllare in modo sicuro l'accesso alle risorse. AWS Gli amministratori IAM controllano chi può essere autenticato (effettuato l'accesso) e autorizzato (disporre delle autorizzazioni) a utilizzare le risorse. AWS Outposts Se ne possiedi uno Account AWS, puoi utilizzare IAM senza costi aggiuntivi.

La tabella seguente elenca le funzionalità IAM con cui puoi utilizzare AWS Outposts.

Funzionalità IAM

AWS Outposts supporto

Policy basate su identità

Policy basate sulle risorse

Sì*

Azioni di policy

Risorse relative alle policy

Chiavi di condizione della policy (specifica del servizio)

elenchi di controllo degli accessi (ACLs)

No

Controllo degli accessi basato su attributi (ABAC) (tag nelle policy)

Credenziali temporanee

Autorizzazioni delle entità principali

Ruoli di servizio

No

Ruoli collegati ai servizi

* Oltre alle policy basate sull'identità IAM, Amazon S3 on Outposts supporta sia le policy relative ai bucket che quelle relative ai punti di accesso. Si tratta di politiche basate sulle risorse allegate alla risorsa Amazon S3 on Outposts.

Per ulteriori informazioni su come queste funzionalità sono supportate in AWS Outposts, consulta la guida per l'utente.AWS Outposts

Sicurezza dell'infrastruttura

La protezione dell'infrastruttura è una parte cruciale di un programma di sicurezza delle informazioni. Garantisce che i sistemi e i servizi di carico di lavoro siano protetti da accessi involontari e non autorizzati e da potenziali vulnerabilità. Ad esempio, si definiscono i limiti di fiducia (ad esempio, i confini della rete e degli account), la configurazione e la manutenzione della sicurezza del sistema (ad esempio, rafforzamento, riduzione al minimo e applicazione di patch), l'autenticazione e le autorizzazioni del sistema operativo (ad esempio, utenti, chiavi e livelli di accesso) e altri punti appropriati per l'applicazione delle politiche (ad esempio, firewall per applicazioni Web o gateway API).

AWS fornisce diversi approcci alla protezione dell'infrastruttura, come illustrato nelle sezioni seguenti.

Protezione delle reti

I tuoi utenti possono far parte della tua forza lavoro o dei tuoi clienti e possono trovarsi ovunque. Per questo motivo, non puoi fidarti di tutti coloro che hanno accesso alla tua rete. Quando si segue il principio dell'applicazione della sicurezza a tutti i livelli, si utilizza un approccio zero trust. Nel modello di sicurezza Zero Trust, i componenti delle applicazioni o i microservizi sono considerati discreti e nessun componente o microservizio considera attendibili gli altri componenti o microservizi. Per ottenere una sicurezza Zero Trust, segui questi consigli:

Protezione delle risorse di elaborazione

Le risorse di calcolo includono EC2 istanze, contenitori, AWS Lambda funzioni, servizi di database, dispositivi IoT e altro ancora. Ogni tipo di risorsa di elaborazione richiede un approccio diverso alla sicurezza. Tuttavia, queste risorse condividono strategie comuni da prendere in considerazione: difesa approfondita, gestione delle vulnerabilità, riduzione della superficie di attacco, automazione della configurazione e del funzionamento ed esecuzione di azioni a distanza.

Ecco una guida generale per proteggere le risorse di elaborazione per i servizi chiave:

  • Crea e gestisci un programma di gestione delle vulnerabilità. Scansiona e applica patch regolarmente a risorse come EC2 istanze, contenitori Amazon Elastic Container Service (Amazon ECS) e carichi di lavoro Amazon Elastic Kubernetes Service (Amazon EKS).

  • Automatizza la protezione dell'elaborazione. Automatizza i meccanismi di protezione dell'elaborazione, tra cui la gestione delle vulnerabilità, la riduzione della superficie di attacco e la gestione delle risorse. Questa automazione consente di risparmiare tempo da utilizzare per proteggere altri aspetti del carico di lavoro e aiuta a ridurre il rischio di errore umano.

  • Riduci la superficie di attacco. Riduci l'esposizione agli accessi involontari rafforzando i sistemi operativi e riducendo al minimo i componenti, le librerie e i servizi consumabili esternamente che utilizzi.

Inoltre, per ciascuno di essi Servizio AWS che utilizzi, consulta le raccomandazioni di sicurezza specifiche nella documentazione del servizio.

Accesso a Internet

Both AWS Outposts e Local Zones forniscono modelli architettonici che consentono ai carichi di lavoro di accedere da e verso Internet. Quando utilizzi questi modelli, considera il consumo di Internet dalla regione un'opzione praticabile solo se lo utilizzi per applicare patch, aggiornare, accedere a repository Git esterni e scenari AWS simili. Per questo modello architettonico, si applicano i concetti di ispezione centralizzata in entrata e uscita centralizzata da Internet. Questi modelli di accesso utilizzano AWS Transit Gateway gateway NAT, firewall di rete e altri componenti che risiedono in, ma sono connessi Regioni AWS, nelle Local AWS Outposts Zones tramite il percorso dati tra la regione e l'edge.

Local Zones adotta un costrutto di rete chiamato network border group, che viene utilizzato in. Regioni AWS AWS pubblicizza gli indirizzi IP pubblici di questi gruppi unici. Un gruppo di confini di rete è costituito da Availability Zones, Local Zones o Wavelength Zones. È possibile allocare in modo esplicito un pool di indirizzi IP pubblici da utilizzare in un gruppo di confini di rete. È possibile utilizzare un gruppo di confini di rete per estendere il gateway Internet alle Local Zones consentendo agli indirizzi IP elastici di essere serviti dal gruppo. Questa opzione richiede l'implementazione di altri componenti a complemento dei servizi di base disponibili in Local Zones. Questi componenti potrebbero provenire da ISVs e aiutarvi a creare livelli di ispezione nella zona locale, come descritto nel post del AWS blog Hybrid inspection architectures with. Zone locali AWS

Inoltre AWS Outposts, se desideri utilizzare il gateway locale (LGW) per raggiungere Internet dalla tua rete, devi modificare la tabella di routing personalizzata associata alla sottorete. AWS Outposts La tabella delle rotte deve avere una voce di percorso predefinita (0.0.0.0/0) che utilizza LGW come hop successivo. L'utente è responsabile dell'implementazione dei restanti controlli di sicurezza nella rete locale, comprese le difese perimetrali come firewall e sistemi di prevenzione delle intrusioni o sistemi di rilevamento delle intrusioni (IPS/IDS). Ciò è in linea con il modello di responsabilità condivisa, che divide i compiti di sicurezza tra l'utente e il provider di servizi cloud.

Accesso a Internet tramite il genitore Regione AWS

In questa opzione, i carichi di lavoro di Outpost accedono a Internet tramite il collegamento al servizio e il gateway Internet del dispositivo principale. Regione AWS Il traffico in uscita verso Internet può essere instradato attraverso il gateway NAT istanziato nel tuo VPC. Per una maggiore sicurezza del traffico in ingresso e in uscita, puoi utilizzare servizi AWS di sicurezza come AWS WAF AWS Shield, e Amazon CloudFront in the. Regione AWS

Il diagramma seguente mostra il traffico tra il carico di lavoro nell' AWS Outposts istanza e Internet che attraversa l'istanza principale. Regione AWS

Carichi di lavoro in Outpost che accedono a Internet tramite il genitore. Regione AWS

Accesso a Internet tramite la rete del data center locale

In questa opzione, i carichi di lavoro di Outpost accedono a Internet tramite il data center locale. Il traffico del carico di lavoro che accede a Internet attraversa il punto di presenza Internet locale e esce localmente. In questo caso, l'infrastruttura di sicurezza di rete del data center locale è responsabile della protezione del traffico del carico di lavoro. AWS Outposts

L'immagine seguente mostra il traffico tra un carico di lavoro nella AWS Outposts sottorete e Internet che attraversa un data center.

Carichi di lavoro in Outpost che accedono a Internet tramite una rete locale.

Governance dell'infrastruttura

Indipendentemente dal fatto che i carichi di lavoro siano distribuiti in una Regione AWS zona locale o in un avamposto, puoi utilizzarli AWS Control Tower per la governance dell'infrastruttura. AWS Control Tower offre un modo semplice per configurare e gestire un ambiente AWS multi-account, seguendo le migliori pratiche prescrittive. AWS Control Tower orchestra le funzionalità di molti altri Servizi AWS AWS Organizations AWS Service Catalog, tra cui IAM Identity Center (vedi tutti i servizi integrati) per creare una landing zone in meno di un'ora. Le risorse vengono configurate e gestite per tuo conto.

AWS Control Tower fornisce una governance unificata in tutti gli AWS ambienti, inclusi Regions, Local Zones (estensioni a bassa latenza) e Outposts (infrastruttura locale). Questo aiuta a garantire sicurezza e conformità coerenti nell'intera architettura di cloud ibrido. Per ulteriori informazioni, consulta la documentazione relativa ad AWS Control Tower.

Puoi configurare funzionalità come AWS Control Tower i guardrail per soddisfare i requisiti di residenza dei dati nei governi e nei settori regolamentati come gli istituti di servizi finanziari (). FSIs Per capire come implementare barriere per la residenza dei dati nell'edge, consulta quanto segue:

Condivisione delle risorse di Outposts

Poiché un Outpost è un'infrastruttura limitata che risiede nel tuo data center o in uno spazio di co-ubicazione, per una governance centralizzata è necessario controllare centralmente con quali account AWS Outposts vengono condivise le risorse. AWS Outposts

Con la condivisione di Outpost, i proprietari di Outpost possono condividere le proprie risorse Outposts e Outpost, inclusi i siti e le sottoreti Outpost, con altri Account AWS membri della stessa organizzazione in. AWS Organizations In qualità di proprietario di Outpost, puoi creare e gestire le risorse di Outpost da una posizione centrale e condividerle tra più risorse all'interno della tua organizzazione. Account AWS AWS Ciò consente ad altri utenti di utilizzare i siti Outpost, configurare VPCs, avviare ed eseguire istanze sull'Outpost condiviso.

Le risorse condivisibili in sono: AWS Outposts

  • Host dedicati assegnati

  • Prenotazioni della capacità

  • Pool di indirizzi IP (CoIP) di proprietà del cliente

  • Tabelle di routing del gateway locale

  • Outposts

  • Amazon S3 su Outposts

  • Siti

  • Sottoreti

Per seguire le best practice per la condivisione delle risorse Outposts in un ambiente con più account, consulta i seguenti AWS post del blog: