Sicurezza
Come proteggiamo i Suoi dati
Le misure tecniche e organizzative in vigore. Questa pagina descrive quanto implementato; le limitazioni pertinenti sono indicate nell'Allegato II del Contratto per il trattamento dei dati.
La presente traduzione è fornita per comodità. In caso di discrepanza, fa fede la versione inglese.
Ultimo aggiornamento:
Crittografia
- Tutte le connessioni sono crittografate in transito con TLS, utilizzando certificati emessi da un'autorità di certificazione pubblica: l'applicazione, l'API e i protocolli di posta (SMTP, IMAP e JMAP).
- I file in Drive, i documenti e le registrazioni delle riunioni sono crittografati da noi, prima di raggiungere il provider di archiviazione, con AES-256-GCM. Il provider memorizza il testo cifrato e non possiede alcuna chiave per decifrarlo.
- Ogni organizzazione dispone di una propria chiave, conservata nell'Unione Europea e avvolta da una chiave master che risiede esclusivamente nell'ambiente del servizio in esecuzione. La cancellazione della chiave di un'organizzazione rende immediatamente illeggibili tutti i file a essa appartenenti — una garanzia più forte della semplice eliminazione di righe.
- Ciò protegge i Suoi file dal provider di archiviazione e da chiunque ottenga una copia dell'archivio. Non si tratta di crittografia end-to-end: noi deteniamo le chiavi, poiché il servizio genera anteprime, modifica documenti nel browser e fornisce link condivisi. Preferiamo dichiararlo piuttosto che lasciare che la parola 'crittografato' possa suggerire il contrario.
- La posta elettronica non è ancora coperta da questa misura. Il contenuto dei messaggi è conservato dal server di posta, che lo legge e scrive direttamente e non passa attraverso il livello sopra descritto. È protetto in transito da TLS e a riposo dalla crittografia del provider e dai controlli di accesso di seguito. L'estensione della nostra crittografia a esso è un lavoro in corso, non qualcosa che dichiariamo oggi.
- I segreti dell'autenticazione a due fattori sono crittografati nel database con una chiave conservata all'esterno di esso.
Controllo degli accessi
- Le password degli account sono memorizzate come hash bcrypt. Le credenziali delle caselle di posta sono conservate dal server di posta e non sono mai memorizzate in chiaro.
- La robustezza della password viene valutata al momento della scelta e le password deboli vengono rifiutate — sia da noi che dal server di posta stesso.
- L'autenticazione a due fattori è disponibile per tutti e può essere resa obbligatoria in tutta l'organizzazione.
- L'accesso ai dati all'interno del servizio è regolato da ruoli e autorizzazioni per singola risorsa. Ogni query sui dati del cliente è vincolata all'organizzazione dell'utente autenticato — è una condizione nella query, non un controllo sullo schermo.
- L'accesso amministrativo all'infrastruttura di produzione è limitato al personale autorizzato e protetto da chiave e secondo fattore.
Sicurezza dell'applicazione
- I cookie di sessione viaggiano solo su HTTPS e non sono accessibili agli script. Le richieste che modificano lo stato richiedono un'intestazione che una richiesta cross-site non può impostare.
- Gli endpoint di autenticazione sono soggetti a limitazione di frequenza, per ostacolare gli attacchi di forza bruta e il riutilizzo di credenziali rubate.
- Segreti e credenziali raggiungono il sistema attraverso l'ambiente e non risiedono nel codice sorgente.
- L'interfaccia di amministrazione del server di posta non è esposta a Internet.
Separazione tra i clienti
- Il servizio è multi-tenant. I dati di ciascuna organizzazione sono separati logicamente: ogni record porta l'identificatore dell'organizzazione proprietaria e ogni query è vincolata da esso.
- Le caselle di posta sono account separati sul server di posta, isolati tra loro dai propri controlli.
Backup
- I database dell'applicazione e della posta — quest'ultimo contenente account, configurazione delle caselle di posta e dati dei messaggi — vengono sottoposti a backup regolarmente su storage a oggetti sotto giurisdizione europea.
- Lo storage a oggetti stesso non è oggetto di backup separato. I file in Drive, le registrazioni delle riunioni e l'originale di ogni messaggio di posta con i suoi allegati si basano sulla durabilità del provider di archiviazione; non esiste una seconda copia sotto il nostro controllo. Lo dichiariamo piuttosto che lasciare che la parola 'backup' copra tutto.
- I backup sono crittografati prima di lasciare il server, con una chiave asimmetrica: il server possiede solo la metà pubblica, quindi può scrivere nuovi backup e non può leggere quelli vecchi. La metà privata è conservata al di fuori dell'infrastruttura di produzione.
- Ogni backup viene verificato come leggibile prima di essere crittografato e memorizzato, e la procedura di ripristino viene testata a partire da una copia crittografata — incluso il controllo che la copia non possa essere letta senza la chiave privata.
Monitoraggio
- La disponibilità di ciascun componente viene misurata continuamente dall'esterno dell'infrastruttura e pubblicata su status.beskos.com.
- L'accesso amministrativo e le operazioni sensibili vengono registrati.
Sviluppo
- Le modifiche al software sono sottoposte a controllo di versione, revisionate prima del rilascio e distribuite tramite una pipeline automatizzata; la cronologia viene conservata.
- Le dipendenze sono bloccate per versione e le immagini sono create da noi a partire da fonti note.
Segnalazione di una vulnerabilità
- Scrivere a security@beskos.com. Accusiamo ricevuta delle segnalazioni entro cinque giorni lavorativi.
- Non perseguiamo i ricercatori che agiscono in buona fede e che non accedono, alterano o conservano dati altrui. Chiediamo tempo per risolvere un problema prima che venga reso pubblico.