Verschlüsselung von ISMS-Daten: At Rest, In Transit und im Backup

Warum ISMS-Daten besonders schützenswert sind

Nicht alle Daten in einem Unternehmen sind gleich sensibel. Kundenstammdaten, Projektpläne und Marketingmaterial erfordern Schutz, aber ihr Verlust ist in der Regel handhabbar. ISMS-Daten bilden eine eigene Kategorie. Sie dokumentieren systematisch, wo ein Unternehmen verwundbar ist.

Ein Risikoregister listet auf, welche Bedrohungen das Unternehmen identifiziert hat und wie wahrscheinlich und schwerwiegend sie eingeschätzt werden. Die Risikobewertung enthält Bewertungen darüber, welche Systeme unzureichend geschützt sind. Das Statement of Applicability dokumentiert, welche Sicherheitsmaßnahmen nicht umgesetzt sind und warum. Audit-Berichte listen Abweichungen und Schwachstellen auf. Maßnahmenpläne zeigen, welche Lücken noch offen sind und wann sie geschlossen werden sollen.

Für einen Angreifer ist das ein Schatz. Statt selbst nach Schwachstellen zu suchen, findet er eine fertige Dokumentation der Angriffsfläche. Wo sind die Systeme nicht gepatcht? Welche Controls fehlen? Welche Risiken hat das Unternehmen bewusst akzeptiert, weil die Eintrittswahrscheinlichkeit als gering eingeschätzt wurde? Wenn diese Daten in falsche Hände geraten, hat der Angreifer einen detaillierten Angriffsplan.

Genau deshalb reicht es nicht, ISMS-Daten genauso zu behandeln wie andere Geschäftsdaten. Sie brauchen Verschlüsselung auf jeder Ebene: wenn sie gespeichert sind (at rest), wenn sie übertragen werden (in transit) und wenn sie gesichert werden (im Backup). Jede einzelne dieser Ebenen hat eigene Anforderungen und eigene Fallstricke.

AES-256-GCM für sensible Datenbankfelder

Die erste Verteidigungslinie ist die Verschlüsselung der Daten dort, wo sie dauerhaft gespeichert werden: in der Datenbank. Dabei gibt es verschiedene Ansätze mit unterschiedlichem Schutzniveau.

Festplattenverschlüsselung allein reicht nicht

Viele Unternehmen setzen auf Full Disk Encryption (FDE) und halten das für ausreichend. BitLocker unter Windows, LUKS unter Linux oder FileVault unter macOS verschlüsseln die gesamte Festplatte. Das schützt gegen einen spezifischen Angriffsvektor: den physischen Diebstahl des Speichermediums. Wenn jemand die Festplatte aus dem Server ausbaut, kann er ohne den Entschlüsselungsschlüssel nichts damit anfangen.

Aber FDE schützt nicht gegen den häufigeren Angriffsvektor: einen Angreifer, der sich über das Netzwerk Zugang zum laufenden System verschafft. Sobald der Server läuft und die Festplatte entschlüsselt ist, liegt die Datenbank im Klartext vor. Jeder Prozess, der Zugriff auf die Datenbankdateien hat, kann sie lesen. Ein Angreifer, der Root-Zugriff auf den Server erlangt, ein kompromittierter Backup-Prozess oder ein Datenbankadministrator mit zu weitreichenden Rechten sieht alles unverschlüsselt.

Festplattenverschlüsselung ist notwendig, aber sie ist die unterste Schicht. Für ISMS-Daten brauchst du eine zusätzliche Ebene.

Transparent Data Encryption (TDE) als Zwischenschritt

Transparent Data Encryption verschlüsselt die Datenbankdateien auf der Festplatte, sodass ein Kopieren der Datenbankdateien ohne den TDE-Schlüssel nutzlos ist. SQL Server, PostgreSQL und MySQL bieten TDE nativ an. Der Vorteil: Es erfordert keine Änderungen an der Anwendung. Die Verschlüsselung geschieht transparent auf der Datenbankebene.

Die Einschränkung: TDE schützt die Daten im Ruhezustand auf Dateiebene, aber nicht innerhalb der laufenden Datenbank. Eine SQL-Abfrage liefert die Daten im Klartext zurück. Ein Angreifer, der gültige Datenbank-Credentials hat, ob durch Phishing, Credential Stuffing oder eine SQL-Injection in der Anwendung, sieht alle Daten unverschlüsselt.

Für viele Anwendungsfälle ist TDE ein guter Kompromiss. Für ISMS-Daten, deren Vertraulichkeit höchste Priorität hat, reicht es nicht.

Feldbasierte Verschlüsselung mit AES-256-GCM

Der stärkste Schutz für besonders sensible Daten ist die Verschlüsselung auf Feldebene. Dabei werden nicht die gesamten Datenbankdateien verschlüsselt, sondern gezielt einzelne Spalten oder Felder, die sensible Informationen enthalten. Die Verschlüsselung und Entschlüsselung geschieht in der Anwendungsschicht, bevor die Daten an die Datenbank übergeben werden.

ISMS Lite setzt genau diesen Ansatz ein. Sensible Felder wie Risikobeschreibungen, Schwachstellendetails und Audit-Feststellungen werden mit AES-256-GCM verschlüsselt, bevor sie in die Datenbank geschrieben werden. AES-256-GCM bietet dabei zwei Eigenschaften, die für ISMS-Daten besonders relevant sind:

Authenticated Encryption. GCM (Galois/Counter Mode) ist ein authentifizierter Verschlüsselungsmodus. Er gewährleistet nicht nur Vertraulichkeit (niemand kann die Daten lesen), sondern auch Integrität (niemand kann die verschlüsselten Daten unbemerkt verändern). Wenn ein Angreifer die verschlüsselten Datenbankfelder manipuliert, schlägt die Entschlüsselung fehl, statt manipulierte Daten zu liefern. Bei einem Risikoregister, dessen Integrität auditrelevant ist, ein wichtiges Merkmal.

256-Bit-Schlüssellänge. AES-256 gilt nach aktuellem Stand der Technik als sicher gegen Brute-Force-Angriffe, auch unter Berücksichtigung potenzieller Quantencomputer. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seiner Technischen Richtlinie TR-02102-1 AES mit 128 oder 256 Bit. Für langfristig schützenswerte Daten wie ISMS-Dokumentation ist 256 Bit die richtige Wahl.

Was verschlüsselt wird und was nicht

Nicht jedes Datenbankfeld muss verschlüsselt werden. Feldbasierte Verschlüsselung hat einen Performance-Overhead und macht bestimmte Datenbankoperationen unmöglich (du kannst nicht nach verschlüsselten Feldern suchen oder sortieren, ohne sie vorher zu entschlüsseln). Die Kunst liegt in der richtigen Klassifizierung.

Felder die verschlüsselt werden sollten:

Felder die nicht verschlüsselt werden müssen:

Die Grenze verläuft entlang der Frage: Kann ein Angreifer aus diesem Feld allein einen Angriff ableiten oder eine Schwachstelle identifizieren? Wenn ja, verschlüsseln. Wenn nein, kann es im Klartext bleiben, was Performance und Funktionalität schont.

TLS für alle Verbindungen: Nicht nur das Webinterface

Die zweite Ebene der Verschlüsselung betrifft Daten in Bewegung. Jedes Mal, wenn ISMS-Daten von einem System zum anderen übertragen werden, müssen sie verschlüsselt sein. Das klingt selbstverständlich, ist es in der Praxis aber überraschend oft nicht.

Das Webinterface: TLS 1.3 als Minimum

Dass das Webinterface eines ISMS-Tools über HTTPS laufen muss, ist offensichtlich. Weniger offensichtlich ist, welche TLS-Version und welche Cipher Suites akzeptabel sind.

TLS 1.2 ist noch weit verbreitet und grundsätzlich sicher, wenn die Cipher Suites korrekt konfiguriert sind. TLS 1.3 bietet allerdings handfeste Verbesserungen: Der Handshake ist schneller (ein Round-Trip statt zwei), unsichere Cipher Suites sind per Design ausgeschlossen, und Forward Secrecy ist obligatorisch. Für neue Installationen gibt es keinen Grund, weniger als TLS 1.3 zu konfigurieren.

Was du vermeiden musst:

• TLS 1.0 und 1.1 sind seit 2021 offiziell deprecated und von allen gängigen Browsern abgelehnt
• SSL in jeder Version (ja, das gibt es auf manchen älteren Systemen noch)
• Cipher Suites mit CBC-Mode (anfällig für Padding-Oracle-Angriffe)
• Cipher Suites ohne Forward Secrecy (RSA Key Exchange ohne ECDHE)

Für Self-Hosted-Instanzen erledigt ein Reverse Proxy wie Traefik oder Caddy die TLS-Terminierung automatisch mit Let's-Encrypt-Zertifikaten und sicheren Standardeinstellungen. Du musst dich nicht selbst um Cipher-Suite-Konfiguration kümmern, solange du den Reverse Proxy aktuell hältst.

API-Verbindungen: Der blinde Fleck

Viele ISMS-Tools bieten eine REST-API für Integrationen: Import von Asset-Daten aus dem IT-Asset-Management, Export von Risikodaten für das Management-Reporting, Anbindung an Ticketsysteme für die Maßnahmenverfolgung. Jede dieser Verbindungen überträgt ISMS-Daten und muss verschlüsselt sein.

In der Praxis werden API-Verbindungen innerhalb des eigenen Netzwerks gerne unverschlüsselt betrieben, nach dem Motto: "Ist ja nur intern." Das ist ein Trugschluss. Ein Angreifer, der sich im internen Netzwerk bewegt (Lateral Movement nach einem initialen Compromise), kann unverschlüsselten internen Traffic genauso mitlesen wie externen. Die Netzwerksegmentierung hilft, den Blast Radius zu begrenzen, aber sie ersetzt keine Verschlüsselung.

Alle API-Aufrufe müssen über HTTPS laufen, auch innerhalb des eigenen Netzwerks. Zusätzlich sollte die API-Authentifizierung über API-Keys oder OAuth-Tokens erfolgen, die regelmäßig rotiert werden.

Datenbankverbindungen verschlüsseln

Wenn die Anwendung und die Datenbank auf verschiedenen Systemen laufen (was bei einer sauberen Architektur der Fall ist), muss auch die Verbindung zwischen beiden verschlüsselt sein. MariaDB, PostgreSQL und andere Datenbanken unterstützen TLS-verschlüsselte Verbindungen nativ. Bei einer Docker-basierten Architektur, wie sie für Self-Hosted-ISMS-Instanzen typisch ist, lässt sich das über die Datenbankkonfiguration erzwingen.

Was in der Praxis häufig passiert: Die Applikation läuft im selben Docker-Netzwerk wie die Datenbank, und die Verbindung läuft unverschlüsselt über das Docker-Bridge-Netzwerk. Das ist für einen einzelnen Server mit beiden Containern vertretbar, solange der Server physisch und logisch gesichert ist. Sobald Applikation und Datenbank auf verschiedenen Hosts laufen, ist TLS für die Datenbankverbindung nicht verhandelbar.

Backup-Transfers: Oft vergessen

Wenn deine Backups über das Netzwerk auf einen separaten Storage-Server oder in die Cloud übertragen werden, muss dieser Transfer verschlüsselt sein. Tools wie restic, BorgBackup und Veeam verschlüsseln den Transfer nativ. Wenn du Backups per rsync oder SCP überträgst, läuft die Verschlüsselung über SSH. Unverschlüsselte Backup-Transfers (FTP, unverschlüsseltes NFS) sind nicht akzeptabel, auch nicht im internen Netzwerk.

Backup-Verschlüsselung: Die am häufigsten vergessene Ebene

Von den drei Verschlüsselungsebenen (at rest, in transit, Backup) wird die Backup-Verschlüsselung am häufigsten übersehen. Das ist paradox, weil Backups oft das leichteste Ziel sind.

Warum Backups ein attraktives Angriffsziel sind

Backups haben Eigenschaften, die sie für Angreifer besonders interessant machen:

Sie enthalten alles. Ein Datenbank-Backup enthält sämtliche Daten, inklusive historischer Daten, die im Produktivsystem möglicherweise schon gelöscht wurden. Ein ISMS-Backup enthält also nicht nur die aktuellen Risikobewertungen, sondern auch die der letzten Monate und Jahre, alte Vorfallberichte und abgeschlossene Audit-Feststellungen.

Sie liegen oft an weniger geschützten Orten. Das Produktivsystem steht in einem gesicherten Rechenzentrum mit Zutrittskontrolle, Firewalls und Monitoring. Backups liegen auf einem NAS im Serverraum, auf einem externen Speicher beim Hosting-Provider oder in einem S3-Bucket. Nicht immer mit denselben Sicherheitsmaßnahmen wie das Produktivsystem.

Sie werden seltener überwacht. Zugriffe auf das Produktivsystem werden protokolliert und oft in Echtzeit überwacht. Zugriffe auf den Backup-Storage werden in vielen Unternehmen nicht oder nur rudimentär geloggt.

Sie werden lange aufbewahrt. Backup-Richtlinien sehen oft Aufbewahrungsfristen von 30, 90 oder sogar 365 Tagen vor. Das bedeutet: Wenn ein Backup kompromittiert wird, das vor sechs Monaten erstellt wurde, hat der Angreifer den Datenbestand von vor sechs Monaten, inklusive aller damals dokumentierten Schwachstellen.

Verschlüsselung auf Backup-Ebene implementieren

Jedes Backup muss vor der Speicherung verschlüsselt werden. Nicht auf dem Speichermedium (das wäre wieder nur Festplattenverschlüsselung), sondern als Teil des Backup-Prozesses selbst. Der Backup-Client verschlüsselt die Daten, bevor er sie an den Backup-Storage überträgt. So sind die Daten sowohl während der Übertragung als auch auf dem Speichermedium verschlüsselt.

Die gängigen Backup-Tools unterstützen das:

restic verschlüsselt standardmäßig, du kannst es nicht einmal abschalten. Das ist die richtige Designentscheidung: Verschlüsselung muss der Default sein, nicht die Option. Für ISMS-Backups ist restic daher eine gute Wahl.

Der Schlüssel darf nicht beim Backup liegen

Ein häufiger Fehler: Das Backup-Passwort oder der Verschlüsselungsschlüssel liegt in einer Konfigurationsdatei auf demselben Server, der auch die Backups erstellt. Wenn ein Angreifer diesen Server kompromittiert, hat er sowohl die verschlüsselten Backups als auch den Schlüssel. Die Verschlüsselung ist dann wertlos.

Der Schlüssel muss getrennt vom Backup aufbewahrt werden. Optionen dafür:

• Secrets Manager wie HashiCorp Vault, der den Schlüssel zur Laufzeit bereitstellt, ohne ihn auf der Festplatte zu speichern
• Key Management Service (KMS) des Cloud-Providers, wenn die Backups in der Cloud liegen
• Offline-Speicherung des Master-Keys in einem physischen Safe, kombiniert mit einem automatisierten Mechanismus, der Arbeitsschlüssel ableitet
• HSM (Hardware Security Module) für Unternehmen mit besonders hohen Anforderungen

Für einen MSP, der ISMS-Instanzen für Kunden betreibt, ist die pragmatischste Lösung ein zentraler Secrets Manager, der die Backup-Schlüssel aller Kundeninstanzen verwaltet. So sind die Schlüssel von den Backup-Daten getrennt und zentral administrierbar.

Schlüsselmanagement bei Self-Hosted: Du hast den Schlüssel

Die wichtigste Frage bei jeder Verschlüsselung ist nicht der Algorithmus. AES-256 ist sicher, das steht nicht zur Debatte. Die wichtigste Frage ist: Wer hat den Schlüssel?

Das Schlüsselmanagement-Problem bei SaaS

Bei einer SaaS-Lösung verwaltet der Anbieter die Verschlüsselungsschlüssel. Das ist technisch oft die einzige praktikable Lösung, weil der Anbieter die Daten entschlüsseln muss, um die Applikation auszuliefern. Auch wenn der Anbieter wirbt, dass alle Daten "verschlüsselt gespeichert" werden, hat er in der Regel Zugriff auf die Schlüssel und damit auf die Daten im Klartext.

Einige SaaS-Anbieter bieten "Bring Your Own Key" (BYOK) an: Du lieferst den Verschlüsselungsschlüssel, der Anbieter nutzt ihn für die Verschlüsselung. Das klingt gut, hat aber einen grundsätzlichen Haken: Sobald der Anbieter den Schlüssel verwendet, liegt er zumindest temporär im Arbeitsspeicher seiner Server. Ein Angreifer, der den SaaS-Server kompromittiert, kann den Schlüssel dort abgreifen. BYOK verschiebt das Vertrauen, es eliminiert es nicht.

Andere Anbieter nutzen einen Key Management Service (KMS) eines Cloud-Providers (AWS KMS, Azure Key Vault, Google Cloud KMS). Das ist besser als ein lokaler Schlüssel auf dem Applikationsserver, aber es bedeutet, dass der Cloud-Provider den Master Key hat. Für die Frage "Wer kann meine ISMS-Daten lesen?" bedeutet das: der SaaS-Anbieter kann es, weil er die Applikation betreibt. Der Cloud-Provider kann es theoretisch, weil er den KMS betreibt.

Self-Hosted: Volle Kontrolle über den Schlüssel

Bei einer Self-Hosted-Lösung behältst du den Verschlüsselungsschlüssel. Er liegt auf deiner Infrastruktur, unter deiner Kontrolle. Kein Dritter hat Zugriff darauf, weder der Softwareanbieter noch ein Cloud-Provider.

In ISMS Lite wird der Verschlüsselungsschlüssel beim initialen Setup generiert und in einer Konfigurationsdatei auf dem Server gespeichert. Du kannst ihn in einen Secrets Manager verschieben, auf ein HSM auslagern oder jede andere Schlüsselverwaltung implementieren, die zu deiner Infrastruktur passt. Die Software greift auf den Schlüssel über eine konfigurierbare Schnittstelle zu und schreibt nicht vor, wo oder wie du ihn speicherst.

Für einen MSP, der Kundeninstanzen betreibt, ergibt sich daraus ein klares Modell: Jede Kundeninstanz hat ihren eigenen Verschlüsselungsschlüssel. Wenn Instanz A kompromittiert wird, sind die Daten von Instanz B nicht betroffen, weil ein anderer Schlüssel zum Einsatz kommt. Das ist das Isolationsprinzip, angewendet auf die Kryptografie.

Schlüsselrotation

Verschlüsselungsschlüssel sollten regelmäßig rotiert werden. Die BSI TR-02102-1 gibt keine feste Frist vor, aber empfiehlt, die Nutzungsdauer kryptografischer Schlüssel zu begrenzen. In der Praxis hat sich eine jährliche Rotation für Datenbankschlüssel etabliert.

Bei einer Schlüsselrotation wird ein neuer Schlüssel erzeugt, und die Daten werden mit dem neuen Schlüssel neu verschlüsselt. Das ist bei feldbasierter Verschlüsselung aufwändiger als bei TDE, weil jedes verschlüsselte Feld einzeln re-encrypted werden muss. Der Prozess lässt sich aber automatisieren und im Hintergrund ausführen, ohne den laufenden Betrieb zu unterbrechen.

Was passiert mit dem alten Schlüssel? Er muss aufbewahrt werden, solange Backups existieren, die mit ihm verschlüsselt wurden. Wenn du Backups 90 Tage aufbewahrst, muss der alte Schlüssel mindestens 90 Tage nach der Rotation noch verfügbar sein. Dokumentiere den Lebenszyklus deiner Schlüssel in der Kryptografie-Richtlinie.

Vergleich: Wer hat den Schlüssel bei SaaS vs. Self-Hosted?

Die folgende Tabelle fasst zusammen, wie sich die Verschlüsselungsmodelle unterscheiden:

Die zentrale Erkenntnis: Bei SaaS hast du verschlüsselte Daten, aber nicht die exklusive Kontrolle über den Schlüssel. Bei Self-Hosted hast du beides. Für den Auditor ist die Frage "Wer kann Ihre ISMS-Daten entschlüsseln?" bei Self-Hosted eindeutig zu beantworten: nur du selbst.

Was das für die DSGVO bedeutet

Die DSGVO erwähnt Verschlüsselung in Artikel 32 als geeignete technische Maßnahme. Noch relevanter ist Artikel 34 Absatz 3a: Wenn bei einem Datenleck die betroffenen Daten verschlüsselt waren und der Schlüssel nicht kompromittiert wurde, kann unter Umständen auf die Benachrichtigung der Betroffenen verzichtet werden. Das setzt voraus, dass die Verschlüsselung wirksam war, der Schlüssel sicher ist und beides nachgewiesen werden kann.

Bei Self-Hosted ist dieser Nachweis einfacher, weil du den Schlüssel kontrollierst und belegen kannst, dass er nicht kompromittiert wurde. Bei SaaS musst du dich auf die Aussagen des Anbieters verlassen, was den Nachweis gegenüber der Aufsichtsbehörde komplexer macht.

Was das für NIS2 bedeutet

NIS2 fordert in Artikel 21 Absatz 2h "Konzepte für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung". Das umfasst nicht nur die Frage, ob verschlüsselt wird, sondern auch wie und mit welchen Schlüsseln. Unternehmen müssen nachweisen können, dass ihre Verschlüsselungsstrategie den aktuellen Standards entspricht und dass das Schlüsselmanagement angemessen ist.

Für ein Unternehmen, das sein ISMS self-hosted betreibt, ist die Dokumentation der eigenen Verschlüsselungsstrategie ein direkter Compliance-Nachweis. Für ein Unternehmen, das ein SaaS-ISMS nutzt, ist es ein Verweis auf die Dokumentation des Anbieters, über die es keine direkte Kontrolle hat.

Checkliste: Verschlüsselung für ISMS-Daten

At Rest

• Festplattenverschlüsselung auf dem ISMS-Server aktiv (LUKS, BitLocker)
• Feldbasierte Verschlüsselung für sensible Datenbankfelder (AES-256-GCM)
• Verschlüsselungsschlüssel getrennt von der Datenbank gespeichert
• Schlüsselrotation dokumentiert und geplant (mindestens jährlich)
• Alte Schlüssel aufbewahrt für die Dauer der Backup-Retention

In Transit

• TLS 1.3 für das Webinterface konfiguriert
• TLS 1.0 und 1.1 deaktiviert
• API-Verbindungen ausschließlich über HTTPS
• Datenbankverbindung verschlüsselt (wenn Applikation und DB auf verschiedenen Hosts)
• Backup-Transfers verschlüsselt (SSH, TLS)
• HSTS-Header gesetzt für alle Webinterfaces

Backup

• Backup-Verschlüsselung aktiviert (AES-256)
• Backup-Schlüssel getrennt von Backup-Storage gespeichert
• Restore-Test mit verschlüsseltem Backup durchgeführt
• Backup-Aufbewahrungsfristen definiert und dokumentiert
• Alte Backups werden nach Ablauf der Retention sicher gelöscht

Schlüsselmanagement

• Alle Verschlüsselungsschlüssel inventarisiert
• Schlüssel-Lifecycle dokumentiert (Erzeugung, Rotation, Archivierung, Vernichtung)
• Notfallprozess für Schlüsselverlust definiert
• Zugriff auf Schlüssel auf benannte Personen beschränkt
• Kryptografie-Richtlinie erstellt und freigegeben

Häufige Fehler bei der Verschlüsselung von ISMS-Daten

Verschlüsselung nur auf einer Ebene. TLS für den Browser, aber unverschlüsselte Datenbankfelder und unverschlüsselte Backups. Oder verschlüsselte Datenbank, aber Backups im Klartext. Verschlüsselung wirkt nur, wenn sie konsistent über alle Ebenen implementiert ist. Die schwächste Ebene bestimmt das Gesamtschutzniveau.

Schlüssel im Quellcode oder in der Konfigurationsdatei neben der Datenbank. Wenn der Verschlüsselungsschlüssel im selben Verzeichnis liegt wie die Datenbank, bietet er keinen zusätzlichen Schutz gegen einen Angreifer, der Zugriff auf das Dateisystem hat. Der Schlüssel muss physisch oder logisch von den verschlüsselten Daten getrennt sein.

Kein Restore-Test. Verschlüsselung macht Backups komplexer. Wenn du den Schlüssel verlierst oder der Entschlüsselungsprozess einen Fehler hat, sind deine Backups wertlos. Teste regelmäßig, ob du ein verschlüsseltes Backup tatsächlich wiederherstellen kannst. Die Bare-Metal-Recovery sollte Teil deines Testplans sein.

Veraltete Algorithmen. 3DES, RC4, SHA-1 haben in einer aktuellen Verschlüsselungsstrategie nichts mehr verloren. Prüfe regelmäßig, ob die eingesetzten Algorithmen und Schlüssellängen den aktuellen BSI-Empfehlungen entsprechen.

Verschlüsselung ohne Dokumentation. Wenn du nicht dokumentiert hast, welche Daten wie verschlüsselt sind, welche Algorithmen und Schlüssellängen du einsetzt und wie das Schlüsselmanagement organisiert ist, kannst du im Audit nicht nachweisen, dass die Verschlüsselung den Anforderungen entspricht. Die Kryptografie-Richtlinie ist nicht optional.

Fazit: Verschlüsselung ist eine Architekturentscheidung, keine Feature-Checkbox

Die Verschlüsselung von ISMS-Daten ist mehr als ein technisches Feature, das man aktiviert und dann abhakt. Sie ist eine Architekturentscheidung, die bestimmt, wer tatsächlich Zugriff auf die Sicherheitsdokumentation deines Unternehmens hat.

AES-256-GCM auf Feldebene, TLS 1.3 für alle Verbindungen und verschlüsselte Backups bilden zusammen eine konsistente Schutzschicht. Aber die Verschlüsselung ist nur so gut wie das Schlüsselmanagement dahinter. Und beim Schlüsselmanagement zeigt sich der fundamentale Unterschied zwischen SaaS und Self-Hosted: Bei SaaS hat der Anbieter den Schlüssel. Bei Self-Hosted hast du ihn. Für Daten, die dokumentieren, wo dein Unternehmen verwundbar ist, sollte die Antwort auf die Frage "Wer kann diese Daten lesen?" genau eine Person umfassen: du.

Weiterführende Artikel

• Verschlüsselung im Unternehmen: Was, wo und wie verschlüsseln
• Kryptografie-Richtlinie erstellen: Algorithmen, Schlüssellängen und Lifecycle
• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• Secrets Management: Passwörter, API-Keys und Zertifikate sicher verwalten
• Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen