Sicherheitserklärung

Diese Erklärung beschreibt die technischen und organisatorischen Maßnahmen, die den RavSolutions-Dienst und die darin gehaltenen Daten schützen. Sie ist so geschrieben, dass sie überprüfbar ist: Sie nennt Maßnahmen, die tatsächlich umgesetzt sind, und Ziffer 15 benennt ebenso deutlich, was wir nicht haben.

Sie ist keine Zusicherung und begründet keine Verfügbarkeitszusage; die vertraglichen Bedingungen stehen in den Allgemeinen Geschäftsbedingungen. Wo dieselbe Maßnahme auch in der DSGVO-Information oder in der Auftragsverarbeitungsinformation erscheint, soll sie inhaltlich dasselbe aussagen.

Sie betrifft den von uns betriebenen Dienst. Für die Sicherheit der Konten, Geräte und Passwörter im eigenen Arbeitsbereich ist der Abonnent verantwortlich; keine der hier beschriebenen Maßnahmen schützt einen Arbeitsbereich, dessen Zugangsdaten weitergegeben oder mehrfach verwendet wurden.

Der Dienst besteht aus drei Oberflächen – der Website, der Anwendung und dem Kundenportal –, einer einzigen API, einer PostgreSQL-Datenbank, einer Redis-Instanz und Objektspeicher. Die Oberflächen erreichen die API ausschließlich über HTTPS.

Alles außer dem Objektspeicher läuft hinter einem Reverse Proxy auf der Infrastruktur von RackForest Zrt. in Hungary (EU). Datenbank und Redis hängen ausschließlich an einem internen Netzwerk und veröffentlichen keinen Port, sind also aus dem Internet nicht erreichbar; nur die API kann mit ihnen sprechen.

Hochgeladene Dateien liegen nicht auf den Anwendungsservern, sondern im Cloudflare-R2-Objektspeicher, konfiguriert für European Union. Der Bucket ist privat: kein öffentlicher Zugriff, keine vorgeschaltete eigene Domain, und jede Datei wird über einen von der API signierten Link ausgeliefert.

Geheimnisse – Datenbankzugangsdaten, Signaturschlüssel, API-Schlüssel von Anbietern – werden beim Deployment über die Umgebung bereitgestellt und niemals in das Quellcode-Repository eingecheckt.

Der gesamte Verkehr zur Website, zur Anwendung, zum Portal und zur API läuft über HTTPS. Zertifikate werden von Let's Encrypt automatisch ausgestellt und erneuert, unverschlüsselte HTTP-Anfragen werden auf HTTPS umgeleitet.

Der Reverse Proxy sendet HTTP Strict Transport Security mit einer Gültigkeit von einem Jahr, einschließlich Subdomains und mit Preload, sodass ein Browser, der die Seite einmal gesehen hat, nicht auf eine unverschlüsselte Verbindung zurückfällt.

Antworten tragen X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, eine Referrer-Policy strict-origin-when-cross-origin sowie eine Permissions-Policy, die Kamera, Mikrofon und Standort verweigert. Header, die Server und Framework preisgeben, werden entfernt. Die API akzeptiert Cross-Origin-Anfragen nur von den Ursprüngen der Anwendung und des Portals.

Die Website, die Anwendung und das Portal werden mit einer Content Security Policy ausgeliefert. Skripte dürfen nur vom Dienst selbst geladen werden und in der Anwendung zusätzlich von Google Identity Services für die Anmeldung mit Google; auf der Website und im Portal ist kein Skript Dritter zugelassen. Das Einbetten in einen Frame, Plugin-Inhalte und das Umschreiben der Dokumentbasis werden abgelehnt, und die API antwortet mit einer Richtlinie, die überhaupt nichts erlaubt.

Ein Passwort muss mindestens acht Zeichen lang sein und einen Groß-, einen Kleinbuchstaben und eine Ziffer enthalten. Passwörter werden ausschließlich als gesalzener kryptografischer Hashwert des Passwort-Hashers von ASP.NET Core Identity gespeichert, nie in rücklesbarer Form; ein vergessenes Passwort können wir daher nicht wiederherstellen, sondern nur zurücksetzen lassen.

Nach zehn fehlgeschlagenen Anmeldeversuchen wird das Konto fünfzehn Minuten gesperrt. Gezählt wird gegen das Konto und nicht gegen den Aufrufer, sodass auch ein über viele Adressen verteilter Versuch gestoppt wird, obwohl jede einzelne Adresse unter dem Limit pro Aufrufer bleibt.

Die Anmeldung mit einem Google-Konto ist möglich. Das von Google ausgestellte Identitätstoken wird vor jeder Sitzung bei Google geprüft; das Google-Passwort erhalten wir nie.

Bei der Registrierung wird eine Bestätigungsnachricht an die angegebene Adresse gesendet; die Adresse gilt als bestätigt, sobald der darin enthaltene Link benutzt wurde. Ein vergessenes Passwort wird über einen einmaligen Link an die hinterlegte Adresse neu gesetzt; ein erfolgreiches Zurücksetzen hebt auch eine bestehende Sperre auf, denn genau diese ist meist der Anlass dafür.

Zugriffstoken sind JSON Web Token mit fünfzehn Minuten Gültigkeit. Bei jeder Anfrage werden Aussteller, Zielgruppe, Signatur und Ablauf geprüft, ohne jede zugelassene Zeitabweichung.

Ein Refresh-Token besteht aus vierundsechzig Bytes eines kryptografischen Zufallsgenerators. Die Datenbank hält nur dessen SHA-256-Hashwert, sodass das Token selbst aus einer Kopie der Datenbank nicht auslesbar ist.

Jede Erneuerung tauscht das Token aus: Das bisherige wird widerrufen, ein neues ausgestellt. Refresh-Token laufen nach dreißig Tagen ab, und das Abmelden widerruft das Token sofort.

Eine Erneuerung wird abgelehnt, wenn der Nutzer deaktiviert oder der Arbeitsbereich inaktiv gesetzt wurde; der Entzug eines Zugangs wirkt damit spätestens mit dem Ablauf des laufenden Zugriffstokens.

Jeder Nutzer hat eine Rolle im Arbeitsbereich, und die Endpunkte prüfen sie. Tarifabhängige Funktionen sind zusätzlich durch eigene Autorisierungsrichtlinien geschützt, sodass eine Funktion außerhalb des gebuchten Tarifs von der API abgelehnt und nicht bloß in der Oberfläche ausgeblendet wird.

Arbeitsbereiche sind auf Datenebene getrennt: Jeder Datensatz trägt die Kennung des Arbeitsbereichs, zu dem er gehört, und jede Abfrage ist auf den Arbeitsbereich des Aufrufers beschränkt. Ein Datensatz eines anderen Arbeitsbereichs wird nicht ausgeblendet – er gelangt gar nicht erst in das Ergebnis.

Der Arbeitsbereich wird einem Claim des signierten Zugriffstokens entnommen und serverseitig aufgelöst. Einer vom Client übermittelten Arbeitsbereichskennung wird zu keinem Zweck vertraut.

Echtzeitverbindungen nutzen dieselbe Authentifizierung wie die übrige API; eine Verbindung ohne gültiges Token wird abgelehnt, die Größe eingehender Nachrichten ist begrenzt, und ausführliche Fehlerinformationen gibt es nur in der Entwicklungsumgebung.

Der Kunde erhält einen Link mit einem zufällig erzeugten Token, das zu genau einem Auftrag gehört und ein Ablaufdatum trägt. Das Token öffnet diesen einen Auftrag und sonst nichts im Arbeitsbereich.

Bevor der Auftrag angezeigt wird, muss der Besucher die für den Kunden hinterlegte E-Mail-Adresse oder Telefonnummer bestätigen. Eine erfolgreiche Bestätigung erzeugt einen zwölf Stunden gültigen Nachweis, der mit HMAC und einem aus dem Signaturgeheimnis des Servers abgeleiteten, davon aber kryptografisch unabhängigen Schlüssel signiert und in konstanter Zeit geprüft wird.

Bestätigungsversuche werden pro Aufrufer begrenzt und bewusst nicht pro Token: Eine Begrenzung pro Token erlaubte es jedem, einen Kunden allein durch Aufbrauchen des Budgets von seinem eigenen Auftrag auszusperren.

Uploads sind auf eine feste Liste von Dateitypen – JPEG, PNG, WebP, PDF, DOCX, XLSX und einfachen Text – und auf eine vom gebuchten Tarif abhängige Höchstgröße beschränkt. Bilder werden vor der Speicherung serverseitig neu kodiert.

Dateien werden über kurzlebige signierte Links ausgeliefert, die die API erzeugt. Da der Bucket selbst privat ist, gewährt ein abgelaufener oder veränderter Link überhaupt nichts.

Für Upload und Download gelten getrennte Limits pro Aufrufer, sodass ein durchgesickerter Link oder ein außer Kontrolle geratener Client nicht unbegrenzt Speicher und Bandbreite verbrauchen kann.

Gespeicherte Dateien werden vom Speicheranbieter im Ruhezustand verschlüsselt.

Die API wendet Limits an, die pro Aufrufer partitioniert sind – nach Arbeitsbereich und Nutzer aus dem Token, sofern vorhanden, sonst nach Adresse des Clients. Anmeldung, Google-Anmeldung, Passwortzurücksetzung und Portalbestätigung sind auf zehn Versuche pro Minute begrenzt, die Registrierung auf fünf.

Die Limiter lesen die tatsächliche Adresse des Aufrufers aus den Forwarded-Headern des Proxys, und nur dem Proxy selbst wird zugestanden, sie zu setzen. Ohne diese Konfiguration schiene jede Anfrage vom Proxy zu kommen und ein einziges Budget würde von allen geteilt – aus dem Schutz würde ein Ausfall.

Der Reverse Proxy wendet vor der Anwendung ein weiteres Gesamtlimit an, sodass der Verkehr gedeckelt wird, bevor er die API überhaupt erreicht.

Eingehende Daten werden serverseitig geprüft, bevor sie die Fachlogik erreichen, und Fehler werden als strukturierte Meldungen zurückgegeben: keine Stacktraces, keine Datenbankmeldungen, keine internen Pfade.

Datenbank und Redis liegen ausschließlich im internen Netz und nehmen Verbindungen nur von der API an; keines von beiden ist zum Internet hin exponiert.

Der Objektspeicher verschlüsselt gespeicherte Dateien im Ruhezustand, und der Bucket ist nicht öffentlich lesbar.

Sicherungen werden regelmäßig erstellt und ihre Wiederherstellung wird getestet. Zum Ende eines Abonnements gelöschte Daten verschwinden aus den Sicherungen, sobald diese im üblichen Turnus auslaufen; bis dahin werden sie zu keinem anderen Zweck verwendet.

Die Anwendung schreibt Serverprotokolle und führt je Arbeitsbereich einen Aktivitätsverlauf darüber, welcher Nutzer wann was geändert hat. Der Verlauf ist für den Abonnenten in der Anwendung einsehbar.

Server-, Anwendungs- und Sicherheitsprotokolle werden 90 Tage aufbewahrt, es sei denn, ein einzelner Eintrag wird für eine laufende Sicherheitsuntersuchung länger benötigt.

Protokolle dienen dem Betrieb des Dienstes und der Untersuchung von Vorfällen. Passwörter, Sitzungstoken und Zahlungskartendaten werden nicht protokolliert.

Zugriff auf Produktivsysteme und Produktivdaten haben nur die Personen, die ihn für Betrieb oder Support benötigen, nach dem Grundsatz der geringstmöglichen Berechtigung und unter einer Vertraulichkeitspflicht, die über das Ende der Tätigkeit hinaus fortbesteht.

Abhängigkeiten von Dritten sind auf feste Versionen gesetzt und zentral verwaltet, sodass eine Version an einer Stelle geändert wird; Sicherheitsupdates für die Plattform und ihre Abhängigkeiten spielen wir ein, sobald sie verfügbar sind.

Änderungen am Datenbankschema werden als versionierte Migrationen beim Start des Dienstes angewendet, sodass das Schema in der Produktion stets zu dem Code passt, der darauf läuft.

Die Anbieter, die in unserem Auftrag Daten verarbeiten – Hosting, Objektspeicher, E-Mail-Zustellung, Zahlung und Rechnungsstellung –, sind mit Rolle und Region in Ziffer 5 der DSGVO-Information und Ziffer 8 der Auftragsverarbeitungsinformation benannt.

Ein neuer Anbieter wird mindestens 30 Tage vor Beginn der Verarbeitung angekündigt, damit ein widersprechender Abonnent Zeit zum Handeln hat.

Wir führen ein internes Verzeichnis von Verletzungen des Schutzes personenbezogener Daten und folgen einem Verfahren, das Erkennung, Bewertung, Eindämmung und Meldung abdeckt.

Führt eine Verletzung voraussichtlich zu einem Risiko für die Rechte und Freiheiten natürlicher Personen, melden wir sie der zuständigen Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Kenntnisnahme (Art. 33 DSGVO); bei hohem Risiko benachrichtigen wir auch die betroffenen Personen in klarer Sprache (Art. 34 DSGVO).

Handeln wir als Auftragsverarbeiter, informieren wir den als Verantwortlichen handelnden Abonnenten unverzüglich nach Kenntnisnahme und unterstützen ihn bei seinen eigenen Meldepflichten.

Kein Onlinedienst lässt sich absolut sicher machen. Diese Seite beschreibt Maßnahmen, keine Garantien, und die Allgemeinen Geschäftsbedingungen enthalten weder eine Verfügbarkeits- noch eine Service-Level-Zusage.

Wir haben weder eine Zertifizierung nach ISO/IEC 27001 noch einen SOC-2-Bericht, und der Dienst wurde keinem unabhängigen Penetrationstest unterzogen. Ändert sich daran etwas, wird es an dieser Stelle stehen.

Eine Zwei-Faktor-Authentifizierung für Benutzerkonten gibt es noch nicht. Die Kontosicherheit beruht daher auf der Stärke des Passworts, der Kontosperre und den oben beschriebenen Limits – deshalb bitten wir um ein Passwort, das nirgends sonst verwendet wird.

Der Dienst läuft in einer einzigen Region ohne regionsübergreifende Ausweichmöglichkeit; fällt diese Region aus, ist der Dienst bis zu ihrer Rückkehr nicht verfügbar. Wir benennen das, weil eine Sicherheitserklärung, die nur Stärken aufzählt, als Entscheidungsgrundlage untauglich ist.

Wenn Sie eine Schwachstelle finden, schreiben Sie bitte an info@ravsolutions.eu – mit Beschreibung, den Schritten zur Reproduktion und der betroffenen Adresse. Wir bestätigen den Eingang und teilen mit, wie wir damit umzugehen gedenken.

Bitte geben Sie uns vor einer Veröffentlichung eine angemessene Gelegenheit zur Behebung. Greifen Sie beim Testen nicht auf fremde Daten zu, verändern oder löschen Sie sie nicht, beeinträchtigen Sie den Dienst für andere nicht und setzen Sie keine Social-Engineering-Methoden gegen unsere Mitarbeiter oder unsere Anbieter ein.

Ein bezahltes Bug-Bounty-Programm betreiben wir nicht. Gegen eine meldende Person, die gutgläubig und innerhalb der genannten Grenzen handelt, gehen wir nicht vor.

Diese Erklärung wird mit dem Dienst aktuell gehalten. Versionsnummer und Datum des Inkrafttretens am Seitenkopf zeigen, welcher Text gilt; frühere Fassungen sind auf Anfrage erhältlich.

Ändert sich eine hier beschriebene Maßnahme, ändert sich diese Seite mit ihr. Fragen zum Inhalt können an info@ravsolutions.eu gerichtet werden.