Achse 4: Techniken

OSCAL - Open Security Controls Assessment Language

OSCAL transformiert Compliance-Dokumentation von Word/Excel in maschinenlesbare JSON/YAML-Formate mit vier Schichten:

Catalogs - Kontroll-Definitionen (NIST 800-53, ISO 27001, BSI IT-Grundschutz)
Profiles - organisationsspezifische Baselines
Implementation Layer - System Security Plans, Component Definitions
Assessment Layer - Assessment Results, POA&M

Das BSI dokumentiert offiziell: "OSCAL ist an internationale Standards anschlussfähig". Das GCBoK definiert deutsche Compliance-Taxonomien (GoBD, BSI, DSGVO) als OSCAL-Kataloge - dies existiert am Markt bisher nicht.

OPA / Rego - Policy as Code

Open Policy Agent mit Rego-Sprache. Compliance-Regeln werden als Code implementiert, der automatisch gegen den Git-State geprüft wird.

VPRM - Verifiable Process Reward Model

Im GCBoK-Kontext fungiert OPA/Rego als VPRM: Guardrails für KI-Agenten entstehen durch deterministisches Regelwerk, nicht durch Prompt-Engineering. Damit werden KI-Agenten nicht durch Prompt-Constraints gesichert, sondern durch Code-Validierung.

GPG-Signierung

Jeder Compliance-relevante Git-Commit wird GPG-signiert. Die Signatur bindet:

Identität (GPG-Fingerprint = Akteur)
Inhalt (Commit-Hash = Daten)
Zeitpunkt (Commit-Timestamp = Wann)

Ab .v7g.md-Metadaten werden GPG-Fingerprints an V7GUIDs gebunden - Identitäten bleiben selbst dann falschungssicher, wenn ein KI-Agent die semantische Struktur manipuliert.

GPG-Keyring-Architektur für forensische Nachweisbarkeit

Damit GPG-Signaturen langfristig verifizierbar bleiben — auch Jahre nach Erstellung, nach Schlüsselablauf oder -widerruf, und bei Rekonstruktion aus git bundle/ZIP-Archiven — müssen die öffentlichen Schlüssel Teil des Repositories sein. Das GCBoK definiert dafür ein Keyring-im-Repo-Muster:

Struktur: `.gitcover/keys/`

.gitcover/
├── keys/
│   ├── team-lead.asc          # Öffentliche Schlüssel von Team-Leads
│   ├── service-accounts/      # CI/CD, Bots, Automation
│   └── identities/            # Personenbezogene Schlüssel (nur PII-Repos)
│       ├── person-a.asc
│       └── person-a_governikus.pdf  # Identitätsnachweis pgp.governikus.de
├── trusted-keys.gpg           # Gesammelter Keyring (optional, für Verifier)
└── compliance/                # GoBD/DSGVO-Dokumente

Zwei-Ebenen-Modell: TOP-Repo vs. PII-Repo

Ebene	Repository	Inhalt	DSGVO-Relevanz
Organisatorisch	TOP-Repo (Tenant Organizational Platform)	Team-Lead-Schlüssel, Service-Accounts, CI/CD-Bots, Vertrauensanker `trusted-keys.gpg`	Keine personenbezogenen Daten — DSGVO-konform
Personenbezogen	PII-Repo (Personal Identifiable Information)	Entwickler-Schlüssel, Identitätsnachweise (Governikus-Bestätigungen), personenbezogene GPG-Fingerprints	PII — Zugriff nur über Org-Unit-Claims (siehe unten)

Diese Trennung spiegelt die zwei Verantwortlichkeitsebenen für PII wider:

Legal — Tenant-Ebene (Rechtsträger, z. B. GCC, GCD, CFP)
Organisatorisch — PMO/Divisions/Departments/Locations (≈ AD Organizational Unit)

Verifizierung isoliert vom lokalen Keyring

Ein Prüfer (oder Auditor 10 Jahre später) verifiziert ohne Abhängigkeit vom lokalen GPG-Keyring:

# Nur Repository-Schlüssel nutzen, lokalen Keyring ignorieren
gpg --no-default-keyring --keyring .gitcover/keys/team-lead.asc \
    --verify-commit <commit-hash>

--no-default-keyring: Ignoriert ~/.gnupg/
--keyring: Nutzt ausschließlich den Schlüssel aus dem Repository
Der öffentliche Schlüssel war zum Commit-Zeitpunkt im Repository → forensisch rekonstruierbarer Belegcharakter

Temporale Gültigkeit und Schlüssel-Lifecycle

Die Frage „War die Signatur zum Zeitpunkt des Commits gültig?“ wird durch die Repository-Integration beantwortet:

Der öffentliche Schlüssel liegt in der Git-History des Commits vor
Selbst bei heutigem Schlüsselablauf/-widerruf: Der Commit beweist, dass der Schlüssel damals vertrauenswürdig war
git bundle transportiert Repos inklusive Schlüssel und Nachweisen → portable forensische Einheit, unabhängig von lebender Infrastruktur

Relevanz für GoBD-Verfahrensdokumentation und NIS2

GoBD (§ 146 AO, Verfahrensdokumentation): Die Keyring-Architektur ist Bestandteil der Verfahrensdokumentation — sie beschreibt, wie Identitätsnachweise revisionssicher erzeugt, archiviert und verifiziert werden. Das „Schlüssel-im-Repo"-Muster erfüllt die GoBD-Anforderungen an Nachprüfbarkeit und Unveränderbarkeit der Identitätsbindung.
NIS2 (Zugangsberechtigungen, Art. 21): Die Trennung TOP/PII-Repo und die Org-Unit-basierte Zugriffssteuerung (via OIDC-Claims tenant_id + Org-Unit-Claim) setzen das Prinzip der geringsten Privilegien um. Nur berechtigte Rollen (via Org-Unit-Claim) erhalten Zugriff auf PII-Repos und damit auf personenbezogene Schlüssel.

Siehe auch: Die Artikelserie „GoBD-Verfahrensanweisungen für Git" im GCBoK (Modul 3: Kryptografische Integrität, Modul 4: Signaturen & Authentizität) vertieft diese Themen. Das Forschungsvorhaben GitCover.IdP (BSFZ 288-335-338/2026-1) untersucht die IdP-Integration.

uuidV7 - UUID Version 7

RFC-4122-kompatible UUID Version 7: zeitbasiert, sortierbar, kollisionsresistent. Die GitCover-spezifische Erweiterung um 14-Bit-Klassen-Identifier macht UUIDs zu V7GUIDs (siehe Konzepte).

Git als IdP - Identity Provider

Gitea-basierte Git-Repositories als Single Source of Truth (SSoT) für ein integriertes Identity- und Access-Management-System (IAM). Das BSFZ-anerkannte Forschungsvorhaben untersucht, ob Git-Organisationen/Teams OAuth2-Clients und Permissions abbilden und >1.000 Benutzer performant verwalten können.

Zwei-Ebenen-Verantwortlichkeit für PII (Legal + Organisatorisch)

Personenbezogene Daten (PII) unterliegen im GitCover-Stack einer doppelten Verantwortlichkeit, die sich in der Repository-Architektur und den OIDC-Claims abbildet:

Ebene	Scope	Repository-Typ	OIDC-Claim	Beispiel
1. Legal	Tenant (Rechtsträger)	TOP-Repo + PII-Repo	`tenant_id` (V7GUID-basiert)	`GCC`, `GCD`, `CFP`, `ADA`
2. Organisatorisch	PMO / Division / Department / Location	PII-Repo (feingranular)	`org_unit_id` (≈ AD Organizational Unit)	`GCC-Portfolio`, `GCD-IT`, `CFP-Sales`

Legal (Tenant-Ebene): Der Rechtsträger ist datenschutzrechtlich Verantwortlicher (Art. 4 Nr. 7 DSGVO). Die tenant_id wird deterministisch aus der V7GUID des TOP-Verzeichnisses abgeleitet (siehe [Konzepte: Zentrales Tenant-Register](v7guid-beleg-ketten-und-cryptographic-evidence.html #zentrales-tenant-register)).
Organisatorisch (PMO/Org-Unit): Innerhalb eines Tenants können mehrere Organisationseinheiten (PMOs, Abteilungen, Standorte) eigenständig für Teilmengen von PII verantwortlich sein. Dies entspricht der Struktur von Active-Directory-Organizational-Units. Die Zuordnung erfolgt über den Custom Claim org_unit_id, der in der others.json des Tenants auf Repository-Pfade gemappt wird.

Claim-Hierarchie in der Inlet-Pipeline

Die Inlet-Pipeline (siehe Vorgehensweisen: Mandanten-Isolation liest die others.json je nach User-Claim und injiziert die erlaubten Pfade:

{
  "tenant_id": "0197a3b2-f3c0-7b00-8001-000000000042",
  "org_unit_id": "ORG-1-Portfolio",
  "allowed_repos": [
    "TOP",
    "PII/ORG-1-Portfolio"
  ]
}

Damit erhält ein Nutzer mit org_unit_id = ORG-1-Portfolio Zugriff auf das PII-Repo des Portfolios, aber nicht auf PII/ORG-2-IT — selbst bei demselben tenant_id.

Siehe auch: Das Forschungsvorhaben zu GitCover.IdP wird in Forschungsvorh aben beschrieben. Die Keyring-Architektur (TOP vs. PII) ist oben unter „GPG-Keyring-Architektur" beschrieben.