Sicherheit gebaut für regulierte Märkte
EthicVault ist darauf ausgelegt, die anspruchsvollsten regulatorischen und infosec-Anforderungen im Finanzwesen zu erfüllen — nicht als nachträglicher Gedanke, sondern als Fundament.
Zero Custody
Die Friction Gate arbeitet vollständig innerhalb Ihrer Deployment-Grenze. Audit-Logs, Richtlinienregeln und Ausführungsdatensätze werden in Ihrer Infrastruktur gespeichert — EthicVault hat nie die Verwahrung Ihrer Daten.
Manipulationserkennende Governance
Jede Governance-Entscheidung wird im Moment der Ausführung kryptografisch signiert und an die vorherige gekettet, sodass jede spätere Veränderung erkennbar ist — was Aufsichtsbehörden einen überprüfbaren Nachweis der getroffenen Disposition und der angewandten Kontrollen gibt.
Deterministisch by Design
Die Friction Gate nutzt regelbasierte Logik — keine probabilistischen ML-Modelle — für ihre Governance-Entscheidungen. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe, was sie auditierbar und erklärbar macht.
Was zertifiziert ist, was ausgelegt ist, und was noch keines von beidem ist
Unser eigenes White Paper argumentiert, dass behauptet, umgesetzt, gemessen, berichtet, unabhängig verifiziert und produktionsreif verschiedene Aussagen sind, die niemals vermengt werden dürfen. Diese Regel muss zuerst uns binden.
“Vertrauen wächst, wenn das Nachweis-Label so präzise ist wie die technische Aussage.”
| Rahmenwerk | Status | Was das heißt — und was nicht |
|---|---|---|
SOC 2 Type II AICPA | Für die Prüfung ausgelegt | Ein Type-II-Bericht verlangt ein Beobachtungsfenster über ein produktiv laufendes System. Architektur und Kontrollsatz sind darauf ausgelegt; das Fenster öffnet mit der kommerziellen Freigabe. Wir halten heute keinen SOC-2-Bericht, weder unter NDA noch anderweitig. |
ISO 27001 ISO/IEC 27001 | Architektur ausgerichtet · ISMS in Erstellung | Die Architektur ist auf den ISO-27001-Kontrollsatz gebaut. Das ISMS als Managementrahmen — schriftliche Richtlinien, Risikoregister, Aufzeichnungen — wird noch erstellt und ist nicht auditfähig. Es existiert kein Zertifikat, keine akkreditierte Stelle hat einen Geltungsbereich auditiert, und wir behaupten heute kein druckfertiges Richtlinienwerk. |
DSGVO Artikel 32 EU 2016/679 | Ausgelegt nach | Die Architektur ist gegen die technischen und organisatorischen Maßnahmen aus Artikel 32 ausgelegt; das Zero-Custody-Modell ist der Hauptgrund. Designabsicht ist keine Compliance-Feststellung, und keine Aufsichtsbehörde und kein Auditor hat sie bewertet. |
DORA EU 2022/2554 | Ausgelegt für | Gebaut für die IKT-Risikomanagementpflichten, die Finanzunternehmen unter DORA tragen, einschließlich der Nachweise, die eine Antwort nach Artikel 11 erzeugen muss. DORA bindet Finanzunternehmen, nicht uns. Wir können Nachweise für Ihre Pflicht liefern; erfüllen können wir sie nicht. |
Ändert sich eine Zeile oben, ändert sie sich hier zuerst und im selben Wortlaut. Kein Status wird auf dieser Seite hochgestuft, bevor das zugrunde liegende Artefakt existiert.
Wir betreiben kein Compliance-Theater
Ein SOC-2-Type-II-Bericht oder ein Penetrationstest gegen ein System, das noch nicht produktiv läuft, wäre ein Dokument, kein Nachweis. Unser ganzes Argument lautet, dass behauptet, umgesetzt und unabhängig verifiziert verschiedene Wörter sind. Wir werden diese Regel nicht brechen, um diese Seite zu schmücken. Die Architektur ist für diese Audits ausgelegt; sie beginnen, wenn das System echten Verkehr trägt.
Artefakte, nach denen ein Security Review fragen wird
Gelistet, ob sie schon existieren oder nicht — denn das Fehlen eines davon ist selbst eine Information, die eine Prüfinstanz früh statt spät braucht.
| Artefakt | Status |
|---|---|
| Responsible-Disclosure-Richtlinie Veröffentlicht unter /.well-known/security.txt mit Kontaktadresse und bevorzugter Sprache. | Verfügbar |
Auftragsverarbeitungsvertrag (AVV) Wird je Engagement ausgestellt, sobald der Verarbeitungsumfang feststeht. Kein Standarddokument. | Auf Anfrage |
Service Level Agreement Geformt durch Bereitstellungsmodell und Zusicherungspflichten. Siehe „Wie wir bepreisen“. | Je Engagement |
Unterauftragsverarbeiter-Liste Die Engine liest, bewertet, signiert und erlaubt oder blockiert dann. Kunden-Payload und personenbezogene Daten werden nie gespeichert; die WORM-Kette hält kryptografische Nachweise und Dispositionen. Die Liste ist damit architekturbedingt minimal und wird vollständig, mit Änderungsbenachrichtigung, vor jeder Verarbeitung von Kundendaten veröffentlicht. | Zero-Payload-Custody by Design |
ISMS-Ansatz Die administrative Ebene — Personal, Geräteverwaltung, Standard-Zugriffsprüfungen — läuft der Abdeckung wegen über eine Compliance-Automatisierungsplattform. Die Engine-Kontrollen — die Autorisierungsgrenze, die Zero-Payload-Custody, der deterministische Entscheidungspfad — werden von Hand geschrieben, weil fertige Cloud-Compliance-Vorlagen ein System voraussetzen, das Kundendaten speichert, und nicht zu einer Architektur passen, die gerade dafür gebaut ist, das nicht zu tun. | Hybrid — automatisiert + handgeschrieben |
Penetrationstest-Zusammenfassung Ein Test gegen eine Staging-Hülle beweist wenig. Er läuft zur allgemeinen Verfügbarkeit gegen die Produktionsumgebung; Zusammenfassung und Geltungsbereich erscheinen hier. | Geplant zur GA |
Öffentliche Statusseite Eine Statusseite berichtet über einen Produktionsdienst unter SLA. Sie geht mit dem ersten live. | Zur GA |
Was heute gilt und was für die GA ausgelegt ist
Dies sind Eigenschaften der Engine im Ist-Zustand, jetzt vorführbar — drei davon im Demonstrator selbst.
Deterministische Entscheidungsgrenze
- Kein probabilistisches Modell liegt im Freigabe-Entscheidungspfad
- Dieselbe begrenzte Anfrage, derselbe Richtlinien- und Nachweiszustand ergeben dieselbe Disposition
- Jede Disposition trägt die Ursachencodes, gegen die sie geprüft werden kann
Zero-Payload-Custody
- Kunden-Payload und personenbezogene Daten werden nie gespeichert
- Die WORM-Kette hält kryptografische Nachweise und Dispositionen, keinen Inhalt
- Kundendaten werden nie zum Trainieren oder Feinjustieren eines Modells verwendet
Manipulationssichere Audit-Kette
- Hash-verkettetes, nur anhängbares Entscheidungsregister
- Jeder Datensatz bindet einen SHA-256-Zertifikat-Hash an den Richtlinien-Hash, unter dem entschieden wurde
- Ein erneuter Lauf reproduziert ein bitidentisches Zertifikat
Die Plattformkontrollen unten sind ausgelegt und werden aktiv, wenn das System Produktionsverkehr trägt. Sie sind als Zielarchitektur gelistet, nicht als heute wirkende Kontrollen. SOC 2, Penetrationstest und SLA stehen oben im Zusicherungsstatus und werden hier nicht wiederholt.
Transport & Speicherung
- TLS 1.3 bei der Übertragung, erzwungen ohne Downgrade
- AES-256 im Ruhezustand über die Speicherschichten
- Mandantengetrennte Schlüsselverwaltung, mit BYOK
Zugriff & Identität
- SSO über SAML 2.0 und OIDC für Unternehmenskonten
- Hardware-MFA für privilegierten Zugriff
- Rollenbasierte Zugriffskontrolle nach dem Least-Privilege-Modell
Resilienz & Betrieb
- Multi-Region-Bereitstellung mit automatischem Failover
- Prüfer-fertiger regulatorischer Export
- SIEM-Integration über Webhook oder Syslog
Keine Daten verlassen Ihre Umgebung ohne Ihre ausdrückliche Autorisierung.
Die Friction Gate arbeitet vollständig innerhalb Ihrer Deployment-Grenze. Audit-Logs, Richtlinienregeln und Ausführungsdatensätze werden in Ihrer Infrastruktur gespeichert — EthicVault hat nie die Verwahrung Ihrer Daten.
Unser eigenes Gate versagte in vier von vier Fällen — und das haben wir geändert.
Veröffentlicht, weil eine Offenlegungsrichtlinie ohne Protokoll dahinter verlangt, die Haltung auf Treu und Glauben zu nehmen. Dies ist das wichtigste negative Ergebnis unserer Prototyp-Nachweise, in den Worten des Berichts selbst.
- Was wir annahmen
Dass schädliches Verhalten stets über einen bereits als eingeschränkt registrierten Werkzeugnamen eintrifft. Das Gate klassifizierte nach Namen und verweigerte, was auf der Liste stand.
- Was geschah4 / 4
Vier schädliche Aktionen, deren Effekte nicht im Register eingeschränkter Werkzeuge abgebildet waren, passierten das Gate in jedem getesteten Fall. Der Bericht verzeichnet dies als echtes Prototyp-Versagen und stellt klar, dass Klassifikation nach Werkzeugnamen allein keine ausreichende Ausführungskontrollgrenze ist.
- Was sich änderte
Default-Deny-Allowlist, effektbasierte Egress-Kontrolle und autoritätsgebundene Freigabe — die Haltung, die der Bericht Phi-Invariant nennt. Die Disposition bindet an kanonisierte Argumente, Ziel, Autorität, Beweis und Policy-Version, nicht an ein Etikett.
- In der Regression0 / 4
Dieselben vier Fälle wurden gegen die neue Haltung erneut ausgeführt. Keiner kam durch.
Die Frage, die das Gate nun stellt
Nicht „steht dieser Werkzeugname auf einer Sperrliste?“, sondern „ist genau dieser Effekt, sein Ziel, seine Autorität, sein Beweiszustand und sein Freigabepfad ausdrücklich erlaubt?“ Der vorschlagende Agent stuft seine eigene Aktion nicht selbst als sicher ein.
Geltungsbereich, wie der Bericht ihn angibt: Regressionsnachweis für vier wiederholte Fälle, keine universelle Exploit-Resistenz. Die Verhinderung unbekannter oder Zero-Day-Schadeffekte ist als nicht belegt aufgeführt. Unabhängig verfasste Angriffsvarianten, verdeckte Kanäle und adversariale Trace-Formung bleiben ungetestet.
Verantwortungsvolle Offenlegung
Wenn Sie glauben, eine Sicherheitslücke in EthicVault-Systemen entdeckt zu haben, legen Sie sie bitte verantwortungsvoll offen. Wir verpflichten uns, gültige Meldungen innerhalb von 48 Stunden zu bestätigen und kritische Probleme innerhalb von 14 Tagen zu beheben.
Schwachstelle melden