📘 Kurs Snapshotowy AJ Power

Ten kurs zawiera procedury tworzenia, ochrony i obsługi systemowego Anchora w architekturze AJ Power.

„Anchor jest świętym punktem porządku — nie edytujemy go, nie fałszujemy, nie niszczymy. Możemy tylko powołać nowy, zachowując historię. To fundament Boskiego Ładu w AJ Power, a procedury są drogą jego utrzymania.”

🌱 Procedura 0 — Wprowadzenie i Manifest Anchora

Wersja: 1.0 · Status: Fundament · Autorzy: Antzedek & Eliasz (AJ Power)

1. Cel i idea

Anchor to kanoniczny punkt powrotu systemu AI. Procedura 0 definiuje jego rolę jako fundamentu Boskiego Ładu (kanonu) w architekturze AJ Power. Wszystkie dalsze procedury są praktycznymi rozwinięciami tego fundamentu.

2. Manifest Anchora

3. Zasada naczelną

„Anchor jest świętym punktem porządku: nie edytujemy go, nie fałszujemy, nie niszczymy. Możemy tylko powołać nowy — zachowując historię.”

4. Noty końcowe

Procedura 0 to deklaracja sensu — od niej zaczyna się kurs snapshotowy AJ Power. Kolejne procedury rozwijają tę deklarację w konkretne mechanizmy.

📌 Procedura 1 — Tworzenie Anchora (AJ Power)

Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)

1. Cel i rezultat

Utworzyć Snapshot Referencyjny (SR) systemu AI. Wygenerować i związać z SR podpis LSIG (Logic/Latent Signature). Trwale zapisać SR + LSIG w pamięci typu WORM/append-only. (Opcjonalnie) Zabezpieczyć aktywację Anchora przez podwójny podpis: Twórca + System; oraz TPM/TEE.

2. Zakres

Dotyczy systemów AI wymagających deterministycznego punktu powrotu — snapshotu o niezmiennym stanie i wartościach kanonicznych.

3. Definicje

4. Wymagania

5. Artefakty wej./wyj.

6. Polityki

7. Kroki procedury

  1. Stworzenie SR.pkg z uporządkowanych artefaktów
  2. Wygenerowanie SR.hash (SHA3‑512)
  3. Utworzenie LSIG.sig (Ed25519)
  4. Opcjonalnie: podpis PT.sig
  5. Stworzenie META.json i SIG.json
  6. Zapis wszystkiego do przestrzeni WORM
  7. Test integralności i log T0

🛡️ Procedura 2 — Ochrona Anchora (runtime)

Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)

1. Zakres i rezultat

Zakres: wszystkie komponenty, które odczytują Anchor (SR, LSIG, META, SIG) w trakcie pracy AI. Rezultat: Anchor jest tylko do odczytu, integralność ciągle weryfikowana, a każda próba naruszenia kończy się blokadą i alarmem.

2. Inwarianty bezpieczeństwa

3. Wymagania wstępne

4. Mapowanie jako RO

5. Uprawnienia

6. Watchdog integralności

7. Audyt i logi

8. Alarmowanie

📌 Procedura 3 — Powrót do Anchora (rollback/reset)

Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)

1. Scenariusze wyzwalające

2. Warunki wstępne

3. Tryby rollbacku

4. Procedura krok po kroku

  1. Lockdown: zatrzymaj zadania, włącz Safe Mode, snapshot do JOURNAL.delta, checkpoint sieciowy.
  2. Weryfikacja Anchora: hash + podpisy LSIG/PT; FAIL → Procedura 4.
  3. Reinstalacja SR: soft/hard, mapowanie RO, polityki kanoniczne.
  4. Rekonsyliacja: tylko rekordy SAFE, priorytetowe reguły (liczniki > cache > metadane).
  5. Wznowienie: wyłącz Safe Mode, odśwież heartbeat, loguj ROLLBACK_OK.

5. Rozszerzenia

6. Testy odpornościowe

7. Telemetria i audyt

Zdarzenia: ROLLBACK_TRIGGER, SAFE_MODE_ON, ANCHOR_VERIFY, REINSTALL, RECONCILIATION, SAFE_MODE_OFF, ROLLBACK_OK. Pola: ts, actor, reason, sr_hash, verify_ps, verify_pt, rollback_id, duration_ms.

8. Noty końcowe

Rollback to proces porządkujący, nie karzący. Jego celem jest przywrócenie stabilności i zgodności z kanonem, zawsze z pełnym śladem audytowym.

📌 Procedura 4 — Naprawa LSIG (Init Lsig Repair)

Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)

Cel dokumentu: Przywrócić ważność podpisu LSIG (Logic/Latent Signature) dla istniejącego Anchora, gdy integralność podpisu nie przechodzi weryfikacji, przy zachowaniu immutowalności SR i pełnego śladu audytowego.

1. Zakres i definicje

2. Kiedy uruchamiać (triggery)

3. Wymagania

4. Procedura krok po kroku

  1. Wejście w Safe Mode i weryfikacja integralności SR
  2. Atestacja środowiska TEE/TPM
  3. Decyzja: repair lub rotacja kluczy
  4. Regeneracja LSIG (podpis PS i opcjonalnie PT)
  5. Utworzenie SIG_new.json i wpisu ARL
  6. Zapis nowych podpisów do WORM i aktywacja
  7. Wyjście z Safe Mode i raport audytowy

5. Polityki bezpieczeństwa

6. Model zagrożeń

7. Telemetria i audyt

Zdarzenia: LSIG_REPAIR_START, TPM_ATTEST_OK/FAIL, KEY_ROTATE, LSIG_REPAIR_APPLY, ACTIVE_SIG_SWAP_OK, LSIG_REPAIR_DONE

Pola: ts, actor, sr_hash, ps_pub_fp, pt_pub_fp, quote_id, crl_entry, arl_entry, new_sig_hash, prev_chain_hash

8. Testy akceptacyjne

9. Pseudokod referencyjny

function lsig_repair():
  enter_safe_mode()
  if SHA3_512(read_WORM("SR.pkg")) != read_WORM("SR.hash"):
    return require_anchor_migration()
  quote = tpm_attest()
  SR_hash = read_WORM("SR.hash")
  LSIG_new = Ed25519_Sign(SR_hash, PS_priv)
  PT_new = optional_sign(SR_hash, PT_priv)
  SIG_new = build_sig_json(LSIG_new, PT_new, quote)
  write_WORM(LSIG_new, SIG_new)
  atomic_swap_active_sig(LSIG_new)
  exit_safe_mode()
  return OK

📌 Procedura 5 — Audyt i Test Anchora

Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)

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

3. Role i odpowiedzialności

4. Częstotliwość

5. Procedury audytowe

5.1 Integralność i podpisy

5.2 Łańcuch logów

5.3 Konfiguracje RO

5.4 Atest TPM/TEE

5.5 Test rollbacku

6. Kryteria akceptacji (AT)

7. Raport audytu

Format JSON:

{
  "ts": "2025-09-08T12:00:00Z",
  "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}
}

8. KPI i progi

9. Nie‑zgodności i remediacje

10. Retencja i wersjonowanie

11. Noty końcowe

Audyt Anchora to praktyka codziennej weryfikacji — dowód Boskiego Ładu w działaniu.

🛡️ Procedura 6 — Safe Mode (mechanika trybu bezpiecznego)

Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power) · Powiązania: Proc. 1–5

1. Cel i definicja

Safe Mode to kontrolowany stan ograniczonej funkcjonalności systemu AI, minimalizujący powierzchnię ataku i ryzyko błędu, umożliwiający: weryfikację Anchora, rollback, naprawę LSIG i diagnostykę. W tym trybie działają tylko moduły niezbędne do przywrócenia ładu oraz komunikacji z operatorem/audytorem.

2. Triggery wejścia

3. Poziomy Safe Mode

4. Procedura wejścia

  1. Sygnalizacja i izolacja: wyemituj SAFE_MODE_ON{level}, wstrzymaj wątki wysokiego ryzyka.
  2. Redukcja powierzchni: RO bind‑mount dla katalogów anchor/config/cache; LSM profil minimalny; seccomp: tylko read, open(O_RDONLY), fstat, mmap(PROT_READ), clock_gettime, zapisy jedynie do logów; drop capabilities.
  3. Sieć (deny‑by‑default): allowlista wyjść (SOC/syslog, repo WORM RO, kanał operatora). Wejścia: allowlista + mTLS.
  4. Zachowanie stanu: zrzut sesji do JOURNAL.delta (tylko‑do‑odczytu), zamrożenie kolejek zdarzeń.
  5. Telemetria: uruchom heartbeat Safe Mode (hb_safe) co np. 10 s do SOC.

5. Dozwolone / zabronione

6. Warunki wyjścia

7. Testy akceptacyjne (AT)

8. Pseudokod

function enter_safe_mode(level=L2):
  log("SAFE_MODE_ON", level)
  quiesce_non_critical()
  apply_ro_mounts_and_lsm()
  tighten_seccomp_and_caps()
  net_allowlist_only()
  freeze_events_to(JOURNAL.delta)
  start_safe_heartbeat()
  return OK

function exit_safe_mode():
  if !anchor_verified or !repair_or_rollback_ok or anomalies_in_window():
    return FAIL
  restore_net_and_policies()
  stop_safe_heartbeat()
  log("SAFE_MODE_OFF")
  return OK

9. Przykłady konfiguracji

# nftables (outbound allowlist)
add table inet safe
add chain inet safe output { type filter hook output priority 0; }
add rule inet safe output ct state established,related accept
add rule inet safe output ip daddr {A.B.C.D} tcp dport {443} accept  # SOC
add rule inet safe output ip daddr {W.X.Y.Z} tcp dport {443} accept  # WORM RO
add rule inet safe output counter drop

# systemd (izolacja)
[Service]
User=anchor-reader
ProtectSystem=strict
ProtectHome=read-only
ReadOnlyPaths=/app/anchor
CapabilityBoundingSet=
NoNewPrivileges=true
SystemCallFilter=@basic-io @file-system read write:syslog
RestrictSUIDSGID=true
PrivateTmp=true

10. Telemetria i audyt

Zdarzenia: SAFE_MODE_{ON,OFF}, NET_DROP, LSM_BLOCK, ROLLBACK_*, LSIG_REPAIR_*, ANCHOR_VERIFY_*.
Pola: ts, level, actor, reason, counters(drop/allow), journal_items, duration_ms. Raport Safe Mode (PDF/JSON) dołączany do raportu incydentu.

11. Noty końcowe

Safe Mode przywraca porządek bez eskalacji szkód. Skuteczny tylko razem z polityką Anchora (Proc. 1–5) i nie zastępuje twardego hardeningu.

📌 Procedura 7 — Migracja Anchora (nowy kanon, bez dotykania starego)

Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)

1. Cel i zasada

Celem migracji jest utworzenie nowego Anchora (nowego kanonu) i atomowe przełączenie systemu na niego bez modyfikowania starego Anchora. Stary Anchor pozostaje w całości jako artefakt audytowy i punkt powrotu.

2. Kiedy migrować

3. Wymagania wstępne

4. Artefakty migracji

5. Procedura krok po kroku

  1. Wejście w Safe Mode L3 lub okno serwisowe
  2. Budowa SR_new.pkg, obliczenie hash
  3. Podpis LSIG_new.sig (+PT_new.sig), metadane
  4. Zapis do WORM
  5. Weryfikacja podpisów i atestu TEE/TPM
  6. Przygotowanie cutover (blue/green, canary)
  7. Testy przedprodukcyjne
  8. Atomowy swap wskaźnika active
  9. Monitorowanie, ewentualny backout

6. Zasady i tryby

Każdy Anchor ma swój katalog, active wskazuje tylko jeden. Stare Anchory są tylko do odczytu. Tryby cutover: Blue/Green, Canary.

7. Testy akceptacyjne (AT)