Zum Inhalt springen
ERP Preflight

Datenverarbeitung im Detail

Wie Uploads geprüft, gescannt, geschwärzt, je Mandant gespeichert und gelöscht werden — die technischen Maßnahmen hinter der Sicherheitsübersicht.

Inhalt geprüft am 26. September 2026

Mandantentrennung in der Datenbank

Jede Organisation ist ein Mandant. Mandantentabellen tragen die Organisations-ID; PostgreSQL-Row-Level-Security ist für sie aktiviert und erzwungen. Für jede Anfrage setzt die API die geprüfte Organisation als app.current_tenant_id auf der Datenbanktransaktion, und die Richtlinien liefern und akzeptieren nur Zeilen dieser Organisation. Im Produktivbetrieb laufen mandantenbezogene Transaktionen unter einer Datenbankrolle ohne Superuser- oder BYPASSRLS-Rechte, sodass die Richtlinien auch dann greifen, wenn der Verbindungsbenutzer Eigentümer der Tabellen ist. Die Abfragen der Anwendung filtern zusätzlich nach Organisation.

Der Analysedienst hat keinen Zugriff auf Benutzer-, Abrechnungs- oder Mandantentabellen; siehe Sicherheit & Datenverarbeitung.

Speicherbereiche

Dateien liegen in S3-kompatiblem Objektspeicher unter Schlüsseln je Organisation und Projekt: tenants/{organizationId}/projects/{projectId}/…. Über einen vorsignierten Link hochgeladene Dateien werden bis zur Prüfung in einem separaten Quarantäne-Bucket gehalten; direkte Uploads werden im Arbeitsspeicher geprüft. Nur Dateien, die alle Prüfungen bestehen, gelangen in den Clean-Bucket. Erzeugte Berichte werden unter demselben Präfix für Organisation und Projekt abgelegt. Vorsignierte Upload- und Download-Links laufen nach höchstens 15 Minuten ab; Download-Links für Artefakte werden nur für CLEAN-Dateien ausgestellt.

Upload-Prüfungen

Jeder Upload — aus der Web-App, über die API oder die CLI — durchläuft dieselbe Pipeline:

  1. Inhaltsprüfung: Die Dateiendung bestimmt das erwartete Format, und der Inhalt muss dazu passen: ZIP-Signatur, XML-Deklaration oder Wurzelelement (XML mit Entity-Deklarationen oder externer DTD wird abgewiesen), gültiges JSON, der XDP-Namespace, der PDF-Header; CSV-, ABAP- und Textdateien dürfen keine binären Nullbytes enthalten. Dateien, die mit dem Header einer ausführbaren Datei beginnen (Windows PE, ELF, Mach-O, Java-Klasse), werden unabhängig von der Endung abgewiesen.
  2. Archivprüfung: Ein ZIP-Archiv wird abgewiesen bei mehr als 10 000 Einträgen, einem Eintrag über 250 MB, insgesamt mehr als 500 MB entpackter Größe, einem Kompressionsverhältnis über 100:1 (geprüft ab 10 MB entpackter Größe) sowie bei absoluten Eintragspfaden oder Pfaden mit ../. Öffnet der Analysedienst ein Archiv, setzt er die Verhältnis- und Größengrenzen anhand der tatsächlich entpackten Bytes durch und erlaubt höchstens 2 Ebenen verschachtelter Archive.
  3. Malware-Scan und 4. Schwärzung von Geheimnissen, siehe unten.

Die API akzeptiert die Endungen zip, xml, wsdl, edmx, xsd, xdp, json, csv, abap, txt, prog, incl und pdf bis 100 MB je Datei, sofern der Betreiber keine andere Grenze gesetzt hat; die Artifact Dropzone eines Projekts bietet .xml, .json, .csv, .zip und .abap an. Die SHA-256-Prüfsumme jeder Datei wird mit ihr gespeichert.

Malware-Scan und Quarantäne

Jede Datei wird vor ihrer Verwendung mit ClamAV gescannt. Infizierte Dateien erhalten den Status QUARANTINED und gelangen nie in den Clean-Bucket. Der Scan arbeitet nach dem Fail-closed-Prinzip: Ist der Scanner nicht erreichbar, läuft die Prüfung in ein Timeout oder antwortet der Scanner unerwartet, wird die Datei ebenfalls in Quarantäne gestellt. Dateien, die die Inhalts- oder Archivprüfung nicht bestehen, erhalten den Status REJECTED.

Nur CLEAN-Dateien können analysiert oder heruntergeladen werden. Im Produktivbetrieb ist der Scan mit ClamAV die Voreinstellung; ein Mock-Scanner existiert für die Entwicklung und muss ausdrücklich eingeschaltet werden.

Schwärzung von Geheimnissen

Bevor eine Textdatei in den Clean-Bucket geschrieben wird, werden darin enthaltene Geheimnisse durch Masken der Form [REDACTED:SECRET:<hash>] ersetzt. Das gilt für XML, XSD, WSDL, EDMX, XDP, JSON, CSV, ABAP und Klartextquellen (.txt, .prog, .incl). Nach der Übernahme wird eine ungeschwärzte Kopie im Quarantäne-Bucket gelöscht.

  • Die Erkennung kombiniert Muster — private Schlüssel, JSON Web Tokens, Authorization-, Cookie- und andere sensible HTTP-Header, Zugangsdaten in URLs, Query-Strings und Verbindungszeichenfolgen, SAP-RFC- und SAProuter-Passwörter, AWS-, GitHub- und OpenAI-Schlüssel, generische API-Schlüssel — mit einem Entropie-Scan für zufällig wirkende Tokens. Gängige SAP-Tabellen- und ABAP-Namen sind ausgenommen.
  • Die Maske ist ein HMAC mit einem Schlüssel je Organisation: Dasselbe Geheimnis ergibt innerhalb Ihrer Organisation dieselbe Maske, in jeder anderen eine andere.
  • Die Anzahl der Schwärzungen wird mit der Datei gespeichert und zum Upload gemeldet.
  • ZIP-Archive und PDF-Dateien werden nach bestandenen Prüfungen unverändert gespeichert; ihr Inhalt wird nicht umgeschrieben. Unabhängig vom Dateityp schwärzt der Analysedienst jeden Evidenz-Ausschnitt, bevor ein Befund den Dienst verlässt.
  • Der lokale Agent schwärzt bereits auf Ihrem Host, bevor etwas gesendet wird.

Aufbewahrung und Löschung

Organisationsinhaber und Security-Admins legen die Aufbewahrung unter Einstellungen → Daten & Berichte fest:

  • Artefakte: aufbewahren, bis das Projekt gelöscht wird (Standard), direkt nach der Analyse löschen, die sie verwendet hat (nie analysierte Uploads werden nach 24 Stunden entfernt), oder nach einer Anzahl von Tagen löschen.
  • Berichte: aufbewahren (Standard) oder nach einer Anzahl von Tagen löschen.

Die höchstmögliche Anzahl an Tagen hängt von Ihrem Tarif ab. Ein Hintergrundjob wendet die Richtlinien standardmäßig stündlich an; Inhaber und Security-Admins können eine Bereinigung auch sofort starten (POST /api/v1/retention/purge). Objekte werden zuerst aus dem Speicher gelöscht, dann ihre Datenbankzeilen, und jede Bereinigung wird im Audit-Log protokolliert. Befunde und Evidenz-Hashes bleiben zur Nachvollziehbarkeit erhalten. Solange für die Organisation ein Legal Hold (rechtliche Aufbewahrungspflicht) gesetzt ist, findet keine Bereinigung statt.

Den Export personenbezogener Daten und das Löschen eines Kontos beschreibt Sicherheit & Datenverarbeitung.

Verschlüsselung gespeicherter Zugangsdaten

Zugangsdaten, die ERP Preflight später verwenden muss — Konnektor-Zugangsdaten, das Client-Secret Ihres Identitätsanbieters und Webhook-Signatur-Secrets —, werden vor dem Speichern mit AES-256-GCM verschlüsselt; der Schlüssel wird je Verwendungszweck aus dem Master-Schlüssel des Betreibers abgeleitet. API-Schlüssel und SCIM-Tokens werden gar nicht gespeichert, sondern nur ihre SHA-256-Hashes.

ERP Preflight legt über gespeicherte Dateien keine eigene Verschlüsselungsschicht; ob der Objektspeicher ruhende Daten verschlüsselt, hängt von seiner Konfiguration ab.

Weiterführende Seiten

Datenverarbeitung im Detail — ERP Preflight Docs