SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro - Framework AWS Well-Architected
Guida all'implementazioneRisorse

SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro

Un carico di lavoro richiede una capacità automatizzata di dimostrare la propria identità a database, risorse e servizi di terze parti. A tal fine si utilizzano credenziali di accesso segrete, come chiavi di accesso API, password e token OAuth. L'utilizzo di un servizio appositamente creato per archiviare, gestire e ruotare queste credenziali aiuta a ridurre la probabilità che queste vengano compromesse.

Risultato desiderato: implementare un meccanismo per la gestione sicura delle credenziali delle applicazioni che raggiunga i seguenti obiettivi:

  • Identificare i segreti necessari per il carico di lavoro.

  • Ridurre il numero di credenziali a lungo termine sostituendole con credenziali a breve termine, quando possibile.

  • Stabilire l'archiviazione sicura e la rotazione automatica delle rimanenti credenziali a lungo termine.

  • Sottoporre a audit l'accesso ai segreti esistenti nel carico di lavoro.

  • Eseguire il monitoraggio continuo per verificare che nessun segreto sia incorporato nel codice sorgente durante il processo di sviluppo.

  • Ridurre la probabilità che le credenziali vengano divulgate inavvertitamente.

Anti-pattern comuni:

  • Nessuna rotazione delle credenziali.

  • Memorizzazione di credenziali a lungo termine nel codice sorgente o nei file di configurazione.

  • Memorizzazione delle credenziali a riposo non criptate.

Vantaggi dell'adozione di questa best practice:

  • I segreti sono conservati in modo criptato a riposo e in transito.

  • L'accesso alle credenziali è regolato da un'API (si pensi a un distributore automatico di credenziali).

  • L'accesso a una credenziale (sia in lettura che in scrittura) viene sottoposto a audit e registrato.

  • Separazione delle preoccupazioni: la rotazione delle credenziali viene eseguita da un componente distinto, che può essere separato dal resto dell'architettura.

  • I segreti vengono distribuiti automaticamente su richiesta ai componenti software e la rotazione avviene in una posizione centrale.

  • L'accesso alle credenziali può essere controllato in modo granulare.

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

Guida all'implementazione

In passato, le credenziali utilizzate per l'autenticazione ai database, alle API di terze parti, ai token e ad altri segreti potevano essere incorporate nel codice sorgente o nei file di ambiente. AWS fornisce diversi meccanismi per memorizzare queste credenziali in modo sicuro, ruotarle automaticamente e sottoporre a audit il loro utilizzo.

Il modo migliore per affrontare la gestione dei segreti è seguire le indicazioni di rimuovere, sostituire e ruotare. La credenziale più sicura è quella che non si deve memorizzare, gestire o trattare. Possono esserci credenziali che non sono più necessarie per il funzionamento del carico di lavoro e che possono essere rimosse in modo sicuro.

Per le credenziali che sono ancora necessarie per il corretto funzionamento del carico di lavoro, potrebbe esserci l'opportunità di sostituire una credenziale a lungo termine con una credenziale temporanea o a breve termine. Ad esempio, invece di una codifica fissa di una chiave di accesso segreta AWS, si può pensare di sostituire la credenziale a lungo termine con una credenziale temporanea utilizzando i ruoli IAM.

Alcuni segreti di lunga durata potrebbero non poter essere rimossi o sostituiti. Questi segreti possono essere memorizzati in un servizio come AWS Secrets Manager, dove possono essere archiviati, gestiti e ruotati regolarmente a livello centrale.

Un audit del codice sorgente e dei file di configurazione del carico di lavoro può rivelare molti tipi di credenziali. La tabella seguente riassume le strategie per gestire i tipi più comuni di credenziali:

Credential type Description Suggested strategy
IAM access keys AWS IAM access and secret keys used to assume IAM roles inside of a workload Replace: Use Ruoli IAM assigned to the compute instances (such as Amazon EC2 or AWS Lambda) instead. For interoperability with third parties that require access to resources in your Account AWS, ask if they support AWS cross-account access (Accesso multi-account AWS). For mobile apps, consider using temporary credentials through Pool di identità di Amazon Cognito (identità federate). For workloads running outside of AWS, consider IAM Roles Anywhere or Attivazioni ibride AWS Systems Manager.
SSH keys Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process Replace: Use AWS Systems Manager or EC2 Instance Connect to provide programmatic and human access to EC2 instances using IAM roles.
Application and database credentials Passwords – plain text string Rotate: Store credentials in AWS Secrets Manager and establish automated rotation if possible.
Amazon RDS and Aurora Admin Database credentials Passwords – plain text string Replace: Use the Secrets Manager integration with Amazon RDS (Integrazione di Secrets Manager con Amazon RDS) or Amazon Aurora. In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see IAM database authentication (Autenticazione del database IAM)).
OAuth tokens Secret tokens – plain text string Rotate: Store tokens in AWS Secrets Manager and configure automated rotation.
API tokens and keys Secret tokens – plain text string Rotate: Store in AWS Secrets Manager and establish automated rotation if possible.

Un anti-pattern comune è quello di incorporare le chiavi di accesso IAM all'interno del codice sorgente, dei file di configurazione o delle applicazioni mobili. Quando è richiesta una chiave di accesso IAM per comunicare con un servizio AWS, utilizza le credenziali di sicurezza temporanee (a breve termine). Queste credenziali a breve termine possono essere fornite attraverso ruoli IAM per istanze EC2, ruoli di esecuzione per funzioni Lambda, ruoli Cognito IAM per l'accesso degli utenti di dispositivi mobili e policy IoT Core per i dispositivi IoT. Quando ci si interfaccia con terze parti, è preferibile delegare l'accesso a un ruolo IAM con l'accesso necessario alle risorse del proprio account, piuttosto che configurare un utente IAM e inviare alla terza parte la chiave di accesso segreta per quell'utente.

In molti casi il carico di lavoro richiede la memorizzazione di segreti necessari per l'interoperabilità con altri servizi e risorse. AWS Secrets Manager è costruito appositamente per gestire in modo sicuro queste credenziali, nonché l'archiviazione, l'uso e la rotazione di token API, password e altre credenziali.

AWS Secrets Manager fornisce cinque funzionalità chiave per garantire l'archiviazione e la gestione sicura delle credenziali sensibili: crittografia a riposo, crittografia in transito, audit completo, controllo degli accessi granulare e rotazione estensibile delle credenziali. Sono accettabili anche altri servizi di gestione dei segreti dei partner AWS o soluzioni sviluppate localmente che forniscano funzionalità e garanzie simili.

Passaggi dell'implementazione

  1. Individuare i percorsi di codice contenenti credenziali hard-coded utilizzando strumenti automatizzati come Amazon CodeGuru.

    • Utilizzare Amazon CodeGuru per eseguire la scansione dei repository di codice. Una volta completata la revisione, filtrare Type=Secrets in CodeGuru per trovare le linee di codice problematiche.

  2. Identificare le credenziali che possono essere rimosse o sostituite.

    1. Identificare le credenziali non più necessarie e contrassegnarle per la rimozione.

    2. Le chiavi segrete AWS incorporate nel codice sorgente devono essere sostituite con ruoli IAM associati alle risorse necessarie. Se una parte del carico di lavoro è al di fuori di AWS ma richiede le credenziali IAM per accedere alle risorse AWS, considerare IAM Roles Anywhere o Attivazioni ibride AWS Systems Manager.

  3. Per altri segreti di terze parti a lunga durata che richiedono l'uso della strategia di rotazione, integrare Secrets Manager nel codice per recuperare i segreti di terze parti in fase di esecuzione.

    1. La console CodeGuru può creare un segreto in Secrets Manager automaticamente utilizzando le credenziali individuate.

    2. Integrare il recupero dei segreti da Secrets Manager nel codice dell'applicazione.

  4. Esaminare periodicamente la base di codice e ripetere la scansione per verificare che non siano stati aggiunti nuovi segreti al codice.

    • Valutare l'utilizzo di uno strumento come git-secrets per impedire il commit di nuovi segreti nel repository del codice sorgente.

  5. Monitorare l'attività di Secrets Manager per rilevare indicazioni di utilizzo inatteso, accesso inappropriato ai segreti o tentativi di cancellazione dei segreti.

  6. Ridurre l'esposizione umana alle credenziali. Limitare l'accesso alle credenziali di lettura, scrittura e modifica a un ruolo IAM dedicato a questo scopo e fornire l'accesso per assumere il ruolo solo a un piccolo sottoinsieme di utenti operativi.

Risorse

Best practice correlate:

Documenti correlati:

Video correlati:

Workshop correlati: