Attestazione C5: preparare le evidenze di assurance per il cloud

Un cliente cloud vuole sapere quali protezioni gestisce il provider e quali restano di sua responsabilità. L’Ufficio federale tedesco per la sicurezza informatica (BSI) pubblica il Cloud Computing Compliance Criteria Catalogue, C5, come base strutturata per esaminare questa assurance. Per un CTO, prepararsi significa rendere verificabili il confine del servizio, l’implementazione dei controlli e le registrazioni operative, non soltanto raccogliere policy.

Il C5 è un catalogo di criteri usato per un’attestazione indipendente, non una certificazione in stile ISO. La documentazione del BSI sul C5 è il riferimento principale. Iniziate concordando con il revisore indipendente l’edizione applicabile, l’obiettivo di assurance e il perimetro dell’esame.

Definire con esattezza quale servizio coprirà il report

Descrivete il servizio cloud, le sedi operative, i confini organizzativi e le dipendenze. Un report che copre un servizio non copre automaticamente ogni prodotto venduto con lo stesso marchio. Individuate componenti di produzione, interfacce di gestione, attività di supporto e servizi esterni che possono incidere sulle affermazioni di assurance.

La descrizione del sistema deve consentire a un soggetto esterno di capire come i dati dei clienti entrano nel servizio, vi transitano e ne escono. Includete percorsi di amministrazione, processi di deployment, monitoraggio della sicurezza, backup e la ripartizione delle responsabilità tra i team. Spiegate le caratteristiche rilevanti del servizio e le condizioni operative invece di sostituire la parte descrittiva con diagrammi di architettura.

Risolvete queste questioni di perimetro prima di raccogliere le evidenze:

• Quali prodotti, regioni e ambienti sono inclusi?
• Quali team amministrano la produzione o possono accedere alle informazioni dei clienti?
• Quali provider sottostanti supportano il servizio, e come vengono trattati i loro controlli?
• Quali configurazioni e attività di sicurezza restano a carico dei clienti?
• Quali modifiche rilevanti sono avvenute, o sono previste, durante il periodo di esame?

Motivate esplicitamente le esclusioni. Se un deployment legacy è escluso, assicuratevi che le comunicazioni rivolte ai clienti non lascino intendere che sia coperto. Il risultato è una descrizione del sistema versionata, supportata da registrazioni su architettura, dipendenze e responsabilità.

Scegliere il tipo di report prima di fissare il calendario delle evidenze

L’assurance C5 si esprime generalmente attraverso un report di attestazione del revisore. Il Type 1 riguarda la progettazione e l’implementazione dei controlli in un determinato momento. Il Type 2 esamina inoltre l’efficacia operativa lungo un periodo specificato.

Il Type 1 può essere una tappa utile quando si costruisce un ambiente di controllo, ma non risponde alla stessa domanda del Type 2. Verificate che cosa richiedono effettivamente i clienti prima di scegliere un report intermedio.

Concordate con il revisore il periodo e le aspettative sulle evidenze. Non date per scontata una durata di osservazione universale. Una procedura redatta verso la fine di un periodo non può dimostrare che il controllo abbia funzionato in precedenza. Allo stesso modo, un test attuale superato non cancella un malfunzionamento passato.

Costruire le evidenze attorno a responsabilità ed esecuzione

Come metodo pratico di preparazione, costruite un registro delle evidenze che colleghi ogni criterio applicabile al controllo implementato, al responsabile, al confine del servizio, alla fonte delle evidenze, alla frequenza di revisione e alle lacune aperte. Registrate le decisioni di applicabilità e la loro motivazione; evitate di dichiarare un criterio non pertinente solo perché l’implementazione sarebbe difficile.

Separate tre domande: che cosa dovrebbe accadere, che cosa è implementato e che cosa è effettivamente accaduto. Una policy risponde alla prima. Le registrazioni della configurazione possono supportare la seconda. Ticket, log, approvazioni e risultati dei test supportano la terza.

Sono esempi pratici, non una checklist C5 completa. Usate il catalogo e il perimetro concordati per stabilire la copertura richiesta, compresi i controlli organizzativi, relativi al personale, fisici e tecnici.

Rendere le evidenze riproducibili

Per ogni esportazione o screenshot, conservate il sistema di origine, la data di raccolta, il periodo pertinente, i filtri e chi l’ha raccolta. Spiegate se rappresenta l’intera popolazione o un elemento selezionato. I revisori devono capire la popolazione da cui selezionano i campioni; una cartella che contiene solo esempi riusciti non è sufficiente.

Preferite registrazioni che conservano autore, marcatura temporale, azione ed esito. Proteggete le evidenze da modifiche non autorizzate ed evitate di esporre inutilmente dati dei clienti. Quando è necessario oscurare informazioni, preservate un contesto sufficiente perché il revisore capisca che cosa dimostra la registrazione.

Separare i controlli ereditati dagli obblighi che restano a vostro carico

L’assurance di un provider di infrastruttura può supportare la sicurezza fisica o i controlli della piattaforma sottostante. Non dimostra che l’autorizzazione a livello di tenant della vostra applicazione funzioni. Documentate la dipendenza, il perimetro del report pertinente, il periodo, le eccezioni e le responsabilità che il vostro team deve comunque adempiere.

Anche i controlli complementari dei clienti richiedono una formulazione pratica. «Il cliente è responsabile della sicurezza» è troppo generico. Specificate attività come l’amministrazione degli utenti del tenant, la configurazione della federazione delle identità o la revisione delle policy di accesso controllate dal cliente. Mantenete coerenti queste responsabilità tra descrizione del sistema, documentazione del servizio e accordi contrattuali.

Gestire la preparazione come un programma di ingegneria

Iniziate con una gap analysis rispetto ai criteri concordati. Distinguete l’implementazione mancante dalle evidenze mancanti: richiedono rimedi diversi. Una revisione non documentata può richiedere registrazioni migliori; una revisione degli accessi mai avvenuta richiede un controllo operativo.

Assegnate a ogni lacuna un responsabile, un’azione di remediation, le dipendenze e una data obiettivo. Date priorità alle questioni che riguardano separazione dei tenant, accessi privilegiati, modifiche in produzione, risposta agli incidenti e ripristinabilità in base ai rischi del servizio, non semplicemente alle attività documentali più facili.

Prima del periodo Type 2, verificate che i controlli ricorrenti abbiano pianificazioni praticabili e registrazioni durevoli. Accertate chi li esegue in caso di assenze o turnover del personale. Per i controlli attivati da eventi, come la cessazione di un account, assicuratevi che la popolazione degli eventi scatenanti possa essere identificata.

Svolgete un walkthrough di prontezza con evidenze rappresentative. Seguite una modifica dalla richiesta al deployment, un amministratore in uscita fino alla revoca e un’esercitazione di ripristino fino all’azione correttiva. Così emergono passaggi di consegne interrotti che una revisione delle policy può non cogliere.

Durante l’esame, mantenete un registro delle richieste con responsabili e stato delle risposte. Tenete disponibili le registrazioni originali, spiegate apertamente le discrepanze e tracciate la remediation separatamente dalle evidenze storiche. Non riscrivete le vecchie registrazioni per farle apparire conformi. È il revisore a stabilire come le risultanze incidono sui test e sul giudizio.

Esempio pratico: un’applicazione gestita su infrastruttura esterna

Supponiamo, a titolo illustrativo, che un provider gestisca un’applicazione multi-tenant in una regione, utilizzi un provider di infrastruttura esterno e punti a un’assurance Type 2. Il suo team controlla i rilasci applicativi, i permessi dei tenant, l’amministrazione della produzione e le procedure di ripristino.

La descrizione del perimetro individua applicazione, database, piano di gestione, strumenti di supporto e dipendenza infrastrutturale. Spiega quali controlli sottostanti sono ereditati e quali restano in capo al provider dell’applicazione.

Per l’isolamento dei tenant, il team registra la progettazione delle autorizzazioni, i test negativi automatizzati, le risultanze dei test di sicurezza e le approvazioni dei rilasci. Conserva inoltre le registrazioni delle modifiche che mostrano quando è cambiata la logica di autorizzazione. Il report dell’infrastruttura è un’evidenza di supporto relativa alla dipendenza, non una prova dell’isolamento applicativo.

Per gli accessi privilegiati, il team conserva la popolazione degli amministratori, le approvazioni delle concessioni, le decisioni di revisione e le registrazioni delle rimozioni. Supponiamo che una revisione scopra un account di supporto inutilizzato. Il team registra la scoperta, la revoca, la valutazione dell’esposizione e l’azione preventiva. Ciò è più credibile che presentare solo l’elenco degli account già ripulito.

Per il ripristino, conserva il risultato di un test di ripristino che mostra che cosa è stato recuperato, il tempo trascorso, le verifiche di integrità dei dati e i limiti irrisolti. Un job di backup configurato, da solo, non dimostra la ripristinabilità. Ogni insieme di evidenze ha un responsabile e un periodo definito, così che il revisore possa collegare le registrazioni al controllo esaminato.

Riutilizzare il lavoro di assurance senza dichiarare equivalenze

La ISO/IEC 27001 riguarda un sistema di gestione della sicurezza delle informazioni con un perimetro definito. SOC 2 è un report di attestazione con criteri e contesto di reporting propri. Il C5 si concentra sull’assurance dei servizi cloud secondo il catalogo del BSI.

Valutazioni del rischio, controlli di accesso, procedure di gestione degli incidenti e registrazioni operative esistenti possono supportare più di un programma. Riutilizzateli attraverso mappature specifiche per versione e perimetro, poi verificate le differenze nei requisiti o nel reporting. Un controllo condiviso non è un’equivalenza automatica tra framework.

Scegliete il portafoglio di assurance in base ai requisiti effettivi dei clienti e ai rischi del servizio. Il C5 non è universalmente obbligatorio per ogni cloud provider; i requisiti di gara, contrattuali o settoriali applicabili richiedono una verifica separata. Né un report C5 né un altro documento di assurance stabiliscono di per sé la conformità al GDPR o alla NIS2.

Preparare il report per le decisioni dei clienti

I clienti hanno bisogno della descrizione del sistema, della data o del periodo, del giudizio effettivo, delle eccezioni e dei confini di responsabilità, non solo dell’etichetta del report. Quando condividete i report, rispettate la riservatezza contrattuale e fornite il contesto per la valutazione del cliente.

Spiegate lo stato della remediation senza lasciare intendere che le correzioni successive modifichino il giudizio relativo al periodo passato. Se il periodo del report precede un’importante modifica architetturale, segnalate questo limite. Concordate esami ricorrenti in funzione delle aspettative dei clienti e dei cambiamenti operativi, invece di trattare l’attestazione come una credenziale senza scadenza.

Secani aiuta i team a collegare l’implementazione dei controlli e le evidenze a requisiti revisionati. Modellate il servizio e le dipendenze, assegnate responsabili e revisori, collegate le registrazioni a supporto e trasformate le lacune nelle evidenze in attività. Mantenete esplicita l’approvazione umana per mappature e conclusioni. Il modello di preparazione agli audit aiuta a preservare il perimetro e le responsabilità alla base di ogni affermazione.

Domande da risolvere prima del primo esame

È il BSI a emettere il report?

Il BSI pubblica il catalogo. Un revisore indipendente svolge l’esame ed emette il report di attestazione; verificate con quel revisore il framework di assurance applicabile e le condizioni dell’incarico.

E se non si è verificato alcun incidente reale?

Non inventate una registrazione di incidente. Conservate le evidenze che il processo è stato implementato e, ove opportuno, messo alla prova con esercitazioni. Concordate con il revisore come l’assenza di eventi incide sui test.

Che cosa deve fare il team come passo successivo?

Prendete un servizio di produzione rappresentativo e preparatene la descrizione del perimetro, la matrice delle responsabilità e il registro delle evidenze. Esaminate questi tre deliverable con il potenziale revisore prima di assemblare un ampio pacchetto di evidenze.