Dichiarazione di sicurezza

Questa dichiarazione descrive le misure tecniche e organizzative che proteggono il servizio RavSolutions e i dati in esso conservati. È scritta per poter essere verificata: indica misure effettivamente attuate, e la sezione 15 dichiara con altrettanta chiarezza ciò di cui non disponiamo.

Non è una garanzia e non crea alcun impegno sui livelli di servizio; le condizioni contrattuali sono nei Termini e Condizioni. Dove la stessa misura compare anche nell'informativa GDPR o nell'informativa sul trattamento per conto altrui, deve dire nella sostanza la stessa cosa.

Riguarda il servizio che gestiamo noi. La sicurezza degli account, dei dispositivi e delle password all'interno dello spazio di lavoro di un abbonato spetta all'abbonato; nessuna misura qui descritta protegge uno spazio di lavoro le cui credenziali siano state condivise o riutilizzate altrove.

Il servizio è composto da tre interfacce — il sito web, l'applicazione e il portale clienti —, da una sola API, da una banca dati PostgreSQL, da un'istanza Redis e dall'archiviazione a oggetti. Le interfacce raggiungono l'API soltanto tramite HTTPS.

Tutto, tranne l'archiviazione a oggetti, funziona dietro un proxy inverso sull'infrastruttura di RackForest Zrt. in Hungary (EU). La banca dati e Redis sono collegate a una sola rete interna e non pubblicano alcuna porta, quindi non sono raggiungibili da Internet; soltanto l'API può comunicare con esse.

I file caricati non risiedono sui server applicativi ma nell'archiviazione a oggetti Cloudflare R2, configurata per European Union. Il bucket è privato: nessun accesso pubblico, nessun dominio proprio anteposto, e ogni file viene servito tramite un collegamento firmato dall'API.

I segreti — credenziali della banca dati, chiavi di firma, chiavi API dei fornitori — sono forniti dall'ambiente al momento del rilascio e non finiscono mai nel repository del codice sorgente.

Tutto il traffico verso il sito, l'applicazione, il portale e l'API viaggia su HTTPS. I certificati sono emessi e rinnovati automaticamente da Let's Encrypt e le richieste HTTP in chiaro vengono reindirizzate a HTTPS.

Il proxy inverso invia HTTP Strict Transport Security con validità di un anno, sottodomini inclusi e con preload, così che un browser che ha già visitato il sito non torni a una connessione non cifrata.

Le risposte recano X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, una referrer policy strict-origin-when-cross-origin e una permissions policy che nega fotocamera, microfono e geolocalizzazione. Le intestazioni che identificano server e framework vengono rimosse. L'API accetta richieste cross-origin soltanto dalle origini dell'applicazione e del portale.

Il sito web, l'applicazione e il portale sono serviti con una Content Security Policy. Gli script possono essere caricati solo dal servizio stesso e, nell'applicazione, anche da Google Identity Services per l'accesso con Google; il sito web e il portale non ammettono alcuno script di terze parti. L'inserimento in un frame, i contenuti dei plugin e la riscrittura della base del documento sono rifiutati, e l'API risponde con una politica che non consente nulla.

La password deve avere almeno otto caratteri e contenere una lettera maiuscola, una minuscola e una cifra. Le password sono conservate soltanto come impronta crittografica con sale prodotta dall'algoritmo di ASP.NET Core Identity, mai in forma rileggibile: per questo non possiamo restituire una password dimenticata, ma solo farne impostare una nuova.

Dopo dieci tentativi di accesso falliti l'account viene bloccato per quindici minuti. Il conteggio è tenuto sull'account e non su chi effettua la chiamata, così anche un tentativo distribuito su molti indirizzi viene fermato, benché ciascun indirizzo resti sotto il limite per chiamante.

È possibile accedere con un account Google. Il token di identità emesso da Google viene verificato presso Google prima di creare qualsiasi sessione, e la password Google non ci arriva mai.

La registrazione invia un messaggio di conferma all'indirizzo indicato, che risulta confermato quando viene usato il collegamento in esso contenuto. La password dimenticata si reimposta tramite un collegamento monouso inviato all'indirizzo registrato; una reimpostazione riuscita rimuove anche un blocco in corso, poiché di norma è proprio il blocco a motivarla.

I token di accesso sono JSON Web Token validi quindici minuti. A ogni richiesta si verificano emittente, destinatario, firma e scadenza, senza alcuna tolleranza di scostamento dell'orologio.

Il token di aggiornamento è composto da sessantaquattro byte prodotti da un generatore crittografico di numeri casuali. La banca dati conserva soltanto la sua impronta SHA-256, cosicché il token stesso non è estraibile da una copia della banca dati.

Ogni aggiornamento sostituisce il token: il precedente viene revocato e ne viene emesso uno nuovo. I token di aggiornamento scadono dopo trenta giorni e la disconnessione revoca il token immediatamente.

L'aggiornamento è rifiutato se l'utente è stato disattivato o lo spazio di lavoro reso inattivo: la revoca di un accesso ha quindi effetto al più tardi alla scadenza del token di accesso in corso.

Ogni utente ha un ruolo nello spazio di lavoro e gli endpoint lo verificano. Le funzioni legate al piano sono inoltre protette da apposite politiche di autorizzazione, così che una funzione estranea al piano sottoscritto venga rifiutata dall'API e non semplicemente nascosta nell'interfaccia.

Gli spazi di lavoro sono separati a livello di dati: ogni registrazione reca l'identificativo dello spazio cui appartiene e ogni interrogazione è circoscritta allo spazio di chi la esegue. Una registrazione di un altro spazio non viene nascosta dal risultato: non vi entra affatto.

Lo spazio di lavoro è ricavato da un claim del token di accesso firmato ed è risolto sul server. Nessun identificativo di spazio trasmesso dal client è ritenuto attendibile, per alcuna finalità.

Le connessioni in tempo reale usano la stessa autenticazione del resto dell'API; una connessione priva di token valido viene rifiutata, la dimensione dei messaggi in ingresso è limitata e le informazioni dettagliate sugli errori sono restituite solo in ambiente di sviluppo.

Il cliente riceve un collegamento contenente un token generato casualmente, riferito a un solo lavoro e dotato di data di scadenza. Il token apre quell'unico lavoro e nient'altro dello spazio di lavoro.

Prima che il lavoro venga mostrato, il visitatore deve confermare l'indirizzo e-mail o il numero di telefono registrati per quel cliente. Una conferma riuscita produce una prova valida dodici ore, firmata con HMAC mediante una chiave derivata dal segreto di firma del server ma da esso crittograficamente indipendente, e verificata a tempo costante.

I tentativi di conferma sono limitati per chiamante e deliberatamente non per token: limitare per token consentirebbe a chiunque di escludere un cliente dal proprio lavoro semplicemente esaurendone il budget.

I caricamenti sono limitati a un elenco fisso di tipi di file — JPEG, PNG, WebP, PDF, DOCX, XLSX e testo semplice — e a una dimensione massima che dipende dal piano sottoscritto. Le immagini vengono ricodificate sul server prima di essere conservate.

I file sono serviti tramite collegamenti firmati di breve durata generati dall'API. Poiché il bucket è privato, un collegamento scaduto o alterato non dà accesso a nulla.

Caricamento e download hanno limiti distinti per chiamante, così che un collegamento trapelato o un client fuori controllo non possano consumare senza fine spazio di archiviazione e banda.

I file conservati sono cifrati a riposo dal fornitore dell'archiviazione.

L'API applica limiti di frequenza partizionati per chiamante: per spazio di lavoro e utente indicati nel token quando c'è, altrimenti per indirizzo del client. Accesso, accesso con Google, reimpostazione della password e conferma del portale sono limitati a dieci tentativi al minuto; la registrazione a cinque.

I limitatori leggono l'indirizzo reale del chiamante dalle intestazioni inoltrate dal proxy, e solo al proxy stesso è riconosciuto il potere di impostarle. Senza questa configurazione ogni richiesta sembrerebbe provenire dal proxy e un unico budget sarebbe condiviso da tutti: la protezione diventerebbe un'interruzione del servizio.

Il proxy inverso applica davanti all'applicazione un ulteriore limite complessivo, così che il traffico sia contenuto prima ancora di raggiungere l'API.

I dati in ingresso sono convalidati sul server prima di raggiungere la logica di dominio e gli errori sono restituiti come messaggi strutturati: al client non arrivano tracce di stack, messaggi della banca dati o percorsi interni.

La banca dati e Redis risiedono soltanto nella rete interna e accettano connessioni unicamente dall'API; nessuna delle due è esposta a Internet.

L'archiviazione a oggetti cifra a riposo i file conservati e il bucket non è leggibile pubblicamente.

I backup sono eseguiti regolarmente e il loro ripristino viene collaudato. I dati cancellati al termine di un abbonamento scompaiono dai backup man mano che questi scadono secondo la consueta rotazione e, fino ad allora, non sono utilizzati per alcun'altra finalità.

L'applicazione scrive registri del server e tiene, per ciascuno spazio di lavoro, una cronologia delle attività che indica quale utente ha modificato che cosa e quando. La cronologia è consultabile dall'abbonato all'interno dell'applicazione.

I registri del server, dell'applicazione e di sicurezza sono conservati per 90 giorni, salvo che una singola voce debba essere trattenuta più a lungo per un'indagine di sicurezza in corso.

I registri servono a far funzionare il servizio e a indagare gli incidenti. Non registriamo password, token di sessione né dati delle carte di pagamento.

L'accesso ai sistemi e ai dati di produzione è limitato al personale che ne ha bisogno per l'esercizio o l'assistenza, secondo il principio del privilegio minimo e sotto un obbligo di riservatezza che permane dopo la fine del rapporto.

Le dipendenze di terze parti sono fissate a versioni precise e gestite centralmente, così che una versione si cambi in un solo punto; applichiamo gli aggiornamenti di sicurezza della piattaforma e delle sue dipendenze non appena disponibili.

Le modifiche allo schema della banca dati sono applicate come migrazioni versionate all'avvio del servizio, così che lo schema in produzione corrisponda sempre al codice che vi gira.

I fornitori che trattano dati per nostro conto — hosting, archiviazione a oggetti, recapito delle e-mail, pagamento e fatturazione — sono indicati, con ruolo e regione, alla sezione 5 dell'informativa GDPR e alla sezione 8 dell'informativa sul trattamento per conto altrui.

Un nuovo fornitore è annunciato almeno 30 giorni prima dell'inizio del trattamento, perché l'abbonato che si oppone abbia il tempo di agire.

Teniamo un registro interno delle violazioni dei dati personali e seguiamo una procedura che copre rilevamento, valutazione, contenimento e notifica.

Quando una violazione presenta probabilmente un rischio per i diritti e le libertà delle persone fisiche, la notifichiamo all'autorità di controllo competente senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando ne veniamo a conoscenza (art. 33 GDPR); in caso di rischio elevato informiamo anche gli interessati con linguaggio chiaro (art. 34 GDPR).

Quando agiamo come responsabili del trattamento, informiamo l'abbonato che agisce da titolare senza ingiustificato ritardo dopo esserne venuti a conoscenza e lo assistiamo nei suoi obblighi di notifica.

Nessun servizio online può essere reso assolutamente sicuro. Questa pagina descrive misure, non garanzie, e i Termini e Condizioni non contengono impegni di disponibilità né livelli di servizio.

Non abbiamo né la certificazione ISO/IEC 27001 né una relazione SOC 2, e il servizio non è stato sottoposto a un test di intrusione indipendente. Se ciò dovesse cambiare, sarà dichiarato in questa sezione.

L'autenticazione a due fattori per gli account utente non è ancora disponibile. La sicurezza dell'account poggia quindi sulla robustezza della password, sul blocco dell'account e sui limiti descritti sopra: per questo chiediamo una password non usata altrove.

Il servizio funziona in una sola regione, senza commutazione tra regioni: se quella regione viene meno, il servizio resta indisponibile fino al ripristino. Lo dichiariamo perché una dichiarazione di sicurezza che elenchi soltanto i punti di forza non consente di fondare una decisione.

Se trova una vulnerabilità, scriva a info@ravsolutions.eu indicando la descrizione, i passaggi per riprodurla e l'indirizzo interessato. Confermiamo la ricezione e comunichiamo come intendiamo trattarla.

Le chiediamo di lasciarci una ragionevole possibilità di correggere il problema prima di renderlo pubblico. Durante le prove non acceda a dati non suoi, non li modifichi né li cancelli, non degradi il servizio per gli altri e non impieghi tecniche di ingegneria sociale verso il nostro personale o i nostri fornitori.

Non gestiamo un programma retribuito di ricompense per bug. Non agiremo contro chi segnala in buona fede e nei limiti sopra indicati.

Manteniamo questa dichiarazione aggiornata insieme al servizio. Il numero di versione e la data di entrata in vigore in cima alla pagina indicano quale testo è vigente; le versioni precedenti sono disponibili su richiesta.

Quando una misura qui descritta cambia, questa pagina cambia con essa. Le domande sul contenuto possono essere inviate a info@ravsolutions.eu.