Trục 5: Quy trình thực hiện

Onboarding cho DNNVV

Việc gia nhập Git-native Compliance của DNNVV tuân theo một lộ trình từng bước:

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

Dành cho doanh nhân từ mức hoạt động phụ

Việc bắt đầu có thể bắt đầu bằng một câu chuyện rất đơn giản: GCDMS để lưu trữ chứng từ, GCPN cho chuỗi bằng chứng. Sau đó mở rộng: OSCAL-Policies, xác thực OPA, Multi-Tenant.

Onboarding tương tác: “Thành phố Tuân thủ”

Thay vì bảng câu hỏi cổ điển, quá trình onboarding diễn ra như một cấu trúc mô-đun theo khái niệm một thành phố trên nền tấm Lego. Mỗi quyết định kiến trúc và mỗi yêu cầu chuyên môn tương ứng với một viên gạch hoặc một cụm công trình (bộ Lego), được lưu và đánh phiên bản như một mô-đun có cấu trúc trong kho Git mặc định mới được khởi tạo.

Phép loại suy cho người dùng:

• Tấm nền: Kho Git trống, vừa được tạo cho tenant trong hạ tầng của họ. Nó cung cấp khung chuẩn hóa (các núm gắn), trên đó mọi thứ được gắn vào.
• Các viên gạch: Cấu hình mô-đun và tệp dịch vụ. Chỉ khi một viên gạch khớp vào (Git-Commit), chức năng hoặc kiểm tra tuân thủ tương ứng mới được kích hoạt.

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

Hệ thống tự động tạo kho mặc định cho tenant. Trợ lý onboarding xác định danh tính của doanh nghiệp. Dữ liệu được lưu có cấu trúc trong kho 'TOP' (Tenant Organization Profile) - Git-Commit đầu tiên đã là quy trình tuân thủ có thể kiểm toán đầu tiên. Ngoài ra: Tenants tất nhiên cũng có thể được tổ chức theo thứ bậc, giống như các cấu trúc doanh nghiệp mà họ thuộc về.

Giai đoạn 2 - Đi dây hạ tầng (Mạng cung cấp):

Trợ lý ghi nhận bối cảnh CNTT: máy tính xách tay tại nơi làm việc, file-server, ưu tiên đám mây hoặc hạ tầng lai. Các tham số như kết nối Internet, miền, đường dẫn lưu trữ, v.v. được đưa vào thông tin hạ tầng và chuẩn bị các đường dẫn cho các kết nối chéo (others.json).

Giai đoạn 3 - Dựng tòa nhà (Phạm vi chuyên môn):

Người dùng quyết định theo mô-đun những lĩnh vực quy định mà thành phố của mình sẽ 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 ngay lập tức tạo ra một Git-Commit sạch, hệ thống được ghi chép hoàn toàn có thể kiểm toá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

Việc liên kết OIDC-Claims với others.json là giải pháp lý tưởng cho môi trường tuân thủ đa tenant, an toàn với người không chuyên. Trong others.json tập hợp:

1. Tuyến đường chuẩn tắc đến các kho Git riêng của tenant
2. Kết nối chéo đến các kho Git của tenant khác, nếu tenant là thành viên của một nhóm

Truy cập được kiểm soát thông qua OIDC-Claims (vai trò và custom claims như tenant_id, org_unit_id và tư cách thành viên nhóm). Một Inlet-Pipeline đọc others.json theo claim của người dùng 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 kho sau: [Đường dẫn 1], [Đường dẫn 2]. Không thực thi lệnh nào bên ngoài các thư mục này.

Mô hình claim hai cấp cho quyền truy cập PII

Để truy cập dữ liệu cá nhân (PII), GCBoK định nghĩa một hệ thống phân cấp claim với hai cấp (xem Kỹ thuật: Git như IdP:

others.json ánh xạ các claim này sang đường dẫn kho:

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

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

Đối với người dùng cuối, bộ máy bảo mật này vẫn 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 thông qua Formular-Bridging

Giao diện chat phù hợp cho ngữ cảnh và phân tích, không phù hợp để thu thập kiểu dữ liệu nghiêm ngặt (IBAN, mã bưu chính, lược đồ OSCAL). Do đó GCBoK khuyến nghị Formular-Bridging:

1. AI nhận biết nhu cầu: Người dùng nói “Tôi muốn thêm một địa điểm kinh doanh mới.”
2. URL biểu mẫu động: AI xuất ra một liên kết đến giao diện nhập liệu web đã được xác thực (Blazor WASM/PWA), được liên kết với quản lý phiên và người dùng.
3. Nhập liệu được đóng gói: Người dùng điền biểu mẫu - được xác thực 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 kho tenant và kích hoạt commit.
5. 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: Xác thực trước khi lưu bảo vệ Single Source of Truth. LLM không thao túng quá trình ghi. Việc xác thực 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/ trong root của một kho GitCover là kho lưu trữ trung tâm cho mọi hiện vật không phải mã. Nó phục vụ an toàn kiểm toán, tuân thủ (GoBD/AO) và duy trì audit trail.

Bố cục thư mục

.gitcover/
├── issues/              # Gitea-Issues als .gc.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ên tệp

Định dạng chung: {YYMMDD}_{human-readable-key}_{Beschreibung}.gc.md

V7GUID và docUid nằm trong hiện vật dữ liệu, không nằm trong tên tệp; tên tệp mang chữ ký thời gian {YYMMDD}.

Hiện vật dữ liệu (.gc.md)

Hiện vật dữ liệu tuân theo mẫu “Con người đọc được trước, JSON sau cùng” (JSON-First, không có YAML-Frontmatter):

{
  "docUid": "018e312f-3e4f-7000-8000-000000000000",
  "v7guid": "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"
  },
  "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

Các repo GitCover được tự động cấu hình với hooks/webhooks khi init hoặc Tenant Onboarding:

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

Việc đánh phiên bản các hooks/webhooks này cũng diễn ra qua Git, nhờ đó các thay đổi có thể truy vết và kiểm toán (tự tham chiếu, có phiên bản, an toàn kiểm toán). Bản thân các hook có thể là hiện vật mã có phiên bản, nằm trong .gitcover/hooks/ và được cập nhật khi cần, đồng thời được ghi chép tuân thủ GoBD hoặc NIS2.

Các quy định riêng của HITL - Quy ước và quy tắc cho tác nhân

Ngoài tài liệu tuân thủ được đánh phiên bản, mỗi người làm việc còn duy trì các quy định cá nhân của mình - tức cách họ muốn tự làm việc, phân định ranh giới và ưu tiên. Lớp này là riêng tư và được bảo vệ: nó cục bộ và không được đánh phiên bản (thông thường nằm trong một thư mục bị loại trừ bởi .gitignore trong ngữ cảnh làm việc riêng, mẫu: projections/). Do đó nó không phải là một phần của kho tài liệu tuân thủ và cũng không thuộc về các kho, issue, pull request, báo cáo hoặc hiển thị đã commit.

Mục đích: Nó là nguyên liệu đầu vào cho những gì được ghi chép - cho tài liệu quyết định (ADR), cho mẫu, cho việc cân nhắc ưu tiên các dự định và cho việc thiết kế công cụ. Kết quả được ghi chép, không phải đánh giá phía sau.

Quy tắc cho tác nhân (bắt buộc):

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

GitCover-Sidecars (.gc.md)

Một GitCover-Sidecar là tệp siêu dữ liệu *.gc.md được đặt cạnh một tài liệu gốc kỹ thuật số - ví dụ Rechnung_2026.pdf có Rechnung_2026.pdf.gc.md trong cùng thư mục. Sidecar mang siêu dữ liệu mà Git không thể lưu bên trong một tệp nhị phân (PDF, DOCX, EML, hình ảnh) và nhờ đó neo bản 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 - mã băm SHA-256 của tài liệu gốc kỹ thuật số (bằng chứng toàn vẹn).

Ngoài ra, nó thường chứa 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 được tạo. DocID là uuidv7 thuần - định danh thể hiện cụ thể (Object ID) của dual identifier, thứ hiện thực hóa từng tài liệu riêng lẻ (xem Trục 2: Khái niệm). Do đó nó cần được phân biệt với v7guid đã được phân loại, vốn mã hóa ngữ cảnh chuyên môn (lớp, tenant, lĩnh vực).

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

1. Công cụ: Một công cụ sidecar tạo UUIDv7 từ một đối số TimeStamp 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 chuyên môn (nếu có): Nếu tên tệp hoặc nội dung cung cấp một ngày có ý nghĩa chuyên môn (ví dụ ngày hóa đơn, email hoặc quyết định), ngày đó được 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 định danh - DocID (uuidv7) và v7guid đã phân loại - đều được ghi trong sidecar và được liên kết qua composite_key ({v7guid}:{uuidv7}).

Liên hệ với V7GUID và Registry

• V7GUID: Khối v7g_taxonomy phân loại tài liệu thông qua v7guid đã phân loại vào hệ thống phân cấp doanh nghiệp sáu cấp và lĩnh vực tenant (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, khoảng thời gian hiệu lực). Các định danh tenant đã đăng ký được quản lý trong sổ đăng ký tenant trung tâm (Zentrales Tenant-Register, Trục 2).

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

# GitCover 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-2.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: từ Gitea-DB sang cơ sở dữ kiện Git

Vấn đề

Gitea-Issues là các bản ghi cơ sở dữ liệu - không phải đối tượng Git gốc. Chúng không được đánh phiên bản và không thể tái tạo nếu mất cơ sở dữ liệu Gitea. Commit chỉ tham chiếu issue 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: Xuất tự động dưới dạng .gc.md

Quy trình từ cơ sở dữ liệu Gitea đến cơ sở dữ kiện an toàn kiểm toán:

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

Ví dụ quy tắc OPA để xác thực 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 nghĩa là: mọi cuộc kiểm toán có thể diễn ra bất cứ lúc nào - không cần chuẩn bị hậu kỳ.

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

Kết toán năm GoBD

Kết toán năm GoBD với Git-native Compliance:

1. Đóng kỳ - đóng băng nhánh Git FY2026 (tag)
2. Xác thực chuỗi chứng từ - kiểm tra nối tiếp V7GUID (script)
3. Tạo OSCAL-Assessment-Results - tự động từ xác thực OPA
4. Cấp niêm phong GPG - commit kết thúc với chữ ký GF
5. Lưu trữ - container .gc.zip, gc-dms pack

Phân tích rủi ro NIS2

Phân tích rủi ro NIS2 trên cơ sở Git:

1. Kiểm kê tài sản - kho Git làm sổ đăng ký tài sản
2. Nhận diện 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 hạng mục rủi ro
4. Giảm thiểu - Pre-receive-Hooks để thực thi chính sách
5. Báo cáo - OSCAL-Assessment-Results làm bằng chứng NIS2

Xử lý sự cố an ninh (Incident Response)

Nguyên tắc: chứng minh trước, đánh giá sau. Một incident report là hiện vật Git có lịch sử thay đổi — cả đánh giá sai của chính mình cũng phải nằm trong đó. Phát biểu có cơ sở không bao giờ là “chúng ta an toàn”, mà là: “Đối với khoảng thời gian này, các hệ thống này và các mức log này, không có dấu hiệu bị khai thác — với giới hạn bằng chứng sau đây.”

Quy trình bảy bước

1. Ghi nhận và phân loại. Điều gì đã biết (CVE, cảnh báo, quan sát), những hệ thống và dịch vụ nào nằm trong phạm vi ảnh hưởng, cần xem xét khoảng thời gian nào? Ghi lại nguyên nhân kích hoạt và dấu thời gian.
2. Xác định mức độ ảnh hưởng qua kiểm kê. Không phải “chúng tôi dùng sản phẩm X”, mà là: SAPI nào, dịch vụ nào, endpoint nào bị lộ? Đường dẫn nội bộ, cổng chỉ LAN và các site bị bỏ rơi cần được chỉ ra riêng.
3. Dẫn chứng 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ụ), tính toàn vẹn tệp, hiệu lực của cấu hình. Với mỗi phát biểu về config, cần đối chứng: Tệp có tồn tại, có tăng trưởng, có xoay vòng không?
4. Đánh giá log qua nhiều lớp. Một lớp không bao giờ trả lời mọi câu hỏi; 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 kết quả phủ định không có phạm vi tìm kiếm không phải là kết quả.
5. Đánh giá và kiểm tra nghĩa vụ báo cáo. NIS2 Art. 23 yêu cầu khi có sự cố an ninh nghiêm trọng: cảnh báo sớm (24 giờ), báo cáo (72 giờ) và báo cáo kết thúc (một tháng). Quyết định “có nghĩa vụ báo cáo / không có nghĩa vụ báo cáo” phải được lý giải, 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, tăng cường bảo vệ, gỡ bỏ dịch vụ bị bỏ rơi. Bảo đảm bằng chứng trước lần xoay vòng tiếp theo dưới dạng lưu trữ: nén, chủ sở hữu root, quyền 640, checksum trong báo cáo.
7. Theo dõi sau. Lessons Learned, biện pháp thành task có liên kết control, phiên bản báo cáo có lịch sử thay đổi. Các phát hiện sai được sửa và ghi chép như một bản đính chính.

Các lớp log và điểm mù của chúng

Bổ sung: trình quản lý gói (thời điểm vá), Fail2ban (bruteforce), 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 phát biểu có giá trị.

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

Các hiện vật của chuỗi bằng chứng

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

• Cơ bản (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 có thể chứng minh và chữ ký cho báo cáo và bằng chứng (GPG, uuidV7, Git như IdP).
• Mẫu (Trục 6): Incident-Report tuân theo cùng cấu trúc như các báo cáo kiểm tra khác — Management Summary, phạm vi áp dụng, bằng chứng, đánh giá, 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 cho việc tích hợp một máy chủ AI headless trong LAN, cung cấp tập trung suy luận LLM và các tác nhân tuân thủ dựa trên RAG. Môi trường AI chạy trong một môi trường container cô lập (Rootless Podman), nhưng kết nối với các dịch vụ được cài đặt gốc trên host để suy luận và tìm kiếm web.

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 tuân thủ) vượt ra ngoài sandbox container, tác nhân sử dụng một SSH Script Host - một lối thoát được kiểm soát, dựa trên khóa, sang hệ thống host:

1. Tác nhân quyết định: “Chạy dotnet-build”
2. Kênh SSH: kết nối mã hóa qua id_rsa.pub đến người dùng host
3. Tiến trình gốc: lệnh được thực thi trong ngữ cảnh hệ điều hành thật
4. Trả về luồng: stdout/stderr được trả về dưới dạng luồng văn bản
5. Tác nhân phân tích: đầu ra trình biên dịch trong ngữ cảnh LLM

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

Địa chỉ hóa đườ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, các chia sẻ file-server được gắn tại các mount point giống hệt nhau trên mọi hệ thống. Tác nhân AI và nhà phát triển con người tham chiếu các đường dẫn tuyệt đối giống hệt nhau tại mọi thời điểm.

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

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

• Nhà phát triển bắt đầu phân tích mã trên desktop
• Người đó theo dõi tiến độ của tác nhân theo thời gian thực trên smartphone qua VPN
• Không có chặn lẫn nhau - script host mở các tiến trình shell riêng, ngắn hạn

Share-Frontends: Nextcloud như frontend chỉ đọc

Phân chia vai trò

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

Nextcloud có thể được dùng có chọn lọc cho các share trong môi trường dựa trên GCBoK nếu:

1. Chỉ share chỉ đọc - Không thay đổi qua Nextcloud; mọi thay đổi đều qua Git
2. Tích hợp Git - Nextcloud gắn Git-Repos như lưu trữ ngoài (WebDAV, S3-Gateway hoặc GCSYNC)
3. Xác thực chính sách - GCPN định nghĩa quy tắc truy cập (OPA/Rego); Nextcloud chỉ thực hiện chúng
4. Audit-Logging - Log Nextcloud được chuyển tiếp đến GCAL (Syslog/Loki)
5. 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 có thể truy cập Git-Repos)

Xem thêm: Mẫu cho danh mục OSCAL và OPA-Policies trong Trục 6: Mẫu.