Ziele

Rahmenlehrplan

• Mit Hilfe einer Risikoanalyse den Schutzbedarf eines vernetzten Systems ermitteln und Schutzmaßnahmen planen, umzusetzen und dokumentieren

• Auf Kundengespräch zur Identifizierung eines Schutzbedarfes vorbereiten

  • Informieren über Informationssicherheit in vernetzten Systemen

• Im Kundengespräch die Schutzziele ermitteln, analysieren der Systeme hinsichtlich der Anforderungen an die Informationssicherheit und benennen von Risiken

• Unter Beachtung betrieblicher IT-Sicherheitsleitlinien und rechtlicher Regelungen die Vorkehrungen und Maßnahmen zur Minimierung der Wahrscheinlichkeit eines Schadenseintritts planen

• Implementieren der Maßnahmen unter Berücksichtigung technischer und organisatorischer Rahmenbedingungen

• Prüfen der Sicherheit des vernetzten Systems und bewerten des erreichten Sicherheitsniveaus in Bezug auf die Kundenanforderungen, eingesetzter Maßnahmen und Wirtschaftlichkeit

  • Erstellen einer Dokumentation
  • Informieren des Kunden über die Ergebnisse der Risikoanalyse

• Reflektieren des Arbeitsprozesses hinsichtlich möglicher Optimierungen

  • Diskutieren des Ergebnisses in Bezug auf den Begriff der relativen Sicherheit des vernetzten Systems

Lehrplan Sachsen

Prüfungsvorbereitung

Überblick Prüfungsthemen der vergangenen Jahre

Für die Prüfungsvorbereitung erscheinen nach Sichtung vergangener IHK-Prüfungen folgenden Schwerpunkte als relevant für LF11b um alle Fachkompetenzen in einem geeigneten Lernfeld abzudecken:

Datenschutz und Datensicherheit

• Wiederholung LF4
  • Datenschutz
  • IT-Grundschutz
  • Schutzbedarfsanalyse
  • Grundlagen TOM
• Risikoanalyse

Crypto & Auth

• X.509, CA
• TLS
• Auth
  • 2FA
  • SSO (SAML, OAuth2, OpenID Connect)

Sicherheit vernetzter Systeme

• Router, NAT
• Firewall, DMZ
• VLAN, Router-on-a-stick
• VPN
• WLAN, Radius

Praxis

Verschlüsselung

• SSH-Keys
• GPG
• TLS

Netzwerkpraxis

• MITM-Proxy
• nmap
• tcpdump, Wireshark
• OpenVAS, SIEM

CTF

Quellen

Anforderungen

• Rahmenlehrplan Fachinformatiker, KMK — Beschluss vom 13.12.2019; Übersicht aller 12 Lernfelder mit Titeln, abstrakten Inhalten und Zeitrichtwerten.

• Rahmenlehrplan Fachinformatiker, Sachsen — Beschreibung des Lernfelds; Grundlage aller Lernziele.

Recht

• DSGVO, Verordnung (EU) 2016/679, amtlicher Text — Art. 5 Grundsätze der Verarbeitung, Art. 32 technische und organisatorische Maßnahmen.
  • DSGVO, Art. 5 (Grundsätze für die Verarbeitung personenbezogener Daten)
  • DSGVO, Art. 32 (Sicherheit der Verarbeitung)

IT-Grundschutz & Standards

• BSI-Standard 200-1 — Managementsysteme für Informationssicherheit (ISMS)

• BSI-Standard 200-3 — Risikoanalyse auf Basis von IT-Grundschutz (HTML Version)

• BSI IT-Grundschutz++

OER & Unterrichtsmaterial

• Softwareanforderungen — Funktionale vs. Nichtfunktionale Anforderungen; Software-Qualitätsmerkmale: ISO 25010 (LF10a)

Bedrohungslage

• BSI-Lagebericht 2025 — jährlicher Lagebericht zur IT-Sicherheit in Deutschland

Übungen

• LF10b Praxisprojekte 2026 — Hier finden wir noch genug spannende Herausforderungen

• OWASP Juice Shop — bewusst unsichere Webanwendung zum Üben.

• Hack The Box — schwierigere Maschinen ohne Anleitung.

• Bios-Passwörter zurücksetzen — Nötig für Labor-Rechner ;)

• hashcat — Passwortknacken

• John the Ripper — Passwortknacken

Hinweise für Lehrkräfte

• Prüfungskatalog (U-Form Verlag)

• IHK Dresden, Ausbildungsberuf Fachinformatiker — Ausbildungsberuf, Prüfungsordnung und Anforderungen der IHK.

• Fachinformatikerausbildungsverordnung (FIAusbV) — Volltext der Ausbildungsverordnung

  • § 24 — Gewichtung der Prüfungsbereiche für die Fachrichtung Systemintegration

Plan

Zeitplan

gantt
    title LF11b Stunden
    dateFormat YYYY-MM-DD
    axisFormat %d.%m.%Y
    section 06.10. – 08.10.
        IT-Grundschutz : 2026-10-06, 3d
    section 19.10. – 23.10.
        Crypto & Auth : 2026-10-19, 5d
    section 26.10. – 29.10.
        Netzwerksicherheit : 2026-10-26, 4d
    section 30.11. – 02.12.
        Praxis : 2026-11-30, 3d

KW 41: Grundlagen Datenschutz und Datensicherheit

06.10.:

• Einordnung Datenschutz und Datensicherheit

• Datenschutzrecht

  • Gesetze
    • DSGVO, BDSG, …
  • Prinzipien
    • Verbot mit Erlaubnisvorbehalt
    • Grundsätze für die Verarbeitung personenbezogener Daten
    • Betroffenenrechte
    • Verarbeitung besonderer Kategorien personenbezogener Daten
    • Melde-/Benachrichtigungspflichten
  • Verantwortlichkeiten
  • Datensparsamkeit

• Datensicherheit

• IT-Grundschutz-Methodik

  • Basis-, Kern-, Standardabsicherung

07.10.:

• IT-Sicherheitsmanagement
• Gefährdungen
  • DoS
  • Phishing
  • Arten von Malware: Würmer, Trojaner, Ransomware
• Vulnerability -> Exploit
• Schutzbedarfsanalyse

Interaktive Übung zu Strukturanalyse und Schutzbedarfsfeststellung am Beispiel „Mail“

08.10.:

• IT-Grundschutz-Methodik

  • Ablauf Standard-Absicherung
  • Wiederholung Schutzbedarfsanalyse

• IT-Grundschutz-Check

• Grundlagen TOM

  • Endgerätesicherheit

• Ablauf Standard-Absicherung

  • Risikoanalyse

Gruppenarbeit “Risikoanalyse” -> IT-Grundschutz (vereinfacht) mittels Vorlage für Praxisprojekt an eigenem Beispiel

KW43: Crypto & Auth

gantt
    title LF11b Stunden KW43
    dateFormat YYYY-MM-DD
    axisFormat %d.%m.
    section Mo 19.10. (6 UE)
        Grundlagen TOM : 2026-10-19, 6h
    section Di 20.10. (6 UE)
        Verschlüsselung+Signaturen : 2026-10-20, 6h
    section Mi 21.10. (6 UE)
        Authentifizierung+Authorisierung : 2026-10-21, 6h
    section Do 22.10. (6 UE)
        Wiederholung : 2026-10-22, 6h
    section Fr 23.10. (2 + 2 UE)
        1. Klassenarbeit : crit, 26_10_23_ue56, 2026-10-23, 2h
        SOL : after 26_10_23_ue56, 2h
        Nachhilfe Ansible : after 26_10_23_ue56, 2h

19.10.:

• Überleitung vom Datenschutzrecht und organisatorischen Maßnahmen zu TOM
• Wiederholung Krypto-Grundlagen
  • symmetrische vs. asymmetrische Kryptographie
  • Hashes
• Überblick Authentifizierung
  • Passwörter, 2FA/MFA
  • ACL
• Ausblick: Schlüsselaustausch-Problem

Praxis: /etc/shadow, chmod, SSH-Keys

20.10.:

• Verschlüsselung unterscheiden: Datenträger-, Transport-, Ende-zu-Ende
• Hybride Verschlüsselung
• Signaturen und Schlüsselaustausch
  • PKI vs. Web-of-Trust
  • CA, X.509 → SSL/TLS

Praxis: PGP/GPG

21.10.:

• Authentifizierung und Autorisierung
  • relevante TOMs raussuchen, unterscheiden, erklären
• Passwörter
• Dateiberechtigungen (ACL)
• SSO, OAuth2, OIDC, SAML

Praxis: FastAPI-Security, Keycloak/Authentik/Authelia

22.10.:

• Wiederholung
  • Datenschutz & Datensicherheit
    • Gefährdungen, Malware (Vektoren, Payload)
  • IT-Grundschutz
    • Basis-, Kern- und Standardabsicherung
    • Schutzbedarfsanalyse -> 6 Schadensszenarien
    • Risikobehandlung
  • TOM
    • Endgerätesicherheit und SYS.2.1 „Allgemeiner Client“
    • Zutritts-, Zugangs- und Zugriffskontrolle
  • Kryptogrundlagen
  • TLS 1.2
  • Authentifizierung
  • Autorisierung
    • Least Privilege, ACL, RBAC, OAauth2

23.10.:

• Klassenarbeit (2 UE)
• SOL: Prüfungsaufgaben

KW44: Netzwerksicherheit

gantt
    title LF11b Stunden KW44
    dateFormat YYYY-MM-DD
    axisFormat %d.%m.
    section Mo 26.10. (6 UE)
        Firewall : 2026-10-26, 6h
    section Di 27.10. (6 UE)
        VLAN + WLAN : 2026-10-27, 6h
    section Mi 28.10. (6 UE)
        VPN : 2026-10-28, 6h
    section Do 29.10. (3 UE)
        2. Klassenarbeit : crit, 2026_10_29_ka, 2026-10-29, 2h
        Ausblick Praxisprojekt : after 2026_10_29_ka, 1h

26.10.:

• Wiederholung Routing
  • NAT
• Firewalls
  • Whitelist-/Blacklist-Strategie
  • Paketfilter, SPI, Application-Layer → NGFW, WAF
• DMZ

27.10.:

• VLAN
  • Traffic-Trennung, Verkleinerung der Broadcast-Domäne
  • L3-Switching, Router-on-a-stick, IEEE 802.1Q
  • VLAN-Hopping
• WLAN
  • SSID, BSSID, Kanäle, hidden SSID, WLAN-Scan
  • WPA2/WPA3, Enterprise (EAP/RADIUS)

28.10.:

• VPN
  • TUN/TAP, WireGuard, OpenVPN, IPSec, VXLAN
• Zero Trust
• Wiederholung
  • WLAN

29.10.:

• Klassenarbeit (2 UE): Gesamtstoff, Schwerpunkt Netzwerksicherheit
• Ausblick Praxisprojekt
  • MITM-Proxy, nmap, tcpdump, Wireshark, OpenVAS, SIEM
  • CTF, Hackerethik, 202c StGB

AP2-Übersicht: Zuordnung zu LF11b-Blöcken

Legende

* = Zuordnung zur Spalte inhaltlich passend, wird aber als Stoff aus Vorgänger-LFs vorausgesetzt und nicht erneut behandelt.

Matrix

IT-Grundschutz

💡 Für Grundlagen zu Datenschutz & Datensicherheit und IT-Grundschutz bitte im LF4-Repo nachschauen.

Datenschutz und Datensicherheit

• Einordnung Datenschutz und Datensicherheit
• Datenschutzrecht
  • Gesetze
    • DSGVO, BDSG, …
  • Prinzipien
    • Verbot mit Erlaubnisvorbehalt
    • Grundsätze für die Verarbeitung personenbezogener Daten
    • Betroffenenrechte
    • Verarbeitung besonderer Kategorien personenbezogener Daten
    • Melde-/Benachrichtigungspflichten
  • Verantwortlichkeiten
  • Datensparsamkeit
• Datensicherheit
• IT-Sicherheitsmanagement

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 1 ba

Vier inhaltliche Anforderungen an ein Datenschutzkonzept nennen, das das Bankhaus regelmäßig überarbeitet

📝❗ FiSi AP2 Konzeption Sommer 2022 Aufgabe 3 bc

DSGVO bei der Videoüberwachung des Firmengeländes: Begriffe Löschfristen, Persönlichkeitsrecht und Zweckbindung erläutern

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 1 bb

Kundendaten versehentlich an einen unberechtigten Empfänger gesendet: drei Maßnahmen, die das Bankhaus nach DSGVO unverzüglich einleiten muss

📝❗ FiSi AP2 Konzeption Sommer 2025 Aufgabe 2 a

Erheblicher IT-Sicherheitsvorfall im SAN: drei datenschutzrelevante Kriterien, die über die Informationspflicht der betroffenen Kunden entscheiden

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 4 bb

Briefgeheimnis: unter welcher Bedingung ein Spamfilter oder der Administrator eine Firma Mails auf unerwünschten Inhalt untersuchen darf

📝❗ FiSi AP2 Konzeption Sommer 2026 Aufgabe 3 d

Datenschutz bei Cloud-Speicherung: besonders schützenswerte personenbezogene Daten und zugangsrelevante Geheimnisse nur verschlüsselt speichern; TOM für Verschlüsselung bei Übertragung und im Ruhezustand; AVV nach Art. 28 DSGVO; Serverstandort EU

Gefährdungen

• Gefährdungen
  • DoS
  • Phishing
  • Arten von Malware: Würmer, Trojaner, Ransomware
• Vulnerability → Exploit

📝❗ FiSi AP2 Analyse Winter 2025 Aufgabe 2 e

Angriffsmethoden erläutern

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 2 bc

Malware-Typen zuordnen: Virus, Wurm, Trojaner, Ransomware

Mail

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 2 ba–bb

Phishing-E-Mail im Bankhaus: drei Merkmale für die Unvertrauenswürdigkeit erkennen; drei Unregelmäßigkeiten am PC nach dem Klick auf den Hyperlink

📝❗ FiSi AP2 Konzeption Winter 2024 Aufgabe 2 c cb

Spam-Filter mit BLOCKLIST: Grund für die SMTP-Fehlermeldung 554 5.7.1 Matched map: BLOCKLIST_SENDER_DOMAIN beim Geschäftspartner

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 4 bc

Funktion einer Sandbox beim Mail-Eingang für unbekannte Datei-Anhänge beschreiben

TOM

• Grundlagen TOM
  • Endgerätesicherheit
    • Systemhärtung

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 2 ab

Schutzziele der Informationssicherheit erläutern: Confidentiality, Integrity, Availability → Maßnahmen ableiten

📝❗ FiSi AP2 Konzeption Winter 2024 Aufgabe 2 b bb

Sechs TOM, um E-Mails vor Kompromittierung oder Verlust zu bewahren

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 2 a aa

TOM-Zuordnung: Arbeitssituationen den Schutzzielen Zutritts-, Zugangs- und Zugriffskontrolle zuordnen

📝❗ FiSi AP2 Konzeption Sommer 2025 Aufgabe 2 d

Zwei weitere Maßnahmen der System-Härtung für Server und Clients ergänzen

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 4 b

Drei Schutzmaßnahmen für firmeneigene Notebooks im Außendienst, z. B. TPM, MDM mit Fernlöschfunktion, Härtung des BIOS

📝❗ FiSi AP2 Konzeption Sommer 2022 Aufgabe 4 b

Zwei Änderungen an den Default-Einstellungen zur Betriebssystemhärtung des Fileservers erläutern

Grundschutz-Methodik, Schutzbedarfsanalyse, Grundschutz-Check und Risikoanalyse

• IT-Grundschutz-Methodik
  • Basis-, Kern-, Standardabsicherung
  • Ablauf Standard-Absicherung
• Schutzbedarfsanalyse
• IT-Grundschutz-Check
• Risikoanalyse

💻 Interaktive Übung zu Strukturanalyse und Schutzbedarfsfeststellung am Beispiel „Mail“

💻 Gruppenarbeit „Risikoanalyse“ → IT-Grundschutz (vereinfacht) mittels Vorlage für Praxisprojekt an eigenem Beispiel

📝❗ FiSi AP2 Konzeption Winter 2025 Aufgabe 2 c

IT-Sicherheits-Anforderungen an die Datenbank: zu jeweils drei Anforderungen eine geeignete Maßnahme nennen — Datenschutzbeauftragter, Zugriffsschutz, Nachvollziehbarkeit, Verfügbarkeit

Schutzbedarfsanalyse

-> Vorgehen siehe LF4

Beispiel: „SSO Homeserver“

Ausgangslage

Sie betreiben im eigenen Haushalt einen Homeserver. Authentik ist der zentrale OIDC-Provider für Nextcloud mit Familienfotos und gemeinsamen Dokumenten, ein Wiki mit Haushaltswissen und einen Medienserver. Nutzer sind Sie als Administrator sowie 3–5 enge Familienangehörige oder Mitbewohner; keine Freunde oder Gäste. Der Server ist nur im LAN und über VPN erreichbar, nicht öffentlich aus dem Internet. Smart-Home- oder Safety-Systeme hängen nicht daran. Der Admin-Zugang ist mit MFA geschützt, Backups sind vorhanden.

Zielobjekt

Authentik-Instanz einschließlich Admin-Konten, Benutzerdatenbank, OIDC-Client-Secrets, Signaturschlüssel und Sessions.

Schadensfall

Ein Angreifer erlangt Admin-Zugriff oder erbeutet Signaturschlüssel beziehungsweise Client-Secrets. Dann kann er Tokens für beliebige Nutzer ausstellen oder sich als Nutzer ausgeben. Alternativ fällt Authentik aus; dann sind keine neuen SSO-Anmeldungen möglich.

Aufgabenstellung

Bewerten Sie den Schutzbedarf des Zielobjekts für die Schutzziele Vertraulichkeit (C), Integrität (I) und Verfügbarkeit (A).

Gehen Sie dabei so vor:

1. Betrachten Sie die sechs Schadensszenarien aus der Maßstabstabelle.
2. Wählen Sie für jedes Schadensszenario und jedes Schutzziel eine Kategorie: normal, hoch oder sehr hoch.
3. Begründen Sie jede Einstufung mit der möglichen Schadenswirkung auf das Zielobjekt.
4. Ermitteln Sie anschließend den Gesamtschutzbedarf je Schutzziel nach dem Maximumprinzip.

Hinweis: Der Schutzbedarf beschreibt die mögliche Schadenshöhe, nicht die Eintrittswahrscheinlichkeit. Es gibt nicht die eine richtige Lösung; entscheidend ist eine nachvollziehbare Begründung.

Maßstab: Schutzbedarfskategorien

Vorlage

Musterlösung

Crypto & Auth

Der Unterrichtsblock “Crypto & Auth” beinhaltet die folgenden Themenkomplexe:

Grundlagen

• Überleitung vom Datenschutzrecht und organisatorischen Maßnahmen zu TOM
• Wiederholung Krypto-Grundlagen
  • symmetrische vs. asymmetrische Kryptographie
  • Hashes
• Überblick Authentifizierung
  • Passwörter, 2FA/MFA
  • ACL
• Ausblick: Schlüsselaustausch-Problem

💻 Praxis: /etc/shadow, chmod, SSH-Keys

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 2

Zuordnungsaufgabe: Schutzmaßnahmen wie Datenträger verschlüsseln und Berechtigungskonzept auf Dateiebene den Schutzzielen Zutritts-, Zugangs- und Zugriffskontrolle zuordnen

📝❗ FiSi AP2 Konzeption Sommer 2022 Aufgabe 3

Kamera-Vergleichstabelle: Verschlüsselungsmethode (WEP, WPA, WPA2, WPA3) und „passwortgeschützter Zugriff“ als Auswahlkriterium

Verschlüsselung und Signaturen

• Verschlüsselung unterscheiden: Datenträger-, Transport-, Ende-zu-Ende
• Hybride Verschlüsselung
• Signaturen und Schlüsselaustausch
  • PKI vs. Web-of-Trust
  • CA, X.509 → SSL/TLS

💻 Praxis: PGP/GPG

💻 Praxisprojekt: TLS

📝❗ FiSi AP2 Analyse Sommer 2024 Aufgabe 2 ca–cc

Mailclient per Telnet-Analyse konfigurieren: Protokoll, Verbindungssicherheit (STARTTLS vs. SSL/TLS) und Authentifizierungsmethode wählen

📝❗ FiSi AP2 Konzeption Winter 2024 Aufgabe 2 d

X.509-Personalzertifikate: zwei Eigenschaften nennen; Signierung und Verschlüsselung von Mails gemäß Unternehmensregelung

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 3

Browser-Fehler ERR_CERT_AUTHORITY_INVALID: Das Serverzertifikat gilt nicht als vertrauenswürdig — Ursache und Behebung

📝❗ FiSi AP2 Analyse Winter 2024 Aufgabe 4

SSL/TLS-Inspection an der NGFW: Man-in-the-Middle-Mechanik, Vor- und Nachteile, rechtliche Maßnahme, Intermediat-CA und Behebung der Browser-Fehler SEC_ERROR_UNKNOWN_ISSUER und BEHAVIOR_CHANGED

📝❗ FiSi AP2 Analyse Sommer 2025 Aufgabe 3 b

VPN-Produktentscheidung: X.509-Zertifikate für gegenseitige Authentifizierung versus hinterlegte Public-Keys; Relevanz hardware-unterstützter Krypto-Algorithmen

Authentifizierung und Authorisierung

• Authentifizierung und Autorisierung
  • relevante TOMs raussuchen, unterscheiden, erklären
• Passwörter
• Dateiberechtigungen (ACL)
• SSO
  • SAML, OAuth2, OIDC
  • RADIUS, EAP

💻 Praxis: FastAPI-Security, Keycloak/Authentik/Authelia

📖 PV Aktuell SI AP2 2.8.17

SSO (SAML, OAuth2, OpenID Connect)

📝❗ FiSi AP2 Analyse Winter 2025 Aufgabe 2 da–db

Passwort-Policy der VPN-Nutzer um zwei Regeln für sicherere Passwörter ergänzen; Multi-Faktor-Authentifizierung: zwei weitere Methoden neben Passwort

📝❗ FiSi AP2 Analyse Sommer 2025 Aufgabe 4 ab–ac

IoT-WLAN: Begriffe Authentifizierung und Vertraulichkeit erklärt, je ein Beispiel wie WPA 1/2/3 sie realisieren

📝❗ FiSi AP2 Analyse Sommer 2024 Aufgabe 4 aa–ab

WPA2-Personal im Unternehmens-WLAN: drei Nachteile dieser Verschlüsselungsmethode und eine Möglichkeit zur Verbesserung

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 2 ab–ac

RADIUS (AAA) versus PSK am WLAN-Controller: Bedeutung der drei A-Komponenten und zwei Vorteile von RADIUS AAA

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 2 bc

Fremde Endgeräte an den Netzwerkdosen verhindern: technische Möglichkeit beschreiben — RADIUS-Gerätedatenbank, IEEE 802.1X, Port-Security

Wiederholung

📝❗ FiSi AP2 Konzeption Sommer 2025 Aufgabe 2 f

Passwort- und Benutzersicherheit als Testbereich eines Sicherheits-Dienstleisters im Zero-Trust-Kontext

Grundlagen

🧠 Tagesziel: Wir verstehen, welche TOM für Vertraulichkeit und Integrität dringend erforderlich sind, um:

a) Daten auf einem Endgerät abzusichern

b) Daten zwischen „Sender“ und „Empfänger“ zu übermitteln

TOM

-> 14 „Anforderungen an die Sicherheit der Datenverarbeitung“ nach § 64 BDSG

-> Wiederholung: Endgerätesicherheit, SYS.2.1 „Allgemeiner Client“

Authentifizierung vs Autorisierung

📝❗ FiSi AP2 Konzeption Sommer 2024 Aufgabe 2

Zuordnungsaufgabe: Schutzmaßnahmen wie Datenträger verschlüsseln und Berechtigungskonzept auf Dateiebene den Schutzzielen Zutritts-, Zugangs- und Zugriffskontrolle zuordnen

💬❓ Welche Maßnahmen zur Authentifizierung und Autorisierung kennen Sie?

-> Methoden der Authentisierung (Authentifizierung)

📝❗ FiSi AP2 Analyse Winter 2025 Aufgabe 2 da+db

Passwortpolicy und zwei weitere Authentifizierungsmethoden (neben Wissen) für MFA

Verschlüsselung

-> Grundlagen aus LF4

Nach Einsatzzweck

Lokal:

• Datenträgerverschlüsselung -> z.B. Bitlocker, Veracrypt, LUKS/cryptsetup
• Dateiverschlüsselung -> z.B. GPG

Übertragung:

• Transportverschlüsselung -> z.B. TLS
• Ende-zu-Ende-Verschlüsselung (E2E) -> z.B. GPG

🎨 Tafelbild: Transportverschlüsselung vs E2E — Strukturanalyse Mail

Nach Verfahren:

• Symmetrisch -> z.B. AES, One-time pad
• Asymmetrisch -> z.B. RSA, Elliptic Curve Cryptography
• Hybrid

💬❓ Wie funktionieren Symmetrische und Asymmetrische Verschlüsselungsverfahren?

💬❓ Welche Vor- und Nachteile haben Symmetrische und Asymmetrische Verschlüsselungsverfahren?

Signaturen

💬❓ Was wissen Sie zum Thema Signaturen?

Beschreiben Sie Schutzziel und Funktionsweise.

💬❓ Welche Schlüssel werden bei Asymmetrischer Verschlüsselung und welche für Signaturen verwendet?

Hash-Funktionen

💬❓ Was wissen Sie zum Thema Hash-Funktionen?

Welchen Zweck erfüllen Sie?

In welchem Zusammenhang zu Verschlüsselung und Signaturen stehen Hash-Funktionen?

-> Hashes sind keine Verschlüsselung!

-> Signaturen werden üblicherweise über den Hash der Daten berechnet

💬❓ Welche Anforderungen an kryptografisch starke Hash-Funktionen gibt es?

• feste Länge des Hash-Werts
• Urbildresistenz (Einweg-Funktion): aus dem Hash lässt sich keine Eingabe berechnen
• zweite Urbildresistenz: zu einer bekannten Eingabe kein zweites Dokument mit demselben Hash finden
• Kollisionsresistenz: überhaupt kein Paar verschiedener Eingaben mit demselben Hash finden

„Codierung“

💬❗ Was unterscheidet Codierungen (z.B. base64) von Verschlüsselung?

• keine Schlüssel -> keine Verschlüsselung!

Schlüsselaustausch

💬❓ Was sind die „großen“ Herausforderungen beim korrekten Einsatz von Kryptographie?

Welche Lösungsansätze kennen Sie?

1. Direkter Schlüsselaustausch (z.B. mittels QR-Code)
2. Web-of-trust
3. PKI -> CA

💻 Beispiel: „GPG-Mailverschlüsselung“ via Delta Chat

Zusammenfassung

Um Vertraulichkeit in vernetzten Systemen zu gewährleisten, sind mehrere TOM gemeinsam erforderlich. Welche technischen zusätzlich zu organisatorischen Maßnahmen erforderlich sind, zeigt uns die Strukturanalyse:

• Um die Vertraulichkeit von Daten auf ausgeschalteten Geräten zu gewährleisten, sollten Datenträger vollständig verschlüsselt werden.
• Um Nachrichteninhalte bei der Übertragung zu schützen, hilft Ende-zu-Ende-Verschlüsselung am „einfachsten“ ohne komplizierte Annahmen über die auf dem Transportweg vorhandenen Systeme machen zu müssen.
• Transportverschlüsselung ist ein verbreiteter Kompromiss für Protokolle, die nicht von Anfang an für maximale Vertraulichkeit entwickelt wurden. Sie sollte zusätzlich zu E2E-Verschlüsselung eingesetzt werden, um Metadaten (From, To, Subject, …) auf dem Transportabschnitt zu verschlüsseln.
• Verschlüsselung alleine ist nicht ausreichend. Zutritts-, Zugang- und Zugriffsschutz (Authentifizierung und Autorisierung) muss bei allen beteiligten Systemen angemessen umgesetzt werden. Das gilt für:
  • Laufende datenverarbeitende Systeme — solange Schlüssel im RAM liegen, wäre Verschlüsselung sonst einfach angreifbar.
  • Protokolle zum Datenaustausch müssen Authentifizierung und Autorisierung angemessen umsetzen.
• Das Schlüsselaustausch-Problem ist nicht trivial und auch durch asymmetrische Verschlüsselung alleine nicht gelöst. Lösungen sind möglich und Inhalt der kommenden Unterrichtsstunden.

SSL/TLS

❓❗ Was ist TLS und warum wird es benötigt?

Wie würden Sie TLS im OSI-Modell einordnen?

Grundlagen (TLS 1.2)

❓❗ Wie funktioniert TLS?

📝❗ FiAE AP2 Planung Winter 2022 Aufgabe 4c

📝❗ FiAE AP2 Planung Winter 2022 Aufgabe 1d

📝❗ FiSi AP2 Konzeption Sommer 2026 Aufgabe 2 ab

Ablauf des TLS-Handshakes: Client Hello, Server Hello mit Zertifikat, Zertifikatsprüfung, Schlüsselaustausch, Session Key

sequenceDiagram
    participant Client
    participant Server
    Note right of Client: Kennt Public Keys von Root-CAs
    Client->>Server: Verbindungsanfrage
    Note left of Server: Hat Asymmetrisches Schlüsselpaar
    Note left of Server: Public Key ist via Zertifikatskette von Root-CA unterschrieben
    Server->>Client: Übergabe des Public Keys + Zertifikatskette
    Client->>Client: Überprüfung des Zertifikats mit CA Public Key
    Client->>Client: Generierung AES Session Key *
    Client->>Client: Verschlüsselung des AES Session Key mit dem Public Key des Servers
    Client->>Server: Übertragung des verschlüsselten AES Session Keys
    Server->>Server: Entschlüsselung AES Session Keys
    Server->Client: mit AES Session Key verschlüsselte Datenübertragung

💬❓ Wie würden Sie anhand des TLS 1.2 Sequenzdiagramms „Hybride Verschlüsselung“, sowie „CA“ und „Zertifikat“ erklären?

TLS 1.3

💡 BSI-Empfehlungen für den Einsatz von TLS:

TR-02102-2 „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“ Teil 2 – Verwendung von Transport Layer Security (TLS)

Das obige Diagramm aus der Prüfungsaufgabe zeigt den RSA-Key-Transport und gilt für TLS 1.2 und älter (nur RSA-Cipher-Suiten):

• Der Client erzeugt den Schlüssel und verschlüsselt ihn mit dem Server-Pubkey — ohne Forward Secrecy; deshalb entfernt.
• In TLS 1.2 daneben üblich: (EC)DHE (ServerKeyExchange -> im Diagramm als * markiert).
• In TLS 1.3 nur noch (EC)DHE: Der Schlüssel kommt immer aus dem Diffie-Hellman-Austausch; das Zertifikat/die RSA-Signatur dient nur der Authentifizierung.

sequenceDiagram
    participant Client
    participant Server
    Note right of Client: Kennt Public Keys der Root-CAs
    Client->>Server: ClientHello + key_share
    Server->>Client: ServerHello + key_share
    Note over Client,Server: ab hier verschlüsselt (Handshake-Schlüssel)
    Server->>Client: EncryptedExtensions, Certificate, CertificateVerify, Finished
    Client->>Client: Prüfung der Zertifikatskette und Signatur
    Client->>Server: Finished
    Server->>Client: Application Data
    Note over Client,Server: verschlüsselt (Application-Schlüssel)

Prüfungsaufgaben

📝❗ FiSi AP2 Analyse Sommer 2024 Aufgabe 2 ca–cc

Mailclient per Telnet-Analyse konfigurieren: Protokoll, Verbindungssicherheit (STARTTLS vs. SSL/TLS) und Authentifizierungsmethode wählen

• Implizites TLS verschlüsselt ab dem ersten Byte.
• STARTTLS verschlüsselt eine bestehende Klartext-Verbindung nachträglich: Der Client verbindet erst unverschlüsselt und schaltet dann per STARTTLS-Kommando auf TLS um.
  • Ohne STARTTLS beginnt die Verbindung ungeschützt; Angreifer können die Aushandlung stören (STRIPTLS-Angriff) und auf Klartext zurückdrängen.

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 3

Browser-Fehler ERR_CERT_AUTHORITY_INVALID: Das Serverzertifikat gilt nicht als vertrauenswürdig — Ursache und Behebung

📝❗ FiSi AP2 Analyse Winter 2024 Aufgabe 4

SSL/TLS-Inspection an der NGFW: Man-in-the-Middle-Mechanik, Vor- und Nachteile, rechtliche Maßnahme, Intermediat-CA und Behebung der Browser-Fehler SEC_ERROR_UNKNOWN_ISSUER und BEHAVIOR_CHANGED

Praxis

💻 Zertifikate im Browser untersuchen und Zertifikatsfehler analysieren

💻 In Wireshark den TLS-Handshake nachvollziehen

💡💻 Praxisprojekt: Webserver mit TLS mindestens mit selbstsignierter CA integrieren

💡💻 Man-in-the-middle Proxy für HTTP und HTTPS

PKI, CA, X.509

Public-Key-Zertifikat

❓❗ Was ist ein Public-Key-Zertifikat?

• Bindet einen Public Key an eine Identität (Subject)
• Enthält:
  • Public Key
  • Identität
  • Gültigkeit
  • Signatur einer CA (RFC 5280)
• Der Client prüft die Signatur mit dem Public Key der CA
  • die Kette endet bei einer Root-CA im Trust Store
• Zweck: Authentifizierung des Inhabers und Verteilung seines Public Keys

X.509

Beispiel:

Certificate
  Version:             3
  Serial Number:       01
  Signature Algorithm: sha256WithRSAEncryption
  Issuer:              C=DE, O=schullabor, CN=LF11b-Test-CA
  Validity
    Not Before:        Jan  1 00:00:00 2026 GMT
    Not After:         Jan  1 00:00:00 2027 GMT
  Subject:             C=DE, O=schullabor, CN=example.local
  Subject Public Key Info
    Algorithm:         rsaEncryption
    Public-Key:        (2048 bit)
  X509v3 extensions
    X509v3 Subject Alternative Name:
      DNS:example.local
  Signature Algorithm: sha256WithRSAEncryption
  Signature Value:     ...

Der Abschnitt von Version bis X509v3 extensions wird als tbsCertificate (to be signed) bezeichnet.

❓ Welche Felder hat ein X.509-Zertifikat?

-> RFC 5280 §4.1

• Version, Seriennummer
• Gültigkeit (notBefore / notAfter)
• Issuer und Subject:
  • Land/Region (C)
  • Organisation (O)
  • Gebräuchlicher Name (CN)
• Public Key Info
• Erweiterungen (nur v3), z. B. subjectAltName:
  • DNS:example.local — fehlt der Hostname, meldet der Browser ERR_CERT_COMMON_NAME_INVALID oder SSL_ERROR_BAD_CERT_DOMAIN
  • email:max.mustermann@example.org für Mailverschlüsselung mit S/MIME
• Signaturalgorithmus (einmal innerhalb und einmal außerhalb des tbsCertificate)
• Signatur des Hashes der Inhalte

Dateiformate:

• PKCS#12: verschlüsselter Private Key + Zertifikat (RFC 7292)
• PKCS#10: CSR (vom Antragsteller selbst signiert) (RFC 2986)
• PEM: als Base64-Text (RFC 7468)
• DER: binär

PKI

❓ Was gehört zu einer PKI?

• Bindet Public Keys an Identitäten und „schafft“ damit Vertrauen
• Lebenszyklus: CSR → Ausstellung → Nutzung → Erneuerung → Sperrung
• Kette: Root-CA (selbstsigniert) → Intermediate-CA → Endentitäts-Zertifikat

CA

❓❗ Welche Aufgaben hat eine CA?

• Stellt Zertifikate aus und signiert sie mit ihrem Private Key
• Root-CA: selbstsigniert, ihr Zertifikat steht im Trust Store
• Intermediate-CA: von der Root-CA signiert und stellt Endentitäts-Zertifikate aus (Delegation)
• Sperrung: CRL als Liste oder OCSP online (RFC 5280 §3.3, RFC 6960)
• Ob eine CA vertrauenswürdig ist, entscheidet der Client über seinen Trust Store

S/MIME

❓ Was ist S/MIME?

-> Standard zum Signieren und Verschlüsseln von E-Mails auf Basis von X.509-Zertifikaten (RFC 8551)

• verwendet Zertifikate mit:

  • subjectAltName = email:…
  • extendedKeyUsage = emailProtection

• Signieren: Absender signiert mit seinem privaten Schlüssel, Empfänger prüft mit dem öffentlichen Schlüssel aus dem Zertifikat

• Verschlüsseln: hybrid mit dem öffentlichen Schlüssel des Empfängers (überprüft mittels Zertifikat)

Prüfungsaufgaben

📝❗ FiSi AP2 Konzeption Winter 2024 Aufgabe 2 d

X.509-Personalzertifikate: zwei Eigenschaften nennen; Signierung und Verschlüsselung von Mails gemäß Unternehmensregelung

📝❗ FiSi AP2 Analyse Sommer 2025 Aufgabe 3 b

VPN-Produktentscheidung: X.509-Zertifikate für gegenseitige Authentifizierung versus hinterlegte Public-Keys; Relevanz hardware-unterstützter Krypto-Algorithmen

📝❗ FiSi AP2 Konzeption Sommer 2026 Aufgabe 2 aa

Aufgaben einer Certificate Authority (CA): zwei Aufgaben erläutern, z. B. Identitätsprüfung, Zertifikatsausstellung, Statusverwaltung per CRL/OCSP, Lebenszyklus-Management

Praxis

💻 Eigene CA erstellen (einfach -> vollständig)

Authentifizierung

„Wer sind Sie?“

-> Zugangskontrolle

💡 Der Benutzer weist seine Identität nach (Authentisierung); das System prüft diesen Nachweis (Authentifizierung). „Authentifizierung“ darf als Oberbegriff für den gesamten Vorgang verwendet werden.

(siehe auch BSI TR-03187, Abschnitt 2.1 „Definitionen“)

Faktoren

Die Authentisierung kann auf drei Wegen erfolgen:

• Wissen: PIN, Passwort, Passphrase, …
• Besitz: Schlüssel, Smartcard, Hardware Security Token, …
• Sein: biometrische Merkmale (Fingerabdruck, Iris, Stimme, …)

2FA & MFA

💬❓ Was muss bei der Umsetzung von Multi-Faktor-Authentisierung beachtet werden?

Was sind unabhängige Faktoren?

Wissen

Passwörter / Passphrases

Passwortrichtlinien

📝❗ FiSi AP2 Analyse Winter 2025 Aufgabe 2 da

Passwort-Policy

• Großer Zeichenvorrat (klein+groß+nummern+sonderzeichen) -> viel Zufall
• Passwortlänge
• Keine Wörterbuchwörter
• Kein persönlicher Bezug (Name, Benutzername, Geburtsdatum)
• Unterschiedliche Passwörter für verschiedene Zugänge
• Keine Wiederverwendung / Ableitung ehemaliger Passwörter

💡 Hinweise zum Umgang mit Passwörtern des Landesbeauftragten für Datenschutz und Informationsfreiheit Baden-Württemberg

💡 BSI-Empfehlungen

Passwortmanager

-> Zwingend erforderlich!

Wie will man sonst Passwort-Policies für viele Dienste umsetzen?

💬❓ Welchen Schutzbedarf sehen wir für unsere Passwortmanager?

Welche Lösungen können die Anforderungen erfüllen?

PIN & Fehlbedienungszähler

❓ Unter welchen Bedingungen kann eine kurze PIN zur Authentifizierung eingesetzt werden?

❓ Was ist ein Fehlbedienungszähler?

…Realität…

💡💬 Die häufigsten 4-stelligen PIN-Codes

Besitz

Für Besitzfaktoren sollte möglichst Challenge-Response auf Basis von Schlüsseln eingesetzt werden. Der Schlüssel sollte nicht kopierbar sein — also nicht als bloße Datei, sondern in einem dafür vorgesehenen System (Hardware Security Token, Smartcard, TPM) gespeichert werden. Als zweiter Faktor bietet sich eine Passphrase (Wissen) an, die den Zugriff auf den Schlüssel schützt.

Hardware- und Plattformstandards

• FIDO2-Authenticator — nicht exportierbarer Schlüssel, Domain-Bindung, dafür gebaut.
• TPM 2.0 — Schlüssel im Chip, optional an PCRs/Systemzustand gebunden.
• Secure Enclave / Android Keystore — Plattform-Keystore, Basis für Passkeys.
• PIV — Smartcard-Profil mit PIN, bewährt im Behördenumfeld.
• OpenPGP Card — Smartcard für GPG, Nische, älter.

Schlüssel und Schnittstellen

• SSH-Key — privater Schlüssel im Token/TPM ist ein starker Besitzfaktor; als Datei kopierbar und nur durch eine Passphrase geschützt.
• TLS-Client-Zertifikat (mutual TLS) — X.509-Zertifikat mit privatem Schlüssel, idealerweise im TPM oder Token; der Server prüft Kette, Gültigkeit und Sperrstatus. Typisch für VPN, API und Service-to-Service.
• GPG-/OpenPGP-Schlüssel — privater Schlüssel im Keyring oder auf OpenPGP Card; signiert eine Challenge. Für Login unüblich, für Signaturen und E-Mail verbreitet; Vertrauen über Web of Trust oder eigene Richtlinie.
• PKCS#11 — API für Schlüssel in HSM und Smartcard; ob sie exportierbar sind, bestimmt das Token.

Credential-Protokolle

• FIDO2 / WebAuthn — Challenge-Response pro Domain, phishing-resistent.
• Passkeys — FIDO2-Credential im Plattform-Authenticator, modern und benutzerfreundlich.
• TOTP — zeitbasiertes OTP, weit verbreitet, aber phishbar.
• HOTP — zählerbasiertes OTP, älter; kann desynchronisieren.
• OCRA — challenge-basiertes OTP, vor allem im Banking.
• U2F — Vorgänger von FIDO2, nur Challenge-Response, ohne Passkey-Sync.

Biometrie

❓ Welche Nachteile haben biometrische Merkmale zur Authentifizierung?

SSO

Ziele

• Ein Login für viele Dienste: weniger Passwörter und weniger Reset-Aufwand.
• Zentrale Policy: MFA, Sperren und Rollen an einer Stelle durchsetzen.
• Schnelles Onboarding/Offboarding: ein Konto statt vieler Einzelkonten.
• Einheitliche Identität und Protokollierung über Anwendungen hinweg.

Herausforderungen

• Der Identity Provider (IdP) ist Single Point of Failure und attraktives Angriffsziel.
• Zentrales Abmelden (Single Logout) ist über verschiedene Protokolle schwer.
• Kurze, gebundene und widerrufbare Tokens sind aufwendig; gestohlene Tokens bleiben sonst gültig.
• Ein kompromittiertes Konto öffnet viele Dienste; MFA/FIDO2 und Monitoring sind Pflicht.
• Attribute sammeln Nutzungsdaten beim IdP; Datenschutz und Zweckbindung beachten.

Protokolle

• OpenID Connect (OIDC) — Identitätsschicht auf OAuth 2.0
  • das ID Token (JWT) meldet die Identität
  • Häufige Fehlannahme: OAuth2 authentifiziert nicht — dafür ist OIDC da
  • typisch für Web- und App-SSO
• SAML 2.0 — XML-basiertes SSO zwischen Identity Provider und Service Provider; Assertions tragen Authentifizierung und Attribute
• Kerberos — ticketbasiertes SSO in Active Directory; authentifiziert den Nutzer, die Autorisierung prüft der Dienst selbst

Autorisierung

„Was dürfen Sie?“

-> Zugriffskontrolle

Least Privilege

Least Privilege heißt: Ein Konto, ein Dienst oder ein Prozess bekommt nur die Rechte, die für die konkrete Aufgabe nötig sind — und nur so lange wie nötig. Der Ausgangspunkt ist „Default deny“: erst einmal nichts erlauben und dann gezielt freigeben.

Das begrenzt den Schaden bei einer Kompromittierung, weil ein Angreifer nicht die Rechte des gesamten Systems erbt. Es verhindert außerdem versehentliche Änderungen, macht Rechte prüfbar und ist die Grundlage für Service-Accounts, Datenbankbenutzer, enge sudo-Regeln und Container ohne root.

Umsetzung

• Minimale Zugriffsrechte pro Datei
• Kein unnötiges arbeiten als Administrator
• Getrennete Nutzer für verschiedene Kontexte
• Nur notwendige Gruppenzugehörigkeiten vergeben
• sudo nur für konkrete Befehle einsetzen und /etc/sudoers einschränken
• Je ein eigener unprivilegierter Nutzer pro Dienst
• Delegierte Autorisierung mit minimalen Scopes

ACL

Eine Access Control List (ACL) ist eine Liste von Berechtigungen, die an einem Objekt hängt.

POSIX-ACL

Unter Linux erweitern POSIX-ACLs das klassische Modell aus Eigentümer, Gruppe und Anderen um benannte Benutzer und Gruppen sowie eine Maske; die Permission Bits sind die Kurzform dieser ACL. Eine POSIX-ACL besteht aus der Zugriffs-ACL für das Objekt und optional aus einer Default-ACL, die Verzeichnisse an neu angelegte Inhalte vererben.

klassische Permission Bits

ls -l zeigt zuerst den Typ und danach neun Rechte-Bits: - steht für eine Datei, d für ein Verzeichnis, l für einen symbolischen Link. Die neun Bits bilden drei Blöcke für Eigentümer (Owner), Gruppe (Group) und Andere (Other). r bedeutet Lesen (4), w Schreiben (2), x Ausführen (1); die Summe ergibt den Oktalwert.

Bei Verzeichnissen bedeutet r: Namen auflisten; w: Einträge anlegen und löschen; x: das Verzeichnis betreten. Ohne x kommen Sie auch mit r nicht an die Inhalte.

Über die neun Bits hinaus gibt es setuid (4000) und sticky (1000). setuid sorgt dafür, dass ein Programm mit den Rechten des Dateieigentümers läuft, nicht mit denen des aufrufenden Benutzers; dadurch kann ein Programm gezielt erhöhte Rechte erhalten, ist aber ein Risiko, wenn es unsicher ist. sticky sorgt bei Verzeichnissen dafür, dass nur der Datei-Eigentümer, der Verzeichnis-Eigentümer und root Einträge löschen dürfen.

chmod kann alle neun Bits auf einmal setzen (oktal) oder gezielt einzelne Bits ändern (symbolisch). chmod 640 setzt die vollständigen Rechte; chmod u+x ergänzt nur das Ausführen-Recht für den Eigentümer.

$ ls -l bericht.txt
-rw-r--r-- 1 alice users 4096 20. Okt 10:00 bericht.txt

# Rechte auf 640 setzen
$ chmod 640 bericht.txt
$ ls -l bericht.txt
-rw-r----- 1 alice users 4096 20. Okt 10:00 bericht.txt

$ ls -l start.sh
-rw-r--r-- 1 alice users 1234 20. Okt 10:00 start.sh

# Ausführbar für den Eigentümer machen
$ chmod u+x start.sh
$ ls -l start.sh
-rwxr--r-- 1 alice users 1234 20. Okt 10:00 start.sh

Die umask ist keine Berechtigung, sondern eine Maske für neue Dateien und Verzeichnisse. Sie nennt die Bits, die beim Anlegen weggelassen werden: 022 ergibt 644 bei Dateien und 755 bei Verzeichnissen, 077 ergibt 600 bzw. 700. Rechnerisch ist das Modus & ~umask; bestehende Dateien ändert die umask nicht.

$ umask
0022

# Neue Datei mit der Standard-umask anlegen
$ touch neu.txt
$ ls -l neu.txt
-rw-r--r-- 1 alice users 0 20. Okt 10:05 neu.txt

# umask für die aktuelle Shell ändern
$ umask 077

# Neue Datei mit umask 077 anlegen
$ touch privat.txt
$ ls -l privat.txt
-rw------- 1 alice users 0 20. Okt 10:05 privat.txt

erweiterte ACLs

Die neun Bits reichen nicht, wenn eine einzelne Person Leserecht auf genau eine Datei braucht, zwei Gruppen unterschiedliche Rechte haben sollen, der Webserver-User zugreifen soll, ohne Gruppenmitglied zu werden, oder neue Dateien Gruppenrechte erben sollen.

Mit getfacl lesen Sie die ACL, mit setfacl setzen Sie Einträge. Die mask ist die Obergrenze für benannte Benutzer, benannte Gruppen und group::; sie erscheint in ls -l als Gruppenfeld, und ein + zeigt die erweiterte ACL an.

$ getfacl bericht.txt
# file: bericht.txt
# owner: alice
# group: users
user::rw-
group::r--
other::---

# Lesezugriff für bob ergänzen
$ setfacl -m u:bob:r-- bericht.txt
$ getfacl bericht.txt
# file: bericht.txt
# owner: alice
# group: users
user::rw-
user:bob:r--
group::r--
mask::r--
other::---

$ ls -l bericht.txt
-rw-r-----+ 1 alice users 4096 20. Okt 10:10 bericht.txt

setfacl -x u:bob bericht.txt entfernt einen Eintrag, setfacl -b bericht.txt entfernt die erweiterte ACL. Default-ACLs setzen Sie mit -d; sie gelten nur auf Verzeichnissen und werden an neue Dateien und Unterverzeichnisse vererbt.

# Default-ACL für neue Inhalte setzen
$ setfacl -d -m u:bob:rwx projekt
$ getfacl projekt
# file: projekt
# owner: alice
# group: users
user::rwx
group::r-x
other::---
default:user::rwx
default:user:bob:rwx
default:group::r-x
default:mask::rwx
default:other::---

Die Prüfreihenfolge ist: Eigentümer, benannter Benutzer, Gruppenklasse (alle passenden Gruppen vereinigt und durch die Maske begrenzt), Andere.

RBAC

RBAC (Role-Based Access Control) ordnet Rechte Rollen zu und Personen diesen Rollen. Dadurch wirkt eine Änderung an der Rolle für alle zugeordneten Personen; neue Mitarbeiter bekommen einfach die passende Rolle.

Die Grenzen: In Unix gibt es keine Rollenhierarchie, keine echte Trennung von Aufgaben, Rechte addieren sich bei mehreren Gruppen, und es gibt keine zeitliche Begrenzung.

Unix Gruppen

Unix-Gruppen sind die einfachste Umsetzung von RBAC: Jeder Benutzer hat eine primäre Gruppe und kann Mitglied in weiteren Gruppen sein.

# alice zur Gruppe users hinzufügen
$ sudo usermod -aG users alice
$ id alice
uid=1000(alice) gid=1000(alice) groups=1000(alice),100(users)

# Eigentümer und Gruppe der Datei setzen
$ sudo chown alice:users bericht.txt

# Rechte für Eigentümer und Gruppe setzen
$ sudo chmod 660 bericht.txt
$ ls -l bericht.txt
-rw-rw---- 1 alice users 4096 20. Okt 10:20 bericht.txt

usermod -aG ergänzt eine Gruppe bei einem bestehenden Konto; ohne -a würden andere Zusatzgruppen ersetzt. useradd -G setzt Gruppen nur beim Anlegen eines neuen Kontos; auf Debian ist adduser alice users der bequemere Weg. chown ändert Eigentümer und Gruppe, chgrp nur die Gruppe.

su vs sudo

sudo ist nur dann Least Privilege, wenn die Regel eng ist. NOPASSWD, sudo -i und sudo su - können die Beschränkung aufheben, wenn die sudoers-Regel es erlaubt. Eine enge Regel für eine Admin-Gruppe wäre %admins ALL=(root) /usr/bin/systemctl restart nginx; sie wird mit visudo bearbeitet und erlaubt nur dieses Kommando.

JWT

(JSON Web Token)

• Einordnung: JWT ist ein Token-Format, kein Protokoll und keine Authentifizierung.
• Aufbau: Ein JWT besteht aus Header.Payload.Signatur.
• Kodierung: Alle Teile sind Base64url-kodiert. Das ist keine Verschlüsselung; der Payload ist lesbar.
• Inhalt: Keine Passwörter, Secrets oder unnötige personenbezogene Daten in den Payload schreiben.
• Claims: Wichtige Claims sind iss (Aussteller), sub (Nutzer), aud (Empfänger/API), exp (Ablauf), nbf (nicht vor), iat (ausgestellt) und jti (Token-ID).
• Signatur: HS256 nutzt ein gemeinsames Secret. RS256/ES256 nutzen einen privaten Signaturschlüssel und einen öffentlichen Prüfschlüssel.
• Schlüssel: Bei mehreren Diensten öffentliche Schlüssel über JWKS verteilen und mit kid auswählen.
• Prüfung: Signatur, erlaubten Algorithmus, iss, aud, exp/nbf und bei Bedarf jti und Scopes prüfen.
• Algorithmus: alg: none nie akzeptieren und den Algorithmus nicht ungeprüft aus dem Token übernehmen.
• Bearer-Token: Als Access Token ist ein JWT ein Bearer-Token: Wer es hat, kann die API aufrufen. Kurze Laufzeit und sichere Speicherung sind wichtig.
• Widerruf: Ein JWT bleibt bis exp gültig, wenn es keine Sperrliste oder serverseitige Prüfung gibt.
• JWT oder opakes Token: Signatur des JWT kann lokal geprüft werden; Im Gegensatzt zu “opaken Token” ist keine Überprüfung durch den Autorisierungsserver zwingend.
• OAuth2 und OIDC: Access Tokens können JWT oder opak sein; ID Tokens sind JWT.
  • Token-Rollen: Das ID Token ist für den Client, das Access Token für die API.

OAuth2

OAuth2 ist ein Protokoll für delegierte Autorisierung: Eine App erhält Zugriff auf geschützte Ressourcen, ohne das Passwort des Nutzers zu kennen.

Beteiligt sind Resource Owner (Nutzer), Client (App), Authorization Server (Autorisierungsserver) und Resource Server (z.B. Backend-API).

Der folgende Ablauf heißt Authorization Code Flow:

1. Der Nutzer meldet sich beim Authorization Server an und stimmt der Freigabe der angeforderten Scopes (Berechtigungen) zu.
2. Der Authorization Server gibt einen Authorization Code über den Browser zurück. Der Code ist kurzlebig, einmal verwendbar und allein kein API-Zugang.
3. Der Client tauscht den Code am Token-Endpunkt gegen ein Access Token.
4. Mit dem Access Token ruft der Client den Resource Server auf.

Das Access Token ist ein Bearer-Token und damit der eigentliche Zugangsschlüssel: Wer es besitzt, kann die API aufrufen. Deshalb wird es nicht über den Browser-Redirect zurückgegeben, sondern direkt am Token-Endpunkt ausgegeben; dadurch landet es nicht in URL oder Browserverlauf. Der Code ist dagegen kurzlebig, einmal verwendbar und an den Client, die Redirect-URI und den PKCE-Verifier gebunden.

sequenceDiagram
    participant U as Resource Owner
    participant C as Client
    participant A as Authorization Server
    participant R as Resource Server

    C->>U: 1. Weiterleitung zur Anmeldung
    U->>A: 2. Anmeldung und Zustimmung
    A-->>C: 3. Authorization Code
    C->>A: 4. Code gegen Access Token tauschen
    A-->>C: 5. Access Token
    C->>R: 6. API-Aufruf mit Access Token
    R-->>C: 7. geschützte Daten

💻 Praxis

Resource Server: FastAPI

Authorization Server: Keycloak / Authentik / Authelia

Beispiel Setups

FastAPI wird in allen drei Beispielen als Resource Server verwendet. In den ersten beiden Beispielen übernimmt FastAPI zusätzlich die Rolle des Authorization Server; im dritten Beispiel übernimmt Authentik diese Rolle.

a) FastAPI: Einfaches OAuth2 mit Passwort und Bearer-Token. Das Tutorial nutzt den Password Flow. Der Resource Owner meldet sich mit Benutzername und Passwort direkt an. FastAPI prüft die Zugangsdaten gegen eine feste Benutzerliste und gibt am Token-Endpunkt den Benutzernamen als Access Token zurück. JWT, Ablaufzeit und echte Passwort-Hashes fehlen.

b) FastAPI: OAuth2 mit Passwort (und Hashing), Bearer mit JWT-Token. Das Tutorial nutzt denselben Password Flow, prüft die Passwörter aber mit Argon2. FastAPI stellt ein signiertes JWT mit Ablaufzeit aus und gibt es als Access Token zurück. Bei geschützten Endpunkten prüft FastAPI das Access Token.

c) Authentik + FastAPI. Hier meldet sich der Resource Owner im Browser bei Authentik: OAuth-2.0-Provider (optional per MFA) an und stimmt der Freigabe der Scopes zu. Der Client tauscht den Authorization Code am Token-Endpunkt gegen ein Access Token. FastAPI prüft das Access Token als Resource Server. Der Ablauf ist Authorization Code Flow mit PKCE. Wenn OpenID Connect gewünscht ist, kann Authentic als OIDC-Provider eingesetzt werden.

Die folgende Tabelle zeigt die drei Varianten im Vergleich.

Die folgende Tabelle zeigt die relevanten Unterschiede zwischen dem Einsatz des Authorization Servers als reinem OAuth2-Provider und als OIDC-Provider:

Netzwerksicherheit

Der Unterrichtsblock “Netzwerksicherheit” beinhaltet die folgenden Themenkomplexe:

Routing, NAT, Firewall und DMZ

• Wiederholung Routing
  • NAT
• Firewalls
  • Whitelist-/Blacklist-Strategie
  • Paketfilter, SPI, Application-Layer → NGFW, WAF
• DMZ: Pufferzone zwischen Internet und internem Netz

📝❗ FiSi AP2 Analyse Sommer 2024 Aufgabe 1 aa

Routing-Tabelle am Router vervollständigen: Netze WAN, LAN und DMZ mit Subnetzmaske und Next-Hop bzw. Interface ergänzen

📝❗ FiSi AP2 Analyse Winter 2024 Aufgabe 2 c (ca–cb)

Default-Route am Core-Switch begründen und die notwendige Route in die Tabelle eintragen

📝❗ FiSi AP2 Analyse Winter 2025 Aufgabe 1 a-c

Routingtabelle des Routers in der Zentrale prüfen und für die Kommunikation aller Standorte vervollständigen

📝❗ FiSi AP2 Analyse Sommer 2024 Aufgabe 1 b–ba

DMZ-Server von außen erreichbar machen: am Router einrichten, was dafür erforderlich ist

📝❗ FiSi AP2 Analyse Winter 2024 Aufgabe 2 d

NAT/PAT mit einer einzigen öffentlichen IPv4-Adresse: technische Umsetzung, Vor- und Nachteile

📝❗ FiSi AP2 Analyse Winter 2025 Aufgabe 1 ba–bd

NAT/PAT-Prozess: warum das NAT den Paketinhalt verändert, Tabelle der Abschnitte ergänzen, Trotz TLS-verschlüsselter Verbindung, Portforwarding

📝❗ FiSi AP2 Analyse Sommer 2025 Aufgabe 1 bc

Zwei Eigenschaften einer DMZ nennen

📝❗ FiSi AP2 Analyse Sommer 2025 Aufgabe 3 aa–ac

Stateful Packet Inspection versus Paketfilter unterscheiden, Firewall-Regeln-Tabelle vervollständigen, zwei NGFW-Vorteile gegenüber klassischem Paketfilter

📝❗ FiSi AP2 Analyse Sommer 2026 Aufgabe 2 aa–ac

Router-Aufgaben nennen; Grenzen einer Firewall erklären; SPI und NGFW unterscheiden

📝❗ FiSi AP2 Analyse Sommer 2026 Aufgabe 2 ba–bb

Firewall-Regeln für VPN-Zugriff und internes Netz vervollständigen: Ports 80/443, DNS 53, SMTP 465/587, IMAPS 993, Default Deny

Reverse-Proxy

• Reverse-Proxy: Schutz, Anonymisierung, Caching, Loadbalancing

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 3 ca–cc

Reverse-Proxy anhand von zwei Funktionen für eingehende Anfragen begründen; DMZ und Funktionsweise; Serververteilung zwischen DMZ und internem Netzwerk

VLAN

• Traffic-Trennung, Verkleinerung der Broadcast-Domäne
• L3-Switching, Router-on-a-stick, IEEE 802.1Q
• VLAN-Hopping

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 2 ba–bb

Zwei Vorteile von VLANs beschreiben; die Verbindung zwischen den Switches als Trunk (getaggte Verbindung) einrichten

📝❗ FiSi AP2 Analyse Winter 2025 Aufgabe 3 aa–bc

Zwei Gründe für VLANs; Switchports auf untagged/tagged setzen; Konzept Router-on-a-Stick bzw. One-armed-Router; 802.1Q-Subinterfaces

📝❗ FiSi AP2 Analyse Sommer 2025 Aufgabe 1 ac

Subinterface am Router: warum je VLAN ein logisches Interface auf der physischen LAN-Schnittstelle angegeben wird und was ein Subinterface ist (Router-on-a-Stick)

📝❗ FiSi AP2 Analyse Winter 2024 Aufgabe 1 aa–cb

VLAN-Vorteile, portbasierte versus dynamische VLANs, 802.1Q-Tagging, native VLAN am Trunk und warum es nicht das default VLAN (1) sein sollte, VLAN-Hopping

WLAN

• WLAN: SSID, Broadcast, Enterprise

RADIUS/EAP

• Siehe Authentifizierung und Authorisierung: RADIUS (AAA), EAP, IEEE 802.1X

📝❗ FiSi AP2 Analyse Sommer 2024 Aufgabe 4 ba–cc

WLAN-Kanalplanung 2,4 GHz nach Störung durch neue Accesspoints; Begriffe aus dem WLAN-Scan (SSID, BSSID, Channel, Security, Signal); hidden SSID

📝❗ FiSi AP2 Analyse Sommer 2025 Aufgabe 4 aa

SSID-Broadcast: Funktion und Zweck des öffentlichen Aussendens der SSID

VPN

• VPN
  • TUN/TAP, WireGuard, OpenVPN, IPSec, VXLAN

📝❗ FiSi AP2 Analyse Winter 2025 Aufgabe 2 aa–c

VPN-Typ (Site-to-Site versus Remote-Access) aus dem Netzwerkplan ableiten; zwei Schutzziele von VPN mit IPSec; Troubleshooting: Nutzer ohne VPN-Zugriff

📝❗ FiSi AP2 Analyse Sommer 2022 Aufgabe 1 ca–cc

VPN-Fachbegriff und Erläuterung; Laptop-Konfiguration mit ausschließlich VPN-Traffic (Volltunnel); Adresspool: wie viele VPNs nach RFC 3021 (=/31) berechnen

Zero Trust

📝❗ FiSi AP2 Konzeption Sommer 2025 Aufgabe 2 e

Least-Privilege-Prinzip und Zero-Trust-Prinzip: zu jedem Prinzip eine typische Maßnahme

Wiederholung

📝❗ FiSi AP2 Analyse Winter 2024 Aufgabe 1 d

Switch-Verwaltungszugriff absichern: vier Einstellungen zum Ermöglichen und Absichern des Zugriffs — separates Management-VLAN, HTTPS/SSH, starke Passwörter und 2FA, SNMP, Logging, Firmware-Updates

Ausblick: Testen

• nmap, tcpdump, Wireshark
• MITM-Proxy
• OpenVAS, SIEM

📝❗ FiSi AP2 Konzeption Sommer 2025 Aufgabe 2 f

Netzwerksicherheit als Testbereich eines Sicherheits-Dienstleisters: Penetrationstest durch simulierte Angriffe und Netzwerksicherheitsprüfung — offene Ports und aktive Dienste sowie Firewall- und Routerkonfiguration; dazu Logs auswerten, Malware-Prüfung, Prüfung gemäß Richtlinien und simulierte Social-Engineering-Tests

📝❗ FiSi AP2 Analyse Sommer 2026 Aufgabe 3 a–d

MitM, Monitoring-Port, Wireshark, ARP-Poisoning, Port-Security: Angriff, Indizien im Paketmitschnitt, Configured/Sticky MAC, Port-Deaktivierung

Praxis

Netzwerksicherheit testen

• Schwachstellenanalyse: IST-Analyse → Vergleich mit Soll-Zustand → Risikobewertung
  • Beweisen vs. Testen, Penetrationstests
• Netzwerk-Verkehr sichtbar machen
  • nmap, wireshark, tshark, tcpdump
• MITM-Proxy

Praxisprojekt

• Schutzbedarfs + Risikoanalyse
• Modellierung gemäß IT-Grundschutz
• Vorlage: pdf, odt

Ausblick

• SIEM und XDR, z.B. Wazuh
• Vulnerability Scanne, z.B. OpenVAS
• Computer Forensics, Reverse Engineering
• CTF