# Zero Trust správa syntetických dat napříč multi‑cloud prostředími

Syntetická data se stala základním kamenem pro trénování AI modelů při ochraně soukromí, ale jejich hodnota se naplní jen tehdy, když mohou bezpečně proudit napříč složitým souborem moderních cloudových infrastruktur. Tradiční modely zabezpečení založené na perimetru selhávají pod tíhou multi‑cloud nasazení, kontejnerizovaných pracovních zátěží a serverless funkcí. **Zero‑trust** přístup – kde je každý požadavek autentizován, autorizován a neustále ověřován – nabízí chybějící dílčí část pro robustní správu syntetických dat.

V tomto článku se podíváme na:

1. Definování principů zero‑trust v kontextu syntetických dat.  
2. Ukázku, jak lze engine Formize policy‑as‑code rozšířit o velké jazykové modely (LLM) pro tvorbu adaptivních, kontextově‑citlivých kontrol.  
3. Praktickou architekturu, která zasahuje AWS, Azure, GCP i on‑premise datová jezera.  
4. Krok‑za‑krokem implementační průvodce včetně Mermaid diagramů a úryvků kódu.  
5. Diskusi o dopadech na soulad s předpisy ([GDPR](https://gdpr.eu/), [CCPA](https://oag.ca.gov/privacy/ccpa), [HIPAA](https://www.hhs.gov/hipaa/index.html)) a výkonnostních úvahách.

> **TL;DR** – Kombinací deklarativního policy frameworku Formize s LLM‑řízeným skórováním rizik mohou organizace vynucovat zero‑trust správu syntetických dat napříč libovolným cloudem, dosahovat kontinuálního souladu a zároveň nebránit datovým pipeline.

---

## 1. Základy Zero Trust pro syntetická data

| Princip | Kontext syntetických dat |
|-----------|------------------------|
| **Never Trust, Always Verify** | Každý syntetický dataset, bez ohledu na původ, musí být považován za nedůvěryhodný, dokud není ověřena jeho provenance, kvalita a stav souladu. |
| **Least‑Privilege Access** | Spotřebitelé dat (ML pipeline, analytické notebooky, downstream služby) získají pouze minimální oprávnění potřebná pro konkrétní úkol. |
| **Micro‑Segmentation** | Úložiště syntetických dat jsou izolována do logických zón (např. „training‑ready“, „research‑only“, „public‑share“) a politiky jsou vynucovány per zónu. |
| **Continuous Monitoring** | Telemetrie v reálném čase (logy přístupů, výsledky vyhodnocení politik, LLM skóre rizik) vstupuje do automatického remediace. |
| **Assume Breach** | Politiky jsou navrženy tak, aby omezily „blast radius“; kompromitované přihlašovací údaje nemohou vycizit celý syntetický datový jezero. |

Tyto principy se překládají do konkrétních technických kontrol: token‑based autentizace, attribute‑based access control (ABAC), neměnné auditní stopy a automatické vyhodnocování politik při každé operaci čtení/zápisu.

---

## 2. Proč Formize + LLM?

Formize již poskytuje **policy‑as‑code** engine, který dokáže vyjádřit složité souladové pravidla v lidsky čitelném DSL. Statické politiky však bojují s nuancovanými hodnoceními rizik, jako je „syntetická data odvozená z vysoce rizikového zdroje by měla být označena, pokud generované vzorky obsahují identifikovatelné vzory“.

Velké jazykové modely vynikají v **sémantickém skórování rizik**:

* **Kontextová klasifikace** – LLM dokáže přečíst schéma syntetických dat, ukázkové řádky a odhadnout, zda data neodhalují reálné atributy.  
* **Dynamické generování politik** – Promptováním LLM s nejnovějšími regulatorními aktualizacemi můžete automaticky generovat nové Formize pravidla bez ručního kódování.  
* **Vysvětlitelné rozhodnutí** – LLM může vytvořit přirozený jazykový odůvodnění, proč byl konkrétní dataset odmítnut, což usnadňuje auditovatelnost.

Synergie vypadá takto:

```
User Request → Formize Policy Engine → LLM Risk Scorer → Decision (Allow/Deny) → Audit Log
```

---

## 3. Přehled architektury

Níže je diagram úrovně zero‑trust správy syntetických dat. Ukazuje, jak data proudí od generace po konzumaci a procházejí body vynucování politik.

```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
```

**Klíčové komponenty:**

* **API Gateway** – Zpracovává autentizaci (OAuth2, mTLS) a předává požadavky engine Formize.  
* **Formize Policy Engine** – Provádí deklarativní pravidla, dotazuje se na LLM risk model a vrací rozhodnutí.  
* **LLM Risk Scorer** – Hostovaný jako serverless funkce (např. AWS Lambda), načítá nejnovější risk model z registru.  
* **Audit & Telemetry Service** – Streamuje rozhodnutí do centralizovaného SIEM pro alerty v reálném čase a souladové reporty.

---

## 4. Implementace zero‑trust stacku

### 4.1. Definujte zóny politik ve Formize

Vytvořte tři zóny: `training_ready`, `research_only` a `public_share`. Každá zóna má své ABAC atributy.

```yaml
# formize/policy_zones.yaml
zones:
  training_ready:
    description: "Datasets approved for model training"
    attributes:
      - purpose: training
      - sensitivity: low
  research_only:
    description: "Datasets for internal research, not for production"
    attributes:
      - purpose: research
      - sensitivity: medium
  public_share:
    description: "Datasets that can be published externally"
    attributes:
      - purpose: public
      - sensitivity: low
```

### 4.2. Napište základní přístupovou politiku

```hcl
# formize/policies/access.hcl
policy "synthetic_data_access" {
  description = "Zero‑trust access control for synthetic data"

  condition {
    # Verify token claims
    claim "role" in ["ml_engineer", "data_scientist"]
    claim "org_id" == request.org_id
  }

  condition {
    # Zone‑specific checks
    zone = request.metadata.zone
    allowed = zone in ["training_ready", "research_only"]
  }

  # Hook into LLM risk scorer
  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. Nasazení LLM Risk Scoreru

Lehký Python Lambda, který načte jemně doladěný LLM (např. OpenAI `gpt‑4o‑mini`) a vrátí pravděpodobnost rizika.

```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"]

    # Retrieve a sample of the dataset (metadata only)
    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": []}
```

Nasazujte tuto funkci a zaregistrujte její endpoint v sekci `external_evaluators` ve Formize.

### 4.4. Propojte vše dohromady

1. **Provision API Gateway** s JWT validací.  
2. **Konfigurujte Formize**, aby volalo LLM scorer přes blok `evaluate`.  
3. **Zapněte auditování**: Formize emitne události do Amazon Kinesis streamu; Lambda consumer zapisuje do Elasticsearch indexu pro dashboardy.  
4. **Nastavte alerty**: CloudWatch alarmy na risk skóre > 0.9 spustí Slack notifikaci.

### 4.5. Kontinuální aktualizace politik pomocí LLM

Místo ručního updatu politik při změně regulací můžete automaticky generovat nové Formize pravidla:

```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

# Example usage
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)
```

Naplánujte tento skript na každou noc, commitujte vygenerované politiky do GitOps repozitáře a nechte Formize je automaticky načíst.

---

## 5. Mapování na soulad

| Regulace | Požadavek Zero‑Trust | Implementace ve Formize |
|------------|------------------------|------------------------|
| [GDPR](https://gdpr.eu/) Art. 30 | Záznam zpracovatelských činností | Neměnné auditní logy uložené v S3 s verzováním a ochranou proti manipulaci |
| [CCPA](https://oag.ca.gov/privacy/ccpa) §1798.105 | Minimalizace dat | ABAC zajišťuje, že jsou vystaveny jen potřebné sloupce |
| [HIPAA](https://www.hhs.gov/hipaa/index.html) 45 CFR §164.312(a)(1) | Jedinečná identifikace uživatele | OAuth2 s MFA, token claimy validovány v politice |
| ISO 27001 / ISO/IEC 27001 | Událostní logování | Telemetrie v reálném čase do SIEM, retence dle politiky |
| NIST CSF (Identify‑Protect‑Detect‑Respond) | Kontinuální monitoring a reakce | Automatické skórování rizik + smyčka alertů |

Díky mapování každé kontroly na Formize pravidlo nebo LLM‑řízenou kontrolu mohou organizace generovat auditovatelné artefakty přímo z auditních stop.

---

## 6. Výkonnostní úvahy

* **Cold‑Start latence** – Serverless LLM scorer může přidat ~150 ms na požadavek. Mitigujte pomocí provisioned concurrency nebo pravidelných „warm‑up“ pingů.  
* **Caching** – Ukládejte nedávná risk skóre (TTL 5 min) v Redis, abyste se vyhnuli opakovanému skórování stejných datasetů.  
* **Batch vyhodnocení** – Pro hromadné stažení dat vyhodnocujte riziko jednou na verzi datasetu místo řádku po řádku.  
* **Řízení nákladů** – Používejte OpenAI `gpt‑4o‑mini` (≈ $0.00015 za 1 k tokenů) a omezte velikost promptu pod 2 k tokenů.

---

## 7. End‑to‑End průvodce

### Krok 1 – Generování syntetických dat

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

Generátor automaticky označí dataset atributem `zone=training_ready` a zaregistruje metadata.

### Krok 2 – Požadavek na přístup z ML pipeline

```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())
```

### Krok 3 – Tok vyhodnocení politik

1. **API Gateway** ověří JWT.  
2. **Formize** zkontroluje roli, org a atributy zóny.  
3. **LLM Scorer** obdrží ID datasetu, vrátí risk skóre `0.42`.  
4. **Rozhodnutí** – `allow`, protože skóre < 0.7.  
5. **Audit log** – Událost zapsána do Elasticsearch s poli: `user_id`, `dataset_id`, `risk_score`, `decision`.

### Krok 4 – Monitoring dashboard

Kibana dashboard vizualizuje:

* Počet požadavků podle zóny (training vs research)  
* Průměrné risk skóre v čase  
* Top uživatelé s odmítnutými pokusy  

Alerty se spustí, když uživatel opakovaně generuje vysoká risk skóre, což vyvolá bezpečnostní revizi.

---

## 8. Budoucí směřování

* **Federované LLM Scorery** – Nasazení risk modelů v každém cloud regionu ke snížení latence a dodržení pravidel rezidence dat.  
* **Zero‑Trust Service Mesh** – Rozšíření stejného policy engine na gRPC služby, které streamují syntetická data přímo do tréninkových úloh.  
* **Self‑Healing Policies** – Použití reinforcement learningu k automatickému zpřísnění politik při opakovaných porušeních.  

---