Sicurezza

Sicurezza e affidabilità.

Una panoramica delle pratiche con cui Cima protegge identità, tenant, dati operativi e flussi tra i servizi, e di come segnalare in modo responsabile eventuali vulnerabilità.

Documento

Leggibile, diretto, operativo.

Sicurezza come proprietà del sistema.

Cima è progettata intorno a tenant separati, identità verificate, autorizzazioni esplicite e confini chiari tra frontend, BFF e servizi backend.

Il principio guida è ridurre l'esposizione dei dati sensibili: il browser comunica con endpoint same-origin quando possibile, mentre token, tenant e autorizzazioni vengono validati lato server.

Separazione logica tra organizzazioni e servizi.
Controlli di accesso basati su ruoli e tenant attivo.
Tracciabilità degli eventi rilevanti per audit e diagnostica.

Identità, sessioni e permessi.

L'autenticazione è delegata a un identity provider OIDC tramite un client pubblico con flusso PKCE, senza segreti lato browser. La sessione è gestita server-side e i token non vengono esposti al client.

Le autorizzazioni non derivano da un singolo segnale isolato: identità, organizzazione attiva e progetto applicativo concorrono alla decisione finale di accesso, validata lato server a ogni richiesta.

Client pubblico OIDC con PKCE, senza credenziali nel browser.
Sessione e token custoditi server-side, mai inoltrati al client.
Ruoli letti da fonte autorevole, non dedotti dal solo token.

Protezione dei dati operativi.

Il traffico tra browser, BFF e servizi backend è cifrato in transito (TLS). I dati di telemetria, configurazione, simulazione e integrazione sono trattati come informazioni operative del tenant, con confini tra organizzazioni che fanno parte del modello applicativo e non solo della UI.

I flussi verso backend distinti passano da un livello BFF che allega il contesto necessario (identità e tenant) e riduce la superficie esposta direttamente al browser.

Traffico cifrato in transito tramite TLS.
Header tenant validati lato server prima del proxy verso i servizi.
Log e diagnostica pensati per supportare l'audit senza diventare rumore.

Continuità, monitoraggio e accessi.

La sicurezza operativa include monitoraggio, riduzione dei privilegi al minimo necessario, gestione delle configurazioni e procedure di backup e ripristino. Le funzioni critiche sono progettate con attenzione a osservabilità e recuperabilità.

Gli accessi interni seguono il principio del minimo privilegio e sono tracciati. In caso di incidente di sicurezza, applichiamo un processo di risposta che include contenimento, analisi e, dove previsto, notifica agli interessati e all'autorità nei termini di legge.

Accessi interni per ruolo e necessità, con tracciamento.
Backup e procedure di ripristino per le funzioni critiche.
Processo di gestione degli incidenti con notifica nei termini di legge.

Segnalare una vulnerabilità.

Accogliamo le segnalazioni di sicurezza secondo un modello di divulgazione coordinata. Se individui una vulnerabilità, scrivici a [email sicurezza] — oppure consulta /.well-known/security.txt (conforme alla RFC 9116) — includendo descrizione, impatto e passi di riproduzione.

Confermiamo la ricezione entro [es. 3 giorni lavorativi] e ti teniamo aggiornato sull'avanzamento. Ti chiediamo di non divulgare pubblicamente la vulnerabilità finché non è stata risolta e di concordare con noi i tempi di pubblicazione.

Se agisci in buona fede e nel rispetto di queste regole, non intraprenderemo azioni legali nei tuoi confronti.

Non accedere, modificare o cancellare dati di altri tenant o utenti.
Non eseguire test che degradino la disponibilità del servizio (DoS, brute force massivo).
Usa solo account di test e fermati al primo segnale di accesso a dati reali.