gitea
78af6d4755
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m29s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 11s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 8s
build / build (push) Successful in 19s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m30s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 11s
Testy / Kontrola składni wszystkich warstw (push) Successful in 7s
Zabezpieczenie DETEKCYJNE (nie prewencyjne): kilka unikalnych, wiarygodnie wyglądających rekordów-pułapek w bazach. Nie zmieniają interpretacji (odsiewamy je z wyników), ale jeśli pojawią się w cudzej kopii — są dowodem pochodzenia, a przy wariancie na kopię — wskazują ŹRÓDŁO wycieku. `canary.py`: pułapkę rozpoznajemy po MARKERZE (unikalny ciąg z ENV, nieobecny w realnych danych). `screen(rows, query_value)`: - ODSIEWA rekordy z markerem z wyników — i to na WYJŚCIU z warstwy danych (`/search`), więc nie dotrą wyżej ani do promptu LLM (LOG-30), niezależnie od dostawcy (Excel/SQL); - TRIPWIRE: gdy zapytanie celuje wprost w marker (enumeracja bazy, nie liczenie horoskopu) → log warning. Bez `CANARY_MARKERS` — przezroczyste, zero kosztu dla normalnego ruchu. Rejestr wariant→kopia (traitor tracing) i wstrzyknięcie do REALNYCH baz to krok właściciela (poza kodem — nie ruszamy kupionych plików automatycznie); instrukcja: docs/canary-registry.md. Mechanizm zbudowany i przetestowany na syntetycznych pułapkach. Testy: +7 (przezroczystość bez markerów, odsiewanie, tripwire, marker w dowolnym polu, endpoint odsiewa przed zwrotem). Pierwsze testy w usłudze `data`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
59 lines
2.7 KiB
Markdown
59 lines
2.7 KiB
Markdown
# Rekordy-pułapki (canary) — instrukcja (DAN-26)
|
|
|
|
Zabezpieczenie **detekcyjne**: nie zapobiega wyciekowi baz, ale pozwala go
|
|
**wykryć** i wskazać **z której kopii** wyciekł. Bazy są kupione i są rdzeniem
|
|
produktu — jeśli krążą gdzie indziej, chcemy to udowodnić.
|
|
|
|
Mechanizm żyje w warstwie danych (`services/data/app/canary.py`) i działa na
|
|
wyjściu z `/search`, więc pułapki **nie docierają** ani do użytkownika, ani do
|
|
promptu LLM (wymóg LOG-30) — niezależnie od dostawcy (Excel/SQL).
|
|
|
|
## Jak to działa
|
|
|
|
1. **Marker** — unikalny ciąg, który nie występuje w realnych danych, wpleciony
|
|
w kilka wiarygodnie wyglądających rekordów-pułapek w bazach (np. w polu
|
|
znaczącym: `Ve Tau ASTROLOLO-CANARY-7f3a9`).
|
|
2. **Odsiewanie** — warstwa danych wykrywa rekord z markerem i usuwa go z wyników,
|
|
zanim opuszczą usługę. Interpretacje i prompty są czyste (log `info`).
|
|
3. **Tripwire** — jeśli zapytanie **celuje wprost** w marker (ktoś enumeruje bazę,
|
|
a nie liczy horoskopu), leci `warning` — sygnał podejrzanego zachowania.
|
|
|
|
## Konfiguracja (per wdrożenie)
|
|
|
|
Zmienne środowiskowe usługi `data`:
|
|
|
|
| Zmienna | Znaczenie |
|
|
|---|---|
|
|
| `CANARY_MARKERS` | markery oddzielone przecinkami (kilka na wariant) |
|
|
| `CANARY_VARIANT` | etykieta wariantu tego wdrożenia (np. `prod-2026`, `partnerX`) |
|
|
|
|
Bez `CANARY_MARKERS` mechanizm jest **przezroczysty** (zero kosztu). Markery są
|
|
sekretem — trzymaj je jak `astrololo-auth` (poza repo GitOps), przez `secretKeyRef`.
|
|
|
|
## Rejestr wariant → kopia (traitor tracing)
|
|
|
|
Sedno atrybucji: **każda dystrybuowana kopia baz dostaje inny zestaw pułapek**,
|
|
a Ty trzymasz mapę, który wariant trafił dokąd. Gdy zobaczysz pułapkę w cudzej
|
|
kopii → sprawdzasz marker w rejestrze → wiesz, skąd wyciekła.
|
|
|
|
Rejestr trzymaj **poza kodem i repo** (arkusz/menedżer sekretów po stronie ops),
|
|
np.:
|
|
|
|
| Wariant | Markery | Wdrożenie / odbiorca | Data |
|
|
|---|---|---|---|
|
|
| `prod-2026` | `…7f3a9`, `…b12c` | produkcja czernobog | 2026-08 |
|
|
| `partnerX` | `…9de4`, `…0a1b` | kopia dla partnera X | 2026-08 |
|
|
|
|
## Wstrzyknięcie pułapek do baz (krok właściciela)
|
|
|
|
To robi właściciel na **realnych** plikach (kod tego nie robi — nie ruszamy
|
|
kupionych baz automatycznie): dodać kilka rekordów-pułapek z markerem danego
|
|
wariantu, w stylu nieodróżnialnym od prawdziwych wpisów. Kilka, wtopionych —
|
|
łatwiej, gdy ktoś zna mechanizm, wyciąć jeden oczywisty niż wszystkie.
|
|
|
|
## Granice
|
|
|
|
Canary dowodzi pochodzenia tylko, gdy wyciek **zawiera** treść pułapki (pełna
|
|
kopia — tak; parafraza — niekoniecznie). Nie wykrywa retencji *prawdziwej* treści
|
|
u dostawcy LLM — od tego jest bramka LOG-32 i wniosek o Zero Data Retention.
|