# Zero Trust szintetikus adatkezelés többfelhős környezetekben

A szintetikus adatok kulcsfontosságúvá váltak az AI modellek képzéséhez, miközben védik a magánszférát, de az értékük csak akkor realizálódik, ha biztonságosan áramolhatnak a modern felhőinfrastruktúrák összetett szövetén keresztül. A hagyományos perem‑alapú biztonsági modellek összeomlanak a többfelhős telepítések, konténerizált munkaterhek és serverless funkciók súlya alatt. Egy **zero‑trust** megközelítés – ahol minden kérés hitelesített, felhatalmazott és folyamatosan ellenőrzött – a hiányzó darab a robusztus szintetikus adatkezeléshez.

Ebben a cikkben:

1. Definiáljuk a zero‑trust elveket a szintetikus adatokra vonatkozóan.  
2. Bemutatjuk, hogyan bővíthető a Formize szabály‑kód motorja nagy nyelvi modellekkel (LLM‑ek) adaptív, kontextus‑érzékeny vezérlések létrehozásához.  
3. Áttekintünk egy gyakorlati architektúrát, amely az AWS, Azure, GCP és a helyi adat-tavak között terjed ki.  
4. Lépés‑ről‑lépésre megvalósítási útmutatót adunk, mermaid diagramokkal és kódrészletekkel.  
5. Megvitatjuk a megfelelőségi hatásokat ([GDPR](https://gdpr.eu/), [CCPA](https://oag.ca.gov/privacy/ccpa), [HIPAA](https://www.hhs.gov/hipaa/index.html)) és a teljesítmény‑szempontokat.

> **TL;DR** – A Formize deklaratív szabálykeretrendszerének és az LLM‑alapú kockázat‑pontozásnak a kombinálásával a szervezetek zero‑trust irányítást valósíthatnak meg a szintetikus adatokra bármely felhőben, folyamatos megfelelőséget biztosítva anélkül, hogy szűkítenék az adatcsővezetékeket.

---

## 1. Zero Trust alapelvek szintetikus adatokhoz

| Elv | Szintetikus adat kontextus |
|-----------|------------------------|
| **Soha ne bízz, mindig ellenőrizd** | Minden szintetikus adatkészletet, függetlenül a származásától, megbízhatatlanként kell kezelni, amíg a származás, minőség és megfelelőségi állapot nincs ellenőrizve. |
| **Legkisebb jogosultság elve** | Az adatfogyasztók (ML csővezetékek, elemző notebookok, downstream szolgáltatások) csak a konkrét feladathoz szükséges minimális jogosultságot kapják. |
| **Mikro‑szegmentáció** | A szintetikus adat tárolókat logikai zónákba (pl. „training‑ready”, „research‑only”, „public‑share”) izoláljuk, és a szabályok zónánként kerülnek érvényesítésre. |
| **Folyamatos megfigyelés** | Valós‑idő telemetria (hozzáférési naplók, szabály‑értékelési eredmények, LLM kockázati pontszámok) egy automatizált helyreállítási ciklusba táplálkozik. |
| **Feltételezzük a behatolást** | A szabályok úgy vannak kialakítva, hogy korlátozzák a hatótávolságot; kompromittált hitelesítő adatok nem tudják az egész szintetikus adat‑tavat kifelé exportálni. |

Ezek az elvek konkrét technikai kontrollokká alakulnak: token‑alapú hitelesítés, attribútum‑alapú hozzáférés‑vezérlés (ABAC), változtathatatlan audit‑nyomok és automatizált szabály‑értékelés minden olvasási/írási műveletnél.

---

## 2. Miért Formize + LLM‑ek?

A Formize már most egy **policy‑as‑code** motorral rendelkezik, amely összetett megfelelőségi szabályokat fejez ki ember‑olvasható DSL‑ben. A statikus szabályok azonban nehezen kezelik a finomabb kockázat‑értékeléseket, például a „szintetikus adat, amely magas‑kockázatú forrásból származik, jelölve legyen, ha a generált minták azonosítható mintákat tartalmaznak”.

A nagy nyelvi modellek kiválóak a **szemantikus kockázat‑pontozásban**:

* **Kontekstus‑osztályozás** – Az LLM képes elolvasni egy szintetikus adat sémát, mintasorokat, és megállapítani, hogy az adatok véletlenül valós világbeli attribútumokat fednek‑fel.  
* **Dinamikus szabály‑generálás** – Az LLM‑et a legújabb szabályozási frissítésekkel promptolva automatikusan új Formize szabályokat hozhatunk létre emberi kódolás nélkül.  
* **Magyarázható döntések** – Az LLM természetes nyelvű indoklásokat tud adni arról, miért utasították el egy adott adatkészletet, ezáltal segítve az auditálhatóságot.

A szinergia így néz ki:

```
Felhasználói kérés → Formize szabálymotor → LLM kockázati pontozó → Döntés (Engedélyez/Elutasít) → Audit napló
```

---

## 3. Architektúra áttekintése

Az alábbi magas szintű diagram a zero‑trust szintetikus adatkezelési stacket mutatja. Ábrázolja, hogyan mozog az adat a generálástól a fogyasztásig, miközben a szabály‑érvényesítési pontokon halad át.

```mermaid
graph TD
    subgraph Generation
        G1["Synthetic Data Generator (LLM, GAN, etc.)"]
        G2["Metadata Enricher"]
    end

    subgraph Storage
        S1["Multi‑Cloud Data Lake (S3, Azure Blob, GCS)"]
        S2["Formize Policy Store"]
        S3["LLM Risk Model Registry"]
    end

    subgraph Access
        A1["API Gateway (AuthN/AuthZ)"]
        A2["Formize Policy Engine"]
        A3["LLM Risk Scorer"]
        A4["Audit & Telemetry Service"]
    end

    subgraph Consumption
        C1["ML Training Pipeline"]
        C2["Analytics Notebook"]
        C3["External Partner API"]
    end

    G1 -->|Generate| G2
    G2 -->|Attach Metadata| S1
    G2 -->|Register Policies| S2
    G2 -->|Publish Model| S3

    C1 -->|Request Data| A1
    C2 -->|Request Data| A1
    C3 -->|Request Data| A1

    A1 -->|Validate Token| A2
    A2 -->|Evaluate Policy| A3
    A3 -->|Score Risk| A2
    A2 -->|Decision| A1
    A1 -->|Serve Data| S1
    A1 -->|Log Event| A4

    A4 -->|Continuous Monitoring| S2
```

**Kulcsfontosságú komponensek**

* **API Gateway** – Kezeli a hitelesítést (OAuth2, mTLS) és továbbítja a kéréseket a Formize motorhoz.  
* **Formize Policy Engine** – Végrehajtja a deklaratív szabályokat, lekérdezi az LLM kockázati modellt, és döntést ad.  
* **LLM Risk Scorer** – Serverless funkcióként (pl. AWS Lambda) fut, a legújabb kockázati modellt tölti be a regisztrációból.  
* **Audit & Telemetry Service** – Az eseményeket egy központosított SIEM‑be streameli valós‑idő riasztások és megfelelőségi jelentések céljából.

---

## 4. A Zero‑Trust stack megvalósítása

### 4.1. Zónák definiálása a Formize‑ben

Hozzunk létre három zónát: `training_ready`, `research_only` és `public_share`. Minden zónához saját ABAC attribútumok tartoznak.

```yaml
# formize/policy_zones.yaml
zones:
  training_ready:
    description: "Képzéshez jóváhagyott adatkészletek"
    attributes:
      - purpose: training
      - sensitivity: low
  research_only:
    description: "Belső kutatáshoz, nem produkciós felhasználásra"
    attributes:
      - purpose: research
      - sensitivity: medium
  public_share:
    description: "Külsőleg publikálható adatkészletek"
    attributes:
      - purpose: public
      - sensitivity: low
```

### 4.2. Alap hozzáférési szabály írása

```hcl
# formize/policies/access.hcl
policy "synthetic_data_access" {
  description = "Zero‑trust hozzáférés‑vezérlés szintetikus adatokhoz"

  condition {
    # Token igények ellenőrzése
    claim "role" in ["ml_engineer", "data_scientist"]
    claim "org_id" == request.org_id
  }

  condition {
    # Zónához kapcsolódó ellenőrzések
    zone = request.metadata.zone
    allowed = zone in ["training_ready", "research_only"]
  }

  # LLM kockázati pontozó hívása
  evaluate "llm_risk_score" {
    input = {
      dataset_id = request.dataset_id
      user_id    = request.user_id
    }
    threshold = 0.7
  }

  effect = evaluate.llm_risk_score.passed ? "allow" : "deny"
}
```

### 4.3. LLM kockázati pontozó telepítése

Egy könnyű Python Lambda, amely egy finomhangolt LLM‑et (pl. OpenAI `gpt‑4o‑mini`) tölt be, és kockázati valószínűséget ad vissza.

```python
# llm_risk_scorer.py
import json
import os
import openai

openai.api_key = os.getenv("OPENAI_API_KEY")

def lambda_handler(event, context):
    dataset_id = event["input"]["dataset_id"]
    user_id    = event["input"]["user_id"]

    # Egy minta lekérése a datasetből (csak metaadat)
    sample = get_dataset_sample(dataset_id)

    prompt = f"""
    You are a compliance analyst. Given the following synthetic data sample and user context, output a risk score between 0 (no risk) and 1 (high risk).

    Sample: {json.dumps(sample)}
    User ID: {user_id}
    """

    response = openai.ChatCompletion.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.0,
    )
    score = float(response.choices[0].message.content.strip())
    return {
        "passed": score < 0.7,
        "risk_score": score
    }

def get_dataset_sample(dataset_id):
    # Placeholder: fetch first 10 rows from the data lake
    return {"rows": []}
```

Telepítsük ezt a funkciót, és regisztráljuk a végpontját a Formize `external_evaluators` szekciójában.

### 4.4. Összekapcsolás

1. **API Gateway** – JWT validációval.  
2. **Formize** – az `evaluate` blokkban hívja az LLM pontozót.  
3. **Audit** – Formize eseményeket egy Amazon Kinesis stream‑be küld; egy Lambda fogyasztó Elasticsearch indexbe írja a dashboardokhoz.  
4. **Riasztás** – CloudWatch alarmok 0,9‑nél nagyobb kockázati pontszámra Slack értesítést küldenek.

### 4.5. Folyamatos szabályfrissítés LLM‑ekkel

A szabályok manuális frissítése helyett automatikusan generálhatunk új Formize szabályokat:

```python
# policy_generator.py
import openai, json, os

def generate_policy(regulation_text):
    prompt = f"""
    You are a policy engineer. Convert the following regulation excerpt into a Formize HCL policy that enforces zero‑trust access for synthetic data.

    Regulation: {regulation_text}
    """
    response = openai.ChatCompletion.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.0,
    )
    return response.choices[0].message.content

# Példa használat
reg_text = "Synthetic data derived from health records must be labeled as high‑sensitivity and cannot be exported outside the EU."
policy_hcl = generate_policy(reg_text)
print(policy_hcl)
```

Ezt a szkriptet éjszakánként ütemezzük, a generált szabályokat egy GitOps repóba commitáljuk, és a Formize automatikusan újratölti őket.

---

## 5. Megfelelőségi térkép

| Szabályozás | Zero‑Trust követelmény | Formize megvalósítás |
|------------|------------------------|----------------------|
| [GDPR](https://gdpr.eu/) Art. 30 | Feldolgozási tevékenységek nyilvántartása | Változtathatatlan audit‑naplók tamper‑evident S3‑ban verziózással |
| [CCPA](https://oag.ca.gov/privacy/ccpa) §1798.105 | Adatminimalizálás | ABAC biztosítja, hogy csak a szükséges oszlopok legyenek elérhetők |
| [HIPAA](https://www.hhs.gov/hipaa/index.html) 45 CFR §164.312(a)(1) | Egyedi felhasználói azonosítás | OAuth2 MFA‑val, token igények validálása a szabályban |
| ISO 27001 / ISO/IEC 27001 | Esemény‑naplózás | Valós‑idő telemetria SIEM‑be, szabályozott megőrzési idő |
| NIST CSF (Identify‑Protect‑Detect‑Respond) | Folyamatos megfigyelés és válasz | Automatizált kockázati pontozás + riasztási ciklus |

Az egyes kontrollok közvetlenül egy Formize szabályra vagy LLM‑alapú ellenőrzésre lefordíthatók, így a szervezetek közvetlenül a naplóból exportálható, benyújtható megfelelőségi anyagokat generálhatnak.

---

## 6. Teljesítmény‑szempontok

* **Hideg‑indítás késleltetés** – A serverless LLM pontozók körülbelül 150 ms‑es késleltetést adhatnak egy kéréshez. Enyhítsük a **provisioned concurrency** vagy **warm‑up ping** feladatokkal.  
* **Gyorsítótárazás** – A legutóbbi kockázati pontszámokat (TTL 5 perc) Redis‑ben tároljuk, hogy elkerüljük az azonos adatkészlet többszöri újra‑pontozását.  
* **Kötegelt értékelés** – Bulk adatlekérések esetén a kockázatot egyszer értékeljük adatkészlet‑verzióra, nem soronként.  
* **Költségmenedzsment** – Az OpenAI `gpt‑4o‑mini` (≈ $0.00015/1 k token) használata, a prompt méretét 2 k token alá korlátozva.

---

## 7. Vég‑től‑vég útmutató

### 1. lépés – Szintetikus adat generálása

```bash
formize generate --type gan --output s3://synthetic-data/training_ready/customer_churn_v1.parquet
```

A generátor automatikusan a `zone=training_ready` címkét csatolja, és egy metaadat‑rekordot regisztrál.

### 2. lépés – Hozzáférés kérése egy ML csővezetékből

```python
import requests, jwt, time

token = jwt.encode(
    {"sub": "ml_engineer_42", "role": "ml_engineer", "org_id": "acme_corp", "exp": time.time() + 3600},
    "your_private_key",
    algorithm="RS256"
)

resp = requests.get(
    "https://api.formize.io/v1/data/s3://synthetic-data/training_ready/customer_churn_v1.parquet",
    headers={"Authorization": f"Bearer {token}"}
)

if resp.status_code == 200:
    print("Dataset retrieved")
else:
    print("Access denied:", resp.json())
```

### 3. lépés – Szabály‑értékelési folyamat

1. **API Gateway** ellenőrzi a JWT‑t.  
2. **Formize** ellenőrzi a szerepkört, szervezet‑azonosítót és a zóna attribútumokat.  
3. **LLM pontozó** megkapja a dataset‑ID‑t, visszaad egy `0.42`‑es kockázati pontszámot.  
4. **Döntés** – `allow`, mert a pontszám < 0.7.  
5. **Audit napló** – Az esemény Elasticsearch‑be íródik a következő mezőkkel: `user_id`, `dataset_id`, `risk_score`, `decision`.

### 4. lépés – Monitoring dashboard

Egy Kibana dashboard megjeleníti:

* Kérések száma zónánként (training vs research)  
* Átlagos kockázati pontszám időbeli alakulása  
* Leggyakoribb felhasználók elutasított kérései  

Riasztások indulnak, ha egy felhasználó ismételten magas kockázati pontszámot generál, így biztonsági felülvizsgálatot indítunk.

---

## 8. Jövőbeli irányok

* **Federált LLM pontozók** – A kockázati modelleket minden felhő‑régióban telepítjük, csökkentve a késleltetést és biztosítva az adat‑rezidencia szabályok betartását.  
* **Zero‑Trust Service Mesh** – A szabálymotor kiterjesztése gRPC‑szolgáltatásokra, amelyek közvetlenül stream‑elik a szintetikus adatokat a modell‑tréning feladatokba.  
* **Ön‑gyógyító szabályok** – Reinforcement learning alkalmazása a szabályok automatikus szigorítására, ha ismételt szabálysértéseket észlelünk.  

---