Il modello cloud e la responsabilità condivisa

Nel cloud la sicurezza non appartiene mai a un solo attore: è condivisa tra il cloud provider (CSP) e il cliente. Il confine di responsabilità si sposta a seconda del modello di servizio. La regola mnemonica è semplice: più il servizio è “gestito”, meno controllo (e meno responsabilità operativa) ha il cliente, ma il cliente resta sempre responsabile dei propri dati, delle identità e della corretta configurazione degli accessi.

I tre modelli di servizio

Livello Chi gestisce lo stack sottostante Responsabilità principale del cliente
IaaS Il provider gestisce hardware, virtualizzazione, rete fisica e storage OS guest, patching, middleware, runtime, applicazioni, dati, IAM, config di rete virtuale (security group, subnet)
PaaS Il provider gestisce anche OS, runtime e patching della piattaforma Applicazioni e codice, configurazione del servizio, dati, identità
SaaS Il provider gestisce quasi tutto lo stack Solo i propri dati e la gestione delle identità/accessi

In IaaS il cliente eredita molte responsabilità tipiche dell’on-premise: è lui che deve patchare l’OS guest, hardenizzare, applicare ACL e configurare segmentazione. In SaaS il provider si occupa di applicazione, OS e infrastruttura; al cliente restano classificazione e protezione dei dati e la governance degli account (MFA, least privilege, offboarding). Il PaaS è la via di mezzo: patching della piattaforma al provider, sicurezza del codice e dei dati al cliente.

Modelli di deployment

Ortogonali ai modelli di servizio, i deployment model descrivono dove e per chi è erogato il cloud:

  • Public: infrastruttura multi-tenant condivisa gestita dal CSP.
  • Private: dedicato a una singola organizzazione (on-prem o hosted), massimo controllo.
  • Hybrid: combinazione di private e public con orchestrazione tra i due, tipicamente per mantenere dati sensibili on-prem e scalare i workload sul public.
  • Community: condiviso tra organizzazioni con requisiti comuni (es. compliance settoriale, enti pubblici).

DevSecOps: sicurezza integrata nella pipeline

Il DevSecOps sposta la sicurezza “a sinistra” (shift-left), integrandola in ogni fase della pipeline CI/CD invece di trattarla come controllo finale. Concetti chiave che SCOR si aspetta:

  • SAST/DAST e scansione delle dipendenze automatizzate nella build.
  • Secret management: nessuna credenziale hard-coded nel codice o nelle immagini.
  • Container security: scansione delle immagini per vulnerabilità note (CVE), uso di immagini base minimali, registri fidati e image signing per garantire integrità e provenienza.
  • Orchestrazione (es. Kubernetes): sicurezza di runtime, network policy per la micro-segmentazione tra pod, RBAC e isolamento dei namespace.
  • Infrastructure as Code (IaC): la config è versionata e verificabile, riducendo il configuration drift.

L’obiettivo è la ripetibilità: build immutabili e controlli automatici che bloccano artefatti non conformi prima del deploy.

Il ruolo del CASB

Il CASB (Cloud Access Security Broker) è il punto di controllo posto tra utenti e servizi cloud (soprattutto SaaS). Fornisce visibility su Shadow IT (app cloud non autorizzate), applica DLP, controlli di accesso, rilevamento di anomalie e verifica della compliance. In casa Cisco questa funzione è coperta da Cisco Umbrella e da Cisco Secure Cloud Analytics (Stealthwatch Cloud) per la visibilità sui workload cloud. Il CASB colma il gap di controllo proprio dove il cliente ha meno leve infrastrutturali, cioè nel SaaS.

Trappole tipiche d’esame

  • Scenario: workload SaaS, chi patcha il sistema operativo? → Il provider. In SaaS il CSP gestisce tutto lo stack tranne dati e identità; il patching dell’OS non è mai del cliente.
  • Scenario: si vuole massimo controllo sull’hardening dell’OS guest e sul patching. → IaaS, perché è l’unico modello dove OS guest, runtime e applicazioni restano responsabilità del cliente.
  • Scenario: “il cloud provider è responsabile della sicurezza dei nostri dati”. → Falso in ogni modello. La protezione e classificazione dei dati e la gestione delle identità restano sempre del cliente, anche in SaaS.
  • Scenario: rilevare Shadow IT e applicare DLP sulle app SaaS usate dai dipendenti. → CASB (es. Cisco Umbrella), non un firewall perimetrale tradizionale.
  • Scenario: bloccare un’immagine container vulnerabile prima del deploy. → Integrare image scanning e signing nella pipeline CI/CD (approccio shift-left), non un controllo post-produzione.