Cloud Shared Responsibility Model

#

Il modello di responsabilita' condivisa definisce il confine tra cio' che il provider cloud protegge e cio' che e' responsabilita' del cliente. Il confine si sposta a seconda del modello di servizio usato: IaaS, PaaS o SaaS. Non conoscere questo confine e' la causa della maggior parte dei breach cloud.

Mappa Globale

#

Shared Responsibility Model — Panoramica

#

Il Principio

#

Il modello di responsabilita' condivisa non e' un'assicurazione: il fatto che il provider gestisca l'infrastruttura fisica non significa che il cloud sia automaticamente sicuro. AWS non e' mai responsabile di un S3 bucket che hai configurato come pubblico.

La distinzione chiave e':

• Sicurezza DELL'infrastruttura (provider): datacenter fisici, hardware, cavi, switch, hypervisor, rete globale
• Sicurezza NEL cloud (cliente): dati, configurazioni, identita', accessi, OS delle VM, applicazioni

flowchart TD
    subgraph PROV[Provider Cloud]
        DC[Datacenter fisico]
        HW[Hardware, cavi, rack]
        HYPER[Hypervisor]
        NET_PHYS[Rete fisica globale]
    end

    subgraph SHARED[Confine variabile - dipende dal modello]
        OS[Sistema Operativo]
        RUNTIME[Runtime / Middleware]
        APP[Applicazione]
        NET_VIRT[Networking virtuale - VPC, SG, NSG]
    end

    subgraph CUSTOMER[Cliente]
        DATA[Dati]
        IAM_C[Identity - chi accede e con quali permessi]
        ENCR[Cifratura at rest e in transit]
        CONFIG[Configurazioni - S3 public?, SG open?, RDS encrypted?]
    end

    PROV -->|sempre provider| PROV
    SHARED -->|IaaS: cliente\nPaaS: provider\nSaaS: provider| SHARED
    CUSTOMER -->|sempre cliente| CUSTOMER

IaaS (Infrastructure as a Service)

#

IaaS fornisce al cliente l'infrastruttura virtualizzata grezza: CPU, RAM, storage, rete. Il cliente gestisce tutto il software sopra, incluso il sistema operativo. E' il modello con la massima flessibilita' e la massima responsabilita'.

Esempi: AWS EC2, Azure Virtual Machines, GCP Compute Engine, DigitalOcean Droplet.

Provider gestisce:

• Datacenter fisico, alimentazione, raffreddamento
• Hardware (server, switch, storage fisico)
• Hypervisor (VMware, KVM, Xen)
• Rete fisica e backbone globale

Cliente gestisce:

• Sistema operativo: scelta, installazione, patch, hardening
• Middleware e runtime (Node.js, PHP-FPM, Java)
• Applicazione e il suo codice
• Dati e loro cifratura
• IAM: chi accede all'istanza, con quale ruolo, con quale chiave SSH
• Firewall virtuale: Security Groups (AWS), NSG (Azure), VPC Firewall Rules (GCP)
• Configurazione rete virtuale: VPC, subnet, routing tables

Dev parallel: E' come noleggiare un server dedicato in un datacenter (colocation). Il datacenter si occupa di corrente, raffreddamento e connettivita', ma il server fisicamente e' tuo: tu installi Ubuntu, tu applichi le patch, tu configuri iptables. IaaS e' la stessa cosa ma il server e' virtualizzato.

Mappa — IaaS

#

PaaS (Platform as a Service)

#

PaaS fornisce una piattaforma gestita su cui il cliente deploya la sua applicazione senza gestire l'OS sottostante. Il provider si occupa di patch, aggiornamenti, scaling dell'infrastruttura. Il cliente si concentra sull'applicazione e sui dati.

Esempi: AWS RDS, AWS Lambda, Azure App Service, Azure Functions, Google Cloud Run, Heroku.

Provider gestisce (tutto IaaS piu'):

• Sistema operativo (patch automatiche, mai visibili al cliente)
• Runtime (versione Python, Node.js, Java gestita dal provider)
• Middleware (web server, connection pooling, replica DB)
• Piattaforma e sue dipendenze

Cliente gestisce:

• Codice applicativo e dipendenze dell'app
• Dati nel servizio (tabelle RDS, oggetti S3, record in DynamoDB)
• Configurazione IAM: chi puo' chiamare la Lambda, chi puo' leggere il DB
• Configurazione della piattaforma stessa: retention log, encryption settings, VPC integration

Il cliente non puo' fare SSH a un'istanza RDS o a un container Cloud Run. L'OS e' gestito e non accessibile — questo e' sia un vantaggio (no patch OS) sia un limite (meno controllo per hardening personalizzato).

Dev parallel: E' come usare un servizio di hosting PHP gestito come Platform.sh o Heroku. Tu fai git push e la piattaforma si occupa di PHP, Nginx, SSL, scaling. Tu gestisci solo il tuo codice Symfony e il database PostgreSQL che hai configurato.

Mappa — PaaS

#

SaaS (Software as a Service)

#

SaaS fornisce un'applicazione completa pronta all'uso. Il cliente usa il software via browser o client, senza gestire nulla dell'infrastruttura, OS, runtime o applicazione stessa. La responsabilita' del cliente si concentra su dati e controllo degli accessi.

Esempi: Microsoft 365, Google Workspace, Salesforce, Slack, GitHub, Zoom, ServiceNow.

Provider gestisce (tutto PaaS piu'):

• L'applicazione stessa (feature, bug fix, aggiornamenti)
• Scaling, availability, backup dell'applicazione
• Sicurezza applicativa di base

Cliente gestisce:

• Dati: chi inserisce cosa, classificazione, retention, export/delete
• IAM: chi ha accesso all'applicazione, quali permessi (admin vs read-only), MFA obbligatorio
• Configurazione privacy: condivisione file esterna si/no, link pubblici si/no, guest access
• Integrazione sicura: OAuth scopes configurati correttamente, SSO con provider aziendale

SaaS non significa "sicuro di default": un tenant Microsoft 365 con MFA disabilitato, sharing esterno abilitato e nessun DLP configurato e' un rischio significativo — ed e' interamente responsabilita' del cliente.

Dev parallel: E' come usare Stripe per i pagamenti. Tu non gestisci nulla di Stripe — loro si occupano di PCI DSS, patching, scaling. Tu gestisci solo i tuoi dati cliente, chi nella tua azienda ha accesso alla dashboard Stripe, e che permessi OAuth hai concesso alla Stripe API. Il confine e' sottile ma reale.

Mappa — SaaS

#

Tabella Responsabilita' Completa

#

Ogni layer e' colorato in base a chi e' responsabile: il confine si sposta verso il cliente man mano che si scende da SaaS a IaaS.

Shared Responsibility non significa "il cloud e' sicuro"

#

La maggior parte dei breach cloud non sono colpa del provider — sono misconfiguration del cliente. Il National Cybersecurity Agency e Gartner stimano che entro il 2025 oltre il 99% dei breach cloud derivera' da errori di configurazione del cliente.

flowchart TD
    BREACH[Cloud Security Breach]

    subgraph CLIENTE_ERR[Responsabilita' Cliente - cause frequenti]
        S3_PUB[S3 bucket configurato pubblico]
        IAM_OVER[IAM role con AdministratorAccess inutile]
        NO_ENC[RDS/EBS non cifrato]
        EC2_OLD[EC2 con OS non patchato - Log4Shell]
        SG_OPEN[Security Group 0.0.0.0/0 porta 22]
        MFA_OFF[MFA disabilitato su account root]
    end

    subgraph PROVIDER_ERR[Responsabilita' Provider - rari]
        HW_FAIL[Failure hardware datacenter]
        HYPER_CVE[0-day nel hypervisor]
        BACKBONE[Interruzione rete backbone]
    end

    BREACH --> CLIENTE_ERR
    BREACH --> PROVIDER_ERR
    Note1[~99% dei breach]:::note -.-> CLIENTE_ERR
    Note2[~1% dei breach]:::note -.-> PROVIDER_ERR

    classDef note fill:none,stroke:none

Esempi reali di misconfiguration cliente:

• Capital One (2019): SSRF su EC2 + IAM role con troppi permessi → 100 milioni di record esposti. Causa: misconfiguration IAM del cliente, non bug AWS.
• S3 exposure frequente: decine di aziende ogni anno espongono dati sensibili in bucket S3 pubblici configurati per errore. AWS offre gli strumenti per evitarlo (S3 Block Public Access, AWS Config), ma devono essere abilitati dal cliente.

Implicazioni Operative per Cloud Security Engineer

#

La comprensione del shared responsibility model e' il punto di partenza per il lavoro quotidiano di un Cloud Security Engineer. Il ruolo non e' gestire il datacenter fisico — quello lo fa il provider. Il ruolo e' garantire che tutto cio' che e' responsabilita' del cliente sia configurato correttamente.

In ambienti IaaS:

• Patch management sistematico degli OS (AWS Systems Manager Patch Manager, Azure Update Manager)
• Hardening delle istanze (CIS Benchmark, STIG)
• Security Group review periodica (nessuna regola 0.0.0.0/0 non giustificata)
• Cifratura EBS/dischi at rest e in transit
• IAM least privilege: nessun ruolo con AdministratorAccess se non necessario

In ambienti PaaS:

• Focus su application security (SAST, DAST sul codice deployato)
• IAM per i servizi managed (chi puo' scrivere su RDS? chi puo' invocare Lambda?)
• Configurazione encryption settings della piattaforma (RDS encryption, Lambda VPC config)
• Logging e monitoring: CloudWatch, CloudTrail, Azure Monitor

In ambienti SaaS:

• MFA obbligatorio per tutti gli utenti (specialmente admin)
• De-provisioning rapido degli account in uscita
• Audit periodico degli OAuth grant (quante app di terze parti hanno accesso a Google Workspace?)
• CASB per visibilita' centralizzata su tutti i SaaS usati in azienda
• SSPM (SaaS Security Posture Management) per configurazioni insicure di default

Dev parallel: Come dev PHP/Node con 20 anni di esperienza sai bene che un framework come Symfony non ti protegge automaticamente da SQLi o XSS — devi usare le sue funzionalita' di sicurezza attivamente (prepared statements, CSRF token, output escaping). AWS e' uguale: i tool per essere sicuri ci sono tutti (KMS, IAM, CloudTrail, GuardDuty, Security Hub), ma sei tu che devi attivarli e configurarli correttamente.

Mappa — Implicazioni Operative

#