#230: IT-Grundschutz mapping for APP.3.1 and CON.11.1
All checks were successful
All checks were successful
docs/vs-nfd/80-grundschutz-mapping.md against the Edition 2023 texts of both building blocks (fetched from the BSI single PDFs, edition and retrieval date stated; the dropped requirements of APP.3.1 are listed as such, CON.11.1's 18 requirements are all Basis). Every requirement classified as product / operator / n.a.: product rows point at code, configuration and tests (auth+rate limits, upload controls, security headers with the honest HSTS-at-the-proxy split, marking = the whole of M26 under CON.11.1.A7 incl. the answered does-the-marking-carry-a- security-function question); operator rows say what we hand over (copy list, procedures, network plan, SBOMs); n.a. rows are argued via the delimitation statement (no §52 security functions, no built-in remote maintenance). Open requirements point at their closing issues (M27/M28/M29/M32), so the document doubles as the gap list; the never-scheduled external pentest is stated honestly. Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
7fe3ffd936
commit
4d1e0f36c7
@ -192,8 +192,8 @@ nach sich zieht.
|
|||||||
- [x] **Betriebshandbuch**: Installation (inkl. Airgap), Update, Backup/Restore,
|
- [x] **Betriebshandbuch**: Installation (inkl. Airgap), Update, Backup/Restore,
|
||||||
Löschung und Vernichtung, Rollentrennung · 4–5 AT · #229 → `70-betriebshandbuch.md`
|
Löschung und Vernichtung, Rollentrennung · 4–5 AT · #229 → `70-betriebshandbuch.md`
|
||||||
(Airgap-Kapitel verweist auf offene #218–#221)
|
(Airgap-Kapitel verweist auf offene #218–#221)
|
||||||
- [ ] **Zuarbeit IT-Grundschutz** APP.3.1 und CON.11.1, je Anforderung
|
- [x] **Zuarbeit IT-Grundschutz** APP.3.1 und CON.11.1, je Anforderung
|
||||||
„Produkt / Betreiber / nicht anwendbar" · 3–4 AT · #230
|
„Produkt / Betreiber / nicht anwendbar" · 3–4 AT · #230 → `80-grundschutz-mapping.md`
|
||||||
- [x] **Restrisikoliste** mit bewusst offenen Punkten · 1 AT · #231 → `90-restrisiken.md`
|
- [x] **Restrisikoliste** mit bewusst offenen Punkten · 1 AT · #231 → `90-restrisiken.md`
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|||||||
111
docs/vs-nfd/80-grundschutz-mapping.md
Normal file
111
docs/vs-nfd/80-grundschutz-mapping.md
Normal file
@ -0,0 +1,111 @@
|
|||||||
|
# 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 |
|
||||||
Loading…
Reference in New Issue
Block a user