GitCover Symbol GCBoKGitCover Body of Knowledge

Trục 4: Các 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ó thể đọ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 - 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.

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 được bảo đảm không phải bằng Prompt-Constraints mà bằng xác thực mã.

Ký GPG

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

Kể từ siêu dữ liệu .v7g.md, các GPG-Fingerprint được liên kết với V7GUID - danh tính vẫn giữ tính chống 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 chứng

Để 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ì 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 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 lập trình viên, bằng chứng danh tính (các xác nhận Governikus), GPG-Fingerprint cá nhân PII — truy cập chỉ 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 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 giải đáp bằng việc tích hợp 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) khảo sát 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 định danh lớp 14-bit biến UUIDs thành V7GUIDs (xem Khái niệm).

Git với vai trò 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ý >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 Phạm vi 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 (chi tiết tinh) org_unit_id (≈ AD Organizational Unit) GCC-Portfolio, GCD-IT, CFP-Sales

Phân cấp Claim trong Inlet-Pipeline

Inlet-Pipeline (xem Cách tiếp cận: Cách ly Tenant đọc others.json tùy theo User-Claim và chèn 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 cùng tenant_id.

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 tại mục „Kiến trúc GPG-Keyring".