SEC05-BP01 Creazione di livelli di rete - Framework AWS Well-Architected

SEC05-BP01 Creazione di livelli di rete

Segmenta la topologia di rete in diversi livelli basati su raggruppamenti logici dei componenti del carico di lavoro in base alla sensibilità dei dati e ai requisiti di accesso. Distingui tra i componenti che richiedono l'accesso in entrata da Internet, come gli endpoint Web pubblici, e quelli che necessitano solo di un accesso interno, come i database.

Risultato desiderato: i livelli della tua rete sono parte di un approccio completo di difesa stratificata alla sicurezza che completa la strategia di autenticazione e autorizzazione dell'identità dei tuoi carichi di lavoro. I livelli sono implementati in base alla sensibilità dei dati e ai requisiti di accesso, con meccanismi appropriati di flusso e controllo del traffico.

Anti-pattern comuni:

  • Creazione di tutte le risorse in un VPC o una sottorete unica.

  • Costruzione dei livelli di rete senza considerare i requisiti di sensibilità dei dati, il comportamento dei componenti o la loro funzionalità.

  • Utilizzo di VPC e sottoreti come impostazioni predefinite per tutte le considerazioni relative al livello di rete senza considerare come i servizi gestiti da AWS influenzino la tua topologia.

Vantaggi della definizione di questa best practice: stabilire i livelli di rete è il primo passo per limitare i percorsi non necessari attraverso la rete, in particolare quelli che conducono ai sistemi e ai dati critici. In tal modo gli attori non autorizzati avranno più difficoltà ad accedere alla rete e a navigare verso altre risorse al suo interno. I livelli di rete discreti riducono l'ambito di analisi dei sistemi di ispezione, ad esempio per il rilevamento delle intrusioni o la prevenzione del malware. Di conseguenza, si riduce il potenziale di falsi positivi e il sovraccarico di elaborazione non necessario.

Livello di rischio associato se questa best practice non fosse adottata: elevato

Guida all'implementazione

Quando si progetta l'architettura di un carico di lavoro, è comune separare i componenti in diversi livelli in base alle rispettive responsabilità. Ad esempio, un'applicazione Web può avere un livello di presentazione, un livello di applicazione e un livello di dati. È possibile adottare un approccio simile quando si progetta la topologia di rete. I controlli di rete sottostanti possono contribuire a far rispettare i requisiti di accesso ai dati del carico di lavoro. Ad esempio, in un'architettura di applicazioni Web a tre livelli, puoi archiviare i file statici del livello di presentazione in Amazon S3 e servirli da una rete di distribuzione di contenuti (CDN), ad esempio Amazon CloudFront. Il livello applicativo può avere endpoint pubblici che un Application Load Balancer (ALB) serve in una sottorete Amazon VPC pubblica (simile a una zona demilitarizzata o DMZ), con servizi di back-end distribuiti in sottoreti private. Il livello dati che ospita risorse come database e file system condivisi può risiedere in sottoreti private diverse dalle risorse del livello applicativo. In corrispondenza di ciascuno di questi limiti di livello (CDN, sottorete pubblica, sottorete privata), è possibile implementare controlli che consentano solo al traffico autorizzato di attraversarli.

Analogamente alla modellazione dei livelli di rete in base allo scopo funzionale dei componenti del carico di lavoro, è necessario considerare anche la sensibilità dei dati elaborati. Utilizzando l'esempio dell'applicazione Web, mentre tutti i servizi del carico di lavoro possono risiedere all'interno del livello dell'applicazione, servizi diversi possono elaborare dati con livelli di sensibilità differenti. In questo caso, la divisione del livello dell'applicazione utilizzando più sottoreti private, diversi VPC nello stesso Account AWS o persino VPC diversi in diversi Account AWS per ogni livello di sensibilità dei dati può essere appropriata in base ai requisiti di controllo.

Un'ulteriore considerazione per i livelli di rete è la coerenza del comportamento dei componenti del carico di lavoro. Continuando l'esempio, nel livello dell'applicazione possono essere presenti servizi che accettano input dagli utenti finali o integrazioni di sistemi esterni che sono intrinsecamente più rischiosi rispetto agli input di altri servizi. A titolo di esempio, si possono citare il caricamento di file, l'esecuzione di script di codice, la scansione di e-mail e così via. La collocazione di questi servizi nel proprio livello di rete contribuisce a creare un limite di isolamento più forte attorno ad essi e può evitare che il loro comportamento unico crei falsi allarmi positivi nei sistemi di ispezione.

Come parte della progettazione, considera in che modo l'utilizzo dei servizi AWS gestiti influenza la topologia di rete. Scopri come servizi come Amazon VPC Lattice possono contribuire a semplificare l'interoperabilità dei componenti del carico di lavoro tra i livelli di rete. Durante l'utilizzo di AWS Lambda, esegui l'implementazione nelle sottoreti VPC a meno che non vi siano motivi specifici per non farlo. Determina dove si trovano gli endpoint VPC e AWS PrivateLink può semplificare l'adesione alle policy di sicurezza che limitano l'accesso ai gateway Internet.

Passaggi dell'implementazione

  1. Rivedi l'architettura del carico di lavoro. Raggruppa logicamente componenti e servizi in base alle funzioni che svolgono, alla sensibilità dei dati elaborati e al loro comportamento.

  2. Per i componenti che rispondono alle richieste provenienti da Internet, prendi in considerazione l'utilizzo di bilanciatori del carico o altri proxy per fornire endpoint pubblici. Esplora lo spostamento dei controlli di sicurezza utilizzando servizi gestiti, come CloudFront, Amazon API Gateway, Elastic Load Balancing e AWS Amplify per ospitare endpoint pubblici.

  3. Per i componenti in esecuzione in ambienti di elaborazione, come istanze Amazon EC2, container AWS Fargate o funzioni Lambda, distribuiscili in sottoreti private in base ai tuoi gruppi sin dal primo passaggio.

  4. Per i servizi AWS completamente gestiti, come Amazon DynamoDB, Amazon Kinesis o Amazon SQS, prendi in considerazione l'utilizzo di endpoint VPC come impostazione predefinita per l'accesso tramite indirizzi IP privati.

Risorse

Best practice correlate:

Video correlati:

Esempi correlati: