Axe 4 : Techniques
OSCAL - Open Security Controls Assessment Language
OSCAL transforme la documentation de conformité de Word/Excel en formats JSON/YAML lisibles par machine, avec quatre couches :
- Catalogs - Définitions de contrôles (NIST 800-53, ISO 27001, BSI IT-Grundschutz)
- Profiles - Baselines spécifiques à l'organisation
- Implementation Layer - System Security Plans, Component Definitions
- Assessment Layer - Assessment Results, POA&M
Le BSI documente officiellement : « OSCAL est compatible avec les normes internationales ». Le GCBoK définit les taxonomies de conformité allemandes (GoBD, BSI, DSGVO) comme catalogues OSCAL - cela n'existe pas encore sur le marché.
Les catalogues OSCAL et les règles OPA font partie de la couche sémantique lisible par machine de l'ontologie GitCover : elles décrivent, dans le même langage que les dictionnaires L1–L6, quelles exigences s'appliquent et comment elles sont vérifiées (voir Concepts : Business-Hierarchie en tant qu'ontologie et Glossaire : Ontologie).
OPA / Rego - Policy as Code
Open Policy Agent avec le langage Rego. Les règles de conformité sont implémentées sous forme de code, qui est vérifié automatiquement par rapport au Git-State.
VPRM - Verifiable Process Reward Model
Dans le contexte du GCBoK, OPA/Rego fonctionne comme VPRM : les garde-fous pour les agents d'IA naissent d'un ensemble de règles déterministe, et non du prompt engineering. Ainsi, les agents d'IA ne sont pas sécurisés par des contraintes de prompt, mais par une validation de code.
Signature GPG
Chaque commit Git pertinent pour la conformité est signé avec GPG. La signature lie :
- Identité (GPG-Fingerprint = acteur)
- Contenu (Commit-Hash = données)
- Moment (Commit-Timestamp = quand)
À partir des métadonnées .v7g.md, les GPG-Fingerprints sont liés aux V7GUIDs - les identités restent à l'épreuve de toute falsification même si un agent d'IA manipule la structure sémantique.
Architecture de keyring GPG pour la traçabilité forensique
Pour que les signatures GPG restent vérifiables à long terme — même des années après
leur création, après expiration ou révocation de la clé, et lors d'une reconstruction à
partir d'archives git bundle/ZIP — les clés publiques doivent faire partie du
dépôt. Le GCBoK définit pour cela un modèle de keyring dans le dépôt :
Structure : .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
Modèle à deux niveaux : TOP-Repo vs. PII-Repo
| Niveau | Dépôt | Contenu | Pertinence DSGVO |
|---|---|---|---|
| Organisationnel | TOP-Repo (Tenant Organizational Platform) | Clés des Team-Leads, Service-Accounts, bots CI/CD, ancre de confiance trusted-keys.gpg |
Aucune donnée à caractère personnel — conforme au DSGVO |
| Personnel | PII-Repo (Personal Identifiable Information) | Clés des développeurs, justificatifs d'identité (confirmations Governikus), GPG-Fingerprints à caractère personnel | PII — accès uniquement via les Org-Unit-Claims (voir ci-dessous) |
Cette séparation reflète les deux niveaux de responsabilité pour les PII :
- Juridique — niveau Tenant (entité juridique, p. ex. GCC, GCD, GCP)
- Organisationnel — PMO/Divisions/Departments/Locations (≈ AD Organizational Unit)
Vérification isolée du keyring local
Un vérificateur (ou un auditeur 10 ans plus tard) vérifie sans dépendance au keyring GPG local :
# 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: ignore~/.gnupg/--keyring: utilise exclusivement la clé du dépôt- La clé publique se trouvait au moment du commit dans le dépôt → valeur probante reconstruisable de manière forensique
Validité temporelle et cycle de vie des clés
La question « La signature était-elle valide au moment du commit ? » trouve sa réponse dans l'intégration au dépôt :
- La clé publique est présente dans l'historique Git du commit
- Même en cas d'expiration ou de révocation actuelle de la clé : le commit prouve que la clé était alors digne de confiance
git bundletransporte les dépôts clés et justificatifs inclus → unité forensique portable, indépendante de toute infrastructure vivante
Pertinence pour la documentation des procédures GoBD et NIS2
- GoBD (§ 146 AO, documentation des procédures) : l'architecture de keyring fait partie de la documentation des procédures — elle décrit comment les justificatifs d'identité sont générés, archivés et vérifiés à l'épreuve des audits. Le modèle « clé dans le dépôt » satisfait les exigences GoBD en matière de vérifiabilité et d'inaltérabilité de la liaison d'identité.
- NIS2 (droits d'accès, Art. 21) : la séparation TOP/PII-Repo et le contrôle
d'accès basé sur les Org-Units (via les OIDC-Claims
tenant_id+ Org-Unit-Claim) mettent en œuvre le principe du moindre privilège. Seuls les rôles autorisés (via l'Org-Unit-Claim) obtiennent l'accès aux PII-Repos et donc aux clés à caractère personnel.
Voir aussi : La série d'articles « Instructions de procédure GoBD pour Git » dans le GCBoK (Module 3 : Intégrité cryptographique, Module 4 : Signatures & Authenticité) approfondit ces thèmes. Le projet de recherche GitCover.IdP (BSFZ 288-335-338/2026-1) étudie l'intégration IdP.
uuidV7 - UUID Version 7
UUID Version 7 compatible RFC 4122 : basée sur le temps, triable, résistante aux collisions. L'extension spécifique à GitCover par des identifiants de classe de 14 bits transforme les UUIDs en V7GUIDs (voir Concepts).
Git comme IdP - Identity Provider
Des dépôts Git basés sur Gitea comme Single Source of Truth (SSoT) pour un système intégré de gestion des identités et des accès (IAM). Le projet de recherche reconnu par le BSFZ étudie si les organisations/équipes Git peuvent représenter des OAuth2-Clients et des permissions et gérer de manière performante > 1 000 utilisateurs.
Responsabilité à deux niveaux pour les PII (Juridique + Organisationnel)
Les données à caractère personnel (PII) sont soumises dans le GitCover-Stack à une double responsabilité, qui se reflète dans l'architecture des dépôts et les OIDC-Claims :
| Niveau | Scope | Type de dépôt | OIDC-Claim | Exemple |
|---|---|---|---|---|
| 1. Juridique | Tenant (entité juridique) | TOP-Repo + PII-Repo | tenant_id (basé sur V7GUID) |
GCC, GCD, GCP, ADA |
| 2. Organisationnel | PMO / Division / Department / Location | PII-Repo (à granularité fine) | org_unit_id (≈ AD Organizational Unit) |
GCC-Portfolio, GCD-IT, GCP-Sales |
- Juridique (niveau Tenant) : l'entité juridique est le responsable du traitement au
sens de la protection des données (Art. 4 Nr. 7 DSGVO). La
tenant_idest dérivée de manière déterministe de la V7GUID du répertoire TOP (voir [Concepts : Registre central des Tenants](v7guid-beleg-ketten-und-cryptographic-evidence.html #zentrales-tenant-register)). - Organisationnel (PMO/Org-Unit) : au sein d'un Tenant, plusieurs unités
organisationnelles (PMOs, départements, sites) peuvent être responsables de manière
autonome de sous-ensembles de PII. Cela correspond à la structure des
Active-Directory-Organizational-Units. L'affectation s'effectue via le
Custom Claim
org_unit_id, qui est mappé dans laothers.jsondu Tenant sur des chemins de dépôts.
Affectation des personnes aux rôles (pont PII) — Travail à fournir
Affectation des personnes aux rôles (pont PII) — Travail à fournir
Les conteneurs de signature GCPN référencent les participants (attendees) comme
Actors (rôle dans le Tenant, fonction dans l'entreprise) et ne mentionnent les
personnes que de manière pseudonymisée (persons.mappings avec référence PII). La
correspondance canonique Personne → Rôles → Org-Units relève du cercle PII
(gitignored) — pour un modèle cohérent de bout en bout, les relations suivantes doivent
encore être élaborées en détail dans le GCBoK :
| Relation | Statut GCBoK | Travail à fournir |
|---|---|---|
| User → Role | Approche (Git-Repo = IdP ; document de signature comme porteur de claims) | Définition des rôles par Tenant (GF, GS-Verwalter, Auditor) comme vocabulaire normatif — analogue à kinds.json/status_flags.json dans l'OSS-Normative-Root |
| Role → Group | Équipes Gitea (Org → Team → Member) | Mapping équipe Gitea ↔ Role ; convention de slug d'équipe + raccordement à others.json (allowed_repos) |
| Group → Org-Unit | L2 Department comme ancre d'Org-Unit (02-konzepte) | Remplir departments.json par Tenant (actuellement AFJD-Master : entries vides) ; convention en clair pour org_unit_id (GCC-Portfolio etc.) |
| Org-Unit → Tenant | Claim à deux niveaux (tenant_id juridique, org_unit_id organisationnel) |
Remplir others.json par TOP-Repo (actuellement vide) ; documenter le mapping des claims dans la Inlet-Pipeline |
| Person (PII) → User | PII-Repo (gitignored) | Schéma PII pour le mapping Personne↔Role (DSGVO : minimisation, référence pseudonymisée comme dans GCPN persons.mappings) |
Liaison : gcpn-container-1.0 → attendees (rôles dans le dossier) →
persons.mappings (référence PII pseudonymisée) → PII-Repo (correspondance
canonique). Jusqu'à leur élaboration, les références pseudonymisées documentées
ici servent de solution transitoire.
Hiérarchie des claims dans la Inlet-Pipeline
La Inlet-Pipeline (voir Procédures : isolation des Tenants
lit la others.json en fonction du User-Claim et injecte les chemins autorisés :
{
"tenant_id": "0197a3b2-f3c0-7b00-8001-000000000042",
"org_unit_id": "ORG-1-Portfolio",
"allowed_repos": [
"TOP",
"PII/ORG-1-Portfolio"
]
}
Ainsi, un utilisateur avec org_unit_id = ORG-1-Portfolio obtient l'accès au
PII-Repo du portfolio, mais pas à PII/ORG-2-IT — même avec le même
tenant_id.
Voir aussi : Le projet de recherche sur GitCover.IdP est décrit dans Projets de recherche. L'architecture de keyring (TOP vs. PII) est décrite ci-dessus sous « Architecture de keyring GPG ».