Sicurezza e dati

• Dentro la rete ci sono tutti i dipendenti, i consulenti in VPN e qualunque PC infetto: con credenziali falsificabili chiunque di loro entrerebbe come l'amministratore delegato.
• Per l'assistenza abbiamo spesso un accesso VPN al cliente: credenziali nostre piu accesso di rete nostro sarebbe accesso completo.
• Nella modalita con dominio tecnico borc controlla il DNS del nome e potrebbe puntarlo a un proprio server con certificato valido.
• I questionari di sicurezza dei clienti chiedono se il fornitore puo accedere ai dati, e "solo se e nella vostra rete" non viene accettato come risposta.

Resta un punto di fiducia non eliminabile: il software lo scriviamo e lo aggiorniamo noi, e un rilascio malevolo firmato da noi potrebbe leggere i dati. Le contromisure sono verificabili: chiave di firma offline, rilasci riproducibili, immagini per digest e approvazione manuale degli aggiornamenti per chi la chiede.

• Il manifest con versione, immagini per digest, hash dell'updater e catalogo MCP si firma su un portatile. L'updater accetta solo manifest firmati con quella chiave.
• Niente downgrade: l'updater rifiuta qualunque versione inferiore a quella installata e a quella minima scritta nell'ultimo manifest. L'unico ritorno indietro e il rollback locale dopo un aggiornamento fallito.
• L'elenco firmato delle versioni pubblicate ha una scadenza di 30 giorni: se l'istanza non ne vede uno valido entro quel tempo, lo segnala in amministrazione.
• Finestra di aggiornamento per cliente e, a scelta, approvazione manuale: vale per tutto, correzioni di sicurezza comprese.
• Prima di ogni rilascio con migrazioni si fa una copia del database (snapshot ZFS o pg_basebackup) e, se un servizio non e pronto in tempo, si torna alla versione precedente.

• L'amministratore apre l'assistenza in amministrazione, con durata da 1 a 8 ore e motivo.
• L'updater avvia un tunnel in uscita: nessuna porta aperta verso internet, nessuna connessione in ingresso.
• sshd accetta l'utente di assistenza solo con un certificato SSH firmato dalla CA di assistenza, valido dentro la finestra. La CA e fidata solo durante la sessione: si aggiunge all'apertura e si toglie alla chiusura.
• Il protocollo SSH resta cifrato da un capo all'altro: il tunnel trasporta byte che non puo leggere. Per questo non si usa un registro dei comandi lato cloud.
• La registrazione della sessione (formato asciicast) sta sulla macchina e si riproduce da amministrazione, con chi e quando. Alla scadenza le sessioni si chiudono da sole.

Ogni notte un pg_dump cifrato con age finisce sulla cartella di rete del cliente. La chiave pubblica sta sulla macchina, quella privata la custodisce il cliente: una copia in chiaro scavalcherebbe ogni permesso.

Cancellare un utente cancella conversazioni, collegamenti e token personali, e lascia una traccia con solo un identificativo interno, in due posti: sulla macchina e in un file fuori dai backup. Dopo un ripristino il worker riapplica le cancellazioni da quel file.

Utenti, sessioni, documenti, indice, conversazioni, allegati, token personali e registro attivita stanno sulla macchina del cliente, con le copie cifrate sul suo NAS. borc non ha accesso.

Metriche tecniche dell'istanza e conteggio degli utenti attivi stanno nel database centrale di borc: aggregati e numerici, mai per persona. Ragione sociale, referenti e fatture sono dati di contratto.

La nomina a responsabile del trattamento e limitata ad assistenza e manutenzione, con le misure: firma offline dei rilasci, approvazione manuale degli aggiornamenti su richiesta, accesso di assistenza a tempo e registrato. Il cliente informa i dipendenti e valuta utilizzo e registro attivita con il proprio consulente.