SEC09-BP03 Autenticazione delle comunicazioni di rete - Pilastro della sicurezza
Guida all'implementazioneRisorse

SEC09-BP03 Autenticazione delle comunicazioni di rete

Verifica l'identità delle comunicazioni utilizzando protocolli che supportano l'autenticazione, ad esempio Transport Layer Security (TLS) o IPsec.

Progetta il carico di lavoro in modo da utilizzare protocolli di rete sicuri e autenticati per le comunicazioni tra servizi, applicazioni o utenti. L'utilizzo di protocolli di rete che supportano autenticazione e autorizzazione offre un controllo più rigido sui flussi di rete e riduce l'impatto di eventuali accessi non autorizzati.

Risultato desiderato: un carico di lavoro con un piano dati ben definito e flussi di traffico del piano di controllo (control-plane) tra i servizi. I flussi di traffico utilizzano protocolli di rete autenticati e crittografati laddove tecnicamente fattibile.

Anti-pattern comuni:

  • Flussi di traffico non crittografati o non autenticati all'interno del carico di lavoro.

  • Riutilizzo delle credenziali di autenticazione tra più utenti o entità.

  • Uso esclusivo di controlli di rete come meccanismo di controllo degli accessi.

  • Creazione di un meccanismo di autenticazione personalizzato anziché usare meccanismi di autenticazione standard del settore.

  • Flussi di traffico eccessivamente permissivi tra i componenti del servizio o altre risorse nel VPC.

Vantaggi dell'adozione di questa best practice:

  • Limita l'ambito dell'impatto di eventuali accessi non autorizzati a una parte del carico di lavoro.

  • Fornisce un livello maggiore di sicurezza affinché solo entità autenticate eseguano le azioni.

  • Migliora il disaccoppiamento dei servizi definendo e applicando in modo chiaro le interfacce di trasferimento dei dati previste.

  • Migliora monitoraggio, creazione di log e risposta agli incidenti tramite l'attribuzione di richieste e interfacce di comunicazione ben definite.

  • Fornisce una difesa approfondita ai carichi di lavoro combinando i controlli di rete con quelli di autenticazione e autorizzazione.

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

Guida all'implementazione

È possibile suddividere i modelli di traffico di rete del tuo carico di lavoro in due categorie:

  • Il traffico est-ovest corrisponde ai flussi di traffico tra i servizi facenti parte di un carico di lavoro.

  • Il traffico nord-sud rappresenta i flussi di traffico tra carico di lavoro e consumatori.

Sebbene crittografare il traffico nord-sud sia la prassi comune, proteggere il traffico est-ovest mediante protocolli autenticati non è così frequente. Le moderne best practice di sicurezza raccomandano che la progettazione della rete non sia l'unico elemento in grado di garantire una relazione affidabile tra due entità. Quando due servizi possono trovarsi all'interno di una rete comune, è comunque consigliabile crittografare, autenticare e autorizzare le comunicazioni tra tali servizi.

Ad esempio, le API del servizio AWS utilizzano il protocollo di firma AWSSignature Version 4 (SIGv4) per autenticare il chiamante, indipendentemente dalla rete di provenienza della richiesta. Questa autenticazione garantisce che le API di AWS possano verificare l'identità che ha richiesto l'azione e che tale identità possa quindi essere combinata con le policy per decidere se autorizzare o meno l'azione.

Servizi come Amazon VPC Lattice e Gateway Amazon API consentono di utilizzare lo stesso protocollo di firma SigV4 per aggiungere autenticazione e autorizzazione al traffico est-ovest nei propri carichi di lavoro. Se le risorse esterne al tuo ambiente AWS devono comunicare con servizi che richiedono autenticazione e autorizzazione basate su SigV4, puoi utilizzare AWS Identity and Access Management (IAM) Roles Anywhere sulla risorsa non AWS per acquisire credenziali AWS temporanee. Queste credenziali possono essere utilizzate per firmare richieste ai servizi che utilizzano SigV4 per autorizzare l'accesso.

Un altro meccanismo comune per l'autenticazione del traffico est-ovest è l'autenticazione reciproca TLS (mTLS). Molte applicazioni Internet delle cose (IoT), business-to-business (B2B) e microservizi utilizzano mTLS per convalidare l'identità di entrambi i lati di una comunicazione TLS mediante l'uso di certificati X.509 lato client e lato server. Questi certificati possono essere emessi da AWS Private Certificate Authority (AWS Private CA). Puoi utilizzare servizi come Gateway Amazon API per garantire l'autenticazione mTLS per le comunicazioni interne ai carichi di lavoro o tra un carico di lavoro e un altro. Application Load Balancer supporta mTLS anche per i carichi di lavoro interni o esterni. Sebbene fornisca informazioni di autenticazione per entrambi i lati di una comunicazione TLS, mTLS non fornisce un meccanismo di autorizzazione.

Infine, OAuth 2.0 e OpenID Connect (OIDC) sono due protocolli in genere utilizzati per controllare l'accesso ai servizi da parte degli utenti, ma stanno diventando sempre più diffusi anche per il traffico da servizio a servizio. API Gateway fornisce un sistema di autorizzazione JSON Web token (JWT), che consente ai carichi di lavoro di limitare l'accesso ai percorsi API utilizzando JWT emessi da gestori dell'identità digitale OIDC o OAuth 2.0. È possibile utilizzare gli ambiti OAuth2 come base per decisioni di autorizzazione essenziali, ma i controlli di autorizzazione vanno comunque implementati a livello di applicazione. Gli ambiti OAuth2 da soli non possono supportare requisiti di autorizzazione più complessi.

Passaggi dell'implementazione

  • Definisci e documenta i flussi di rete del carico di lavoro: il primo passo per implementare una strategia di difesa approfondita consiste nel definire i flussi di traffico del carico di lavoro.

    • Crea un diagramma del flusso di dati che definisca in modo chiaro le modalità di trasmissione dei dati tra i diversi servizi che costituiscono il carico di lavoro. Questo diagramma è il primo passo per autorizzare tali flussi nei canali di rete autenticati.

    • Nelle fasi di sviluppo e test dota il carico di lavoro di strumenti per controllare che il diagramma del flusso di dati rifletta in modo preciso il comportamento del carico di lavoro in fase di runtime.

    • Un diagramma di flusso di dati può essere utile anche quando si esegue un esercizio di modellazione delle minacce, come illustrato in SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia.

  • Stabilisci i controlli di rete: valuta le funzionalità di AWS per stabilire controlli di rete allineati ai flussi di dati. Sebbene non debbano costituire l'unico elemento di controllo della sicurezza, i confini della rete forniscono un livello nella strategia di difesa di alto profilo a protezione del carico di lavoro.

    • Utilizza i gruppi di sicurezza per stabilire, definire e limitare i flussi di dati tra le risorse.

    • Valuta l'utilizzo di AWS PrivateLink per comunicare sia con servizi AWS e di terze parti che supportano AWS PrivateLink. I dati inviati tramite un endpoint di interfaccia AWS PrivateLink rimangono all'interno della dorsale della rete AWS e non attraversano la rete Internet pubblica.

  • Implementa autenticazione e autorizzazione tra i servizi del tuo carico di lavoro: scegli il set di servizi AWS più adeguato a fornire flussi di traffico autenticati e crittografati nel tuo carico di lavoro.

  • Monitora gli accessi non autorizzati: monitora in modo continuo i canali di comunicazione non intenzionali, i tentativi di accesso dei principali non autorizzati a risorse protette e altri schemi di accesso impropri.

    • Se utilizzi VPC Lattice per la gestione dell'accesso ai tuoi servizi, prendi in considerazione l'abilitazione e il monitoraggio dei log di accesso VPC Lattice. Questi log di accesso includono informazioni sull'entità richiedente, informazioni di rete tra cui VPC di origine e destinazione e metadati della richiesta.

    • Considera l'abilitazione dei log di flusso VPC per acquisire metadati sui flussi di rete e verificare a cadenza periodica la presenza di anomalie.

    • Consulta la AWS Security Incident Response Guide e la sezione Risposta agli imprevisti del pilastro della sicurezza del Framework AWS Well-Architected per ulteriori indicazioni su pianificazione, simulazione e risposta agli incidenti di sicurezza.

Risorse

Best practice correlate:

Documenti correlati:

Video correlati:

Esempi correlati: