Sicherheit · Architektur

Wo Ihre Daten liegen, wie sie geschützt sind – und warum wir es so gebaut haben.

Sicherheit ist bei uns keine Liste von Häkchen, sondern eine Reihe von Entscheidungen. Hier stehen sie – mit dem Grund, warum wir sie so getroffen haben, und dem Weg, wie Ihre IT sie nachprüfen kann.

Ein Ort

Was gilt: Daten und Anwendung laufen auf Microsoft Azure in der Region Schweden-Mitte: Datenbank, Anwendung, Dokumentenspeicher und Archiv. Die Oberfläche selbst – statische Dateien ohne Kundendaten – liefert ein globales Content Delivery Network aus.
Wie wir das sicherstellen: Die gesamte Umgebung ist als Code beschrieben und wird daraus aufgebaut – nicht von Hand. Die Region steht darin als Vorgabe für jede Komponente; ein Aufbau woanders wäre eine sichtbare Änderung im Code, kein Versehen. So bleibt die Antwort auf „Wo liegen meine Daten?“ ein Satz.
Wie Sie es prüfen: Auf Anfrage erhalten Sie die Liste der Azure-Dienste je Komponente mit Region – so, dass Ihr Datenschutzbeauftragter sie übernehmen kann.

Verschlüsselung und Schlüssel

Was gilt: Gespeicherte Daten sind durch Azure verschlüsselt, die Übertragung erfolgt ausschließlich über HTTPS mit TLS 1.2 oder neuer. Zugangsdaten zu Carrier-Konten werden zusätzlich auf Anwendungsebene mit AES-256 verschlüsselt.
Wie wir das sicherstellen: Der Schlüssel dafür liegt im Azure Key Vault, nie im Code und nie in einer Konfigurationsdatei. Die Anwendung greift über ihre eigene Identität darauf zu; es gibt kein Geheimnis, das jemand abschreiben könnte. Der Tresor ist gegen endgültiges Löschen geschützt. Ohne den Schlüssel sind die Carrier-Zugangsdaten auch für jemanden mit Datenbankzugriff wertlos.
Wie Sie es prüfen: Auf Anfrage zeigen wir den Aufbau: welche Identität welchen Schlüssel nutzen darf – und dass es keine zweite Kopie gibt.

Identität statt Passwörter

Was gilt: Menschen melden sich über Microsoft Entra ID an, mit Multi-Faktor-Authentifizierung Ihres Unternehmens. Systeme nutzen API-Schlüssel, die je Kunde vergeben und jederzeit widerrufbar sind.
Wie wir das sicherstellen: Wir speichern keine Passwörter – es gibt also keine zu verlieren. Ein API-Schlüssel wird beim Anlegen einmal angezeigt; bei uns liegt nur sein Hash (SHA-256). Anfragen je Schlüssel sind ratenbegrenzt, und Notfallzugänge werden bei Fehlversuchen gedrosselt.
Wie Sie es prüfen: Legen Sie in der Plattform einen Schlüssel an und widerrufen Sie ihn wieder – die Wirkung ist sofort, und beides steht im Protokoll.

Speicher ohne Kontoschlüssel

Was gilt: Kein Speicherkonto der Plattform lässt sich mit einem Kontoschlüssel öffnen, und kein Blob ist öffentlich erreichbar.
Wie wir das sicherstellen: Der Zugriff auf Dokumente und Archive läuft ausschließlich über die Identität der Anwendung mit genau der Rolle, die sie braucht. Ein Kontoschlüssel wäre ein einzelnes Geheimnis, das alles öffnet – deshalb ist er in der Infrastruktur abgeschaltet, nicht nur ungenutzt.
Wie Sie es prüfen: Auf Anfrage erhalten Sie den Auszug aus der Infrastruktur-Beschreibung, der genau das festlegt.

Sicherungen

Was gilt: Die Datenbank wird täglich gesichert; Sicherungen werden 14 Tage aufbewahrt, und innerhalb dieser Frist lässt sich jeder Zeitpunkt wiederherstellen.
Wie wir das sicherstellen: Die Sicherung ist Teil des verwalteten Datenbankdienstes von Azure und der Infrastruktur-Beschreibung – sie hängt nicht davon ab, dass jemand daran denkt. Dass sie trägt, wird geübt: Bei der letzten dokumentierten Übung am 22. September 2026 war die Anwendung nach der Wiederherstellung vollständig, mit allen Tabellen bis zum gewählten Zeitpunkt.
Wie Sie es prüfen: Auf Anfrage nennen wir Ihnen Aufbewahrung und Verfahren im Detail und zeigen das Protokoll der letzten Übung.

Wie Software zu uns in den Betrieb kommt

Was gilt: Jede Änderung an der Plattform durchläuft einen automatisierten Build mit Tests, bevor sie in eine Umgebung gelangt. Der Build ist zugleich das Schwachstellen-Tor: Enthält eine Abhängigkeit eine bekannte Sicherheitslücke, schlägt er fehl – auf dem Server ab mittlerer, in der Oberfläche ab hoher Schwere –, dazu ein wöchentlicher Prüflauf.
Wie wir das sicherstellen: Es gibt keinen Weg, Software am Build vorbei in den Betrieb zu bringen. Was nicht baut oder testet, wird nicht ausgeliefert – und was eine bekannte Lücke mitbringt, baut nicht. Wird die Gesundheitsprüfung nach einer Auslieferung rot, rollt sie automatisch zurück. Einmal pro Woche wird die Anwendung ohnehin mit aktuellem Basis-Image neu gebaut und in der Entwicklungsumgebung ausgerollt; in die Produktivumgebung kommt ein Stand nur mit einer Freigabe.
Wie Sie es prüfen: Auf Anfrage zeigen wir Ihnen den Ablauf und ein Beispiel für einen abgebrochenen Build.

Überwachung und Betreiberzugriff

Gesundheitsprüfung. Jede Komponente meldet ihren Zustand über einen Prüfpunkt; fällt er auf Rot, startet die Anwendung automatisch neu. Telemetrie und Protokolle laufen je Umgebung in Application Insights und Log Analytics zusammen.
Alarmierung. Verfügbarkeit, Fehlerquote, Datenbank und Warteschlange werden überwacht. Ein Ausfall meldet sich per E-Mail an zwei Personen auf unserer Seite – erprobt mit einem Testalarm, nicht nur eingerichtet.
Wartung kündigen wir an. Steht eine geplante Wartung an, erscheint ein Hinweis über der Anwendung – sichtbar bis zum angekündigten Ende.
Zwei benannte Personen. Zugriff auf Produktivdaten haben ausschließlich benannte Identitäten – zwei Personen, keine geteilten Konten. Geheimnisse liegen nur im Key Vault.
Einrichtungszugänge im Protokoll. Schlüssel, mit denen wir eine Umgebung einrichten, sind gedrosselt und jede Nutzung wird protokolliert.

Noch etwas offen?

Fragen Ihrer IT oder Ihres Prüfers beantworten wir direkt: info@opexguard.de

Alle Themen dieses Bereichs gibt es auch gesammelt als Whitepaper (PDF, Stand 24.09.2026).