msolarczekandClaude Opus 5
c8e6f30a27
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
151 lines
7.8 KiB
Markdown
151 lines
7.8 KiB
Markdown
# ISO/IEC 27001:2022 auf der gemeinsamen Dokumentenbibliothek (Variante A)
|
||
|
||
**Stand:** 2026-08-27 · **Paket:** `seed/isms-vorlagenpaket-v2` (+ `-en`) · **Status:** umgesetzt, ISB-Freigabe offen
|
||
|
||
> **Entscheidung:** Ein Dokumentensatz, zwei Framework-Mappings. Die bestehenden Richtlinien und
|
||
> Verfahren bleiben die einzige Quelle; ISO/IEC 27001 wird als zweites Mapping darübergelegt.
|
||
> Damit ersetzt diese Umsetzung die ursprüngliche Annahme aus `KONZEPT-framework-iso27001.md`
|
||
> (D4: zweites Seed-Paket `seed/isms-iso27001-v1/`).
|
||
|
||
---
|
||
|
||
## 1. Warum nicht zwei Pakete
|
||
|
||
`PolicyDocument` ist über `@@unique([tenantId, code])` eindeutig. Zwei Pakete mit denselben
|
||
Dokument-Codes (`L00`, `R01`…`R14`, `VA-01`…`VA-20`) können in einem Mandanten nicht nebeneinander
|
||
existieren — der zweite Import überschreibt beim Upsert den Inhalt des ersten und archiviert die
|
||
Dokumente, die im anderen Paket fehlen. Für einen Mandanten mit ISO **und** TISAX wäre das Ergebnis
|
||
das Gegenteil der Absicht.
|
||
|
||
Hinzu kommt der fachliche Punkt: Die Umsetzungsbeschreibung („Umsetzung bei {{ORG_NAME}}") ist
|
||
normunabhängig. Wie eine Organisation Berechtigungen vergibt, ändert sich nicht dadurch, ob ISO oder
|
||
VDA ISA danach fragt. Sie zweimal zu pflegen erzeugt Widersprüche.
|
||
|
||
## 2. Aufbau
|
||
|
||
| Bestandteil | Rolle |
|
||
|---|---|
|
||
| `richtlinien/`, `verfahren/` | **gemeinsame** Dokumente — ein Umsetzungstext je Thema |
|
||
| `mapping.json` | Framework-Mapping **VDA ISA 2027** (321 Anforderungen) |
|
||
| `mapping-iso.json` | Framework-Mapping **ISO/IEC 27001:2022** (120 Anforderungen) |
|
||
| `_iso_crosswalk.json` | fachliche Zuordnung ISO-Anforderung → Dokument + Abschnitt (redaktionell) |
|
||
| `_iso_sections.json` / `_iso_sections_en.json` | Texte der ISO-only-Abschnitte (redaktionell, je Sprache) |
|
||
| `_iso_texts_en.json` | englische Anforderungstexte (Struktur bleibt im Crosswalk) |
|
||
| `_generate_iso.py` | erzeugt aus beidem die Dokument-Patches, `mapping-iso.json` und die SoA |
|
||
| `_verify.py` / `_verify_iso.py` | prüfen je eine Framework-Sicht |
|
||
| `Statement-of-Applicability-ISO.md` | SoA-Gerüst mit den Pflichtangaben aus 6.1.3 d) |
|
||
|
||
### Sichtbarkeitssteuerung über Platzhalter
|
||
|
||
Zwei neue Flags in `variables.schema.json` steuern, welche Anforderungssicht ein Mandant sieht:
|
||
|
||
| Flag | Default | Wirkung |
|
||
|---|---|---|
|
||
| `FLAG_FW_TISAX` | `true` | VDA-ISA-Anforderungsblöcke sichtbar |
|
||
| `FLAG_FW_ISO27001` | `false` | ISO-Anforderungsblöcke und ISO-only-Abschnitte sichtbar |
|
||
|
||
Im Dokument sieht das so aus — der Umsetzungstext steht **einmal** und gilt für beide:
|
||
|
||
```markdown
|
||
### 3.2 Sichere Anmeldung
|
||
|
||
*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.5{{/if}}
|
||
|
||
**Anforderung**
|
||
|
||
{{#if FLAG_FW_TISAX}}
|
||
- **[MUSS]** Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt.
|
||
{{/if}}
|
||
{{#if FLAG_FW_ISO27001}}
|
||
- **[ISO A.8.5]** Sichere Authentisierungstechnologien und -verfahren sind einzusetzen.
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 4.1.2 -->
|
||
Die Authentifizierungsverfahren sind risikobasiert ausgewählt … Passwortvorgaben nach BL-IAM-01 …
|
||
```
|
||
|
||
Beide Mappings zeigen mit `impl_anchor` auf denselben Block `IMPL 4.1.2`.
|
||
|
||
## 3. Abdeckung
|
||
|
||
- **120 ISO-Anforderungen:** 27 Klauseln (Kap. 4–10, inkl. 6.3 aus Amd 1:2024) + 93 Anhang-A-Controls
|
||
in der Verteilung 37/8/14/34.
|
||
- **43 Abschnitte** der Bibliothek werden von beiden Frameworks genutzt.
|
||
- **19 ISO-only-Abschnitte** wurden ergänzt, wo VDA ISA kein Gegenstück hat:
|
||
|
||
| Dokument | Neue Abschnitte | ISO-Bezug |
|
||
|---|---|---|
|
||
| L00 | Politik, Ziele, Kommunikation | 5.2, 6.2, 7.4, A.5.1 |
|
||
| R01 | Kontext/Scope · Änderungsplanung · Dokumentenlenkung · Behördenkontakte | 4.1–4.4, 6.3, 7.5.1–7.5.3, A.5.5, A.5.6 |
|
||
| R02 | Datenmaskierung | A.8.11 |
|
||
| R03 | SoA · Betriebliche Planung · Messung · Managementbewertung · CAPA | 6.1.3, 8.1, 9.1, 9.3, 10.1, 10.2 |
|
||
| R05 | Vorgehen bei Verstößen | A.6.4 |
|
||
| R07 | Umgebungsschutz/Versorgung/Verkabelung/Wartung · Clear Desk | A.7.5, A.7.7, A.7.8, A.7.11–A.7.13 |
|
||
| R10 | Bedrohungsinformationen · Betriebsabläufe · Kapazität · Datenabfluss · Zeitsynchronisation | A.5.7, A.5.37, A.8.6, A.8.12, A.8.17 |
|
||
|
||
Die neuen Abschnitte sind ausschließlich über Platzhalter individualisierbar — wie die
|
||
Bestandstexte. Dafür kamen elf Variablen und acht Baseline-Parameter hinzu
|
||
(`BL-OPS-10/11/12`, `BL-NET-03`, `BL-PHY-03/04`, `BL-GOV-02/03`).
|
||
|
||
**Ohne ISO-Bezug** bleibt nur der Abschnitt „Nutzung von KI-/GenAI-Diensten" (eigene Ergänzung) sowie
|
||
die Dokumente `P01` (Prototypenschutz) und `D01` (Datenschutz-Prüfziel) — beides TISAX-spezifisch.
|
||
|
||
## 4. Änderungen am Anwendungscode
|
||
|
||
Zwei Stellen, beide klein und rückwärtskompatibel:
|
||
|
||
1. **`prisma/import-policies.ts`** — der Umsetzungstext wird jetzt über `impl_anchor` aufgelöst
|
||
(`IMPL 4.1.2`), mit Rückfall auf die Anforderungs-ID und auf ein `implementation`-Feld im Mapping.
|
||
*Nebeneffekt:* Das behebt einen Bestandsfehler. Bisher wurde `implMap.get(a.id)` gesucht — die
|
||
Anforderungs-IDs (`4.1.2-M1`) haben aber keinen eigenen IMPL-Block, sodass **alle 321**
|
||
VDA-ISA-Anforderungen mit leerem Umsetzungstext importiert wurden. Sichtbar war das u. a. in der
|
||
Spalte „Umsetzung" unter `/policies` und in der Plattform-Vorlagenverwaltung. Nach der Korrektur
|
||
bleiben 12 leere Einträge (L00 — die Leitlinie hat bewusst keine IMPL-Blöcke).
|
||
2. **`src/lib/policy-render.ts`** — `buildContext` belegt fehlende Framework-Flags vor
|
||
(`FLAG_FW_TISAX = true`, `FLAG_FW_ISO27001 = false`). Ohne das würden Bestandsmandanten, deren
|
||
Vorlagenpaket noch nicht neu importiert wurde, die VDA-ISA-Anforderungsblöcke leer sehen.
|
||
|
||
## 5. Prüfung
|
||
|
||
```bash
|
||
cd seed/isms-vorlagenpaket-v2
|
||
python3 _generate_iso.py # deutsche Fassung, idempotent
|
||
python3 _generate_iso.py --lang en # englische Fassung
|
||
python3 _verify.py # TISAX-Sicht → OK
|
||
python3 _verify_iso.py # ISO-Sicht DE → OK
|
||
python3 _verify_iso.py --lang en # ISO-Sicht EN → OK
|
||
```
|
||
|
||
`_verify_iso.py` prüft Vollständigkeit (27 + 93), Auflösbarkeit aller Anker, nicht leere
|
||
Umsetzungsblöcke, das Rendering **beider** Sichten ohne offene Platzhalter sowie die Verknüpfung zu
|
||
den Verfahren.
|
||
|
||
## 6. Was noch fehlt (Anwendungsseite)
|
||
|
||
Das Paket ist fertig; die Anwendung kennt das zweite Mapping noch nicht. Offen bleibt aus
|
||
`KONZEPT-framework-iso27001.md`:
|
||
|
||
- **Lane 1** — `Framework`-Enum, `TenantFramework`, `framework` an `PolicyTemplateVersion` und
|
||
`PolicyPackageState`. Erst damit lässt sich `mapping-iso.json` überhaupt importieren; heute liest
|
||
`parsePackageFiles` fest `mapping.json`.
|
||
- **Lane 3/4** — ISO-Assessment (Applicability statt Reifegrad) und das **SoA-Modul**. Bis dahin wird
|
||
die SoA als gelenktes Dokument geführt (`Statement-of-Applicability-ISO.md`).
|
||
- **Setzen der Flags** — beim Provisionieren eines ISO-Mandanten müssen `FLAG_FW_ISO27001 = true`
|
||
und, falls kein TISAX, `FLAG_FW_TISAX = false` gesetzt werden.
|
||
|
||
Ebenfalls offen und unabhängig davon: `REVIEW_CYCLE` wird weiterhin für fünf verschiedene Zyklen
|
||
verwendet. Die neuen Abschnitte nutzen bereits die getrennten Variablen
|
||
(`POLICY_REVIEW_CYCLE`, `MGMT_REVIEW_CYCLE`, `RISK_REVIEW_CYCLE`); die Bestandstexte umzustellen ist
|
||
eine eigene, kleine Änderung.
|
||
|
||
## 7. Urheberrechtlicher Hinweis
|
||
|
||
Die ISO-Anforderungstexte in `mapping-iso.json` und in den Dokumenten sind **eigene Paraphrasen**;
|
||
die Referenzen sind exakt, damit in der erworbenen Norm nachgeschlagen werden kann. Wörtliche
|
||
Normzitate sind bewusst unterlassen. Das VDA-ISA-Mapping übernimmt die Anforderungen laut eigenem
|
||
Hinweis in `mapping.json` „1:1 aus ISA" — auch dieser Katalog ist geschützt. Bei der weiteren Pflege
|
||
der gemeinsamen Bibliothek sollte die vorsichtigere Linie des ISO-Mappings die gemeinsame werden
|
||
(vgl. `SPEC.md` §12).
|