Un vault su cui puoi ragionare, compreso il punto in cui si ferma

Le domande che ti faranno

Gran parte del lavoro di sicurezza sui segreti consiste nel rispondere a domande. Chi può leggere production? Chi lo ha fatto davvero? Cosa esporrebbe una violazione dell’hosting? Cosa è cambiato dopo che qualcuno se n’è andato?

Il lavoro è avere queste risposte in una forma che puoi mostrare a un auditor, a un cliente o al tuo consiglio di amministrazione.

Cosa puoi affermare, e perché regge

• Il server non può leggere i valori. La cifratura avviene solo nel browser e nell’agente crunu. Il server conserva testo cifrato, chiavi pubbliche e documenti firmati, e in nessun punto del protocollo possiede una chiave di decifratura.
• Un database rubato non apre i valori. La chiave dell’account si ricava con PBKDF2-SHA256 su 1.000.000 di iterazioni dalla password e da una Secret Key di circa 128 bit, e nessuna delle due raggiunge il server. Una copia completa del database è inutile per indovinare le password.
• Il server non può concedersi l’accesso. Gli elenchi di accesso e ogni versione sono firmati. Client e agenti controllano le firme e rifiutano gli stati più vecchi del più recente che hanno visto. Un dispositivo che non ha mai visto lo stato più recente non può rilevare un ritorno a uno stato precedente.
• I ruoli sono garantiti dalle chiavi. Un membro con accesso a development non ha la chiave di production. Un Operator registra le macchine senza vedere alcun valore.
• Il registro rivela le manomissioni. Il registro di audit è una catena di hash: modificare, eliminare o inserire una voce si vede quando lo verifichi. Verificalo con un clic, oppure esporta il JSONL e controllalo fuori da Crunu.
• Anche mostrare e copiare viene registrato. Quando qualcuno rivela, copia o esporta un valore, l’evento viene registrato con la sua firma e contrassegnato come segnalato dal client.
• Le uscite lasciano una traccia. La procedura di rimozione dei membri produce un report di esposizione: quali versioni di quali ambienti ha ricevuto la persona, quando e da quale indirizzo.
• Puoi verificare il client che usi. Le release sono firmate con Ed25519, il client web si compila in modo riproducibile, e l’app confronta la propria build con la release firmata a ogni caricamento.
• Gli accessi hanno un limite di frequenza. 10 tentativi falliti per indirizzo e 5 per account in 15 minuti, e «nessun account» appare identico a «password errata». Una sessione dura 12 ore di inattività e 7 giorni al massimo, e non può cambiare la password né eliminare l’account senza password e Secret Key.
• Secondi fattori su ogni account. Codici delle app di autenticazione e passkey sul web; nel terminale, un codice dell’app o l’approvazione da un altro dispositivo connesso.

Algoritmi: AES-256-GCM per i valori, X25519 per sigillare le chiavi, Ed25519 per le firme, HKDF-SHA256 per la derivazione delle chiavi. Il modello di sicurezza spiega come si combinano.

Quando qualcosa non torna

• Gli avvisi scattano per accessi da un nuovo dispositivo, un codice di registrazione riutilizzato, una macchina su un nuovo indirizzo, un token CI riproposto, una serie di rifiuti, un lease scaduto, un accesso con codice di recupero, certificati in scadenza, chiavi non consegnate ed eventi di rete come una regola allentata o un accesso break-glass. Arrivano a un webhook firmato con HMAC o per email.
• Le restrizioni di rete forniscono production solo agli intervalli di indirizzi consentiti. Allentare una regola richiede un’attesa di 15 minuti con un avviso e la possibilità di annullare; l’accesso break-glass di un proprietario dura fino a 60 minuti, richiede un motivo e genera un avviso.
• «Device compromised» sostituisce le chiavi dell’account della persona, disconnette i suoi altri dispositivi e ruota ogni ambiente di cui aveva una chiave.
• Una conservazione che controlli tu. Il registro di audit si conserva per 365 giorni per impostazione predefinita, e l’organizzazione può solo estenderla, fino a 36.500 giorni o a tempo indeterminato. La potatura conserva un punto di controllo, quindi la catena si verifica comunque.

Cosa Crunu non può proteggere

• Un client web manomesso è il principale rischio residuo, come per qualsiasi vault che gira in un browser: una pagina fornita da un server compromesso potrebbe catturare password e Secret Key al momento dell’accesso. Le difese sono il manifest firmato con cui l’app si verifica a ogni caricamento e una policy di sicurezza dei contenuti con integrità delle sottorisorse che blocca gli script di terze parti. Questo autocontrollo gira nella stessa pagina, perciò non può accorgersi di un server che modifica entrambi. Le firme dipendono dalla chiave di release, quindi non ti proteggono da chi possiede quella chiave.
• I valori già visti non si possono riprendere. La rotazione protegge le nuove versioni. I valori stessi vanno riemessi presso ciascun fornitore.
• Il server vede i metadati: nomi di organizzazioni, progetti, ambienti e macchine, indirizzi email, il registro di audit e le dimensioni e gli orari delle versioni.
• Il server può rifiutare il servizio o scartare le scritture. La difesa sono le esportazioni, le copie offline e, se ospiti il server in proprio, i backup.
• Un malware su un dispositivo dove le chiavi vengono decifrate (un keylogger, un’estensione del browser, root su una macchina) può leggere ciò che quel dispositivo può leggere.
• Un codice di recupero apre un account dopo un periodo di attesa senza secondo fattore. L’attesa la impone il server, quindi un server compromesso potrebbe saltarla.
• Le restrizioni di rete le applica il server, non la cifratura.
• Proprietari e amministratori possono raggiungere ogni ambiente condiviso tramite la chiave di recupero dell’organizzazione.
• Un server compromesso che collabora con un membro rimosso potrebbe tenere un nuovo dispositivo su uno stato precedente dell’organizzazione. Per chiudere del tutto questa possibilità servirebbe un registro di trasparenza esterno.
• Se il database del server e la sua chiave trapelano insieme, i codici delle app di autenticazione si indeboliscono come secondo fattore.
• Niente single sign-on né SCIM.

Ogni limite, con cosa fare al riguardo, è nella pagina delle limitazioni.

Hai trovato qualcosa?

Scrivi a security@crunu.com. Il nostro security.txt si trova in /.well-known/security.txt.

Documentazione correlata

• Come funziona la cifratura
• Cosa vede il server
• Limitazioni
• Registro di audit
• Avvisi
• Regole di rete
• Offboarding di un collega