Modello di sicurezza: il server conserva solo testo cifrato

Crunu cifra il contenuto di ogni ambiente nel tuo browser o nell’agente crunu prima che venga inviato qualsiasi dato. Il server conserva testo cifrato, chiavi pubbliche e record firmati, e in nessun punto del protocollo possiede una chiave in grado di decifrarli.

Su app.crunu.com, quel server lo gestisce Crunu. Se ospiti Crunu in proprio, lo gestisci tu. In entrambi i casi il server non può leggere i tuoi valori. Crunu è in accesso anticipato, quindi descriviamo solo ciò che fa la versione attuale e aggiorniamo questa pagina quando cambia.

In breve

• I tuoi ambienti vengono cifrati sui tuoi dispositivi. Il server conserva solo testo cifrato e non ha alcuna chiave per leggerlo.
• La password e la Secret Key non lasciano mai il tuo dispositivo, quindi un database rubato non aiuta nessuno a indovinarle.
• Ogni ambiente ha la propria chiave. Persone, macchine e token CI ricevono solo gli ambienti che sono stati loro concessi.
• Elenchi di accesso e versioni sono firmati, quindi il server non può aggiungersi come destinatario né modificare i tuoi dati senza che tu te ne accorga.
• Il server vede comunque i metadati: nomi, indirizzi email, il registro di audit e il momento in cui è stata salvata ogni versione.
• Il principale rischio residuo è una pagina web manomessa. Limitazioni note lo descrive insieme a ogni altro limite che conosciamo.
• Non pubblichiamo un report SOC 2 né un audit esterno. Hai trovato un problema? Scrivi a security@crunu.com.

Il percorso di un segreto, passo per passo

Segui STRIPE_SECRET_KEY dal momento in cui Priya la salva fino ai programmi che la leggono.

1. Il browser di Priya cifra e firma. La sua password e la sua Secret Key, 26 caratteri casuali creati sul suo dispositivo, vengono combinate nella chiave del suo account, e nessuna delle due viene mai inviata. Quando salva, il browser cifra l’intera nuova versione dell’ambiente, con tutti i file e le variabili che contiene, come un unico record con la chiave di quell’ambiente (AES-256-GCM). Riempie il record fino a blocchi interi da 4 KB, così la dimensione esatta non si vede, e firma la versione a nome di Priya (Ed25519).
2. Il server conserva ciò che non può aprire. Conserva un record cifrato per versione, non uno per valore, insieme all’elenco di accesso firmato che dice chi può leggerlo. Decide a chi consegnare il testo cifrato, ma non ha alcuna chiave per decifrarlo.
3. Un collega riceve solo gli ambienti che gli sono stati concessi. Jonas riceve le chiavi degli ambienti development e staging, ciascuna sigillata con la sua chiave pubblica (X25519). Production non è nel suo elenco di accesso, quindi non riceve mai la sua chiave. Il suo browser verifica ogni firma e ogni numero di versione prima di decifrare.
4. Un server riceve il suo ambiente allo stesso modo. L’agente su api-prod-1 riceve la chiave di production sigillata per quella macchina, verifica ciò che il server ha inviato e tiene in memoria l’ambiente decifrato. Il tuo programma lo riceve tramite crunu run, oppure come file dove li chiedi con crunu pull.
5. Un job CI riceve esattamente la sua parte. Il token di servizio per GitHub Actions può leggere solo web-app / staging. Con un vincolo CI (OIDC), funziona solo dal repository e dal branch che hai scelto.

Su app.crunu.com, il server gira su Cloudflare. La pagina Sub-responsabili elenca ogni azienda che tratta dati per il servizio e cosa può vedere ciascuna.

Nella documentazione: Come funziona la cifratura

Chiavi e algoritmi

Crunu usa componenti standard: AES-256-GCM per cifrare, X25519 per sigillare le chiavi per un destinatario, Ed25519 per firmare, HKDF-SHA256 e PBKDF2-SHA256 per derivare le chiavi. Il browser usa la sua WebCrypto integrata e l’agente la libreria standard di Go. Entrambi sono testati con gli stessi vettori di test.

Se trapela una copia del database, indovinare la tua password a partire da essa non funziona: ogni tentativo richiede anche la tua Secret Key, che non è mai stata sul server, quindi verificare un solo tentativo significa esplorare circa 2¹²⁸ possibilità. I token sono conservati solo come hash con chiave.

Nella documentazione: Emergency Kit e Secret Key · Codice di recupero

Ogni ambiente è sigillato separatamente

• Le organizzazioni sono separate dalle proprie chiavi. Un server può ospitare molte organizzazioni. Ognuna ha le proprie chiavi di firma e di recupero, e le chiavi dei suoi ambienti sono sigillate solo per i membri e le macchine che quell’organizzazione ha certificato.
• L’accesso a development non apre production. Ogni ambiente ha la propria chiave, e chi non ha la chiave di production non può leggere production.
• Specific files significa file specifici. Una persona con quel ruolo, o una macchina impostata su file selezionati, riceve una copia sigillata dei soli file scelti.
• Gli Operator configurano le macchine senza vedere i valori. Non possiedono alcuna chiave d’ambiente. Una persona che possiede la chiave approva l’accesso di ogni macchina.
• Le regole di rete limitano dove arrivano i contenuti. Un ambiente può essere fornito solo a intervalli IP consentiti, per persone, macchine e token allo stesso modo. Allentare una regola richiede un’attesa di 15 minuti con un avviso, a meno che non la firmi un secondo amministratore. Restringerla ha effetto immediato. È una regola applicata dal server, non cifratura.

Nella documentazione: Ruoli nelle organizzazioni e negli ambienti · Regole di rete

Cosa può vedere il server, e cosa no

Anche un server cieco ha bisogno di alcune informazioni: a chi consegnare il testo cifrato e cosa scrivere nel registro di audit. Ecco l’elenco completo.

Leggibile dal server

• I nomi di organizzazioni, progetti, ambienti, macchine, token di servizio, profili di accesso ed elenchi di reti
• I nomi e gli indirizzi email dei membri, e gli indirizzi a cui vengono inviati gli inviti
• Chi ha quale ruolo in quale ambiente, dall’elenco di accesso firmato
• Per ogni versione: il numero, chi l’ha salvata, quando, e la dimensione arrotondata a un multiplo di 4 KB
• Quale versione ha ricevuto ogni persona, macchina e token, quando e da quale indirizzo IP
• Il registro di audit, i tuoi dispositivi e le sessioni, e gli indirizzi IP che usano
• Le tue regole di rete: gli intervalli IP che consenti
• Il segreto della tua app di autenticazione, se ne usi una. Il server verifica i tuoi codici, quindi conserva quel segreto cifrato con una propria chiave.

Solo testo cifrato

• Tutto ciò che c’è dentro un ambiente: nomi e valori delle variabili, nomi dei file, percorsi, contenuti e note. Ogni versione è un unico record cifrato dell’intero ambiente, quindi il server non vede le singole variabili né quale è cambiata.
• I file che invii tramite link di condivisione
• Le chiavi private degli account e dell’organizzazione

Mai inviato al server

• La tua password e la tua Secret Key
• Il tuo codice di recupero. Il server conserva una copia della chiave del tuo account che solo il codice può decifrare.
• Le chiavi private delle macchine, che vengono create sulla macchina e lì restano
• La chiave in un link di condivisione, che si trova dopo il # che i browser non inviano
• I token di servizio stessi. Il server conosce solo le loro chiavi pubbliche.

È questo che intendiamo per server cieco: vede chi e quando, ma niente di ciò che c’è dentro i tuoi ambienti. Su app.crunu.com, l’elenco dei dati leggibili è esattamente ciò che Crunu può vedere, e l’Informativa sulla privacy dice per quanto tempo lo conserviamo. Tieni i segreti fuori dai nomi: un progetto che porta il nome di un accordo non ancora annunciato rivela l’accordo al server, anche se ogni valore al suo interno resta cifrato.

Nella documentazione: Cosa vede il server

Chi può leggere i tuoi segreti

• Le persone a cui concedi l’accesso. I membri ricevono solo gli ambienti che sono stati loro concessi. Nascondere i valori nell’app è una scelta di visualizzazione: chi può decifrare un valore può copiarlo.
• Owner e Admin. Possiedono la chiave di recupero dell’organizzazione, quindi possono aprire ogni ambiente condiviso. Possono aprire anche gli ambienti personali dei membri finché è attiva l’impostazione dell’organizzazione per il recupero degli ambienti personali, che lo è per impostazione predefinita.
• Macchine e CI. Ogni macchina e ogni token leggono solo ciò che è stato loro concesso. I codici di registrazione durano 15 minuti per impostazione predefinita e valgono una sola volta, e approvi una macchina solo dopo aver confrontato l’impronta che crunu enroll stampa su di essa. Una macchina revocata elimina i propri ambienti entro pochi minuti, mentre è online.
• Non il personale di Crunu. Su app.crunu.com, il server lo gestisce Crunu, e il server non ha alcuna chiave. Vediamo i metadati indicati sopra. Per arrivare ai tuoi valori bisognerebbe modificare il codice che gira sul tuo dispositivo, ad esempio con una pagina web manomessa. Limitazioni note spiega questo rischio.
• Chiunque cerchi di entrare in un account. L’accesso consente 10 tentativi falliti per indirizzo IP e 5 per account in 15 minuti, e un’email sconosciuta e una password sbagliata ricevono la stessa risposta. Un nuovo dispositivo richiede il tuo secondo fattore, un’app di autenticazione o una passkey, una volta che lo attivi. Le sessioni terminano dopo 12 ore di inattività e al massimo dopo 7 giorni, e una sessione rubata non può cambiare la tua password, la Secret Key o le chiavi dell’account.

Nella documentazione: Macchine e lease · Legare un token di servizio alla CI con OIDC · Accedere dal terminale

Come vengono costruiti e verificati i rilasci

• Ogni rilascio dell’agente crunu e dell’app web è firmato con una chiave di rilascio Ed25519.
• I rilasci dell’agente sono pubblicati su releases.crunu.com: binari, pacchetti .deb, install.sh e un manifest firmato. L’installer verifica lo SHA-256 del binario dell’agente, e crunu self-update verifica la firma del rilascio con una chiave integrata nell’agente. Il comando di installazione mostrato dall’app web include i checksum del rilascio firmato.
• Crunu pubblica il manifest firmato dell’app web su app.crunu.com. Quando l’app si carica, verifica quella firma e la propria build rispetto al manifest e mostra «Signed build» nella barra laterale. Seleziona il contrassegno per verificare ogni file del sito. Se qualcosa non corrisponde, l’app ti dice di non inserire la password.
• Quella verifica gira in codice consegnato dallo stesso server. Rileva un deployment rotto o mescolato, ma non un server che modifica insieme la pagina e la verifica.
• La build dell’app web è riproducibile: un commit del codice sorgente produce sempre gli stessi file. La pagina non consente script di terze parti e carica il proprio codice con checksum di integrità (CSP e SRI).
• Poche dipendenze: l’agente usa solo la libreria standard di Go, e il codice del browser include un solo pacchetto npm, yaml.

Nella documentazione: Aggiornare crunu con self-update

Backup, disponibilità e uscita

• Su app.crunu.com, il database conserva fino a 30 giorni di cronologia di ripristino presso Cloudflare. Durante l’accesso anticipato non garantiamo alcun livello di disponibilità. Vedi i Termini di servizio.
• Tieni una tua copia. L’app può scaricare una copia offline di ogni ambiente a cui hai accesso. Si apre con la tua password e la Secret Key, senza alcun server. Gli ambienti con restrizioni di rete non sono inclusi.
• Gestiscilo in proprio, o spostati. Lo stesso server gira in Docker su una tua macchina, su Cloudflare Workers, Vercel e Google Cloud Run, e su AWS App Runner negli account che vi hanno ancora accesso. Un unico archivio senza valori in chiaro lo sposta dall’uno all’altro, e lo stesso archivio è il tuo backup. Vedi Self-hosting.

Nella documentazione: Esportazione e copia offline · Backup e ripristino

Cosa viene conservato e per quanto

• Versioni. Ogni ambiente conserva le sue ultime 100 versioni, fino a 64 MB. Ripristinare una vecchia versione la salva come nuova.
• Registro di audit. Accessi, inviti, cambi di ruolo, versioni salvate, rotazioni delle chiavi, macchine, token, link di condivisione e richieste rifiutate finiscono in un registro le cui voci formano una catena di hash. Modificare, cancellare o inserire una voce spezza la catena, e «Verify integrity» lo mostra. Il registro viene conservato per 365 giorni per impostazione predefinita, e gli Owner possono estendere il periodo. I valori non vi compaiono mai, perché il server non li ha.
• Registri di consegna e cancellazione. Il registro di chi ha ricevuto ogni versione viene conservato per 90 giorni dopo l’ultima consegna, poi viene accorpato in un riepilogo. Per cancellare il tuo account servono la password e la Secret Key. Un’organizzazione cancellata diventa subito non disponibile e viene rimossa a lotti poco dopo. L’Informativa sulla privacy contiene la tabella completa.

Nella documentazione: Registro di audit · Versioni e cronologia

Se è il server stesso a essere compromesso

Progettiamo per il caso peggiore: un database violato, un operatore disonesto o un account cloud sottratto, dopo i quali il server può rispondere con qualsiasi cosa. I tuoi dispositivi verificano ciò che invia, quindi anche allora non può leggere i tuoi valori, aggiungersi come destinatario, scambiare una chiave, modificare una versione, rinominare production, spacciare per tua un’organizzazione propria o infilare una chiave diversa quando entra qualcuno. App e agenti ricordano anche lo stato più recente che hanno accettato e rifiutano qualsiasi stato precedente, quindi un elenco di accesso riproposto non riporta indietro chi hai rimosso. Un dispositivo nuovo non ha nulla con cui fare il confronto, quindi alla prima visita non può accorgersi di un ritorno a uno stato precedente.

Ciò che può ancora fare è rifiutare il servizio, leggere i metadati e fornire una pagina web manomessa. Gli avvisi segnalano accessi da nuovi dispositivi, codici di registrazione riutilizzati, token CI riproposti e rifiuti ripetuti. Quando qualcuno se ne va, l’app ruota le chiavi che aveva ed elenca i valori da riemettere. Per un dispositivo rubato, «Device compromised» sostituisce le chiavi del tuo account e ruota ogni ambiente di cui avevi la chiave.

Se veniamo a sapere che app.crunu.com è stato violato, invieremo un’email ai titolari degli account coinvolti senza ingiustificato ritardo: cosa è successo, quali dati sono stati coinvolti e cosa fare. Una violazione del servizio espone testo cifrato e metadati, non i valori nei tuoi ambienti, che non possono essere decifrati senza la tua password e la Secret Key. L’Informativa sulla privacy riporta lo stesso impegno.

Nella documentazione: Offboarding di un collega · Ruotare le chiavi degli ambienti · Avvisi

Cosa dipende da te

La cifratura toglie il server dall’elenco di chi può leggere i tuoi segreti. Alcune cose, però, puoi farle solo tu.

• Stampa l’Emergency Kit quando crei l’account e tienilo lontano dai tuoi dispositivi. Nessuno, noi compresi, può reimpostare la tua password o recuperare la tua Secret Key.
• Crea un codice di recupero e conservalo separato dall’Emergency Kit. Apre il tuo account dopo un periodo di attesa, un’ora per impostazione predefinita, senza il secondo fattore.
• Attiva un secondo fattore e tieni breve il blocco per inattività. Per impostazione predefinita l’app dimentica le tue chiavi dopo 10 minuti senza attività.
• Dai a ogni persona e macchina solo ciò che le serve, e tieni pochi Owner e Admin.
• Quando qualcuno se ne va, riemetti presso ciascun fornitore i valori che ha visto. La rotazione protegge le nuove versioni, non ciò che ha già visto.
• Se l’app avvisa «Build signature doesn’t match: do not enter your password», non inserire la password e avvisa il tuo amministratore.

Nella documentazione: Limitazioni · Blocco e timeout per inattività

Audit e documentazione

Crunu è nuovo e in accesso anticipato. Non ha certificazioni SOC 2 o ISO 27001, e non è stato pubblicato alcun audit esterno.

Questi documenti descrivono come il servizio tratta i dati:

• Informativa sulla privacy: quali dati conserviamo, perché e per quanto tempo
• Sub-responsabili: chi gestisce il servizio con noi, e dove
• Termini di servizio e Politica di uso accettabile

Per le tue verifiche interne, Owner e Admin possono esportare il registro di audit in JSONL e controllarne la catena di hash fuori da Crunu. Quando qualcuno se ne va, il report di esposizione mostra quali versioni di quali ambienti ha ricevuto, quando e da dove, e puoi scaricarlo.

Segnala una vulnerabilità

Scrivi a security@crunu.com con i passaggi per riprodurre il problema. Non includere segreti reali nella segnalazione.

Durante i test, per favore:

• esegui i test solo su account e organizzazioni che hai creato tu, o con il permesso dei loro proprietari;
• non accedere ai dati di altre persone e non conservarli, e avvisaci se li raggiungi per errore;
• non eseguire test di negazione del servizio, non inviare spam e non usare tecniche di ingegneria sociale;
• mantieni le scansioni automatiche abbastanza leggere da non influire sugli altri utenti.

Ti confermeremo di aver ricevuto la segnalazione e ti terremo aggiornato mentre ci lavoriamo. Concorderemo con te una data di divulgazione, di norma entro 90 giorni dalla segnalazione.

La Politica di uso accettabile contiene le regole complete, compreso il nostro impegno a non intraprendere azioni legali per ricerche svolte in buona fede. Lo stesso contatto si trova in security.txt.