YPCad
Deutsch
Demo anfragen

Sicherheit

Diese Seite nennt beides: was wir schützen und was wir nicht schützen können. Eine Sicherheitsdarstellung ohne den zweiten Teil verleitet den Leser dazu, eine Liste für eine Garantie zu halten.

Der Ausgangspunkt

Ein Paket zu veröffentlichen heißt, auf dem Rechner jedes Ingenieurs Code auszuführen, der es installiert. Jede Sicherheitsentscheidung in diesem Produkt wurde zuerst an einer Frage gemessen: macht diese Änderung unbefugtes Veröffentlichen leichter?

  • Pakete sind signiert (ECDSA P-256)

    Die Signaturdatei reist im Paket mit. Signiert wird eine Manifestdatei mit den Dateiprüfsummen, der Paketkennung und der Version — nicht die nackte Archivprüfsumme.

    Würde nur die Prüfsumme signiert, ließe sich ein gültig signiertes altes Archiv unter einer neuen Versionsnummer anbieten: die Signatur ginge auf, und der Benutzer installierte ein bekannt verwundbares Werkzeug als „Update“.

  • Der private Schlüssel liegt NICHT auf dem Server

    Der Server prüft nur. Signiert wird auf dem Rechner des Veröffentlichenden, mit einem eigenen Werkzeug.

    Läge der Schlüssel auf dem Server, könnte, wer den Server übernimmt, ein Paket ändern und neu signieren — womit das Signieren sinnlos wäre.

  • Auch der Client prüft

    Das Zusatzmodul auf dem Rechner des Ingenieurs prüft die Signatur unabhängig, und die Liste der vertrauenswürdigen Schlüssel kommt nicht vom Server.

    Signieren gibt es, weil man dem Server nicht aufs Wort glauben kann. Die Vertrauensliste von genau diesem Server zu holen würde diese Annahme still aufheben.

  • Ein Prüfprotokoll, das sich nicht löschen lässt

    Jede Veröffentlichung, jede Berechtigungsänderung und jede Kanalentscheidung wird dauerhaft geschrieben. Es gibt bewusst keinen Änderungs- oder Löschweg, und die Aufbewahrungsbereinigung fasst es nicht an.

    „Wie kam dieses Werkzeug hierher“ wird meist Monate später gefragt. An dem Tag ist ein Protokoll, das sich löschen ließe, ein Protokoll, das es nie gab.

  • Optionales Vier-Augen-Prinzip

    Eine Version in einen breiteren Kanal zu heben kann die Zustimmung eines zweiten Administrators verlangen, und wer anfragt, kann die eigene Anfrage nicht freigeben. Ein Rollback verlangt nie eine Freigabe.

    Anfangs ist es abgeschaltet. In einem Dreierteam wird aus dieser Kontrolle binnen Wochen eine Nachricht, die ungelesen freigegeben wird; eine Kontrolle, von der man glaubt, sie schütze, obwohl sie es nicht tut, ist schlimmer als gar keine.

  • Auch das Entpacken eines Archivs ist eine Angriffsfläche

    Hochgeladene Archive werden auf Pfadausbruch (Zip-Slip) und Dekomprimierungsbomben geprüft, und die entpackte Größe ist gedeckelt.

    Ein Archiv zu entpacken wirkt harmlos. Ein präpariertes kann Dateien außerhalb des Zielordners schreiben oder die Festplatte des Servers füllen.

  • Anmeldung ohne Passwort

    Benutzer melden sich mit einem Einmalcode an ihre E-Mail-Adresse an. Die Sitzung läuft über ein kurzlebiges Token; das Erneuerungstoken ist für Browsercode nie sichtbar.

    Ohne Passwortbestand gibt es keine Passwortdatenbank, die abfließen kann. Und die Wiederverwendung eines zurückgezogenen Erneuerungstokens gilt als Diebstahls-signal: die Sitzung wird verworfen.

  • Was installiert wird, steht schriftlich

    Im Installationsordner liegen eine maschinenlesbare Stückliste (CycloneDX SBOM) und Migrationsskripte für beide Datenbanken.

    Ihre IT sollte vor der Installation sehen können, was auf den Server kommt. Wird in einer Abhängigkeit eine Lücke bekannt, ist „haben wir das“ eine Dateisuche.

Was wir nicht schützen können

Das sind keine Lücken, sondern Grenzen. Sie folgen aus der Struktur, und etwas anderes zu behaupten wäre unwahr.

  • Zwei Administratoren, die zusammenarbeiten. Das Vier-Augen-Prinzip hält einen auf, nicht zwei.
  • Der Systemadministrator des Servers. Für jemanden mit Datenbank- und Dateisystemzugriff ist keine Kontrolle auf Anwendungsebene ein Hindernis.
  • Der Arbeitsplatz, auf dem der Signaturschlüssel liegt. Der Schlüssel ist nicht auf dem Server, aber er ist irgendwo; fällt dieser Rechner, fällt die Signatur mit.
  • Absichtlich verstecktes Schadverhalten. Unsere Paketprüfung arbeitet heuristisch, und wir behaupten nicht, dass sie Code erkennt, der sich verstecken will.
  • Datenabfluss. Ein installiertes Werkzeug läuft mit den eigenen Rechten des Ingenieurs und kann alles lesen, was diese Rechte erreichen. Das begrenzen Betriebssystem und Netzwerk, nicht dieses Produkt.
  • Die Sicherheit Ihrer Sicherungen. Die Datenbanksicherung liegt in Ihrer Hand, und alles darin ist genau so wertvoll wie das laufende System.

Sicherheitslücke melden

Wenn Sie eine gefunden haben, schreiben Sie uns. Wir nehmen Meldungen ernst, schließen die meldende Person nicht aus dem Vorgang aus und sagen Ihnen, wann die Korrektur erscheint.

security@ypcad.com