Sicherheit & Vertrauen bei OpsCodex

Betrieb & Mandantentrennung

OpsCodex wird single-tenant und on-premise in Ihrer eigenen Umgebung betrieben. Ihre Dokumente und Prozessmodelle verlassen Ihren Tenant nie, und Sie entscheiden, wo — und ob — KI-Inferenz läuft. Es gibt keine geteilte, mandantenübergreifende Datenebene.

Zugriff & Authentifizierung

Rollenbasierte Zugriffskontrolle

Granulare Rollen bilden den Governance-Workflow ab — Autor, Prüfer, Freigeber, Administrator, Auditor und Dokumentations-Redakteur. Jeder sieht und tut genau das, was seine Rolle erlaubt, und nicht mehr.

Single Sign-on & MFA

OpsCodex liegt hinter einer Zero-Trust-Zugriffsschicht, die gegen Ihren eigenen Identity Provider über SAML/OIDC authentifiziert (zum Beispiel Microsoft Entra ID oder Okta) und Single Sign-on sowie Mehr-Faktor-Authentifizierung erzwingt, bevor eine Anfrage die Anwendung erreicht.

Sitzungen

Sitzungen nutzen kurzlebige, HttpOnly- und Secure-Cookies. Abmeldung, Deaktivierung und Rollenwechsel wirken sofort.

Lokale Konten

Wo lokale Passwörter verwendet werden, sind sie per Einweg-Hash (bcrypt) mit Mindestlängen-Policy gespeichert; eine Passwortänderung erfordert das aktuelle Passwort und macht bestehende Sitzungen ungültig.

Datenschutz auf technischer Ebene

Bei der Übertragung

Der gesamte Verkehr ist mit modernem TLS verschlüsselt; schwache Cipher werden nicht angeboten.

Im Ruhezustand

Anwendungs-Secrets — etwa Schlüssel von KI-Anbietern — sind mit AES-256-GCM verschlüsselt, Konto-Passwörter sind per Einweg-Hash gespeichert. Im On-Premise-Betrieb halten Sie sämtliches Schlüsselmaterial selbst.

Hochgeladene Dateien

Von Nutzern hochgeladene Inhalte werden als Download mit deaktiviertem MIME-Sniffing ausgeliefert, damit nicht vertrauenswürdige Dateien nicht im Browser ausgeführt werden können.

Auditierbarkeit

Governance-Aktionen werden in einen Append-only-Audit-Trail geschrieben. Das wird in der Datenbank erzwungen, nicht im Anwendungscode: Ein Trigger auf der Audit-Tabelle weist jedes UPDATE und DELETE zurück, und der Datenbank-Rolle, unter der die Anwendung läuft, sind diese Rechte entzogen. Die Anwendung kann ihre eigene Audit-Historie selbst dann nicht umschreiben, wenn sie kompromittiert ist — das kann nur die separate Migrations-Rolle für Schema-Änderungen und Test-Teardown, und diese Rolle bedient nie eine Anfrage.

Um die Grenze präzise zu benennen: Der Trigger deckt Änderung und Löschung auf Zeilenebene ab. Er deckt TRUNCATE nicht ab, und er schützt nicht gegen jemanden mit Superuser-Zugriff auf Ihren eigenen Datenbankserver — das kann keine Kontrolle auf Anwendungsebene. Betrachten Sie den Nachweis als manipulationserkennend innerhalb der Reichweite der Anwendung, und flankieren Sie ihn mit den Backup- und Datenbank-Zugriffskontrollen, die Sie für andere führende Systeme ohnehin betreiben.

Fragt ein Auditor, wer ein Modell wann freigegeben hat, steht die Antwort im Protokoll: Autor, Prüfer, Freigeber, Zeitstempel und der Export-Hash dessen, was freigegeben wurde.

Härtung der Anwendung

Jede Antwort trägt moderne Browser-Sicherheits-Header — Content-Security-Policy, HTTP Strict Transport Security, Schutz gegen Clickjacking und MIME-Sniffing sowie eine restriktive Permissions-Policy. Rate-Limiting schützt die Authentifizierung und andere sensible Endpunkte, und Abhängigkeits- und Sicherheitsprüfungen laufen in der Continuous Integration.

Datenhoheit & Datenschutz

Ihre Daten gehören Ihnen

Ihre Inhalte gehören Ihnen. Sie sind jederzeit exportierbar; bei Vertragsende können sie sofort exportiert und auf Wunsch gelöscht werden. On-premise steuern Sie die Löschung unmittelbar selbst.

DSGVO

Der Betreiber sitzt in der EU (Mews Group SAS, Frankreich). On-premise bleiben Ihre Prozessdaten in Ihrer eigenen Infrastruktur und Ihrer eigenen Jurisdiktion — sie werden nicht an uns übertragen, es gibt auf unserer Seite also keine Drittlandübermittlung zu begründen.

Kein Tracking durch Dritte

Keine Weitergabe personenbezogener Daten an Dritte, keine Drittanbieter-Cookies und kein Zugriff auf Kontakte, Kalender oder andere Gerätedaten.

KI

KI ist eine optionale Assistenzschicht: Sie schlägt vor, ein Mensch gibt frei, und der Inhalt Ihrer Prompts wird nie gespeichert. Wie Anbieter-Schlüssel, Datenspeicherung und private oder selbst gehostete Inferenz funktionieren, steht unter KI-Governance.

Was uns noch fehlt

Eine Sicherheitsseite, die nur aufzählt, was es gibt, sagt Ihnen die Hälfte dessen, was Sie brauchen. Dies sind die Lücken, die Sie sonst durch Nachfragen finden müssten — hier benannt, damit Sie sie früh statt spät abwägen können.

Zertifizierungen

Keine ISO 27001, kein SOC 2, kein TISAX. Nicht erlangt, und es ist kein Zertifizierungstermin zugesagt. On-Premise-Installationen laufen in Ihrer eigenen zertifizierten Umgebung — deshalb war das bisher nicht die blockierende Frage. Ist ein Zertifikat in Ihrer Beschaffung zwingend, sprechen Sie es bitte früh an und nicht spät.

Unabhängiger Penetrationstest

Bisher keiner beauftragt. Was läuft: ein täglicher automatisierter Scan auf Schwachstellen in Abhängigkeiten in der CI und ein Regressionstest, der den Build scheitern lässt, wenn die oben genannten Security-Header wegfallen. Beides ersetzt nicht, dass jemand die Anwendung unter Vertrag angreift — und wir sagen das lieber, als beides miteinander verwechseln zu lassen.

Öffentliche Statusseite

Keine. Bei einer Single-Tenant-Installation on-premise ist die Verfügbarkeit, die zählt, die Ihrer eigenen Infrastruktur — das rangiert also weit hinten. Erwähnenswert ist das Fehlen trotzdem, statt es Sie selbst bemerken zu lassen.

Datenklassifizierung und DLP-Kennzeichnung

Keine Funktion für Sensitivitätskennzeichen oder DLP. Der Zugriff wird stattdessen strukturell gesteuert: über Rollen, teambezogene Berechtigungen und eine harte Grenze zwischen internen Entwürfen und dem veröffentlichten Portal.

Verwalteter Schlüsseldienst

Jedes Geheimnis liegt in Ihrer eigenen Umgebung, und wir halten keines davon — es gibt aber keine Anbindung an ein verwaltetes KMS oder HSM, falls Ihre Organisation Schlüssel lieber so verwahrt.

Finden Sie eine Lücke, die diese Liste nicht nennt, sagen Sie es uns — dann kommt sie auf die Liste. Eine solche Seite ist nur dann lesenswert, wenn sie vollständig ist.

Eine Sicherheitslücke gefunden? Bitte schreiben Sie an [email protected], statt einen öffentlichen Report zu eröffnen. Wir bestätigen Meldungen innerhalb von drei Werktagen.