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 định dạng JSON/YAML mà máy đọ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ở theo tổ chức
  3. Implementation Layer - Kế hoạch Bảo mật Hệ thống, Định nghĩa Thành phần
  4. Assessment Layer - Kết quả Đánh giá, POA&M

BSI ghi nhận 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) như các catalog OSCAL - điều này chưa tồn tại trên thị trường cho đến nay.

Các catalog OSCAL và quy tắc OPA là một phần của lớp ngữ nghĩa máy đọc được của bản thể học GitCover: Chúng mô tả bằng cùng ngôn ngữ như 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 nghiệp vụ như bản thể học và Thuật ngữ: Bản thể học).

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 tự động kiểm tra dựa trên trạng thái Git.

VPRM - Mô hình Phần thưởng Quy trình Có thể Xác minh

Trong ngữ cảnh GCBoK, OPA/Rego đóng vai trò là VPRM: Các rào chắn cho tác nhân AI được tạo ra bởi hệ thống quy tắc tất định, không phải bằng kỹ thuật prompt. Nhờ đó, các tác nhân AI không được bảo vệ bằng các ràng buộc prompt, 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ý ràng buộc:

Từ siêu dữ liệu .v7g.md, dấu vân tay GPG đượ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ư một tạo tác được đánh phiên bản

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

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

Kiến trúc chuỗi khóa GPG cho khả năng chứng minh pháp y

Để các chữ ký GPG vẫn có thể xác minh lâu dài — ngay 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/các kho 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 chuỗi khóa 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

Cấp Repository Nội dung Mức độ liên quan DSGVO
Tổ chức TOP-Repo (Tenant Organizational Platform) Khóa trưởng nhóm, Tài khoản dịch vụ, Bot CI/CD, 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 nhà phát triển, Chứng minh danh tính (Xác nhận Governikus), Dấu vân tay GPG cá nhân PII — Chỉ truy cập qua các claim đơn vị tổ chức (xem bên dưới)

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 thuê bao (pháp nhân, ví dụ GCC, GCD, GCP)
  2. Tổ chức — PMO/Divisions/Departments/Locations (≈ Đơn vị Tổ chức AD)

Xác minh tách biệt khỏi chuỗi khóa cục bộ

Một người kiểm tra (hoặc kiểm toán viên 10 năm sau) xác minh mà không phụ thuộc vào chuỗi khóa GPG 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 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 thông qua việc tích hợp repository:

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

Xem thêm: Loạt bài „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 tích hợp IdP.

uuidV7 - UUID Phiên bản 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 va chạm. Phần mở rộng dành riêng cho GitCover với mã đị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 tiêu chuẩn: Các tiêu chuẩn RFC cho GUID có thể sắp xếp theo thời gian (RFC 9562/4122) mô tả chỉ 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 như đại lượng tham chiếu và phân loại trong hậu tố — được quy định bởi GCBoK (Đặc tả V7GUID, lược đồ OSS v7guid-epoch-mode-1.0). Do đó, một chế độ như person không vi phạm cấu trúc RFC; nó là một 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à không dấu và có thể sắp xếp; kỷ nguyên tham chiếu của nó trong GitCover là một chế độ được định nghĩa (Union/Enum, lược đồ OSS v7guid-epoch-mode-1.0):

Chế độ Kỷ nguyên Mục đích
real Unix 1970-01-01Z Tiêu chuẩn RFC; thời gian thực tế (hệ thống)
tenant Kỷ nguyên thuê bao (ví dụ: ngày thành lập) suy ra lớp/TenantId tất định
person Kỷ nguyên cá nhân (mặc định 1900-01-01Z) thời gian PII sinh/historical trước 1970 có thể biểu diễn dương

Tiền tố RFC (dấu thời gian + phiên bản + biến thể) vẫn là giao diện từ Normative-Root đến Customizing („Interface-Inheritance"); 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/từ khóa). 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 có wrap dấu): Số học .NET là có dấu (DateTimeOffset trả về long âm trước 1970), chỉ chứng minh không âm — do đó thứ tự sắp xếp và định dạng RFC được giữ nguyên, trong khi dữ liệu lịch sử (ví dụ: ngày sinh, PII) vẫn có thể sắp xếp.

Quy tắc đặt tên JSON phiên bản (`

Bản ghi cơ sở (JSON phiên bản) 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 = Mã định danh lớp V7GUID; 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 phiên bản 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ả tạo tác dữ liệu (bao gồm PII persons/<uuidv7>/, mục registry, lược đồ chứng từ).

Cơ sở thời gian & cờ (GitCover.Core)

Git như IdP - Nhà cung cấp Danh tính

Các Git-Repository dựa trên Gitea như Nguồn Sự thật Duy nhất (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/nhóm Git có thể ánh xạ các OAuth2-Client và quyền cũng như quản lý hiệu quả 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 ngăn xếp GitCover chịu trách nhiệm kép, được phản ánh trong kiến trúc repository và các OIDC-Claim:

Cấp Phạm vi Loại repository OIDC-Claim Ví dụ
1. Pháp lý Thuê bao (pháp nhân) TOP-Repo + PII-Repo tenant_id (dựa trên V7GUID) GCC, GCD, GCP, ADA
2. Tổ chức PMO / Division / Department / Location PII-Repo (chi tiết) org_unit_id (≈ Đơn vị Tổ chức AD) GCC-Portfolio, GCD-IT, GCP-Sales

Gán người với vai trò (Cầu nối PII) — Nhu cầu công việc

Gán người với vai trò (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) như Actors (vai trò trong thuê bao, chức năng trong doanh nghiệp) và chỉ mang theo người được giả danh (persons.mappings với tham chiếu PII). Việc gán chuẩn tắc Người → Vai trò → Org-Unit nằm trong vòng PII (gitignored) — để có một mô hình xuyên suốt, các mối quan hệ sau vẫn cần được xây dựng chi tiết trong GCBoK:

Mối quan hệ Trạng thái GCBoK Nhu cầu công việc
User → Role Cách tiếp cận (Git-Repo = IdP; tài liệu chữ ký như vật mang claim) Định nghĩa vai trò theo từng thuê bao (GF, GS-Verwalter, Auditor) như từ vựng chuẩn tắc — tương tự kinds.json/status_flags.json trong OSS-Normative-Root
Role → Group Nhóm Gitea (Org → Team → Member) Ánh xạ Gitea-Team ↔ Role; quy ước slug nhóm + kết nối others.json (allowed_repos)
Group → Org-Unit Bộ phận L2 như neo Org-Unit (02-konzepte) Điền departments.json theo từng thuê bao (hiện tại AFJD-Master: entries trống); quy ước văn bản thuần org_unit_id (GCC-Portfolio v.v.)
Org-Unit → Tenant Claim hai cấp (tenant_id pháp lý, org_unit_id tổ chức) Điền others.json theo từng TOP-Repo (hiện tại trống); ghi lại ánh xạ claim trong Inlet-Pipeline
Person (PII) → User PII-Repo (gitignored) Lược đồ PII cho ánh xạ Person↔Role (DSGVO: tối thiểu hóa, tham chiếu giả danh như trong GCPN persons.mappings)

Liên kết: gcpn-container-2.4 → 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 coi là giải pháp tạm thời.

Phân cấp claim trong Inlet-Pipeline

Inlet-Pipeline (xem Quy trình: Cô lập thuê bao đọ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 vào PII-Repo của portfolio, nhưng không được truy cập vào PII/ORG-2-IT — ngay cả khi có 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 chuỗi khóa (TOP so với PII) được mô tả ở trên trong „Kiến trúc chuỗi khóa GPG".