Unterwegs und im Speicher
Jede Verbindung zur Plattform läuft über HTTPS mit TLS 1.2 oder neuer; unverschlüsselte Verbindungen werden nicht angenommen. Gespeicherte Daten – Datenbank, Dokumente, Archiv – sind durch Azure serverseitig verschlüsselt. Das ist der Stand, den jede Azure-Ressource mitbringt; er schützt Datenträger, nicht Zugriffe. Für Zugriffe gilt das Folgende.
Carrier-Zugangsdaten: Umschlagverschlüsselung
Zugangsdaten zu Carrier-Konten sind das wertvollste Geheimnis, das Sie uns anvertrauen. Sie liegen nicht „irgendwie verschlüsselt” in der Datenbank, sondern in einer Umschlagverschlüsselung (envelope encryption):
- Für jedes einzelne Geheimnis erzeugt die Anwendung einen frischen, zufälligen 32-Byte-Datenschlüssel (DEK) und verschlüsselt das Geheimnis damit – AES-256-GCM, mit Nonce und Authentifizierungs-Tag, sodass jede Veränderung des Chiffrats beim Entschlüsseln auffällt.
- Der Datenschlüssel wird mit einem Schlüssel im Azure Key Vault eingepackt (wrapped, RSA-OAEP-256). Das Einpacken und Auspacken geschieht im Tresor; das Schlüsselmaterial des Tresorschlüssels verlässt ihn nie und ist im Prozess der Anwendung nie vorhanden.
- Gespeichert wird ein Token aus Versionskennung, Kennung des Tresorschlüssels, eingepacktem Datenschlüssel, Nonce, Tag und Chiffrat. Der Datenschlüssel existiert im Speicher nur für die Dauer einer Operation und wird danach überschrieben.
Die Folgen: Wer die Datenbank in Händen hält, hält Chiffrate, die ohne den Tresor wertlos sind. Wer den Tresor kompromittieren wollte, müsste die Identität der Anwendung übernehmen – Zugriff auf den Tresor gibt es nur über die Managed Identity, ohne Passwort, ohne Verbindungszeichenfolge. Die Kennung des Tresorschlüssels im Token erlaubt eine Schlüsselrotation, ohne alte Geheimnisse neu verschlüsseln zu müssen. Der Tresor selbst ist in der Produktivumgebung gegen endgültiges Löschen geschützt.
Keine Geheimnisse im Code
Es gibt keine Verbindungszeichenfolge und keinen Schlüssel in einer Konfigurationsdatei der ausgelieferten Umgebungen. Die Anwendung hat eine eigene Identität in Azure und erhält über sie genau die Rollen, die sie braucht: Lesen und Schreiben im Dokumentenspeicher, Einpacken und Auspacken im Tresor, Ziehen ihres eigenen Container-Images. Die Speicherkonten erlauben keinen Zugriff per Kontoschlüssel – nicht „ungenutzt”, sondern abgeschaltet.
Menschen: Entra ID statt eigener Passwörter
Benutzer melden sich mit dem Microsoft-Konto ihres Unternehmens an (Microsoft Entra ID, OpenID Connect). Die Plattform speichert keine Passwörter – Anmeldung, Multi-Faktor-Authentifizierung, Sperrung beim Ausscheiden und Kennwortregeln bleiben in Ihrer Hand und in Ihrem Verzeichnis. Was bei uns liegt, ist die Zuordnung eines Kontos zu Mandant und Rechten. Ein Konto wird per Einladung verknüpft; der Einladungscode ist ein Zugangsgeheimnis und wird – wie alle Geheimnisse – nur als Hash gespeichert und nie protokolliert.
Systeme: API-Schlüssel als Hash
Ein Anschluss aus Ihrem ERP-, Shop- oder Warenwirtschaftssystem nutzt einen API-Schlüssel:
- Er wird je Kunde und Rolle ausgestellt und beim Anlegen genau einmal angezeigt.
- Bei uns liegt nur sein SHA-256-Hash. Ein Abfluss der Datenbank enthält keinen gültigen Schlüssel.
- Er ist jederzeit widerrufbar, mit sofortiger Wirkung; Ausstellen und Widerrufen stehen im Protokoll.
- Anfragen sind je Schlüssel ratenbegrenzt, damit ein einzelner Anschluss die Plattform nicht für andere bremst.
Schlüssel, mit denen wir als Betreiber eine Umgebung einrichten, folgen strengeren Regeln: Sie sind getrennt von den Kundenschlüsseln, werden bei Fehlversuchen gedrosselt, und jede Nutzung wird protokolliert.
Rechte statt Rollennamen
Autorisiert wird auf Ebene einzelner Rechte („Dokument hochladen”, „Protokoll des eigenen Mandanten lesen”). Rollen sind Bündel solcher Rechte: die Systemrollen Betreiber, Mandanten-Admin, Benutzer, Prüfer (nur Lesen, mit Export des eigenen Protokolls und dem Prüfpaket je Sendung) und Integration für angebundene Systeme – weitere legen wir für Sie an. Die Oberfläche prüft Rechte, nie Rollennamen. Die Betreiberrolle lässt sich zur Laufzeit nicht verändern; sie wird bei jedem Start mit dem Stand der Software abgeglichen. Die übrigen Systemrollen erhalten ihre Rechte beim Anlegen und behalten danach, was ein Administrator an ihnen einstellt – bringt ein Update neue Rechte, ziehen wir sie mit der Auslieferung nach.