dorfteich/docs/vs-nfd/80-grundschutz-mapping.md

IT-Grundschutz-Zuarbeit: APP.3.1 und CON.11.1 (Issue #230)

Zweck: Die Dokumentationspflicht der Behörde läuft entlang der IT-Grundschutz-Bausteine. Diese Zuarbeit ordnet jede Anforderung der Bausteine APP.3.1 Webanwendungen und Webservices und CON.11.1 Geheimschutz VS-NUR FÜR DEN DIENSTGEBRAUCH (VS-NfD) einer von drei Kategorien zu:

• Produkt — Dorfteich erfüllt die Anforderung selbst; der Eintrag verweist auf Code, Konfiguration oder Test als Beleg.
• Betreiber — die Erfüllung fällt der Plattform/Organisation zu; der Eintrag nennt, was wir übergeben, damit der Betreiber sie erfüllen kann.
• n. a. — nicht anwendbar, mit Argument (nie bloß behauptet).

Offene Punkte verweisen auf das Issue, das sie schließt — die Zuarbeit ist damit zugleich eine Lückenliste.

Baustein-Stände (Anforderungen werden vom BSI revidiert — vor Verwendung gegen die aktuelle Edition abgleichen):

• APP.3.1 Webanwendungen und Webservices, IT-Grundschutz-Kompendium Edition 2023 (Einzel-PDF des BSI, abgerufen 31.07.2026).
• CON.11.1 Geheimschutz VS-NfD, IT-Grundschutz-Kompendium Edition 2023 (Einzel-PDF des BSI, abgerufen 31.07.2026).

Grundsatzeinordnung vorab: Dorfteich ist bewusst kein IT-Sicherheitsprodukt im Sinne der §§ 51, 52 VSA und erbringt keine Sicherheitsgrundfunktion (ADR 0019, Abgrenzungserklärung 40-abgrenzungserklaerung.md). Wo eine Anforderung ein Produkt „mit Zulassungsaussage" verlangt (Verschlüsselung, VS-Löschung, Fernwartungs-VPN), ist das strukturell Betreibersache — Dorfteich tritt an diesen Stellen absichtlich nicht an. Die Zeilen unten machen das je Anforderung explizit.

Querbezüge: Härtungsleitfaden (50-haertungsleitfaden.md, als Produkt-Beleg referenziert), Sicherheitsdokumentation (60-sicherheitsdokumentation.md), Betriebshandbuch (70-betriebshandbuch.md), Restrisikoliste (90-restrisiken.md).

---

1 APP.3.1 Webanwendungen und Webservices (Edition 2023)

Entfallene Anforderungen der Edition 2023 (A2, A3, A5, A6, A10, A13, A15, A16, A17, A18, A19, A23, A24, A25) werden nicht gemappt.

Basis-Anforderungen

Anforderung	Einordnung	Begründung / Beleg
A1 Authentisierung (B)	Produkt	Geschützte Ressourcen verlangen Session-Authentisierung (default-closed Guards, permissions.md); Grenzwerte für Fehlanmeldungen: Rate-Limit 10/min/IP (rate_limits, security.md §Authentication). Methodenwahl dokumentiert (ADR 0007/0021); Fremdauthentisierung folgt mit M27 (#214–#217).
A4 Kontrolliertes Einbinden von Dateien und Inhalten (B)	Produkt	Upload-Funktion maximal eingeschränkt: Extension-Allowlist (upload.allowedExtensions), Größenlimit (Quota max_file_bytes), Magic-Byte-Prüfung, SVG-Policy, fester Speicherort (uploads-Volume), Berechtigungen über das zentrale Modell; nie inline ausführbar (Download-Disposition + nosniff). Beleg: security.md §Content & upload security, files.e2e.db.test.ts; Referenzwerte im Härtungsleitfaden §1.1.
A7 Schutz vor unerlaubter automatisierter Nutzung (B)	Produkt (+ Betreiber-Anteil)	Rate-Limits: Login 10/min/IP, Signup 5/h/IP, API 100/min/Token (operations.md §Capacity); Feeds als explizit automatisierte Nutzung haben eigenen Schalter und sind in der Referenzkonfiguration aus. Zusätzliche netzseitige Drosselung (Proxy) steht dem Betreiber frei.
A14 Schutz vertraulicher Daten (B)	Produkt	Zugangsdaten serverseitig als Argon2id-Hashes (salted, memory-hard — erfüllt „Salted Hash", security.md §Authentication); Quelltexte sind nicht abrufbar (ausgeliefert wird nur das gebaute SPA-Bundle; Server-Code liegt außerhalb jedes Web-Roots), Secrets nie in der Settings-Tabelle (security.md §Secrets).

Standard-Anforderungen

Anforderung	Einordnung	Begründung / Beleg
A8 Systemarchitektur (S)	Produkt	Sicherheitsaspekte sind Planungsgegenstand: ADR-Reihe (0001–0026), Architektur-Doku, Sicherheitsdokumentation §1–§4; VS-NfD-Spezifika als Security-by-Design in ADR 0019–0026.
A9 Beschaffung (S) [Beschaffungsstelle]	Betreiber (Produkt liefert Beleg)	Die Beschaffungskriterien des Bausteins sind je einzeln belegbar und werden übergeben: Ein-/Ausgabevalidierung (zod-Schemas, sanitisierte Renderer), Session-Management (#190), Kryptoverfahren (Inventar, Abgrenzungserklärung §3), Authentisierung (A1), Zugangsdaten-Speicherung (A14), Berechtigungsmanagement (permissions.md), Protokollierung (audit-events.md v1.1), Sicherheitsupdates (Release-Prozess, operations.md), Schutz vor verbreiteten Angriffen (#189/#197), Quelltext-Zugang: vollständig, MIT-Lizenz.
A11 Sichere Anbindung von Hintergrundsystemen (S)	Produkt (+ Betreiber bei verteiltem Betrieb)	Hintergrundsysteme (PostgreSQL, pandoc, Gotenberg) sind nur über definierte Schnittstellen im internen Docker-Netz erreichbar, ohne Host-Portbindung (Sicherheitsdokumentation §2). Referenzbetrieb ist ein Host — es gibt keine Netz-/Standortgrenzen-Kommunikation; verteilt der Betreiber die Komponenten, fällt ihm Authentisierung/Verschlüsselung dieser Strecken zu.
A12 Sichere Konfiguration (S)	Produkt + Betreiber	Produktseitig: Zugriff nur über vorgesehene Pfade (127.0.0.1-Bindungen, ein Eintrittspunkt), Fehlermeldungen ohne Interna (stabile Fehlercodes statt Stacktraces), Konfiguration außerhalb jedes Web-Roots (.env, Secret-Store-Volume), Grenzwerte (A1/A7), abschaltbare Funktionen mit 404-Semantik. Betreiberseitig: Anwendung des Härtungsleitfadens (nicht benötigte Funktionen deaktivieren — API/MCP/Feeds/Plugins).
A21 Sichere HTTP-Konfiguration (S)	Produkt + Betreiber	Produkt setzt eigene Security-Header-Middleware (#197): Content-Security-Policy (script-src 'self'), X-Content-Type-Options, Content-Type, Cache-Control, X-Frame-Options; Cookies secure, httponly, SameSite (auth.guard). Strict-Transport-Security setzt der TLS-Terminator des Betreibers (Reverse Proxy) — im Produkt wäre der Header wirkungslos, da TLS dort endet.
A22 Penetrationstest und Revision (S)	Betreiber (Produkt liefert Voraussetzungen)	Durchführung/Turnus liegen bei der Institution. Übergeben werden: vollständiger Quelltext, Sicherheitsdokumentation, Test-/CI-Nachweise, Sandbox-Regressionstest, SBOMs (#202) — und der Hinweis, dass die CSP Prüfwerkzeug-Injektion blockt (Playwright mit bypassCSP nutzen, rein lesend). Eine externe Pentest-Kampagne hat bisher nicht stattgefunden (ehrlich offen; kein Issue geplant — Beauftragung ist Betreiber-/Projektentscheidung je Einsatz).

Anforderungen bei erhöhtem Schutzbedarf

Anforderung	Einordnung	Begründung / Beleg
A20 Einsatz von Web Application Firewalls (H)	Betreiber	Eine WAF sitzt vor dem Reverse Proxy in der Plattformzone; die Anwendung übergibt dafür Netzplan und Pfadliste (Sicherheitsdokumentation §2/§3.5).

2 CON.11.1 Geheimschutz VS-NfD (Edition 2023)

Alle 18 Anforderungen sind Basis-Anforderungen; Standard-/erhöhte gibt es in diesem Baustein nicht. Der Baustein richtet sich an die Dienststelle (Geheimschutzbeauftragte) — die Grundhaltung der Zuarbeit ist deshalb: Betreiber erfüllt, Produkt liefert die technischen Beiträge und die Übergabedokumente.

Anforderung	Einordnung	Begründung / Beleg
A1 Grundsätze der VS-Verarbeitung (§§ 3, 4, 6, Anlage V)	Betreiber (Produkt-Beitrag)	Freigabe der VS-IT, Verbot privater IT: organisatorisch. Produkt-Beitrag zu „Kenntnis nur, wenn nötig" technisch: zentrales Permission-Modell, default-closed, deny-wins (permissions.md; 404-Politik versteckt Existenz). Grenze ehrlich benannt: Site-Admin-Bypass (Restrisiko R-09). Mehrschichtigkeit: Prävention (Härtung), Detektion (Audit-Katalog v1.1), Reaktion (fail-closed Integritätsprüfung #199, Runbooks).
A2 VS-IT-Dokumentation (§ 12, Anlage II)	Betreiber (Produkt liefert Bausteine)	Die Dienststelle führt die Geheimschutzdokumentation. Übergeben werden die aktuell gehaltenen Grundlagen: Sicherheitsdokumentation (60-…), Betriebshandbuch (70-…), Härtungsleitfaden (50-…), Restrisikoliste (90-…), SBOMs je Release (#202) — jeweils mit Pflegeregel „im selben PR".
A3 Einsatz von IT-Sicherheitsprodukten (§§ 51, 52)	Betreiber / für das Produkt n. a. (argumentiert)	Kernaussage der Abgrenzungserklärung: Dorfteich übernimmt keine der elf Sicherheitsfunktions-Kategorien des § 52 VSA als Grundfunktion (keine Inhalts-/Backup-Verschlüsselung, kein eigenes MFA, keine Netztrennung …) und ist damit bewusst kein IT-Sicherheitsprodukt, das eine Zulassungsaussage bräuchte. Die Auswahl zugelassener Produkte (BSI-Schrift 7164) für Verschlüsselung, Löschung, Fernwartung fällt dem Betreiber zu. Das anwendungsinterne Berechtigungsmodell ist Ordnung, kein Schutzmechanismus (ADR 0022; Test in #204 pinnt die Invarianz).
A4 Beschaffung von VS-IT (§ 49)	Betreiber (Produkt liefert Beleg)	Vergabeunterlagen/Verträge: Dienststelle. Übergeben werden die Lebenszyklus-Nachweise: Aufbewahrung/Archivierung/Löschung elektronischer VS (Betriebshandbuch §5 mit Kopienliste), Aussonderung (§5), Wartung (§2), SBOM + Lizenzreport, Digest-Pins, MIT-Quelltext. Datenträger-Verbleib bei Rückgabe: Vertrags-/Plattformsache.
A5 Verpflichtung bei Zugang zu VS (§ 4, Anlage V)	Betreiber	Rein organisatorisch (Verpflichtungserklärungen). Produktseitig n. a.; Konten vergibt der Betreiber (Referenzkonfiguration: Registrierung geschlossen).
A6 Beaufsichtigung von Fremdpersonal (§§ 3, 4)	Betreiber	Organisatorisch. Produktseitig n. a.
A7 Kennzeichnung elektronischer VS und Datenträger (§§ 20, 54, Anlagen III/V/VIII)	Produkt (Teilaspekte Betreiber)	Das ist der Kern von M26 (#204–#213, ADR 0022): Kennzeichnung als First-Class-Metadatum, jederzeit erkennbar in Web-Ansicht, Editor, Public-/No-JS-Ansicht, und bleibt erhalten bei Kopie/Versand/Ausdruck: Browser-Druck je Blatt, PDF je Seite, DOCX/ODT in der Kopf-/Fußzeilen-Definition, ZIP mit Frontmatter+Aufdruck+Manifest, Feeds/API/Suche mit Level. Dateiname trägt das Kennzeichen (VS-NfD_-Präfix, #212 — erfüllt das SOLLTE zur Erkennbarkeit ohne Öffnen). Die geforderte Prüfung „übernimmt die elektronische Kennzeichnung IT-Sicherheitsfunktionen?" ist getroffen und dokumentiert: nein — Markierung, nicht Schutz (ADR 0022, per Test gepinnt), daher keine Zulassungsrelevanz. Betreiber-Teile: E-Mail-Kennzeichnung nach Muster 11 (Referenzkonfiguration ohne SMTP; Titel-Unterdrückung M32, R-05) und Kennzeichnung physischer Datenträger.
A8 Verwaltung und Nachweis elektronischer VS (§ 21)	Produkt-Beitrag + Betreiber	VS-NfD verlangt keine Nachweisführung; Verwaltung in offener elektronischer Registratur ist zulässig, sofern „Kenntnis nur, wenn nötig" — genau das leistet das Berechtigungsmodell je Teich/Label/Seite. Aktenführungs-Grundsätze (Registraturrichtlinie): organisatorisch.
A9 Speicherung elektronischer VS (§ 23, Anlage V)	Betreiber	Verschlüsselte Speicherung mit zugelassenem Produkt oder materielle Sicherung: Plattform-/Infrastrukturentscheidung (Volume-/Datenträgerverschlüsselung, gesicherter Serverraum). Dorfteich verschlüsselt bewusst nicht selbst (ADR 0019; Backups unverschlüsselt by design).
A10 Elektronische Übertragung von VS (§§ 24, 53, 55, Anlage V)	Betreiber	Übertragungsverschlüsselung braucht ein Produkt mit Zulassungsaussage — das Anwendungs-TLS am Reverse Proxy ist das ausdrücklich nicht. Der Betreiber stellt zugelassene Leitungs-/Netzverschlüsselung oder geschützte leitungsgebundene Netze; die Anwendung übergibt den Netzplan (Sicherheitsdokumentation §2) und hält alle App-Bindungen host-lokal.
A11 Mitnahme elektronischer VS (§ 28, Anlage V)	Betreiber	Organisatorisch + Endgeräte-Freigabe. Produkt-Bezug offen benannt: die Browser-Offline-Kopie (IndexedDB, R-07) macht jedes Nutz-Endgerät faktisch zu VS-IT — Mitnahme-/Heimarbeitsregeln müssen das Endgerät erfassen.
A12 Archivierung elektronischer VS (§§ 30, 31)	Betreiber (Produkt liefert Schnittstelle)	Absprache mit dem zuständigen Archiv: Dienststelle. Übergabeformate: Markdown-/ZIP-Export mit erhaltener Kennzeichnung und Manifest (#210) als Aussonderungsschnittstelle; ansonsten sichere Löschung nach A13.
A13 Löschung elektronischer VS, Vernichtung (§§ 32, 56, Anlage V)	Betreiber (Produkt liefert Lösch-Landkarte)	VS-konformes Löschen/Vernichten arbeitet auf Datenträgerebene mit zugelassenen Produkten/Verfahren (BSI TL-M 50) — Betreibersache. Die Anwendungs-Löschung ist ausdrücklich kein VS-Löschen; sie liefert aber die vollständige Kopienliste und die Fristen (Betriebshandbuch §5, Sicherheitsdokumentation §5), ohne die eine Datenträger-Löschstrategie unvollständig bliebe.
A14 Zugangs- und Zugriffsschutz (§ 3)	Betreiber + Produkt-Beitrag	Der geforderte Schutz darf über zugelassene Produkte ODER materielle/organisatorische/personelle Maßnahmen erfolgen — Betreiber-Mix. Produkt-Beitrag: Authentisierung + zentrales Berechtigungsmodell (A1/A4-Belege). MFA (SOLLTE) ist bewusst nicht im Produkt (ADR 0019/0021): es kommt über die Fremdauthentisierung der Behörde (IdP, M27 #214–#217) bzw. Plattform; bis M27 gilt R-02.
A15 Handhabung von Datenträgern (§ 54, Anlage V)	Betreiber	Aufbewahrung in verschlossenen Behältern/Räumen: materiell/organisatorisch.
A16 Zusammenschaltung von VS-IT (§ 58)	Betreiber (Produkt liefert Netzplan)	Prüfung und Absicherung von Zusammenschaltungen: Netzarchitektur der Dienststelle. Grundlage seitens des Produkts: vollständiger Netzplan, Vertrauensgrenzen und die Instanz-je-Niveau-Architektur (ADR 0022: eine Instanz pro Einstufungsniveau — es gibt bewusst keine anwendungsinterne Niveau-Mischung).
A17 Wartung und Instandsetzung (§ 3 Abs. 3)	Betreiber (Produkt liefert Prozeduren)	Ort/Beaufsichtigung: organisatorisch. Übergeben: Update-/Rollback-Prozeduren mit Belegstufen (Betriebshandbuch §2), Digest-Pin-Verfahren, geplanter Offline-Update-Pfad (#221, M28).
A18 Fernwartung (§ 3 Abs. 3)	Betreiber / für das Produkt n. a. (argumentiert)	Dorfteich enthält keine Fernwartungsfunktion, keinen Telemetrie- oder Hersteller-Remote-Zugang (einzige Außenverbindungen: SMTP, Backup-Spiegel per Allowlist — Sicherheitsdokumentation §4). Entscheidet sich der Betreiber für Fernwartung der Plattform, sind zugelassene VPN-Produkte und das Fernwartungs-Sicherheitskonzept seine Aufgabe (Baustein OPS.1.2.5).

3 Offene Punkte (Lückenliste)

Punkt	Issue
Fremdauthentisierung/IdP (schließt die MFA- und Kontenführungs-Lücken in APP.3.1.A1 / CON.11.1.A14)	#214–#217 (M27)
Lesetrail für eingestufte Inhalte (stärkt Detektion in CON.11.1.A1)	#222–#225 (M29)
Offline-/Airgap-Pfad (Beschaffungs-/Wartungs-Nachweise CON.11.1.A4/A17)	#218–#221 (M28)
E-Mail-Titel-Unterdrückung (CON.11.1.A7, Mail-Teil)	M32 (#243–#246), Restrisiko R-05
Externe Pentest-Kampagne (APP.3.1.A22)	bewusst kein Issue — Beauftragung je Einsatz durch Betreiber/Projektleitung