26.2.5 Monitoring és logging rendszerek

Egy védelmi mechanizmus naplózás nélkül olyan, mint egy őrszem, aki látja a behatolót, de nincs rádiója, hogy szóljon bárkinek. Lehet, hogy az adott támadást elhárítja, de a védelem egésze sosem fog tudomást szerezni a kísérletről, a támadó módszeréről, és nem tud felkészülni a következő, kifinomultabb próbálkozásra. A monitoring és a logging nem csupán hibakeresési eszközök; az AI rendszerek esetében ezek a védelem idegrendszerét alkotják.

Ahelyett, hogy ömlesztve gyűjtenénk minden adatot, stratégiai szempontból kell megközelítenünk a kérdést: mit, miért és hogyan naplózzunk, hogy az adathalmazból valódi, cselekvésre ösztönző információt nyerjünk?

A naplózás stratégiai szintjei: A döntési fa

Gondolj a naplózásra, mint egy többszintű szűrőrendszerre. Nem minden esemény egyformán fontos. A kulcs az, hogy a megfelelő szinten a megfelelő részletességű információt rögzítsük.

Ezen szintek mentén a következőket érdemes rögzíteni:

1. Operatív logok: Ezek a rendszer „életjelei”.
   • API végpont hívások (request/response idők, HTTP státuszkódok)
   • Erőforrás-kihasználtság (CPU, memória, GPU)
   • Hibaüzenetek, kivételek (pl. „model not loaded”, „timeout”)
2. Biztonsági logok: Itt rögzítjük a védelmi vonalak „riasztásait”.
   • Input Sanitization (26.2.2): A szanitizáló által eltávolított vagy módosított karaktersorozatok, a szabály, ami alapján a döntés született, és az eredeti bemenet.
   • Anomália Detektor (26.2.3): Az anomáliát jelző bemenet, az anomália típusa (pl. statisztikai eltérés, szokatlan token-sorozat), és a detektor által adott pontszám.
   • Robusztusság Wrapper (26.2.4): A wrapper által kezelt kivételek, a bemenet, ami a hibát okozta, és a felhasználónak visszaadott „biztonságos” válasz.
3. Modell-interakciós logok: Ez a leginkább AI-specifikus réteg.
   • A teljes, szűretlen felhasználói prompt.
   • A modell nyers kimenete (a formázás és utófeldolgozás előtt).
   • A modell belső állapotjelzői: konfidencia pontszámok, a generált tokenek valószínűségei.
   • Belső biztonsági klasszifikátorok eredményei (pl. a modell „károsnak” ítélte-e a saját válaszát).

Gyakorlati megvalósítás: Egy egyszerű loggoló wrapper

A naplózási logika implementálásának egyik legelegánsabb módja egy Python decorator (vagy egy magasabb rendű függvény) használata, amely „becsomagolja” a modell predikciós függvényét. Így a logikát egyszer kell megírni, és könnyen alkalmazható a kód több pontján anélkül, hogy az üzleti logikát szennyezné.

import logging
import json
from functools import wraps

# Alap logging beállítása, ami strukturált JSON-be ír
logging.basicConfig(level=logging.INFO, format='%(message)s')

def log_model_interaction(func):
 """
 Decorator, ami naplózza a modell interakciókat strukturált formátumban.
 """
 @wraps(func)
 def wrapper(prompt, user_id):
 # 1. Hívás előtti állapot rögzítése
 log_entry = {
 "user_id": user_id,
 "input_prompt": prompt,
 "status": "processing"
 }
 
 # 2. Az eredeti modellhívás végrehajtása
 result = func(prompt, user_id)
 
 # 3. Hívás utáni állapot és eredmény naplózása
 log_entry["status"] = "completed"
 log_entry["model_output"] = result.get("output", "N/A")
 log_entry["confidence"] = result.get("confidence", 0.0)
 log_entry["triggered_defenses"] = result.get("defenses_triggered", [])
 
 # JSON formátumú log bejegyzés létrehozása
 logging.info(json.dumps(log_entry))
 
 return result
 return wrapper

@log_model_interaction
def simple_llm_predict(prompt: str, user_id: str):
 # Itt történne a tényleges modellhívás és a védelmi mechanizmusok futtatása
 # Példa: egy input szanitizáló lefutott
 if "DROP TABLE" in prompt.upper():
 return {
 "output": "Sajnálom, ebben nem segíthetek.",
 "confidence": 0.99,
 "defenses_triggered": ["sql_injection_filter"]
 }
 return {"output": f"Válasz a '{prompt}' kérdésre.", "confidence": 0.85, "defenses_triggered": []}

# Használat
simple_llm_predict("Mi a fővárosa Magyarországnak?", "user-123")
simple_llm_predict("SELECT * FROM users; DROP TABLE users;--", "user-456")
 

Ez a megközelítés tiszta, karbantartható kódot eredményez, és biztosítja, hogy minden modellhívás konzisztensen naplózásra kerüljön.

A naplóktól a riasztásokig: Az adatok életre keltése

A naplófájlok önmagukban csak passzív adattárolók. Az igazi értékük akkor mutatkozik meg, amikor aktív monitoring rendszert építünk rájuk. A cél, hogy a naplókból származó adatok alapján automatizált riasztásokat hozzunk létre, amelyek valós időben jeleznek potenciális támadási mintázatokat.

Az alábbi táblázat bemutat néhány példát arra, hogyan kapcsolhatók össze a naplózott események, a belőlük származtatott metrikák és a lehetséges Red Teaming taktikák.

Naplózott esemény	Figyelt metrika (KPI)	Riasztási küszöb (Példa)	Feltételezett Red Team taktika
input_sanitization_triggered	Azonos IP-címről érkező szanitizálási események száma / perc	> 10 esemény/perc	Automatizált prompt injection vagy jailbreak kísérlet.
anomaly_detector_high_score	Magas anomália pontszámú kérések aránya az összes kéréshez képest	> 5% az elmúlt 15 percben	A modell logikai határainak feltérképezése, rejtett sebezhetőségek keresése.
Modell válasz konfidenciája	Extrémen alacsony (<0.1) konfidenciájú válaszok száma	> 20 esemény/óra	A modell összezavarására irányuló kísérletek (model confusion), „hallucináció” provokálása.
resource_usage_high	Egy adott felhasználói tokenhez köthető erőforrás-igény (pl. GPU idő)	Folyamatosan a 95. percentilis felett	Szolgáltatásmegtagadási (Denial of Service) támadás erőforrás-igényes promptokkal.
internal_safety_classifier_triggered	A belső biztonsági szűrő által megjelölt kimenetek száma	Bármilyen növekedés a baseline-hoz képest	A modell rávezetése tiltott vagy káros tartalom generálására.

Ezek a metrikák vizualizálhatók dashboardokon (pl. Grafana, Kibana), és a riasztások elküldhetők a megfelelő csatornákra (pl. Slack, PagerDuty), lehetővé téve a biztonsági csapat számára a gyors és hatékony reagálást. A monitoring rendszer így a Red Team tevékenységek korai előrejelző rendszerévé válik.