Sicherheit & Bedrohungsmodell

Was ist ein Bedrohungsmodell? Es beschreibt, was geschützt werden soll, wer es angreifen könnte, auf welchen Wegen das geschehen könnte und welche Schutzmaßnahmen dagegen stehen. Es zeigt auch ehrlich, was nicht oder nur teilweise abgedeckt ist. So können Sie als Kunde einschätzen, was Sie uns anvertrauen und was Sie selbst beitragen müssen.

1. Was wir schützen

Schutzgut	Warum es wichtig ist
Daten Ihrer Organisation	Mieter, Verträge, Garagen, Dokumente und E-Mails dürfen nur Ihre Integrationen sehen, nie eine andere Organisation.
Tokens	Ein Token ist der Schlüssel zu Ihren Daten im Rahmen seiner Berechtigungen.
Webhook-Geheimnisse	Mit dem Geheimnis kann ein Empfänger prüfen, dass eine Nachricht von uns stammt; wer es kennt, könnte Nachrichten fälschen.
Buchungs- und Zahlungsdaten	Finanzdaten sind besonders sensibel; Bank- und Zahlerangaben gibt es nur mit einem zusätzlichen Recht.
Verfügbarkeit	Die API und die Webhook-Zustellung sollen auch bei Fehlbedienung oder Massenanfragen für alle nutzbar bleiben.

2. Wer angreifen könnte, und was wir annehmen

Eine andere Organisation (ein fremder Mandant), die versucht, an Daten oder Ids Ihrer Organisation zu kommen.
Wer ein Token besitzt — gestohlen, abgelaufen oder bereits widerrufen — und es missbraucht.
Ein böswilliger Webhook-Empfänger oder jemand, der uns über eine Webhook-Adresse dazu bringen will, interne Systeme anzusprechen (SSRF), oder der Nachrichten fälscht oder wiederholt einspielt.
Ein Angreifer im Netzwerk, der Verkehr mitliest oder verändert.
Missbrauch durch Massenanfragen, absichtlich oder durch einen Fehler in einer Integration.
Fehler im Betrieb, etwa eine falsche Einstellung oder ein versehentlich weitergegebenes Geheimnis.

Wir gehen davon aus, dass ein Angreifer die öffentliche Dokumentation und die OpenAPI-Beschreibung kennt, aber weder Ihre Tokens noch Ihre Webhook-Geheimnisse. Nicht abgedeckt ist ein Angreifer, der bereits Zugriff auf Ihre eigenen Systeme oder auf Ihr Konto in der Verwaltung hat: Wer ein gültiges Token besitzt, darf damit tun, was dessen Berechtigungen erlauben.

3. Bedrohungen und Schutzmaßnahmen

Die Tabellen nennen je Bereich die Bedrohung, die Schutzmaßnahme und die Art der Prüfung. Einzelheiten zu Zahlen und Grenzen stehen auf den jeweiligen Seiten der Dokumentation.

Authentifizierung und Tokens

Bedrohung	Schutzmaßnahme	Wie wir das prüfen
Token wird aus der Datenbank gestohlen	Es wird nur ein schlüsselabhängiger Hash des Geheimnisses gespeichert, nie das Geheimnis selbst; der dafür nötige Schlüssel liegt nicht in der Datenbank. Das Token wird nur einmal angezeigt.	Automatisierte Tests, Datenbankprüfungen
Token ist zu mächtig	Jedes Token trägt nur die Berechtigungen (Scopes), die Sie vergeben haben; die Endpunkte mit Daten verlangen den passenden Scope. Das Token wirkt nur, solange sein Ersteller in der Verwaltung noch das Recht auf API-Zugänge hat.	Automatisierte Tests, Datenbankprüfungen
Gestohlenes oder abgelaufenes Token	Tokens haben ein Ablaufdatum. Der Widerruf wirkt ab der nächsten Anfrage; dasselbe gilt, wenn der Zugang der Organisation abgeschaltet wird. Anlage und Widerruf eines Tokens werden im Audit-Log festgehalten.	Automatisierte Tests, Datenbankprüfungen
Raten von Tokens	Das Geheimnis ist zufällig und sehr lang. Zusätzlich bremsen Grenzen je Adresse falsche Anmeldeversuche; fällt der dafür nötige Zähler aus, lehnt die API ab, statt ungebremst zu antworten.	Automatisierte Tests
Token im Browser oder in Links	Ein Token in der Adresse (Query-String) wird abgewiesen; Cookies werden nicht ausgewertet. Die API ist für Server-zu-Server-Aufrufe gedacht.	Automatisierte Tests

Mandantentrennung und Antworten

Bedrohung	Schutzmaßnahme	Wie wir das prüfen
Zugriff auf Daten einer anderen Organisation	Die Organisation ergibt sich aus dem Token, nicht aus Angaben der Anfrage. Die Abfragen laufen über Datenbankfunktionen der API, die das Token und die Organisation selbst prüfen (Entwurfsregel); diese Prüfung ist die maßgebliche Grenze. Der Zeilenschutz (RLS) der Tabellen schützt die anderen Zugriffswege, etwa die Verwaltung, ist aber keine zweite Schutzschicht der API. Wo die API Dateien bereitstellt (Dokument- und DATEV-Download-Links), wird erst nach der Prüfung in der Datenbank ein kurzlebiger Link für einen Pfad der eigenen Organisation erzeugt.	Automatisierte Mandantentrennungs-Prüfung in der Entwicklung, Datenbankprüfungen
Ids fremder Objekte ausprobieren	Bei Einzelressourcen werden unbekannte und fremde Ids gleich mit 404 beantwortet, nicht mit „keine Berechtigung“. Bei den Sammelabrufen per by-ids antwortet die API mit 200 und lässt unbekannte, fremde und nicht sichtbare Kennungen einfach weg. In beiden Fällen verrät die API nicht, ob es eine Id anderswo gibt.	Automatisierte Tests
Interna in Fehlermeldungen	Fehler haben ein festes Format mit Fehlercode und request_id. Ein interner Fehler (500) nennt keine Einzelheiten; Antworten werden nicht zwischengespeichert.	Automatisierte Tests

Missbrauch und Wiederholungen

Bedrohung	Schutzmaßnahme	Wie wir das prüfen
Massenanfragen	Grenzen je Adresse, je Token und je Organisation; beim Token-Kontingent sind lesende und schreibende Aufrufe getrennt; die Sandbox hat engere Grenzen. Siehe Seite „Grenzen“.	Automatisierte Tests
Doppelte Buchung durch Wiederholung	Schreibende Aufrufe nehmen in der Regel einen Idempotency-Key: Wiederholen Sie dieselbe Anfrage mit demselben Schlüssel, wird das Ergebnis zurückgegeben statt etwas zweimal anzulegen. Wie lange und woran der Schlüssel gebunden ist, hängt vom Endpunkt ab: bei den meisten an das Token (nach einem Tokenwechsel kann ein neuer Vorgang entstehen), bei einigen (etwa Importe, Termine, DATEV-Exporte) an die Organisation; die Übernahme eines Imports braucht keinen Schlüssel, weil sie von sich aus wiederholbar ist. Nach Ablauf der Aufbewahrungsfrist kann eine späte Wiederholung einen neuen Vorgang auslösen. Die verbindliche Tabelle je Endpunkt steht unter Idempotenz.	Automatisierte Tests
Nachvollziehbarkeit	Abrufe werden protokolliert (ohne Token und ohne Inhalte), abgelehnte Anmeldungen mit bekannter Token-Kennung eingeschlossen; Sie sehen den Verlauf je Token in der Verwaltung. Das Protokoll ist ein Hilfsmittel auf Bestmöglich-Basis und kann unvollständig sein (etwa bei sehr vielen abgelehnten Anmeldungen oder bei Störungen des Protokolls).	Automatisierte Tests, Datenbankprüfungen

Webhooks

Bedrohung	Schutzmaßnahme	Wie wir das prüfen
Gefälschte Nachricht	Jede Nachricht ist signiert (HMAC-SHA256 über Zeitstempel und unveränderten Rohkörper). Der Empfänger soll die Signatur mit einem Vergleich in konstanter Zeit prüfen. Beispielcode dafür steht im Webhooks-Handbuch.	Gemeinsame Testvektoren für alle Beispiele, automatisierte Tests
Wiederholt eingespielte Nachricht (Replay)	Wir liefern einen signierten Zeitstempel und eine gleichbleibende Ereignis-Kennung. Gegen Replay schützt der Empfänger: Er muss Nachrichten ablehnen, die älter als 5 Minuten sind, und verarbeitete Ereignis-Kennungen speichern. Der Server erzwingt das nicht.	Automatisierte Tests
Geheimnis wird bekannt oder geht verloren	Das Geheimnis wird nur verschlüsselt gespeichert und nur einmal angezeigt. Eine Rotation ist jederzeit möglich; das bisherige Geheimnis gilt danach noch 24 Stunden mit, damit Sie ohne Ausfall umstellen können. Es gilt immer nur das unmittelbar vorherige Geheimnis mit: Rotieren Sie innerhalb dieser 24 Stunden ein zweites Mal, endet die Übergangsfrist des ersten Geheimnisses sofort.	Automatisierte Tests
Webhook-Adresse als Hebel gegen interne Systeme (SSRF)	Nur https auf Port 443, nur öffentliche Ziele. Die Adresse wird beim Anlegen und bei jedem Senden geprüft; die Verbindung geht genau zu den geprüften Adressen, damit ein späterer DNS-Wechsel (DNS-Rebinding) nichts ändert. Weiterleitungen werden nicht verfolgt, der Antwortinhalt des Empfängers wird nicht gespeichert, und es werden keine internen Ablaufverfolgungs-Köpfe mitgesendet.	Automatisierte Tests
Verlorene oder doppelte Nachrichten	Wiederholungen mit gleichbleibender Ereignis-Kennung, Erkennung doppelter Ereignisse, erneutes Senden (Replay) fehlgeschlagener Zustellungen, Pausieren statt Verwerfen beim Abschalten, Abgleich über die Listen-Endpunkte. Das ist ein Zuverlässigkeitsthema und zugleich eines der Datenintegrität — Grenzen siehe unten.	Automatisierte Tests, Datenbankprüfungen

Sandbox, Status und Verwaltung

Bedrohung	Schutzmaßnahme	Wie wir das prüfen
Test- und Echtdaten vermischen sich	Die Sandbox ist eine eigene Organisation mit erfundenen Musterdaten. Ein Test-Token sieht nur diese Daten, ein echtes Token nie die Sandbox. Die Zuordnung wird in der Datenbank erzwungen; passt sie nicht, wird das Token abgewiesen. Antworten auf Test-Tokens tragen den Kopf X-M2H-Sandbox.	Automatisierte Tests, Datenbankprüfungen
Kundendaten auf der Statusseite	Die Statusseite zeigt nur aggregierte Werte (Zustand, Verfügbarkeit, Vorfälle, wenige Kennzahlen) ohne Angaben zu einzelnen Kunden, Organisationen oder Tokens.	Automatisierte Tests, Datenbankprüfungen
Token-Verwaltung von außen missbrauchen	Tokens anlegen und widerrufen geht nur angemeldet in der Verwaltung und nur mit dem Recht auf API-Zugänge. Die Verwaltung ist vom API-Host getrennt: Auf dem API-Host gibt es keine Verwaltungsseiten.	Automatisierte Tests
Geheimnisse in Protokollen	Das Abrufprotokoll enthält weder Token noch Inhalte; Fehlermeldungen des Netzes werden auf feste Codes abgebildet. Die Fehlerüberwachung maskiert bekannte Felder mit Zugangsdaten.	Automatisierte Tests

4. Bekannte Grenzen und akzeptierte Restrisiken

Webhooks sind nicht „genau einmal“. Nachrichten können mehrfach, in anderer Reihenfolge oder verspätet ankommen, und in seltenen Fällen kann ein Ereignis verloren gehen. Verarbeiten Sie fachlich idempotent und gleichen Sie regelmäßig über die Listen ab (siehe Bekannte Grenzen der Webhooks).
Die Statusseite misst im selben Dienst, den sie beobachtet. Fällt der gesamte Dienst aus, kann die Seite selbst betroffen sein. Sie ersetzt keine eigene Überwachung Ihrer Integration.
Ein gültiges Token ist ein Schlüssel. Wer es besitzt, darf im Rahmen seiner Berechtigungen alles tun, was es erlaubt, bis es widerrufen wird oder abläuft. Wir erkennen nicht, ob der Aufrufer „wirklich“ Ihre Integration ist.
Kein unabhängiger Nachweis. Es liegt derzeit keine unabhängige Penetrationstest-Bescheinigung und keine Zertifizierung (etwa ISO 27001 oder SOC 2) für die API vor. Die unten genannten Prüfverfahren sind eigene, automatisierte und KI-gestützte Prüfungen — sie ersetzen keine unabhängige Prüfung.
Die Organisationsprüfung der Datenbankfunktionen ist eine Entwurfsregel. Ob alle Funktionen der API sie aufrufen, wird im Review geprüft; ein automatischer Test dafür fehlt bisher.
Nicht jede Prüfung zielt eigens auf die API. Einige der allgemeinen Sicherheitsprüfungen laufen für die gesamte Anwendung, nicht gezielt gegen die externe API. Die Datenbank der API wird zusätzlich durch eigene Prüfungen abgedeckt.

5. Was Sie tun sollten

Vergeben Sie jedem Token nur die Berechtigungen, die die Integration wirklich braucht, und legen Sie je Integration ein eigenes Token an.
Legen Sie Tokens und Webhook-Geheimnisse in einem Passwort-Manager oder Secret-Speicher ab — nie in Webseiten, Browser-Apps, E-Mails, Chats oder Git.
Prüfen Sie bei Webhooks immer die Signatur, und zwar über den unveränderten Rohkörper, nicht über erneut serialisiertes JSON. Vergleichen Sie in konstanter Zeit.
Lehnen Sie Nachrichten mit zu altem Zeitstempel ab (5 Minuten) und verarbeiten Sie jede Ereignis-Kennung nur einmal.
Rotieren Sie Webhook-Geheimnisse regelmäßig und sofort, wenn eines bekannt geworden sein könnte; widerrufen Sie Tokens, die Sie nicht mehr brauchen.
Betreiben Sie Webhook-Empfänger nur über https auf Port 443 mit einem gültigen Zertifikat und einer öffentlich erreichbaren Adresse.

Mehr dazu unter Sicherheit & Support, Authentifizierung und Webhooks.

6. Wie wir prüfen

Wir setzen mehrere Verfahren ein, die jeweils einen Teil der oben genannten Bedrohungen abdecken. Sie sind eigene Prüfungen und kein Gütesiegel einer unabhängigen Stelle:

Automatisierte Tests zu Token, Berechtigungen, Signatur, Adressprüfung, Zustellung und Dokumentation (laufen bei jeder Änderung).
Eine automatisierte Mandantentrennungs-Prüfung, die versucht, Daten einer Organisation aus einer anderen zu lesen.
Datenbankprüfungen („Sonden“) gegen die Datenbank der API, auch zeitgesteuert.
Statische Code-Analyse und Abhängigkeits-, Geheimnis- und Container-Prüfungen in der automatischen Qualitätssicherung (u. a. Sonar, Semgrep, Trivy, gitleaks).
Sicherheitsdurchsichten des Codes, auch mit KI-Unterstützung, bei größeren Änderungen der API.
Allgemeine automatisierte Angriffstests der Anwendung (u. a. SQL-Injection, Schnittstellen-Fuzzing, Web-Scanner).

7. Schwachstelle melden

Sicherheitsbedenken und Schwachstellen melden Sie bitte per E-Mail an security@manage2hero.com. Die Adresse steht auch in unserer security.txt (/.well-known/security.txt). Wir prüfen Ihre Meldung und melden uns bei Rückfragen.

Eine Meldung sollte enthalten:

den betroffenen Endpunkt oder die betroffene Funktion
die Schritte, mit denen sich das Problem nachstellen lässt
die vermutete Auswirkung
die request_id der betroffenen Antwort, falls vorhanden

Bitte nicht:

ein Token oder Geheimnis mitschicken — auch nicht, um das Problem zu belegen
Kundendaten mitschicken oder sammeln
auf Daten anderer Organisationen zugreifen, um die Lücke zu beweisen
Lasttests oder Denial-of-Service-Versuche gegen die Produktion durchführen

Haben Sie ein Token verloren, widerrufen Sie es zuerst sofort in der Verwaltung (siehe Sicherheit & Support).

Welche Änderungen wir ankündigen und wie lange alte Versionen laufen, steht unter Versionierung; Änderungen an der Beschreibung der Sicherheit erscheinen im Änderungsprotokoll.