Verschlüsselung im Unternehmen: Was, wo und wie verschlüsseln

Warum Verschlüsselung kein optionales Feature mehr ist

Verschlüsselung ist eines dieser Themen, bei denen die meisten IT-Verantwortlichen nicken und sagen: Ja, machen wir. HTTPS ist aktiviert, die Festplatten sind verschlüsselt, alles gut. Und in vielen Fällen stimmt das auch, zumindest oberflächlich. Aber wenn ein Auditor oder eine Aufsichtsbehörde genauer nachfragt, wie die Verschlüsselungsstrategie aussieht, welche Algorithmen und Schlüssellängen eingesetzt werden, wie das Schlüsselmanagement organisiert ist und ob es eine dokumentierte Kryptografie-Richtlinie gibt, wird es in den meisten mittelständischen Unternehmen dünn.

NIS2 hat das Thema von einer Best Practice zu einer gesetzlichen Pflicht erhoben. Artikel 21 Absatz 2 listet zehn Mindestmaßnahmen auf, die betroffene Unternehmen umsetzen müssen. Buchstabe h nennt explizit Konzepte für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung. Das bedeutet: Du musst nicht nur verschlüsseln, sondern dokumentieren, was du verschlüsselst, warum du es verschlüsselst und nach welchen Standards du das tust.

ISO 27001 adressiert Verschlüsselung in Annex A.8.24 (Einsatz von Kryptografie). Die Norm fordert, dass Regeln für den wirksamen Einsatz von Kryptografie, einschließlich des Managements kryptografischer Schlüssel, definiert und umgesetzt werden. Das betrifft sowohl die Auswahl der Algorithmen als auch den gesamten Lebenszyklus der Schlüssel: Erzeugung, Verteilung, Speicherung, Nutzung, Archivierung, Rückruf und Vernichtung.

Die DSGVO erwähnt Verschlüsselung in Artikel 32 als geeignete technische Maßnahme zur Sicherung personenbezogener Daten. Wer verschlüsselt und im Falle einer Datenpanne nachweisen kann, dass die betroffenen Daten verschlüsselt waren, kann unter Umständen sogar auf die Benachrichtigung der Betroffenen verzichten (Artikel 34 Absatz 3a). Das macht Verschlüsselung nicht nur zu einer Sicherheitsmaßnahme, sondern zu einem handfesten wirtschaftlichen Vorteil im Ernstfall.

Dieser Artikel bringt Ordnung in das Thema. Was muss verschlüsselt werden? Welche Algorithmen und Schlüssellängen sind aktuell sicher? Wie organisierst du das Schlüsselmanagement? Und wie sieht eine praxistaugliche Kryptografie-Richtlinie aus?

Die drei Zustände von Daten

Um systematisch über Verschlüsselung nachzudenken, hilft die Unterscheidung der drei Zustände, in denen Daten existieren können. Jeder Zustand hat eigene Risiken und erfordert eigene Schutzmaßnahmen.

Data at Rest: Daten in Ruhe

Data at Rest sind Daten, die auf einem Speichermedium liegen und gerade nicht aktiv verarbeitet oder übertragen werden. Festplatten, SSDs, USB-Sticks, Backup-Bänder, Datenbanken, Dateiserver, Cloud-Speicher. Immer wenn Daten irgendwo gespeichert sind, sind sie Data at Rest.

Das Risiko: Wenn jemand physischen Zugriff auf das Speichermedium erlangt, ob durch Diebstahl eines Laptops, Einbruch ins Rechenzentrum oder unbefugten Zugang zu einem Backup-Band, kann er die Daten lesen. Ohne Verschlüsselung reicht es, die Festplatte auszubauen und an einen anderen Rechner anzuschließen. Keine Zugangskontrolle der Welt hilft, wenn der Angreifer das physische Medium in der Hand hält.

Data in Transit: Daten in Bewegung

Data in Transit sind Daten, die gerade übertragen werden. Netzwerkverkehr zwischen Client und Server, E-Mails auf dem Weg zum Empfänger, Dateitransfers per FTP oder SFTP, API-Aufrufe zwischen Systemen. Immer wenn Daten von A nach B fließen, sind sie Data in Transit.

Das Risiko: Netzwerkverkehr kann abgefangen und mitgelesen werden. In lokalen Netzwerken durch ARP-Spoofing, in WLANs durch das Mitlesen des Funkverkehrs, im Internet durch Man-in-the-Middle-Angriffe auf unsichere Verbindungen. Ohne Verschlüsselung ist der Netzwerkverkehr Klartext, den jeder lesen kann, der Zugang zum Übertragungsweg hat.

Data in Use: Daten in Verarbeitung

Data in Use sind Daten, die gerade aktiv verarbeitet werden. Das bedeutet: Sie liegen im Arbeitsspeicher (RAM), in CPU-Caches oder in Registern. In diesem Zustand sind sie in aller Regel unverschlüsselt, weil die CPU mit verschlüsselten Daten nicht rechnen kann.

Das Risiko: Angriffe auf Data in Use sind technisch anspruchsvoll, aber möglich. Cold Boot Attacks extrahieren Daten aus dem RAM, indem der Speicher gekühlt und ausgelesen wird. Seitenkanalangriffe wie Spectre und Meltdown lesen Daten aus CPU-Caches. Memory Scraping Malware durchsucht den Arbeitsspeicher nach sensiblen Informationen wie Kreditkartendaten oder Schlüsselmaterial.

Für den Mittelstand ist Data in Use der am schwierigsten zu schützende Bereich, und gleichzeitig der mit dem geringsten praktischen Risiko. Confidential Computing, also die Verschlüsselung von Daten auch während der Verarbeitung mittels Technologien wie Intel SGX oder AMD SEV, steckt noch in den Kinderschuhen und ist für die meisten KMU-Szenarien weder verfügbar noch notwendig. Konzentriere dich auf Data at Rest und Data in Transit, dort liegt der Großteil des Risikos und des Handlungsbedarfs.

Data at Rest verschlüsseln

Festplattenverschlüsselung (Full Disk Encryption)

Festplattenverschlüsselung ist die grundlegendste Form der Verschlüsselung und gleichzeitig die mit dem besten Aufwand-Nutzen-Verhältnis. Die gesamte Festplatte wird verschlüsselt, sodass ohne den richtigen Schlüssel (der an die Anmeldung des Benutzers oder einen TPM-Chip gekoppelt ist) kein Zugriff auf die Daten möglich ist.

Windows: BitLocker. BitLocker ist in Windows Pro und Enterprise enthalten und lässt sich über Gruppenrichtlinien oder Intune zentral aktivieren. Der Verschlüsselungsschlüssel wird im TPM-Chip des Geräts gespeichert, der Recovery-Key muss zentral im Active Directory oder in Entra ID hinterlegt werden. Verwende AES-256 als Algorithmus, das ist über die Gruppenrichtlinie konfigurierbar. BitLocker verschlüsselt die gesamte Festplatte einschließlich des Betriebssystems und ist für den Benutzer transparent, er merkt von der Verschlüsselung im Alltag nichts.

macOS: FileVault. FileVault 2 ist in macOS integriert und verschlüsselt die Systempartition mit XTS-AES-128. Die Recovery-Keys können über ein MDM wie JAMF oder Intune zentral verwaltet werden. Die Aktivierung über ein Konfigurationsprofil ist unkompliziert.

Linux: LUKS. Linux Unified Key Setup ist der Standard für Festplattenverschlüsselung unter Linux. Es wird üblicherweise bei der Installation eingerichtet und verschlüsselt die Root-Partition mit AES-256 im XTS-Modus. Die zentrale Verwaltung von Recovery-Keys ist bei Linux aufwändiger als bei Windows oder macOS und erfordert eigene Tooling- oder Konfigurationsmanagement-Lösungen.

Server und Speichersysteme. Auch Serverfestplatten sollten verschlüsselt sein, besonders wenn sie sich nicht in einem physisch gesicherten Rechenzentrum befinden. Viele Storage-Systeme und RAID-Controller bieten Self-Encrypting Drives (SEDs) an, bei denen die Verschlüsselung auf der Firmware-Ebene der Festplatte stattfindet und keinen Performance-Overhead erzeugt.

Datenbankverschlüsselung

Festplattenverschlüsselung schützt vor physischem Diebstahl des Speichermediums. Was sie nicht schützt: Daten, auf die über das Betriebssystem oder die Anwendung zugegriffen wird. Ein Angreifer, der sich auf dem Server anmeldet (etwa über kompromittierte Credentials), kann die Datenbank normal abfragen, obwohl die Festplatte verschlüsselt ist, weil das Betriebssystem die Entschlüsselung transparent durchführt.

Für sensible Daten in Datenbanken gibt es deshalb eine zweite Verschlüsselungsebene:

Transparent Data Encryption (TDE) verschlüsselt die Datenbankdateien auf der Festplatte, sodass ein Angreifer, der die Datenbankdateien kopiert, ohne den Datenbankschlüssel nichts damit anfangen kann. SQL Server, PostgreSQL und MySQL bieten TDE nativ an. TDE ist transparent für die Anwendung, es muss kein Code geändert werden.

Column-Level Encryption verschlüsselt einzelne Spalten in einer Tabelle, zum Beispiel Kreditkartennummern, Sozialversicherungsnummern oder Gesundheitsdaten. Das bietet einen feineren Schutz als TDE, erfordert aber Anpassungen in der Anwendung, weil die Entschlüsselung explizit durchgeführt werden muss.

Für die meisten mittelständischen Unternehmen reicht die Kombination aus Festplattenverschlüsselung und TDE aus. Column-Level Encryption ist dann sinnvoll, wenn einzelne Felder besonders schützenswerte Daten enthalten und auch innerhalb der Anwendung vor bestimmten Rollen geschützt werden müssen.

Backup-Verschlüsselung

Backups sind eine der am häufigsten übersehenen Schwachstellen. Das Produktivsystem ist verschlüsselt, die Zugriffsrechte sind sauber konfiguriert, aber die Backups liegen unverschlüsselt auf einem NAS oder bei einem Cloud-Anbieter. Ein Angreifer, der an die Backups kommt, hat den gesamten Datenbestand, oft inklusive historischer Daten, die auf dem Produktivsystem längst gelöscht wurden. Das gilt besonders für ISMS-Daten, die eine detaillierte Sicherheitslandkarte deines Unternehmens darstellen und daher eine durchgängige Verschlüsselung at Rest, in Transit und im Backup erfordern.

Jedes Backup muss verschlüsselt sein. Die gängigen Backup-Lösungen (Veeam, Acronis, Duplicati, restic, BorgBackup) unterstützen Verschlüsselung nativ. Verwende AES-256 und speichere den Verschlüsselungsschlüssel getrennt vom Backup. Wenn der Schlüssel auf dem gleichen System liegt wie das Backup, kann ein Angreifer beides zusammen erlangen, und die Verschlüsselung ist wertlos.

Ein besonderer Punkt: Teste regelmäßig, ob du deine verschlüsselten Backups auch tatsächlich wiederherstellen kannst. Ein verschlüsseltes Backup, für das du den Schlüssel verloren hast, ist schlimmer als kein Backup, weil du denkst, du hättest eines.

Cloud-Verschlüsselung

Bei Cloud-Diensten gibt es drei Ebenen der Verschlüsselung:

Encryption at Rest durch den Cloud-Anbieter. AWS, Azure und Google Cloud verschlüsseln standardmäßig alle gespeicherten Daten. Das schützt vor physischem Diebstahl der Hardware im Rechenzentrum, aber nicht vor dem Cloud-Anbieter selbst oder vor einem Angreifer, der deine Cloud-Credentials kompromittiert hat.

Customer-Managed Keys. Du generierst und verwaltest den Verschlüsselungsschlüssel selbst, der Cloud-Anbieter nutzt ihn für die Verschlüsselung. Wenn du den Schlüssel löschst oder widerrufst, sind die Daten auch für den Anbieter nicht mehr lesbar. Das gibt dir mehr Kontrolle, erfordert aber ein sauberes Key Management.

Client-Side Encryption. Die Daten werden vor dem Upload in die Cloud auf deinem Endgerät verschlüsselt. Der Cloud-Anbieter sieht nur verschlüsselte Daten und hat keinen Zugriff auf die Schlüssel. Das ist die sicherste Variante, aber auch die aufwändigste, weil du die Verschlüsselung in deine Anwendungen und Prozesse integrieren musst.

Für den Mittelstand ist die Empfehlung: Nutze mindestens die Standard-Encryption des Cloud-Anbieters (die ist meistens automatisch aktiv). Für besonders sensible Daten solltest du Customer-Managed Keys einsetzen. Client-Side Encryption ist für spezifische Anwendungsfälle sinnvoll, zum Beispiel für den Austausch vertraulicher Dokumente mit externen Partnern.

Data in Transit verschlüsseln

TLS: Der Standard für verschlüsselte Verbindungen

Transport Layer Security (TLS) ist das Fundament der verschlüsselten Kommunikation im Internet und im internen Netzwerk. Wenn du eine HTTPS-Webseite aufrufst, eine verschlüsselte Verbindung zu einem Mailserver aufbaust oder eine API über HTTPS ansprichst, nutzt du TLS.

Mindestversion: TLS 1.2. TLS 1.0 und 1.1 gelten seit 2020 als unsicher und sollten auf allen Systemen deaktiviert sein. Alle modernen Browser und Betriebssysteme unterstützen TLS 1.2 und 1.3. Es gibt keinen Grund mehr, ältere Versionen zu tolerieren.

Bevorzugt: TLS 1.3. TLS 1.3 ist schneller (weniger Roundtrips beim Verbindungsaufbau), sicherer (veraltete Cipher Suites wurden entfernt) und einfacher zu konfigurieren. Wenn deine Server und Clients TLS 1.3 unterstützen, solltest du es aktivieren und bevorzugen.

Cipher Suites auswählen. Nicht alle Verschlüsselungsverfahren, die TLS unterstützt, sind gleich sicher. Deaktiviere schwache Cipher Suites (alles mit RC4, DES, 3DES, MD5, SHA-1) und priorisiere starke Suites mit Forward Secrecy (ECDHE-basiert). Für TLS 1.2 sind ECDHE-RSA-AES256-GCM-SHA384 und ECDHE-ECDSA-AES256-GCM-SHA384 gute Standardkonfigurationen. TLS 1.3 vereinfacht das, weil nur noch sichere Suites zur Verfügung stehen.

Zertifikatsmanagement. TLS-Zertifikate haben ein Ablaufdatum. Wenn ein Zertifikat abläuft, funktioniert die verschlüsselte Verbindung nicht mehr, und die Nutzer sehen eine Sicherheitswarnung. Automatisiere die Zertifikatserneuerung mit Let's Encrypt und Certbot für öffentlich erreichbare Dienste. Für interne Dienste betreibe eine interne Certificate Authority (CA) oder nutze die Zertifikatsdienste deiner Firewall oder deines Reverse Proxy.

VPN-Verschlüsselung

VPN-Verbindungen verschlüsseln den Datenverkehr zwischen dem Endgerät und dem Firmennetz. Die Verschlüsselung findet auf einer niedrigeren Ebene statt als TLS und schützt damit auch Protokolle, die selbst keine Verschlüsselung mitbringen (zum Beispiel SMB-Dateifreigaben oder ältere Anwendungsprotokolle).

Die empfohlenen VPN-Protokolle und ihre Verschlüsselung: WireGuard nutzt ChaCha20 für die Verschlüsselung und Poly1305 für die Authentifizierung, eine moderne und schnelle Kombination. OpenVPN sollte mit AES-256-GCM oder ChaCha20-Poly1305 konfiguriert werden. IKEv2/IPsec sollte AES-256 mit SHA-256 oder SHA-384 verwenden.

E-Mail-Verschlüsselung

E-Mail ist eines der unsichersten Kommunikationsmedien. Standardmäßig werden E-Mails im Klartext übertragen, und selbst wenn der Transport zwischen den Mailservern verschlüsselt ist (STARTTLS), liegt die E-Mail auf den Mailservern selbst unverschlüsselt vor.

Es gibt zwei Ansätze für E-Mail-Verschlüsselung:

Transportverschlüsselung (STARTTLS/TLS). Die Verbindung zwischen den Mailservern wird verschlüsselt. Das schützt vor dem Mitlesen auf dem Transportweg, aber nicht auf den Mailservern selbst. Stelle sicher, dass dein Mailserver STARTTLS erzwingt und keine unverschlüsselten Verbindungen akzeptiert. MTA-STS (Mail Transfer Agent Strict Transport Security) bietet zusätzlichen Schutz gegen Downgrade-Angriffe.

Ende-zu-Ende-Verschlüsselung (S/MIME oder PGP). Die E-Mail wird auf dem Endgerät des Absenders verschlüsselt und erst auf dem Endgerät des Empfängers entschlüsselt. Kein Mailserver auf dem Weg kann den Inhalt lesen. S/MIME nutzt X.509-Zertifikate und ist in Outlook und Apple Mail nativ integriert. PGP/GPG nutzt ein Web of Trust und ist technisch flexibler, aber schwieriger zu bedienen.

Die ehrliche Einschätzung: Ende-zu-Ende-Verschlüsselung von E-Mails ist für den Mittelstand im Alltag kaum praktikabel. Die Schlüsselverwaltung ist komplex, die Benutzerfreundlichkeit ist schlecht, und beide Seiten müssen die gleiche Technologie nutzen. Für die reguläre Geschäftskommunikation ist Transportverschlüsselung plus ein sicherer Messaging-Dienst (zum Beispiel Microsoft Teams oder Signal für besonders vertrauliche Kommunikation) oft die bessere Lösung. S/MIME lohnt sich für definierte Kommunikationswege, zum Beispiel den Austausch vertraulicher Dokumente mit einem Steuerberater oder einer Behörde.

Algorithmen und Schlüssellängen: Was ist aktuell sicher?

Die Auswahl der richtigen Algorithmen und Schlüssellängen ist ein Thema, das schnell technisch wird. Für die Praxis im Unternehmen brauchst du aber keine Kryptografie-Vorlesung, sondern klare Vorgaben, was du einsetzen sollst und was nicht.

Symmetrische Verschlüsselung

Bei symmetrischer Verschlüsselung verwenden Sender und Empfänger den gleichen Schlüssel. Das ist schnell und effizient und wird für die Verschlüsselung großer Datenmengen verwendet (Festplatten, Datenbanken, VPN-Tunnel).

Empfohlen: AES-256. Der Advanced Encryption Standard mit 256-Bit-Schlüsseln ist der weltweite Standard. Er wird von NIST, BSI und allen relevanten Sicherheitsbehörden empfohlen und ist in absehbarer Zukunft nicht durch Brute-Force-Angriffe zu brechen, auch nicht durch Quantencomputer.

Akzeptabel: AES-128. AES mit 128-Bit-Schlüsseln ist ebenfalls sicher und bietet eine bessere Performance. Für die meisten Anwendungsfälle ist der Unterschied zwischen AES-128 und AES-256 akademisch, beide sind sicher. Wenn du die Wahl hast, nimm AES-256, aber verliere keine Schlafnacht über AES-128.

Akzeptabel: ChaCha20. Eine Alternative zu AES, die besonders auf Geräten ohne Hardware-AES-Beschleunigung schneller ist. Wird von WireGuard und modernen TLS-Implementierungen verwendet.

Verboten: DES, 3DES, RC4, Blowfish. Diese Algorithmen sind veraltet und gelten als unsicher. Wenn du sie noch in deiner Infrastruktur findest, tausche sie aus.

Asymmetrische Verschlüsselung

Bei asymmetrischer Verschlüsselung gibt es ein Schlüsselpaar: einen öffentlichen Schlüssel zum Verschlüsseln und einen privaten Schlüssel zum Entschlüsseln. Das wird für den Schlüsselaustausch, digitale Signaturen und Zertifikate verwendet.

Empfohlen: RSA mit mindestens 2048 Bit. RSA 2048 ist der aktuelle Mindeststandard. RSA 4096 bietet mehr Sicherheitsreserve, ist aber langsamer. Für Zertifikate, die mehrere Jahre gültig sind, empfiehlt das BSI mindestens RSA 3072 oder RSA 4096.

Empfohlen: Elliptic Curve Cryptography (ECC). ECDSA und ECDH bieten das gleiche Sicherheitsniveau wie RSA mit deutlich kürzeren Schlüsseln. Ein ECDSA-Schlüssel mit 256 Bit entspricht in etwa RSA 3072. ECC ist schneller und effizienter und wird zunehmend zum Standard, besonders in TLS 1.3.

Verboten: RSA mit weniger als 2048 Bit. RSA 1024 gilt seit Jahren als unsicher. RSA 512 kann in wenigen Stunden gebrochen werden.

Hash-Funktionen

Hash-Funktionen erzeugen aus Daten einen Fingerabdruck fester Länge. Sie werden für Passwort-Hashing, digitale Signaturen und Integritätsprüfungen verwendet.

Empfohlen: SHA-256, SHA-384, SHA-512 (SHA-2-Familie). SHA-2 ist der aktuelle Standard und sicher.

Empfohlen: SHA-3. Die neueste Generation der SHA-Familie, basierend auf einem völlig anderen Algorithmus (Keccak). SHA-3 ist eine gute Wahl, wenn du zukunftssicher sein willst, aber SHA-2 ist für die absehbare Zukunft ebenfalls sicher.

Für Passwörter: bcrypt, scrypt oder Argon2. Passwörter dürfen niemals mit SHA-256 oder ähnlichen schnellen Hash-Funktionen gehasht werden. Für Passwort-Hashing brauchst du absichtlich langsame Algorithmen wie bcrypt, scrypt oder Argon2, die Brute-Force-Angriffe erschweren.

Verboten: MD5, SHA-1. Beide gelten als gebrochen und dürfen nicht mehr für sicherheitsrelevante Zwecke eingesetzt werden. MD5-Kollisionen können in Sekunden erzeugt werden, SHA-1-Kollisionen in Stunden bis Tagen.

Key Management: Das eigentliche Kernproblem

Verschlüsselung ist nur so sicher wie das Schlüsselmanagement. Der beste Algorithmus mit der längsten Schlüssellänge hilft nichts, wenn der Schlüssel auf einem Post-it am Monitor klebt, im Klartext in einer Konfigurationsdatei steht oder über Jahre nicht rotiert wird.

Schlüsselerzeugung

Schlüssel müssen mit einem kryptografisch sicheren Zufallsgenerator erzeugt werden. Das klingt selbstverständlich, ist es aber nicht immer. Anwendungen, die eigene Verschlüsselung implementieren und dabei einen schwachen Zufallsgenerator verwenden, erzeugen Schlüssel, die vorhersagbar sind. Nutze für die Schlüsselerzeugung immer die kryptografischen Bibliotheken des Betriebssystems oder etablierte Bibliotheken wie OpenSSL, libsodium oder die Kryptografie-APIs des Frameworks.

Schlüsselspeicherung

Schlüssel dürfen nicht im Klartext gespeichert werden, nicht in Konfigurationsdateien, nicht in Datenbanken, nicht in Code-Repositories. Auch dann nicht, wenn die Zugriffsrechte restriktiv sind.

Für den Mittelstand gibt es mehrere Optionen:

Hardware Security Module (HSM). HSMs sind dedizierte Hardware-Geräte, die Schlüssel erzeugen, speichern und kryptografische Operationen durchführen, ohne dass der Schlüssel das Gerät jemals verlässt. HSMs bieten das höchste Sicherheitsniveau, sind aber teuer (mehrere Tausend Euro pro Gerät). Für die meisten KMU ist ein physisches HSM Overkill.

Cloud-basierte Key Management Services. AWS KMS, Azure Key Vault und Google Cloud KMS bieten HSM-basierte Schlüsselspeicherung als Cloud-Dienst an. Die Kosten sind gering (wenige Euro pro Monat pro Schlüssel), und die Integration in Cloud-Anwendungen ist einfach. Für Unternehmen, die Cloud-Dienste nutzen, ist das die pragmatischste Lösung.

TPM-Chip. Der Trusted Platform Module Chip in modernen Laptops und Desktops speichert den BitLocker-Schlüssel und andere Schlüssel in einem gegen physische Angriffe geschützten Bereich. Für Endgeräte ist der TPM die Standard-Lösung.

Passwort-Manager und Secrets-Management. Für API-Schlüssel, Datenbank-Passwörter und ähnliche Geheimnisse, die von Anwendungen benötigt werden, gibt es Secrets-Management-Tools wie HashiCorp Vault, Bitwarden Secrets Manager oder die Secrets-Funktionen von CI/CD-Plattformen. Diese Tools speichern Geheimnisse verschlüsselt und stellen sie den Anwendungen über APIs zur Verfügung.

Schlüsselrotation

Schlüssel haben eine begrenzte Lebensdauer. Je länger ein Schlüssel verwendet wird, desto größer ist das Risiko, dass er kompromittiert wird, sei es durch einen Sicherheitsvorfall, durch eine Schwachstelle im System oder schlicht durch die Wahrscheinlichkeitsrechnung.

Definiere Rotationsintervalle für verschiedene Schlüsseltypen: TLS-Zertifikate alle 90 Tage (Let's Encrypt macht das automatisch), API-Schlüssel mindestens jährlich, Datenbank-Verschlüsselungsschlüssel alle 1-2 Jahre, Backup-Verschlüsselungsschlüssel bei jedem Wechsel des Verantwortlichen.

Schlüsselverlust und Recovery

Was passiert, wenn ein Schlüssel verloren geht? Bei Festplattenverschlüsselung bedeutet das: Die Daten sind unwiederbringlich verloren. Bei Backup-Verschlüsselung: Die Backups sind wertlos. Bei E-Mail-Verschlüsselung: Alle verschlüsselten E-Mails sind nicht mehr lesbar.

Deshalb brauchst du ein Recovery-Konzept: BitLocker-Recovery-Keys in Active Directory oder Entra ID speichern. Backup-Verschlüsselungsschlüssel an einem separaten, gesicherten Ort hinterlegen (nicht auf dem gleichen System wie die Backups). Für besonders kritische Schlüssel ein Key Escrow mit Vier-Augen-Prinzip einrichten, bei dem zwei Personen zusammenkommen müssen, um den Schlüssel zu rekonstruieren.

Praktische Umsetzung für KMU

Wie setzt du das alles in der Praxis um, ohne ein Kryptografie-Projekt mit sechsstelligem Budget zu starten? Die folgende Priorisierung hilft:

Sofort umsetzen (Woche 1-2)

Festplattenverschlüsselung auf allen Endgeräten. BitLocker auf Windows, FileVault auf macOS. Recovery-Keys zentral speichern. Über Gruppenrichtlinien oder MDM erzwingen, dass neue Geräte automatisch verschlüsselt werden. Bestehende Geräte in den nächsten zwei Wochen nachrüsten.

TLS-Konfiguration prüfen. Prüfe alle extern erreichbaren Dienste (Webserver, Mailserver, VPN-Gateway) auf ihre TLS-Konfiguration. Tools wie SSL Labs (ssllabs.com) oder testssl.sh machen das in Minuten. Deaktiviere TLS 1.0 und 1.1, deaktiviere schwache Cipher Suites, aktiviere TLS 1.3, wo möglich.

VPN-Verschlüsselung prüfen. Stelle sicher, dass dein VPN AES-256 oder ChaCha20 verwendet. Ersetze veraltete Protokolle (PPTP, L2TP ohne IPsec).

Kurzfristig umsetzen (Monat 1-2)

Backup-Verschlüsselung aktivieren. Aktiviere die Verschlüsselung in deiner Backup-Lösung. Speichere die Schlüssel getrennt von den Backups. Teste die Wiederherstellung eines verschlüsselten Backups.

Datenbankverschlüsselung evaluieren. Prüfe, ob deine Datenbanken sensible Daten enthalten, die über die Festplattenverschlüsselung hinaus geschützt werden müssen. Wenn ja, aktiviere TDE.

E-Mail-Transportverschlüsselung prüfen. Stelle sicher, dass dein Mailserver STARTTLS erzwingt. Konfiguriere MTA-STS, wenn dein Mailserver es unterstützt.

Mittelfristig umsetzen (Monat 3-6)

Kryptografie-Richtlinie erstellen. Dokumentiere die Verschlüsselungsstandards deines Unternehmens in einer formalen Richtlinie (mehr dazu im nächsten Abschnitt). In ISMS Lite lässt sich die Kryptografie-Richtlinie mit den zugehörigen Controls verknüpfen und der Umsetzungsstand jeder Verschlüsselungsmaßnahme nachverfolgen.

Key-Management-Prozess definieren. Dokumentiere, wer für welche Schlüssel verantwortlich ist, wo sie gespeichert werden, wann sie rotiert werden und was bei Verlust passiert.

Bestandsaufnahme der Verschlüsselung. Erstelle eine Übersicht aller Systeme und Datenflüsse und dokumentiere, welche Verschlüsselung jeweils eingesetzt wird. Identifiziere Lücken und priorisiere deren Schließung.

Die Kryptografie-Richtlinie

Eine Kryptografie-Richtlinie ist ein Pflichtdokument für jedes ISMS. Sie dokumentiert die Verschlüsselungsstandards des Unternehmens und gibt allen Beteiligten, vom Entwickler bis zum Administrator, klare Vorgaben, welche Verschlüsselung wo und wie eingesetzt werden muss.

Was in die Richtlinie gehört

Geltungsbereich. Für welche Systeme, Daten und Kommunikationswege gilt die Richtlinie?

Klassifizierung der Daten. Welche Daten müssen verschlüsselt werden? Die Richtlinie sollte an die Datenklassifizierung des Unternehmens anknüpfen: Alle vertraulichen und streng vertraulichen Daten müssen im Ruhezustand und bei der Übertragung verschlüsselt sein.

Zugelassene Algorithmen und Schlüssellängen. Eine klare Liste, was erlaubt und was verboten ist. Die Tabelle aus dem vorherigen Abschnitt ist ein guter Ausgangspunkt.

Verbotene Algorithmen. Explizit auflisten, was nicht mehr verwendet werden darf: DES, 3DES, RC4, MD5, SHA-1, RSA unter 2048 Bit, TLS unter Version 1.2.

Schlüsselmanagement. Regeln für Erzeugung, Speicherung, Rotation, Verteilung und Vernichtung von Schlüsseln. Wer ist verantwortlich? Wie werden Schlüssel gesichert? Was passiert bei Verlust?

Zertifikatsmanagement. Regeln für die Beschaffung, Erneuerung und Widerrufung von TLS-Zertifikaten. Wer ist für die Erneuerung verantwortlich? Wie wird sichergestellt, dass keine Zertifikate ablaufen?

Ausnahmen. Unter welchen Bedingungen darf von den Standards abgewichen werden? Wer genehmigt Ausnahmen? Wie werden sie dokumentiert?

Überprüfung. Wie oft wird die Richtlinie überprüft und aktualisiert? Mindestens jährlich, und zusätzlich bei relevanten Änderungen der Bedrohungslage oder der Empfehlungen des BSI.

Ein Wort zur Post-Quantum-Kryptografie

Die Entwicklung von Quantencomputern bedroht einen Teil der heute verwendeten kryptografischen Verfahren. Insbesondere asymmetrische Verfahren wie RSA und ECC sind theoretisch durch Quantencomputer brechbar (Shor's Algorithmus). Symmetrische Verfahren wie AES sind weniger betroffen, hier verdoppelt sich der Aufwand durch Grover's Algorithmus, was bei AES-256 immer noch ein Sicherheitsniveau von 128 Bit ergibt, also weiterhin sicher.

NIST hat 2024 die ersten Post-Quantum-Kryptografie-Standards veröffentlicht: ML-KEM (ehemals CRYSTALS-Kyber) für den Schlüsselaustausch und ML-DSA (ehemals CRYSTALS-Dilithium) für digitale Signaturen. TLS 1.3 unterstützt bereits hybride Verfahren, die klassische und Post-Quantum-Algorithmen kombinieren. Chrome und Firefox haben begonnen, diese hybriden Verfahren zu aktivieren.

Für den Mittelstand gilt: Du musst jetzt keine Post-Quantum-Migration starten. Was du aber tun solltest, ist das Thema in der Kryptografie-Richtlinie erwähnen und beim nächsten Review prüfen, ob deine Systeme die neuen Standards unterstützen. Die Migration wird in den nächsten Jahren schrittweise über Software- und Firmware-Updates kommen. Wenn deine Systeme aktuell gehalten werden, bist du auf der sicheren Seite.

Verschlüsselung im Audit

Wenn ein Auditor die Kryptografie-Controls prüft, wird er typischerweise folgende Fragen stellen: Gibt es eine dokumentierte Kryptografie-Richtlinie? Welche Algorithmen und Schlüssellängen sind definiert? Sind alle Endgeräte mit Festplattenverschlüsselung ausgestattet? Wie ist das Schlüsselmanagement organisiert? Gibt es ein Verfahren für den Schlüsselverlust? Sind die Backups verschlüsselt? Welche TLS-Version ist auf den externen Diensten konfiguriert?

Die Kryptografie-Richtlinie ist das zentrale Dokument, das du vorlegen kannst. Ergänzt wird sie durch technische Nachweise: BitLocker-Status-Berichte aus dem MDM, SSL-Labs-Scans der externen Dienste, Konfigurationsdokumentation der Backup-Verschlüsselung, Key-Management-Prozessdokumentation.

Auditoren prüfen auch, ob die Richtlinie gelebt wird. Eine Richtlinie, die AES-256 vorschreibt, aber auf den Servern findet sich noch 3DES in der TLS-Konfiguration, erzeugt eine Feststellung. Deshalb ist die Bestandsaufnahme der tatsächlich eingesetzten Verschlüsselung ein wichtiger Schritt, der vor dem Audit stattfinden sollte.

Verschlüsselung als Fundament der Informationssicherheit

Verschlüsselung ist kein einzelnes Projekt, das du einmal umsetzt und dann abhakst. Sie ist ein kontinuierlicher Prozess, der in das ISMS eingebettet sein muss. Algorithmen, die heute sicher sind, können morgen als gebrochen gelten. Schlüssel müssen rotiert, Zertifikate erneuert, neue Systeme in das Verschlüsselungskonzept einbezogen werden.

Aber der Einstieg ist machbar, auch für den Mittelstand. Festplattenverschlüsselung auf allen Geräten, TLS in aktueller Konfiguration auf allen Diensten, verschlüsselte Backups und eine dokumentierte Kryptografie-Richtlinie, das sind vier Bausteine, die du in wenigen Wochen umsetzen kannst und die den Großteil der regulatorischen Anforderungen abdecken.

Fang mit der Bestandsaufnahme an: Was ist heute schon verschlüsselt, und wo gibt es Lücken? Schließe die kritischen Lücken zuerst, dokumentiere deine Standards in einer Richtlinie und baue das Key Management schrittweise auf. Die perfekte Kryptografie-Strategie gibt es am ersten Tag nicht. Aber ein Unternehmen, das seine Festplatten verschlüsselt, aktuelle TLS-Konfigurationen fährt, seine Backups verschlüsselt und das alles in einer Richtlinie dokumentiert hat, steht im Audit und bei einem Sicherheitsvorfall deutlich besser da als eines, das Verschlüsselung dem Zufall überlässt.

Weiterführende Artikel

• NIS2 für den Mittelstand: Was du wissen musst und was jetzt zu tun ist
• Backup-Strategie und Restore-Tests: Daten sichern, die auch wiederherstellbar sind
• TOMs dokumentieren: Technische und organisatorische Maßnahmen nach DSGVO
• Sichere Remote-Arbeit: VPN, Endpoint Security und Richtlinien für Homeoffice
• Passwort-Richtlinie erstellen: Anforderungen, Länge, Komplexität und Alternativen