SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro - Pilastro della sicurezza
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: implementazione di un meccanismo per la gestione sicura delle credenziali delle applicazioni che consenta di raggiungere 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, laddove 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 è controllato tramite un'API (immaginala come un distributore automatico di credenziali).

  • L'accesso alle credenziali (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 segregato dal resto dell'architettura.

  • La distribuzione dei segreti avviene in automatico on demand ai componenti software e la rotazione avviene in una posizione centrale.

  • È possibile controllare l'accesso alle credenziali 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 in automatico e sottoporre a audit il loro utilizzo.

Il modo migliore per affrontare la gestione dei segreti è seguire le indicazioni relative a rimozione, sostituzione e rotazione. Le credenziali più sicure sono quelle che non si devono memorizzare, gestire o trattare. Possono esserci credenziali non più necessarie per il funzionamento del carico di lavoro e che possono essere rimosse in modo sicuro.

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

Alcuni segreti di lunga durata potrebbero non poter essere rimossi o sostituiti. È possibile archiviare tali segreti in un servizio come AWS Secrets Manager, dove saranno archiviati, gestiti e rotati a livello centrale su base regolare.

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:

Tipo di credenziali Descrizione Strategia suggerita
Chiavi di accesso IAM Chiavi segrete e accesso IAM AWS utilizzate per assumere ruoli IAM all'interno di un carico di lavoro Sostituzione: utilizza invece i ruoli IAM assegnati alle istanze di calcolo (come Amazon EC2 o AWS Lambda). Per l'interoperabilità con terze parti che richiedono l'accesso alle risorse del tuo Account AWS, chiedi se supportano l'accesso multi-account AWS. Per le app mobili, prendi in considerazione l'utilizzo di credenziali temporanee tramite pool di identità di Amazon Cognito (identità federate). Per i carichi di lavoro eseguiti all'esterno di AWS, valuta IAM Roles Anywhere o le attivazioni ibride di AWS Systems Manager. Per i container, consulta il ruolo IAM dell'attività di Amazon ECS o il ruolo IAM del nodo di Amazon ECS.
Chiavi SSH Chiavi private Secure Shell utilizzate per accedere alle istanze Linux EC2, manualmente o nell'ambito di un processo automatizzato Sostituzione: utilizza AWS Systems Manager o EC2 Instance Connect per fornire un accesso programmatico e umano alle istanze EC2 mediante i ruoli IAM.
Credenziali di applicazione e database Password: stringa di testo semplice Rotazione: memorizza le credenziali in AWS Secrets Manager e, laddove possibile, stabilisci una rotazione automatica.
Credenziali del database di amministrazione Aurora e Amazon RDS Password: stringa di testo semplice Sostituzione: utilizza l'integrazione di Secrets Manager con Amazon RDS o Amazon Aurora. Inoltre, alcuni tipi di database RDS possono utilizzare i ruoli IAM anziché le password per alcuni casi d'uso (per maggiori dettagli, consulta Autenticazione del database IAM).
Token OAuth Token segreti: stringa di testo semplice Rotazione: archivia i token in AWS Secrets Manager e configura la rotazione automatica.
Token e chiavi API Token segreti: stringa di testo semplice Rotazione: archivia in AWS Secrets Manager e stabilisci una rotazione automatica, laddove possibile.

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. Se occorre una chiave di accesso IAM per la comunicazione con un servizio AWS, utilizza credenziali di sicurezza temporanee (a breve termine). È possibile fornire queste credenziali a breve termine tramite ruoli IAM per le istanze EC2, ruoli di esecuzione per le funzioni Lambda, ruoli IAM di Cognito per l'accesso degli utenti mobili e policy IoT Core per i dispositivi IoT. Nell'interfacciarsi con terze parti, è preferibile delegare l'accesso a un ruolo IAM con l'accesso necessario alle risorse dell'account anziché configurare un utente IAM e inviare alla terza parte la chiave di accesso segreta per l'utente interessato.

Esistono molti casi in cui il carico di lavoro richiede l'archiviazione dei segreti necessari per l'interoperabilità con altri servizi e risorse. AWS Secrets Manager è stato creato proprio 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 offre cinque funzionalità chiave per garantire la sicurezza di archiviazione e gestione delle credenziali sensibili: crittografia a riposo, crittografia in transito, audit completi, controllo granulare degli accessi e rotazione delle credenziali estensibile. Sono accettabili anche altri servizi di gestione dei segreti dei partner AWS o soluzioni sviluppate localmente che forniscano funzionalità e garanzie simili.

Quando si recupera un segreto, è possibile utilizzare il componente di caching lato client di Secrets Manager per memorizzarlo nella cache per un uso futuro. Il recupero di un segreto memorizzato nella cache è più veloce rispetto al recupero da Secrets Manager. Inoltre, poiché la chiamata alle API di Secrets Manager ha un costo, l'uso della cache può ridurre i costi. Per una descrizione di tutti i modi in cui è possibile recuperare i segreti, consulta Ottieni segreti.

Nota

Alcune lingue possono richiedere l'implementazione di una propria crittografia in memoria per la cache lato client.

Passaggi dell'implementazione

  1. Identifica i percorsi di codice con credenziali con codifica fissa mediante strumenti automatizzati come Amazon CodeGuru.

    1. Utilizza Amazon CodeGuru per eseguire la scansione dei repository di codice. Una volta completata l'analisi, filtra su Type=Secrets in CodeGuru per trovare righe di codice problematiche.

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

    1. Identifica 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 parte del tuo carico di lavoro è al di fuori di AWS ma richiede credenziali IAM per accedere a risorse AWS, prendi in considerazione IAM Roles Anywhere o le attivazioni ibride di AWS Systems Manager.

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

    1. La console di CodeGuru può creare in automatico un segreto in Secrets Manager utilizzando le credenziali scoperte.

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

      1. Le funzioni Lambda serverless possono utilizzare un'estensione Lambda indipendente dal linguaggio.

      2. Per container o istanze EC2, AWS fornisce un esempio di codice lato client per il recupero di segreti da Secrets Manager in diversi linguaggi di programmazione diffusi.

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

    1. Prendi in considerazione l'utilizzo di uno strumento come git-secrets per evitare di inserire nuovi segreti nel tuo repository di codice sorgente.

  5. Monitora l'attività di Secrets Manager per individuare eventuali indicazioni di utilizzo imprevisto, accesso inopportuno ai segreti o tentativi di eliminazione degli stessi.

  6. Riduci l'esposizione umana alle credenziali. Limita l'accesso alle credenziali di lettura, scrittura e modifica a un ruolo IAM dedicato a questo scopo e fornisci l'accesso in modo che il ruolo sia assunto solo da un piccolo sottoinsieme di utenti operativi.

Risorse

Best practice correlate:

Documenti correlati:

Video correlati:

Workshop correlati: