On this page
Impressum · Datenschutzerklärung · Allgemeine Geschäftsbedingungen · Drittsoftware · Lizenzbedingungen (EULA) · SaaS-Bedingungen · Fair-Use-Regeln · Service Levels · Auftragsverarbeitungsvertrag · Technische und organisatorische Maßnahmen
1. Geltung
1.1 Diese Anlage gehört zum Auftragsverarbeitungsvertrag (avv.de.md) und beschreibt die Maßnahmen nach Art. 32 DSGVO, die die Helm & Nagel GmbH („wir“) für die Verarbeitung von Kundendokumenten in der OCR-API von ocr-software.com trifft.
1.2 Sie gilt für den SaaS-Betrieb auf einem Server der Hetzner Online GmbH im Rechenzentrum Helsinki (Finnland, EU). Beim Server des Kunden verarbeiten wir keine Kundendokumente; dort gilt Ziff. 7.
1.3 Wir entwickeln die Maßnahmen weiter und senken das Schutzniveau nicht. Wesentliche Änderungen teilen wir auf Anfrage mit.
2. Vertraulichkeit
2.1 Zugriff auf die API nur mit Schlüssel (Authorization: Bearer). Schlüssel haben 256 Bit Zufall; gespeichert wird nur der SHA-256-Wert (service/internal/auth/auth.go Z. 1 und 29).
2.2 Das Ergebnis geht nur an den Aufrufer mit dem Schlüssel, der den Auftrag angelegt hat; Aufträge sind je Schlüssel getrennt abgelegt (service/internal/jobrun/jobrun.go Z. 856).
2.3 Die Jobablage ist ein privates Verzeichnis (Rechte 0700, Dateien 0600; jobrun.go Z. 138 und 226, service/internal/intake/intake.go Z. 188 und 603). Der Upload liegt zuerst in einer Arbeitsdatei mit Zufallsnamen, nie unter dem Dateinamen des Kunden.
2.4 Verschlüsselung ruhender Dokumente durch Vermeidung: Im SaaS-Betrieb liegt die Jobablage im Arbeitsspeicher (jobs_dir: /run/ocr/jobs, Einheit deploy/ocrd-ramjobs.conf, Grenze MemoryMax=12G); kein Dokument und kein Ergebnis erreicht die Platte. Folge: Ein Neustart des Rechners verliert unfertige Aufträge; der Kunde reicht sie neu ein, berechnet wird nur Fertiges (deploy/ocrd-ramjobs.conf Z. 5 bis 7). Die Systemplatte trägt nur Metadaten (Ziff. 4.3) und ist nicht gesondert verschlüsselt.
2.5 Transportverschlüsselung: TLS und HSTS am Proxy (Caddy, Zertifikate per ACME, doku/sicherheit.md Z. 10, doku/deploy.md Z. 30).
2.6 Administration getrennt vom Netz der Kunden: /metrics und /admin sind nie öffentlich; die Admin-Schnittstelle läuft auf eigenem Listener (doku/sicherheit.md Z. 10).
2.7 Der Dienst läuft als eigener Benutzer mit NoNewPrivileges, ProtectSystem=strict und PrivateTmp, der Spool auf tmpfs (doku/sicherheit.md Z. 10).
2.8 Kein Inhalt in Protokollen: Route (Muster), Status, fester Fehlercode, Dauer, Antwortgröße, Schlüssel-ID, Pipeline und Version, Seitenzahl; nie Pfad, Abfrage, Header, Dateiname, Hash eines Dokuments oder Panic-Text (doku/sicherheit.md Z. 3, Datenschutzerklärung Ziff. 11).
2.9 Pseudonymisierung der Adressen: die volle Client-Adresse steht nur im Sicherheitsprotokoll; Zähler und Kontingent sehen nur das Netzpräfix (IPv4 /24, IPv6 /64).
2.10 Verpflichtung: Wer bei uns Zugang zu Servern oder Betriebsdaten hat, ist schriftlich zur Vertraulichkeit verpflichtet. Zugang zu Servern haben nur die Personen, die ihn für den Betrieb brauchen; bei Ausscheiden entziehen wir ihn am selben Tag.
3. Integrität
3.1 Eingaben gelten als feindlich: zugelassen sind PDF, PNG, JPEG (Prüfung der Dateikennung); Archive werden nie entpackt (doku/sicherheit.md Z. 5, service/internal/intake/).
3.2 Prüfung vor dem Rendern: Größe (Standard 100 MiB), Seitenzahl (Standard höchstens 1.000 je Dokument), Verschlüsselung, Größe je Seite (höchstens 10 MiB) und Pixelzahl; JavaScript in PDF wird nie ausgeführt.
3.3 Kindprozesse (poppler) laufen mit minimaler Umgebung, ohne Eingabe, mit Zeit- und Speichergrenze und niedriger Priorität (intake/, doku/sicherheit.md Z. 5).
3.4 Mindestrate beim Upload (Standard 128 KiB/s nach 15 s), sonst Abbruch mit Löschung der Arbeitsdatei (doku/betrieb.md Z. 32).
3.5 SSRF-Schutz bei Bucket-Aufträgen: nur https, nie Loopback oder private Adressen; keine Einstellung lockert das (doku/sicherheit.md Z. 14).
3.6 Weitergabekontrolle: Es gehen keine Dokumente an externe KI-Dienste oder Dritte. Ausgehende Aufrufe des Dienstes sind nur der Auftrag an den eigenen Worker, der Alarm-Webhook ohne Dokumentinhalt und der S3-Eingang auf Wunsch des Kunden (Datenschutzerklärung Ziff. 10).
3.7 Änderungskontrolle: Code kommt nur über deploy/rollout.sh aus einem sauberen Commit auf den Server; die Revision ist am Server ablesbar; meldet ein Dienst nach dem Start nicht den neuen Commit, schaltet install-release.sh auf das vorige Release zurück (doku/deploy.md, doku/betrieb.md Z. 26). Abhängigkeiten sind gepinnt und stammen aus offiziellen Quellen (doku/setup.md); der Proxy wird in fester Version mit SHA-512 geprüft installiert.
3.8 Prüfung vor Auslieferung: Ein Prüfer sieht jede Änderung nach; der Release-Check (Stufen vet, CPU, GPU) läuft vor jedem Release (doku/release-check.md). Lastgrenzen und feindliche Eingaben sind im Lasttest gemessen (doku/betrieb.md Z. 47 bis 59).
4. Löschung und Aufbewahrung
4.1 Fristen (alle im Code festgelegt, Standardwerte):
| Daten | Frist |
|---|---|
| Dokument | Ende des Auftrags; Rest eines Absturzes beim Dienststart |
| Ergebnis | 24 Stunden (einstellbar 1 Minute bis 720 Stunden); stündliche Aufräumrunde |
Zeile im Auftragsprotokoll (job_log) | 90 Tage |
| Adresse im Auftragsprotokoll | 7 Tage |
| Sicherheitsprotokoll mit voller Adresse | 7 Tage, stündlich gelöscht |
| Seitenzähler je Netzpräfix | 30 Tage |
4.2 Der Kunde kann ein Ergebnis jederzeit sofort löschen (DELETE /v1/jobs/{id}).
4.3 Sicherungen enthalten nur Metadaten (Buchungsbuch, Aufträge ohne Inhalt, Schlüssel-Hashes, Konten), nie Dokumente oder Ergebnisse; die Jobablage gehört nicht ins Backup (doku/sicherheit.md Z. 11).
4.4 Training: Kundendokumente und Ergebnisse werden nie zum Training, zur Verbesserung oder zur Bewertung von Modellen genutzt (AVV Ziff. 3.3).
5. Verfügbarkeit und Belastbarkeit
5.1 Lastgrenzen je Schlüssel (Anfragerate, gleichzeitige Aufträge) und global; Überschreitung ergibt 429 rate_limited mit Retry-After, gezählt erst nach gültigem Schlüssel (doku/betrieb.md Z. 5 bis 11).
5.2 Überwachung: ocralert prüft jede Minute Dienst, Worker, hängende Aufträge, Grafikspeicher, Speicherplatz, Fehlerrate, Fehler der Engine und Abstürze und meldet per Webhook; die Adresse steht nur in /etc/ocr/alert.env (0600) (doku/betrieb.md Z. 40 bis 43).
5.3 Wiederanlauf: Ein unterbrochener Auftrag setzt nach dem Neustart des Dienstes fort; jede Seite wird genau einmal gebucht (getestet in cmd/ocrd/restore_test.go, doku/betrieb.md Z. 19).
5.4 Sicherung und Wiederherstellung: stündlich eine Sicherung der Datenbank, der Schlüssel- und Kontodateien nach /var/backups/ocr (14 Stände), Integritätsprüfung, Wiederherstellung mit ocrctl restore (doku/deploy.md Z. 32, doku/betrieb.md Z. 14 bis 20).
5.5 Rückfall bei fehlgeschlagenem Release (Ziff. 3.7); die letzten drei Releases bleiben liegen.
6. Organisation und Verfahren
6.1 Weisungen: Die Verarbeitung folgt allein dem API-Aufruf und dem AVV (AVV Ziff. 3).
6.2 Unterauftragsverarbeiter: nur die in AVV Anlage 2 genannten, mit vertraglich gleichen Pflichten (AVV Ziff. 6).
6.3 Datenpannen: Alarme (Ziff. 5.2) und Sicherheitsprotokoll (Ziff. 2.9) führen zur Meldung an den Kunden unverzüglich, in der Regel binnen 48 Stunden nach Kenntnis (AVV Ziff. 7.3).
6.4 Ansprechstelle für Sicherheitsfragen und Schwachstellenmeldungen: info@ocr-software.com; die Helm & Nagel GmbH führt auf helm-nagel.com eine Vulnerability Disclosure Policy.
6.5 Die Helm & Nagel GmbH verweist auf helm-nagel.com auf eine Zertifizierung nach ISO/IEC 27001 (https://trust.helm-nagel.com/). Ob der Dienst im Geltungsbereich liegt, sagen wir erst, wenn der Nachweis vorliegt; bis dahin stützen sich die Zusagen dieser Anlage allein auf die genannten Maßnahmen.
6.6 Rechenzentrum, physischer Zutritt, Strom, Klima und Netz des Rechenzentrums liegen bei der Hetzner Online GmbH; wir verlassen uns darauf nur im Rahmen von deren Vertrag (AVV Anlage 2).
7. Server beim Kunden
Beim Betrieb auf dem Server des Kunden gelten die Ziff. 2.1 bis 2.3, 2.5 bis 2.8, 3 und 5.1 bis 5.5 als Funktion der Software. Betriebssystem, Netz, Firewall, DNS, Zugang zum Server, Schlüsselverwaltung und Datensicherung außerhalb der Datenbank liegen beim Kunden. Die Jobablage im Arbeitsspeicher (Ziff. 2.4) richten wir dort auf Wunsch ein.
8. Grenzen, die wir offen nennen
8.1 Die Sicherung liegt nur auf demselben Server; eine Kopie an einen zweiten Ort gibt es nicht. Bis zu eine Stunde Buchungen kann verloren gehen; die Sicherung schützt nicht gegen den Verlust des Servers (doku/betrieb.md Z. 36).
8.2 Es läuft ein Worker auf einem Server; es gibt keine Hochverfügbarkeit (doku/deploy.md Z. 36).
8.3 Eine ständige Bereitschaft außerhalb der Supportzeiten (Service Levels Ziff. 5) besteht nicht; Alarme laufen rund um die Uhr, werden aber nur in den Supportzeiten bearbeitet.
8.4 Eine gesonderte Verschlüsselung der Systemplatte gibt es nicht (Ziff. 2.4).
8.5 Stand der Maßnahmen auf dem Server (Auslagerungsspeicher, Absturzabbilder, Zugangsverwaltung) legen wir dem Kunden auf Anfrage als Auszug aus der Betriebsdokumentation vor (AVV Ziff. 9.1).