# Kontrola pristupa i revizija sintetičkih podataka uz Zero Trust i Formize

Sintetički podaci postali su temelj za razvoj AI‑a, omogućujući organizacijama da treniraju modele bez izlaganja stvarnim osobnim informacijama. Ipak, sama priroda sintetičkih podataka – izvedenih iz osjetljivih izvornih skupova podataka – stvara paradoks: moraju biti i **korisni** i **sigurni**. Tradicionalni modeli sigurnosti temeljeni na perimetru ne zadovoljavaju potrebe jer pretpostavljaju pouzdanu internu mrežu, što više ne vrijedi u modernim, cloud‑prvom okruženjima.

Uvodimo **Zero Trust**: sigurnosni paradime koji svaki zahtjev tretira kao nepouzdan sve dok se ne dokaže suprotno. Kada se kombinira s **Formizeom**, platformom za automatizaciju radnih tokova s niskim kodom, Zero Trust se može proširiti od mrežnih slojeva do sloja podataka, pružajući finu kontrolu pristupa, nepromjenjive revizijske zapise i automatizirano izvještavanje o usklađenosti za pipeline‑ove sintetičkih podataka.

U ovom članku ćemo:

1. Objasniti osnovna načela Zero Trusta kako se primjenjuju na sintetičke podatke.  
2. Pokazati kako Formize može orkestrirati definiciju politika, provođenje i nadzor.  
3. Demonstrirati referentnu arhitekturu koja integrira povjerljivo računalstvo, policy‑as‑code i revizijsko bilježenje u stvarnom vremenu.  
4. Pružiti praktične korake za implementaciju rješenja u vašoj organizaciji.  
5. Istaknuti najbolje prakse za održavanje korisnosti podataka uz strogu sigurnost.

---

## 1. Zašto Zero Trust ima značaj za sintetičke podatke

| Tradicionalni perimetarski model | Zero Trust model |
|----------------------------------|------------------|
| Povjerenje se dodjeljuje jednom kada je korisnik unutar mreže. | Svaki zahtjev se verificira, neovisno o lokaciji. |
| Odluke o pristupu su statične, često temeljene samo na ulogama. | Odluke o pristupu su dinamične, temeljene na kontekstu, riziku i namjeri. |
| Revizija je retrospektivna i fragmentirana. | Revizija je kontinuirana, nepromjenjiva i pretraživa. |
| Osjetljivi podaci mogu biti previše izloženi internim uslugama. | Podaci se pristupaju samo putem verificiranih, najmanje privilegiranih putanja. |

Pipeline‑ovi sintetičkih podataka obično uključuju:

- **Uzimanje izvornih podataka** (PII, PHI, financijski zapisi).  
- **Transformaciju i sintezu** pomoću generativnih modela.  
- **Distribuciju** timovima za strojno učenje, vanjskim partnerima ili javnim API‑jima.

Svaka faza predstavlja površinu napada. Zero Trust pristup osigurava da:

- Samo ovlaštene entitete mogu **pokrenuti sintezu**.  
- Generirani skupovi podataka su **označeni politikama upotrebe** koje putuju zajedno s podacima.  
- Svaka operacija čitanja/pisanja je **zapisana i verificirana** prema politici prije izvršenja.  

---

## 2. Formize kao omogućivač Zero Trusta

Formize pruža tri mogućnosti koje izravno odgovaraju zahtjevima Zero Trusta:

1. **Policy‑as‑Code motor** – Definirajte pravila pristupa deklarativnim YAML/JSON formatom koji se može verzionirati.  
2. **Orkestracija radnih tokova** – Automatizirajte validaciju zahtjeva, izdavanje tokena i provođenje politika bez pisanja prilagođenog koda.  
3. **Neizmjenjivi revizijski zapis** – Pohranite svaku odluku, zahtjev i odgovor u ledger koji otkriva manipulacije (po izboru podržan blockchainom).

### 2.1 Primjer definicije politike

```yaml
policy:
  name: synthetic-data-access
  description: Zero‑trust kontrola pristupa za sintetičke skupove podataka
  version: 1.2.0
  rules:
    - id: allow‑ml‑team‑read
      effect: permit
      actions: [read]
      resources: ["synthetic/*"]
      subjects:
        - role: ml_engineer
          attributes:
            department: "AI"
            clearance: "high"
      conditions:
        - ip_range: "10.0.0.0/8"
        - time_of_day: "08:00-20:00"
    - id: deny‑external‑write
      effect: deny
      actions: [write, delete]
      resources: ["synthetic/*"]
      subjects:
        - any
      conditions:
        - source: "external"
```

Politika se pohranjuje u **Policy Store** Formizea, verzionirana zajedno s vašim CI/CD pipeline‑om. Svaka promjena pokreće automatiziranu **analizu utjecaja politike** koja obavještava dionike prije implementacije.

### 2.2 Primjer radnog toka: Validacija zahtjeva

```mermaid
flowchart TD
    A["Korisnik podnosi zahtjev za sintetičke podatke"] --> B["Formize prima zahtjev"]
    B --> C["Motor politika evaluira zahtjev"]
    C -->|Permit| D["Izdaj token kratkog trajanja"]
    C -->|Deny| E["Vrati grešku uz revizijski zapis"]
    D --> F["Token se koristi za poziv Data Service"]
    F --> G["Data Service verificira token s Formizeom"]
    G --> H["Data Service vraća sintetički skup podataka"]
    H --> I["Formize zapisuje transakciju u neizmjenjivi ledger"]
```

Dijagram prikazuje **cijeli životni ciklus jednog zahtjeva**: korisnik podnosi zahtjev, Formize ga evaluira prema pohranjenim politikama, izdaje kratkotrajan token, a servis podataka verificira token prije isporuke sintetičkog skupa podataka. Svaki korak je zabilježen u neizmjenjivom revizijskom zapisu.

---

## 3. Referentna arhitektura

Dolje je prikazana visoko‑razina arhitekture koja kombinira Formize s modernim sigurnosnim primitivima:

```mermaid
graph LR
    subgraph "Korisnički i aplikacijski sloj"
        U[Korisnik / ML aplikacija] -->|HTTPS| API[Formize API Gateway]
    end

    subgraph "Politika i orkestracija"
        API --> P[Motor politika (OPA) ]
        API --> W[Motor radnih tokova (Formize)]
        P -->|Policy Decision| W
    end

    subgraph "Obrada podataka"
        W --> C[Confidential Compute Enclave]
        C --> S[Synthetic Data Service]
        S -->|Encrypted Data| D[Data Lake]
    end

    subgraph "Revizija i usklađenost"
        W --> L[Neizmjenjivi ledger (Blockchain/Append‑Only DB)]
        L --> R[Compliance Dashboard]
    end

    style U fill:#f9f,stroke:#333,stroke-width:2px
    style API fill:#bbf,stroke:#333,stroke-width:2px
    style P fill:#bfb,stroke:#333,stroke-width:2px
    style W fill:#ff9,stroke:#333,stroke-width:2px
    style C fill:#c9f,stroke:#333,stroke-width:2px
    style S fill:#9cf,stroke:#333,stroke-width:2px
    style D fill:#9f9,stroke:#333,stroke-width:2px
    style L fill:#fcc,stroke:#333,stroke-width:2px
    style R fill:#fc9,stroke:#333,stroke-width:2px
```

**Ključne komponente:**

| Komponenta | Uloga |
|------------|-------|
| **Formize API Gateway** | Centralna točka ulaza, provodi TLS, ograničenje brzine i međusobni TLS za pozive između servisa. |
| **Motor politika (OPA)** | Evaluira policy‑as‑code u stvarnom vremenu. Integriran je s Formizeovim motorom radnih tokova za keširanje odluka. |
| **Motor radnih tokova** | Orkestrira izdavanje tokena, rotaciju tajni i uvjetne korake (npr. višefaktorsko odobrenje). |
| **Confidential Compute Enclave** | Izvršava model generacije sintetičkih podataka unutar hardverski izoliranog okruženja (Intel SGX, AMD SEV). Jamči da sirovi izvorni podaci nikada ne napuste enclave. |
| **Synthetic Data Service** | Poslužuje generirane skupove podataka, dodaje **metapodatke upotrebe** (ID politike, hash tokena, isteka). |
| **Neizmjenjivi ledger** | Pohranjuje svaku odluku politike, izdavanje tokena i događaj pristupa podacima. Može biti poduprt permissioned blockchainom za regulatorni dokaz. |
| **Compliance Dashboard** | Vizualizacija u stvarnom vremenu obrazaca pristupa, kršenja politika i metrika spremnosti za reviziju. |

---

## 4. Vodič korak po korak za implementaciju

### 4.1 Postavite Formize okruženje

1. **Implementirajte Formize Cloud** ili on‑premise Docker stack.  
2. Omogućite **Policy Store** i povežite ga s vašim Git repozitorijem radi verzioniranja.  
3. Instalirajte **OPA dodatak** za evaluaciju politika.

### 4.2 Definirajte Zero Trust politike

- Upotrijebite predložak politike iznad.  
- Dodajte **uvjete temeljene na riziku** poput posture uređaja, statusa MFA i anomalijskih skorova iz SIEM‑a.  
- Označite svaki sintetički skup podataka **identifikatorom politike** (`policy_id`) koji će se provjeravati pri svakom čitanju.

### 4.3 Integrirajte povjerljivo računalstvo

- Pripremite **confidential compute čvor** (npr. Azure Confidential Compute VM).  
- Deployajte svoj generativni model unutar enclave‑a.  
- Izložite **gRPC endpoint** koji prihvaća samo tokenove potpisane od strane Formizea.

### 4.4 Izgradite radni tok pristupa

1. **Obrazac zahtjeva** – Niskokodni Formize web obrazac prikuplja detalje zahtjeva (svrha, tip skupa podataka, vrijeme isteka).  
2. **Korak odobrenja** – Opcionalno višerazinsko odobrenje putem ugrađenog email ili Slack integracije.  
3. **Generiranje tokena** – Formize kreira JWT s claim‑ovima: `sub`, `policy_id`, `exp`, `nonce`. Token je potpisan rotirajućim ključem pohranjenim u HSM‑u.  
4. **Poziv servisu podataka** – Klijent prezentira token; servis verificira token putem **Token Validation API** Formizea.  
5. **Revizijski zapis** – Svaki rezultat validacije zapisuje se u neizmjenjivi ledger s kriptografskim hash‑om skupa podataka.

### 4.5 Omogućite reviziju u stvarnom vremenu

- Konfigurirajte Formize da streama zapise ledger‑a u **SIEM** (Splunk, Elastic ili Azure Sentinel).  
- Izradite alarme za **kršenja politika**, **ponovnu upotrebu tokena** ili **pristup s neovlaštenih IP raspona**.  
- Koristite **Dashboard Builder** Formizea za kreiranje izvještaja koji zadovoljavaju GDPR, HIPAA i CCPA zahtjeve.

### 4.6 Automatizirajte izvještavanje o usklađenosti

- Zakazite noćni **Formize posao** koji agregira zapise ledger‑a, mapira ih na verzije politika i generira PDF/HTML paket usklađenosti.  
- Paket se automatski učitava u sustav za upravljanje dokumentima (SharePoint, Confluence) i šalje regulatorima putem sigurnog emaila.

---

## 5. Najbolje prakse i zamke koje treba izbjegavati

| Najbolja praksa | Razlog |
|-----------------|--------|
| **Koristite kratkotrajne tokene (≤15 min)** | Smanjuje prozor napada ako token bude kompromitiran. |
| **Rotirajte potpisne ključeve dnevno** | Ograničava učinak curenja ključa i zadovoljava mnoge regulatorne okvire. |
| **Označite podatke nepromjenjivim hash‑om politike** | Jamči da se porijeklo skupa podataka može verificirati čak i nakon što napusti sustav. |
| **Primijenite MFA za sve akcije promjene politika** | Sprječava neovlaštene izmjene politika koje bi mogle otvoriti backdoor. |
| **Izvršavajte generiranje unutar povjerljivih enclave‑a** | Osigurava da sirovi izvorni podaci nikada ne budu u čistom tekstu izvan enclave‑a. |
| **Redovito revizirajte Policy Store** | Otkriva zastarjele pravila koja mogu dati preširoka prava. |
| **Kombinirajte RBAC s atributima i kontekstom** | Zero Trust zahtijeva dodatni kontekst, ne samo uloge. |
| **Pohranite revizijske zapise u nepromjenjivo skladište** | Upotreba append‑only baze ili blockchaina jamči otkrivanje manipulacije. |
| **Implementirajte mehanizam za opoziv tokena** | Provjerava **revocation list** prije svakog poziva servisu podataka. |

---

## 6. Mjerenje uspjeha

| Metrička | Cilj |
|----------|------|
| **Prosječno vrijeme otkrivanja (MTTD) kršenja politike** | < 5 minuta |
| **Prosječno vrijeme reagiranja (MTTR) na incident** | < 30 minuta |
| **Potpunost revizijskih zapisa** | 100 % događaja pristupa zabilježeno |
| **Detekcija odstupanja politika** | Automatski alarmi za svaku promjenu pravila koja nije pregledana u roku od 24 sata |
| **Gubitak korisnosti sintetičkih podataka** | < 2 % degradacije u odnosu na referentne modele |

Redovito pregledavajte ove KPI‑e na Formize **Compliance Dashboardu** kako biste osigurali da sigurnosne kontrole ne ometaju produktivnost timova za data science.

---

## 7. Budući smjerovi

- **AI‑potaknuta preporuka politika** – Upotrijebite LLM‑ove za predlaganje poboljšanja politika na temelju uočenih obrazaca korištenja.  
- **Zero‑knowledge dokazi za verifikaciju podataka** – Dokazujte da sintetički skup podataka zadovoljava politiku bez otkrivanja samog skupa.  
- **Federirano dijeljenje sintetičkih podataka** – Proširite Zero Trust model preko granica organizacija koristeći Secure Multi‑Party Computation (MPC).  

Kontinuiranim razvojem motora politika i integracijom naprednih kriptografskih tehnika, organizacije mogu održavati svoje pipeline‑ove sintetičkih podataka **sigurnima** i **pripremljenima za budućnost**.

---

## Vidi također

- [Zero Trust Architecture (NIST SP 800‑207)](https://csrc.nist.gov/publications/detail/sp/800-207/final)  
- [Open Policy Agent (OPA) Documentation](https://www.openpolicyagent.org/docs/latest/)