Sicurezza e affidabilità

Costruita perché le cose sbagliate non possano accadere.

La conformità alla revisione legale non è una funzione aggiunta tardi. È il pavimento su cui poggia ogni altro pavimento. Qui sotto: come è costruita la piattaforma, dove è ospitata e cosa possiamo — e non possiamo — affermare oggi.

01 / Hosting

Ospitata su Microsoft Azure.

Provider cloud: Microsoft Azure (Azure Container Apps per il livello API, Azure Functions per il livello worker).
Selezione regione: Selezionabile dal cliente al provisioning. Canada Central, Stati Uniti East/West, UE West, Regno Unito South, Australia East disponibili oggi; altre regioni su richiesta.
Residenza dei dati: I dati del cliente restano nella regione scelta. La replica cross-region è solo per i backup, mai per i percorsi di lettura in produzione.
Isolamento di rete: Tutto il traffico inter-servizio passa per integrazione Azure VNet. Nessun servizio espone un endpoint pubblico oltre al gateway API.
Datastore: Azure SQL con Transparent Data Encryption, backup geo-ridondanti, ripristino point-in-time al secondo entro la finestra di retention.
Messaging: Azure Service Bus con managed identity. Niente stringhe di connessione nel codice o in variabili d'ambiente in produzione.

02 / Crittografia

Cifrata a ogni livello.

In transito: TLS 1.3 per tutto il traffico client e inter-servizio. HSTS abilitato. Protocolli più vecchi disabilitati al load balancer.
A riposo: Azure SQL Transparent Data Encryption (AES-256). Cifratura a livello di storage su tutti i blob e i file.
Chiavi per tenant: Key Vault custodisce chiavi a perimetro tenant per qualsiasi dato segnalato come sensibile. Rotazione supportata. Bring-your-own-key nel tier enterprise.
Segreti: Tutte le credenziali e le stringhe di connessione in Azure Key Vault. Nessun segreto nel codice sorgente. I segreti di callback monouso vengono rimossi allo stato terminale.
Backup: Cifrati con le stesse chiavi dei dati in produzione. Gli accessi ai backup sono loggati separatamente da quelli di produzione.

03 / Multi-tenant

Multi-tenant, fatto come si deve.

L'isolamento dei tenant è imposto a livello di servizio, non tramite filtri di query globali. Ogni lettura e scrittura passa OrgId esplicitamente. Un audit legge un solo booleano — è stato applicato OrgId? — invece di una catena di assunzioni sui filtri.

OrgId imposto a ogni chiamata API tramite IOrganizationContext.
SubOrgId opzionale rispettato per il perimetro per dipartimento dove applicabile.
OrgValidationMiddleware rifiuta al confine le scritture con OrgId non corrispondente.
I riferimenti cross-org nei payload restituiscono 400 con il campo errato indicato.
Isolamento a livello riga del database tramite indici a perimetro tenant. Nessuna riga condivisa tra tenant.
Export dati per tenant disponibile su richiesta; nessun lock-in.

04 / Conformità alla revisione legale

Cosa significa davvero «conformità alla revisione legale».

Sola aggiunta, per imposizione

Il libro mastro di magazzino è protetto da trigger INSTEAD OF UPDATE/DELETE e da un REVOKE sulla tabella stessa. Aggirare l'API non aggira il libro mastro.

Tabelle temporali

La maggior parte degli aggregati usa lo storico temporale di SQL Server. Le query a un istante preciso sono native — niente logging d'audit lato applicazione.

Storia delle modifiche firmata

Ogni modifica è attribuita all'utente o al processo che l'ha fatta, firmata e datata in modo immutabile.

Ingestione idempotente

Gli endpoint di movimento di magazzino rifiutano richieste senza Idempotency-Key. Una ripetizione con la stessa chiave restituisce la riga originale.

05 / Postura di conformità

Dove siamo. Dove stiamo andando.

Non rivendicheremo una certificazione che non abbiamo. La tabella qui sotto rispecchia ciò che è realmente vero oggi e ciò che è davvero in roadmap.

Standard	Stato	Dettaglio
Progettazione conforme al GDPR	Conforme	Accesso, cancellazione e portabilità dei dati per gli interessati supportati. DPA disponibile su richiesta.
NIS2 / D.lgs. 138/2024	Architettura compatibile	Per i clienti classificati come soggetti essenziali o importanti dal recepimento italiano della direttiva NIS2: registro eventi immutabile, tracciabilità degli incidenti sugli asset, residenza dati UE selezionabile. Velaurum non è essa stessa in perimetro NIS2; supporta chi lo è.
Progettata sui controlli SOC 2	In corso	Audit di Tipo I previsto nel Q4 2026. I controlli esistenti si mappano sui Trust Services Criteria di SOC 2.
ISO/IEC 27001	In roadmap	Certificazione mirata al 2027 una volta completato SOC 2 Tipo II. Controlli interni costruiti sul framework già oggi.
ISO 55000 (gestione asset)	Progettata in linea	La forma della piattaforma rispecchia la struttura raccomandata dallo standard. Utile per i clienti che mirano essi stessi alla certificazione.
HIPAA	Non perseguita	Attualmente fuori perimetro. Parlaci se il tuo caso d'uso lo richiede.
PCI-DSS	Fuori perimetro	Velaurum non tratta dati di carte di pagamento.

Backup

Spedizione continua dei log di transazione. Ripristino point-in-time al secondo entro 35 giorni (configurabile a 365 giorni nel tier enterprise). Backup completo settimanale geo-replicato.

Disaster recovery

RTO target 4 ore, RPO target 15 minuti. Esercitazione DR annuale con risultati documentati. Post-mortem condiviso col cliente per ogni incidente che superi l'RPO.

Risposta agli incidenti

Reperibilità 24/7 in produzione. Clienti notificati entro un'ora dalla conferma di un incidente significativo. Revisione post-incidente condivisa entro 5 giorni lavorativi.

Una domanda d'acquisto a cui non abbiamo risposto qui?

Mandaci il tuo questionario di sicurezza, il tuo modello DPA o la tua mappatura di controlli specifica. Risponderemo con la risposta vera, non con un'evasione.

Parla con il procurement