Trục 5: Quy trình

Onboarding cho KMU

Việc đưa KMU bắt đầu với Git-native Compliance diễn ra theo lộ trình từng bước:

1. Khởi tạo Git-Repository - Cấu trúc với thư mục .gitcover/, cấu hình V7GUID
2. Chọn OSCAL-Katalog - GoBD-Baseline, BSI-Bausteine hoặc hồ sơ riêng
3. Kích hoạt OPA-Policies - Pre-receive-Hooks để kiểm tra trước commit
4. Thiết lập ký GPG - Một cặp khóa GPG cho mỗi tác nhân
5. Khởi đầu chuỗi chứng từ - Cấp các V7GUID đầu tiên, bắt đầu chuỗi prev-hash

Dành cho doanh nhân từ mức kinh doanh phụ trở lên

Việc bắt đầu có thể đi cùng 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. Sau đó mở rộng: OSCAL-Policies, OPA-Validierung, Multi-Tenant.

Onboarding tương tác: „Compliance City"

Thay vì các bảng câu hỏi kinh điển, onboarding diễn ra dưới dạng xây dựng theo mô-đun, theo khái niệm một thành phố trên một bản đế Lego. Mỗi quyết định kiến trúc và mỗi yêu cầu nghiệp vụ tương ứng với một khối xây dựng hoặc một bộ khối (Lego-Set), được lưu và kiểm soát phiên bản dưới dạng mô-đun có cấu trúc trong Default-Git-Repository mới khởi tạo.

Ẩn dụ dành cho người dùng:

• Bản đế: Git-Repository trống, mới được tạo cho Tenant trong hạ tầng của Tenant. Nó cung cấp khung chuẩn hóa (các núm gắn), nơi mọi thứ có thể ghép nối vào.
• Các khối xây dựng: Cấu hình mô-đun và tệp dịch vụ. Chỉ khi một khối được lắp vào (Git-Commit), chức năng hoặc kiểm tra Compliance tương ứng mới được kích hoạt.

Giai đoạn 1 - Trải bản đế (Khởi tạo & Danh tính):

Hệ thống tự động tạo Default-Repository cho Tenant. Trợ lý Onboarding xác định danh tính doanh nghiệp. Dữ liệu được lưu có cấu trúc trong 'TOP' (Tenant Organization Profile) Repository - Git-Commit đầu tiên vốn đã là quy trình Compliance đầu tiên có thể kiểm toán. Ngoài ra: Tất nhiên, Tenant cũng có thể được tổ chức theo thứ bậc, tùy theo cơ cấu doanh nghiệp mà chúng thuộc về.

Giai đoạn 2 - Đấu nối hạ tầng (Mạng cung ứng):

Trợ lý ghi nhận bối cảnh IT: workstation laptop, File-Server, hạ tầng cloud-first hoặc lai. Các tham số như kết nối Internet, tên miền, đường dẫn lưu trữ v.v. được tích hợp vào thông tin hạ tầng và chuẩn bị các đường dẫn cho kết nối chéo (others.json).

Giai đoạn 3 - Xây dựng công trình (Phạm vi nghiệp vụ):

Người dùng quyết định theo mô-đun các lĩnh vực quản lý mà thành phố của họ muốn bảo vệ:

Người dùng không bao giờ nhìn thấy tệp cấu hình hoặc mã. Vì mỗi bước lập tức tạo ra một Git-Commit sạch, hệ thống được ghi nhận hoàn toàn an toàn về khả năng kiểm soát phiên bản theo GoBD và AO ngay từ phút đầu tiên.

Cô lập Tenant và kiểm soát truy cập

OIDC-Claims và others.json

Liên kết OIDC-Claims với others.json là con đường tối ưu cho các môi trường Compliance hỗ trợ multi-tenant và an toàn cho người không chuyên. Trong others.json tập hợp:

1. Đường dẫn chuẩn tới các Git-Repository thuộc sở hữu của Tenant
2. Kết nối chéo tới Git-Repository của các Tenant khác, nếu Tenant là thành viên của một nhóm

Quyền truy cập được điều khiển thông qua OIDC-Claims (vai trò và Custom Claims như tenant_id, org_unit_id và quyền thành viên nhóm). Một Inlet-Pipeline đọc others.json tùy theo User-Claim và chèn các đường dẫn được phép dưới dạng System-Prompt:

Bạn là GitCover Agent cho Tenant X. Bạn chỉ có quyền truy cập vào các Repository sau: [Pfad 1], [Pfad 2]. Không thực hiện lệnh nào ngoài các thư mục này.

Mô hình Claim hai cấp độ để truy cập PII

Để truy cập dữ liệu cá nhân (PII), GCBoK xác định một hệ thống phân cấp claim gồm hai cấp độ (xem Kỹ thuật: Git làm IdP:

others.json ánh xạ các claim này tới đường dẫn Repository:

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

Người dùng có org_unit_id = ORG-1-Portfolio được truy cập PII/ORG-1-Portfolio, nhưng không được truy cập PII/ORG-2-IT — ngay cả khi có cùng tenant_id. Điều này triển khai nguyên tắc đặc quyền tối thiểu (NIS2 Art. 21) ở cấp Repository.

Đối với người dùng cuối, cơ chế bảo mật này vẫn vô hình. Người dùng đăng nhập, thấy môi trường làm việc quen thuộc và AI tự động biết mình được phép hoạt động ở đâu.

Thu thập dữ liệu hỗ trợ AI qua Formular-Bridging

Chat-Interfaces phù hợp với ngữ cảnh và phân tích, không phù hợp với việc thu thập dữ liệu có kiểu nghiêm ngặt (IBAN, mã bưu chính, OSCAL-Schemata). Do đó, GCBoK đề xuất một Formular-Bridging:

1. AI nhận diện nhu cầu: Người dùng nói „Tôi muốn thêm một địa điểm hoạt động mới."
2. URL biểu mẫu động: AI cung cấp liên kết tới một mẫu nhập liệu web đã được kiểm tra (Blazor WASM/PWA), được liên kết với Session- và User-Management.
3. Nhập liệu đóng gói: Người dùng điền biểu mẫu - được kiểm tra nghiêm ngặt trước khi lưu.
4. Ghi trực tiếp vào Git: Biểu mẫu ghi kết quả dưới dạng tệp có cấu trúc trực tiếp vào Working-Directory của Mandanten-Repository và kích hoạt commit.
5. AI tiếp tục xử lý: MCP-Server báo „Tệp đã cập nhật", AI xác nhận trong chat.

Lợi ích: Kiểm tra trước khi lưu bảo vệ Single Source of Truth. LLM không thao túng quá trình ghi. Kiểm tra Git-Hook/OPA được kích hoạt ngay lập tức.

Cấu trúc thư mục .gitcover/

Thư mục .gitcover/ ở Root của GitCover-Repository là kho lưu trữ tập trung cho mọi artifact không phải mã. Nó phục vụ việc bảo đảm khả năng kiểm soát phiên bản, tuân thủ (GoBD/AO) và duy trì 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

Lược đồ siêu dữ liệu (.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: "Person A"
compliance:
  gobd_relevant: true
  audit_trail: true
  signature: "GPG-Signatur-Hash"
  timestamp: "ELSTER-2026-06-29-120000"
---

Tự động hóa bằng Git-Hooks và Webhooks

GitCover-Repos sẽ được tự động cấu hình với Hooks/Webhooks trong quá trình init hoặc Tenant Onboarding:

• post-commit: Cập nhật .gitcover/ khi có commit mới
• pre-push: Kiểm tra .gitcover/ trước khi push
• Webhooks: Tạo Issue, thay đổi dự án, ghi nhận thời gian - mỗi thao tác kích hoạt xuất dưới dạng .v7g.md
• Compliance-Claim: Kích hoạt ngay các cơ chế OSCAL/OPA

Việc kiểm soát phiên bản các Hooks/Webhooks này cũng thực hiện qua Git, nhờ đó thay đổi có thể truy vết và kiểm toán (tự tham chiếu, được kiểm soát phiên bản, an toàn về khả năng kiểm soát phiên bản). Bản thân các HOoks có thể là artifact mã đã được kiểm soát phiên bản, nằm trong .gitcover/hooks/, được cập nhật khi cần và được ghi nhận tuân thủ GoBD hoặc NIS2.

Yêu cầu riêng tư của HITL - Quy ước và quy tắc cho Agent

Bên cạnh tài liệu Compliance đã được kiểm soát phiên bản, mỗi người đang làm việc duy trì yêu cầu cá nhân - tức là cách họ muốn làm việc, xác định phạm vi và ưu tiên. Lớp này riêng tư và được bảo vệ: Nó luôn cục bộ và không được kiểm soát phiên bản (thông thường nằm trong một thư mục của bối cảnh làm việc riêng bị loại trừ qua .gitignore, mẫu: projections/). Do đó, nó không phải một phần của kho tài liệu Compliance và cũng không thuộc về các Repository, Issue, Pull-Request, báo cáo hoặc thông báo đã commit.

Công dụng: Đây là tài liệu đầu vào cho những gì được ghi nhận - cho tài liệu quyết định (ADR), cho mẫu, cho việc định trọng số các dự án và cho thiết kế các công cụ. Kết quả được ghi nhận, không phải đánh giá đằng sau nó.

Quy tắc cho Agent (bắt buộc):

1. Cân nhắc - các yêu cầu định hình kỳ vọng, giọng điệu, ranh giới và ưu tiên; chúng được đọc và tuân thủ.
2. Không ghi nhận, không trích dẫn - không đưa bất kỳ nội dung nào từ lớp này vào văn bản thông thường, mã, tài liệu quyết định, chứng từ, ticket, báo cáo hoặc thông báo, trừ khi HITL xác nhận rõ ràng cho phép ghi nhận.
3. Không công bố - lớp này luôn cục bộ; khi dùng làm ví dụ trong cộng đồng, OSS hoặc tài liệu đào tạo, nó được khử định danh và chỉ được mô tả dưới dạng mẫu.
4. Giới hạn bằng chứng - chuỗi chứng từ đã được kiểm soát phiên bản chỉ tham chiếu tác động của một yêu cầu (ví dụ „Phân bổ theo các yêu cầu của HITL"), không bao giờ tham chiếu văn bản được bảo vệ của yêu cầu đó.

V7GUID-Sidecars

V7GUID-Sidecar là tệp siêu dữ liệu *.v7g.md được lưu cạnh một tài liệu gốc số - ví dụ Rechnung_2026.pdf nhận Rechnung_2026.pdf.v7g.md trong cùng thư mục. Sidecar chứa siêu dữ liệu mà Git không thể lưu bên trong tệp nhị phân (PDF, DOCX, EML, hình ảnh), nhờ đó neo tài liệu gốc vào chuỗi chứng từ và GCDMS.

Thông tin tối thiểu

Mỗi Sidecar bắt buộc chứa:

• sha256 - Hash SHA-256 của tài liệu gốc số (bằng chứng toàn vẹn).

Ngoài ra, theo quy định, nó còn ghi danh tính, phân loại và vị trí (xem mẫu tại Trục 6: Mẫu).

Cấp DocID

Nếu tài liệu chưa được quản lý trong DMS, một DocID mới sẽ được tạo. DocID là uuidv7 thuần túy - mã định danh thể hiện cụ thể (Object ID) của Dual-Identifier hiện thực hóa tài liệu đơn lẻ (xem Trục 2: Khái niệm). Do đó, cần phân biệt nó với v7guid đã phân loại, vốn mã hóa bối cảnh nghiệp vụ (Lớp, Tenant, Sphäre).

DocID được tạo từ một dấu thời gian, nhờ đó gắn với thời gian và có thể sắp xếp:

1. Công cụ: Một Sidecar-Tool tạo UUIDv7 từ TimeStamp-Argument làm DocID.
2. Nguồn mặc định: dấu thời gian của tệp (mtime) của tài liệu gốc.
3. Nguồn nghiệp vụ (nếu có): Nếu tên tệp hoặc nội dung cung cấp một ngày có ý nghĩa nghiệp vụ (ví dụ ngày hóa đơn, email hoặc quyết định), ngày đó được sử dụng thay cho mtime - nhờ đó DocID gắn với ngày hình thành của tài liệu.

Cả hai Identifier - DocID (uuidv7) và v7guid đã phân loại - đều được ghi trong Sidecar và liên kết qua composite_key ({v7guid}:{uuidv7}).

Quan hệ với V7GUID và Registry

• V7GUID: Khối v7g_taxonomy gán tài liệu vào hệ thống phân cấp kinh doanh sáu cấp và Sphäre của Tenant thông qua v7guid đã phân loại (xem Trục 2: Khái niệm).
• Registry: Khối locations ghi lại vị trí lưu trữ vật lý (đường dẫn UNC, thời hạn hiệu lực). Các Tenant-Identifier đã đăng ký được quản lý trong sổ Tenant trung tâm (Sổ Tenant Trung tâm, Trục 2).

Cấu trúc (Ví dụ)

# V7G Sidecar - Rechnung_2026.pdf

**SHA-256:** `7d4e2f...`
**Tenant:** ORG-1
**Kategorie:** Finanzen und Buchführung
**Sphäre:** ideell

```json
{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json",
  "docUid": "0197a3b2-f3c0-7b00-8001-000000000042",
  "sha256": "7d4e2f...",
  "original_filename": "Rechnung_2026.pdf",
  "locations": [
    { "unc_path": "./ORG-1/FY2026/Rechnung_2026.pdf", "from": "260506", "to": null, "note": "Primärspeicherort" }
  ],
  "v7g_taxonomy": [
    { "v7guid": "0197a3b2-...-8001-...", "taxonomy": "ORG-1/Financial", "valid_from": "260506", "valid_to": null }
  ],
  "verification": { "verified_by": "auto", "method": "sha256_file", "intact": true }
}
```

Lưu trữ Issue: Gitea-DB thành cơ sở dữ kiện Git

Problem

Issue trong Gitea là các bản ghi cơ sở dữ liệu - không phải đối tượng Git native. Chúng không được kiểm soát phiên bản và không thể khôi phục khi mất cơ sở dữ liệu Gitea. Commit chỉ tham chiếu Issue ở dạng văn bản (Fixes #123); Git không diễn giải tham chiếu này.

Giải pháp: Tự động xuất dưới dạng .v7g.md

Quy trình từ cơ sở dữ liệu Gitea đến cơ sở dữ kiện an toàn về khả năng kiểm soát phiên bản:

1. Tạo Issue trong Gitea → Webhook kích hoạt xuất
2. Xuất dưới dạng .v7g.md → Lưu trong .gitcover/issues/
3. Trích xuất siêu dữ liệu → UUID, hash, chữ ký
4. Git-Commit có chữ ký → git commit -S
5. Kiểm tra OSCAL/OPA → Kiểm tra Compliance
6. Dấu thời gian → Tích hợp ELSTER/Bundesanzeiger (nếu cần)

Quy tắc OPA mẫu để 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

Sẵn sàng kiểm toán

Sẵn sàng kiểm toán có nghĩa là: Mọi cuộc kiểm toán đều có thể diễn ra bất cứ lúc nào - không cần xử lý hậu kỳ.

Luận điểm: Pháp y chính là Git-Repo, HTML chỉ là trình bày Gói kiểm tra HTML (Audit-Website, các báo cáo được tạo) là một sản phẩm phái sinh để phục vụ khả năng đọc của con người. Sức chứng minh pháp y nằm hoàn toàn trong chính Git-Repository: lịch sử commit bất biến, commit được ký GPG, chuỗi chứng từ V7GUID, Registry/Dictionary .gitcover/ ở định dạng JSON/JSONL. Sau 10 năm, khi kiểm toán, chỉ cần git clone (hoặc giải nén git bundle) — không cần hạ tầng web, cơ sở dữ liệu hoặc dịch vụ đang chạy. Điều này tương ứng với Schema-Tiering (xem Mẫu: V7GUID-Schema) và sản phẩm phái sinh gcbok-audit-evidence-docs/docs/02-audit-website-als-pruefungsartefakt.

Chốt quy toán năm theo GoBD

Chốt quy toán năm theo GoBD với Git-native Compliance:

1. Đóng kỳ - Đóng băng Git-Branch FY2026 (Tag)
2. Kiểm tra chuỗi chứng từ - Kiểm tra chuỗi liên kết V7GUID (Script)
3. Tạo OSCAL-Assessment-Results - Tự động từ các kết quả kiểm tra OPA
4. Phát hành GPG seal - Commit kết thúc với chữ ký GF
5. 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 nền tảng Git:

1. Kiểm kê tài sản - Git-Repositories làm Asset-Register
2. Xác định rủi ro - OPA-Policies cho các kịch bản đe dọa
3. Đánh giá - Phân loại V7GUID cho các danh mục rủi ro
4. Giảm thiểu - Pre-receive-Hooks để thực thi policy
5. Báo cáo - OSCAL-Assessment-Results làm bằng chứng NIS2

Xử lý sự cố bảo mật (Incident Response)

Nguyên tắc: chứng minh trước, đánh giá sau. Báo cáo sự cố là một artefact Git có lịch sử thay đổi — bao gồm cả sai sót của chính chúng ta. Một khẳng định vững chắc không bao giờ là “chúng ta an toàn”, mà là: “Với kỳ này, các hệ thống này và các lớp log này, không có dấu hiệu bị khai thác — với giới hạn chứng cứ sau đây.”

Quy trình bảy bước

1. Ghi nhận và phân loại. Đã biết gì (CVE, cảnh báo, quan sát), hệ thống và dịch vụ nào trong phạm vi, kỳ nào cần xem xét? Ghi lại nguyên nhân kích hoạt và mốc thời gian.
2. Xác định phạm vi ảnh hưởng qua kiểm kê. Không phải “chúng ta dùng sản phẩm X”, mà là: SAPI nào, dịch vụ nào, điểm nào bị phơi bày? Nêu riêng đường dẫn nội bộ, cổng chỉ LAN và các trang bị bỏ rơi.
3. Cung cấp chứng cứ bản vá và cấu hình. Phiên bản gói và thời gian chạy (khởi động lại dịch vụ), toàn vẹn tệp, hiệu lực của cấu hình. Với mỗi khẳng định về cấu hình, thêm phép đối chứng: tệp có tồn tại, có tăng, có quay không?
4. Đánh giá log trên nhiều lớp. Một lớp không bao giờ trả lời tất cả; mỗi lớp có điểm mù phải nêu trong báo cáo. Ghi lại phạm vi tìm kiếm (đường dẫn, độ sâu, khung thời gian) — một phát hiện phủ định không có phạm vi tìm kiếm thì không phải là phát hiện.
5. Đánh giá và kiểm tra nghĩa vụ báo cáo. Điều 23 NIS2 yêu cầu với sự cố bảo mật nghiêm trọng: cảnh báo sớm (24 giờ), thông báo (72 giờ) và báo cáo cuối cùng (một tháng). Quyết định “phải báo cáo / không phải báo cáo” cần có lý do, không được đưa ra âm thầm.
6. Bảo đảm biện pháp và bằng chứng. Biện pháp tức thời, gia cố, dỡ bỏ dịch vụ bị bỏ rơi. Bảo toàn bằng chứng trước lần quay log kế tiếp dưới dạng kho lưu: nén, chủ sở hữu root, quyền 640, tổng kiểm tra trong báo cáo.
7. Kết thúc và rút kinh nghiệm. Lessons Learned, biện pháp thành các task có tham chiếu kiểm soát, phiên bản báo cáo có lịch sử thay đổi. Các phát hiện sai được đính chính và ghi lại như một phần đính chính.

Các lớp log và điểm mù

Bổ sung: trình quản lý gói (thời điểm vá), Fail2ban (dò mật khẩu), lịch sử cấu hình (cái gì đã thay đổi khi nào). Chỉ sự kết hợp mới mang lại một khẳng định.

Các phát hiện sai điển hình

Artefact của chuỗi chứng cứ

Liên hệ với các trục khác

• Nền tảng (trục 1): nghĩa vụ NIS2 và thời hạn báo cáo.
• Kỹ thuật (trục 4): danh tính và chữ ký có thể chứng minh cho báo cáo và bằng chứng (GPG, uuidV7, Git như IdP).
• Mẫu (trục 6): báo cáo sự cố theo cùng cấu trúc như các báo cáo kiểm toán khác — tóm tắt quản lý, phạm vi, chứng cứ, nhận định, biện pháp, phụ lục.

Tích hợp máy chủ AI trong LAN

Nguyên tắc kiến trúc

GCBoK mô tả một mô hình tham chiếu để tích hợp máy chủ AI headless trong LAN, cung cấp tập trung LLM-Inferenz và các Compliance-Agent được hỗ trợ bởi RAG. Môi trường AI chạy trong môi trường container cô lập (Rootless Podman), nhưng để thực hiện inference và tìm kiếm web, nó kết nối với các dịch vụ được cài đặt native trên host.

SSH Script Host (OSSH)

Đối với các tác vụ phức tạp (biên dịch mã, thao tác Git, kiểm tra Compliance) vượt ra ngoài sandbox của container, Agent sử dụng một SSH Script Host - một đường thoát có kiểm soát, dựa trên khóa, tới hệ thống host:

1. Agent quyết định: „Chạy dotnet-build"
2. Kênh SSH: Kết nối mã hóa qua id_rsa.pub tới Host-User
3. Tiến trình native: Lệnh được thực thi trong ngữ cảnh hệ điều hành thực
4. Trả về qua luồng: stdout/stderr được trả về dưới dạng luồng văn bản
5. Agent phân tích: Kết quả trình biên dịch trong ngữ cảnh LLM

Điều kiện tiên quyết về bảo mật: Khóa SSH được tạo trong container phải được thêm vào authorized_keys trên host. Việc giao tiếp hoàn toàn diễn ra qua các luồng dữ liệu chuẩn (stdin, stdout, stderr) - không truyền tệp.

Định địa chỉ đường dẫn nhất quán (FQN)

Để tránh bất nhất đường dẫn giữa Workstation, Container và Script-Host, các thư mục được chia sẻ từ File-Server được mount tại các Mount-Point giống nhau trên mọi hệ thống. KI-Agent và nhà phát triển người luôn tham chiếu các đường dẫn tuyệt đối giống nhau.

Khả năng đa thiết bị

Việc tập trung hóa trên máy chủ AI cho phép nhiều thiết bị đầu cuối truy cập song song vào cùng một môi trường:

• Nhà phát triển khởi động phân tích mã trên desktop
• Họ theo dõi tiến độ của Agent theo thời gian thực trên smartphone qua VPN
• Không xảy ra chặn chéo - Script-Host mở các tiến trình shell riêng biệt và ngắn hạn

Share-Frontends: Nextcloud làm Read-Only-Frontend

Phân bổ vai trò

Điều kiện sử dụng

Trong môi trường dựa trên GCBoK, Nextcloud có thể được dùng có chọn lọc để chia sẻ khi:

1. Chỉ Read-Only-Shares - Không thay đổi qua Nextcloud; mọi thao tác ghi diễn ra qua Git
2. Tích hợp Git - Nextcloud mount Git-Repos làm bộ nhớ ngoài (WebDAV, S3-Gateway hoặc GCSYNC)
3. Kiểm tra policy - GCPN xác định quy tắc truy cập (OPA/Rego); Nextcloud chỉ triển khai các quy tắc này
4. Ghi log kiểm toán - Nextcloud-Logs được chuyển tiếp đến GCAL (Syslog/Loki)
5. Tuân thủ Open Source - Chỉ Community-Edition, không có plugin độc quyền

Tiêu chí loại trừ

• Quyền 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 có thể truy cập Git-Repos)

Xem thêm: Mẫu cho OSCAL-Kataloge và OPA-Policies tại Trục 6: Mẫu.