Procedura - Backup e ripristino

Scopo Garantire la continuità del servizio SaaS Flowvenue attraverso: 1. backup regolari dei dati critici; 2. verifica periodica della capacità di ripristino;…

Scopo

Garantire la continuità del servizio SaaS Flowvenue attraverso:

  1. backup regolari dei dati critici;
  2. verifica periodica della capacità di ripristino;
  3. un quadro onesto di disaster recovery (DR) coerente con l’infrastruttura cloud effettivamente utilizzata.

Questa procedura è operativa e descrittiva. Non estende il perimetro del certificato ISO/IEC 27001 / 27017 / 27018. Impegni quantitativi verso il cliente (SLA di disponibilità, RTO/RPO contrattuali, penali, finestre di manutenzione) restano definiti nel contratto o negli allegati tecnici della singola commessa, ove presenti.

Quadro di riferimento: Sicurezza delle informazioni — continuità e operatività · Misure di sicurezza — §1.2 / §1.2a · Service management & ITIL 4 · Verifica & Evidenze.

Perimetro e modello di responsabilità

Cosa è in perimetro

Componente Ruolo nel ripristino
Amazon RDS (PostgreSQL) Dati applicativi multi-tenant (configurazioni, processi, istanze, audit trail, ecc.). Fonte primaria di verità per il ripristino dati.
Amazon S3 Allegati, documenti, artefatti statici e materiali compliance/evidenze ove archiviati su object storage.
Amazon ECS + Amazon ECR Compute applicativo (task/servizi) e immagini container necessarie a ripubblicare il servizio dopo un ripristino dati o un guasto di piattaforma.
Amazon VPC / ALB / IAM / CloudWatch Rete, bilanciamento HTTPS, identità infrastrutturale e osservabilità a supporto di diagnosi e ripristino.

Cosa non è “backup Flowvenue” in senso stretto

Dipendenza Nota onesta
Auth0 (IdP UE) Identità e autenticazione utenti SaaS. Il ripristino dell’IdP segue i meccanismi e gli SLA del fornitore; Flowvenue non esegue un backup proprietario del directory Auth0.
Fornitori LLM (es. OpenAI / Anthropic) Inferenza e ZDR/retention secondo accordi col provider; non costituiscono datastore primario dei dati di processo del cliente.
Endpoint aziendali (laptop, ecc.) Coperti da controlli endpoint (es. Microsoft Defender / Intune); non sostituiscono i backup del servizio cloud.

Shared responsibility (AWS)

Regione di produzione: AWS Milano (eu-south-1), Unione Europea. Salvo diversi accordi per progetti dedicati, non è dichiarata una seconda regione attiva di hot-standby multi-region.

Distinzione: backup, ripristino, DR, business continuity

Concetto Cosa significa per Flowvenue
Backup Copia recuperabile dei dati (RDS automated backup / snapshot; oggetti S3 con versioning/lifecycle ove applicabile).
Ripristino (restore) Ricostruire dati e/o servizio da backup (tipicamente: restore RDS da snapshot o PITR, ripristino oggetti S3, ripubblicazione ECS).
Disaster recovery (DR) Capacità di ripristinare il servizio dopo un incidente grave (corruzione dati, errore operativo, guasto di componente, evento regionale limitato). Per Flowvenue il DR è single-region su eu-south-1, basato su meccanismi gestiti AWS + runbook applicativo.
Business continuity (BCP) Continuità organizzativa (comunicazioni, priorità, supporto, alternative operative). Si integra con Incident di servizio, Incident response e Service management & ITIL 4. Una sintesi BCP dettagliata può essere condivisa su richiesta formale.

Obiettivi di ripristino (RTO / RPO) — dichiarazioni oneste

Indicatore Posizione Flowvenue
RPO (perdita dati massima accettabile) Target operativo interno: allineato alla frequenza dei backup automatici RDS (almeno giornaliera) e, ove abilitato, alle capacità di point-in-time recovery (PITR) del servizio gestito. Il valore contrattuale verso un cliente è quello scritto in SLA/allegato, se presente.
RTO (tempo di ripristino del servizio) Dipende dalla natura dell’incidente (solo DB, anche object storage, anche rete/compute) e dalle finestre AWS. Non si pubblica qui un RTO numerico unico per tutti i clienti: ove richiesto in gara o contratto, si formalizza per iscritto dopo validazione operativa.
Disponibilità Obiettivi commerciali generali (es. disponibilità indicativa nei Termini) e SLA dedicati restano contrattuali; questa procedura non li sostituisce.

In sintesi: la procedura garantisce meccanismi e controlli; i numeri vincolanti verso il committente nascono dal contratto.

Policy di backup (produzione)

Database (Amazon RDS)

  1. Sono abilitati i backup automatici del database di produzione con cadenza almeno giornaliera.
  2. La retention dei backup automatici è configurata in console/API AWS e riesaminata periodicamente (valore operativo interno; dettaglio su richiesta formale o in sede di audit).
  3. Ove supportato dalla configurazione dell’istanza, si utilizza il point-in-time recovery per ridurre la perdita dati rispetto al solo snapshot giornaliero.
  4. Snapshot manuali possono essere eseguiti prima di interventi a rischio (migrazioni maggiori, change strutturali), in coerenza con la Procedura - Change e release.
  5. I backup RDS restano nel perimetro del servizio gestito AWS (cifratura at rest secondo configurazione del servizio).

Object storage (Amazon S3)

  1. I bucket rilevanti per allegati e artefatti di servizio adottano cifratura at rest lato AWS.
  2. Ove applicabile alla tipologia di contenuto, sono valutati versioning e lifecycle (retention, transizione, scadenza) per mitigare cancellazioni accidentali e contenere costi/retention.
  3. Materiali di evidenza compliance possono essere archiviati sotto prefissi dedicati (es. compliance/…); non sostituiscono i backup RDS.

Compute e configurazione applicativa (ECS / ECR / codice)

  1. Le immagini necessarie al ripristino del runtime sono in Amazon ECR (o ricostruibili dalla pipeline CI/CD a partire dal repository di codice versionato).
  2. Il “backup” del codice applicativo è il controllo di versione (repository), non uno snapshot ECS.
  3. Il ripristino del servizio dopo un restore dati prevede tipicamente: verifica rete/IAM → restore DB → ripubblicazione task ECS → smoke test.

Cosa non si fa

Attività operative su Flowvenue

  1. Owner: la responsabilità operativa di backup/restore è della funzione operations / infrastruttura (coordinata con sviluppo per restore applicativi). Contatto sicurezza/DPO: mricci@flowvenue.com; intake operativo: info@flowvenue.com.
  2. Monitoraggio: verificare gli esiti dei backup automatici e gli alert di fallimento (CloudWatch / console RDS); intervenire sui fallimenti prima che si accumulino gap di retention.
  3. Change rischiosi: prima di migrazioni o interventi ad alto impatto, valutare snapshot manuale e piano di rollback (Change e release).
  4. Registro: mantenere traccia interna di backup rilevanti, test di restore ed esiti (data, ambito, risultato, tempo osservato, gap rispetto a target interni).
  5. Incidenti: se la perdita/corruzione dati emerge in un incidente di servizio o di sicurezza, applicare anche Incident di servizio o Incident response secondo la natura dell’evento.

Attività su AWS (runbook sintetico)

  1. RDS: Console (o CLI) → verificare backup automatici, retention, ultima finestra di backup, stato PITR; in caso di restore, creare istanza/cluster di ripristino da snapshot o da point-in-time, senza sovrascrivere la produzione finché il restore non è validato.
  2. S3: verificare versioning/lifecycle e, se necessario, ripristinare versioni precedenti di oggetti critici.
  3. ECS/ECR: assicurare disponibilità dell’immagine corretta e ripubblicare il servizio verso l’ambiente target dopo la validazione dati.
  4. IAM / Security Group / VPC: confermare che l’istanza ripristinata sia raggiungibile solo dalle reti/ruoli previsti (least privilege).
  5. CloudWatch: correlare metriche/log per confermare stabilità post-restore.

Test di ripristino (obbligatorio)

Aspetto Impegno
Frequenza minima Almeno una volta all’anno, e comunque dopo cambi infrastrutturali rilevanti (nuovo cluster DB, cambio modello di storage, major migration).
Ambiente Preferibilmente non produttivo (istanza/ambiente di prova creato da snapshot o PITR). Evitare overwrite accidentale della produzione.
Cosa si valida Accessibilità del DB ripristinato; integrità di un campione di tabelle/dati critici; avvio del runtime applicativo (ove nel perimetro del test); tempo complessivo osservato (input al riesame RTO interno).
Output Verbale / registro prova di ripristino (data, esecutore, ambito, esito, tempi, anomalie, azioni correttive). Disponibile su richiesta formale per audit o committenza, con proporzionalità e riservatezza.

Un test annuale soddisfa l’aspettativa tipica dei questionari fornitore sul “DR/backup testato almeno annualmente”; non equivale a un esercizio full multi-region se quest’ultimo non è implementato.

Scenario di ripristino tipico (esempio)

Ipotesi: corruzione o cancellazione accidentale di dati su database di produzione, senza compromissione di sicurezza in corso.

  1. Classificare l’evento (servizio vs sicurezza) e aprire tracking.
  2. Congelare interventi rischiosi; comunicare internamente lo stato.
  3. Individuare il punto di ripristino (snapshot o PITR) con il miglior compromesso RPO.
  4. Ripristinare su istanza di validazione (o ambiente dedicato); verificare sample dati e applicativo.
  5. Solo dopo validazione: promuovere il ripristino secondo runbook interno (cutover controllato).
  6. Smoke test, monitoraggio CloudWatch, chiusura con verbale e lezioni apprese.

Output documentali

Riesame

La procedura è riesaminata almeno annualmente, oppure dopo:

Ultimo aggiornamento: ottobre 2026