Sicherheitsmodell: Der Server speichert nur Chiffretext

Crunu verschlüsselt den Inhalt jeder Umgebung in Ihrem Browser oder im Agenten crunu, bevor irgendetwas gesendet wird. Der Server speichert Chiffretext, öffentliche Schlüssel und signierte Datensätze, und an keiner Stelle des Protokolls besitzt er einen Schlüssel, mit dem er sie entschlüsseln könnte.

Auf app.crunu.com betreibt Crunu diesen Server. Wenn Sie Crunu selbst hosten, betreiben Sie ihn. In beiden Fällen kann der Server Ihre Werte nicht lesen. Crunu ist im Early Access, deshalb beschreiben wir nur, was das aktuelle Release tut, und aktualisieren diese Seite, wenn sich das ändert.

Die Kurzfassung

• Ihre Umgebungen werden auf Ihren Geräten verschlüsselt. Der Server speichert nur Chiffretext und hat keinen Schlüssel, um ihn zu lesen.
• Ihr Passwort und Ihr Secret Key verlassen nie Ihr Gerät. Eine gestohlene Datenbank hilft deshalb niemandem, sie zu erraten.
• Jede Umgebung hat ihren eigenen Schlüssel. Menschen, Maschinen und CI-Tokens erhalten nur die Umgebungen, die ihnen freigegeben sind.
• Zugriffslisten und Versionen sind signiert. So kann sich der Server weder selbst als Empfänger eintragen noch Ihre Daten unbemerkt ändern.
• Der Server sieht weiterhin Metadaten: Namen, E-Mail-Adressen, das Audit-Log und wann jede Version gespeichert wurde.
• Das größte verbleibende Risiko ist eine manipulierte Webseite. Die Seite Bekannte Grenzen führt es auf, zusammen mit allen anderen Grenzen, die wir kennen.
• Wir veröffentlichen weder einen SOC-2-Bericht noch ein externes Audit. Sie haben ein Problem gefunden? Schreiben Sie an security@crunu.com.

Der Weg eines Secrets, Schritt für Schritt

Folgen Sie STRIPE_SECRET_KEY von dem Moment, in dem Priya ihn speichert, bis zu den Programmen, die ihn lesen.

1. Priyas Browser verschlüsselt und signiert. Ihr Passwort und ihr Secret Key, 26 zufällige Zeichen, die auf ihrem Gerät erzeugt wurden, werden zu ihrem Kontoschlüssel kombiniert, und keines von beiden wird je gesendet. Beim Speichern verschlüsselt der Browser die gesamte neue Version der Umgebung, jede Datei und jede Variable darin, als einen einzigen Datensatz mit dem Schlüssel dieser Umgebung (AES-256-GCM). Er füllt den Datensatz auf ganze Blöcke von 4 KB auf, damit die genaue Größe nicht sichtbar ist, und signiert die Version als Priya (Ed25519).
2. Der Server speichert, was er nicht öffnen kann. Er hält einen verschlüsselten Datensatz pro Version, nicht einen pro Wert, zusammen mit der signierten Zugriffsliste, die festlegt, wer ihn lesen darf. Er entscheidet, an wen er den Chiffretext ausliefert, hat aber keinen Schlüssel, um ihn zu entschlüsseln.
3. Ein Teammitglied erhält nur die Umgebungen, die ihm freigegeben sind. Jonas erhält die Umgebungsschlüssel für development und staging, jeweils mit seinem eigenen öffentlichen Schlüssel versiegelt (X25519). Die Umgebung production steht nicht in seiner Zugriffsliste, also erhält er ihren Schlüssel nie. Sein Browser prüft jede Signatur und jede Versionsnummer, bevor er entschlüsselt.
4. Ein Server erhält seine Umgebung auf dieselbe Weise. Der Agent auf api-prod-1 erhält den Schlüssel von production, für diese Maschine versiegelt, prüft, was der Server gesendet hat, und hält die entschlüsselte Umgebung im Arbeitsspeicher. Ihr Programm erhält sie über crunu run oder als Dateien an den Stellen, die Sie mit crunu pull angeben.
5. Ein CI-Job erhält genau seinen Anteil. Das Service-Token für GitHub Actions darf nur web-app / staging lesen. Mit einer CI-Bindung (OIDC) funktioniert es nur aus dem Repository und dem Branch, die Sie gewählt haben.

Auf app.crunu.com läuft der Server bei Cloudflare. Die Seite Unterauftragsverarbeiter nennt jedes Unternehmen, das Daten für den Dienst verarbeitet, und was es jeweils sehen kann.

In der Dokumentation: So funktioniert die Verschlüsselung

Schlüssel und Algorithmen

Crunu verwendet Standardbausteine: AES-256-GCM zum Verschlüsseln, X25519 zum Versiegeln von Schlüsseln für einen Empfänger, Ed25519 zum Signieren sowie HKDF-SHA256 und PBKDF2-SHA256 zum Ableiten von Schlüsseln. Der Browser nutzt sein eingebautes WebCrypto, der Agent die Standardbibliothek von Go. Beide werden mit denselben Testvektoren geprüft.

Gelangt eine Kopie der Datenbank nach außen, lässt sich Ihr Passwort daraus nicht erraten: Jeder Rateversuch braucht zusätzlich Ihren Secret Key, der nie auf dem Server war. Einen einzigen Versuch zu prüfen heißt deshalb, etwa 2¹²⁸ Möglichkeiten zu durchsuchen. Tokens werden nur als Hashes mit geheimem Schlüssel gespeichert.

In der Dokumentation: Emergency Kit und Secret Key · Wiederherstellungscode

Jede Umgebung ist einzeln versiegelt

• Organisationen sind durch eigene Schlüssel getrennt. Ein Server kann viele Organisationen beherbergen. Jede hat eigene Signatur- und Wiederherstellungsschlüssel, und ihre Umgebungsschlüssel werden nur für Mitglieder und Maschinen versiegelt, die diese Organisation zertifiziert hat.
• Zugriff auf development öffnet production nicht. Jede Umgebung hat ihren eigenen Schlüssel, und wer den Schlüssel von production nicht hat, kann production nicht lesen.
• Specific files bedeutet genau diese Dateien. Eine Person mit dieser Rolle oder eine Maschine mit der Zustellung „Selected files“ erhält eine versiegelte Kopie nur der ausgewählten Dateien.
• Personen mit der Rolle Operator richten Maschinen ein, ohne Werte zu sehen. Sie besitzen überhaupt keinen Umgebungsschlüssel. Den Zugriff jeder Maschine gibt eine Person frei, die den Schlüssel besitzt.
• Netzwerkregeln begrenzen, wohin Inhalte gehen. Eine Umgebung lässt sich nur an erlaubte IP-Bereiche ausliefern, für Menschen, Maschinen und Tokens gleichermaßen. Eine Lockerung der Regel greift erst nach 15 Minuten und löst eine Warnung aus, es sei denn, ein zweiter Admin signiert sie. Eine Verschärfung gilt sofort. Diese Regel setzt der Server durch, nicht die Verschlüsselung.

In der Dokumentation: Rollen in Organisationen und Umgebungen · Netzwerkregeln

Was der Server sehen kann und was nicht

Auch ein blinder Server braucht einige Angaben: an wen er Chiffretext ausliefert und was er ins Audit-Log schreibt. Hier ist die vollständige Liste.

Für den Server lesbar

• Namen von Organisationen, Projekten, Umgebungen, Maschinen, Service-Tokens, Zugriffsprofilen und Netzwerklisten
• Namen und E-Mail-Adressen der Mitglieder sowie die Adressen, an die Einladungen gehen
• Wer welche Rolle in welcher Umgebung hat, aus der signierten Zugriffsliste
• Für jede Version: ihre Nummer, wer sie gespeichert hat, wann, und ihre Größe, aufgerundet auf ein Vielfaches von 4 KB
• Welche Version jede Person, jede Maschine und jedes Token erhalten hat, wann und von welcher IP-Adresse
• Das Audit-Log, Ihre Geräte und Sitzungen sowie die IP-Adressen, die sie nutzen
• Ihre Netzwerkregeln: die IP-Bereiche, die Sie erlauben
• Das Geheimnis Ihrer Authenticator-App, falls Sie eine nutzen. Der Server prüft Ihre Codes und speichert dieses Geheimnis deshalb verschlüsselt mit einem eigenen Schlüssel.

Nur als Chiffretext

• Alles innerhalb einer Umgebung: Namen und Werte von Variablen, Dateinamen, Pfade, Inhalte und Notizen. Jede Version ist ein einziger verschlüsselter Datensatz der gesamten Umgebung, daher sieht der Server weder einzelne Variablen noch, welche sich geändert hat.
• Dateien, die Sie über Freigabelinks senden
• Die privaten Schlüssel der Konten und der Organisation

Wird nie an den Server gesendet

• Ihr Passwort und Ihr Secret Key
• Ihr Wiederherstellungscode. Der Server hält eine Kopie Ihres Kontoschlüssels, die nur dieser Code entschlüsseln kann.
• Private Schlüssel von Maschinen, die auf der Maschine erzeugt werden und dort bleiben
• Der Schlüssel in einem Freigabelink. Er steht nach dem #, und diesen Teil senden Browser nicht.
• Die Service-Tokens selbst. Der Server kennt nur ihre öffentlichen Schlüssel.

Das meinen wir mit einem blinden Server: Er sieht, wer und wann, aber nichts innerhalb Ihrer Umgebungen. Auf app.crunu.com ist die Liste des Lesbaren genau das, was Crunu sehen kann, und die Datenschutzerklärung sagt, wie lange wir es aufbewahren. Halten Sie Secrets aus Namen heraus: Ein Projekt, das nach einem unangekündigten Deal benannt ist, verrät dem Server den Deal, auch wenn jeder Wert darin verschlüsselt bleibt.

In der Dokumentation: Was der Server sieht

Wer Ihre Secrets lesen kann

• Personen, denen Sie Zugriff geben. Mitglieder erhalten nur die Umgebungen, die ihnen freigegeben sind. Werte in der App zu verbergen ist eine Frage der Anzeige: Wer einen Wert entschlüsseln kann, kann ihn auch kopieren.
• Owner und Admins. Sie besitzen den Wiederherstellungsschlüssel der Organisation und können deshalb jede geteilte Umgebung öffnen. Auch die persönlichen Umgebungen von Mitgliedern können sie öffnen, solange die Einstellung der Organisation zur Wiederherstellung persönlicher Umgebungen aktiv ist. Das ist die Voreinstellung.
• Maschinen und CI. Jede Maschine und jedes Token liest nur, was ihm freigegeben wurde. Registrierungscodes gelten standardmäßig 15 Minuten und verfallen beim ersten Einsatz, und Sie geben eine Maschine erst frei, nachdem Sie den Fingerabdruck abgeglichen haben, den crunu enroll auf ihr ausgibt. Eine widerrufene Maschine verwirft ihre Umgebungen innerhalb von Minuten, solange sie online ist.
• Nicht die Mitarbeitenden von Crunu. Auf app.crunu.com betreibt Crunu den Server, und der Server hat keinen Schlüssel. Wir sehen die oben genannten Metadaten. Um an Ihre Werte zu gelangen, müsste man den Code ändern, der auf Ihrem Gerät läuft, etwa über eine manipulierte Webseite. Die Seite Bekannte Grenzen erklärt dieses Risiko.
• Alle, die versuchen, in ein Konto zu gelangen. Die Anmeldung erlaubt 10 Fehlversuche pro IP-Adresse und 5 pro Konto innerhalb von 15 Minuten, und eine unbekannte E-Mail-Adresse erhält dieselbe Antwort wie ein falsches Passwort. Ein neues Gerät braucht Ihren zweiten Faktor, eine Authenticator-App oder einen Passkey, sobald Sie einen eingerichtet haben. Sitzungen enden nach 12 Stunden Inaktivität und spätestens nach 7 Tagen, und eine gestohlene Sitzung kann weder Ihr Passwort noch Ihren Secret Key oder Ihre Kontoschlüssel ändern.

In der Dokumentation: Maschinen und Leases · Service-Token per OIDC an CI binden · Anmeldung im Terminal

Wie Releases gebaut und geprüft werden

• Jedes Release des Agenten crunu und der Web-App ist mit einem Ed25519-Release-Schlüssel signiert.
• Releases des Agenten erscheinen unter releases.crunu.com: Binärdateien, .deb-Pakete, install.sh und ein signiertes Manifest. Der Installer prüft die SHA-256-Prüfsumme der Agent-Binärdatei, und crunu self-update prüft die Signatur des Releases mit einem Schlüssel, der in den Agenten eingebaut ist. Der Installationsbefehl, den die Web-App anzeigt, enthält Prüfsummen aus dem signierten Release.
• Crunu veröffentlicht das signierte Manifest der Web-App auf app.crunu.com. Beim Laden prüft die App diese Signatur und ihren eigenen Build anhand des Manifests und zeigt in der Seitenleiste „Signed build“ an. Wählen Sie diese Markierung, um jede Datei der Website zu prüfen. Stimmt etwas nicht überein, weist die App Sie an, Ihr Passwort nicht einzugeben.
• Diese Prüfung läuft in Code, den derselbe Server ausgeliefert hat. Sie erkennt ein fehlerhaftes oder vertauschtes Deployment, aber keinen Server, der die Seite und die Prüfung gemeinsam verändert.
• Der Build der Web-App ist reproduzierbar: Ein Quell-Commit erzeugt immer dieselben Dateien. Die Seite erlaubt keine Skripte von Dritten und lädt ihren eigenen Code mit Integritätsprüfsummen (CSP und SRI).
• Wenige Abhängigkeiten: Der Agent nutzt nur die Standardbibliothek von Go, und der Browser-Code enthält ein einziges npm-Paket, yaml.

In der Dokumentation: crunu mit self-update aktualisieren

Backups, Verfügbarkeit und Ausstieg

• Auf app.crunu.com bewahrt die Datenbank bei Cloudflare einen Wiederherstellungsverlauf von bis zu 30 Tagen auf. Im Early Access sagen wir keine bestimmte Verfügbarkeit zu. Siehe Nutzungsbedingungen.
• Behalten Sie eine eigene Kopie. Die App kann eine Offline-Kopie aller Umgebungen herunterladen, auf die Sie Zugriff haben. Sie öffnet sich mit Ihrem Passwort und Ihrem Secret Key, ganz ohne Server. Umgebungen mit Netzwerkbeschränkung sind nicht enthalten.
• Selbst betreiben oder umziehen. Derselbe Server läuft in Docker auf Ihrer eigenen Maschine, auf Cloudflare Workers, Vercel und Google Cloud Run sowie auf AWS App Runner in Konten, die noch Zugang dazu haben. Ein einziges Archiv ohne Klartextwerte zieht ihn zwischen diesen Plattformen um, und dasselbe Archiv ist Ihr Backup. Siehe Self-Hosting.

In der Dokumentation: Export und Offline-Kopie · Backups und Wiederherstellung

Was aufbewahrt wird und wie lange

• Versionen. Jede Umgebung behält ihre letzten 100 Versionen, bis 64 MB. Wer eine alte Version wiederherstellt, speichert sie als neue.
• Audit-Log. Anmeldungen, Einladungen, Rollenänderungen, gespeicherte Versionen, Schlüsselrotationen, Maschinen, Tokens, Freigabelinks und abgelehnte Anfragen landen in einem Log, dessen Einträge eine Hash-Kette bilden. Das Ändern, Löschen oder Einfügen eines Eintrags unterbricht die Kette, und „Verify integrity“ zeigt das an. Das Log wird standardmäßig 365 Tage aufbewahrt, Owner können die Frist verlängern. Werte erscheinen darin nie, weil der Server sie nicht hat.
• Auslieferungsnachweise und Löschung. Der Nachweis, wer jede Version erhalten hat, wird 90 Tage nach ihrer letzten Auslieferung aufbewahrt und dann zu einer Zusammenfassung verdichtet. Um Ihr Konto zu löschen, brauchen Sie Ihr Passwort und Ihren Secret Key. Eine gelöschte Organisation ist sofort nicht mehr verfügbar und wird kurz darauf schrittweise entfernt. Die Datenschutzerklärung enthält die vollständige Tabelle.

In der Dokumentation: Audit-Log · Versionen und Verlauf

Wenn der Server selbst kompromittiert ist

Wir planen für den schlimmsten Fall: eine kompromittierte Datenbank, ein böswilliger Betreiber oder ein gekapertes Cloud-Konto, nach dem der Server beliebig antworten kann. Ihre Geräte prüfen, was er sendet. Selbst dann kann er Ihre Werte nicht lesen, sich nicht als Empfänger eintragen, keinen Schlüssel austauschen, keine Version ändern, production nicht umbenennen, keine eigene Organisation unterschieben und keinen anderen Schlüssel einschleusen, wenn jemand beitritt. Apps und Agenten merken sich außerdem den neuesten Stand, den sie akzeptiert haben, und lehnen alles Ältere ab. Eine wieder eingespielte Zugriffsliste holt also niemanden zurück, den Sie entfernt haben. Ein ganz neues Gerät hat nichts zum Vergleichen und kann einen Rollback deshalb beim ersten Besuch nicht erkennen.

Was er weiterhin kann: den Dienst verweigern, Metadaten lesen und eine manipulierte Webseite ausliefern. Warnungen melden Anmeldungen von neuen Geräten, wiederverwendete Registrierungscodes, erneut eingereichte CI-Tokens und wiederholte Ablehnungen. Verlässt jemand das Team, rotiert die App die Schlüssel, die die Person hatte, und listet die Werte auf, die neu auszustellen sind. Bei einem gestohlenen Gerät ersetzt „Device compromised“ Ihre Kontoschlüssel und rotiert jede Umgebung, für die Sie einen Schlüssel hatten.

Erfahren wir, dass app.crunu.com kompromittiert wurde, informieren wir die Personen, deren Konten betroffen sind, unverzüglich per E-Mail: was passiert ist, welche Daten betroffen waren und was zu tun ist. Ein Einbruch in den Dienst legt Chiffretext und Metadaten offen, nicht die Werte in Ihren Umgebungen, die sich ohne Ihr Passwort und Ihren Secret Key nicht entschlüsseln lassen. Die Datenschutzerklärung enthält dieselbe Zusage.

In der Dokumentation: Offboarding eines Teammitglieds · Umgebungsschlüssel rotieren · Warnungen

Was in Ihrer Hand liegt

Die Verschlüsselung streicht den Server von der Liste derer, die Ihre Secrets lesen können. Einiges können nur Sie selbst tun.

• Drucken Sie bei der Registrierung Ihr Emergency Kit aus und bewahren Sie es getrennt von Ihren Geräten auf. Niemand, auch wir nicht, kann Ihr Passwort zurücksetzen oder Ihren Secret Key wiederherstellen.
• Erstellen Sie einen Wiederherstellungscode und bewahren Sie ihn getrennt vom Emergency Kit auf. Er öffnet Ihr Konto nach einer Wartezeit, standardmäßig einer Stunde, ohne Ihren zweiten Faktor.
• Aktivieren Sie einen zweiten Faktor und halten Sie die Sperre bei Inaktivität kurz. Standardmäßig vergisst die App Ihre Schlüssel nach 10 Minuten ohne Aktivität.
• Geben Sie jeder Person und jeder Maschine nur, was sie braucht, und halten Sie die Zahl der Owner und Admins klein.
• Wenn jemand geht, stellen Sie die Werte, die die Person gesehen hat, beim jeweiligen Anbieter neu aus. Die Rotation schützt neue Versionen, nicht das, was schon gesehen wurde.
• Warnt die App „Build signature doesn’t match: do not enter your password“, geben Sie Ihr Passwort nicht ein und informieren Sie Ihren Admin.

In der Dokumentation: Grenzen · Sperre bei Inaktivität

Audits und Nachweise

Crunu ist neu und im Early Access. Wir haben keine Zertifizierungen wie SOC 2 oder ISO 27001 und kein externes Audit veröffentlicht.

Diese Dokumente beschreiben, wie der Dienst mit Daten umgeht:

• Datenschutzerklärung: was wir speichern, warum und wie lange
• Unterauftragsverarbeiter: wer den Dienst mit uns betreibt und wo
• Nutzungsbedingungen und Nutzungsrichtlinie

Für Ihre eigenen Prüfungen können Owner und Admins das Audit-Log als JSONL exportieren und seine Hash-Kette außerhalb von Crunu prüfen. Wenn jemand geht, zeigt der Offenlegungsbericht, welche Versionen welcher Umgebungen die Person erhalten hat, wann und von wo, und Sie können ihn herunterladen.

Eine Schwachstelle melden

Schreiben Sie an security@crunu.com und beschreiben Sie die Schritte, mit denen sich das Problem nachstellen lässt. Lassen Sie echte Secrets aus der Meldung heraus.

Wenn Sie testen, bitten wir Sie:

• nur mit Konten und Organisationen zu testen, die Sie selbst angelegt haben, oder mit Erlaubnis der jeweiligen Owner;
• nicht auf Daten anderer Personen zuzugreifen oder sie zu behalten und uns zu informieren, falls Sie versehentlich darauf stoßen;
• keine Denial-of-Service-Tests durchzuführen, keinen Spam zu senden und kein Social Engineering einzusetzen;
• automatisierte Scans so zurückhaltend zu halten, dass niemand sonst beeinträchtigt wird.

Wir bestätigen den Eingang Ihrer Meldung und halten Sie auf dem Laufenden, während wir daran arbeiten. Den Termin für die Veröffentlichung vereinbaren wir mit Ihnen, in der Regel innerhalb von 90 Tagen nach Ihrer Meldung.

Die Nutzungsrichtlinie enthält die vollständigen Regeln, einschließlich unserer Zusage, gegen Sicherheitsforschung in gutem Glauben nicht rechtlich vorzugehen. Denselben Kontakt finden Sie in security.txt.