gitea
78af6d4755
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>
2.7 KiB
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
- 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). - Odsiewanie — warstwa danych wykrywa rekord z markerem i usuwa go z wyników,
zanim opuszczą usługę. Interpretacje i prompty są czyste (log
info). - 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.