SEC09-BP03 Autentica le comunicazioni di rete - Pilastro della sicurezza
Guida all'implementazioneRisorse

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

SEC09-BP03 Autentica le comunicazioni di rete

Verifica l'identità delle comunicazioni utilizzando protocolli che supportano l'autenticazione, come Transport Layer Security (TLS) oIPsec.

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

  • Gestisce defense-in-depth i carichi di lavoro combinando i controlli di rete con i controlli 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, il AWS servizio APIs utilizza il protocollo di AWS firma Signature Version 4 (SigV4) per autenticare il chiamante, indipendentemente dalla rete da cui proviene la richiesta. Questa autenticazione garantisce che sia AWS APIs possibile verificare l'identità che ha richiesto l'azione e che tale identità possa quindi essere combinata con le politiche per prendere una decisione di autorizzazione per determinare se l'azione debba essere consentita o meno.

Servizi come Amazon VPC Lattice e Amazon API Gateway 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 all' AWS ambiente devono comunicare con servizi che richiedono l'autenticazione e l'autorizzazione basate su SigV4, puoi utilizzare AWS Identity and Access Management (IAM) Roles Anywhere sulla risorsa non utilizzata per acquisire credenziali temporanee.AWS AWS 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 (m). TLS TLS Molte business-to-business applicazioni, microservizi e Internet of Things (IoT) utilizzano m TLS per convalidare l'identità di entrambi i lati di una TLS comunicazione 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 Amazon API Gateway e AWS App Meshfornire TLS l'autenticazione m per le comunicazioni tra o tra carichi di lavoro. Sebbene m TLS fornisca informazioni di autenticazione per entrambi i lati di una TLS comunicazione, non fornisce un meccanismo di autorizzazione.

Infine, OAuth 2.0 e OpenID Connect (OIDC) sono due protocolli tipicamente utilizzati per controllare l'accesso ai servizi da parte degli utenti, ma ora stanno diventando popolari anche per il service-to-service traffico. APIGateway fornisce un autorizzatore JSON Web Token (JWT), che consente ai carichi di lavoro di limitare l'accesso ai API percorsi utilizzando provider di identità JWTs emessi da OIDC o OAuth 2.0. OAuth2gli ambiti possono essere utilizzati come fonte per le decisioni di autorizzazione di base, ma i controlli di autorizzazione devono ancora essere implementati a livello di applicazione e gli OAuth2 ambiti da soli non possono supportare esigenze di autorizzazione più complesse.

Passaggi dell'implementazione

  • Definisci e documenta i flussi di rete del carico di lavoro: il primo passo nell'implementazione di una defense-in-depth strategia è 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 del flusso di dati può essere utile anche quando si esegue un esercizio di modellazione delle minacce, come descritto in SEC01-BP07 Identificare le minacce e assegnare priorità alle mitigazioni utilizzando un modello di minaccia.

  • Stabilisci i controlli di rete: valuta la possibilità di stabilire controlli di rete allineati ai AWS flussi di dati. Sebbene i confini di rete non debbano essere l'unico controllo di sicurezza, forniscono un livello di defense-in-depth strategia per proteggere il carico di lavoro.

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

    • Valuta la possibilità AWS PrivateLinkdi utilizzarlo per comunicare sia con AWS i servizi di terze parti che lo supportano AWS PrivateLink. I dati inviati tramite un endpoint di AWS PrivateLink interfaccia rimangono all'interno della spina dorsale della AWS rete e non attraversano la rete Internet pubblica.

  • Implementa l'autenticazione e l'autorizzazione tra i servizi del tuo carico di lavoro: scegli il set di AWS servizi più appropriato per 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 gestire l'accesso ai tuoi servizi, prendi in considerazione l'abilitazione e il monitoraggio dei log di accesso di VPCLattice. Questi registri di accesso includono informazioni sull'entità richiedente, informazioni di rete tra cui origine e destinazione VPC e metadati della richiesta.

    • Valuta la possibilità di abilitare i log di VPC flusso per acquisire i metadati sui flussi di rete e verificare periodicamente la presenza di anomalie.

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

Risorse

Best practice correlate:

Documenti correlati:

Video correlati:

Esempi correlati: