Trục 5: Quy trình
Onboarding DNVV
Việc tiếp cận cho DNVV vào tuân thủ Git-native theo một lộ trình từng bước:
- Khởi tạo kho Git — Cấu trúc với thư mục
.gitcover/, cấu hình V7GUID - Chọn catalog OSCAL — Baseline GoBD, khối BSI hoặc profile cá nhân
- Kích hoạt chính sách OPA — Pre-receive-hooks để kiểm tra trước commit
- Thiết lập ký GPG — Mỗi tác nhân một cặp khóa GPG
- Bắt đầu chuỗi chứng từ — Gán V7GUID đầu tiên, bắt đầu nối prev-hash
Cho doanh nhân từ cấp kinh doanh phụ
Việc tiếp cận có thể bắt đầu với một câu chuyện rất đơn giản: GCDMS cho lưu trữ chứng từ, GCPN cho chuỗi bằng chứng. Mở rộng sau: chính sách OSCAL, kiểm chứng OPA, multi-tenant.
Onboarding tương tác: "Compliance City"
Thay vì bảng câu hỏi cổ điển, onboarding diễn ra như xây dựng module theo khái niệm một thành phố trên đế Lego. Mỗi quyết định kiến trúc và mỗi yêu cầu chuyên ngành tương ứng một khối gạch hoặc một nhóm gạch (Lego-Set), được lưu trữ làm module có cấu trúc trong kho Default-Git vừa khởi tạo và có phiên bản.
Ẩn dụ cho người dùng:
- Đế gạch: Kho Git rỗng, vừa tạo cho tenant trong hạ tầng của nó. Nó cung cấp khung chuẩn (các nút gạch) mà mọi thứ gắn vào.
- Khối gạch: Cấu hình module và tệp dịch vụ. Chỉ khi khối gạch gắn chặt (Git-Commit), chức năng hoặc kiểm tra tuân thủ tương ứng mới kích hoạt.
Giai đoạn 1 — Trải đế gạch (Khởi tạo & Định danh):
Hệ thống tự động tạo Default-Repository cho tenant. Trợ lý onboarding xác định định danh của doanh nghiệp. Dữ liệu được lưu có cấu trúc trong repo 'TOP' (Tenant Organization Profile) — commit Git đầu tiên đã là quy trình tuân thủ có thể kiểm toán đầu tiên. Nhân tiện: Tenant tất nhiên cũng có thể tổ chức phân cấp, như cấu trúc doanh nghiệp mà chúng thuộc về.
| Khối gạch | Tương ứng kỹ thuật | Mục đích |
|---|---|---|
| Đế gạch | git init --object-format=sha256 |
Cơ sở mọi hoạt động tenant trong repo Git 'TOP' và thư mục |
| Tòa thị chính | ./.gitcover |
Dot-Directory GitCover, chứa Tenant Dictionaries và Configurations |
Giai đoạn 2 — Đi dây hạ tầng (Mạng cung cấp):
Trợ lý ghi nhận cảnh quan IT: Máy trạm laptop, file-server, cloud-first hoặc hạ tầng lai. Các tham số như kết nối Internet, domain, đường dẫn storage v.v. chảy vào thông tin hạ tầng và chuẩn bị đường dẫn cho kết nối chéo (others.json).
Giai đoạn 3 — Xây tòa nhà (Phạm vi chuyên ngành):
Người dùng quyết định module, khu vực quản lý nào thành phố của họ nên bảo đảm:
| Khối gạch | Phạm vi | Hành động |
|---|---|---|
| Chợ (GoBD/AO cơ bản) | Bắt buộc cho mọi DNVV — tài liệu quy trình | ví dụ Module & thư mục /compliance/gobd/ kích hoạt |
| Ngân hàng & quầy thu (Kế toán tài chính) | Ghi sổ nhật ký, sổ cái, giao diện ngân hàng | ví dụ Module & thư mục /finance/journal/ và /finance/ledgers/ kích hoạt |
| Cổng xưởng (An ninh/NIS2) | Bảo mật IT mở rộng tùy chọn và nghĩa vụ báo cáo | ví dụ Module & thư mục /compliance/nis2/ kích hoạt |
Người dùng không thấy tệp cấu hình hay mã ở bất kỳ thời điểm nào. Vì mỗi bước ngay lập tức tạo một Git-Commit sạch, hệ thống được tài liệu hóa an toàn kiểm toán đầy đủ theo GoBD và AO từ phút đầu tiên.
Cô lập tenant và kiểm soát truy cập
OIDC-Claims và others.json
Việc liên kết OIDC-Claims với others.json là con đường vua cho môi trường tuân thủ đa tenant, an toàn cho người ngoài chuyên môn. Trong others.json thu thập:
- Tuyến canonical tới kho Git riêng của tenant
- Kết nối chéo tới kho Git của tenant khác, khi tenant là thành viên của nhóm
Truy cập được điều khiển qua OIDC-Claims (vai trò và Custom Claims như tenant_id và nhóm). Pipeline Inlet đọc others.json tùy theo User-Claim và inject đường dẫn được phép làm system-prompt:
Bạn là GitCover Agent cho Mandant X. Bạn chỉ có truy cập cho các repository sau: [Pfad 1], [Pfad 2]. Không thực thi lệnh ngoài các thư mục này.
Với người dùng cuối, bộ máy bảo mật này vô hình. Họ đăng nhập, thấy môi trường làm việc quen thuộc và AI tự động biết nơi nó được phép hoạt động.
Thu thập dữ liệu hỗ trợ AI qua Formular-Bridging
Giao diện chat phù hợp cho ngữ cảnh và phân tích, không cho thu thập kiểu dữ liệu nghiêm ngặt (IBAN, mã bưu điện, lược đồ OSCAL). GCBoK khuyến nghị Formular-Bridging:
- AI nhận diện nhu cầu: Người dùng nói "Tôi muốn thêm một cơ sở kinh doanh mới."
- URL form động: AI đưa ra liên kết đến form nhập web đã kiểm chứng (Blazor WASM/PWA), kết nối với quản lý session và user.
- Nhập liệu cách ly: Người dùng điền form — được kiểm chứng nghiêm ngặt trước khi lưu.
- Ghi trực tiếp vào Git: Form ghi kết quả làm tệp có cấu trúc trực tiếp vào working-directory của repo tenant và kích hoạt commit.
- AI tiếp quản lại: MCP-server báo "Tệp đã cập nhật", AI xác nhận trong chat.
Ưu điểm: Kiểm chứng trước khi lưu bảo vệ Single Source of Truth. LLM không thao túng quá trình ghi. Kiểm chứng Git-Hook/OPA được kích hoạt ngay.
Cấu trúc thư mục .gitcover/
Thư mục .gitcover/ trong root của kho GitCover là kho lưu trữ trung tâm cho mọi artifact không phải mã. Nó phục vụ an toàn kiểm toán, tuân thủ (GoBD/AO) và dẫn dắt audit-trail.
Bố cục thư mục
.gitcover/
├── issues/ # Gitea-Issues als .v7g.md
├── projects/ # Projekt-Management-Daten
├── time_tracking/ # Zeiterfassung und Aufwandsnachweise
├── workflows/ # Workflow-Zustände und Genehmigungen
├── compliance/
│ ├── oscals/ # OSCAL-Dokumente (System Security Plans)
│ ├── opa/ # OPA-Regeln (Rego-Policies)
│ └── hooks/ # Git-Hooks für Automatisierung
├── audit/
│ ├── signatures/ # Kryptografische Signaturen
│ ├── timestamps/ # Zeitstempel (ELSTER/Bundesanzeiger)
│ └── logs/ # Protokolle
└── README.md # Dokumentation der Struktur
Quy ước đặt tên tệp
Định dạng chung: {uuidV7}_{human-readable-key}_{Beschreibung}.v7g.md
| Loại artifact | Ví dụ | Lý do |
|---|---|---|
| Issue | 018e312f-..._#123_Bugfix-Login.v7g.md |
UUIDv7 để sắp xếp được, # để nhận diện |
| Dự án | 018e312f-..._Projekt-X.v7g.md |
Duy nhất, sắp xếp theo thời gian |
| Chấm công | 018e312f-..._2026-06-29_Axel-D.v7g.md |
Ngày và user dạng plaintext |
| Sidecar (PDF/DOCX) | Rechnung_2026.pdf.v7g.md |
Metadata cho tài liệu gốc |
Lược đồ metadata (.v7g.md Frontmatter)
---
uuid: 018e312f-3e4f-7000-8000-000000000000
key: "#123"
type: "issue"
title: "Bugfix: Login-Modul"
original_source: "Gitea"
original_repo_hash: "a1b2c3d4e5f6..."
related_commits: ["abc123", "def456"]
related_elements:
project: "Projekt-X"
milestone: "v1.0"
forensic_attributes:
created_at: "2026-06-29T12:00:00Z"
updated_at: "2026-06-29T14:30:00Z"
created_by: "Axel D."
compliance:
gobd_relevant: true
audit_trail: true
signature: "GPG-Signatur-Hash"
timestamp: "ELSTER-2026-06-29-120000"
---
Tự động hóa qua Git-Hooks và Webhooks
Kho GitCover được cấu hình tự động với hooks/webhooks khi init hoặc Tenant Onboarding:
post-commit: Cập nhật.gitcover/khi commit mớipre-push: Kiểm tra.gitcover/trước khi push- Webhooks: Tạo issue, thay đổi dự án, chấm công — mỗi cái kích hoạt export làm
.v7g.md - Compliance-Claim: Kích hoạt ngay cơ chế OSCAL/OPA
Việc quản lý phiên bản các hooks/webhooks cũng qua Git, để thay đổi truy vết và kiểm toán được (tự tham chiếu, có phiên bản, an toàn kiểm toán). Bản thân các hooks có thể là artifact mã có phiên bản, nằm trong .gitcover/hooks/ và cập nhật khi cần, được tài liệu hóa theo GoBD hoặc NIS2.
Lưu trữ issue: DB Gitea sang cơ sở sự thật Git
Vấn đề
Gitea-Issues là mục cơ sở dữ liệu — không phải đối tượng Git native. Chúng không có phiên bản và không tái dựng được khi mất DB Gitea. Commit tham chiếu issue chỉ bằng văn bản (Fixes #123); tham chiếu này không được Git diễn giải.
Giải pháp: Export tự động làm .v7g.md
Quy trình từ DB Gitea sang cơ sở sự thật an toàn kiểm toán:
- Gitea-Issue tạo → Webhook kích hoạt export
- Export làm .v7g.md → Lưu vào
.gitcover/issues/ - Trích metadata → UUID, hash, chữ ký
- Git-Commit với chữ ký →
git commit -S - Kiểm chứng OSCAL/OPA → Kiểm tra tuân thủ
- Timestamp → Tích hợp ELSTER/Bundesanzeiger (nếu cần)
Quy tắc OPA mẫu cho kiểm tra issue
package gcbok.compliance
violation[msg] {
input.path == "issues"
file := input.files[_]
not startswith(file.name, "018") # UUIDv7-Prüfung
msg := sprintf("Issue %s hat keine gueltige UUIDv7 im Dateinamen", [file.name])
}
Tuân thủ GoBD/AO
| Yêu cầu GoBD | Thực hiện trong .gitcover/ |
|---|---|
| Tính truy vết | Mỗi thay đổi được ghi trong .gitcover/audit/logs/ |
| Tính không thay đổi | Tệp .v7g.md không bao giờ ghi đè, mà có phiên bản |
| Nghĩa vụ lưu trữ | 10 năm (DE) — .gitcover/ làm kho lưu trữ trung tâm |
| Chức năng chứng từ | Tệp .v7g.md làm chứng từ kỹ thuật số |
| Tính kiểm tra được | Chữ ký và timestamp cho phép kiểm chứng pháp y |
Sẵn sàng kiểm toán
Sẵn sàng kiểm toán có nghĩa: Mọi kiểm toán có thể diễn ra bất cứ lúc nào — không cần chuẩn bị sau.
| Điều kiện tiên quyết | Đáp ứng Git-native |
|---|---|
| Audit-trail đầy đủ | Lịch sử Git (commit-log) |
| Định danh chứng minh được | Chữ ký GPG |
| Sắp xếp theo thời gian | Timestamp V7GUID |
| Bằng chứng máy đọc được | OSCAL-Assessment-Results |
| Tuân thủ chính sách | Kết quả kiểm chứng OPA |
Khóa sổ cuối năm GoBD
Khóa sổ cuối năm GoBD với tuân thủ Git-native:
- Chốt kỳ — Đóng băng nhánh Git
FY2026(Tag) - Kiểm tra chuỗi chứng từ — Kiểm tra nối V7GUID (Script)
- Tạo OSCAL-Assessment-Results — Tự động từ kiểm chứng OPA
- Cấp seal GPG — Commit kết thúc với chữ ký GF
- Lưu trữ — Container
.v7g.zip, v7g-export
Phân tích rủi ro NIS2
Phân tích rủi ro NIS2 trên cơ sở Git:
- Kiểm kê tài sản — Kho Git làm sổ đăng ký tài sản
- Nhận diện rủi ro — Chính sách OPA cho kịch bản đe dọa
- Đánh giá — Phân loại V7GUID cho danh mục rủi ro
- Giảm thiểu — Pre-receive-hooks cho policy-enforcement
- Báo cáo — OSCAL-Assessment-Results làm bằng chứng NIS2
Tích hợp máy chủ AI trong LAN
Nguyên tắc kiến trúc
GCBoK mô tả mô hình tham chiếu cho tích hợp một máy chủ AI headless trong LAN, cung cấp LLM-inference và AI-agent tuân thủ hỗ trợ RAG trung tâm. Môi trường AI chạy trong môi trường container cách ly (Rootless Podman), nhưng kết nối cho inference và tìm web với dịch vụ cài đặt native trên host.
SSH Script Host (OSSH)
Cho các tác vụ đòi hỏi (biên dịch mã, thao tác Git, kiểm tra tuân thủ) vượt ra ngoài sandbox container, agent sử dụng SSH Script Host — một lối thoát có kiểm soát, dựa trên khóa lên hệ thống host:
- Agent quyết định: "Thực thi dotnet-build"
- Kênh SSH: kết nối mã hóa qua
id_rsa.pubtới Host-User - Quá trình native: Lệnh thực thi trong ngữ cảnh hệ điều hành thật
- Trả về stream: stdout/stderr trả về làm text-stream
- Agent phân tích: Output compiler trong ngữ cảnh LLM
Điều kiện bảo mật: Khóa SSH tạo trong container phải được cài đặt trên host trong authorized_keys. Giao tiếp thuần qua stream dữ liệu chuẩn (stdin, stdout, stderr) — không truyền tệp.
Địa chỉ đường dẫn nhất quán (FQN)
Để tránh không nhất quán đường dẫn giữa workstation, container và script-host, file-server share được gắn tại mount-point giống nhau trên mọi hệ thống. AI-agent và lập trình viên tham chiếu đường dẫn tuyệt đối giống nhau tại mọi thời điểm.
Khả năng đa thiết bị
Qua tập trung hóa lên máy chủ AI, nhiều thiết bị cuối có thể truy cập song song cùng môi trường:
- Lập trình viên khởi động phân tích mã trên desktop
- Theo dõi tiến độ agent theo thời gian thực trên smartphone qua VPN
- Không có blockages lẫn nhau — script-host mở tiến trình shell riêng biệt, ngắn sống
Share-Frontends: Nextcloud làm frontend read-only
Phân vai
| Thành phần | Vai trò | Tuân thủ GCBoK |
|---|---|---|
| GCDMS | Nơi lưu trữ chính cho artifact tuân thủ trong Git | Đầy đủ |
| GCPN | Kiểm chứng chính sách (OPA/Rego) và quy tắc tuân thủ | Đầy đủ |
| GCUCB | Bus ngữ cảnh cho AI-agent, trình kiểm chứng OPA, hệ thống kiểm toán | Đầy đủ |
| Nextcloud | Chỉ cho share/chia sẻ (người dùng ngoài, truy cập di động) | Hạn chế |
Điều kiện sử dụng
Nextcloud có thể được sử dụng trong môi trường dựa trên GCBoK cho share nếu:
- Chỉ share read-only — Không thay đổi qua Nextcloud; mọi mutation chạy qua Git
- Tích hợp Git — Nextcloud gắn kho Git làm external storage (WebDAV, S3-Gateway hoặc GCSYNC)
- Kiểm chứng chính sách — GCPN định nghĩa quy tắc truy cập (OPA/Rego); Nextcloud chỉ thực thi
- Audit-logging — Log Nextcloud chuyển tiếp tới GCAL (Syslog/Loki)
- Tuân thủ open-source — Chỉ Community-Edition, không plugin độc quyền
Tiêu chí loại trừ
- Ghi qua Nextcloud (vi phạm lưu trữ Git-native)
- Tiện ích mở rộng Nextcloud độc quyền (vi phạm nguyên tắc OSS)
- Thiếu tích hợp Git (Nextcloud phải truy cập được kho Git)
Xem thêm: Mẫu cho catalog OSCAL và chính sách OPA trong Trục 6: Mẫu.