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à.
Conformità
La conformità è una responsabilità condivisa tra AWS e i consumatori dei suoi servizi. In generale, AWS è responsabile della «sicurezza del cloud» mentre i suoi utenti sono responsabili della «sicurezza nel cloud». La linea che definisce le responsabilità di AWS e dei suoi utenti varia a seconda del servizio. Ad esempio, con Fargate, AWS è responsabile della gestione della sicurezza fisica dei suoi data center, dell'hardware, dell'infrastruttura virtuale (Amazon EC2) e del runtime dei container (Docker). Gli utenti di Fargate sono responsabili della protezione dell'immagine del contenitore e della relativa applicazione. Sapere chi è responsabile di ciò è un fattore importante quando si eseguono carichi di lavoro che devono rispettare gli standard di conformità.
La tabella seguente mostra i programmi di conformità a cui si conformano i diversi servizi di container.
| Programma di conformità | Amazon ECS Orchestrator | Amazon EKS Orchestrator | ECS Fargate | Amazon ECR |
|---|---|---|---|---|
|
PCI DSS livello 1 |
1 |
1 |
1 |
1 |
|
Conforme a HIPAA |
1 |
1 |
1 |
1 |
|
SOC I |
1 |
1 |
1 |
1 |
|
SOCI II |
1 |
1 |
1 |
1 |
|
SOCI III |
1 |
1 |
1 |
1 |
|
ISO 27001:2013 |
1 |
1 |
1 |
1 |
|
ISO 9001:2015 |
1 |
1 |
1 |
1 |
|
ISO 27017:2015 |
1 |
1 |
1 |
1 |
|
ISO 27018:2019 |
1 |
1 |
1 |
1 |
|
IRAP |
1 |
1 |
1 |
1 |
|
FedRAMP Moderate (Est/Ovest) |
1 |
1 |
0 |
1 |
|
FedRAMP High () GovCloud |
1 |
1 |
0 |
1 |
|
HA FATTO CC SRG |
1 |
Recensione DISA () IL5 |
0 |
1 |
|
HIPAA BAA |
1 |
1 |
1 |
1 |
|
MTCS |
1 |
1 |
0 |
1 |
|
C5 |
1 |
1 |
0 |
1 |
|
K-ISMS |
1 |
1 |
0 |
1 |
|
ENS High |
1 |
1 |
0 |
1 |
|
OSPAR |
1 |
1 |
0 |
1 |
|
HITRUST CSF |
1 |
1 |
1 |
1 |
Lo stato di conformità cambia nel tempo. Per lo stato più recente, consulta sempre https://aws.amazon.com/compliance/services-in-scope/
Per ulteriori informazioni sui modelli e le best practice di accreditamento sul cloud, consulta il white paper di AWS Accreditation
Spostamento a sinistra
Il concetto di spostamento a sinistra implica l'individuazione di violazioni ed errori delle politiche nelle prime fasi del ciclo di vita dello sviluppo del software. Dal punto di vista della sicurezza, questo può essere molto utile. Uno sviluppatore, ad esempio, può risolvere i problemi relativi alla configurazione prima che l'applicazione venga distribuita nel cluster. Individuare tempestivamente errori come questo aiuterà a prevenire l'implementazione di configurazioni che violano le policy.
La politica come codice
La politica può essere pensata come un insieme di regole per governare i comportamenti, ad esempio i comportamenti consentiti o quelli proibiti. Ad esempio, potresti avere una politica che afferma che tutti i Dockerfile devono includere una direttiva USER che fa funzionare il contenitore come utente non root. Come documento, una politica come questa può essere difficile da scoprire e applicare. Potrebbe inoltre diventare obsoleta man mano che i requisiti cambiano. Con le soluzioni Policy as Code (PaC), puoi automatizzare i controlli di sicurezza, conformità e privacy per rilevare, prevenire, ridurre e contrastare le minacce note e persistenti. Inoltre, offrono un meccanismo per codificare le politiche e gestirle come si fanno con altri artefatti di codice. Il vantaggio di questo approccio è che puoi riutilizzare le tue GitOps strategie DevOps e per gestire e applicare in modo coerente le policy tra flotte di cluster Kubernetes. Fai riferimento a Pod Security
Utilizza policy-as-code gli strumenti nelle pipeline per rilevare le violazioni prima della distribuzione
-
OPA è un
motore di policy open source che fa parte del CNCF. Viene utilizzato per prendere decisioni politiche e può essere eseguito in vari modi, ad esempio come libreria linguistica o servizio. Le politiche OPA sono scritte in un Domain Specific Language (DSL) chiamato Rego. Sebbene venga spesso eseguito come parte di un Kubernetes Dynamic Admission Controller come progetto Gatekeeper , OPA può anche essere incorporato nella pipeline CI/CD. Ciò consente agli sviluppatori di ottenere un feedback sulla loro configurazione nelle prime fasi del ciclo di rilascio, che può successivamente aiutarli a risolvere i problemi prima di passare alla produzione. Una raccolta di politiche OPA comuni è disponibile nell' GitHubarchivio di questo progetto. -
Conftest
è basato su OPA e offre un'esperienza incentrata sugli sviluppatori per testare la configurazione di Kubernetes. -
Kyverno
è un motore di policy progettato per Kubernetes. Con Kyverno, le policy vengono gestite come risorse Kubernetes e non è necessaria alcuna nuova lingua per scrivere le policy. Ciò consente di utilizzare strumenti familiari come kubectl, git e kustomize per gestire le politiche. Le policy di Kyverno possono convalidare, modificare e generare risorse Kubernetes, oltre a garantire la sicurezza della catena di fornitura delle immagini OCI. La CLI di Kyverno può essere utilizzata per testare le politiche e convalidare le risorse come parte di una pipeline CI/CD. Tutte le politiche della community di Kyverno sono disponibili sul sito Web di Kyverno e, per esempi di utilizzo della CLI di Kyverno per scrivere test nelle pipeline, consulta l'archivio delle politiche.
Strumenti e risorse
-
Workshop Amazon EKS Security Immersion - Conformità normativa
-
Kubernetes Security Review Una valutazione di sicurezza di
terze parti di Kubernetes 1.13.4 (2019) -
NeuVector di SUSE
, piattaforma open source di sicurezza per container zero-trust, fornisce report di conformità e controlli di conformità personalizzati
