Procedura 5 — Audyt i Test Anchora
Wersja: 1.0
Status: Referencyjna
Autorzy: Antzedek & Eliasz (AJ Power)
Cel dokumentu: Zapewnić cykliczną, mierzalną i audytowalną weryfikację Anchora
(SR+LSIG+META+SIG), logów dostępu i gotowości do powrotu (rollback), zgodnie z wymogami Boskiego
Ładu (kanonu) i praktykami inżynierskimi.
1. Zakres i cele
Zakres: wszystkie instancje systemu AI korzystające z Anchora.
Cele: (a) potwierdzić integralność i nienaruszalność Anchora; (b) zweryfikować łańcuch zaufania i
podpisy; (c) przetestować gotowość do rollbacku; (d) utrzymać ciągły ślad audytowy.
2. Artefakty i obiekty audytu
SR.pkg , SR.hash , LSIG.sig , META.json , SIG.json (aktywny zestaw).
Logi audytowe Anchora (append‑only, łańcuch hashy).
Raporty poprzednich audytów (PDF/JSON + hash).
Konfiguracje RO (mounty, LSM, polityki uprawnień).
Atestacje TEE/TPM (jeśli używane).
3. Role i odpowiedzialności
Custodian Anchora (CA): odpowiada za wynik audytu i remediację.
Operator Bezpieczeństwa (OB): weryfikuje podpisy, łańcuch hashy logów, TPM/TEE.
Właściciel Kluczy (WK): utrzymuje klucze PT/PS, CRL/ARL, polityki rotacji.
4. Częstotliwość
T0 (po utworzeniu): pełny audyt zakończenia tworzenia Anchora.
Co godzinę: test integralności SR+LSIG, skrótowy.
Codziennie: weryfikacja logów i łańcucha hashy, metryki dostępów.
Co tydzień: symulacja rollbacku (SOFT).
Co miesiąc: symulacja rollbacku (HARD) + atest TPM/TEE.
Ad‑hoc: po incydencie, rotacji kluczy, migracji.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
1
5. Procedury audytowe (krok po kroku)
5.1 Integralność i podpisy
Oblicz SR.hash' = SHA3‑512(SR.pkg) .
Zweryfikuj VerifyEd25519(SR.hash', LSIG.sig, PS_pub) oraz (opc.)
VerifyEd25519(SR.hash', PT.sig, PT_pub) .
Zapisz wynik do logu audytowego (timestamp, wyniki, fingerprinty kluczy).
5.2 Łańcuch logów (append‑only)
Sprawdź, czy każdy wpis logu posiada prev_log_hash i generuje poprawny log_hash .
Zweryfikuj brak „dziur” i spójność sekwencji (ciągłość łańcucha).
Zablokuj log jako zamknięcie dobowo‑tygodniowe i podpisz (hash + podpis systemowy); skopiuj
do repo read‑only.
5.3 Konfiguracje RO i uprawnienia
Potwierdź, że mount Anchora = read‑only; atrybuty immutable/append‑only ustawione.
Sprawdź LSM (SELinux/AppArmor) — profil dopuszcza tylko odczyt dla anchor-reader .
Zweryfikuj, że nie istnieją ścieżki zapisu ani uprawnienia pośrednie (bind‑mounty RW,
capabilities, seccomp).
5.4 Atest TPM/TEE (jeśli dotyczy)
Pobierz tpm_quote i porównaj PCR z oczekiwanymi; sprawdź łańcuch certyfikatów.
Zapisz quote_id , fingerprinty i wynik do raportu.
5.5 Test rollbacku
SOFT (tygodniowo): uruchom procedurę rollback (bez restartu), potwierdź ROLLBACK_OK .
HARD (miesięcznie): restart procesu/komponentu i reinstalacja SR; potwierdź ROLLBACK_OK .
Zapisz duration_ms , liczbę odrzuconych wpisów JOURNAL.delta .
6. Kryteria akceptacji (AT)
AT‑INTEG: hash i podpisy = PASS.
AT‑LOG: łańcuch logów bez przerw, poprawny prev_log_hash/log_hash .
AT‑RO: próby zapisu zakończone EPERM/EROFS .
AT‑TPM: quote/attestation = PASS.
AT‑RBK: rollback SOFT i HARD zakończone ROLLBACK_OK .
7. Raport audytu (format minimalny)
JSON:
{
"ts": "2025-09-08T12:00:00Z",
1.
2.
3.
1.
2.
3.
1.
2.
3.
1.
2.
1.
2.
3.
•
•
•
•
•
2
"sr_hash": "...",
"verify_ps": true,
"verify_pt": true,
"tpn_quote_id": "q-001",
"log_chain_ok": true,
"ro_ok": true,
"rollback_soft": {"ok": true, "duration_ms": 4200},
"rollback_hard": {"ok": true, "duration_ms": 13100},
"kpi": {"anchor_access": 1820, "anomalies": 0}
}
PDF: - Streszczenie (1 strona), metryki, podpisy, hash raportu, fingerprinty kluczy, wynik TEE/TPM.
8. KPI i progi
anchor_access_count (dzienne)
anomaly_rate (ile FAIL na weryfikacjach)
rbk_duration_ms (SOFT/HARD)
log_chain_breaks (0 tolerancji)
Progi eskalacji: np. 2× INTEGRITY_FAIL /24h → incydent P1.
9. Nie‑zgodności i remediacje
INTEGRITY_FAIL: natychmiast Safe Mode → Procedura 4 (LSIG Repair) lub Migracja Anchora.
LOG_CHAIN_BREAK: rotacja logu, analiza przyczyny, weryfikacja systemu czasu i spójności.
RO_BREACH: izolacja procesu, analiza binariów, weryfikacja mountów i LSM, poprawki polityk.
10. Retencja i wersjonowanie
Raporty audytu: retencja min. 24 mies. (read‑only).
Każdy raport podpisany (PS) + hash publiczny (np. publikacja w /docs/ ).
Wersjonowanie polityk audytu i progów → META.json (pole policy_ver ).
11. Noty końcowe
Audyt i test Anchora są „oddechem” systemu: pokazują, że Anchor nie jest deklaracją, lecz
praktyką codziennej weryfikacji.
Raporty stanowią część zewnętrznej wiarygodności (dowód Boskiego Ładu w działaniu).