42escrow
ProduktSo funktioniert esSicherheitPreiseKontakt aufnehmen
ENDE

Sicherheit

Die Teile eines Escrow-Dienstes, die kein Vertrauen erfordern sollten.

Ein Escrow-Treuhänder verlangt Vertrauen ausgerechnet bei dem, was am wenigsten nach außen dringen soll. Ziel ist daher, so wenig davon wie möglich zu brauchen: Hinterlegungen, die Sie ohne uns prüfen können, ein Speicher, der nie überschreibt, und ein Protokoll, das auch wir nicht ändern können.

Anatomie einer Hinterlegung6 Schichten
SPEICHERUNVERÄNDERBARKEITVERSIONIERUNGVERSCHLÜSSELUNGAUFBEWAHRUNGKUNDENZUGRIFF
vom System erzwungendurch Verfahren eingehalten
  1. 01
    Kundenzugriffvom System erzwungen

    Keiner, nie

    Kein Kunde besitzt Zugangsdaten zum Speicher. Der einzige Weg hinaus ist eine genehmigte Freigabe: ein Link, der nach 24 Stunden abläuft, auf 42escrow zeigt — nie auf den Speicher — und bei dem jeder Download protokolliert wird.

Was Sie selbst prüfen können

Die stärkste Garantie ist die, nach der Sie uns nicht fragen müssen.

Zwei Prüfungen, beide ohne uns: die Hinterlegung gegen Ihren eigenen Clone und das Protokoll gegen seine eigene Hash-Kette.

Eine Hinterlegung, wie Ihr Prüfer sie sieht

versiegelt
repository
helios-core
version
412 · 02:02:11 UTC
commit
a3f91c2
sha-256
9f2b41c7…b17d4e92
aufbewahrung
7 Jahre · bis 2033-10-19
speicher
versioniert nach Content-Hash

Rechnen Sie diesen Hash aus Ihrem eigenen Clone nach. Stimmt er überein, ist das Archiv bei uns der Code, der Ihnen zugesagt wurde.

Hinterlegung prüfen

Jede Hinterlegung zeigt ihren Commit und die SHA-256-Prüfsumme des gespeicherten Archivs. So rechnen Sie sie aus Ihrem eigenen Clone nach:

$ git bundle create archive.bundle --all$ sha256sum archive.bundle9f2b41c7…b17d4e92  archive.bundle

Stimmt sie nicht überein, haben Sie ein Problem gefunden, das einen Anruf wert ist — bevor Sie den Code gebraucht hätten. Genau darum geht es.

Protokoll prüfen

Jede Hinterlegung, jeder Download, jede Genehmigung und jede Freigabe wird in ein Append-only-Protokoll geschrieben. Jeder Eintrag hasht den vorherigen mit.

#2111
c41e…
#2112
7a0d…
#2113
e93b…
  • Die Datenbank weist UPDATE, DELETE und TRUNCATE auf das Protokoll zurück — per Trigger.
  • Wer einen früheren Eintrag ändert, bricht jeden Hash danach.
  • Die Kette nachzurechnen ist eine Kundenaktion, keine Support-Anfrage.
  • Kunden sehen nur die Einträge ihrer eigenen Organisation.

Trennung zwischen den Parteien

Hinterleger und Begünstigter teilen einen Vertrag — und sonst fast nichts.

SiehtHerstellerLizenznehmer42escrow
Den Vertrag und seine Bedingungen
Welche Repositories erfasst sind
Hinterlegungshistorie, Prüfsummen, Aufbewahrung
Die Zugangsdaten zum Repository
Den hinterlegten Quellcode
Die Daten einer anderen Organisation

Das wird über Row-Level-Security-Richtlinien der Datenbank durchgesetzt, nicht über Prüfungen im Anwendungscode — ein Fehler in einer Maske kann die Rechte also nicht erweitern.

Ehrliche Grenzen

Was eine Sicherheitsseite sonst verschweigt.

Die meisten Anbieter würden das weglassen. Wir schreiben es hin, denn blindes Vertrauen ist genau das, was Escrow überflüssig machen soll.

42escrow · Sicherheit
01

Wir können Ihren Code lesen

Ein Escrow-Treuhänder hält zwangsläufig eine entschlüsselbare Kopie — sonst könnte er keine freigeben. Was wir begrenzen, ist das Verfahren: kein Kundenweg zum Speicher, Vier-Augen-Prinzip und ein Protokolleintrag für jeden Zugriff.

02

Escrow ist kein Backup

Hinterlegungen dienen der vertraglichen Freigabe, nicht Ihrer eigenen Notfallwiederherstellung. Wenn Sie für Ihren Betrieb einen Wiederherstellungsweg brauchen, halten Sie einen eigenen vor.

03

Eine Hinterlegung beweist Bytes, nicht Qualität

Wir weisen nach, dass das Archiv dem Commit entspricht. Wir bestätigen nicht, dass es sich bauen lässt, dass es vollständig ist oder dass es der richtige Branch ist — eine Build-Verifikation ist ein eigener Dienst, und das sagen wir Ihnen auch.

42escrow · ein Service von 42law