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à.
Best practice di sicurezza per Amazon SQS
AWS offre molte funzionalità di sicurezza per Amazon SQS, che dovresti esaminare nel contesto della tua politica di sicurezza. Di seguito sono riportate le best practice di prevenzione per la sicurezza per Amazon SQS.
Nota
Le linee guida specifiche per l'implementazione fornite sono per i casi d'uso e le implementazioni comuni. Si consiglia di visualizzare best practice nel contesto del caso d'uso specifico, dell'architettura e del modello di minaccia.
Argomenti
- Assicurarsi che le code non siano accessibili pubblicamente
- Implementazione dell'accesso con privilegi minimi
- Usa i ruoli IAM per applicazioni e AWS servizi che richiedono l'accesso ad Amazon SQS
- Implementare la crittografia lato server
- Applica la crittografia dei dati in transito
- Prendere in considerazione l'utilizzo di endpoint VPC per accedere a Amazon SQS
Assicurarsi che le code non siano accessibili pubblicamente
A meno che tu non richieda esplicitamente a chiunque su Internet di essere in grado di leggere o scrivere nella tua coda Amazon SQS, devi assicurarti che la coda non sia accessibile al pubblico (accessibile da tutti nel mondo o da qualsiasi utente autenticato). AWS
-
Evitare di creare policy con
Principal
impostato su""
. -
Evitare di utilizzare un carattere jolly (
*
). Assegnare invece un nome a uno o più utenti specifici.
Implementazione dell'accesso con privilegi minimi
Quando si concedono autorizzazioni, si decide chi le riceve, per quali code sono le autorizzazioni e operazioni API specifiche che si desidera consentire per queste code. Implementare privilegi minimi è importante per ridurre i rischi per la sicurezza e ridurre l'effetto di errori o intenti dannosi.
Seguire i consigli di sicurezza standard relativi alla concessione dei privilegi minimi. Cioè, concedere solo le autorizzazioni necessarie per eseguire un'attività specifica. È possibile effettuare questa implementazione utilizzando una combinazione di policy di sicurezza.
Amazon SQS utilizza il modello produttore-consumatore, che richiede tre tipi di accesso all'account utente:
-
Amministratori: accesso alla creazione, alla modifica e all'eliminazione di code. Gli amministratori controllano anche le policy della coda.
-
Produttori: accesso all'invio di messaggi alle code.
-
Consumatori: accesso alla ricezione e all'eliminazione di messaggi dalle code.
Per ulteriori informazioni, consulta le sezioni seguenti:
Usa i ruoli IAM per applicazioni e AWS servizi che richiedono l'accesso ad Amazon SQS
Affinché applicazioni o AWS servizi come Amazon EC2 possano accedere alle code di Amazon SQS, devono utilizzare credenziali AWS valide nelle richieste API. AWS Poiché queste credenziali non vengono ruotate automaticamente, non è necessario archiviare AWS le credenziali direttamente nell'applicazione o nell'istanza EC2.
È preferibile usare un ruolo IAM per gestire credenziali provvisorie per le applicazioni o i servizi che devono accedere ad Amazon SQS. Quando utilizzi un ruolo, non devi distribuire credenziali a lungo termine (come nome utente, password e chiavi di accesso) a un'istanza o servizio EC2 come. AWS AWS Lambda Al contrario, il ruolo fornisce autorizzazioni temporanee che le applicazioni possono utilizzare quando effettuano chiamate ad altre risorse. AWS
Per ulteriori informazioni, consultaRuoli IAM e Scenari comuni per ruoli: utenti, applicazioni e servizi nella Guida per l'utente IAM.
Implementare la crittografia lato server
Per attenuare i problemi di perdita di dati, utilizzare la crittografia dei dati inattivi per crittografare i messaggi utilizzando una chiave memorizzata in un percorso diverso da quello in cui vengono archiviati i messaggi. La crittografia lato server (SSE) fornisce la crittografia dei dati inattivi. Amazon SQS esegue la crittografia dei dati a livello di messaggio quando li memorizza e decrittografa i messaggi per l'utente quando vi accede. SSE utilizza chiavi gestite in. AWS Key Management Service Finché si autentica la richiesta e si dispone delle autorizzazioni di accesso, non vi è alcuna differenza tra l'accesso alle code crittografate e non crittografate.
Per ulteriori informazioni, consulta Crittografia inattiva in Amazon SQS e Gestione delle SQS chiavi Amazon.
Applica la crittografia dei dati in transito
Senza HTTPS (TLS), un utente malintenzionato basato sulla rete può intercettare il traffico di rete o manipolarlo, utilizzando un attacco come. man-in-the-middle Consenti solo connessioni crittografate tramite HTTPS (TLS) utilizzando la condizioneaws:SecureTransport
nella policy della coda per forzare le richieste a utilizzare SSL.
Prendere in considerazione l'utilizzo di endpoint VPC per accedere a Amazon SQS
Se si dispone di code con cui è necessario essere in grado di interagire ma che non devono assolutamente essere esposte a Internet, utilizzare gli endpoint VPC per accodare l'accesso solo agli host all'interno di un determinato VPC. È possibile utilizzare le policy della coda per controllare l'accesso alle code da endpoint Amazon VPC specifici o da VPC specifici.
Gli endpoint VPC di Amazon SQS offrono due modi per controllare l'accesso ai messaggi:
-
È possibile controllare le richieste, gli utenti o i gruppi autorizzati tramite un endpoint VPC specifico.
-
È possibile controllare quali VPC o endpoint VPC hanno accesso alla coda utilizzando una policy della coda.
Per ulteriori informazioni, consultare Endpoint Amazon Virtual Private Cloud per Amazon SQS e Creazione di una policy VPC sugli endpoint Amazon per Amazon SQS.