GitCover Symbol GCBoKGitCover Body of Knowledge

Trục 4: Kỹ thuật

OSCAL - Open Security Controls Assessment Language

OSCAL chuyển đổi tài liệu tuân thủ từ Word/Excel sang các định dạng JSON/YAML đọc được bằng máy với bốn lớp:

  1. Catalogs - Định nghĩa kiểm soát (NIST 800-53, ISO 27001, BSI IT-Grundschutz)
  2. Profiles - các Baseline đặc thù của tổ chức
  3. Implementation Layer - System Security Plans, Component Definitions
  4. Assessment Layer - Assessment Results, POA&M

BSI ghi nhận chính thức: "OSCAL có khả năng kết nối với các tiêu chuẩn quốc tế". GCBoK định nghĩa các phân loại tuân thủ của Đức (GoBD, BSI, DSGVO) thành các danh mục OSCAL - điều này cho đến nay chưa tồn tại trên thị trường.

Các danh mục OSCAL và các quy tắc OPA là một phần của lớp ngữ nghĩa đọc được bằng máy của ontology GitCover: Chúng mô tả bằng cùng một ngôn ngữ với các từ điển L1–L6, những yêu cầu nào được áp dụng và cách chúng được kiểm tra (xem Khái niệm: Phân cấp doanh nghiệp như một ontology và Bảng thuật ngữ: Ontology).

OPA / Rego - Policy as Code

Open Policy Agent với ngôn ngữ Rego. Các quy tắc tuân thủ được triển khai dưới dạng mã, được kiểm tra tự động đối chiếu với Git-State.

VPRM - Verifiable Process Reward Model

Trong bối cảnh GCBoK, OPA/Rego đóng vai trò là VPRM: Guardrails cho các tác nhân AI được hình thành nhờ bộ quy tắc tất định, chứ không phải nhờ Prompt-Engineering. Nhờ vậy, các tác nhân AI không được bảo đảm thông qua Prompt-Constraints mà thông qua xác thực mã.

Ký GPG

Mọi Git-Commit liên quan đến tuân thủ đều được ký GPG. Chữ ký gắn kết:

Kể từ các siêu dữ liệu .v7g.md, GPG-Fingerprint được gắn với V7GUID - danh tính vẫn không thể bị giả mạo ngay cả khi một tác nhân AI thao túng cấu trúc ngữ nghĩa.

Kiến trúc GPG-Keyring cho khả năng chứng minh pháp y

Để các chữ ký GPG có thể xác minh trong dài hạn — kể cả nhiều năm sau khi tạo, sau khi khóa hết hạn hoặc bị thu hồi, và khi tái dựng từ các kho lưu trữ git bundle/ZIP — thì các khóa công khai phải là một phần của Repository. GCBoK định nghĩa cho việc này một mẫu Keyring trong Repo:

Cấu trúc: .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

Mô hình hai tầng: TOP-Repo vs. PII-Repo

Tầng Repository Nội dung Mức độ liên quan đến DSGVO
Tổ chức TOP-Repo (Tenant Organizational Platform) Khóa của Team-Lead, Service-Accounts, CI/CD-Bots, điểm neo tin cậy trusted-keys.gpg Không có dữ liệu cá nhân — tuân thủ DSGVO
Cá nhân PII-Repo (Personal Identifiable Information) Khóa của nhà phát triển, bằng chứng danh tính (các xác nhận Governikus), GPG-Fingerprint gắn với cá nhân PII — chỉ truy cập qua Org-Unit-Claims (xem bên dưới)

Sự tách biệt này phản ánh hai tầng trách nhiệm đối với PII:

  1. Pháp lý — tầng Tenant (pháp nhân, ví dụ: GCC, GCD, CFP)
  2. Tổ chức — PMO/Divisions/Departments/Locations (≈ AD Organizational Unit)

Xác minh tách biệt khỏi Keyring cục bộ

Một người kiểm tra (hoặc một Auditor 10 năm sau) xác minh mà không phụ thuộc vào GPG-Keyring cục bộ:

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

Hiệu lực theo thời gian và vòng đời khóa

Câu hỏi „Chữ ký có hiệu lực tại thời điểm commit hay không?" được trả lời bởi việc tích hợp vào Repository:

Mức độ liên quan đến tài liệu hóa quy trình GoBD và NIS2

Xem thêm: Chuỗi bài viết „Hướng dẫn quy trình GoBD cho Git" trong GCBoK (Mô-đun 3: Tính toàn vẹn mật mã, Mô-đun 4: Chữ ký & Tính xác thực) đi sâu vào các chủ đề này. Dự án nghiên cứu GitCover.IdP (BSFZ 288-335-338/2026-1) nghiên cứu việc tích hợp IdP.

uuidV7 - UUID Version 7

UUID Version 7 tương thích RFC-4122: dựa trên thời gian, có thể sắp xếp, chống xung đột. Phần mở rộng đặc thù của GitCover với mã định danh lớp 14-bit biến các UUID thành V7GUIDs (xem Khái niệm).

Git với tư cách IdP - Identity Provider

Các Git-Repository dựa trên Gitea đóng vai trò Single Source of Truth (SSoT) cho một hệ thống quản lý danh tính và truy cập tích hợp (IAM). Dự án nghiên cứu được BSFZ công nhận xem xét liệu các Git-Organisation/Teams có thể biểu diễn OAuth2-Clients và Permissions và quản lý hơn 1.000 người dùng với hiệu năng tốt hay không.

Trách nhiệm hai tầng đối với PII (Pháp lý + Tổ chức)

Dữ liệu cá nhân (PII) trong GitCover-Stack chịu một trách nhiệm kép, được phản ánh trong kiến trúc Repository và các OIDC-Claims:

Tầng Scope Loại Repository OIDC-Claim Ví dụ
1. Pháp lý Tenant (pháp nhân) TOP-Repo + PII-Repo tenant_id (dựa trên V7GUID) GCC, GCD, CFP, ADA
2. Tổ chức PMO / Division / Department / Location PII-Repo (phân cấp tinh) org_unit_id (≈ AD Organizational Unit) GCC-Portfolio, GCD-IT, CFP-Sales

Ánh xạ Người - Vai trò (Cầu nối PII) — Công việc cần thực hiện

Ánh xạ Người - Vai trò (Cầu nối PII) — Công việc cần thực hiện

Các container chữ ký GCPN tham chiếu người tham gia (attendees) dưới dạng Actors (vai trò trong Tenant, chức năng trong doanh nghiệp) và chỉ ghi nhận các cá nhân ở dạng pseudonym hóa (persons.mappings với tham chiếu PII). Ánh xạ chuẩn tắc Person → Rollen → Org-Units nằm trong phạm vi PII (gitignored) — để có một mô hình xuyên suốt, các quan hệ sau vẫn cần được xây dựng chi tiết trong GCBoK:

Quan hệ Trạng thái trong GCBoK Công việc cần thực hiện
User → Role Cách tiếp cận (Git-Repo = IdP; tài liệu chữ ký làm vật mang Claim) Định nghĩa vai trò cho từng Tenant (GF, GS-Verwalter, Auditor) như một bộ từ vựng chuẩn tắc — tương tự kinds.json/status_flags.json trong OSS-Normative-Root
Role → Group Gitea-Teams (Org → Team → Member) Mapping Gitea-Team ↔ Role; quy ước Team-Slug + kết nối others.json (allowed_repos)
Group → Org-Unit L2 Department làm điểm neo Org-Unit (02-konzepte) Bổ sung nội dung departments.json cho từng Tenant (hiện tại AFJD-Master: entries rỗng); quy ước dạng rõ cho org_unit_id (GCC-Portfolio v.v.)
Org-Unit → Tenant Claim hai tầng (tenant_id pháp lý, org_unit_id tổ chức) Bổ sung nội dung others.json cho từng TOP-Repo (hiện đang rỗng); tài liệu hóa Claim-Mapping trong Inlet-Pipeline
Person (PII) → User PII-Repo (gitignored) PII-Schema cho Person↔Role-Mapping (DSGVO: tối thiểu hóa, tham chiếu pseudonym hóa như trong GCPN persons.mappings)

Liên kết: gcpn-container-1.0 → attendees (các vai trò trong vụ việc) → persons.mappings (tham chiếu PII pseudonym hóa) → PII-Repo (ánh xạ chuẩn tắc). Cho đến khi được xây dựng chi tiết, các tham chiếu pseudonym hóa được tài liệu hóa tại đây được coi là giải pháp chuyển tiếp.

Phân cấp Claim trong Inlet-Pipeline

Inlet-Pipeline (xem Cách thức thực hiện: Cô lập Tenant đọc others.json tùy theo User-Claim và tiêm các đường dẫn được phép:

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

Nhờ đó, một người dùng với org_unit_id = ORG-1-Portfolio có quyền truy cập vào PII-Repo của Portfolio, nhưng không vào PII/ORG-2-IT — ngay cả khi tenant_id giống nhau.

Xem thêm: Dự án nghiên cứu về GitCover.IdP được mô tả trong Dự án nghiên cứu. Kiến trúc Keyring (TOP vs. PII) đã được mô tả ở trên dưới mục „Kiến trúc GPG-Keyring".