Block 07 · IT-Sicherheit & Datenschutz

A · Erklärungssatz

IT-Sicherheit kam in 8 von 9 Prüfungen vor, fast immer in Teil 1 als Teilaufgabe einer Szenario-Aufgabe (Sensoren übertragen Daten, eine App spricht mit einem Server, ein Webserver bekommt ein Zertifikat). Gefragt wird mit den Operatoren nennen, erläutern, begründen, meist 1–9 Punkte je Teilaufgabe. Gerechnet oder programmiert wird hier selten. Punkte gibt es für saubere Begriffe und eine Begründung mit Bezug zum Szenario. Wer verschlüsseln, signieren und hashen sicher auseinanderhält, holt hier schnelle Punkte.

Die wichtigste Tabelle des Blocks: Welcher Mechanismus sichert welches Schutzziel?

Fast jede Krypto-Frage lässt sich mit dieser Tabelle beantworten. Die Schutzziele selbst werden in SEC-03 genau erklärt.

SEC-01 · Verschlüsselungsverfahren Meistens

Vorkommen: Kryptografie insgesamt 6/9 · Verschlüsselungsverfahren davon in W21, W22, S23, W25, S26 · immer Teil 1, 1–8 Punkte je Teilaufgabe

Grundbegriffe

• Klartext (lesbare Daten) wird mit einem Verfahren (Algorithmus) und einem Schlüssel in Geheimtext (Chiffrat) umgewandelt. Nur wer den passenden Schlüssel hat, kann zurückwandeln.
• Kerckhoffs-Prinzip: Das Verfahren ist öffentlich bekannt, die Sicherheit hängt nur am geheimen Schlüssel. Ein „geheimer eigener Algorithmus“ ist keine Sicherheitsmaßnahme.
• Verschlüsselung sichert das Schutzziel Vertraulichkeit. Sie verhindert nicht, dass jemand das Chiffrat verändert (→ SEC-02).
• Kodierung ist keine Verschlüsselung: Base64, URL-Encoding oder Hex lassen sich von jedem ohne Schlüssel zurückwandeln.

Symmetrische Verschlüsselung

Sender und Empfänger verwenden denselben geheimen Schlüssel zum Ver- und Entschlüsseln.

• Verfahren: AES (Advanced Encryption Standard, Schlüssellänge 128, 192 oder 256 Bit) ist der Standard. Daneben ChaCha20 (gut für Geräte ohne AES-Hardware). Veraltet und unsicher: DES (56 Bit), RC4; 3DES wird nicht mehr empfohlen.
• Vorteile: sehr schnell, wenig Rechenleistung und Energie, oft direkt in Hardware umgesetzt (Prozessoren, viele Mikrocontroller). Geeignet für große Datenmengen.
• Nachteil 1 – Schlüsselaustauschproblem: Der Schlüssel muss vorher über einen sicheren Kanal zu beiden Partnern gelangen. Schickt man ihn unverschlüsselt über das Netz, kann ihn jeder mitlesen. Baut man ihn fest in eine Software ein, haben alle Installationen denselben Schlüssel, und er lässt sich aus der Software auslesen.
• Nachteil 2 – Schlüsselanzahl: Für n Personen, die paarweise geheim kommunizieren wollen, braucht man n·(n−1)/2 Schlüssel. Beispiel: 50 Personen → 50·49/2 = 1.225 Schlüssel.
• Da beide Seiten denselben Schlüssel haben, kann man nicht beweisen, wer von beiden eine Nachricht verschlüsselt hat.

Asymmetrische Verschlüsselung (Public-Key-Verfahren)

Jeder Teilnehmer hat ein Schlüsselpaar: einen öffentlichen Schlüssel (Public Key, darf jeder kennen) und einen privaten Schlüssel (Private Key, verlässt nie den Besitzer). Was mit dem einen Schlüssel bearbeitet wurde, kann nur mit dem anderen umgekehrt werden. Wer B eine vertrauliche Nachricht schicken will, verschlüsselt mit dem öffentlichen Schlüssel von B; entschlüsseln kann nur B mit seinem privaten Schlüssel.

• Verfahren: RSA, Verfahren auf elliptischen Kurven (ECC, z. B. ECDH für Schlüsselvereinbarung, ECDSA für Signaturen), Diffie-Hellman (Schlüsselvereinbarung).
• Vorteile: kein geheimer Schlüsselaustausch nötig (der öffentliche Schlüssel darf ja jeder sehen); bei n Teilnehmern nur n Schlüsselpaare; ermöglicht digitale Signaturen (SEC-02).
• Nachteile: sehr rechenaufwendig (grob 100- bis 1000-mal langsamer als AES), lange Schlüssel, nur für kleine Datenmengen geeignet. Bei RSA ist das Chiffrat außerdem immer so lang wie der Schlüssel (RSA-2048 → 256 Byte), auch wenn die Nachricht nur 10 Byte hat.
• Neues Problem: Gehört der öffentliche Schlüssel wirklich dem, für den ich ihn halte? Ein Angreifer könnte mir seinen eigenen Schlüssel unterschieben (Man-in-the-Middle). Lösung: Zertifikate (SEC-02).

Nur zum Verständnis (wird nicht gerechnet): Mit den Mini-Primzahlen p = 3, q = 11 ist n = 33. Öffentlicher Schlüssel (e = 3, n = 33), privater Schlüssel (d = 7, n = 33). Nachricht m = 4: Chiffrat c = 4³ mod 33 = 64 mod 33 = 31. Entschlüsseln: 31⁷ mod 33 = 4. Mit echten Zahlen von 600 Dezimalstellen ist das Rückrechnen ohne d praktisch unmöglich.

Hybride Verschlüsselung – die Kombination (am häufigsten gefragt!)

Hybride Verfahren nutzen die Stärken beider Welten: Asymmetrisch wird nur ein kleiner, zufällig erzeugter Sitzungsschlüssel (Session Key) sicher übertragen; die eigentlichen Daten werden mit diesem Sitzungsschlüssel symmetrisch und damit schnell verschlüsselt. Beispiel: Eine Mandantin lädt im Online-Portal ihrer Steuerkanzlei 40 MB Belege hoch.

So beschreibst du den Ablauf (Schritte nummerieren, Schlüssel immer genau benennen):

1. Der Sender erzeugt einen zufälligen symmetrischen Sitzungsschlüssel (nur für diese Sitzung/Nachricht).
2. Er verschlüsselt die Daten mit dem Sitzungsschlüssel symmetrisch (AES).
3. Er verschlüsselt den Sitzungsschlüssel mit dem öffentlichen Schlüssel des Empfängers asymmetrisch (RSA) und schickt beides.
4. Der Empfänger entschlüsselt den Sitzungsschlüssel mit seinem privaten Schlüssel.
5. Mit dem Sitzungsschlüssel entschlüsselt er die Daten symmetrisch.

Vorteile hybrid: schnell auch bei großen Datenmengen (gegenüber rein asymmetrisch) · kein vorheriger geheimer Schlüsselaustausch nötig (gegenüber rein symmetrisch) · für jede Sitzung ein neuer Schlüssel, ein erbeuteter Sitzungsschlüssel öffnet also nur diese eine Sitzung.

TLS / HTTPS vereinfacht

TLS (Transport Layer Security, Nachfolger von SSL) ist das Standardbeispiel für hybride Verschlüsselung. HTTPS ist HTTP über TLS; TLS steckt auch in sicheren Mail-Verbindungen, MQTT über TLS usw. Umgangssprachlich heißt das Server-Zertifikat noch „SSL-Zertifikat“.

Was TLS leistet: Vertraulichkeit (symmetrische Verschlüsselung der Nutzdaten), Integrität (jeder Datensatz wird mit einem MAC bzw. im AEAD-Modus geschützt, Veränderungen fallen auf) und Authentizität des Servers (Zertifikat; der Client weiß, mit wem er spricht). Den Client authentifiziert TLS normalerweise nicht, das macht die Anwendung (Login). Ausnahme: gegenseitiges TLS (mTLS) mit Client-Zertifikat, z. B. bei Maschinen untereinander.

In IHK-Lösungen genügt meist die „klassische“ Darstellung aus TLS 1.2: Der Client erzeugt das Sitzungsgeheimnis und schickt es mit dem öffentlichen Schlüssel des Servers verschlüsselt. Seit TLS 1.3 wird der Sitzungsschlüssel stattdessen von beiden Seiten per (Elliptic-Curve-)Diffie-Hellman berechnet; das Zertifikat dient dann zur Authentifizierung des Servers. Beides ist „hybrid“.

Transport- vs. Ende-zu-Ende-Verschlüsselung

Verfahren für leistungsschwache Geräte (IoT-Sensoren)

Batteriebetriebene Sensoren haben wenig Rechenleistung und Speicher, sollen jahrelang mit einer Batterie laufen und dürfen per Funk oft nur wenige Byte je Nachricht senden. So gehst du bei der Auswahl vor:

1. Rahmenbedingungen aus der Anlage herauslesen: Prozessor, RAM, Energieversorgung, Laufzeitziel, maximale Nachrichtengröße, Sendehäufigkeit, vorhandene Krypto-Hardware.
2. Symmetrisch bevorzugen: AES-128 ist schnell, energiesparend und oft als Hardware-Baustein vorhanden. Das Chiffrat ist kaum größer als der Klartext.
3. Schlüsselverteilung lösen: Jedes Gerät bekommt bei der Produktion oder Inbetriebnahme einen eigenen Schlüssel (Pre-Shared Key), der sicher im Gerät (z. B. Secure Element) und auf dem Server gespeichert wird. Nie einen gemeinsamen Schlüssel für alle Geräte – sonst öffnet ein gestohlenes Gerät alle anderen.
4. Asymmetrisch nur sparsam: Wenn überhaupt, dann ECC statt RSA (256-Bit-ECC ≈ Sicherheit von 3072-Bit-RSA bei viel kürzeren Schlüsseln), und nur selten, z. B. einmalig beim Einbinden des Geräts.
5. Integrität nicht vergessen: Zusätzlich einen MAC mitschicken bzw. einen AEAD-Modus verwenden (SEC-02).

Beispiel mit anderen Daten: Ein Funk-Wasserzähler mit Knopfzelle soll 12 Jahre laufen und sendet einmal täglich ein 20-Byte-Telegramm. RSA-2048 würde jede Nachricht auf mindestens 256 Byte aufblähen und viel Energie kosten; ein AES-128-Schlüssel je Zähler, der beim Einbau beim Versorger hinterlegt wird, ist die passende Lösung.

SEC-02 · Hash, digitale Signatur, Zertifikate/PKI Meistens

Vorkommen: Kryptografie insgesamt 6/9 · Hash/Signatur/Zertifikat davon in W21, S22, W22, S23, S26 · Teil 1, 2–9 Punkte je Teilaufgabe

Hashfunktionen

Eine kryptografische Hashfunktion berechnet aus beliebig großen Daten einen Hashwert (Prüfsumme, „digitaler Fingerabdruck“) fester Länge, z. B. 256 Bit bei SHA-256. Eigenschaften:

• Einwegfunktion: Aus dem Hashwert lassen sich die Ausgangsdaten nicht zurückberechnen.
• Kollisionsresistenz: Es ist praktisch unmöglich, zwei verschiedene Eingaben mit demselben Hashwert zu finden.
• Lawineneffekt: Eine winzige Änderung der Eingabe ergibt einen völlig anderen Hashwert.
• Deterministisch und schnell: Gleiche Eingabe → immer gleicher Hashwert; Berechnung geht schnell.

Einsatz: Prüfsummen bei Downloads, Grundlage der digitalen Signatur, Passwortspeicherung (mit Salt), Versionsverwaltung (Git), Erkennen doppelter Dateien.

MAC / HMAC – Prüfsumme mit geheimem Schlüssel

Ein MAC (Message Authentication Code) ist eine Prüfsumme, in die ein geheimer symmetrischer Schlüssel eingeht. Das genormte Verfahren auf Basis einer Hashfunktion heißt HMAC (z. B. HMAC-SHA256). Beispiel: Eine Wetterstation sendet „Wind 87 km/h“ und dazu HMAC(K, „Wind 87 km/h“). Der Server kennt K, berechnet den HMAC über die empfangene Nachricht neu und vergleicht.

• Sichert Integrität (Änderung → anderer MAC) und Authentizität (nur wer K kennt, konnte den MAC berechnen).
• Sichert keine Verbindlichkeit: Beide Seiten kennen K. Der Empfänger könnte den MAC also auch selbst erzeugt haben und kann Dritten nicht beweisen, dass die Nachricht vom Absender stammt.
• Sehr leichtgewichtig, daher ideal für IoT. AEAD-Modi wie AES-GCM oder AES-CCM verschlüsseln und berechnen einen MAC in einem Schritt.

Digitale Signatur

Ablauf in Worten: Die Absenderin bildet den Hashwert des Dokuments und signiert ihn mit ihrem privaten Schlüssel (bei RSA anschaulich: „verschlüsselt den Hashwert mit dem privaten Schlüssel“). Dokument und Signatur werden zusammen versendet. Der Empfänger berechnet den Hashwert des empfangenen Dokuments selbst (H1), prüft die Signatur mit dem öffentlichen Schlüssel der Absenderin (erhält H2) und vergleicht H1 mit H2.

• Gesichert: Integrität (jede Änderung ändert H1), Authentizität (nur die Besitzerin des privaten Schlüssels konnte signieren), Verbindlichkeit/Nichtabstreitbarkeit (sie kann es später nicht bestreiten – im Gegensatz zum MAC).
• Nicht gesichert: Vertraulichkeit. Das Dokument wird im Klartext mitgeschickt. Wer beides braucht, signiert und verschlüsselt (z. B. E-Mail mit S/MIME oder PGP).
• Warum nur den Hashwert signieren? Asymmetrische Verfahren sind langsam; der Hashwert ist kurz und steht trotzdem eindeutig für das ganze Dokument.

Zertifikate und PKI

Problem der asymmetrischen Verfahren: Woher weiß ich, dass ein öffentlicher Schlüssel wirklich zum Online-Shop oder zur Lieferantin gehört? Ein digitales Zertifikat (Standard X.509) ist eine von einer Zertifizierungsstelle (CA, Certificate Authority) digital signierte Bescheinigung, die einen öffentlichen Schlüssel an eine Identität bindet (Domain, Person, Firma).

• Inhalt: Inhaber (z. B. Domainname), öffentlicher Schlüssel des Inhabers, Aussteller (CA), Gültigkeitszeitraum, Seriennummer, Verwendungszweck, Signatur der CA.
• PKI (Public-Key-Infrastruktur): alles, was zum Ausstellen, Verteilen, Prüfen und Sperren von Zertifikaten gehört: Zertifizierungsstellen (Root-CA, Zwischen-CAs), Registrierungsstelle (prüft die Identität des Antragstellers), Verzeichnisse, Sperrlisten (CRL) bzw. Online-Sperrprüfung (OCSP), Regeln.
• Vertrauenskette: Die Root-Zertifikate weniger CAs sind im Betriebssystem bzw. Browser vorinstalliert („Vertrauensanker“). Die Root-CA signiert Zwischen-CAs, diese signieren die Server-Zertifikate.

Was der Browser prüft: (1) Passt der Name im Zertifikat zur aufgerufenen Adresse? (2) Ist das Zertifikat gültig (Zeitraum) und nicht gesperrt? (3) Ist die Signatur korrekt – geprüft mit dem öffentlichen Schlüssel der ausstellenden CA? (4) Schritt (3) wiederholt sich Stufe für Stufe bis zu einem Root-Zertifikat, das im Vertrauensspeicher liegt. Geht alles auf, zeigt der Browser das Schloss; sonst eine Warnung.

• Selbstsigniertes Zertifikat: Niemand Vertrauenswürdiges bürgt dafür → Browserwarnung. Nur für Tests oder interne Systeme mit eigener, verteilter Root.
• Validierungsstufen: DV (nur Domainbesitz geprüft, z. B. kostenlos und automatisiert bei Let's Encrypt), OV (Organisation geprüft), EV (erweiterte Prüfung).
• Was ein TLS-Zertifikat für eine Website leistet: Authentizität des Servers und – über den damit abgesicherten Schlüsselaustausch – Vertraulichkeit und Integrität der Verbindung.

Code-Signing

Auch Programme, Treiber, Apps, Makros und Firmware-Updates werden signiert. Der Hersteller signiert die Datei mit dem privaten Schlüssel seines Code-Signing-Zertifikats; das Betriebssystem bzw. Gerät prüft vor dem Start oder der Installation Signatur und Zertifikatskette. Beispiel: Eine Bäckereikette verteilt eine neue Version ihrer Kassensoftware. Ist die Datei signiert, zeigt Windows den geprüften Herausgeber an; ist sie unsigniert oder nach dem Signieren verändert worden, erscheint „Unbekannter Herausgeber“ bzw. eine Sperrwarnung.

• Code-Signing sichert Integrität (Datei unverändert) und Authentizität (stammt vom genannten Hersteller).
• Es garantiert nicht, dass das Programm fehlerfrei oder gutartig ist – nur, wer es veröffentlicht hat.
• Der private Signaturschlüssel muss besonders geschützt werden (Hardware-Sicherheitsmodul, nur der Build-Server signiert).

SEC-03 · Schutzziele & Schutzbedarf Meistens

Vorkommen: 6/9 · Prüfungen: S22, W22, S23, S24, W25, S26 · Teil 1 (meist 3–4 Punkte, oft in Krypto-Aufgaben eingebaut)

Die Schutzziele

Das BSI nennt drei Grundwerte der Informationssicherheit: Vertraulichkeit, Integrität und Verfügbarkeit (englisch CIA: Confidentiality, Integrity, Availability). Dazu kommen häufig Authentizität und Verbindlichkeit, die das BSI als Teilaspekte der Integrität sieht. Wenn in der Prüfung nach dem „Schutzziel nach BSI“ gefragt wird, ist fast immer einer der drei Grundwerte gemeint.

So gehst du vor: Situation → Schutzziel

1. Frage dich: Was ist passiert bzw. was befürchtet jemand? Wer sieht etwas, das er nicht sehen darf? Was wurde verändert? Was geht nicht mehr? Wer ist nicht der, der er vorgibt zu sein? Wer kann etwas abstreiten?
2. Achte auf die Signalwörter aus der Tabelle.
3. Nenne ein Hauptschutzziel und begründe mit einem Halbsatz aus der Situation („…, weil die Ausleihdaten nicht mehr abrufbar sind“).
4. Ist die Situation mehrdeutig, nenne das naheliegendste Schutzziel und erwähne das zweite kurz.

Beispiele (Stadtbibliothek): „Wegen eines Defekts am Datenbankserver kann zwei Tage lang nichts ausgeliehen werden“ → Verfügbarkeit. „Ein Praktikant ändert Rückgabedaten, damit seine Freunde keine Mahngebühr zahlen“ → Integrität. „Die Ausleihhistorie einer Leserin taucht in einem Internetforum auf“ → Vertraulichkeit.

BSI IT-Grundschutz und Schutzbedarfsfeststellung

Der IT-Grundschutz des BSI (BSI-Standards 200-1 bis 200-3 und das IT-Grundschutz-Kompendium mit seinen Bausteinen) beschreibt, wie eine Organisation ein angemessenes Sicherheitsniveau erreicht. Ablauf der Standard-Absicherung, stark vereinfacht:

1. Strukturanalyse: Welche Geschäftsprozesse, Anwendungen, IT-Systeme, Räume und Netze gibt es?
2. Schutzbedarfsfeststellung: Für jedes Objekt und jedes Schutzziel (V, I, A) wird der Schutzbedarf bestimmt.
3. Modellierung: passende Bausteine aus dem Kompendium zuordnen (z. B. „Webanwendungen“, „Clients unter Windows“).
4. IT-Grundschutz-Check: Soll-Ist-Vergleich der Anforderungen.
5. Risikoanalyse für Objekte mit hohem oder sehr hohem Schutzbedarf, danach Umsetzung der Maßnahmen.

Beispiel (Stadtbibliothek, andere Daten als in den Aufgaben):

• Maximumprinzip: Ein IT-System erbt den höchsten Schutzbedarf der Anwendungen bzw. Daten, die darauf laufen. Liegen Katalog und Leserkonten auf demselben Server, hat der Server bei der Vertraulichkeit den Schutzbedarf „hoch“.
• Kumulationseffekt: Viele Anwendungen mit normalem Bedarf auf einem System können zusammen einen höheren Bedarf ergeben (fällt der Server aus, fällt alles gleichzeitig aus).
• Verteilungseffekt: Ist eine Anwendung redundant auf mehrere Systeme verteilt, kann der Bedarf des einzelnen Systems niedriger sein.

Sicherheitsanforderungen formulieren

Wird nach „sicherheitstechnischen Anforderungen“ an ein System gefragt (S24), erwartet die IHK konkrete, überprüfbare Sätze, die sich einem Schutzziel zuordnen lassen. Muster: „Das System muss … (Was? Womit? Wie viel?)“. Beispiele für die Online-Terminbuchung einer Kfz-Werkstatt:

• Alle Verbindungen zwischen Browser und Server müssen mit TLS 1.2 oder höher verschlüsselt werden. (Vertraulichkeit, Integrität)
• Passwörter müssen mit Salt und einem langsamen Hashverfahren gespeichert werden; nach fünf Fehlversuchen wird das Konto für 15 Minuten gesperrt. (Vertraulichkeit)
• Werkstattmitarbeiter dürfen nur die Termine ihrer eigenen Filiale sehen und ändern (Rollenkonzept). (Vertraulichkeit, Integrität)
• Jede Änderung oder Stornierung eines Termins wird mit Benutzer und Zeitpunkt manipulationssicher protokolliert. (Verbindlichkeit, Integrität)
• Die Buchung muss Mo–Sa von 6 bis 22 Uhr zu 99,5 % verfügbar sein; die Datenbank wird täglich gesichert und lässt sich innerhalb von 4 Stunden wiederherstellen. (Verfügbarkeit)

Verfügbarkeit und Ausfallsicherheit

• Redundanz: doppelte Komponenten (RAID-Festplattenverbund, zweites Netzteil, Server-Cluster, zweites Rechenzentrum, zweite Internetleitung). Achtung: RAID ist kein Backup – versehentlich gelöschte oder verschlüsselte Daten sind auf allen Platten gleichzeitig weg.
• Backups: regelmäßig, automatisiert, nach der 3-2-1-Regel (3 Kopien, 2 verschiedene Medien, 1 außer Haus/offline). Offline bzw. unveränderbar, damit Ransomware sie nicht mitverschlüsselt. Die Wiederherstellung regelmäßig testen.
• Lastverteilung und Skalierung (Load Balancer, zusätzliche Server in Spitzenzeiten), DDoS-Schutz, Monitoring mit Alarmierung.
• Unterbrechungsfreie Stromversorgung (USV) bzw. Notstrom, Klimatisierung, Brandschutz.
• Organisatorisch: Wartungsverträge mit garantierten Reaktionszeiten (SLA), Notfallhandbuch, Ersatzgeräte, Zuständigkeiten.
• Veraltete IT ist ein Verfügbarkeits- und Sicherheitsrisiko. Beispiel: Das Kassensystem eines Kinos läuft auf einem Betriebssystem ohne Herstellerunterstützung. Bekannt gewordene Lücken werden nicht mehr geschlossen, Ersatzteile und Treiber fehlen, neue Software läuft darauf nicht mehr.

SEC-04 · Authentifizierung Wahrscheinlich

Vorkommen: 3/9 · Prüfungen: S22 (OAuth2), W22 (SSO/OAuth2), S24 (Passwort-Reset, Teil 2) · 3–6 Punkte je Teilaufgabe

Identifikation – Authentifizierung – Autorisierung

Genau genommen authentisiert sich der Benutzer (er legt einen Nachweis vor), und das System authentifiziert ihn (es prüft den Nachweis). In der Prüfung werden beide Wörter meist gleich verwendet.

Faktoren und Mehr-Faktor-Authentifizierung (2FA/MFA)

• Zwei-Faktor-Authentifizierung (2FA) verlangt zwei Faktoren aus verschiedenen Kategorien, z. B. Passwort + Code aus der Authenticator-App. Ein gestohlenes Passwort allein reicht dem Angreifer dann nicht.
• TOTP (Time-based One-Time Password): App und Server kennen ein gemeinsames Geheimnis und berechnen daraus zusammen mit der Uhrzeit alle 30 Sekunden einen neuen sechsstelligen Code.
• FIDO2 / Passkeys: asymmetrisches Verfahren; der private Schlüssel bleibt auf dem Gerät und ist an die echte Domain gebunden → schützt besonders gut gegen Phishing.

Passwort-Richtlinien

• Länge schlägt Komplexität: lieber eine lange Passphrase (z. B. vier zufällige Wörter) als ein kurzes Passwort mit Sonderzeichen. Mindestlänge vorgeben (heute meist 12 oder mehr Zeichen).
• Neue Passwörter gegen Listen bekannter, geleakter Passwörter prüfen; Standardpasswörter bei Inbetriebnahme ändern.
• Kein erzwungener Wechsel ohne Anlass (führt zu „Sommer2025!“ → „Herbst2025!“), aber sofortiger Wechsel bei Verdacht auf Kompromittierung.
• Für jeden Dienst ein eigenes Passwort; Passwortmanager empfehlen.
• Systemseitig: Sperre oder steigende Wartezeit nach Fehlversuchen, Benachrichtigung bei Anmeldung von neuem Gerät.

Passwörter sicher speichern

Passwörter werden nie im Klartext und nie umkehrbar verschlüsselt gespeichert, sondern nur als Hashwert. Beim Login wird die Eingabe genauso gehasht und mit dem gespeicherten Wert verglichen. Ein einfacher, schneller Hash (MD5, auch SHA-256) reicht aber nicht:

• Problem 1 – gleiche Passwörter, gleiche Hashes: Wer die Datenbank sieht, erkennt sofort, welche Benutzer dasselbe Passwort haben.
• Problem 2 – vorberechnete Tabellen: Für häufige Passwörter gibt es fertige Listen „Hashwert → Passwort“ (Rainbow Tables, Suchmaschinen).
• Problem 3 – Geschwindigkeit: Grafikkarten berechnen Milliarden MD5-Hashes pro Sekunde. Kurze Passwörter sind so in Minuten durchprobiert (Brute Force, Wörterbuchangriff).

Schematisch: Registrierung salt := zufallswert(), hash := H(pepper + salt + passwort) (mit vielen Runden) → salt und hash speichern. Login: salt zum Benutzer laden, mit der Eingabe denselben Hash berechnen, vergleichen. In der Praxis nimmt man dafür eine fertige Bibliotheksfunktion (Java: SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"), PHP: password_hash(), Spring: BCryptPasswordEncoder) statt einer Eigenentwicklung.

Sicherer Passwort-Reset

• Schlecht: „Wir schicken Ihnen Ihr Passwort zu“ – das beweist, dass es im Klartext gespeichert ist. Sicherheitsfragen („Name des ersten Haustiers“) lassen sich oft in sozialen Netzwerken recherchieren.
• Schwachstelle Link per E-Mail: Wer Zugriff auf das Postfach hat (gehacktes Konto, abgefangene Mail, Mitleser am Firmenrechner), kann das Passwort neu setzen und das Konto übernehmen. Der Reset hat dann nur noch die Sicherheit des E-Mail-Kontos.
• Besser: zufälliges, nur einmal verwendbares Token mit kurzer Gültigkeit (z. B. 30 Minuten), nur dessen Hash speichern; zusätzlich einen zweiten Faktor über einen anderen Kanal verlangen (Code per SMS oder aus der Authenticator-App); nach dem Reset alle Sitzungen beenden und den Nutzer über die Änderung benachrichtigen; dieselbe Meldung anzeigen, egal ob die E-Mail-Adresse existiert (sonst erfährt ein Angreifer, wer Kunde ist).

Sitzungen (Sessions)

Nach dem Login bekommt der Client eine zufällige, lange Session-ID bzw. ein Token. Regeln: nur über HTTPS übertragen, Cookie mit den Attributen Secure, HttpOnly (kein Zugriff per JavaScript) und SameSite; nach dem Login eine neue Session-ID vergeben; Timeout nach Inaktivität (z. B. 15 Minuten bei sensiblen Daten); beim Logout serverseitig ungültig machen.

Single Sign-On (SSO)

Der Benutzer meldet sich einmal bei einem zentralen Identitätsdienst (Identity Provider) an und kann danach mehrere Anwendungen ohne erneute Anmeldung nutzen. Beispiel: Studierende melden sich einmal an und nutzen Lernplattform, Mail und Bibliotheksportal. Technik: SAML 2.0, OpenID Connect (baut auf OAuth2 auf), im Firmennetz Kerberos/Active Directory.

OAuth2 – delegierte Autorisierung

OAuth2 regelt, wie eine Anwendung im Auftrag eines Benutzers auf dessen Daten bei einem anderen Dienst zugreifen darf, ohne das Passwort des Benutzers zu erhalten. Der Benutzer meldet sich nur beim Dienst selbst an und stimmt einem eingeschränkten Zugriff (Scope) zu; die Anwendung bekommt dafür ein zeitlich begrenztes Token.

• Authorization Code: kurzlebiger Einmal-Code, der über den Browser zum Client gelangt. Er allein gibt noch keinen Datenzugriff, sondern wird vom Client (zusammen mit seiner Client-ID und seinem Client-Secret bzw. PKCE bei Apps) direkt beim Authorization Server gegen das Access Token eingetauscht.
• Access Token: „Zugangsausweis“ für die API; enthält bzw. verweist auf Scope und Ablaufzeit (z. B. 1 Stunde). Der Resource Server prüft es bei jeder Anfrage. Ein Refresh Token erlaubt, ohne neue Benutzeranmeldung ein neues Access Token zu holen.
• Scope: Umfang der Berechtigung, z. B. nur „Fotos lesen“, nicht „Fotos löschen“.
• Vorteile: Das Passwort bleibt beim Anbieter · Zugriff ist auf den Scope begrenzt · Zugriff kann je Anwendung widerrufen werden, ohne das Passwort zu ändern · Tokens laufen ab · MFA des Anbieters gilt automatisch mit.
• OpenID Connect (OIDC) ergänzt OAuth2 um ein ID-Token und macht daraus ein Anmeldeverfahren („Anmelden mit …“) – Grundlage vieler SSO-Lösungen.

SEC-05 · Datenschutz / DSGVO Wahrscheinlich

Vorkommen: 2/9 · Prüfungen: W24 (Einwilligung, Datenschutzerklärung in einer App), W25 (keine echten Daten auf eine Online-Prüfseite) · Teil 1, 4–6 Punkte

Datenschutz ist nicht Datensicherheit

Beides hängt zusammen: Die DSGVO verlangt „geeignete technische und organisatorische Maßnahmen“ (TOM) – also Datensicherheit – für personenbezogene Daten.

Personenbezogene Daten

• Personenbezogen (Art. 4 DSGVO) sind alle Informationen über eine identifizierte oder identifizierbare natürliche Person. Identifizierbar heißt: Mit Zusatzwissen lässt sich die Person ermitteln. Beispiele: Name, Anschrift, Geburtsdatum, E-Mail-Adresse, Telefonnummer, Kundennummer, Kfz-Kennzeichen, Standortdaten, Online-Kennungen (Cookie-ID, Geräte-ID), Foto, Stimme.
• Nicht personenbezogen sind Daten ohne Bezug zu einer Person (Temperatur einer Maschine) und echt anonymisierte bzw. so stark zusammengefasste Daten, dass kein Rückschluss auf Einzelne möglich ist („durchschnittlich 312 Besucher pro Tag“).
• Pseudonymisierte Daten (Name durch Kennung ersetzt, Zuordnungstabelle existiert noch) bleiben personenbezogen – Pseudonymisierung ist aber eine gute Schutzmaßnahme.
• Besondere Kategorien (Art. 9): Gesundheitsdaten, genetische und biometrische Daten (zur Identifizierung), ethnische Herkunft, politische Meinung, religiöse Überzeugung, Gewerkschaftszugehörigkeit, Sexualleben/sexuelle Orientierung. Grundsätzlich verboten, außer mit ausdrücklicher Einwilligung oder einer anderen Ausnahme aus Art. 9 Abs. 2 – und mit besonders hohem Schutzbedarf.

Grundsätze der Verarbeitung (Art. 5)

Rechtsgrundlagen (Art. 6 Abs. 1) – ohne eine davon ist die Verarbeitung verboten

Einwilligung richtig einholen

• Freiwillig: keine Nachteile bei Ablehnung. Kopplungsverbot: Die Vertragsleistung darf nicht von einer Einwilligung abhängig gemacht werden, die dafür nicht nötig ist.
• Für einen bestimmten Fall und getrennt je Zweck (eigene Checkbox für Newsletter, eigene für Weitergabe an Partner), nicht in AGB versteckt.
• Informiert: Zweck, Verantwortlicher, Empfänger, Widerrufsrecht sind vorher bekannt.
• Unmissverständlich durch aktive Handlung: leere Checkbox, die der Nutzer selbst ankreuzt. Vorangekreuzte Kästchen sind keine wirksame Einwilligung (EuGH 2019, „Planet49“).
• Jederzeit widerrufbar – so einfach wie erteilt (z. B. Schalter in den App-Einstellungen).
• Nachweisbar (Zeitpunkt, Version des Textes speichern; bei Newslettern Double-Opt-in).
• Für Gesundheitsdaten und andere besondere Kategorien: ausdrücklich und gesondert.

Beispiel (App einer Tanzschule): Bei der Anmeldung zum Kurs werden nur Name, E-Mail und Bankverbindung als Pflichtfelder abgefragt (Vertrag). Darunter zwei leere, getrennte Checkboxen: „Ich möchte den monatlichen Newsletter erhalten“ und „Fotos von mir dürfen auf der Website der Tanzschule erscheinen“, jeweils mit Hinweis auf den Widerruf in den Einstellungen und einem Link zur Datenschutzerklärung.

Datenschutzerklärung (Informationspflichten, Art. 13)

Die Datenschutzerklärung informiert – ihr muss man nicht „zustimmen“. In einer App muss sie vor der Datenerhebung (z. B. im Registrierungsdialog und im Store-Eintrag) und jederzeit über das Menü erreichbar sein, in klarer, verständlicher Sprache. Inhalt:

• Name und Kontaktdaten des Verantwortlichen und ggf. des Datenschutzbeauftragten,
• Zwecke und Rechtsgrundlagen der Verarbeitung, ggf. das berechtigte Interesse,
• Empfänger (z. B. Zahlungsdienstleister, Hosting-Anbieter), Übermittlung in Drittländer,
• Speicherdauer bzw. Kriterien für die Löschung,
• Betroffenenrechte, Widerrufsrecht bei Einwilligungen, Beschwerderecht bei der Aufsichtsbehörde,
• ob die Angabe der Daten Pflicht ist und was passiert, wenn man sie nicht angibt.

Betroffenenrechte

Frist für die Antwort: grundsätzlich ein Monat. Vorher die Identität des Anfragenden prüfen – sonst gibt man die Daten womöglich einem Betrüger.

Weitere Begriffe, die man kennen muss

• TOM (technische und organisatorische Maßnahmen, Art. 32): z. B. Verschlüsselung, Pseudonymisierung, Rollen- und Rechtekonzept, Protokollierung, Backups, Zutrittskontrolle zum Serverraum, Verpflichtung der Mitarbeitenden auf Vertraulichkeit, Schulungen.
• Privacy by Design (Art. 25): Datenschutz von Anfang an in die Technik einbauen (z. B. Pseudonymisierung, Löschroutinen, Verschlüsselung im Entwurf vorsehen). Privacy by Default: Die Voreinstellungen sind die datenschutzfreundlichsten – z. B. Profil standardmäßig privat, Standortfreigabe aus, optionale Datenfelder leer.
• Auftragsverarbeitung (Art. 28): Ein Dienstleister verarbeitet Daten im Auftrag (Cloud-Hosting, Rechenzentrum, Newsletter-Dienst). Pflicht: AV-Vertrag, Dienstleister ist weisungsgebunden, muss TOM nachweisen; Unterauftragnehmer nur mit Zustimmung. Bei Servern außerhalb der EU zusätzlich prüfen, ob ein angemessenes Datenschutzniveau besteht (Angemessenheitsbeschluss, z. B. EU-US Data Privacy Framework, oder Standardvertragsklauseln).
• Datenschutz-Folgenabschätzung (Art. 35) bei voraussichtlich hohem Risiko, z. B. umfangreiche Verarbeitung von Gesundheitsdaten.
• Datenpanne: Meldung an die Aufsichtsbehörde binnen 72 Stunden (Art. 33), bei hohem Risiko auch Benachrichtigung der Betroffenen. Bußgelder bis 20 Mio. € oder 4 % des weltweiten Jahresumsatzes.
• Aufbewahrungspflichten gehen dem Löschwunsch vor: Rechnungen und andere Buchungsbelege müssen nach Handels- und Steuerrecht mehrere Jahre aufbewahrt werden (Buchungsbelege derzeit 8 Jahre). In dieser Zeit werden sie gesperrt, nicht gelöscht.

Echte Daten in Testsystemen und Online-Tools

Wer echte personenbezogene Daten (Kundenlisten, Rechnungen, Bankverbindungen) in ein kostenloses Online-Prüf- oder Konvertierungstool hochlädt, übermittelt sie an einen Dritten – ohne Rechtsgrundlage, ohne AV-Vertrag, ohne Wissen, wo und wie lange sie gespeichert werden (eventuell außerhalb der EU). Das verletzt Datenschutz und Vertraulichkeit. Besser: synthetische Testdaten (erfundene, aber realistische Datensätze) oder sauber anonymisierte Daten verwenden, Prüfwerkzeuge lokal bzw. im eigenen Netz betreiben oder einen Anbieter mit AV-Vertrag wählen.

SEC-06 · Angriffe & Gegenmaßnahmen Sonstige

Vorkommen: 1/9 · Prüfung: S24 (Teil 2, A1b: Makros in Word-Anhängen, 5 P) · als Wissen aber auch Grundlage für SEC-03 und SEC-04

SQL-Injection im Code erkennen und beheben

Beispiel: Die Katalogsuche einer Bibliothek baut die Eingabe des Benutzers direkt in den SQL-Text ein.

Java · unsicher

String sql = "SELECT titel, autor FROM buch WHERE autor = '" + eingabe + "'";
Statement st = con.createStatement();
ResultSet rs = st.executeQuery(sql);

Enthält die Eingabe ein Hochkomma, endet die Zeichenkette im SQL-Text vorzeitig, und alles danach wird als SQL-Code gelesen. Schon ein harmloser Autorenname wie O'Brien führt deshalb zu einem Syntaxfehler. Ein Angreifer nutzt genau diesen Effekt gezielt aus: Er formuliert seine Eingabe so, dass sich die Bedeutung der Abfrage ändert. Bedingungen wie eine Passwortprüfung werden dann umgangen, fremde Tabellen ausgelesen oder Daten verändert.

Java · sicher mit Prepared Statement

String sql = "SELECT titel, autor FROM buch WHERE autor = ?";
PreparedStatement ps = con.prepareStatement(sql);
ps.setString(1, eingabe);          // Wert wird getrennt als reine Daten übergeben
ResultSet rs = ps.executeQuery();

Warum das hilft: Die SQL-Anweisung mit dem Platzhalter ? wird zuerst an die Datenbank geschickt und dort vorbereitet. Der Eingabewert wird anschließend getrennt als Datenwert übergeben und nie als SQL-Code interpretiert. Eine Eingabe mit Hochkommas ist dann einfach ein (nicht existierender) Autorenname und ändert die Abfrage nicht mehr. Eigene „Filter“, die Hochkommas entfernen, sind dagegen fehleranfällig.

XSS in einem Satz

Ein Gästebuch speichert den Kommentar <script>…</script> und gibt ihn unverändert in die HTML-Seite aus – jeder Besucher führt das Skript aus (z. B. Diebstahl des Session-Cookies, gefälschtes Login-Formular). Abhilfe: Ausgaben kontextgerecht kodieren, dann zeigt der Browser <script> nur als Text an.

B · Belegsatz

Für IT-Sicherheit und Datenschutz legt die IHK keine Notationshilfe bei. Der Belegsatz besteht deshalb nur aus den Anlagen zur Ausgangssituation, auf die sich die Aufgaben beziehen. Keine Erklärungen.

 1  import java.security.MessageDigest;
 2  import java.sql.*;
 3
 4  public class MitgliederDAO {
 5
 6      private static final String DB_URL  = "jdbc:mysql://db.pulsar.intern:3306/pulsar";
 7      private static final String DB_USER = "root";
 8      private static final String DB_PASS = "Pulsar2026!";
 9
10      // Anmeldung im Web-Portal: true, wenn E-Mail und Passwort stimmen
11      public boolean login(String email, String passwort) throws Exception {
12          Connection con = DriverManager.getConnection(DB_URL, DB_USER, DB_PASS);
13          String sql = "SELECT mitglied_nr FROM mitglied WHERE email = '" + email
14                     + "' AND passwort_md5 = '" + md5(passwort) + "'";
15          Statement st = con.createStatement();
16          ResultSet rs = st.executeQuery(sql);
17          return rs.next();              // mindestens ein Treffer = angemeldet
18      }
19
20      // Kursbewertungen als HTML-Liste für das Web-Portal
21      public String bewertungenAlsHtml(int kursId) {
22          StringBuilder html = new StringBuilder("<ul>");
23          try {
24              Connection con = DriverManager.getConnection(DB_URL, DB_USER, DB_PASS);
25              PreparedStatement ps = con.prepareStatement(
26                  "SELECT kommentar FROM bewertung WHERE kurs_id = ?");
27              ps.setInt(1, kursId);
28              ResultSet rs = ps.executeQuery();
29              while (rs.next()) {
30                  html.append("<li>").append(rs.getString("kommentar")).append("</li>");
31              }
32          } catch (SQLException e) {
33              return "<p>Datenbankfehler: " + e.getMessage() + "</p>";
34          }
35          return html.append("</ul>").toString();
36      }
37
38      // MD5-Hashwert als Hex-String (32 Zeichen)
39      private static String md5(String text) throws Exception {
40          MessageDigest md = MessageDigest.getInstance("MD5");
41          StringBuilder hex = new StringBuilder();
42          for (byte b : md.digest(text.getBytes("UTF-8"))) {
43              hex.append(String.format("%02x", b));
44          }
45          return hex.toString();
46      }
47  }

C · Aufgaben

Alle Aufgaben beziehen sich auf die Ausgangssituation in Anlage 1. Antworten bei „erläutern“ und „begründen“ immer mit Bezug zur Situation (PulsarConnect) formulieren. Zeitrichtwert: 1 Punkt ≈ 0,9 Minuten.

SEC-01 · Verschlüsselungsverfahren

SEC-02 · Hash, digitale Signatur, Zertifikate/PKI

SEC-03 · Schutzziele & Schutzbedarf

SEC-04 · Authentifizierung

SEC-05 · Datenschutz / DSGVO

SEC-06 · Angriffe & Gegenmaßnahmen

Originalaufgaben zum Üben

Diese echten Prüfungsaufgaben passen zu diesem Block (Dateien im Ordner Prüfungsvorbereitung). Lösungen gibt es nur für 2023 Sommer, 2023 Winter, 2024 Sommer und 2025 Winter (dort vom u-form-Verlag). W23 enthielt keine Sicherheitsaufgabe.