Security Whitepaper

Panoramica architetturale

Claresia è costruita attorno a una rigorosa separazione tra control plane e data plane. Il control plane (console di amministrazione, identity, billing, distribution, catalogo Skill) risiede sempre in Claresia Cloud. Il data plane (record dello Hub — output, decision, governance event, employee profile, telemetry event) può risiedere in Claresia Cloud o nel cloud del Cliente, a seconda della modalità di deployment.

Ogni release Claresia viene rilasciata attraverso un contratto Skill IR versionato (cc-065/schema/skill-ir-v0.json) e lo schema canonico dello Hub (cc-050). Hash di provenance crittografici (SHA-256 su JSON canonico) sono calcolati nel data plane e co-firmati nel control plane per legare i due mondi senza esporre alcun contenuto.

Principi architetturali

• I dati del Cliente non lasciano mai il cloud del Cliente in Modalità C. Il distribution plane gira in Claresia; l'invocazione LLM avviene nel tenant LLM del Cliente; il record dello Hub viene persistito su Postgres / SharePoint / Snowflake gestiti dal Cliente; verso Claresia tornano solo gli envelope di telemetria.
• Zero codice installato nel Cliente al day-1. Le Modalità A e B richiedono soltanto l'inserimento di una API key, una grant a service principal Azure o un'installazione OAuth Slack. Niente agenti, daemon o sidecar.
• Isolamento per tenant by default. Postgres usa Row-Level Security ancorata a app.tenant_id; lo storage oggetti adotta prefissi per tenant; in Modalità B e C ciascun tenant ha la propria chiave KMS ruotabile dal Cliente.
• L'identità è delegata. Claresia non memorizza alcuna password del Cliente. WorkOS è davanti a ogni login; SAML e OIDC supportati al day-1; SCIM 2.0 per il ciclo di vita degli utenti.
• Auditabilità totale. Ogni azione privilegiata emette un record Hub governance_event. Ogni invocazione di Skill emette un output + un telemetry_event. La catena di provenance dello Hub ricostruisce "cosa ha fatto l'IA, per chi, in quale data" fino a 7 anni indietro.

Crittografia

A riposo. Tutti i dati Cliente persistiti in qualsiasi store gestito da Claresia sono cifrati con AES-256 tramite AWS KMS (oppure Azure Key Vault nei deployment con residenza Microsoft). In Modalità B e Modalità C la chiave di cifratura è ruotabile dal Cliente ed è custodita in un key ring KMS denominato dal Cliente. Claresia opera il key ring sotto contratto Customer Lockbox: l'accesso operativo privilegiato richiede un workflow di approvazione documentato con notifica al Cliente.

In transito. Tutti gli endpoint pubblici Claresia terminano TLS 1.3 (TLS 1.2 minimo, perfect forward secrecy obbligatoria). Tutto il traffico inter-servizio interno a Claresia Cloud è mTLS. Il collegamento di Modalità C dal cloud del Cliente al control plane Claresia è mTLS con certificati emessi dal Cliente.

Rilevamento di dati sensibili. Gli output che attraversano lo Hub vengono scansionati alla ricerca di credenziali (chiavi AWS, chiavi Stripe, token GitHub) e marker PCI / PHI — i match vengono redatti nel record persistito ed emersi come governance event.

Architettura di rete

Claresia Cloud opera oggi su due regioni active-active: eu-south-1 (Milano) ed eu-central-1 (Francoforte). Ogni regione è una copia completa del control plane, con replica cross-region solo per dati non riconducibili al Cliente. I dati del Cliente sono fissati per regione per tenant — una volta scelta, la regione resta immutabile per quel tenant.

Tutto il traffico pubblico in ingresso passa da Cloudflare (WAF, protezione DDoS, mitigazione bot, geo-routing). Cloudflare termina TLS al edge e ricifra verso l'origin. Cloudflare non vede payload Cliente in chiaro — terminazione TLS a livello applicativo solo al edge per trust.claresia.com / app.claresia.com / hub.claresia.com.

Tra Claresia Cloud e i fornitori LLM (Anthropic, OpenAI, Vertex AI, Azure OpenAI), l'egress passa per NAT gateway gestiti da Claresia con range IP di egress stabili, allowlistabili nel firewall del Cliente quando desiderato.

Incident response

Claresia opera una rotazione on-call 24/7 in capo al team di Engineering. Gli incidenti vengono classificati alla rilevazione come Severity 1 (impatto sul Cliente), Severity 2 (servizio degradato) o Severity 3 (cosmetico). Il playbook di risposta segue uno schema a cinque fasi:

1. Detect — alert SLO burn-rate o synthetic Datadog; on-call attivato.
2. Triage — incident commander assegnato, Statuspage aggiornata entro 15 minuti per la Sev 1.
3. Mitigate — ripristino del servizio tramite runbook documentato. Aggiornamento ogni 30 minuti.
4. Resolve — root cause confermata, fix in produzione, post-mortem schedulato.
5. Post-mortem — pubblicato entro 5 giorni lavorativi per ogni Sev 1 o Sev 2; remediation tracciate fino a chiusura.

In caso di incidente di sicurezza confermato che impatti dati Cliente, il Security Lead di Claresia assume il ruolo di incident commander e i Clienti vengono notificati entro 72 ore ai sensi dell'art. 33 GDPR — di norma molto prima. Le notifiche includono categoria di dato impattata, perimetro Cliente, root cause e stato della remediation.

Backup e disaster recovery

Tutti i cluster Postgres usano point-in-time recovery (PITR) con finestra di 7 giorni in Modalità A e 35 giorni in Modalità B. Snapshot giornalieri automatici sono trattenuti per 90 giorni. Gli snapshot sono cifrati con la stessa CMEK del cluster live.

RPO (Recovery Point Objective): 5 minuti (granularità PITR per la produzione). RTO (Recovery Time Objective): 1 ora per la Modalità A, 30 minuti per la Modalità B. Drill di DR trimestrali validano entrambe le metriche e producono evidenze per SOC 2.