Een kluis waarover je kunt redeneren, ook over waar hij ophoudt

Vragen die je krijgt

Het meeste beveiligingswerk rond secrets is vragen beantwoorden. Wie kan production lezen? Wie heeft dat echt gedaan? Wat zou een inbraak bij de hosting blootleggen? Wat is er veranderd nadat iemand vertrok?

De taak is die antwoorden te hebben in een vorm die je aan een auditor, een klant of je raad van bestuur kunt laten zien.

Wat je kunt beweren, en waarom het klopt

• De server kan geen waarden lezen. Versleuteling gebeurt alleen in de browser en in de agent crunu. De server bewaart versleutelde data, publieke sleutels en ondertekende documenten, en heeft op geen enkel moment in het protocol een ontsleutelsleutel.
• Een gestolen database opent geen waarden. De accountsleutel wordt met PBKDF2-SHA256 over 1.000.000 iteraties afgeleid van het wachtwoord en een Secret Key van ongeveer 128 bits, en geen van beide bereikt de server. Een volledige kopie van de database is nutteloos om te raden.
• De server kan zichzelf geen toegang geven. Toegangslijsten en elke versie zijn ondertekend. Clients en agents controleren de handtekeningen en weigeren staten die ouder zijn dan de nieuwste die ze hebben gezien. Een apparaat dat de nieuwere staat nooit zag, kan een terugdraaiing niet opmerken.
• Rollen worden met sleutels afgedwongen. Een lid met toegang tot development heeft geen sleutel van production. Een Operator schrijft machines in zonder waarden te zien.
• De log toont geknoei. De auditlog is een hashketen: een record wijzigen, verwijderen of invoegen valt op als je de keten verifieert. Verifieer met één klik, of exporteer JSONL en controleer die buiten Crunu.
• Tonen en kopiëren worden ook gelogd. Als iemand een waarde toont, kopieert of exporteert, wordt de gebeurtenis vastgelegd met de handtekening van die persoon en gemarkeerd als gemeld door de client.
• Een vertrek laat een spoor na. Een lid verwijderen levert een blootstellingsrapport op: welke versies van welke omgevingen de persoon heeft ontvangen, wanneer en vanaf welk adres.
• Je kunt de client controleren die je draait. Releases zijn ondertekend met Ed25519, de webclient is reproduceerbaar te bouwen, en de app controleert bij elke keer laden zijn eigen build tegen de ondertekende release.
• Inloggen heeft een limiet op pogingen. 10 mislukte pogingen per adres en 5 per account in 15 minuten, en ‘geen account’ ziet er hetzelfde uit als ‘verkeerd wachtwoord’. Een sessie duurt 12 uur zonder activiteit en hooguit 7 dagen, en kan zonder het wachtwoord en de Secret Key het wachtwoord niet wijzigen en het account niet verwijderen.
• Tweede factoren op elk account. Codes uit een authenticator-app en passkeys op het web; in de terminal een code uit een app of goedkeuring vanaf een ander apparaat dat is ingelogd.

Algoritmen: AES-256-GCM voor waarden, X25519 voor het versleutelen van sleutels, Ed25519 voor handtekeningen, HKDF-SHA256 voor het afleiden van sleutels. Het beveiligingsmodel legt uit hoe ze samenwerken.

Als er iets niet klopt

• Waarschuwingen gaan af bij inloggen vanaf een nieuw apparaat, een hergebruikte inschrijfcode, een machine op een nieuw adres, een hergebruikt CI-token, een reeks weigeringen, een verlopen lease, inloggen met een herstelcode, certificaten die verlopen, niet-afgeleverde sleutels, en netwerkgebeurtenissen zoals een versoepeld beleid of break-glass-toegang. Ze gaan naar een webhook die met HMAC is ondertekend of naar e-mail.
• Netwerkbeperkingen leveren production alleen aan toegestane adresbereiken. Een beleid versoepelen wacht 15 minuten met een waarschuwing en een mogelijkheid om terug te draaien; break-glass-toegang door een eigenaar duurt tot 60 minuten, vraagt een reden en geeft een waarschuwing.
• Device compromised vervangt de accountsleutels van de persoon, logt de andere apparaten uit en roteert elke omgeving waarvan de persoon een sleutel had.
• Een bewaartermijn die jij bepaalt. De auditlog wordt standaard 365 dagen bewaard, en de organisatie kan die alleen verlengen, tot 36.500 dagen of onbeperkt. Inkorten laat een controlepunt achter, zodat de keten nog steeds te verifiëren is.

Waartegen Crunu niet beschermt

• Een gemanipuleerde webclient is het belangrijkste overgebleven risico, zoals bij elke kluis die in een browser draait: een pagina die een overgenomen server levert, zou bij het inloggen het wachtwoord en de Secret Key kunnen onderscheppen. De verdediging bestaat uit het ondertekende manifest waartegen de app zichzelf bij elke keer laden controleert, en een Content Security Policy met subresource integrity die scripts van derden blokkeert. Die zelfcontrole draait in dezelfde pagina, dus ze betrapt geen server die beide verandert. Handtekeningen steunen op de releasesleutel, dus ze beschermen je niet tegen wie die sleutel heeft.
• Waarden die al gezien zijn, kun je niet terugnemen. Rotatie beschermt nieuwe versies. Geef de waarden zelf opnieuw uit bij elke provider.
• De server ziet metadata: namen van organisaties, projecten, omgevingen en machines, e-mailadressen, de auditlog, en de grootte en tijdstippen van versies.
• De server kan dienst weigeren of schrijfacties laten vallen. Exports, offline kopieën en, als je zelf host, back-ups zijn de verdediging.
• Malware op een apparaat waar sleutels worden ontsleuteld (een keylogger, een browserextensie, root op een machine) kan lezen wat dat apparaat kan lezen.
• Een herstelcode opent een account na een wachttijd zonder tweede factor. De server dwingt de wachttijd af, dus een overgenomen server zou die kunnen overslaan.
• Netwerkbeperkingen worden door de server afgedwongen, niet door versleuteling.
• Eigenaren en admins kunnen bij elke gedeelde omgeving via de herstelsleutel van de organisatie.
• Een overgenomen server die samenwerkt met een verwijderd lid, zou een nieuw apparaat op een oudere staat van de organisatie kunnen houden. Om dit volledig te dichten, zou een extern transparantielog nodig zijn.
• Als de database van de server en de eigen sleutel van de server samen lekken, worden codes uit authenticator-apps verzwakt als tweede factor.
• Geen single sign-on of SCIM.

Elke grens, met wat je eraan doet, staat op de pagina met beperkingen.

Iets gevonden?

Mail naar security@crunu.com. Ons security.txt staat op /.well-known/security.txt.

Verwante documentatie

• Hoe de versleuteling werkt
• Wat de server ziet
• Beperkingen
• Auditlog
• Waarschuwingen
• Netwerkregels
• Een teamlid offboarden