CompTIA SY0-701: Datensicherheit, Datenschutz & Kryptografie — Lernleitfaden

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Teil des CompTIA Security+ SY0-701 — Lernleitfaden. Üben Sie mit verifizierten Antworten im CompTIA-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Daten sind das ultimative Ziel der meisten Angriffe, und Kryptografie ist der primäre technische Mechanismus, um sie bei der Übertragung, im Ruhezustand und bei der Verwendung zu schützen. Das Verständnis der Eigenschaften, Einschränkungen und korrekten Anwendung kryptografischer Primitive ist von grundlegender Bedeutung – nicht nur für die Prüfung, sondern auch für den Entwurf von Systemen, die auch dann sicher bleiben, wenn einzelne Kontrollen versagen.

Datenklassifizierung und -handhabung

Die Datenklassifizierung weist Sensibilitätseinstufungen zu, die die Anforderungen an die Handhabung bestimmen. Staatliche Rahmenwerke verwenden Unclassified, Confidential, Secret und Top Secret. Kommerzielle Rahmenwerke verwenden typischerweise Public, Internal, Confidential und Restricted (oder Äquivalente). Die Klassifizierung muss sich nach der Sensibilität der Daten und den regulatorischen Verpflichtungen richten, nicht nach der Bequemlichkeit.

Data Loss Prevention (DLP)-Systeme setzen Handhabungsrichtlinien durch, indem sie Inhalte an Endpunkten, Netzwerk-Egress-Punkten und im Cloud-Speicher inspizieren. Eine DLP-Regel könnte E-Mail-Anhänge blockieren, die 16-stellige Zeichenketten enthalten, die Kreditkartenmustern entsprechen, oder eine Warnung auslösen, wenn ein Benutzer eine Datei mit dem Ausdruck „acquisition target“ in einen persönlichen Cloud-Speicherdienst hochlädt. Die Wirksamkeit von DLP hängt von einer genauen Klassifizierung ab – wenn sensible Daten nicht gekennzeichnet sind, kann DLP sie nicht schützen.

Datensouveränität bezieht sich darauf, wo Daten physisch gespeichert sind und welche Gesetze welcher Gerichtsbarkeit gelten. Die DSGVO (GDPR) verlangt, dass personenbezogene Daten aus der EU, die außerhalb der EU übertragen werden, durch Angemessenheitsbeschlüsse, Standardvertragsklauseln (Standard Contractual Clauses) oder verbindliche interne Datenschutzvorschriften (Binding Corporate Rules) geschützt werden. Global tätige Organisationen müssen Datenflüsse abbilden und sicherstellen, dass die Speicher- und Verarbeitungsorte den geltenden Vorschriften entsprechen.

Verschlüsselung bei der Übertragung und im Ruhezustand

TLS 1.3 ist der aktuelle Standard für die Verschlüsselung von Daten bei der Übertragung. Es eliminiert schwache Cipher Suites, schreibt Forward Secrecy (ephemerer Diffie-Hellman-Schlüsselaustausch) vor und reduziert den Handshake auf einen einzigen Round-Trip. TLS 1.0 und 1.1 sind veraltet; TLS 1.2 ist weiterhin akzeptabel, sollte aber mit starken Cipher Suites konfiguriert werden. Eine Nginx-Konfiguration, die aktuelle Standards erzwingt:

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

Verschlüsselung im Ruhezustand schützt Daten auf Speichermedien. Festplattenverschlüsselung (BitLocker, FileVault, LUKS) verschlüsselt das gesamte Volume; Dateiverschlüsselung (EFS, VeraCrypt-Container) verschlüsselt einzelne Dateien. Datenbankverschlüsselung (Transparent Data Encryption in SQL Server und Oracle) verschlüsselt Datendateien und Backups. Die entscheidende Nuance: Verschlüsselung im Ruhezustand schützt vor dem Diebstahl physischer Medien, aber nicht vor einer kompromittierten Anwendung, die die Daten bereits zur Verarbeitung entschlüsselt hat.

Kryptografische Primitive

Symmetrische Algorithmen (AES-128, AES-256, ChaCha20) verwenden einen einzigen gemeinsamen Schlüssel und sind schnell, was sie für große Datenmengen geeignet macht. Asymmetrische Algorithmen (RSA, ECDSA, Ed25519, ECDH) verwenden Schlüsselpaare und ermöglichen Schlüsselaustausch, digitale Signaturen und die Bindung von Identitäten, sind aber rechenintensiv. Hybride Systeme – wie TLS – verwenden asymmetrische Kryptografie, um einen symmetrischen Sitzungsschlüssel auszuhandeln, und verschlüsseln dann den Großteil des Datenverkehrs symmetrisch.

Hashing (SHA-256, SHA-3) ist eine Einwegfunktion, die einen Digest mit fester Länge erzeugt. Hashes sind keine Verschlüsselung: Sie können nicht mit einem Schlüssel umgekehrt werden, da es keinen Schlüssel gibt. Gesalzene Passwort-Hashes (unter Verwendung von bcrypt, scrypt, Argon2 oder PBKDF2) fügen einen benutzerspezifischen Zufallswert hinzu, um Rainbow-Tables zu umgehen. Hashes dienen der Integritätsprüfung; HMAC kombiniert einen Hash mit einem geheimen Schlüssel, um sowohl Integrität als auch Authentizität zu gewährleisten.

Betriebsmodi (Cipher Modes) sind genauso wichtig wie der Algorithmus. AES im ECB-Modus verschlüsselt jeden Block unabhängig, was bei identischen Klartextblöcken zu identischem Chiffretext führt – eine katastrophale Eigenschaft, die Datenmuster preisgibt. AES-GCM (Galois/Counter Mode) bietet sowohl Vertraulichkeit als auch Integrität in einem einzigen Durchgang und ist der Standard für moderne Protokolle. Der CBC-Modus mit korrektem Padding und einem HMAC ist akzeptabel, aber komplexer in der korrekten Implementierung.

Schlüsselverwaltung und -speicherung

Kryptografie ist nur so stark wie ihre Schlüsselverwaltung. Schlüssel müssen mit starker Entropie erzeugt, getrennt von den Daten, die sie schützen, gespeichert, nach einem Zeitplan rotiert und bei Außerbetriebnahme vernichtet werden. Hardware-Sicherheitsmodule (HSMs) bieten manipulationssichere Schlüsselspeicherung und kryptografische Beschleunigung. Ein Trusted Platform Module (TPM) ist ein Chip auf Endgeräten, der von BitLocker und Measured Boot verwendete Schlüssel speichert. Key Escrow (Schlüsselhinterlegung) hinterlegt eine Kopie von Schlüsseln bei einem vertrauenswürdigen Dritten zur rechtmäßigen Wiederherstellung, während Key Recovery Agents (Schlüsselwiederherstellungsagenten) es Unternehmen ermöglichen, Mitarbeiterdaten bei Bedarf zu entschlüsseln. Cloud-KMS-Dienste (AWS KMS, Azure Key Vault, Google Cloud KMS) bieten Envelope Encryption, bei der ein Data Encryption Key (DEK) die Daten schützt und selbst durch einen Key Encryption Key (KEK) verschlüsselt wird, der im HSM gehalten wird.

Public-Key-Infrastruktur (PKI)

Eine PKI bindet Identitäten an öffentliche Schlüssel durch Zertifikate, die von einer Zertifizierungsstelle (Certificate Authority, CA) ausgestellt werden. Eine untergeordnete CA (Subordinate CA) ist mit einer Root-CA verkettet, deren Zertifikat vorab vertrauenswürdig sein muss. Der Lebenszyklus eines Zertifikats beginnt mit einer Zertifikatsignierungsanforderung (Certificate Signing Request, CSR), die zusammen mit einem privaten Schlüssel generiert wird:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

Die CA validiert den Antragsteller, signiert die CSR und stellt ein X.509-Zertifikat aus. Der Widerruf wird über Zertifikatssperrlisten (Certificate Revocation Lists, CRLs) – periodisch heruntergeladene Listen gesperrter Seriennummern – oder über Online Certificate Status Protocol (OCSP)-Responder veröffentlicht, die Anfragen pro Zertifikat in Echtzeit beantworten. OCSP Stapling ermöglicht es dem Server, während des TLS-Handshakes einen aktuellen, signierten Status zu präsentieren, wodurch Abfragen vom Client zur CA vermieden werden. Zertifikate laufen ab und müssen erneuert werden; die Automatisierung über ACME (Let’s Encrypt, interne ACME-Server) verhindert Ausfälle durch abgelaufene Zertifikate.

Code Signing und Integritätsprüfung

Beim Code Signing wird ein Software-Artefakt mit dem privaten Schlüssel eines Entwicklers signiert; Empfänger verifizieren die Signatur mit dem Zertifikat des Entwicklers und bestätigen so sowohl die Integrität als auch die Herkunft. Dies schützt vor Manipulationen in der Lieferkette (Supply-Chain). Tools zur Überwachung der Dateiintegrität (Tripwire, AIDE) und die Veröffentlichung von Hashes (sha256sum-Werte neben Downloads) erkennen ebenfalls unbefugte Änderungen, aber das Hashing allein beweist nur, dass die Datei mit einem Wert übereinstimmt – es authentifiziert nicht, wer diesen Wert erzeugt hat. Nur eine digitale Signatur, die durch eine PKI gestützt wird, bietet sowohl Integrität als auch Nichtabstreitbarkeit.

Aufbewahrung, Bereinigung und sichere Entsorgung

Aufbewahrungsrichtlinien (Retention Policies) definieren, wie lange jede Datenklasse aufbewahrt werden muss und wann sie gelöscht werden muss. Vorschriften schreiben oft sowohl Mindest- (z. B. Finanzunterlagen für sieben Jahre) als auch Höchstfristen (z. B. personenbezogene Daten nicht länger als nötig aufbewahren) vor. Backups sind davon nicht ausgenommen: Wenn eine betroffene Person von ihrem Recht auf Löschung Gebrauch macht, muss die Organisation über einen nachvollziehbaren Prozess verfügen, um diese Daten aus Backups zu entfernen oder die technischen Einschränkungen und kompensierenden Kontrollen zu dokumentieren. Ein Legal Hold (Sperrung aus Rechtsgründen) setzt die normale Aufbewahrung außer Kraft und friert Daten während eines Rechtsstreits ein.

Wenn Medien das Ende ihrer Lebensdauer erreichen, muss die Bereinigung (Sanitization) der Sensibilität der Daten und der weiteren Verwendung des Mediums entsprechen. NIST SP 800-88 definiert drei Stufen: Clear (logisches Überschreiben, ausreichend für die Wiederverwendung innerhalb der Organisation), Purge (kryptografisches Löschen, Block-Löschen oder Entmagnetisieren, ausreichend für die externe Wiederverwendung) und Destroy (Schreddern, Zersetzen, Verbrennen, Pulverisieren). Kryptografisches Löschen (Cryptographic Erasure) – das Zerstören des Verschlüsselungsschlüssels, sodass der Chiffretext unwiederherstellbar wird – ist schnell und effektiv für selbstverschlüsselnde Laufwerke (Self-Encrypting Drives), die wiederverwendet werden sollen. Entmagnetisieren (Degaussing) macht magnetische Medien unbrauchbar und funktioniert nicht bei SSDs. Die physische Zerstörung ist die einzig sichere Methode für beschädigte Medien oder die höchsten Klassifizierungsstufen.

Praktisches Szenario: Sicherheitsverletzung durch fehlerhaftes Key Management

Ein SaaS-Unternehmen verschlüsselte seine Kundendatenbank mit AES-256, speicherte den Verschlüsselungsschlüssel jedoch in einer Konfigurationsdatei im Klartext im selben Repository wie den Anwendungscode. Als ein Entwickler das Repository versehentlich in einen öffentlichen GitHub-Account pushte, entdeckte ein automatisierter Bot zum Scannen von Anmeldeinformationen den Schlüssel innerhalb von 11 Minuten. Der Angreifer nutzte den Schlüssel, um ein Datenbank-Backup zu entschlüsseln, das in einem öffentlich zugänglichen S3-Bucket gespeichert war (eine separate Fehlkonfiguration). Die Verschlüsselung war technisch korrekt – AES-256 ist durch Brute-Force nicht zu knacken –, aber das Key Management war katastrophal fehlerhaft. Ein ordnungsgemäßes Key Management hätte den Schlüssel in einem Secrets Manager (AWS Secrets Manager, HashiCorp Vault) gespeichert, dessen Zugriff durch IAM-Rollen gesteuert wird, und niemals im Quellcode oder in Konfigurationsdateien.

← Cloud- · Alle Domänen · Geschäftskontinuität →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →