NIST SP 800-145 e Penetration Test nel Cloud Security

NIST SP 800-145 (The NIST Definition of Cloud Computing) definisce il perimetro tecnico di un servizio cloud — service model, deployment model e caratteristiche essenziali — ed è il riferimento tassonomico usato da audit, procurement e qualificazioni cloud in tutto il mondo. Quando quel perimetro dipende da portali, console, API, tenant e automazioni, il penetration test è lo strumento più diretto per verificare che la definizione dichiarata corrisponda al comportamento reale.

Se scope, evidenze, remediation o retest non sono allineati al contesto dello standard, il rischio non è solo tecnico: si traduce in ambiguità sulla shared responsibility, in vendor assessment incerti e in audit che richiedono approfondimenti aggiuntivi.

In breve: cosa conta per NIST SP 800-145

NIST SP 800-145 conta sul piano tecnico perché i cinque essential characteristics del cloud, i modelli di servizio e i modelli di deployment non sono solo tassonomia: influenzano cosa deve essere testato, chi ha responsabilità di controllo e quali superfici siano davvero esposte. Il penetration test aiuta a verificare se la definizione del servizio corrisponda al suo comportamento reale, e il suo valore cresce quando collega vulnerabilità tecniche e impatto su scoping, shared responsibility e vendor assessment.

A chi è utile questa guida

Il contenuto è rilevante per CISO, CTO, Cloud Security Architect, Compliance Manager e IT Manager; per i team che devono collegare definizione del cloud e rischio tecnico; per provider SaaS, PaaS, IaaS e organizzazioni che acquistano o qualificano servizi cloud; per chi affronta audit, procurement tecnico, due diligence o chiarimenti sul modello di servizio.

Perché NIST SP 800-145 conta anche sul piano tecnico

Il rischio tecnico può compromettere elementi centrali della definizione cloud, tra cui:

• la coerenza tra service model dichiarato e superfici realmente esposte;
• il controllo su self-service, provisioning, metering e accesso amministrativo;
• la segregazione tra tenant e i confini tra responsabilità di provider e cliente;
• elasticità, accesso di rete e modello operativo del servizio;
• la credibilità della classificazione cloud usata in audit o vendor assessment.

Per questo, anche se lo standard non richiede esplicitamente un penetration test, la verifica tecnica diventa spesso una delle prove più utili per dimostrare che il servizio sia davvero cloud nei termini dichiarati e che il perimetro di rischio sia compreso correttamente.

Dove il penetration test crea valore

In questo contesto, il penetration test è utile soprattutto quando bisogna dimostrare che portali, API e console esposte riflettano davvero il modello di servizio dichiarato; che ruoli, tenant e confini di responsabilità non creino aree grigie o escalation indebite; che provisioning, accesso broad network e funzioni operative cloud reggano a scenari di abuso realistici; che remediation e retest producano una prova leggibile anche da auditor, buyer o management.

Nei test su ambienti cloud descritti con la tassonomia NIST SP 800-145, i finding più ricorrenti riguardano la distanza tra il service model dichiarato e i controlli realmente implementati: on-demand self-service con provisioning che richiede intervento manuale non dichiarato, resource pooling con isolamento dei tenant inferiore a quanto il deployment model implica e broad network access con superfici esposte non considerate nel modello di shared responsibility.

Cosa chiedono buyer, auditor e stakeholder

Un cloud architect, un procurement officer o un auditor che valuta un provider rispetto alla definizione NIST SP 800-145 chiede cose precise:

• il servizio corrisponde davvero al service model dichiarato (SaaS, PaaS, IaaS) e al deployment model (public, private, hybrid)?
• tenant boundary, self-service provisioning e accesso di rete sono stati testati tecnicamente o solo descritti nella documentazione?
• le vulnerabilità trovate impattano il modello di shared responsibility dichiarato, spostando rischio sul cliente?
• i finding sono stati corretti e c’è un retest che dimostra che il servizio funziona come dichiarato?
• il report è leggibile da chi valuta il cloud provider in fase di vendor assessment o due diligence contrattuale?

Mappatura tra aree di verifica, evidenze e attività

Area da validare	Evidenza utile	Attività ISGroup più adatta	Output atteso
Portali, superfici esposte e funzioni SaaS	Vulnerabilità sfruttabili e impatto sul modello di servizio	Web Application Penetration Testing	Executive summary, finding, remediation
Ambienti cloud, tenant e confini di responsabilità	Errori di hardening, accesso e trust boundary	Cloud Security Assessment	Dettaglio tecnico e priorità
Rete, accessi privilegiati e componenti infrastrutturali	Pivoting, esposizione, hardening debole	Network Penetration Testing	Report tecnico e rischio operativo
Governo del miglioramento	Roadmap, remediation, retest e presidio	Virtual CISO	Piano di miglioramento e riesame

Caso d’uso realistico

Uno scenario tipico è questo: un provider dichiara un servizio SaaS multi-tenant conforme alla definizione cloud, ma in audit emergono domande concrete — quanto è davvero self-service? Le API permettono provisioning coerente col modello dichiarato? I tenant sono isolati? Le superfici amministrative sono separate dal servizio cliente? In quel momento il penetration test diventa utile per trasformare NIST SP 800-145 in evidenza tecnica concreta. Un caso utile da considerare è il Web Application Penetration Test su Workforce Management Platform per TimeFlow S.r.l., che mostra come ISGroup traduca verifica tecnica, remediation e fiducia del cliente in un risultato leggibile anche fuori dal team security.

Errori comuni da evitare

• Trattare NIST SP 800-145 come una compliance cloud generica anziché come una definizione di perimetro;
• limitare lo scope a un solo componente quando il modello di servizio reale è più ampio;
• confondere service model dichiarato e superfici effettivamente in carico al provider;
• produrre un report tecnico senza collegarlo a scoping, shared responsibility e vendor assessment;
• chiudere l’attività senza retest.

Domande frequenti su NIST SP 800-145 e penetration test

• NIST SP 800-145 è uno standard di conformità o una definizione di riferimento?
• NIST SP 800-145 è la definizione tecnica di cloud computing adottata come riferimento dal governo USA e da molte organizzazioni internazionali. Non è uno schema di certificazione con requisiti da soddisfare: è il vocabolario comune usato per descrivere service model, deployment model e caratteristiche essenziali del cloud. Il penetration test non è richiesto dalla pubblicazione, ma è lo strumento più diretto per verificare che il servizio dichiarato corrisponda alla realtà tecnica.
• Cosa significa verificare la shared responsibility con un penetration test?
• Significa testare dove finisce la responsabilità del provider e dove inizia quella del cliente. Un finding su una configurazione non sicura da parte del cliente non è responsabilità del provider; un finding su una vulnerabilità nel layer di isolamento tenant è responsabilità del provider. Il test aiuta a disegnare questa linea in modo tecnico e non solo contrattuale.
• Come si usa NIST SP 800-145 in un processo di qualificazione cloud pubblico?
• In Italia, la qualificazione ACN per i servizi cloud PA usa NIST SP 800-145 come base tassonomica per classificare il tipo di servizio. In Europa, il framework EUCS segue una logica simile. Una verifica tecnica indipendente sul servizio accelera il percorso di qualificazione perché riduce le aree di incertezza tecnica che i valutatori devono approfondire.

Per collegare NIST SP 800-145 a evidenze tecniche davvero spendibili, il primo passo utile è chiarire quale parte del modello cloud dichiarato va davvero verificata. È possibile partire dal Cloud Security Assessment, affiancare il Web Application Penetration Testing e il Network Penetration Testing, e coinvolgere il Virtual CISO per trasformare il lavoro in un percorso leggibile, verificabile e convincente.

Approfondimenti correlati

• Per capire quando il penetration test serve davvero nel contesto di NIST SP 800-145, è disponibile l’approfondimento su quando il penetration test conta davvero;
• per audit, vendor assessment e fiducia del buyer, è utile la guida sulle evidenze utili per audit e vendor assessment con NIST SP 800-145;
• per scope, deliverable e retest, è disponibile la guida pratica su scope, deliverable e retest nel contesto NIST SP 800-145.