05_Anlage IT Security Guide AUSZUG Web-Infrastruktur.pdf

[Seite 1]

Security-Guide für digitale Services

Richtlinie Security für digitale Services

Version 02.95.00

22. M(cid:228)rz 2026

(cid:17)Zufall ist ein Wort ohne Sinn;

nichts kann ohne Ursache existieren.(cid:17)

Philosophisches Taschenw(cid:246)rterbuch Band 6, Artikel Philosophie, Sektion IV (deutsche (cid:220)bersetzung), 1764, Voltaire (1694-1778), eigtl. Fran(cid:231)ois-Marie Arouet, frz. Philosoph u. Schriftsteller

[Seite 2]

Security-Guide KAPITEL 16. SIGNATUREN

Kapitel 16

Signaturen

16.1 Grundlagen

[SOLL] F(cid:252)rdigitaleDokumentegibtesverschiedeneArtenvonSignaturen,diesichnachrechtlicher Verbindlichkeit, Sicherheitsniveau und technischer Umsetzung unterscheiden.

16.2 Signaturtypen f(cid:252)r Dokumente

16.2.1 Einfache elektronische Signatur (EES)

Die EES ist jede Form elektronischer Daten, die zur Unterzeichnung genutzt wird. Zum Beispiel eingescannte Unterschriften, Checkboxen ((cid:17)Ich stimme zu(cid:17)) oder einfache Namen unter E-Mails.

Ziel NiederschwelligeFormzurKenntlichmachungeinerZustimmungoderWillenserkl(cid:228)rung ohne hohen Sicherheitsanspruch.

16.2.2 Fortgeschrittene elektronische Signatur (FES)

Die FES ist eindeutig einer Person zugeordnet, erm(cid:246)glicht ihre Identi(cid:28)zierung und erkennt ˜nderungen am Dokument nach der Signatur. Sie basiert meist auf kryptogra(cid:28)schen Ver- fahren mit pers(cid:246)nlichem Schl(cid:252)ssel.

Ziel H(cid:246)here Beweiskraft und Sicherheit als EES, geeignet f(cid:252)r vertrauliche oder rechtlich relevante Dokumente, z.B. Gesch(cid:228)ftsvertr(cid:228)ge.

16.2.3 Quali(cid:28)zierte elektronische Signatur (QES)

Die QES erf(cid:252)llt alle Anforderungen der FES und basiert zus(cid:228)tzlich auf einem quali(cid:28)zierten Zerti(cid:28)kat einer anerkannten Vertrauensstelle. Sie erfordert eine (cid:252)berpr(cid:252)fte Identi(cid:28)zierung (z.B. eID, VideoIdent).

Vertraulich 106

[Seite 3]

Security-Guide KAPITEL 16. SIGNATUREN

Ziel Rechtsverbindliche digitale Unterschrift mit gleichem Stellenwert wie eine handschrift- liche Unterschrift (cid:21) z.B. f(cid:252)r Beh(cid:246)rden, Gerichte, notarielle Vorg(cid:228)nge.

16.2.4 Digitale Signatur (im engeren technischen Sinn)

Dies ist ein kryptogra(cid:28)sches Verfahren, bei dem mit einem privaten Schl(cid:252)ssel ein Hashwert des Dokuments signiert wird. Es dient prim(cid:228)r der Integrit(cid:228)tspr(cid:252)fung und Authentizit(cid:228)t.

Ziel Nachweis, dass ein Dokument unver(cid:228)ndert ist und vom angegebenen Absender stammt unabh(cid:228)ngig von rechtlicher Verbindlichkeit. Grundlage aller oben genannten Signatu- rarten.

16.2.5 (cid:220)bersicht

16.2.5.1 Dokumente (z.B. PDFs, Vertr(cid:228)ge, Bescheide)

Tabelle 16.1: (cid:220)bersicht Signaturen f(cid:252)r Dokumente

16.2.5.2 E-Mails

Tabelle 16.2: (cid:220)bersicht Signaturen f(cid:252)r E-Mails

Vertraulich 107

[Seite 4]

Security-Guide KAPITEL 16. SIGNATUREN

16.3 spezielle Signaturtypen

16.3.1 Sichtbare vs. unsichtbare Signatur

• Sichtbare Signatur: Unterschriftenfeld mit Name, Datum etc. im PDF.

• Unsichtbare Signatur: In den Metadaten des Dokuments eingebettet und dient der Integrit(cid:228)tspr(cid:252)fung.

16.3.2 Zeitstempel (Timestamp)

• Erg(cid:228)nzung zur Signatur zur Best(cid:228)tigung des genauen Signaturzeitpunkts.

• Besonders wichtig f(cid:252)r Langzeitarchivierung oder gerichtliche Nachweise.

Vertraulich 108

[Seite 5]

Security-Guide KAPITEL 23. WEB-INFRASTRUKTUR

Kapitel 23

Web-Infrastruktur

23.1 Grundlagen

[MUSS] Diese Richtlinie de(cid:28)niert die verbindlichen technischen und organisatorischen Anforderun- gen an die Informationssicherheit und die forensische Handlungsf(cid:228)higkeit f(cid:252)r den Betrieb der Web-Infrastruktur sowie der zugeh(cid:246)rigen Autorensysteme.

AufgrundderEinstufungdesZielsystemsalswesentlicheEinrichtunggem(cid:228)(cid:255)NIS-2-Richtlinie [25] [26] bzw. als Kritische Infrastruktur (KRITIS) [6] ist die Umsetzung des Stands der Technik zwingend. Die Richtlinie adressiert zudem die Anforderungen zur Verarbeitung von Sozialdaten gem(cid:228)(cid:255) (cid:159) 393 SGB V [2] sowie den Schutz besonderer Kategorien perso- nenbezogener Daten gem(cid:228)(cid:255) Art. 9 DSGVO [27].

23.2 Infrastruktur und Digitale Souver(cid:228)nit(cid:228)t

23.2.1 Hosting und Datenresidenz

[SOLL] S(cid:228)mtliche Instanzen der Applikations- und Datenbankebene sowie alle Backup-Systeme m(cid:252)ssen innerhalb der Europ(cid:228)ischen Union (EU) betrieben werden. Der Einsatz von US- amerikanischen Hyperscalern (z.B. AWS, Azure, Google Cloud Platform) ist, ungeachtet desRechenzentrumsstandorts,aufgrunddesKon(cid:29)iktpotenzialsmitdemUSCloudActund der angestrebten digitalen Souver(cid:228)nit(cid:228)t zu vermeiden.

23.2.2 Cloud-Compliance (BSI C5)

[MUSS] Sofern Cloud-Dienste (IaaS, PaaS oder SaaS f(cid:252)r Autorensysteme) zum Einsatz kommen, muss der Anbieter ein g(cid:252)ltiges Testat gem(cid:228)(cid:255) dem BSI Cloud Computing Compliance Cri- teria Catalogue (C5) vorlegen. Dies ist Voraussetzung f(cid:252)r die optionale Verarbeitung von Sozialdaten.

23.2.3 Netzsegmentierung

[MUSS] Die Infrastruktur ist in logisch getrennte Zonen (DMZ, Applikation, Datenhaltung) zu un- terteilen. Der Datenaustausch zwischen den Zonen erfolgt nach dem Prinzip des geringsten Privilegs (Least Privilege) (cid:252)ber zustandsorientierte Firewalls mit einem (cid:17)Default Deny(cid:17)- Regelwerk.

Vertraulich 143

[Seite 6]

Security-Guide KAPITEL 23. WEB-INFRASTRUKTUR

23.3 Applikations- und Schnittstellensicherheit

23.3.1 Web Application Firewall (WAF)

[SOLL] Der Web-Infrastruktur ist eine WAF vorzuschalten. Diese soll das OWASP ModSecurity Core Rule Set (CRS) im Paranoia-Level 2 oder h(cid:246)her anwenden. Ein prozessual de(cid:28)niertes False-Positive-Handling sowie ein kontinuierliches Tuning der Regeln sind sicherzustellen.

23.3.2 Container- und DevOps-Security

[MUSS] Bei Nutzung von Container-Technologien m(cid:252)ssen Images automatisiert auf Schwachstellen (CVE) gepr(cid:252)ft werden. Die Kon(cid:28)guration der Infrastruktur (IaC) ist vor dem Deployment gegen Sicherheits-Best-Practices zu pr(cid:252)fen.

23.3.3 API-Sicherheit

[MUSS] Schnittstellen m(cid:252)ssen eine strikte Validierung von Eingangs- und Ausgangsdaten (In- put/Output Validation) vollziehen. Die Authenti(cid:28)zierung erfolgt (cid:252)ber gesicherte Protokolle (OAuth 2.0, mTLS oder JWT).

23.4 Kryptographie und Identit(cid:228)tsmanagement

23.4.1 Schl(cid:252)sselmanagement (KMS/HSM)

[MUSS] Kryptogra(cid:28)scheSchl(cid:252)sselsindineinemnachFIPS140-2Level3[28]zerti(cid:28)ziertenHardware- Sicherheitsmodul (HSM) oder einem (cid:228)quivalenten Key Management System KMS) zu ver- walten. Eine logische Trennung zwischen Schl(cid:252)ssel- und Datenebene ist zwingend. Master- Keys unterliegen einem j(cid:228)hrlichen Rotationszyklus gem(cid:228)(cid:255) BSI TR-02102-1 [29].

23.4.2 Secrets Management

[MUSS] Die Speicherung von Identit(cid:228)tsmerkmalen, API-Schl(cid:252)sseln oder Datenbank-Credentials im Quellcode ist untersagt. Der Zugri(cid:27) erfolgt (cid:252)ber einen zentralen Secrets-Management- Dienst mit automatisierter Rotation.

23.4.3 Identit(cid:228)tsmanagement und MFA

[MUSS] AdministrativeZugri(cid:27)em(cid:252)ssen(cid:252)bereinenzentralenIdentityProvider(IdP)mittelsphishing- resistenter Multi-Faktor-Authenti(cid:28)zierung (MFA), bevorzugt FIDO2 oder hardwarebasier- te Token, abgesichert werden. F(cid:252)r cloud-basierte Autorensysteme sind ausschlie(cid:255)lich (cid:17)Fe- derated IDs(cid:17) (z.B. EntraID) zu verwenden.

23.5 Datenerfassung und Transfer

23.5.1 Zero-Knowledge-Verschl(cid:252)sselung

[SOLL] Sensible Nutzerdaten aus Formularen sind unmittelbar nach der Erfassung auf Applikati- onsebene asymmetrisch zu verschl(cid:252)sseln (z.B. RSA-4096). Der private Schl(cid:252)ssel verbleibt ausschlie(cid:255)lich in der Sph(cid:228)re des Auftraggebers.

Vertraulich 144

[Seite 7]

Security-Guide KAPITEL 23. WEB-INFRASTRUKTUR

23.5.2 Datentransfer (E-Mail und VPN)

[MUSS] Der Transfer verschl(cid:252)sselter Datenpakete an den Auftraggeber erfolgt via E-Mail. Die be- teiligten Mail-Gateways m(cid:252)ssen eine Transportverschl(cid:252)sselung mittels mTLS oder Forced TLS erzwingen. Optional ist eine Site-to-Site VPN-Verbindung bereitzustellen.

23.6 Detektion, Forensik und Incident Response

23.6.1 SOC-Anbindung und SzA

[MUSS] Der Auftragnehmer implementiert ein System zur Angri(cid:27)serkennung (SzA). Detektierte Sicherheitsereignisse sind in Echtzeit an die de(cid:28)nierte Meldestelle des Auftraggeber-SOC (SecurityOperationsCenter) zu(cid:252)bermitteln.DieWeiterleitungvonRoh-LogsandasSIEM des Auftraggebers ist als Option vorzusehen.

23.6.2 Digitale Forensik

[SOLL] Die Beweissicherung soll den Standards ISO/IEC 27037 [30] und dem BSI Leitfaden Di- gitale Forensik [31] entsprechen. Im Falle eines Sicherheitsvorfalls sind vor invasiven Ma(cid:255)- nahmen (cid:29)(cid:252)chtige Daten (RAM-Dumps) und sektorengenaue Abbilder der Datentr(cid:228)ger (Images) anzufertigen. Die Integrit(cid:228)t ist durch kryptogra(cid:28)sche Hashes und eine l(cid:252)cken- lose Chain-of-Custody-Dokumentation zu wahren.

23.6.3 Logging-Spezi(cid:28)kation

[MUSS] Ereignisprotokollesindmanipulationssicherf(cid:252)rmindestenssechsMonatevorzuhalten.Per- sonenbezogene Daten in Payloads sind vor der Protokollierung zu anonymisieren oder zu entfernen.

23.7 Business Continuity und Schwachstellenmanagement

23.7.1 Verf(cid:252)gbarkeit (SLA)

23.7.1.1 Recovery Time Objective (RTO) [MUSS] Die Wiederherstellung des Gesamtsystems muss innerhalb von 24 Stunden abgeschlossen sein.

23.7.1.2 Recovery Point Objective (RPO) [MUSS] Der maximal zul(cid:228)ssige Datenverlust betr(cid:228)gt 12 Stunden.

23.7.2 Backup-Strategie

[SOLL] Es ist eine 3-2-1-1-Backup-Strategie anzuwenden. Mindestens eine Kopie muss unver(cid:228)n- derbar (Immutable) und o(cid:31)ine (Air-Gapped) vorgehalten werden. J(cid:228)hrliche Wiederher- stellungstests sind zu dokumentieren.

23.7.3 Vulnerability Management und Pentests

[SOLL]

Vertraulich 145

[Seite 8]

Security-Guide KAPITEL 23. WEB-INFRASTRUKTUR

S(cid:228)mtliche Komponenten sind kontinuierlichen Schwachstellenscans zu unterziehen. Kri- tische Schwachstellen m(cid:252)ssen innerhalb von 48 Stunden behoben werden. Ein j(cid:228)hrlicher Penetrationstest durch einen unabh(cid:228)ngigen Dritten ist obligatorisch.

23.8 Meldep(cid:29)ichten gem(cid:228)(cid:255) NIS-2 und KRITIS

DerAuftragnehmeristverp(cid:29)ichtet,erheblicheSicherheitsvorf(cid:228)lleinnerhalbvon24Stunden nach Kenntniserlangung dem Auftraggeber zu melden, um die gesetzliche Fr(cid:252)hwarnp(cid:29)icht gegen(cid:252)ber den Aufsichtsbeh(cid:246)rden zu gew(cid:228)hrleisten.

Vertraulich 146

[Seite 9]

Security-Guide KAPITEL 24. CAPTCHA

Kapitel 24

CAPTCHA

24.1 Grundlagen

CAPTCHA (Abk(cid:252)rzung f(cid:252)r (cid:17)Completely Automated Public Turing test to tell Computers and Humans Apart(cid:17)) ist ein Sicherheitstest im Internet. Auf Deutsch bedeutet der Name: (cid:17)Vollautomatischer (cid:246)(cid:27)entlicher Turing-Test, um Computer und Menschen auseinanderzu- halten.(cid:17)

De(cid:28)nition CAPTCHA ist ein kleiner Test, den nur ein Mensch leicht bestehen soll, w(cid:228)hrend ein Computerprogramm (ein (cid:17)Bot(cid:17)) daran scheitert.

Ziel DaswesentlicheZieleinesCAPTCHAsistdieSicherheiteinerWebsite,indemessicher- stellt, dass eine Aktion von einem Menschen und nicht von einem Computerprogramm (Bot) durchgef(cid:252)hrt wird.

Hinweis Ein CAPTCHA ist im Wesentlichen der (cid:17)T(cid:252)rsteher(cid:17) f(cid:252)r Formulare im Internet.

24.2 Anforderungen

[MUSS] Die Konzeption und Implementierung von CAPTCHA-Verfahren basiert auf einem Kata- log spezi(cid:28)scher Anforderungen. Diese Kriterien zielen darauf ab, eine funktionale Balance zwischendernotwendigenSicherheitsfunktionundderGebrauchstauglichkeitf(cid:252)rdenMen- schen zu etablieren.

• Robustheit gegen(cid:252)ber automatisierten Systemen Ein prim(cid:228)res Ziel eines CAPTCHA ist die zuverl(cid:228)ssige Di(cid:27)erenzierung zwischen menschlichen Nutzern und automatisierten Agenten, sogenannten Bots. Das Ver- fahren muss daher eine signi(cid:28)kante Robustheit gegen(cid:252)ber L(cid:246)sungsversuchen durch Software, insbesondere durch Systeme k(cid:252)nstlicher Intelligenz, aufweisen. Die gestell- te Aufgabe sollte so konzipiert sein, dass sie f(cid:252)r Computerprogramme kognitiv oder technischschwerzuinterpretierenundzul(cid:246)senist,w(cid:228)hrendsief(cid:252)rdenMenschenl(cid:246)s-

Vertraulich 147

[Seite 10]

Security-Guide KAPITEL 24. CAPTCHA

barbleibt.DieE(cid:27)ektivit(cid:228)tderBotAbwehristeinzentralerIndikatorf(cid:252)rdieQualit(cid:228)t des Verfahrens.

• Hohe Benutzerfreundlichkeit (Usability) Parallel zur Sicherheitsfunktion ist die Gebrauchstauglichkeit f(cid:252)r den menschlichen Anwender von erheblicher Bedeutung. Die Interaktion mit dem CAPTCHA sollte den Nutzer(cid:29)uss nur minimal beeintr(cid:228)chtigen. Dies bedingt, dass die Aufgabe f(cid:252)r den Menschen kognitiv einfach und zeitnah zu bew(cid:228)ltigen ist. Verfahren, die eine hohe kognitive Last erzeugen oder viel Zeit beanspruchen, k(cid:246)nnen die Nutzerakzeptanz reduzieren und die Konversionsrate einer Webseite negativ beein(cid:29)ussen.

• Gew(cid:228)hrleistung der Barrierefreiheit Eine wichtige Anforderung ist die Zug(cid:228)nglichkeit des Verfahrens f(cid:252)r Menschen mit unterschiedlichen physischen oder kognitiven Einschr(cid:228)nkungen. Ein CAPTCHA, das ausschlie(cid:255)lich auf visueller Erkennung basiert, schlie(cid:255)t beispielsweise Personen mit Sehbehinderungen aus. Moderne Verfahren sollten daher alternative Modalit(cid:228)ten anbieten, wie etwa auditive Ausgaben (vorgelesene Zi(cid:27)ern oder W(cid:246)rter) oder auf Verhaltensanalysen basierende, unsichtbare Pr(cid:252)fungen, um eine breite Nutzergruppe nicht von der Interaktion auszuschlie(cid:255)en.

• Vollst(cid:228)ndige Automatisierung Die De(cid:28)nition eines CAPTCHA impliziert bereits die vollst(cid:228)ndige Automatisierung des Prozesses. Sowohl die Generierung der Pr(cid:252)fungsaufgabe als auch die Validie- rung der vom Nutzer eingegebenen L(cid:246)sung m(cid:252)ssen serverseitig und ohne menschli- che Intervention erfolgen. Dieser Aspekt stellt die Skalierbarkeit des Verfahrens f(cid:252)r Webanwendungen sicher.

• Performanz und Datenschutz In der praktischen Anwendung werden zus(cid:228)tzlich Anforderungen an die technische Performanz gestellt. Die Integration des CAPTCHA darf die Ladezeiten der Web- seite nicht signi(cid:28)kant verz(cid:246)gern. Des Weiteren ist der Datenschutz von Relevanz. Insbesondere bei verhaltensbasierten Analysen, die Mausbewegungen oder Eingabe- muster protokollieren, m(cid:252)ssen datenschutzrechtliche Bestimmungen, wie die der Da- tenschutz Grundverordnung (DSGVO) in Europa, beachtet werden. Die Erhebung und Verarbeitung von Daten sollte auf das f(cid:252)r die Sicherheitspr(cid:252)fung notwendige Ma(cid:255) beschr(cid:228)nkt sein.

24.3 Moderne CAPTCHA-Verfahren

[SOLL] Die Entwicklung im Bereich der Boterkennung hat zu einer signi(cid:28)kanten Diversi(cid:28)zierung der eingesetzten Pr(cid:252)fverfahren gef(cid:252)hrt. W(cid:228)hrend klassische Interaktionstests an E(cid:27)ektivi- t(cid:228)t verlieren, gewinnen passive Analysemethoden und risikobasierte Modelle zunehmend an Bedeutung. Die E(cid:27)ektivit(cid:228)t moderner Systeme beruht oft auf der intelligenten Kombi- nation verschiedener, im Hintergrund agierender Komponenten. Die folgende Aufstellung gliedert die wesentlichen technischen Ans(cid:228)tze, die aktuell zur Di(cid:27)erenzierung von mensch- lichen Nutzern und automatisierten Systemen dienen.

• Verhaltensbasierte Erkennung Analyse von Mausbewegungen, Tippmustern, Scrollverhalten, Interaktionsgeschwin- digkeit. Bots erzeugen unnat(cid:252)rliche Muster. Bewertung erfolgt unsichtbar im Hinter- grund.

Vertraulich 148

[Seite 11]

Security-Guide KAPITEL 24. CAPTCHA

• Risikobasierte Modelle Ger(cid:228)te-Fingerprinting, IP-Reputation, Browser-Telemetrie, Historie der Sitzung. Bei niedrigem Risiko wird gar kein sichtbares CAPTCHA mehr angezeigt.

• Unsichtbare CAPTCHAs Beispiel: invisible reCAPTCHA v3. Liefert eine numerische Risikobewertung anhand von Nutzerinteraktionen. Nur bei hohem Risiko erfolgt ein Zusatztest.

• Proof-of-Work-Mechanismen Der Client muss eine kleine Rechenaufgabe l(cid:246)sen. Vorteil: hohe H(cid:252)rde f(cid:252)r Massenzu- gri(cid:27)e. Kommt in einigen Privacy-orientierten L(cid:246)sungen vor.

• Herausforderungen mit Kontext Klassisches Bilder- oder Audiocaptcha wird nur noch als Fallback genutzt. Fokus auf Tasks, die schwer zu automatisieren sind (z.B. tempor(cid:228)re visuelle Puzzle).

• Hardware-gebundene Nachweise Nutzung sicherer Umgebungen (Passkeys/WebAuthn) als Nachweis, dass ein echter Benutzer am Ger(cid:228)t sitzt. Entlastet CAPTCHA-Systeme in sensiblen Anwendungen.

• Serverseitige Anomalieerkennung Machine-Learning-Modelle, die Tra(cid:30)c-Muster in Echtzeit auswerten und Botnetz- typische Merkmale erkennen.

Vertraulich 149

[Seite 12]

Security-Guide KAPITEL 25. WEBFORMULARE ALS SERVICE

Kapitel 25

WebFormulare als Service

25.1 Grundlagen

Im Rahmen moderner Webarchitekturen kann die Notwendigkeit bestehen, Formularfunk- tionalit(cid:228)ten an externe Dienstleister auszulagern, anstatt diese auf der eigenen Infrastruk- tur zu betreiben. Ein solches Szenario impliziert die (cid:220)bermittlung und Verarbeitung per- sonenbezogener Daten im Sinne der Datenschutz-Grundverordnung (DSGVO) sowie den potenziellen Transfer sensibler Dateianh(cid:228)nge (cid:252)ber Drittsysteme.

Aus dieser Konstellation ergeben sich spezi(cid:28)sche Anforderungen an die IT-Sicherheit, um die Vertraulichkeit und Integrit(cid:228)t der (cid:252)bertragenen Informationen zu gew(cid:228)hrleisten. Insbe- sondere die Exponierung von Eingabeschnittstellen im (cid:246)(cid:27)entlichen Netz erfordert e(cid:27)ektive Abwehrmechanismen gegen automatisierte Zugri(cid:27)e und Missbrauch (z.B. durch Bots oder Spam-Skripte).

Folglich ist die Implementierung einer CAPTCHA-L(cid:246)sung (Completely Automated Public Turing test to tell Computers and Humans Apart) unabdingbar, die dem aktuellen Stand der Technik entspricht. Veraltete Verfahren bieten oft keinen hinreichenden Schutz gegen moderne maschinelle Lernverfahren.

Vertraulich 150

[Seite 13]

Security-Guide KAPITEL 25. WEBFORMULARE ALS SERVICE

25.2 Exemplarisches Szenario

Zur Scha(cid:27)ung einer fundierten Grundlage wird im folgenden ein exemplarisches Szenario konzipiert,dasalsReferenzmodelldient.DerFokusliegtaufeinemWeb-Formular-Prozess, der zwar in seinem Aufbau als grundlegend betrachtet wird, jedoch die wesentlichen Kern- komponenten und Interaktionen einer typischen Datenerfassung im Webumfeld abbildet und den Datenaustausch beschreibt.

Abbildung 25.1: Exemplarisches Szenario Webformular Servicedienstleister

25.2.1 Web-Formular

[MUSS] Ein Webformular muss klare und eindeutig beschriftete Eingabefelder bereitstellen, Ein- gaben validieren und Fehler nachvollziehbar anzeigen, Daten(cid:252)bertragung ausschlie(cid:255)lich verschl(cid:252)sselt durchf(cid:252)hren, nur notwendige Daten abfragen, manipulationssichere Server- Validierung nutzen, barrierefreie Bedienbarkeit gew(cid:228)hrleisten, missbrauchsrelevante Funk- tionen durch Schutzmechnismen, Rate-Limiting und Captcha absichern und eine zuverl(cid:228)s- sige Verarbeitung sowie sichere Speicherung der (cid:252)bermittelten Informationen garantieren. Dabei sind die Angri(cid:27)svektoren (z.B. Cross Site Scriopting) zu beschreiben und entspre- chende Ma(cid:255)nahmen abzuleiten.

25.2.1.1 Daten [MUSS] Die Verarbeitung von Daten, insbesondere wenn sie personenbezogene Daten im Sinne der Datenschutz-Grundverordnung (DSGVO) umfassen, unterliegt einem fundamentalen rechtlichen und operativen Paradigma: Die erforderlichen Schutzma(cid:255)nahmen sind nicht uniform,sondernm(cid:252)ssensichanderSensibilit(cid:228)tunddemRisikoderjeweiligenInformation orientieren.

25.2.1.2 Datei-Updload [MUSS] Die Funktionalit(cid:228)t des Datei-Uploads (Dateianhang) stellt eine signi(cid:28)kante Erweiterung der reinen Formular-Datenerfassung dar. Sie erm(cid:246)glicht es Anwendern, die strukturiert eingegebenen Daten (Formularfelder) durch unstrukturierte Informationen in Form von Dateien (z.B. Dokumente, Bilder, Nachweise) zu erg(cid:228)nzen.

Vertraulich 151

[Seite 14]

Security-Guide KAPITEL 25. WEBFORMULARE ALS SERVICE

Dieseangeh(cid:228)ngtenDateiensinddatenschutzrechtlichdenFormulardaten(siehe Abschnnitt 25.2.1.2) gleichzusetzen. Sofern sie personenbezogene Daten enthalten, was bei Dokumen- ten wie Lebensl(cid:228)ufen, (cid:228)rztlichen Bescheinigungen oder Antragsunterlagen die Regel ist, unterliegen sie vollumf(cid:228)nglich den Verarbeitungsprinzipien und Schutzanforderungen der Datenschutz-Grundverordnung (DSGVO).

Neben dieser datenschutzrechtlichen Dimension (Schutz der Inhalte) muss die kritische Dimension der Informations- und IT-Sicherheit (Schutz der verarbeitenden Systeme) be- trachtet werden.

Dateiupload-Schnittstellen gelten als exponierte Angri(cid:27)svektoren. Sie k(cid:246)nnen missbraucht werden, um schadhafte Dateien (Malware) in die Systemumgebung einzuschleusen. Be- stimmte Dateiformate bergen ein inh(cid:228)rentes Risiko, da sie die Ausf(cid:252)hrung von Skripten, Makros oder eingebettetem Code (z.B. JavaScript in HTML-Dateien, Makros in O(cid:30)ce- Dokumenten) erm(cid:246)glichen. Solche Dateien k(cid:246)nnen zur Kompromittierung des Servers, zur Infektion nachgelagerter Systeme (wie dem Virenscanner selbst oder internen Laufwerken) oder zur Vorbereitung von Cross-Site-Scripting (XSS)-Angri(cid:27)en genutzt werden.

Um dieser Gef(cid:228)hrdungslage ad(cid:228)quat zu begegnen und der Sorgfaltsp(cid:29)icht zur Sicherung der IT-Systeme nachzukommen (vgl. Art. 32 DSGVO, (cid:17)Sicherheit der Verarbeitung(cid:17)), ist eine restriktive Steuerung der zul(cid:228)ssigen Dateitypen unumg(cid:228)nglich.

Zugelassene Dokumentenformate (Stand: 16.11.2025)

• PDF (statisch, kein eingebettetes JavaScript)

• PNG

• JPG/JPEG

• TXT

25.2.1.3 CAPTCHA [MUSS] Die Bereitstellung (cid:246)(cid:27)entlich zug(cid:228)nglicher Webformulare birgt das inh(cid:228)rente Risiko des Missbrauchs durch automatisierte Skripte, sogenannte (cid:17)Bots(cid:17). Diese autonomen Software- Agenten k(cid:246)nnen Schnittstellen f(cid:252)r diverse illegitime Zwecke nutzen, wie beispielsweise das massenhafte Versenden von Spam-Nachrichten, die Durchf(cid:252)hrung von Credential-Stu(cid:30)ng- Angri(cid:27)en oder die k(cid:252)nstliche (cid:220)berlastung von Back-End-Ressourcen (Denial of Service). Diese Bedrohungslage erfordert die Implementierung spezi(cid:28)scher technischer Abwehrma(cid:255)- nahmen (u.a. CAPTCHA in Abschnitt 24), um die Systemintegrit(cid:228)t zu wahren und die Datenqualit(cid:228)t sicherzustellen.

25.2.2 Start

[SOLL] Nach erfolgreicher Durchf(cid:252)hrung der CAPTCHA-Pr(cid:252)fung beginnt der technische Ablauf zur weiteren Verarbeitung des (cid:252)bermittelten Formulars.

25.2.3 Virenscan

[MUSS] Nach dem Hochladen der Dateien ist eine (cid:220)berpr(cid:252)fung mit einem aktuellen und fachlich freigegebenen Virenscanner erforderlich. Die Pr(cid:252)fung dient der Feststellung, ob sch(cid:228)dliche Inhalte vorliegen, die den weiteren Verarbeitungsprozess oder die nachgelagerten Systeme beeintr(cid:228)chtigen k(cid:246)nnten.

Vertraulich 152

[Seite 15]

Security-Guide KAPITEL 25. WEBFORMULARE ALS SERVICE

25.2.4 Ablehnung

[MUSS] F(cid:228)llt die Virenpr(cid:252)fung negativ aus, ist das gesamte Formular als nicht verarbeitbar einzu- stufen. Der Vorgang ist vollst(cid:228)ndig in den zust(cid:228)ndigen Log-Dateien zu protokollieren. Die weitere Behandlung des Vorfalls liegt im Verantwortungsbereich des fachlich zust(cid:228)ndigen Teams, das geeignete Ma(cid:255)nahmen zur Analyse und Bewertung einzuleiten hat.

25.2.5 Verschl(cid:252)sselung

[MUSS] Die verschl(cid:252)sselte Speicherung der (cid:252)bermittelten Dateien stellt einen grundlegenden Be- standteil der Schutzma(cid:255)nahmen dar. F(cid:252)r die Umsetzung kommen zwei Verfahren in Be- tracht. [KANN] ErstenskanneinesymmetrischeVerschl(cid:252)sselungeingesetztwerden.DiesesVerfahrenerfor- dert jedoch einen sensibel zu verwaltenden Schl(cid:252)ssel, der auf der Internetseite theoretisch unbemerkt kompromittiert werden k(cid:246)nnte. Als Mindestanforderung ist die Verwendung eines AES-256-Verfahrens festgelegt. [SOLL] Zweitens kann eine asymmetrische Verschl(cid:252)sselung genutzt werden. Dieses Verfahren re- duziert die Risiken eines Schl(cid:252)sselab(cid:29)usses, erfordert aber mehr Rechenressourcen sowie ein abgestimmtes und dokumentiertes Schl(cid:252)sselmanagement zwischen Dienstleister und Auftraggeber. Vorgabe ist die Nutzung eines RSA-4096-Schl(cid:252)ssels.

25.2.6 (cid:220)bertragung

[MUSS] Die (cid:220)bertragung der Daten an interne Systeme soll (cid:252)ber ein nachvollziehbares und re- visionssicheres Verfahren erfolgen. Eine weniger geeignete, aber in Einzelf(cid:228)llen genutzte M(cid:246)glichkeit stellt die (cid:220)bermittlung per E-Mail dar, die aufgrund des Protokollstandards keine zuverl(cid:228)ssige Best(cid:228)tigung (cid:252)ber erfolgreiche Zustellung bietet und daher zus(cid:228)tzliche technische Implementierungen (u.a. TLS) erfordert. Zu bevorzugen ist ein automatisierter elektronischer Datenaustausch (cid:252)ber SFTP mit de(cid:28)niertem Quittungsmechanismus.

25.2.7 Entschl(cid:252)sselung

[MUSS] DieEntschl(cid:252)sselungderDatenerfolgtnachdemjeweilsangewendetenVerschl(cid:252)sselungsver- fahren. Der eingesetzte Algorithmus bestimmt die konkreten Schritte des kryptogra(cid:28)schen R(cid:252)ckprozesses.

25.2.8 Virenscan

[MUSS] NachdemEingangderDateniminternenSystemisteineerneuteVirenpr(cid:252)fungvorzusehen. Diese zweite Pr(cid:252)fung dient der Absicherung der internen Infrastruktur und erg(cid:228)nzt die Ma(cid:255)nahmen, die bereits auf der Upload-Strecke durchgef(cid:252)hrt wurden.

25.2.9 Verarbeitung

[SOLL] Die weitere Verarbeitung der Daten richtet sich nach den fachlichen, organisatorischen und regulatorischen Vorgaben des Unternehmens. Die konkrete Ausgestaltung dieses Verarbei- tungsschritts wird im Rahmen dieses Kapitels nicht behandelt.

Vertraulich 153

[Seite 16]

Security-Guide QUELLENVERZEICHNIS

Quellenverzeichnis

[1] ISO/IEC 27001:2022 (cid:21) Information security management systems(cid:21) Requirements, Internationale Norm, ISO/IEC, 2022. besucht am 19. Juni 2025. Adresse: https: //www.iso.org/standard/27001 [2] Sozialgesetzbuch (SGB) F(cid:252)nftes Buch (cid:21) Gesetzliche Krankenversicherung (cid:21) (SGB V). Berlin: Bundesministerium der Justiz, 2025, zuletzt abgerufen am 21.09.2025. Adresse: https://www.gesetze-im-internet.de/sgb_5/ [3] Gesetz zurUmsetzung derNIS-2-Richtlinie undzur Regelung wesentlicherGrundz(cid:252)ge desInformationssicherheitsmanagementsinderBundesverwaltung(NIS-2-Umsetzungs- und Cybersicherheitsst(cid:228)rkungesetz - NIS2UmsuCG), https://www.bmi.bund.de/ SharedDocs/gesetzgebungsverfahren/DE/CI1/nis2umsucg.html, Regierungsent- wurf vom Juli 2024, Gesetzgebungsverfahren l(cid:228)uft (cid:22) Referentenentw(cid:252)rfe und Ka- binettsfassung (Stand Juli 2025) liegen vor; ein Inkrafttreten wird bis Ende 2025 erwartet, 2024. [4] TheEuropeanParliamentandtheCounciloftheEuropeanUnion,(cid:16)Regulation(EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identi(cid:28)cation and trust services for electronic transactions in the internal marketandrepealingDirective1999/93/EC,(cid:17) O(cid:30)cialJournaloftheEuropeanUnion, Regulation L 257/73, Aug. 2014. [5] Gesetz (cid:252)ber das Bundesamt f(cid:252)r Sicherheit in der Informationstechnik (BSI-Gesetz

• BSIG), https://www.gesetze-im-internet.de/bsig_2009/, Zuletzt ge(cid:228)ndert durch Artikel 4 des Gesetzes vom 23. Juni 2021 (BGBl. I S. 1858), 2009. [6] Bundesamt f(cid:252)r Sicherheit in der Informationstechnik (BSI). (cid:16)Erstellung branchen- spezi(cid:28)scher Sicherheitsstandards (B3S).(cid:17) Abgerufen am 02. August 2025, besucht am 2. Aug. 2025. Adresse: https://www.bsi.bund.de/DE/Themen/Regulierte- Wirtschaft/Kritische-Infrastrukturen/KRITIS-FAQ/FAQ-zur-Erstellung- von-B3S/faq-zur-erstellung-von-b3s_node.html [7] (cid:16)Branchenspezi(cid:28)scher Sicherheitsstandard f(cid:252)r gesetzliche Kranken- und P(cid:29)egeversi- cherer (B3S-GKV/PV), Version1.4,(cid:17) GKV Spitzenverband, Berlin, Technischer Be- richt, 2025, Feststellung durch BSI am 09.04.2025, g(cid:252)ltig bis April2028. besucht am

19. Juni 2025. Adresse: https://www.gkv-datenaustausch.de/media/dokumente/ sicherheitsstandard_b3s/B3S_GKV-PV_V.1.4_final.pdf [8] Bundesamt f(cid:252)r Sicherheit in der Informationstechnik, Business Continuity Manage- ment-BSI-Standard200-4.Bonn:BSI,2023,Version2023,abgerufenam02.August2025. besucht am 2. Aug. 2025. Adresse: https://www.bsi.bund.de/SharedDocs/ Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_4.pdf?__blob= publicationFile&v=8 [9] Bundesamtf(cid:252)rSicherheitinderInformationstechnik,IT-Grundschutz-Kompendium, Edition 2023. Bonn: BSI, 2023, Version 2023, abgerufen am 19.Juni2025. besucht

Vertraulich 158

[Seite 17]

Security-Guide QUELLENVERZEICHNIS

am19.Juni2025.Adresse:https://www.bsi.bund.de/SharedDocs/Downloads/DE/ BSI/Grundschutz/IT-GS-Kompendium/IT_Grundschutz_Kompendium_Edition2023. pdf [10] ISO/IEC 22301:2019 (cid:21) Security and resilience (cid:22) Business continuity management systems (cid:22) Requirements, Internationale Norm, ISO/IEC, 2019. besucht am 2. Aug. 2025. Adresse: https://www.iso.org/standard/75106.html [11] ISO/IEC 27035-1:2016 (cid:22) Information technology (cid:22) Security techniques (cid:22) Infor- mation security incident management (cid:22) Part 1: Principles of incident manage- ment, ISO/IEC 27035-1:2016, Geneva: International Organization for Standardizati- on, 2016. [12] S. Bradner, (cid:16)Key words for use in RFCs to Indicate Requirement Levels,(cid:17) The Inter- net Engineering Task Force (IETF), Request for Comments RFC 2119, M(cid:228)rz 1997. doi: 10.17487/RFC2119 Adresse: https://www.rfc-editor.org/info/rfc2119 [13] M. Urlaub, IT-Governance Guide - Richtlinie Governance f(cid:252)r digitale Services, Ver- sion 02.00.00, Richtlinie Security f(cid:252)r digitale Services, KKH - Kaufm(cid:228)nnische Kran- kenkasse, 2025. [14] M. Urlaub, IT-Forensik Guide - Richtlinie Forensik f(cid:252)r digitale Services, Version 02.00.00, Richtlinie Security f(cid:252)r digitale Services, KKH - Kaufm(cid:228)nnische Kranken- kasse, 2025. [15] M. U. Christina Thoma, Schulungsmatrix nach Zielgruppe und Angri(cid:27)svektor, in Awareness. 16. Aug. 2025. [16] K. Kent, M. Souppaya und R. L. Chew, (cid:16)Guide to Integrating Forensic Techniques into Incident Response,(cid:17) National Institute of Standards und Technology, Gaithers- burg, MD, Techn. Ber. SP 800-86, Aug. 2006. doi: 10.6028/NIST.SP.800-86 [17] R. D. Pethia, S. D. Crocker und B. Y. Fraser, (cid:16)A Plan for the C3 Initial Opera- tional Capability for the Computer Emergency Response Team (CERT),(cid:17) Softwa- re Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, Techn. Ber. CMU/SEI-89-TR-10, Juni 1989. [18] I. Alsmadi und M. Zarour, Cybersecurity and Incident Response. Cham: Springer, 2020. [19] AXELOS,ITILfi Foundation, ITIL 4 Edition.London:TheStationeryO(cid:30)ce,2019. [20] E. M. Hutchins, M. J. Cloppert und R. J. Amin, (cid:16)Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains,(cid:17) Lockheed Martin Corporation, Hanover, MD, White Paper, 2011. [21] Date and time (cid:22) Representations for information interchange, International Stan- dard, International Organization for Standardization, 2019. [22] G. Klyne und C. Newman, (cid:16)Date and Time on the Internet: Timestamps,(cid:17) Internet Engineering Task Force (IETF), Request for Comments RFC 3339, 2002. [23] Internet Assigned Numbers Authority (IANA), Time Zone Database, https://www. iana.org/time-zones, Primary source for global time zone de(cid:28)nitions, 2026. [24] Center for Internet Security. (cid:16)CIS Controls.(cid:17) Abgerufen am 19. Juni 2025, besucht am 19. Juni 2025. Adresse: https://www.cisecurity.org/controls [25] Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive), Text with EEA relevance, 14. Dez. 2022. Adresse: https://eur-lex.europa.eu/eli/dir/2022/2555/oj

Vertraulich 159

[Seite 18]

Security-Guide QUELLENVERZEICHNIS

[26] Gesetz(cid:252)berdasBundesamtf(cid:252)rSicherheitinderInformationstechnik(BSIG),Artikel 1desGesetzesvom2.Dezember2025,BGBl.2025INr.301;inKraftseit6.Dezember 2025, 2. Dez. 2025. Adresse: https://www.gesetze-im-internet.de/bsig_2025/ [27] Verordnung (EU) 2016/679 des Europ(cid:228)ischen Parlaments und des Rates vom 27. April 2016 zum Schutz nat(cid:252)rlicher Personen bei der Verarbeitung personenbezoge- ner Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG (Datenschutz-Grundverordnung), 27. Apr. 2016. besucht am 15. Sep. 2025. Adres- se: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX: 32016R0679 [28] National Institute of Standards and Technology, (cid:16)Security Requirements for Crypto- graphic Modules,(cid:17) National Institute of Standards und Technology, Federal Informa- tion Processing Standards Publication 140-2, Mai 2001, FIPS PUB 140-2; includes Security Level 3 as one of four de(cid:28)ned security levels. Adresse: https://doi.org/ 10.6028/NIST.FIPS.140-2 [29] Bundesamt f(cid:252)r Sicherheit in der Informationstechnik, (cid:16)Kryptographische Verfahren: Empfehlungen und Schl(cid:252)ssell(cid:228)ngen,(cid:17) Bundesamt f(cid:252)r Sicherheit in der Informations- technik,TechnischeRichtlinieBSITR-02102-1,Version2026-01,23.Jan.2026,Abge- rufen am 22.03.2026. Adresse: https://www.bsi.bund.de/SharedDocs/Downloads/ DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__ blob=publicationFile [30] International Organization for Standardization und International Electrotechnical Commission, ISO/IEC 27037:2012 (cid:21) Information technology (cid:21) Security techniques (cid:21) Guidelines for identi(cid:28)cation, collection, acquisition and preservation of digital evi- dence, International Standard, ISO/IEC, Geneva, Switzerland, Okt. 2012. [31] Bundesamtf(cid:252)rSicherheitinderInformationstechnik(BSI),(cid:16)Leitfaden(cid:18)IT-Forensik(cid:16),(cid:17) Bundesamtf(cid:252)rSicherheitinderInformationstechnik,Bonn,Leitfaden,2011,Version 1.0. besucht am 29. Juni 2025. Adresse: https://www.bsi.bund.de/SharedDocs/ Downloads/DE/BSI/Publikationen/Leitfaden/Leitfaden_IT-Forensik.pdf?__ blob=publicationFile&v=3

Vertraulich 160