Sicurezza #
EthicsPortal tratta dati sensibili dei segnalanti. Questa pagina documenta le specifiche misure tecniche e organizzative che abbiamo adottato. È redatta per i responsabili della compliance, i DPO e i team legali che valutano la piattaforma.
Ultimo aggiornamento: 2026-05-17.
Crittografia dei dati #
Tutti i campi sensibili sono crittografati a riposo mediante Rails ActiveRecord Encryption con crittografia non deterministica (ogni crittografia produce un testo cifrato univoco, impedendo l’analisi dei pattern).
| Campo | Crittografato | Deterministico |
|---|---|---|
| Descrizione della segnalazione | Sì | No |
| Nome del segnalante | Sì | No |
| Dati di contatto del segnalante | Sì | No |
| Corpo del messaggio (comunicazione segnalante–gestore) | Sì | No |
La crittografia non deterministica significa che questi campi non possono essere interrogati per valore a livello di database. Anche con pieno accesso al database, un aggressore non può cercare uno specifico nome di segnalante tra i record.
Tutte le connessioni a EthicsPortal utilizzano HTTPS/TLS. Le richieste HTTP non crittografate vengono reindirizzate.
Anonimato e privacy #
Anonimizzazione degli indirizzi IP #
Le rotte del portale (invio della segnalazione, consultazione del caso, messaggistica) utilizzano un hash SHA256 unidirezionale dell’IP della richiesta esclusivamente per la limitazione delle richieste. L’hash non è reversibile — non è possibile recuperare l’IP originale dal valore memorizzato.
A livello applicativo, l’indirizzo IP grezzo del segnalante non viene memorizzato nel database e i log dell’applicazione per le rotte del portale vengono ripuliti per proteggere l’anonimato dei segnalanti.
Rimozione dei metadati dei file #
I file caricati vengono automaticamente ripuliti dai metadati identificativi prima dell’archiviazione:
| Tipo di file | Metadati rimossi | Metodo |
|---|---|---|
| Immagini (JPEG, PNG, TIFF, WebP) | Dati EXIF: coordinate GPS, modello della fotocamera, numero di serie del dispositivo, autore, marche temporali | Elaborazione immagini Vips |
| Documenti PDF | Autore, applicazione di creazione, cronologia delle modifiche | exiftool nella configurazione di produzione standard |
| File video | GPS, informazioni sul dispositivo, software di registrazione | exiftool nella configurazione di produzione standard |
| File audio | Dispositivo di registrazione, GPS, tag del software | exiftool nella configurazione di produzione standard |
La rimozione dei metadati viene eseguita lato server prima dell’archiviazione. Per i tipi di file gestiti da exiftool, ciò dipende dalla presenza degli strumenti di produzione standard.
Scansione antivirus #
Tutti i file caricati vengono automaticamente sottoposti a scansione antimalware mediante ClamAV , un motore antivirus open source. La scansione avviene lato server in un processo in background dopo il caricamento. I file che non hanno superato la scansione sono bloccati alla consegna e i file infetti vengono rimossi automaticamente.
I file vengono sottoposti a scansione sull’infrastruttura di EthicsPortal — nessun dato dei file viene inviato a servizi di scansione di terze parti.
Anonimato del gestore #
I segnalanti non vedono mai i nomi reali o gli indirizzi email delle persone che gestiscono la loro segnalazione. Tutti i messaggi dei gestori sono visualizzati come “Gestore del caso”. Ciò protegge l’identità del gestore e previene l’ingegneria sociale.
Nessun tracciamento #
EthicsPortal non utilizza cookie di tracciamento di terze parti, pixel pubblicitari o script di fingerprinting. Utilizziamo Cloudflare Web Analytics solo sulle pagine di marketing — è privo di cookie, non raccoglie dati personali ed è pienamente conforme al GDPR. Il portale di segnalazione stesso non ha strumenti di analisi.
Stato attuale delle garanzie #
EthicsPortal attualmente non dichiara su questo sito una certificazione ISO 27001 accreditata. Non pubblica inoltre attualmente un audit indipendente di terze parti dell’architettura di anonimato. Qualora ciò cambi, l’ambito e la data saranno pubblicati qui.
Materiali per la verifica di sicurezza #
I clienti che necessitano di materiali per la verifica in fase di approvvigionamento o legale possono richiederli durante l’approvvigionamento. I materiali disponibili possono includere un DPA firmato, evidenze di registro e fiscali, un questionario di sicurezza compilato e risposte scritte relative alle procedure di backup e ripristino, all’accesso privilegiato in produzione e alla gestione della risposta agli incidenti.
Controllo di accesso #
L’autorizzazione è applicata a livello applicativo mediante le policy di Pundit .
| Ruolo | Può visualizzare le segnalazioni | Può gestire le impostazioni dell’organizzazione | Può assegnare i gestori |
|---|---|---|---|
| Amministratore | Tutte le segnalazioni | Sì | Sì |
| Gestore | Le segnalazioni a cui è assegnato o a cui partecipa | No | No |
- I gestori non possono vedere le segnalazioni a cui non sono né assegnati né partecipanti. I partecipanti sono aggiunti esplicitamente da un amministratore o dall’assegnatario principale (ad esempio, coinvolgendo l’ufficio legale o le risorse umane).
- I segnalanti non hanno un account utente — accedono alla propria segnalazione tramite un ID del caso (
WB-XXXX-XXXX) più un codice di accesso di 6 cifre che scelgono al momento dell’invio. - Ogni azione del controller verifica l’autorizzazione. I tentativi di accesso non autorizzati vengono bloccati e registrati.
Autenticazione a due fattori #
Gli account dei gestori e degli amministratori possono abilitare l’autenticazione a due fattori basata su TOTP tramite qualsiasi app di autenticazione standard (Google Authenticator, 1Password, Authy e alternative compatibili). Una volta abilitata, l’accesso richiede sia la credenziale primaria sia un codice rotante di 6 cifre.
Anche i segnalanti si autenticano con due fattori: l’ID del caso (qualcosa che possiedono) e il codice di accesso scelto al momento dell’invio (qualcosa che conoscono). Il codice di accesso è memorizzato solo come digest bcrypt e non può essere recuperato. La casella di seguito e l’invio di messaggi sono protetti dalla sessione dietro questo controllo, così che un ID del caso trapelato da solo non possa leggere la segnalazione né impersonare il segnalante.
Ciclo di vita delle sessioni #
Ogni sessione autenticata registra last_seen_at a ogni richiesta (con debounce). Gli utenti possono esaminare le proprie sessioni attive, vedere quando ciascuna è stata attiva l’ultima volta, revocare singolarmente qualsiasi sessione o disconnettersi da tutte le altre sessioni contemporaneamente dalle impostazioni dell’account.
Le sessioni scadono automaticamente dopo 14 giorni di inattività. La richiesta successiva da una sessione inattiva distrugge il record lato server, cancella il cookie e impone una nuova autenticazione tramite un nuovo magic link. Un processo notturno ripulisce le sessioni abbandonate sulla stessa scadenza, così che user_agent e ip_address non siano conservati oltre la finestra di inattività anche quando l’utente non ritorna mai.
L’autenticazione tramite magic link limita l’impatto delle sessioni di lunga durata: un cookie di sessione rubato non fornisce una credenziale riutilizzabile e la nuova autenticazione richiede l’accesso all’email.
Accesso dei membri e dismissione #
L’accesso all’organizzazione è applicato al confine della richiesta. Quando un membro viene disattivato:
- L’accesso all’organizzazione è rifiutato immediatamente, anche per gli URL salvati in precedenza.
- Le assegnazioni di segnalazioni aperte vengono annullate.
- Le partecipazioni vengono rimosse.
- La cronologia del registro delle attività attribuibile al membro è preservata.
- Il membro disattivato viene avvisato.
- La riattivazione non ripristina automaticamente l’accesso ai casi precedenti.
L’ultimo amministratore attivo e il proprietario dell’organizzazione non possono essere disattivati. Tutti gli eventi di disattivazione e riattivazione sono scritti nel registro delle attività in sola aggiunta.
Le appartenenze prive di rilevanza ai fini della conformità (nessuna voce nel registro delle attività, nessuna assegnazione, nessuna partecipazione) vengono eliminate definitivamente alla rimozione; le appartenenze con una rilevanza vengono disattivate in modo reversibile affinché il registro delle attività resti risolvibile.
Limitazione delle richieste #
Gli endpoint del portale pubblico sono soggetti a limitazione delle richieste per prevenire abusi e attacchi di enumerazione:
| Endpoint | Limite |
|---|---|
| Invio della segnalazione | 5 ogni 10 minuti per IP anonimizzato |
| Consultazione del caso (ID del caso + codice di accesso) | 10 ogni 3 minuti per IP anonimizzato |
| Invio di messaggi | 10 ogni 3 minuti per IP anonimizzato |
La limitazione delle richieste utilizza l’hash IP unidirezionale descritto sopra — nessun IP reale viene memorizzato.
Audit e conformità #
Registro delle attività in sola aggiunta #
Ogni azione in EthicsPortal è registrata con:
- Marca temporale (UTC)
- Attore (quale utente o processo di sistema ha eseguito l’azione)
- Tipo di azione (segnalazione creata, stato modificato, messaggio inviato, gestore assegnato, segnalazione visualizzata, segnalazione esportata, segnalazione eliminata, ecc.)
Le voci del registro delle attività sono in sola aggiunta. Non possono essere modificate o eliminate da alcun utente, inclusi gli amministratori dell’organizzazione. Il registro delle attività completo è incluso nelle esportazioni dei casi in PDF per la verifica delle autorità.
Conservazione dei dati #
Le organizzazioni configurano il proprio periodo di conservazione: 12, 24, 36, 48 o 60 mesi dopo la chiusura di una segnalazione. Alla scadenza del periodo di conservazione, la segnalazione e tutti i dati associati (messaggi, allegati, voci del registro delle attività) vengono eliminati automaticamente e definitivamente da un processo in background.
Ciò soddisfa i requisiti di limitazione della conservazione del GDPR (art. 5, par. 1, lett. e)) e gli obblighi di conservazione dei registri della Direttiva (UE) 2019/1937 (artt. 17-18).
Protezione CSRF #
Tutti gli invii di moduli sono protetti contro il cross-site request forgery mediante i token CSRF integrati di Rails.
Ciclo di vita di sviluppo sicuro #
EthicsPortal segue un ciclo di vita di sviluppo documentato per le modifiche che toccano il Servizio. Le fasi sono indicate qui affinché un addetto all’approvvigionamento possa mapparle ai controlli A.8.25-A.8.29 della ISO/IEC 27001:2022 (vedi la mappa dei controlli per la mappatura completa).
| Fase | Prassi |
|---|---|
| Architettura e progettazione | Le funzionalità che introducono nuovi flussi di dati personali, sub-responsabili del trattamento o ambiti di autorizzazione sono valutate rispetto agli impegni su crittografia, controllo di accesso e registro delle attività documentati in questa pagina prima dell’implementazione. |
| Revisione del codice | Le modifiche in produzione sono riesaminate rispetto a una checklist di sicurezza scritta (copertura della crittografia, ambito di autorizzazione, emissione del registro delle attività, validazione dell’input, gestione dei segreti) prima del deploy. L’analisi statica viene eseguita a ogni modifica e blocca il merge in caso di errore. |
| Codifica sicura | Il codice utilizza per impostazione predefinita le difese a livello di framework — query parametrizzate tramite ActiveRecord, strong parameters, escaping dell’output nelle viste, token CSRF, crittografia a livello di attributo, autorizzazione Pundit al confine del controller. Le deviazioni richiedono una giustificazione scritta. |
| Test di sicurezza in sviluppo | L’analisi statica (Brakeman
, bundler-audit
, importmap audit) viene eseguita a ogni modifica. I test coprono i percorsi di autorizzazione, gli invarianti della crittografia a riposo, l’emissione del registro delle attività e l’applicazione dei limiti di richieste. Vedi gestione delle dipendenze e delle patch
per la toolchain completa. |
| Separazione degli ambienti | Gli ambienti di produzione e non di produzione sono isolati. Nessun dato personale di produzione viene utilizzato al di fuori della produzione; gli ambienti di staging e sviluppo utilizzano fixture sintetiche. |
| Risposta alle vulnerabilità | Le segnalazioni ricevono avviso di ricevimento entro 2 giorni lavorativi (vedi divulgazione responsabile ). Obiettivi: problemi critici risolti entro 7 giorni, di livello alto entro 30, medio entro 90. I problemi confermati che interessano i clienti attivi sono comunicati tramite il registro degli incidenti quando soddisfano i criteri di ambito del registro. |
Gestione delle dipendenze e delle patch #
EthicsPortal non distribuisce componenti software a fine vita. L’applicazione gira su versioni attivamente supportate di Rails, Ruby, PostgreSQL e del sistema operativo sottostante; le release di sicurezza a monte vengono applicate su base continuativa.
Le dipendenze sono sottoposte a scansione continua in continuous integration:
- Brakeman segnala le vulnerabilità specifiche di Rails a ogni modifica.
- bundler-audit verifica il Gemfile rispetto al Ruby Advisory Database a ogni modifica e nuovamente su base giornaliera, così che i nuovi avvisi pubblicati vengano intercettati anche quando il codice non è cambiato.
importmap auditesegue la scansione delle importazioni JavaScript alla ricerca di vulnerabilità note a ogni modifica e nuovamente su base giornaliera.- Dependabot apre pull request settimanali per le gemme Ruby e le GitHub Actions obsolete, raggruppate per aggiornamenti minor/patch.
I componenti che raggiungono il fine vita a monte vengono sostituiti o aggiornati prima della chiusura della loro finestra di supporto.
Infrastruttura #
| Componente | Fornitore | Posizione |
|---|---|---|
| Server applicativo e database | Hetzner | Norimberga, Germania (UE) |
| Archiviazione dei file | Hetzner Object Storage | Norimberga, Germania (UE) |
| Email transazionali | Mailjet | Francia (UE) |
| Elaborazione dei pagamenti | Stripe | UE |
- Tutto il trattamento dei dati principale avviene all’interno dell’Unione europea.
- Nessun numero di carta di credito o credenziale di pagamento è memorizzato sui server di EthicsPortal. Tutti i dati di pagamento sono gestiti da Stripe.
- Mailjet è utilizzato per le email transazionali (notifiche ai gestori, non rivolte ai segnalanti). Mailjet ha sede in Francia e tratta tutti i dati all’interno dell’UE.
- Il sito di marketing è erogato tramite Cloudflare (CDN, Stati Uniti); i portali di segnalazione e di gestione no. Vedi la pagina sub-responsabili del trattamento per l’elenco completo e le garanzie di trasferimento.
Backup e ripristino #
EthicsPortal opera due livelli di backup complementari, entrambi conservati all’interno dell’UE:
| Livello | Cosa | Dove | Conservazione |
|---|---|---|---|
| Database | Dump PostgreSQL crittografati giornalieri tramite un accessorio Kamal | Hetzner Object Storage, Norimberga (UE) | 7 giorni |
| Server | Snapshot completi del disco dell’host applicativo | Hetzner Cloud, Norimberga (UE) | 7 giorni |
Obiettivi di ripristino. L’obiettivo del punto di ripristino (RPO) è di 24 ore. L’obiettivo del tempo di ripristino (RTO) è di 4 ore. Questi obiettivi figurano anche nell’accordo sul livello di servizio .
Test di ripristino. Un’esercitazione di ripristino viene eseguita automaticamente ogni mese tramite un workflow CI che ripristina l’ultimo dump in un ambiente usa e getta, e su richiesta tramite bin/backup-restore-test. La freschezza dei backup è monitorata continuamente (avviso se il dump più recente è più vecchio di 36 ore).
Crittografia. I dump del database sono crittografati a riposo da Hetzner Object Storage; i campi a livello applicativo crittografati con Rails ActiveRecord Encryption restano crittografati nel dump.
Esame operativo #
Alcuni materiali operativi sono condivisi durante la verifica in fase di approvvigionamento anziché pubblicati per intero sul web aperto, perché contengono dettagli infrastrutturali e di risposta più appropriati per una divulgazione controllata.
Tra gli argomenti disponibili su richiesta durante l’approvvigionamento figurano:
- Riepilogo dell’accesso privilegiato in produzione
- Flusso di lavoro di risposta agli incidenti e contatti per l’escalation
- Risposte su continuità operativa e dismissione/esportazione dei dati dei clienti
Divulgazione responsabile #
Se scopri una vulnerabilità di sicurezza in EthicsPortal, ti preghiamo di segnalarla a security@ethicsportal.eu . Ti chiediamo di:
- Non divulgare pubblicamente la vulnerabilità prima che abbiamo avuto la possibilità di affrontarla.
- Fornire dettagli sufficienti affinché possiamo riprodurre e correggere il problema.
- Non accedere né modificare i dati di altri clienti.
Daremo avviso di ricevimento della tua segnalazione entro 2 giorni lavorativi e ci impegneremo a risolvere prontamente le vulnerabilità confermate.
Ultimo aggiornamento: