Ein Tresor, den Sie nachvollziehen können, auch dort, wo er aufhört
Crunu ist so gebaut, dass eine Kopie seiner Datenbank keine Werte preisgibt. Zugriff wird mit Schlüsseln durchgesetzt, Änderungen sind signiert, und das Audit-Log ist eine Hash-Kette, die Sie selbst prüfen können. Diese Seite nennt auch, was Crunu nicht schützen kann, denn Ihre Risikobewertung braucht diesen Teil ebenfalls.
Was Teams wie Ihres fragen
Die Fragen, die aufkommen, wenn ein Team wie Ihres seine Secrets an einen Ort bringt. Der Leitfaden unten beantwortet jede davon.
- Was würde ein Einbruch in den Server oder seine Datenbank offenlegen?
- Kann der Betreiber des Tresors selbst unsere Werte lesen?
- Wer kann production heute lesen, und wer hat es tatsächlich getan?
- Kann jemand Einträge im Audit-Log unbemerkt ändern oder löschen?
- Was hat eine ausscheidende Person erhalten, und was müssen wir neu ausstellen?
- Welche Ereignisse lösen eine Warnung aus, und wohin gehen Warnungen?
- Können wir production auf bekannte Netzwerke beschränken?
- Wovor kann dieser Tresor nicht schützen?
Die Teile von Crunu, die das abdecken
Jeder Teil folgt derselben Regel: Der Server bewahrt Chiffretext, öffentliche Schlüssel und signierte Dokumente auf und hat nie einen Schlüssel, der Ihre Werte öffnet.
Verschlüsselter Tresor
Bewahren Sie .env-Dateien, Cloud-Zugangsdaten und API-Schlüssel in Projekten und Umgebungen auf, verschlüsselt auf Ihren Geräten, bevor irgendetwas den Server erreicht.
Mehr erfahren
Audit-Log
Anmeldungen, Freigaben, Versionen, Rotationen und Ablehnungen landen in einem Log als Hash-Kette, das Sie mit einem Klick prüfen und exportieren können.
Mehr erfahren
Offboarding
Wenn jemand geht, liefert der Server der Person nichts mehr aus, die Schlüssel ihrer Umgebungen ändern sich, und ein Bericht zeigt, was sie gesehen hat und was neu auszustellen ist.
Mehr erfahren
Netzwerkregeln
Liefern Sie den Inhalt einer Umgebung nur an erlaubte IPv4- und IPv6-Netze aus, mit signierten Regeln, die sich nicht unbemerkt lockern lassen.
Mehr erfahren
Zugriffskontrolle
Geben Sie jeder Person, Maschine und Pipeline nur die Umgebungen, die sie braucht, mit Rollen, hinter denen Schlüssel stehen und nicht nur Prüfungen auf dem Server.
Mehr erfahren
So funktioniert es für security-verantwortliche
Auf dieser Seite
Fragen, die Ihnen gestellt werden
Die meiste Security-Arbeit an Secrets besteht darin, Fragen zu beantworten. Wer kann production lesen? Wer hat es tatsächlich getan? Was würde ein Einbruch beim Hosting offenlegen? Was hat sich geändert, nachdem jemand gegangen ist?
Die Aufgabe: diese Antworten in einer Form haben, die Sie einem Auditor, einem Kunden oder Ihrem Vorstand zeigen können.
Was Sie sagen können, und warum es hält
- Der Server kann keine Werte lesen. Verschlüsselt wird nur im Browser und im Agenten
crunu. Der Server speichert Chiffretext, öffentliche Schlüssel und signierte Dokumente und hat an keiner Stelle des Protokolls einen Schlüssel zum Entschlüsseln. - Eine gestohlene Datenbank öffnet keine Werte. Der Kontoschlüssel wird mit PBKDF2-SHA256 und 1.000.000 Iterationen aus dem Passwort und einem Secret Key mit etwa 128 Bit abgeleitet, und keines von beiden erreicht den Server. Eine vollständige Kopie der Datenbank nützt zum Raten nichts.
- Der Server kann sich keinen Zugriff gewähren. Zugriffslisten und jede Version sind signiert. Clients und Agenten prüfen die Signaturen und lehnen Stände ab, die älter sind als der neueste, den sie gesehen haben. Ein Gerät, das den neueren Stand nie gesehen hat, kann einen Rollback nicht erkennen.
- Rollen werden durch Schlüssel durchgesetzt. Ein Mitglied mit Zugriff auf development hat keinen Schlüssel für production. Wer die Rolle Operator hat, registriert Maschinen, ohne Werte zu sehen.
- Das Log zeigt Manipulationen. Das Audit-Log ist eine Hash-Kette: Wird ein Eintrag geändert, gelöscht oder eingefügt, zeigt sich das bei der Prüfung. Prüfen Sie mit einem Klick, oder exportieren Sie JSONL und prüfen Sie es außerhalb von Crunu.
- Auch Anzeigen und Kopieren werden protokolliert. Wenn jemand einen Wert anzeigt, kopiert oder exportiert, wird das Ereignis mit der Signatur der Person festgehalten und als vom Client gemeldet markiert.
- Wer geht, hinterlässt einen Nachweis. Das Entfernen eines Mitglieds erzeugt einen Offenlegungsbericht: welche Versionen welcher Umgebungen die Person wann und von welcher Adresse erhalten hat.
- Sie können den Client prüfen, den Sie ausführen. Releases sind mit Ed25519 signiert, der Web-Client wird reproduzierbar gebaut, und die App prüft bei jedem Laden ihren eigenen Build gegen das signierte Release.
- Die Anmeldung ist begrenzt. 10 Fehlversuche pro Adresse und 5 pro Konto in 15 Minuten, und „kein Konto“ sieht genauso aus wie „falsches Passwort“. Eine Sitzung dauert 12 Stunden ohne Aktivität und höchstens 7 Tage und kann ohne Passwort und Secret Key weder das Passwort ändern noch das Konto löschen.
- Zweite Faktoren für jedes Konto. Codes aus Authenticator-Apps und Passkeys im Web; im Terminal ein Code aus der App oder die Freigabe von einem anderen angemeldeten Gerät.
Algorithmen: AES-256-GCM für Werte, X25519 zum Versiegeln von Schlüsseln, Ed25519 für Signaturen, HKDF-SHA256 für die Schlüsselableitung. Das Sicherheitsmodell erklärt, wie sie zusammenspielen.
Wenn etwas verdächtig aussieht
- Warnungen lösen aus bei Anmeldungen von einem neuen Gerät, einem erneut verwendeten Registrierungscode, einer Maschine unter einer neuen Adresse, einem wiederverwendeten CI-Token, einer Reihe von Ablehnungen, einer abgelaufenen Lease, einer Anmeldung per Wiederherstellungscode, ablaufenden Zertifikaten, nicht zugestellten Schlüsseln und Netzwerkereignissen wie einer gelockerten Richtlinie oder Break-Glass-Zugriff. Sie gehen an einen per HMAC signierten Webhook oder per E-Mail.
- Netzwerkbeschränkungen liefern production nur an erlaubte Adressbereiche aus. Eine Lockerung der Richtlinie wartet 15 Minuten, mit Warnung und Möglichkeit zum Rückgängigmachen; Break-Glass-Zugriff durch einen Owner dauert bis zu 60 Minuten, braucht eine Begründung und löst eine Warnung aus.
- „Device compromised“ ersetzt die Kontoschlüssel der Person, meldet ihre anderen Geräte ab und rotiert jede Umgebung, für die sie einen Schlüssel hatte.
- Aufbewahrung, die Sie steuern. Das Audit-Log wird standardmäßig 365 Tage aufbewahrt, und die Organisation kann diese Frist nur verlängern, auf bis zu 36.500 Tage oder unbegrenzt. Beim Kürzen bleibt ein Prüfpunkt erhalten, die Kette lässt sich also weiter prüfen.
Wovor Crunu nicht schützen kann
- Ein manipulierter Web-Client ist das wichtigste verbleibende Risiko, wie bei jedem Tresor, der im Browser läuft: Eine Seite, die ein kompromittierter Server ausliefert, könnte Passwort und Secret Key bei der Anmeldung abgreifen. Die Abwehr besteht aus dem signierten Manifest, gegen das sich die App bei jedem Laden selbst prüft, und einer Content Security Policy mit Subresource Integrity, die Skripte von Dritten blockiert. Diese Selbstprüfung läuft in derselben Seite, also erkennt sie keinen Server, der beides verändert. Die Signaturen beruhen auf dem Release-Schlüssel und schützen daher nicht vor dem, der diesen Schlüssel besitzt.
- Bereits gesehene Werte lassen sich nicht zurückholen. Die Rotation schützt neue Versionen. Stellen Sie die Werte selbst bei jedem Anbieter neu aus.
- Der Server sieht Metadaten: die Namen von Organisationen, Projekten, Umgebungen und Maschinen, E-Mail-Adressen, das Audit-Log sowie Größe und Zeitpunkt der Versionen.
- Der Server kann den Dienst verweigern oder Schreibvorgänge verwerfen. Die Abwehr sind Exporte, Offline-Kopien und, wenn Sie selbst hosten, Backups.
- Schadsoftware auf einem Gerät, auf dem Schlüssel entschlüsselt werden (ein Keylogger, eine Browsererweiterung, Root auf einer Maschine), kann lesen, was dieses Gerät lesen kann.
- Ein Wiederherstellungscode öffnet ein Konto nach einer Wartezeit ohne zweiten Faktor. Die Wartezeit setzt der Server durch, ein kompromittierter Server könnte sie also überspringen.
- Netzwerkbeschränkungen setzt der Server durch, nicht die Verschlüsselung.
- Owner und Admins erreichen jede geteilte Umgebung über den Wiederherstellungsschlüssel der Organisation.
- Ein kompromittierter Server könnte im Zusammenspiel mit einem entfernten Mitglied ein neues Gerät auf einem älteren Stand der Organisation festhalten. Um das vollständig auszuschließen, bräuchte es ein externes Transparenzlog.
- Gelangen die Datenbank des Servers und sein eigener Schlüssel zusammen nach außen, sind Codes aus Authenticator-Apps als zweiter Faktor geschwächt.
- Kein Single Sign-on und kein SCIM.
Jede Grenze und was Sie dagegen tun können, steht auf der Seite zu den Grenzen.
Etwas gefunden?
Schreiben Sie an security@crunu.com. Unsere security.txt liegt unter /.well-known/security.txt.
Verwandte Dokumentation
Fragen aus der Praxis
Nicht dabei? Schreiben Sie an support@crunu.com, und ein Mensch antwortet.
Was bekäme ein Angreifer bei einem Einbruch in den Crunu-Server?
Chiffretext, öffentliche Schlüssel, signierte Dokumente und Metadaten, aber keine Werte. Das ernste Risiko ist ein manipulierter Web-Client, der Personen bei der Anmeldung ausgeliefert wird. Signierte Releases und eine strenge Content Security Policy verringern es, und die Seite zu den Grenzen erklärt den Rest.
Ist Crunu nach SOC 2 oder ISO 27001 zertifiziert?
Crunu beansprucht heute keine Zertifizierung und kein unabhängiges Sicherheitsaudit. Um es zu bewerten, prüfen Sie das Sicherheitsmodell, die Seite zu den Grenzen und Ihr eigenes exportiertes Audit-Log.
Können wir das Audit-Log an unser SIEM senden?
Einen direkten Connector gibt es nicht. Exportieren Sie das Log als JSONL mit Filtern nach Person, Aktion, Umgebung und Zeitraum, und prüfen Sie die Kette außerhalb von Crunu. Warnungen können an jeden Webhook gehen.
Rotiert Crunu Secrets bei unseren Anbietern?
Nein. Rotation in Crunu ersetzt Schlüssel der Verschlüsselung. Werte bei Anbietern werden von Hand neu ausgestellt, und die Checkliste für Neuausstellungen sagt Ihnen, welche.
Können wir alles in unserer eigenen Infrastruktur halten?
Sie können den Crunu-Server selbst auf Docker, Cloudflare Workers, Vercel oder Google Cloud Run betreiben und mit einem Archiv ohne Klartextwerte zwischen ihnen umziehen. Der Server wird nicht als öffentlicher Download angeboten. Schreiben Sie an support@crunu.com.
Unterstützt Crunu SSO oder SCIM?
Nein. Mitglieder melden sich mit Passwort, Secret Key und einem zweiten Faktor an.