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à.
Sicurezza
Quando crei sistemi sull'infrastruttura AWS, le responsabilità di sicurezza vengono condivise tra te e AWS. Questo modello di responsabilità condivisa
Ruoli IAM
I ruoli di AWS Identity and Access Management (IAM) consentono ai clienti di assegnare policy e autorizzazioni di accesso granulari a servizi e utenti sul cloud AWS. Questa soluzione crea ruoli IAM che garantiscono l'accesso alle funzioni AWS Lambda della soluzione per creare risorse regionali.
Amazon CloudFront
Questa soluzione implementa un'interfaccia utente Web ospitata in un bucket Amazon S3, distribuito da Amazon. CloudFront Per contribuire a ridurre la latenza e migliorare la sicurezza, questa soluzione include una CloudFront distribuzione con un'identità di accesso di origine, ovvero un CloudFront utente che fornisce l'accesso pubblico ai contenuti del bucket del sito Web della soluzione. Per impostazione predefinita, la CloudFront distribuzione utilizza TLS 1.2 per applicare il più alto livello di protocollo di sicurezza. Per ulteriori informazioni, consulta la sezione Limitazione dell'accesso a un'origine Amazon S3 nella CloudFront Amazon Developer Guide.
CloudFront attiva ulteriori mitigazioni di sicurezza per aggiungere intestazioni di sicurezza HTTP a ciascuna risposta del visualizzatore. Per ulteriori informazioni, consulta Aggiungere o rimuovere intestazioni HTTP nelle risposte. CloudFront
Questa soluzione utilizza il CloudFront certificato predefinito, che ha un protocollo di sicurezza minimo supportato di TLS v1.0. Per imporre l'uso di TLS v1.2 o TLS v1.3, è necessario utilizzare un certificato SSL personalizzato anziché il certificato predefinito. CloudFront Per ulteriori informazioni, consulta Come posso configurare la mia CloudFront
Gateway Amazon API
Questa soluzione implementa endpoint Amazon API Gateway ottimizzati per l'edge per fornire API RESTful per la funzionalità di test di carico utilizzando l'endpoint API Gateway predefinito anziché un dominio personalizzato. Per le API ottimizzate per l'edge che utilizzano l'endpoint predefinito, API Gateway utilizza la policy di sicurezza. TLS-1-0 Per ulteriori informazioni, consulta Working with REST API nella Amazon API Gateway Developer Guide.
Questa soluzione utilizza il certificato API Gateway predefinito, che ha un protocollo di sicurezza minimo supportato di TLS v1.0. Per imporre l'uso di TLS v1.2 o TLS v1.3, è necessario utilizzare un dominio personalizzato con un certificato SSL personalizzato anziché il certificato API Gateway predefinito. Per ulteriori informazioni, consulta Configurazione di nomi di dominio personalizzati per le API REST.
Gruppo di sicurezza AWS Fargate
Per impostazione predefinita, questa soluzione apre al pubblico la regola in uscita del gruppo di sicurezza AWS Fargate. Se desideri impedire ad AWS Fargate di inviare traffico ovunque, modifica la regola in uscita con uno specifico Classless Inter-Domain Routing (CIDR).
Questo gruppo di sicurezza include anche una regola in entrata che consente il traffico locale sulla porta 50.000 verso qualsiasi fonte appartenente allo stesso gruppo di sicurezza. Viene utilizzato per consentire ai contenitori di comunicare tra loro.
Amazon VPC
VPC: un cloud privato virtuale (VPC) basato sul servizio Amazon VPC offre una rete privata e logicamente isolata nel cloud AWS.
Puoi specificare il tuo VPC nei CloudFormation parametri AWS durante la distribuzione. Il VPC viene utilizzato esclusivamente dalle attività ECS che generano carico; la console Web e l'API non vengono distribuite all'interno di questo VPC. Se non si specifica un VPC esistente, la soluzione creerà un nuovo VPC con la configurazione di rete richiesta. Se scegli di utilizzare un VPC esistente, questo deve soddisfare i seguenti requisiti per eseguire correttamente le attività di test di carico.
Requisiti VPC
I requisiti minimi per un VPC da utilizzare con Distributed Load Testing on AWS sono elencati di seguito.
-
Il VPC deve contenere almeno due AZ
-
Il VPC deve contenere almeno due sottoreti, ciascuna in una AZ separata
-
Le sottoreti VPC possono essere pubbliche o private, ma devono utilizzare la stessa configurazione (sia pubblica che privata)
-
Il VPC deve fornire l'accesso agli endpoint per ECR, CloudWatch Logs, S3 e IoT Core.
-
Il VPC deve fornire l'accesso ai servizi oggetto dei test di carico.
Nota
Se non disponi di un VPC che soddisfi questi criteri, puoi creare rapidamente un VPC con la procedura guidata VPC. Per ulteriori informazioni, consulta la sezione Creazione di un VPC.
Le sottoreti pubbliche possono soddisfare questi requisiti includendo quanto segue:
-
Un gateway Internet collegato al VPC
-
Un percorso verso il gateway Internet (0.0.0. 0/0)
Le sottoreti private possono soddisfare questi requisiti tramite l'uso di gateway NAT o endpoint VPC, come descritto di seguito.
Opzione 1: NAT Gateway
-
Implementa un gateway NAT in ogni AZ con sottoreti private
-
Configura le tabelle di routing per indirizzare il traffico diretto a Internet (0.0.0. 0/0) tramite il NAT Gateway
Opzione 2: endpoint VPC
Crea i seguenti endpoint VPC nel tuo VPC:
-
Endpoint dell'API Amazon ECR:
com.amazonaws.<region>.ecr.api -
Endpoint Amazon ECR DKR:
com.amazonaws.<region>.ecr.dkr -
Endpoint Amazon CloudWatch Logs:
com.amazonaws.<region>.logs -
Endpoint Amazon S3 Gateway:
com.amazonaws.<region>.s3 -
Endpoint AWS IoT Core (richiesto se si utilizzano i grafici di dati in tempo reale)
com.amazonaws.<region>.iot.data
Potrebbero funzionare anche altre configurazioni VPC.
Importante
Il gruppo di sicurezza collegato a ciascuna interfaccia endpoint VPC deve consentire il traffico TCP in entrata sulla porta 443 dal gruppo di sicurezza delle attività ECS.
Configurazione del gruppo di sicurezza
Durante l'implementazione, la soluzione creerà un gruppo di sicurezza all'interno del VPC per consentire il seguente traffico con attività nel cluster ECS:
-
Tutto il traffico in uscita
-
Traffico in entrata sulla porta 50000 proveniente da altre attività dello stesso gruppo di sicurezza, per facilitare il coordinamento tra le attività dei dipendenti e quelle dei dirigenti.
Test di stress della rete
Sei responsabile dell'utilizzo di questa soluzione in base alla policy di test di Amazon EC2
Limitazione dell'accesso all'interfaccia utente pubblica
L'approccio per limitare l'accesso alla console Web dipende dall'opzione di distribuzione scelta.
Distribuzione predefinita (CloudFront + S3): per limitare l'accesso all'interfaccia utente pubblica oltre ai meccanismi di autenticazione e autorizzazione forniti da IAM e Amazon Cognito, puoi associare un ACL web AWS WAF alla distribuzione. CloudFront Prendi in considerazione l'utilizzo della soluzione AWS WAF Security Automations
Implementazione ALB + ECS Fargate: la soluzione implementa automaticamente un ACL web AWS WAF davanti all'ALB con regole gestite che forniscono una protezione di base contro i comuni attacchi basati sul Web. Puoi personalizzare le regole WAF per soddisfare i tuoi requisiti di sicurezza specifici, inclusa l'aggiunta di elenchi di IP-based autorizzazioni o blocchi, restrizioni geografiche, limiti di velocità o gruppi di regole gestiti da AWS aggiuntivi. Per istruzioni su come modificare la configurazione WAF, consulta la sezione sull'integrazione WAF nelle istruzioni di distribuzione.
Sicurezza del server MCP (opzionale)
Se distribuisci l'integrazione opzionale con MCP Server, la soluzione utilizza Amazon Bedrock AgentCore Gateway per fornire un accesso sicuro ai dati dei test di carico per gli agenti AI. AgentCore Gateway convalida i token di autenticazione Amazon Cognito per ogni richiesta, garantendo che solo gli utenti autorizzati possano accedere al server MCP. La funzione MCP Server Lambda implementa modelli di accesso di sola lettura, impedendo agli agenti AI di modificare le configurazioni o i risultati dei test. Tutte le interazioni con il server MCP utilizzano gli stessi limiti di autorizzazione e gli stessi controlli di accesso della console web.
Sicurezza della console web ospitata da ALB+ ECS Fargate (opzionale)
Se scegli l'opzione di implementazione ALB + ECS Fargate, si applicano le seguenti considerazioni sulla sicurezza:
-
Compatibilità VPC Block Public Access: l'opzione ALB+ ECS Fargate è progettata per ambienti in cui le politiche VPC Block Public Access (BPA) bloccano il traffico proveniente dalle distribuzioni pubbliche. CloudFront L'ALB può essere implementato come bilanciamento del carico interno all'interno del VPC, accessibile solo tramite la rete aziendale, VPN o AWS PrivateLink, soddisfacendo zero requisiti di esposizione pubblica a Internet.
-
Gestione dei certificati ACM: l'ALB utilizza un certificato ACM per la terminazione HTTPS. È tua responsabilità garantire che il certificato rimanga valido e venga rinnovato prima della scadenza. ACM rinnova automaticamente i certificati che gestisce, ma i certificati importati devono essere rinnovati manualmente. Per ulteriori informazioni, consulta la sezione Managed Certificate Renewal nella AWS Certificate Manager User Guide.
-
Protezione AWS WAF: WAF viene distribuito per impostazione predefinita con il modello ALB + ECS Fargate. Per i dettagli, consulta Limitazione dell'accesso all'interfaccia utente pubblica.
Sicurezza headless (porta il tuo server web) (opzionale)
Se scegliete l'opzione di implementazione headless e ospitate la console Web sul vostro server Web, siete responsabili delle seguenti considerazioni sulla sicurezza:
-
Configurazione HTTPS: consigliamo vivamente di configurare HTTPS sul tuo server web.
-
Controlli di accesso: sei responsabile dell'implementazione dei controlli di accesso, delle regole del firewall e della sicurezza di rete sul tuo server web.
-
Rafforzamento della sicurezza: applica gli standard di rafforzamento della sicurezza della tua organizzazione al server Web, tra cui l'applicazione di patch, il monitoraggio e il rilevamento delle intrusioni.
Third-party framework di test
Distributed Load Testing on AWS include tre framework di test di terze parti: Apache JMeter, Grafana K6 e Locust. In base al modello di responsabilità condivisa di AWS
Apache JMeter
La versione in bundle di Apache JMeter presenta vulnerabilità di sicurezza note che non possono essere completamente corrette esternamente senza compromettere la compatibilità con il framework di automazione dei test Taurus e l'ecosistema di plugin JMeter da cui dipende la soluzione. Prima di eseguire i test di carico, consulta gli avvisi di sicurezza di Apache JMeter e valuta se possono causare vulnerabilità di sicurezza
Nota
Apache JMeter funziona anche sotto il cofano per il tipo di test Single HTTP Endpoint. Quando configuri un URL, un metodo, delle intestazioni e del payload del corpo nella console web, la soluzione genera un piano di test JMeter e lo esegue con il binario JMeter in dotazione. Le considerazioni sulla sicurezza di JMeter descritte in questa sezione si applicano quindi anche ai test Single HTTP Endpoint.
Se hai bisogno di una versione patchata di JMeter, hai due opzioni. Entrambe le opzioni richiedono un archivio di test e sono disponibili solo per il tipo di test JMeter:
-
Fornisci un binario JMeter con patch: includi un binario JMeter con patch nell'archivio di test. La soluzione utilizza il file binario al posto della versione in bundle.
-
Sostituisci i singoli plug-in JAR: utilizza il meccanismo di sostituzione dei plug-in per sostituire JAR di plug-in vulnerabili specifici con versioni patchate. Per ulteriori informazioni, consulta i test JMeter.
Il tipo di test Single HTTP Endpoint non accetta un archivio di test e pertanto non può sovrascrivere il binario o i plugin JMeter in bundle. Se devi eseguire test sugli endpoint HTTP con un JMeter aggiornato, usa il tipo di test JMeter e fornisci uno script JMeter (.jmx) o un archivio.zip che includa i file JAR del plugin o del binario JMeter con patch.
Grafana K6
K6 è rilasciato sotto licenza. AGPL-3.0
Locust
Nessuna vulnerabilità di sicurezza nota era identificata nella versione in bundle di Locust al momento del rilascio di questa soluzione. La soluzione non monitora Locust alla ricerca di nuove vulnerabilità su base continuativa; l'utente è responsabile della valutazione di Locust rispetto ai requisiti di sicurezza durante tutto il suo utilizzo.