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 định dạng JSON/YAML mà máy có thể đọc được 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 - Đường cơ sở riêng theo tổ chức
3. Implementation Layer - System Security Plans, Component Definitions
4. Assessment Layer - Assessment Results, POA&M

BSI tài liệu hóa chính thức: “OSCAL có thể kết nối với các tiêu chuẩn quốc tế”. GCBoK định nghĩa các taxonomy tuân thủ của Đức (GoBD, BSI, DSGVO) dưới dạng 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à quy tắc OPA là một phần của lớp ngữ nghĩa mà máy có thể đọc được trong bản thể học GitCover: Chúng mô tả bằng cùng ngôn ngữ với các từ điển L1–L6, những yêu cầu nào á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ư bản thể học và Thuật ngữ: Bản thể học).

Các GCPN-Events/Flags (vòng đời chữ ký và quy trình) được suy ra từ các danh mục OSCAL này (ao-buchfuehrung, gobd, ustg-rechnung, bmf-erechnung). Bộ sưu tập bất biến GCPN-EVENTS-FLAGS mang neo quản trị (AO §146, GoBD Rz. 146/147) và được tham chiếu trong GCPN thông qua events.enum_ref.

OPA / Rego - Chính sách dưới dạng mã

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 dựa trên trạng thái Git.

VPRM - Verifiable Process Reward Model

Trong ngữ cảnh GCBoK, OPA/Rego đóng vai trò VPRM: Guardrails cho các tác nhân AI được tạo ra bằng bộ quy tắc tất định, không phải bằng Prompt-Engineering. Nhờ đó, các tác nhân AI không được bảo đảm bằng Prompt-Constraints mà bằng kiểm định mã.

Ký GPG

Mỗi Git-Commit liên quan đến tuân thủ đều được ký GPG. Chữ ký ràng buộc:

• Danh tính (GPG-Fingerprint = chủ thể)
• Nội dung (Commit-Hash = dữ liệu)
• Thời điểm (Commit-Timestamp = khi nào)

Từ siêu dữ liệu .gc.md, các GPG-Fingerprint được gắn với V7GUID - danh tính vẫn 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.

GCSIG — Chữ ký như hiện vật được quản lý phiên bản

Lịch sử Git tự nó không đủ để làm bằng chứng chữ ký: Một force-push có thể viết lại nó. Vì vậy, mỗi chữ ký Git-code/commit liên quan (GPG, signed commit, PR) còn được lưu thêm dưới dạng hiện vật bất biến {name}.gcsig.md (schema gcsig-1.4). Nó ràng buộc:

• Đối tượng (Commit-/Tree-/Tag-/PR-SHA)
• Chữ ký GPG + Signer-Fingerprint + trạng thái xác minh
• Các giai đoạn dưới dạng cờ 32-bit (draft, presented, accepted, signed, denied, withdrawn, revoked, expired, superseded, verified)

Nhờ đó, chữ ký commit trở nên được Git quản lý phiên bản và chống viết lại lịch sử; một GCPN tiếp theo tham chiếu GCSIG thông qua parents[]/children[] (GCSIG:{docUid}). Cách tạo: gc-docsign gcsig <repo> --commit <sha>.

Kiến trúc GPG-Keyring để có thể chứng minh pháp y

Để các chữ ký GPG vẫn có thể được xác minh lâu dài — 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 tạo từ git bundle/kho ZIP — 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 cấp: TOP-Repo so với PII-Repo

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

1. Pháp lý — cấp Tenant (pháp nhân, ví dụ GCC, GCD, GCP)
2. Tổ chức — PMO / Bộ phận / Phòng ban / Địa điểm (≈ AD Organizational Unit)

Xác minh độc lập với keyring cục bộ

Người kiểm tra (hoặc auditor 10 năm sau) xác minh 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>

• --no-default-keyring: Bỏ qua ~/.gnupg/
• --keyring: Chỉ sử dụng khóa từ repository
• Khóa công khai đã ở trong repository tại thời điểm commit → có tính chất bằng chứng có thể tái tạo pháp y

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

Câu hỏi “Chữ ký có hợp lệ tại thời điểm commit không?” được trả lời nhờ việc tích hợp vào repository:

• Khóa công khai nằm trong lịch sử Git của commit
• Ngay cả khi khóa hết hạn/bị thu hồi ngày nay: Commit chứng minh rằng khóa khi đó đáng tin cậy
• git bundle vận chuyển repo bao gồm khóa và bằng chứng → đơn vị pháp y di động, độc lập với hạ tầng đang vận hành

Mức độ liên quan đối với tài liệu quy trình GoBD và NIS2

• GoBD (§ 146 AO, Verfahrensdokumentation): Kiến trúc Keyring là một phần của tài liệu quy trình — nó mô tả cách bằng chứng danh tính được tạo, lưu trữ và xác minh một cách an toàn phục vụ kiểm toán. Mẫu “Schlüssel-im-Repo” đáp ứng các yêu cầu của GoBD về khả năng kiểm tra lại và tính bất biến của việc ràng buộc danh tính.
• NIS2 (quyền truy cập, Art. 21): Việc tách TOP/PII-Repo và kiểm soát truy cập dựa trên Org-Unit (thông qua OIDC-Claims tenant_id + Org-Unit-Claim) hiện thực hóa nguyên tắc đặc quyền tối thiểu. Chỉ các vai trò được cấp quyền (thông qua Org-Unit-Claim) mới có quyền truy cập PII-Repo và do đó truy cập các khóa cá nhân.

Xem thêm: Loạt bài “GoBD-Verfahrensanweisungen für 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 Phiên bản 7 tương thích RFC-4122: dựa trên thời gian, có thể sắp xếp, chống trùng lặp. Phần mở rộng dành riêng cho GitCover với định danh lớp 14-bit biến UUID thành V7GUID (xem Khái niệm).

Mô hình kỷ nguyên thời gian (real · tenant · person)

Phân chia chuẩn: Các chuẩn RFC cho GUID có thể sắp xếp theo thời gian (RFC 9562/4122) mô tả duy nhất cấu trúc — bố cục bit, độ dài và vị trí của trường dấu thời gian, phiên bản và biến thể. Ngữ nghĩa — dấu thời gian có nghĩa là gì, đặc biệt là kỷ nguyên thời gian làm đại lượng tham chiếu và việc phân loại trong phần hậu tố — do GCBoK quy định (đặc tả V7GUID, schema OSS v7guid-epoch-mode-1.0). Do đó, một chế độ như person không vi phạm cấu trúc RFC; nó là ngữ nghĩa GCBoK trên cấu trúc tuân thủ RFC.

Dấu thời gian 48-bit (unix_ts_ms, RFC 9562) là unsigned và có thể sắp xếp; kỷ nguyên tham chiếu của nó tại GitCover là một chế độ được định nghĩa (Union/Enum, schema OSS v7guid-epoch-mode-1.0):

Tiền tố RFC (dấu thời gian + phiên bản + biến thể) ở đây vẫn là giao diện từ Normative-Root đến Customizing (“Interface-Inheritance”); phần hậu tố (phần còn lại của 128 bit) mang phân loại GitCover (L1–L6, danh mục/mẫu bit, tìm kiếm Registry-/Keyword). Các giá trị thời gian trước kỷ nguyên đã chọn là một lỗi được định nghĩa (không wrap dấu): Số học .NET là có dấu (DateTimeOffset trả về long âm trước 1970), chỉ không âm mới được ghi nhận — nhờ đó giữ được thứ tự sắp xếp và định dạng RFC, trong khi dữ liệu lịch sử (ví dụ ngày sinh, PII) vẫn có thể được sắp xếp.

Quy tắc đặt tên JSON của instance (`

Bộ dữ liệu cơ sở (JSON của instance) của một đối tượng được lưu trong đường dẫn Git-Repo — và do đó trong WorkingDirectory — dưới dạng {docType}.{classId}.json (docType = viết tắt lớp, classId = V7GUID-Class-Identifier; ví dụ PII_PERSON.01a12f72-4c75-74f1-8626-dd1ae65b6062.json). Đây là một chỉ mục tự nhiên: công cụ gần gũi với OS tìm dữ liệu instance qua {docType} và/hoặc {classId} mà không cần biết tên tệp cố định. Áp dụng cho tất cả hiện vật dữ liệu (trong đó có PII persons/<uuidv7>/, mục Registry, schema chứng từ).

Cơ sở Temporal & Flag (GitCover.Core)

• validFrom/validTo (nullable, SSoT temporal-1.0): validFrom = neo “từ” (đầu tập giải pháp), validTo tùy ngữ cảnh — truy vấn ngày day: validTo < date.AddDays(1). null = “không rõ từ khi nào” / “vẫn còn hiệu lực”. Logic trung tâm: GitCover.Core.Types.Temporal.
• Quy tắc Boolean hai trạng thái: absent == false; giá trị hiện diện vẫn có hiệu lực (false/f/n/no/0/null là falsy, không bao giờ diễn giải là true); false có thể được bỏ qua (giảm phình dữ liệu).
• Flag-BitVectors (tích lũy, [Flags]): schema cơ sở cờ ENUM thuộc vào schema (phase-flags-1.0), không thuộc instance; các instance mang status_flags (chỉ các cờ được đặt; hiện diện == được đặt) + phases_result + current_phase dưới dạng string.Join(" + ", …). Mã: GitCover.Core.Types.Flags.
• Các schema tham chiếu temporal-1.0: pii-person, ou, iam-feature, repository-catalog, repository-identity, legal-entity, gcep-peer-registry, ocr-artifact, dictionary, category-catalog, business-meal-receipt, source-fact, beleg-journal.

Git như IdP - Identity Provider

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

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

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

• Pháp lý (cấp Tenant): Pháp nhân là bên kiểm soát theo luật bảo vệ dữ liệu (Art. 4 Nr. 7 DSGVO). tenant_id được suy ra tất định từ V7GUID của thư mục TOP (xem [Khái niệm: Sổ đăng ký Tenant trung tâm](v7guid-beleg-ketten-und-cryptographic-evidence.html #zentrales-tenant-register)).
• Tổ chức (PMO/Org-Unit): Trong một tenant, nhiều đơn vị tổ chức (PMO, phòng ban, địa điểm) có thể độc lập chịu trách nhiệm cho các tập con PII. Điều này tương ứng với cấu trúc của Active-Directory-Organizational-Units. Việc gán diễn ra thông qua Custom Claim org_unit_id, được ánh xạ tới các đường dẫn repository trong others.json của tenant.

Gán Person với Role (cầu nối PII) — nhu cầu công việc

Gán Person với Role (cầu nối PII) — nhu cầu công việc

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ỉ mang theo người ở dạng giả danh (persons.mappings với tham chiếu PII). Việc gán chuẩn tắc Person → Roles → Org-Units nằm trong vòng PII (gitignored) — để có một mô hình xuyên suốt, các quan hệ sau vẫn còn phải được xây dựng chi tiết trong GCBoK:

Liên kết: gcpn-container-2.7 → attendees (vai trò trong quy trình) → persons.mappings (tham chiếu PII giả danh) → PII-Repo (gán chuẩn tắc). Cho đến khi được xây dựng, các tham chiếu giả danh được ghi lại ở đây được áp dụng như giải pháp chuyển tiếp.

Phân cấp Claim trong Inlet-Pipeline

Inlet-Pipeline (xem Quy trình: Cô lập 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ờ đó, người dùng có org_unit_id = ORG-1-Portfolio được truy cập PII-Repo của Portfolio, nhưng không được truy cập 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 so với PII) được mô tả ở trên trong mục “Kiến trúc GPG-Keyring”.