Controllo della sicurezza: sicurezza DevOps

  • Articolo
  • 18 minuti per la lettura

DevOps Security illustra i controlli correlati alla progettazione e alle operazioni di sicurezza nei processi DevOps, inclusa la distribuzione di controlli di sicurezza critici (ad esempio test di sicurezza statici delle applicazioni, gestione delle vulnerabilità) prima della fase di distribuzione per garantire la sicurezza durante il processo DevOps; include anche argomenti comuni, ad esempio la modellazione delle minacce e la sicurezza dell'approvvigionamento software.

DS-1: Eseguire la modellazione delle minacce

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
16.10, 16.14 SA-15 6.5, 12.2

Principio di sicurezza: eseguire la modellazione delle minacce per identificare le potenziali minacce ed enumerare i controlli di mitigazione. Assicurarsi che la modellazione delle minacce soddisfi i seguenti scopi:

  • Proteggere le applicazioni e i servizi nella fase di runtime di produzione.
  • Proteggere gli artefatti, la pipeline CI/CD sottostante e altri ambienti di strumenti usati per la compilazione, il test e la distribuzione. La modellazione delle minacce deve includere almeno gli aspetti seguenti:
  • Definire i requisiti di sicurezza dell'applicazione. Assicurarsi che questi requisiti siano adeguatamente risolti nella modellazione delle minacce.
  • Analizzare i componenti dell'applicazione, le connessioni dati e la relativa relazione. Assicurarsi che questa analisi includa anche le connessioni upstream e downstream all'esterno dell'ambito dell'applicazione.
  • Elencare le potenziali minacce e i vettori di attacco a cui possono essere esposti i componenti dell'applicazione, le connessioni dati e i servizi upstream e downstream.
  • Identificare i controlli di sicurezza applicabili che possono essere usati per attenuare le minacce enumerate e identificare eventuali lacune nei controlli (ad esempio, vulnerabilità di sicurezza) che potrebbero richiedere piani di trattamento aggiuntivi.
  • Enumerare e progettare i controlli che possono attenuare le vulnerabilità identificate.

Linee guida di Azure: usare strumenti di modellazione delle minacce come Lo strumento di modellazione delle minacce Microsoft con il modello di minaccia di Azure incorporato per guidare il processo di modellazione delle minacce. Usare il modello STRIDE per enumerare le minacce sia interne che esterne e identificare i controlli applicabili. Assicurarsi che il processo di modellazione delle minacce includa gli scenari di minaccia nel processo DevOps, ad esempio l'inserimento di codice dannoso tramite un repository di artefatti non sicuri con criteri di controllo di accesso configurati in modo errato.

Se l'uso di uno strumento di modellazione delle minacce non è applicabile, è consigliabile usare almeno un processo di modellazione delle minacce basato su questionari per identificare le minacce.

Assicurarsi che i risultati della modellazione o dell'analisi delle minacce vengano registrati e aggiornati quando si verifica una modifica importante dell'impatto sulla sicurezza nell'applicazione o nel panorama delle minacce.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare strumenti di modellazione delle minacce come lo strumento di modellazione delle minacce Microsoft e creare un modello AWS personalizzato per guidare il processo di modellazione delle minacce. Usare il modello STRIDE per enumerare le minacce sia interne che esterne e identificare i controlli applicabili. Assicurarsi che il processo di modellazione delle minacce includa gli scenari di minaccia nel processo DevOps, ad esempio l'inserimento di codice dannoso tramite un repository di artefatti non sicuri con criteri di controllo di accesso configurati in modo errato.

Se l'uso di uno strumento di modellazione delle minacce non è applicabile, è consigliabile usare almeno un processo di modellazione delle minacce basato su questionari per identificare le minacce.

Assicurarsi che i risultati della modellazione o dell'analisi delle minacce vengano registrati e aggiornati quando si verifica una modifica importante dell'impatto sulla sicurezza nell'applicazione o nel panorama delle minacce.

Implementazione di AWS e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-2: Garantire la sicurezza della supply chain software

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
16.4, 16.6, 16.11 SA-12, SA-15 6.3, 6.5

Principio di sicurezza: assicurarsi che il processo o il ciclo di vita di SDLC (Software Development Lifecycle) dell'organizzazione includano un set di controlli di sicurezza per gestire i componenti software interni e di terze parti (incluso il software proprietario e open source) in cui le applicazioni hanno dipendenze. Definire criteri di controllo per impedire l'integrazione e la distribuzione di componenti vulnerabili o dannosi nell'ambiente.

I controlli di sicurezza della supply chain software devono includere almeno gli aspetti seguenti:

  • Gestire correttamente un SOM (Software Bill of Materials) identificando le dipendenze upstream necessarie per lo sviluppo di servizi/risorse, la fase di compilazione, integrazione e distribuzione.
  • Inventario e rilevamento dei componenti software interni e di terze parti per la vulnerabilità nota quando è disponibile una correzione nell'upstream.
  • Valutare le vulnerabilità e il malware nei componenti software usando test di applicazioni statici e dinamici per individuare vulnerabilità sconosciute.
  • Assicurarsi che le vulnerabilità e il malware siano mitigati usando l'approccio appropriato. Ciò può includere correzioni locali o upstream del codice sorgente, esclusione delle funzionalità e/o applicazione di controlli di compensazione se la mitigazione diretta non è disponibile.

Se nell'ambiente di produzione vengono usati componenti di terze parti di origine chiusa, è possibile che la visibilità sia limitata al comportamento di sicurezza. È consigliabile prendere in considerazione controlli aggiuntivi, ad esempio il controllo di accesso, l'isolamento della rete e la sicurezza degli endpoint per ridurre al minimo l'impatto se si verifica un'attività dannosa o una vulnerabilità associata al componente.

Linee guida di Azure: per la piattaforma GitHub, assicurarsi che la sicurezza della supply chain del software tramite le funzionalità o gli strumenti seguenti di GitHub Advanced Security o la funzionalità nativa di GitHub: usare Dependency Graph per analizzare, inventariare e identificare tutte le dipendenze del progetto e le vulnerabilità correlate tramite il database consultivo.

  • Usare Dependabot per assicurarsi che la dipendenza vulnerabile venga rilevata e risolta e assicurarsi che il repository mantenga automaticamente le versioni più recenti dei pacchetti e delle applicazioni da cui dipende.
  • Usare la funzionalità di analisi del codice nativo di GitHub per analizzare il codice sorgente durante l'origine del codice da esterno.
  • Usare Microsoft Defender for Cloud per integrare la valutazione delle vulnerabilità per l'immagine del contenitore nel flusso di lavoro CI/CD.

Per Azure DevOps, è possibile usare estensioni di terze parti per implementare controlli simili all'inventario, analizzare e correggere i componenti software di terze parti e le relative vulnerabilità

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: se si usano piattaforme AWS CI/CD come CodeCommit, CodePipeline, assicurarsi che la sicurezza della catena di approvvigionamento software usi CodeGuru Reviewer per analizzare il codice sorgente (per Java e Python) tramite i flussi di lavoro CI/CD. Piattaforme come CodeCommit, CodePipeline supporta anche estensioni di terze parti per implementare controlli simili per l'inventario, analizzare e correggere i componenti software di terze parti e le relative vulnerabilità.

Se si gestisce il codice sorgente tramite la piattaforma GitHub, assicurarsi che la sicurezza della supply chain del software tramite le funzionalità o gli strumenti seguenti di GitHub Advanced Security o la funzionalità nativa di GitHub: usare Dependency Graph per analizzare, inventariare e identificare tutte le dipendenze del progetto e le vulnerabilità correlate tramite il database consultivo.

  • Usare Dependabot per assicurarsi che la dipendenza vulnerabile venga rilevata e risolta e assicurarsi che il repository mantenga automaticamente le versioni più recenti dei pacchetti e delle applicazioni da cui dipende.
  • Usare la funzionalità di analisi del codice nativo di GitHub per analizzare il codice sorgente durante l'origine del codice da esterno.
  • Se applicabile, usare Microsoft Defender for Cloud per integrare la valutazione della vulnerabilità per l'immagine del contenitore nel flusso di lavoro CI/CD.

Implementazione di AWS e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-3: Infrastruttura DevOps sicura

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
16.7 CM-2, CM-6, AC-2, AC-3, AC-6 2.2, 6.3, 7.1

Principio di sicurezza: assicurarsi che l'infrastruttura e la pipeline DevOps seguano le procedure consigliate per la sicurezza in tutti gli ambienti, tra cui le fasi di compilazione, test e produzione. Questo include in genere i controlli di sicurezza per l'ambito seguente:

  • Repository di artefatti che archivia il codice sorgente, i pacchetti e le immagini compilati, gli artefatti del progetto e i dati aziendali.
  • Server, servizi e strumenti che ospitano pipeline CI/CD.
  • Configurazione della pipeline CI/CD.

Linee guida di Azure: nell'ambito dell'applicazione di Microsoft Cloud Security Benchmark ai controlli di sicurezza dell'infrastruttura DevOps, definire le priorità dei controlli seguenti:

  • Proteggere gli artefatti e l'ambiente sottostante per garantire che le pipeline CI/CD non diventino vie per inserire codice dannoso. Ad esempio, esaminare la pipeline CI/CD per identificare eventuali errori di configurazione nelle aree principali di Azure DevOps, ad esempio Organization, Projects, Users, Pipelines ( & Build Release), Connections e Build Agent per identificare eventuali configurazioni non configurate, ad esempio l'accesso aperto, l'autenticazione debole, la configurazione della connessione non sicura e così via. Per GitHub, usare controlli simili per proteggere i livelli di autorizzazione dell'organizzazione.
  • Assicurarsi che l'infrastruttura DevOps venga distribuita in modo coerente nei progetti di sviluppo. Tenere traccia della conformità dell'infrastruttura DevOps su larga scala usando Microsoft Defender for Cloud (ad esempio Dashboard di conformità, Criteri di Azure, Cloud Posture Management) o i propri strumenti di monitoraggio della conformità.
  • Configurare le autorizzazioni di identità/ruolo e i criteri di diritto in Azure AD, servizi nativi e strumenti CI/CD nella pipeline per garantire che le modifiche alle pipeline siano autorizzate.
  • Evitare di fornire l'accesso permanente con privilegi "in piedi" agli account umani, ad esempio sviluppatori o tester usando funzionalità come l'accesso gestito di Azure, l'accesso just-in-time.
  • Rimuovere chiavi, credenziali e segreti dal codice e dagli script usati nei processi del flusso di lavoro CI/CD e mantenerli nell'archivio chiavi o Key Vault di Azure.
  • Se si eseguono agenti di compilazione/distribuzione self-hosted, seguire i controlli di Microsoft Cloud Security Benchmark, tra cui sicurezza di rete, comportamento e gestione delle vulnerabilità e sicurezza degli endpoint per proteggere l'ambiente.

Nota: fare riferimento alla sezione Rilevamento delle minacce e rilevamento delle minacce e alla gestione delle vulnerabilità dS-7 per l'uso di servizi come Monitoraggio di Azure e Microsoft Sentinel per abilitare la governance, la conformità, il controllo operativo e il controllo dei rischi per l'infrastruttura DevOps.

Implementazione di Azure e contesto aggiuntivo:

Linee guida per AWS: nell'ambito dell'applicazione del benchmark di Microsoft Cloud Security all'infrastruttura DevOps (ad esempio GitHub, CodeCommit, CodeArtifact, CodePipeline, CodeBuild e CodeDeploy), la priorità dei controlli seguenti: per proteggere gli ambienti DevOps in AWS, vedere questa guida e AWS Well-architected Framework : pilastro della sicurezza per proteggere gli ambienti DevOps in AWS.

  • Proteggere gli artefatti e l'infrastruttura di supporto sottostante per garantire che le pipeline CI/CD non diventino strade per inserire codice dannoso.
  • Assicurarsi che l'infrastruttura DevOps venga distribuita e sostenuta in modo coerente nei progetti di sviluppo. Tenere traccia della conformità dell'infrastruttura DevOps su larga scala usando AWS Config o lo strumento di verifica della conformità.
  • Usare CodeArtifact per archiviare e condividere in modo sicuro i pacchetti software usati per lo sviluppo di applicazioni. È possibile usare CodeArtifact con strumenti di compilazione e gestioni pacchetti comuni, ad esempio Maven, Gradle, npm, yarn, pip e twine.
  • Configurare le autorizzazioni di identità/ruolo e i criteri di autorizzazione in AWS IAM, servizi nativi e strumenti CI/CD nella pipeline per garantire che le modifiche alle pipeline siano autorizzate.
  • Rimuovere chiavi, credenziali e segreti dal codice e dagli script usati nei processi del flusso di lavoro CI/CD e mantenerli nell'archivio chiavi o nel servizio di gestione delle chiavi AWS
  • Se si eseguono agenti di compilazione/distribuzione self-hosted, seguire i controlli di Microsoft Cloud Security Benchmark, tra cui sicurezza di rete, comportamento e gestione delle vulnerabilità e sicurezza degli endpoint per proteggere l'ambiente. Usare AWS Inspector per l'analisi delle vulnerabilità nell'ambiente EC2 o in contenitori come ambiente di compilazione.

Nota: fare riferimento alla sezione Registrazione e rilevamento delle minacce e DS-7 e Gestione delle vulnerabilità e all'uso di servizi come AWS CloudTrail, CloudWatch e Microsoft Sentinel per abilitare la governance, la conformità, il controllo operativo e il controllo dei rischi per l'infrastruttura DevOps.

Implementazione di AWS e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-4: Integrare test di sicurezza delle applicazioni statiche nella pipeline DevOps

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Principio di sicurezza: assicurarsi che i test di sicurezza delle applicazioni statiche (SAST) fuzzy test, test interattivi, test delle applicazioni mobili, facciano parte dei controlli di gating nel flusso di lavoro CI/CD. L'impostazione di gating può essere impostata in base ai risultati dei test per impedire il commit di pacchetti vulnerabili nel repository, la compilazione nei pacchetti o la distribuzione nell'ambiente di produzione.

Linee guida di Azure: integrare SAST nella pipeline (ad esempio, nell'infrastruttura come modello di codice) in modo che il codice sorgente possa essere analizzato automaticamente nel flusso di lavoro CI/CD. Azure DevOps Pipeline o GitHub può integrare gli strumenti seguenti e gli strumenti SAST di terze parti nel flusso di lavoro.

  • GitHub CodeQL per l'analisi del codice sorgente.
  • Microsoft BinSkim Binary Analyzer per Windows e *nix binary analysis.
  • Scanner delle credenziali di Azure DevOps (estensione Microsoft Security DevOps) e analisi dei segreti nativi di GitHub per l'analisi delle credenziali nel codice sorgente.

Implementazione di Azure e contesto aggiuntivo:

Linee guida DI AWS: integrare SAST nella pipeline in modo che il codice sorgente possa essere analizzato automaticamente nel flusso di lavoro CI/CD.

Se si usa AWS CodeCommit, usare l'analisi del codice sorgente Python e del codice sorgente Java di AWS CodeGuru. AWS Codepipeline può supportare anche l'integrazione di strumenti SAST di terze parti nella pipeline di distribuzione del codice.

Se si usa GitHub, gli strumenti seguenti possono essere integrati negli strumenti SAST di terze parti nel flusso di lavoro.

  • GitHub CodeQL per l'analisi del codice sorgente.
  • Microsoft BinSkim Binary Analyzer per Windows e *nix binary analysis.
  • Analisi dei segreti nativi di GitHub per l'analisi delle credenziali nel codice sorgente.
  • Analisi del codice sorgente DI AWS CodeGuru per Python e Java.

Implementazione di AWS e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-5: Integrare test dinamici della sicurezza delle applicazioni nella pipeline DevOps

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Principio di sicurezza: assicurarsi che il test di sicurezza delle applicazioni dinamiche (DAST) faccia parte dei controlli di gating nel flusso di lavoro CI/CD. L'impostazione di gating può essere impostata in base ai risultati dei test per impedire la compilazione di vulnerabilità nei pacchetti o la distribuzione nell'ambiente di produzione.

Linee guida di Azure: integrare DAST nella pipeline in modo che l'applicazione di runtime possa essere testata automaticamente nel set di flussi di lavoro CI/CD in Azure DevOps o GitHub. Anche i test di penetrazione automatizzati (con convalida assistita manuale) devono far parte del daST.

Azure DevOps Pipeline o GitHub supporta l'integrazione di strumenti DAST di terze parti nel flusso di lavoro CI/CD.

Implementazione di Azure e contesto aggiuntivo:

Linee guida per AWS: integrare DAST nella pipeline in modo che l'applicazione di runtime possa essere testata automaticamente nel set di flussi di lavoro CI/CD in AWS CodePipeline o GitHub. Anche i test di penetrazione automatizzati (con convalida assistita manuale) devono far parte del daST.

AWS CodePipeline o GitHub supporta l'integrazione di strumenti DAST di terze parti nel flusso di lavoro CI/CD.

Implementazione di AWS e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-6: Applicare la sicurezza del carico di lavoro nel ciclo di vita di DevOps

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
7.5, 7.6, 7.7, 16.1, 16.7 CM-2, CM-6, AC-2, AC-3, AC-6 6.1, 6.2, 6.3

Principio di sicurezza: assicurarsi che il carico di lavoro sia protetto nell'intero ciclo di vita nello sviluppo, nei test e nella fase di distribuzione. Usare Microsoft Cloud Security Benchmark per valutare i controlli (ad esempio sicurezza di rete, gestione delle identità, accesso con privilegi e così via) che possono essere impostati come guardrail per impostazione predefinita o spostarsi a sinistra prima della fase di distribuzione. In particolare, assicurarsi che i controlli seguenti siano presenti nel processo DevOps:- Automatizzare la distribuzione usando strumenti di Azure o di terze parti nel flusso di lavoro CI/CD, gestione dell'infrastruttura (infrastruttura come codice) e test per ridurre l'errore umano e la superficie di attacco.

  • Assicurarsi che le macchine virtuali, le immagini del contenitore e altri artefatti siano sicure dalla manipolazione dannosa.
  • Analizzare gli artefatti del carico di lavoro (in altre parole, immagini del contenitore, dipendenze, analisi SAST e DAST) prima della distribuzione nel flusso di lavoro CI/CD
  • Distribuire le funzionalità di valutazione della vulnerabilità e rilevamento delle minacce nell'ambiente di produzione e usare continuamente queste funzionalità in fase di esecuzione.

Linee guida di Azure: Linee guida per le macchine virtuali di Azure:

  • Usare Azure Raccolta immagini condivise per condividere e controllare l'accesso alle immagini da utenti, entità servizio o gruppi di Active Directory all'interno dell'organizzazione. Usare il controllo degli accessi in base al ruolo di Azure per garantire che solo gli utenti autorizzati possano accedere alle immagini personalizzate.
  • Definire le baseline di configurazione sicure per le macchine virtuali per eliminare credenziali, autorizzazioni e pacchetti non necessari. Tramite immagini personalizzate, il modello di azure Resource Manager e/o Criteri di Azure configurazione guest per distribuire e applicare queste linee di base di configurazione.

Linee guida per i servizi azure container:- Usare Registro Azure Container (ACR) per creare il registro contenitori privato in cui l'accesso limitato può essere configurato in modo granulare tramite controllo degli accessi in base al ruolo di Azure, in modo che solo i servizi e gli account autorizzati possano accedere ai contenitori nel Registro di sistema privato.

  • Usare Defender per i contenitori di Azure per la valutazione delle vulnerabilità delle immagini nel Registro Azure Container privato. È inoltre possibile usare Microsoft Defender per Cloud per modificare l'analisi delle immagini del contenitore come parte dei flussi di lavoro CI/CD.

Per i servizi serverless di Azure, adottare controlli simili per garantire che i controlli di sicurezza siano "spostati a sinistra" alla fase prima della distribuzione.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare Amazon Elastic Container Registry per condividere e controllare l'accesso alle immagini da utenti e ruoli diversi all'interno dell'organizzazione. Usare AWS IAM per garantire che solo gli utenti autorizzati possano accedere alle immagini personalizzate.

Definire le baseline di configurazione sicure per le immagini AMI EC2 per eliminare credenziali, autorizzazioni e pacchetti non necessari. Tramite immagini AMI personalizzate, modello CloudFormation e/o REGOLE di configurazione AWS per distribuire e applicare queste linee di base di configurazione.

Usare AWS Inspector per l'analisi della vulnerabilità dell'ambiente in contenitori e della macchina virtuale e la protezione dalla manipolazione dannosa.

Per i servizi serverless AWS, usare AWS CodePipeline in combinazione con AWS AppConfig per adottare controlli simili per garantire che i controlli di sicurezza vengano spostati alla fase precedente alla distribuzione.

Implementazione di AWS e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-7: Abilitare la registrazione e il monitoraggio in DevOps

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
8.2, 8.5, 8.9, 8.11 AU-3, AU-6, AU-12, SI-4 10.1, 10.2, 10.3, 10.6

Principio di sicurezza: assicurarsi che l'ambito di registrazione e monitoraggio includa ambienti non di produzione e elementi del flusso di lavoro CI/CD usati in DevOps (e altri processi di sviluppo). Le vulnerabilità e le minacce destinate a questi ambienti possono introdurre rischi significativi all'ambiente di produzione se non vengono monitorati correttamente. Gli eventi della compilazione CI/CD, del flusso di lavoro di test e distribuzione devono essere monitorati anche per identificare eventuali deviazioni nei processi di flusso di lavoro CI/CD.

Linee guida di Azure: seguire Microsoft Cloud Security Benchmark - Registrazione e rilevamento delle minacce come linee guida per implementare i controlli di registrazione e monitoraggio per il carico di lavoro.

Abilitare e configurare le funzionalità di registrazione dei controlli in ambienti di strumenti non di produzione e CI/CD (ad esempio Azure DevOps e GitHub) usati in tutto il processo DevOps.

Gli eventi del lavoro CI/CD di Azure DevOps e GitHub per i processi di compilazione, test e distribuzione devono essere monitorati anche per identificare eventuali risultati delle eccezioni nei processi CI/CD.

Inserire i log e gli eventi precedenti in Microsoft Sentinel o in altri strumenti SIEM tramite il flusso di registrazione o l'API per garantire che gli eventi imprevisti di sicurezza siano monitorati correttamente e sottoposti a valutazione per la gestione.

Implementazione di Azure e contesto aggiuntivo:

Linee guida AWS: abilitare e configurare AWS CloudTrail per le funzionalità di registrazione dei controlli in ambienti di strumenti non di produzione e CI/CD (ad esempio AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) usati in tutto il processo DevOps.

Gli eventi degli ambienti AWS CI/CD (ad esempio AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) e GitHub CI/CD lavoro per la compilazione, i test e i processi di distribuzione devono essere monitorati anche per identificare eventuali risultati delle eccezioni nei processi CI/CD.

Inserire i log e gli eventi precedenti in AWS CloudWatch, Microsoft Sentinel o altri strumenti SIEM tramite il flusso di registrazione o l'API per garantire che gli eventi imprevisti di sicurezza siano monitorati correttamente e sottoposti a valutazione per la gestione.

Implementazione di AWS e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):