Was gehört zur Entwicklung einer unternehmensweiten Verschlüsselungsrichtlinie?

Eine unternehmensweite Verschlüsselungsrichtlinie ist das formale Dokument, das festlegt, wie Daten in allen Geschäftsbereichen, Systemen und Datenzuständen kryptographisch geschützt werden. Ohne eine solche Richtlinie treffen einzelne Teams unabhängige Verschlüsselungsentscheidungen, was zu Inkonsistenzen, Compliance-Lücken und unentdeckten Schwachstellen führt. Empfohlene Vorgehensweise: Definieren Sie Algorithmen und Schlüssellängenstandards gemäß den aktuellen NIST-Richtlinien, klassifizieren Sie alle Unternehmensdaten, legen Sie Verschlüsselungskontrollen für jeden Datenzustand (ruhend, während der Übertragung, in Verwendung) fest, definieren Sie Anforderungen an das Schlüsselmanagement, einschließlich der Verwendung von HSM für hochsensible Schlüssel, weisen Sie Governance-Rollen zu und integrieren Sie einen Überprüfungszyklus, der sich weiterentwickelnde kryptographische Standards, einschließlich der Post-Quanten-Migration, berücksichtigt. Eine solide unternehmensweite Verschlüsselungsrichtlinie lässt sich an das spezifische Risikoprofil und die Compliance-Verpflichtungen Ihres Unternehmens anpassen und bietet so eine unternehmensspezifische Lösung für Ihre Verschlüsselungslücken.

Kurzantwort: Was muss eine Unternehmensverschlüsselungsrichtlinie abdecken?

Eine umfassende Unternehmensverschlüsselungsrichtlinie deckt sieben Bereiche ab: technische Verschlüsselungsstandards (zugelassene Algorithmen, Schlüssellängen, Verschlüsselungsmodi nach Datenklassifizierung); Datenklassifizierung (Definition, welche Datentypen verschlüsselt werden müssen und auf welcher Klassifizierungsstufe); Verschlüsselung des Datenzustands (Kontrollen für ruhende, übertragene und verwendete Daten); Schlüsselmanagement (Generierung, Speicherung, Rotation, Hinterlegung und Vernichtung von Verschlüsselungsschlüsseln); Zugriffskontrolle und Funktionstrennung; Schulung und Sensibilisierung; sowie Überwachung und Prüfung. Die Richtlinie muss die aktuellen NIST-Standards (SP 800-57, SP 800-131A, FIPS 140-2/140-3 für HSMs) berücksichtigen und einen Zeitplan für die Überprüfung und Aktualisierung im Zuge der Weiterentwicklung von Algorithmen enthalten. Für das Jahr 2026 und die Zeit danach sollte die Richtlinie auch die Migrationsplanung für Post-Quanten-Kryptographie berücksichtigen, da das NIST ML-KEM (FIPS 203) und ML-DSA (FIPS 204) im Jahr 2024 finalisiert hat und vorgeschlagen hat, RSA-2048 und ECC nach 2030 als veraltet zu betrachten.

Grundlagen der Verschlüsselung für Richtlinienentwickler

Ein Richtlinienentwickler muss kein Kryptograph sein, aber das Verständnis des Unterschieds zwischen Verschlüsselungstypen und Datenzuständen ist unerlässlich, um eine Richtlinie zu verfassen, die tatsächlich das regelt, was sie regeln soll.

Es gibt zwei Arten der Verschlüsselung : symmetrische und asymmetrische. Die symmetrische Verschlüsselung verwendet einen Schlüssel für Ver- und Entschlüsselung. Sowohl das verschlüsselnde als auch das entschlüsselnde System müssen denselben Schlüssel besitzen. Symmetrische Verschlüsselung (AES) ist schnell und eignet sich für die Verschlüsselung großer Datenmengen. Die Herausforderung liegt in der Schlüsselverteilung: Wie erhält der Entschlüsseler den Schlüssel sicher, ohne ihn preiszugeben? Die asymmetrische Verschlüsselung verwendet ein mathematisch verknüpftes Schlüsselpaar: einen öffentlichen und einen privaten Schlüssel. Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können nur mit dem privaten Schlüssel entschlüsselt werden. Asymmetrische Verschlüsselung (RSA, ECC) ist langsamer, löst aber das Problem der Schlüsselverteilung: Der öffentliche Schlüssel kann offen weitergegeben werden; nur der Inhaber des privaten Schlüssels kann entschlüsseln. In der Praxis werden diese Verfahren kombiniert: Die asymmetrische Verschlüsselung überträgt sicher einen symmetrischen Schlüssel, und die symmetrische Verschlüsselung verarbeitet große Datenmengen mit diesem Schlüssel.

Die Daten existieren in drei Zuständen, die jeweils unterschiedliche Verschlüsselungsmaßnahmen erfordern:

• Ruhende Daten: Daten werden auf physischen oder virtuellen Speichermedien (Festplatten, SSDs, Cloud-Speicher, Datenbanken) gespeichert. Zu den Verschlüsselungstechniken gehören die vollständige Festplattenverschlüsselung (FDE), die Datenträgerverschlüsselung, die Dateiverschlüsselung und die Datenbankfeldverschlüsselung. AES-256-GCM ist der aktuell empfohlene Algorithmus. Die Schlüssel zur Verschlüsselung ruhender Daten müssen getrennt von den Daten gespeichert werden, idealerweise in einem HSM.
• Daten während der Übertragung: Daten werden über ein Netzwerk zwischen Systemen übertragen. Geschützt durch Transportprotokolle: TLS 1.3 für Web- und API-Datenverkehr, SSH für Systemadministration und Dateiübertragung, VPNs für Standort-zu-Standort- und Fernzugriff. TLS 1.3 ist der aktuelle Standard; TLS 1.0 und 1.1 dürfen nicht verwendet werden.
• Verwendete Daten: Daten, die aktiv im Speicher oder von einer Anwendung verarbeitet werden. Dies ist der am schwierigsten zu schützende Zustand, da Operationen an verschlüsselten Daten typischerweise eine Entschlüsselung erfordern. Zu den Techniken gehören: Formaterhaltende Verschlüsselung (FPE) für Daten, die während der Verarbeitung in einem bestimmten Format erhalten bleiben müssen, und strenge Zugriffskontrollen, die sicherstellen, dass nur autorisierte Systeme und Benutzer auf die entschlüsselten Daten zugreifen können.

Standards für Algorithmen und Schlüssellängen: Was ist anzugeben?

Der Abschnitt zu den Algorithmenstandards ist der technisch präziseste Teil der Richtlinie. Aktuelle NIST-Empfehlungen (NIST SP 800-57, SP 800-131A, FIPS 186-5):

Anwendungsfall	Genehmigt (in den Richtlinien angeben)	Verboten (muss verboten werden)	Literaturhinweis
Daten im Ruhezustand (symmetrisch)	AES-256-GCM (primär); AES-128-GCM (akzeptabel)	DES; 3DES; RC4; AES-ECB (keine Integrität)	NIST FIPS 197; SP 800-57
Datenübertragung (TLS)	TLS 1.3; TLS 1.2 nur mit ECDHE-AEAD-Suites	TLS 1.0; TLS 1.1; SSL 3.0; schwache Verschlüsselungssammlungen	NIST SP 800-52 Rev. 2
Digitale Signaturen und Zertifikate	ECDSA P-256 (bevorzugt für neue Implementierungen); RSA-3072 als Mindestanforderung, wo RSA erforderlich ist	RSA-1024; DSA (1024-Bit); SHA-1-Signaturen	NIST FIPS 186-5; NIST IR 8547
Hashing	SHA-256; SHA-384; SHA-512	MD5; SHA-1 (für neue Signaturen und Zertifikate)	NIST FIPS 180-4; SP 800-131A
Schlüsselaustausch	ECDHE (TLS 1.3, obligatorisch); ECDH (andere Protokolle)	RSA-Schlüsselaustausch (ohne Vorwärtsgeheimhaltung); statisches DH	NIST SP 800-56A Rev. 3
Schlüsselschutzspeicher	FIPS 140-2 Level 2 oder höher HSM für hochempfindliche Tasten	Speicherung der Klartextschlüssel; unverschlüsselte Softwareschlüsseldateien auf demselben Host wie die verschlüsselten Daten.	NIST SP 800-57; FIPS 140-2/140-3
Post-Quanten-Infrastruktur (neue, langlebige Infrastruktur)	ML-KEM (FIPS 203) für den Schlüsselaustausch; ML-DSA (FIPS 204) für Signaturen	RSA und ECC allein für neue CA-Hierarchien und langlebige Codesignaturschlüssel	NIST FIPS 203, 204, 205; NIST IR 8547

Was bei der Strategieentwicklung zu beachten ist

Bevor Sie die Richtlinie verfassen, muss Ihr Unternehmen einige Entscheidungen treffen, die deren Inhalt prägen. Beginnen Sie mit der Zusammenarbeit: Bringen Sie die Bereiche Compliance, Recht, IT-Sicherheit, Daten-Governance und die Teams, die die Kontrollen implementieren werden, zusammen. Jede Gruppe verfügt über Wissen, das den anderen fehlt. Die Compliance-Abteilung kennt die gesetzlichen Anforderungen; die IT-Sicherheit weiß, was technisch machbar ist; die Implementierungsteams wissen, was in der bestehenden Infrastruktur tatsächlich funktioniert.

Die Datenklassifizierung ist die Grundlage für die Entscheidung, welche Daten verschlüsselt werden sollen. Arbeiten Sie mit der Compliance-Abteilung zusammen, um alle relevanten regulatorischen Rahmenbedingungen (PCI DSS, HIPAA, DSGVO, Landesdatenschutzgesetze) zu ermitteln und Ihre Daten anschließend in Kategorien einzuteilen. Eine Standardklassifizierung mit vier Stufen:

• Öffentlichkeit: Daten, die öffentlich sind oder sein werden. Verlust verursacht keinen Schaden. Verschlüsselung ist nicht erforderlich, jedoch können Integritätskontrollen Anwendung finden.
• Geschäftliche Nutzung: Interne Betriebsdaten. Datenverlust ist zwar lästig, aber nicht katastrophal. Verschlüsselung wird für die Speicherung empfohlen und ist für die Übertragung erforderlich.
• Geheim: Sensible Geschäftsdaten mit Wettbewerbswert. Verlust schädigt den Wettbewerb. Verschlüsselung im Ruhezustand und während der Übertragung mit starken Algorithmen erforderlich.
• Beschränkt: Hochsensible Daten (personenbezogene Daten, Gesundheitsdaten, Finanzdaten, Zahlungskartendaten, Geschäftsgeheimnisse) können zu Haftungsansprüchen, Umsatzeinbußen und potenziellen Rechtsstreitigkeiten führen. Stärkste Verschlüsselung, FIPS-validierte HSM-Schlüsselspeicherung, Multi-Faktor-Authentifizierung für den Zugriff und vollständige Protokollierung sind erforderlich.

Rollen und Zugriffskontrolle definieren, wer auf verschlüsselte Daten und Verschlüsselungsschlüssel zugreifen darf. Das Prinzip der minimalen Berechtigungen ist anzuwenden: Benutzer und Systeme dürfen nur auf die Daten zugreifen, die ihre Rolle erfordert. Verwenden Sie rollenbasierte Zugriffskontrolle (RBAC) in Verbindung mit Datenklassifizierungsstufen. Trennen Sie die Zuständigkeiten für das Schlüsselmanagement: Die Person, die einen Schlüssel generiert, sollte nicht dieselbe Person sein, die den Zugriff darauf genehmigt. Für sensible Datenoperationen sind mehrere Genehmiger erforderlich.

Die Auswahl der Lösung bestimmt die technischen Werkzeuge, die die Richtlinie erfordert. Dazu gehören Zertifikatsverwaltungsplattformen (für TLS und den Lebenszyklus von Codesignaturzertifikaten), Enterprise-Verschlüsselungsplattformen (für die Datenverschlüsselung auf Anwendungsebene), Codesignaturlösungen, Schlüsselverwaltungssysteme oder HSMs sowie PKI (Public-Key-Infrastruktur) zur Zertifikatsausstellung. Die Auswahl sollte sich an den Compliance-Anforderungen und den Best Practices des NIST orientieren, nicht an der Verfügbarkeit der Werkzeuge.

Bedrohungsmodell: Wovor die Richtlinie schützt

Bedrohung	Datenstatus-Ziel	Politische Kontrolle, die sich damit befasst
Netzwerkabhören sensibler Übertragungen	Unterwegs	Obligatorische TLS 1.3-Verschlüsselung mit Vorwärtsgeheimhaltung für alle sensiblen Daten während der Übertragung.
Diebstahl von Speichermedien oder unbefugter Zugriff auf Datenbanken	In Ruhe	AES-256-GCM-Verschlüsselung sensibler Datenfelder und -volumes; Schlüssel im HSM gespeichert, nicht zusammen mit den Daten.
Kompromittierung des privaten Schlüssels ermöglicht Entschlüsselung oder Identitätsdiebstahl	Im Transit und im Ruhezustand	FIPS 140-2 Level 2+ HSM-Speicher für hochkritische private Schlüssel; MFA für den Schlüsselzugriff; regelmäßige Schlüsselrotation
Algorithmische Schwächen aufgrund veralteter Verschlüsselungsverfahren (DES, MD5, SHA-1)	Alle Staaten	Explizites Verbot veralteter Algorithmen in den Richtlinien; regelmäßige Überprüfung anhand der Aktualisierungen von NIST SP 800-131A
Lieferkettenangriff über unsignierte oder kompromittierte Software	Im Transit (Lieferung)	Richtlinie zur Codesignierung, die ECDSA-Signaturen für alle Softwareversionen vorschreibt; HSM-geschützte Signaturschlüssel
Quantenangriff auf langlebige verschlüsselte Daten nach dem Prinzip „Ernten und späteres Entschlüsseln“	Im Transit und im Ruhezustand	PQC-Migrationsplan für Daten, die langfristige Vertraulichkeit erfordern; ML-KEM für neue Schlüsselaustauschinfrastruktur

Wichtige Richtlinienbereiche für die Unternehmensverschlüsselung

• Technische Standards für die Verschlüsselung: Legt die zugelassenen Algorithmen, Schlüssellängen, Verschlüsselungsmodi und Protokolle für jede Datenklassifizierungsstufe und jeden Anwendungsfall fest. Ziel ist Einheitlichkeit: Alle Geschäftsbereiche verwenden dieselben zugelassenen Standards, anstatt unabhängige Entscheidungen zu treffen. Verweist auf NIST-Veröffentlichungen als maßgebliche Quelle für den Zulassungsstatus von Algorithmen. Enthält einen Überprüfungsplan zur Aktualisierung dieser Standards bei Änderungen der Richtlinien.
• Zu verschlüsselnde Daten: Definiert, welche Datentypen verschlüsselt werden müssen und auf welcher Klassifizierungsstufe. Arbeitet mit der Datenklassifizierungsmethodik zusammen, um personenbezogene Daten (PII), Gesundheitsdaten (PHI), Zahlungskartendaten, Anmeldeinformationen, kryptografische Schlüssel und andere regulierte oder sensible Datenkategorien zu identifizieren. Legt fest, welche Daten unverschlüsselt bleiben können (öffentliche Daten) und welche die höchsten Verschlüsselungsstandards erfordern (vertrauliche Daten).
• In welcher Phase soll verschlüsselt werden: Legt die Verschlüsselungsanforderungen für jeden Datenzustand fest. Im Ruhezustand: Welche Speichersysteme, Datenträger und Datenbankfelder müssen verschlüsselt werden und welcher Algorithmus und Modus ist zu verwenden? Bei der Übertragung: Welche Protokolle sind für welche Verbindungstypen obligatorisch und welche verboten? Bei der Verwendung: Wo FPE, Tokenisierung oder Maskierung die Verschlüsselung ersetzen können und wo eine vollständige Verschlüsselung mit Entschlüsselung am Verwendungsort erforderlich ist.
• Schlüsselschutz: Legt fest, wie Verschlüsselungsschlüssel gespeichert, abgerufen und geschützt werden. Erfordert HSMs gemäß FIPS 140-2 Level 2 oder höher für hochsensible Schlüssel. Erfordert MFA für den Zugriff auf Schlüsselverwaltungssysteme. Definiert, wer welche Schlüsselverwaltungsoperationen durchführen darf und den Genehmigungsprozess für den Schlüsselzugriff. Siehe HSM als Service für hardwaregestützte Schlüsselschutzoptionen.
• Schlüsselhinterlegung: Definiert Verfahren zur Wiederherstellung von Verschlüsselungsschlüsseln unter autorisierten Umständen: Notfallwiederherstellung (die verschlüsselten Daten müssen auch bei Ausfall des primären Schlüsselverwaltungssystems zugänglich bleiben), rechtliche Anforderungen (Strafverfolgungs- oder behördliche Ermittlungen) und Geschäftskontinuität. Die Schlüsselhinterlegung erfordert dieselben Sicherheitskontrollen wie die Speicherung des primären Schlüssels und muss in der Dokumentation des Schlüssellebenszyklus enthalten sein.
• Training: Alle Teammitglieder, die verschlüsselte Daten verarbeiten, Zugangsdaten generieren oder Systeme bedienen, die dieser Richtlinie unterliegen, müssen ihre Pflichten kennen. Die Schulung umfasst die Datenklassifizierung und -verarbeitung, die Verwendung zugelassener Verschlüsselungstools, die korrekte Generierung und Verwaltung von Schlüsseln, die Klassifizierung neuer Datentypen sowie das Vorgehen bei einem potenziellen Verschlüsselungsvorfall.
• Monitoring: Die Richtlinie ist nur dann wirksam, wenn die Einhaltung überprüft und Verstöße erkannt werden. Zu den Überwachungsanforderungen gehören: Protokollierung aller Zugriffe auf verschlüsselte sensible Daten und alle Schlüsselverwaltungsvorgänge; Überwachung des Zertifikatsablaufs und entsprechende Benachrichtigungen; Warnungen bei Verwendung verbotener Algorithmen; Zugriffsprotokolle für HSMs und Schlüsselverwaltungssysteme; sowie regelmäßige Überprüfungen des Verschlüsselungsstatus durch Vergleich der implementierten Konfigurationen mit den Richtlinienvorgaben.

Implementierungsbeispiel: Unternehmensweite Verschlüsselungsrichtlinie in einer Gesundheitsorganisation

Ein regionales Krankenhausnetzwerk mit 5,000 Mitarbeitern und HIPAA-Verpflichtungen implementiert eine unternehmensweite Verschlüsselungsrichtlinie für ePHI (elektronisch geschützte Gesundheitsinformationen):

1. Datenklassifizierung und ePHI-Mapping: Eine Datensuche in allen Speichersystemen und Datenbanken identifiziert sämtliche ePHI-Felder: Patientennamen, Geburtsdaten, Krankenaktennummern, Diagnosen und Behandlungsdokumentationen. Alle ePHI-Daten werden als vertraulich eingestuft und erfordern daher die höchsten Verschlüsselungsstandards gemäß den technischen Sicherheitsvorkehrungen des HIPAA (45 CFR 164.312).
2. Verschlüsselung im Ruhezustand: Alle Datenbankserver, die ePHI-Felder enthalten, sind mit AES-256-GCM-Spaltenverschlüsselung für diese Felder konfiguriert. Pro Patientendatensatz werden Datenverschlüsselungsschlüssel (DEKs) verwendet. Die DEKs sind durch einen Schlüsselverschlüsselungsschlüssel (KEK) geschützt, der in einem FIPS 140-2 Level 3 HSM gespeichert ist. Das HSM führt alle Entschlüsselungsvorgänge durch; der KEK gelangt niemals in den Arbeitsspeicher des Anwendungsservers.
3. Verschlüsselung während der Übertragung: Alle internen und externen Verbindungen zu Systemen mit elektronischen Gesundheitsdaten (ePHI) erfordern TLS 1.3. TLS 1.0 und 1.1 sind auf allen Servern deaktiviert. Ein Zertifikatsinventar- und automatisiertes Erneuerungssystem (unter Verwendung von TLS 1.3) ist eingerichtet. CertSecure Manager) stellt sicher, dass kein TLS-Zertifikat unerwartet abläuft, was zu Verbindungsfehlern in klinischen Systemen führen würde.
4. Codesignierung für Software für Medizinprodukte: Alle Software-Updates für vernetzte medizinische Geräte werden mit ECDSA P-256 signiert. CodeSign SecureDie Signaturschlüssel werden im HSM gespeichert. Medizinprodukte-Managementsysteme überprüfen die Signaturen, bevor sie Aktualisierungen anwenden, um zu verhindern, dass unsignierte oder manipulierte Software auf patientennahe Geräte gelangt.
5. PKI für die interne Zertifikatsausstellung: Eine interne PKI-Infrastruktur stellt TLS-Zertifikate für interne Systeme, gegenseitige TLS-Zertifikate für Verbindungen zwischen Diensten und Client-Zertifikate für die Authentifizierung privilegierter Benutzer an klinischen Systemen aus.
6. Zeitplan für die Überprüfung der Richtlinien: Die Verschlüsselungsrichtlinie wird vierteljährlich auf Statusänderungen der NIST-Algorithmen überprüft, jährlich umfassend aktualisiert und unverzüglich bei Auftreten eines der in der Richtlinie definierten Auslöseereignisse (Abschaffung des Algorithmus, Änderung der Compliance-Anforderungen oder Sicherheitsvorfall).

Schlüsselmanagement: Der wichtigste Richtlinienabschnitt

Die Verwaltung von Verschlüsselungsschlüsseln ist wohl der wichtigste und gleichzeitig am häufigsten unzureichend spezifizierte Bestandteil der Verschlüsselungsrichtlinie eines Unternehmens. Selbst der stärkste Algorithmus bietet keinen Schutz, wenn die Schlüssel kompromittiert werden. Anforderungen an die Schlüsselverwaltung:

• Schlüsselspeicher: Hochsensible Schlüssel (CA-Privatschlüssel, Codesignaturschlüssel, Hauptschlüssel für die Verschlüsselung) müssen in FIPS 140-2 Level 2- oder Level 3-HSMs gespeichert werden. Softwarebasierte Schlüsselspeicher sind für weniger sensible Schlüssel mit entsprechenden Zugriffskontrollen zulässig. Verschlüsselungsschlüssel dürfen niemals im Klartext auf demselben System wie die zu schützenden Daten gespeichert werden.
• HSM-Sicherheitsstufen: FIPS 140-2 Level 1 (funktionierender Algorithmus, Produktionsgeräte) bietet das Minimum; Level 2 fügt rollenbasierte Authentifizierung und manipulationssichere physische Geräte hinzu; Level 3 (am häufigsten von Unternehmen verwendet) fügt manipulationsresistente Geräte, identitätsbasierte Authentifizierung hinzu und verlangt, dass Schlüssel, die in das HSM gelangen oder es verlassen, verschlüsselt werden; Level 4 fügt eine manipulationsaktive Funktion hinzu, die das Schlüsselmaterial zerstört, wenn ein physischer Angriff erkannt wird.
• Kryptoperioden und Rotation: Gemäß NIST SP 800-57 ist für jeden Schlüsseltyp eine maximale Schlüssellebensdauer festzulegen: symmetrische Inhaltsverschlüsselungsschlüssel (2 Jahre), asymmetrische Signaturschlüssel (1–3 Jahre), TLS-Zertifikatschlüssel (gemäß den Anforderungen des CA/Browser Forums, aktuell tendenziell mit einer maximalen Zertifikatslebensdauer von 47 Tagen). Für Unternehmen ist eine automatische Schlüsselrotation und Zertifikatserneuerung erforderlich.
• Wichtiges Inventar: Die Richtlinie muss eine aktuelle Bestandsaufnahme aller aktiven Verschlüsselungsschlüssel und -zertifikate vorschreiben. Tools wie CBOM Secure Alle kryptografischen Assets in der gesamten Umgebung ermitteln, einschließlich derjenigen, die außerhalb formaler Prozesse bereitgestellt wurden, um sicherzustellen, dass im Geltungsbereich der Richtlinie nichts übersehen wird.

Einschränkungen und häufige politische Lücken

• Eine Politik ohne Durchsetzung ist wirkungslos: Ein Verschlüsselungsrichtliniendokument ohne technische Kontrollen und Überwachung bietet lediglich formale Konformität, aber keinen tatsächlichen Datenschutz. Die Richtlinie muss die Überwachungs- und Prüfmechanismen festlegen, die ihre Einhaltung sicherstellen.
• Änderung der Algorithmus-Empfehlungen: Eine nach den Standards von 2019 (vor der Finalisierung der PQC-Algorithmen durch das NIST) erstellte Richtlinie erfüllt möglicherweise nicht mehr die Anforderungen der Post-Quanten-Technologie. Es sollte ein obligatorischer Überprüfungsmechanismus für jede Statusänderung eines NIST-Algorithmus implementiert werden.
• Funktionslücken in Cloud- und SaaS-Umgebungen: Die Richtlinie muss explizit auf Cloud-gehostete Daten und SaaS-Anwendungen eingehen, einschließlich Anforderungen an den Schlüsselbesitz (vom Kunden verwaltete Schlüssel vs. vom Anbieter verwaltete Schlüssel) und die Verschlüsselung auf Anwendungsebene, nicht nur auf Speicherebene.
• Unzureichende Spezifikation des Schlüsselmanagements: Viele Richtlinien legen zwar die Anforderungen an Algorithmen fest, lassen aber die Schlüsselverwaltung unzureichend spezifizieren: Wie werden Schlüssel gespeichert? Wer hat Zugriff darauf? Wie erfolgt die Schlüsselrotation? Und was passiert, wenn ein Schlüssel kompromittiert wird? Genau hier liegt der Ursprung der meisten Verschlüsselungsfehler in der Praxis.

Produkte und Dienstleistungen der Verschlüsselungsberatung

Wenn Ihr Unternehmen seine unternehmensweite Verschlüsselungsrichtlinie entwickelt oder aktualisiert, kann Encryption Consulting Sie in allen Bereichen unterstützen:

• Verschlüsselungsberatungsdienste: UNSERE Verschlüsselungsberatung Beurteilen Sie Ihre aktuelle Verschlüsselungssituation, identifizieren Sie Lücken im Vergleich zu den NIST-Standards und Ihren Compliance-Anforderungen und helfen Sie bei der Entwicklung oder Aktualisierung der unternehmensweiten Verschlüsselungsrichtlinie mit spezifischen, umsetzbaren Anforderungen, die auf Ihre Umgebung zugeschnitten sind.
• PKI-Dienste: UNSERE PKI-Dienste Entwerfen und implementieren Sie die Zertifizierungsstelleninfrastruktur, die zur Ausstellung und Verwaltung von TLS-, Codesignierungs- und Clientauthentifizierungszertifikaten gemäß Ihren Richtlinienanforderungen erforderlich ist.
• HSM als Dienstleistung: UNSERE HSM als Service bietet eine nach FIPS 140-3 validierte Hardware-Sicherheitsmodul-Infrastruktur zum Schutz hochsensibler Verschlüsselungsschlüssel, ohne dass eine HSM-Bereitstellung und -Verwaltung vor Ort erforderlich ist.
• CertSecure Manager: CertSecure Manager automatisiert die Ermittlung, Erneuerung und Durchsetzung von TLS-Zertifikaten in Ihrer gesamten Umgebung und implementiert die Überwachungs- und Lebenszyklusmanagementanforderungen der Zertifikatsabschnitte der Richtlinie.
• CodeSign Secure: CodeSign Secure Setzt die Anforderungen Ihrer Richtlinie an die Codesignatur um, integriert sich in CI/CD-Pipelines und speichert Signaturschlüssel in HSMs.
• CBOM Secure: CBOM Secure Erkennt alle kryptografischen Assets in Ihrer Umgebung, stellt die von der Richtlinie geforderte Inventargrundlage bereit und identifiziert Assets, die nicht den genehmigten Algorithmusstandards entsprechen.

Fazit

Eine solide Verschlüsselungsrichtlinie bildet die Grundlage für einen einheitlichen Datenschutz im gesamten Unternehmen. Sie stellt sicher, dass einzelne Teams keine willkürlichen Verschlüsselungsentscheidungen treffen, die Sicherheitslücken verursachen, und dass Compliance-Anforderungen systematisch und nicht uneinheitlich in den verschiedenen Geschäftsbereichen erfüllt werden. Die Wirksamkeit der Richtlinie hängt von ihrer Spezifität (vage Algorithmusvorgaben ermöglichen unzureichende Entscheidungen), ihrer Durchsetzbarkeit (technische Kontrollen und Überwachung müssen die Richtlinie unterstützen) und ihrer Aktualität ab (die Algorithmusvorgaben ändern sich, und die Richtlinie muss entsprechend angepasst werden, insbesondere angesichts des laufenden Übergangs zur Post-Quanten-Verschlüsselung).

Die häufigste Schwäche von Verschlüsselungsrichtlinien in Unternehmen liegt im Schlüsselmanagement: Richtlinien, die zwar Algorithmen festlegen, aber Schlüsselspeicherung, Zugriffskontrollen, Schlüsselrotation und Hinterlegung unzureichend spezifizieren, lassen die kritischste Sicherheitskomponente ungeschützt. Der Einsatz von HSM für hochsensible Schlüssel, die Envelope-Verschlüsselungsarchitektur und die automatische Schlüsselrotation sind die drei Schlüsselmanagementpraktiken, die effektive Verschlüsselungsprogramme am häufigsten von solchen unterscheiden, die zwar formal den Anforderungen entsprechen, in der Praxis aber Schwächen aufweisen. Benötigen Sie Unterstützung bei der Entwicklung oder Aktualisierung Ihrer Verschlüsselungsrichtlinie? Kontaktieren Sie Encryption Consulting.

Häufig gestellte Fragen

Was ist eine unternehmensweite Verschlüsselungsrichtlinie?

Ein formelles Dokument, das festlegt, wie die Organisation Daten mithilfe von Kryptografie schützt: welche Daten in welchem ​​Zustand, mit welchen Algorithmen, unter Verwendung welcher Schlüsselverwaltungsmechanismen und mit welchen Zugriffs- und Überwachungsanforderungen verschlüsselt werden müssen. Es schafft Einheitlichkeit über alle Geschäftsbereiche hinweg und gewährleistet die durchgängige Einhaltung regulatorischer Vorgaben.

Welche Verschlüsselungsalgorithmen sollten spezifiziert werden?

Die aktuell vom NIST gemäß SP 800-57 und SP 800-131A zugelassenen Algorithmen sind: AES-256-GCM für ruhende Daten; TLS 1.3 mit ECDHE für übertragene Daten; ECDSA P-256 oder RSA-3072 für Signaturen und Zertifikate; SHA-256 oder SHA-384 für Hashing. DES, 3DES, MD5, SHA-1, RC4, TLS 1.0/1.1 und RSA-Schlüsselaustausch (ohne Vorwärtsgeheimhaltung) sind ausdrücklich verboten.

Was sind die wichtigsten Anforderungen an das HSM-Management?

FIPS 140-2 Level 2 oder Level 3 HSMs für hochsensible Schlüssel (CA-Privatschlüssel, Codesignaturschlüssel, Hauptschlüssel für die Verschlüsselung). MFA für den Zugriff auf Schlüsselverwaltungssysteme. Funktionstrennung bei Schlüsseloperationen. Kryptoperioden gemäß NIST SP 800-57. Automatisierte Rotation und Erneuerung, wo möglich. Protokollierung aller Ereignisse im Schlüssellebenszyklus.

Welche Compliance-Rahmenwerke erfordern eine unternehmensweite Verschlüsselungsrichtlinie?

PCI DSS v4.0 (Anforderungen 3 und 4 für Karteninhaberdaten); HIPAA-Sicherheitsregeln – Technische Schutzmaßnahmen (45 CFR 164.312 für ePHI); DSGVO Artikel 32 (geeignete technische Maßnahmen); NIST SP 800-53 (SC-12, SC-13, SC-28 für Systeme der Bundesregierung); CMMC SC.3.177 (FIPS-validierte Kryptographie für CUI).

Worin besteht der Unterschied zwischen Verschlüsselung, Tokenisierung und Maskierung?

Verschlüsselung wandelt Klartext in Geheimtext um, der mit einem Schlüssel wiederhergestellt werden kann. Tokenisierung ersetzt sensible Daten durch ein Token; das Original wird in einem separaten Datenspeicher aufbewahrt. Maskierung ersetzt Daten durch fiktive Werte; das Original kann nicht wiederhergestellt werden. Die Richtlinie sollte festlegen, welches Verfahren für welche Datenklassifizierung und welchen Anwendungsfall gilt.

Wie oft sollte es überprüft werden?

Mindestens jährlich sowie unverzüglich bei: Änderungen des NIST-Algorithmusstatus (Aktualisierungen gemäß NIST SP 800-131A; Post-Quanten-Standards nach FIPS 203/204/205 erfordern sofortige Richtlinienaktualisierungen); wesentlichen Änderungen der Infrastruktur oder der Compliance; Nachweis einer kryptografischen Kompromittierung. Die NIST-PQC-Standards von 2024 und die in NIST IR 8547 vorgeschlagene Abschaffung von RSA/ECC bis 2030 verpflichten die meisten Organisationen zu einer sofortigen Aktualisierung ihrer Richtlinien.