Zero Trust model sigurnosti

Zero Trust nije proizvod ni naredba da se „nikome ne vjeruje”. To je pristup arhitekturi u kojem mrežna lokacija, vlasništvo uređaja ili prethodna prijava sami po sebi ne daju trajno povjerenje. Pristup konkretnom resursu odobrava se prema identitetu, stanju uređaja, poslovnom kontekstu i politici, uz najmanje potrebne ovlasti i stalno prikupljanje signala.

Ključne činjenice

• NIST SP 800-207 definira Zero Trust kao skup paradigmi usmjerenih na zaštitu resursa, a ne kao jedan proizvod ili obveznu topologiju.
• Autentikacija i autorizacija zasebne su odluke: dokaz identiteta ne znači da korisnik smije pristupiti svakom podatku ili radnji.
• Zero Trust ne ukida vatrozid, VPN ili segmentaciju; mijenja pretpostavku da je sve „unutra” automatski pouzdano.
• MFA je važan temelj, ali sam po sebi nije Zero Trust. Potrebni su inventar, politika pristupa, stanje uređaja, ograničene ovlasti, provedbene točke i telemetrija.
• NIS2 ne propisuje Zero Trust pod tim nazivom. Njegove prakse mogu poduprijeti više mjera iz članka 21., ali primjena mora biti razmjerna riziku i dokazivo učinkovita.

Što NIST podrazumijeva pod Zero Trustom

Prema NIST SP 800-207, implicitno povjerenje ne dodjeljuje se samo zato što je korisnik ili uređaj na lokalnoj mreži, pripada organizaciji ili je prethodno bio odobren. Fokus je na resursu: podatku, aplikaciji, usluzi, računu ili poslovnom procesu kojem se pristupa.

NIST navodi sedam temeljnih načela:

1. svi izvori podataka i računalne usluge smatraju se resursima;
2. sva komunikacija štiti se neovisno o mrežnoj lokaciji;
3. pristup pojedinom resursu odobrava se po sesiji;
4. pristup određuje dinamička politika koja uzima u obzir identitet, resurs, uređaj, ponašanje i druge relevantne okolnosti;
5. organizacija prati stanje i sigurnosni položaj imovine;
6. autentikacija i autorizacija dinamične su i provode se prije pristupa;
7. organizacija prikuplja informacije o imovini, mreži i komunikaciji te ih koristi za poboljšanje sigurnosti.

To su idealna načela, ne tvrdnja da će svaka organizacija odmah i savršeno primijeniti svaki element. Migracija je upravljanje rizikom kroz vrijeme.

Zašto mrežna lokacija nije dovoljna

Tradicionalni model često pretpostavlja snažnu vanjsku granicu i šire povjerenje unutar mreže. Takva pretpostavka slabi kada organizacija koristi SaaS, više oblaka, udaljeni rad, osobne uređaje, vanjske suradnike i dobavljačke integracije.

Čak i u potpuno lokalnoj okolini napadač može ukrasti VPN vjerodajnicu, kompromitirati zaposlenikov uređaj ili iskoristiti ranjivi poslužitelj. Ako pristup nakon ulaska ostane širok i slabo nadziran, jedna točka kompromitacije postaje put prema mnogim resursima.

Zero Trust zato postavlja druga pitanja:

• Tko ili koja usluga traži pristup?
• Kojem točno resursu i kojoj radnji?
• Je li uređaj poznat i u prihvatljivom stanju?
• Je li kontekst prijave u skladu s politikom i procijenjenim rizikom?
• Koliko dugo odobrenje vrijedi i što ga može opozvati?
• Koji je najmanji opseg pristupa potreban za poslovni zadatak?

Arhitektura odluke o pristupu

NIST-ov logički model razlikuje tri ključne funkcije:

Odluka može koristiti podatke iz sustava za identitete, upravljanje uređajima, klasifikaciju podataka, evidenciju imovine, SIEM-a, zaštite krajnjih točaka i obavještajnih izvora o prijetnjama. Više alata ne znači automatski bolju odluku: signali moraju biti pouzdani, pravodobni i povezani s jasnom politikom.

Glavne sposobnosti

Identitet i autentikacija

Uspostavite jedinstven životni ciklus zaposlenika, vanjskih suradnika, servisnih računa i radnih identiteta. Uvedite MFA prema riziku, uz phishing-otporne metode za administratore i kritične pristupe gdje je izvedivo. Posebno zaštitite oporavak računa jer slab postupak oporavka može zaobići snažnu prijavu.

Autorizacija i najmanje privilegije

Pristup dodjeljujte poslovnoj ulozi i konkretnom resursu, ne širokoj mreži. Privilegirane ovlasti mogu biti vremenski ograničene i aktivirane po potrebi. Redovito provjeravajte neiskorištene, naslijeđene i konfliktne ovlasti te hitne „break-glass” račune.

Stanje uređaja i radnog opterećenja

Identitet korisnika nije dovoljan ako je uređaj kompromitiran. Politika može uzeti u obzir podržan operacijski sustav, ažurnost zakrpa, enkripciju, zaštitu krajnje točke, vlasništvo i znakove kompromitacije. Za aplikacije i mikroservise jednako je važan identitet radnog opterećenja, ne samo IP adresa.

Segmentacija i provedba politike

Segmentacija ograničava bočno kretanje, ali ne mora značiti velik broj statičnih VLAN-ova. Granica može biti aplikacijski proxy, identitetski svjestan gateway, host firewall, service mesh ili druga provedbena točka. Pravilo treba dopustiti potrebne tokove i odbiti ostale, uz test da se politika stvarno provodi.

Zaštita podataka

Klasifikacija i vlasništvo podataka omogućuju različite odluke za javni dokument, osobni podatak i kritičnu tajnu. Politika može ograničiti preuzimanje, dijeljenje, administrativnu radnju ili pristup s neupravljanog uređaja. Enkripcija ne rješava neprimjeren pristup legitimno prijavljenog korisnika, pa je autorizacija i dalje ključna.

Telemetrija i odgovor

Prikupljajte dovoljno zapisa da objasnite tko je dobio pristup, na temelju kojih signala, kojoj radnji i s kojim ishodom. Promjena rizika može zahtijevati novu autentikaciju, ograničenje ili prekid sesije. Pravila za automatsku reakciju moraju imati zaštitu od pogrešne masovne blokade.

Plan primjene korak po korak

1. Odaberite poslovni resurs, ne cijelu mrežu

Počnite jednom vrijednom i dovoljno razumljivom uslugom, primjerice administracijom SaaS-a, pristupom financijskoj aplikaciji ili portalom vanjskih suradnika. Definirajte vlasnika, podatke, korisnike, ovisnosti i posljedice pogrešnog dopuštanja ili odbijanja.

2. Nacrtajte stvarne tokove

Popišite ljudske i servisne identitete, uređaje, aplikacije, API-je, dobavljače i administrativne putove. Promatrajte stvarni promet prije blokiranja kako ne biste prekinuli skrivenu, ali važnu ovisnost.

3. Uredite identitete i osnovnu higijenu

Uklonite zajedničke i nepotrebne račune, uvedite centraliziranu prijavu gdje je razumno, MFA, najmanje privilegije i brz postupak ulaska/izlaska zaposlenika. Inventar i zakrpe ostaju nužni; Zero Trust ne nadoknađuje nepoznatu ili nepodržanu imovinu.

4. Napišite odluke kao pravila

Primjer: „Član financijskog tima može odobriti plaćanje samo s upravljanog i usklađenog uređaja, uz phishing-otpornu autentikaciju; iznos iznad internog praga traži drugu ovlaštenu osobu.” Pravilo ima resurs, radnju, identitet, kontekst, dodatnu kontrolu i zapis.

5. Postavite provedbenu točku i način oporavka

Politika mora biti provediva blizu resursa. Dokumentirajte ponašanje pri nedostupnosti identitetskog ili policy sustava: hoće li se pristup zatvoriti, ograničiti ili privremeno dopustiti određenoj kritičnoj funkciji. „Fail open” i „fail closed” nisu univerzalno ispravni; odluka ovisi o sigurnosti ljudi i poslovnom učinku.

6. Pilotirajte i mjerite

U početku koristite način promatranja gdje je moguće, zatim ograničen pilot s podrškom korisnicima i jasnim povratkom. Mjerite ne samo broj blokada, nego točnost odluka, vrijeme rješavanja, neželjeni učinak na korisnike i smanjenje širokih ovlasti.

7. Širite obrazac

Ponovno upotrijebite provjerene politike i integracije na sljedećem resursu. Svako proširenje ažurira inventar, model prijetnje, plan incidenta i arhitekturu oporavka.

Za procjenu početnog opsega, identiteta i kontrola pogledajte usluge kibernetičke sigurnosti.

Prioriteti za mala i srednja poduzeća

MSP ne treba odmah kupiti novu platformu. Razuman slijed može biti:

1. popisati najvažnije aplikacije, podatke, administratore i dobavljačke pristupe;
2. ukloniti zajedničke račune i uvesti MFA, posebno za e-poštu, administraciju, cloud i udaljeni pristup;
3. odvojiti svakodnevne od administratorskih računa;
4. ograničiti pristup vanjskih suradnika na potrebnu uslugu i vrijeme;
5. provjeriti stanje uređaja prije pristupa važnim cloud aplikacijama gdje alat to podržava;
6. uključiti zapise o prijavama, promjenama privilegija i administrativnim radnjama;
7. testirati opoziv računa i rad u slučaju nedostupnosti identitetskog pružatelja.

To nije potpuna Zero Trust arhitektura, ali uklanja široko implicitno povjerenje na mjestima najvećeg rizika i stvara mjerljivu osnovu za daljnji razvoj.

Zero Trust i NIS2

NIS2 članak 21. zahtijeva odgovarajuće i razmjerne mjere upravljanja kibernetičkim rizicima. Zero Trust prakse mogu poduprijeti više područja:

Ipak, kupnja alata označenog „Zero Trust” nije dokaz NIS2 usklađenosti, a Direktiva ne zahtijeva određenu komercijalnu arhitekturu. Organizacija treba povezati mjeru s procjenom rizika i pokazati da djeluje u praksi.

Hrvatska Uredba o kibernetičkoj sigurnosti sadrži konkretne mjere za upravljanje identitetima i pristupom, inventar, segmentaciju, zapisivanje, provjeru ranjivosti i druge kontrole. Opseg njihove primjene ovisi o statusu subjekta, razini mjera i procjeni rizika.

Najčešće pogreške

„Uveli smo MFA, dakle imamo Zero Trust”

MFA potvrđuje identitet s više faktora, ali ne uređuje automatski ovlasti, stanje uređaja, pristup aplikacija, segmentaciju ni odgovor na promjenu rizika.

Previše širokih pravila radi jednostavnosti

Jedna skupina koja daje pristup cijelom okruženju vraća implicitno povjerenje. Pravila trebaju pratiti resurs i poslovnu radnju, uz kontroliran proces iznimke.

Zaboravljeni servisni računi i API ključevi

Radni identiteti često imaju trajne tajne i široke ovlasti. Uvedite vlasništvo, rotaciju, kratkotrajne vjerodajnice gdje je moguće i praćenje stvarne uporabe.

Blokiranje bez plana dostupnosti

Neispravna politika može zaustaviti proizvodnju ili spriječiti hitnu intervenciju. Testirajte ovisnosti, break-glass pristup, zapisivanje njegove uporabe i povratak na sigurnu konfiguraciju.

Prikupljanje signala bez kvalitete

Zastario inventar ili nepouzdan podatak o stanju uređaja dovodi do pogrešnih odluka. Svaki signal treba imati vlasnika, svježinu, zaštitu i poznato ponašanje kada nije dostupan.

Kako mjeriti napredak

Korisne metrike uključuju:

• udio kritičnih resursa s imenovanim vlasnikom i dokumentiranim tokovima;
• udio privilegiranih pristupa koji su vremenski ograničeni i snažno autentificirani;
• broj širokih trajnih ovlasti i njihovo smanjenje;
• vrijeme opoziva korisničkog, servisnog i dobavljačkog pristupa;
• udio zahtjeva za koje je dostupna odluka, razlog i relevantni kontekst;
• broj lažno pozitivnih blokada i vrijeme povratka korisnika;
• rezultat testa zabranjenog bočnog kretanja i break-glass scenarija.

Broj kupljenih licenci ili uključenih pravila nije mjera smanjenog rizika.

Česta pitanja

Zamjenjuje li Zero Trust VPN?+

Ne nužno. VPN može ostati transportna ili prijelazna kontrola. Problem nastaje ako sama VPN veza daje širok pristup bez provjere resursa, uređaja i ovlasti.

Mora li se provjera događati pri svakom mrežnom paketu?+

Ne. NIST govori o pristupu po sesiji i dinamičnim odlukama. Koliko često se kontekst ponovno procjenjuje ovisi o resursu, riziku i tehničkim mogućnostima.

Koliko traje i košta primjena?+

Nema pouzdanog univerzalnog roka ili cijene. Ovisi o inventaru, postojećem upravljanju identitetima, naslijeđenim sustavima, broju resursa i sposobnosti tima. Pilot po jednom poslovnom resursu daje bolju osnovu za procjenu od višegodišnje deklaracije bez opsega.

Može li Zero Trust spriječiti svaki napad?+

Ne. Može smanjiti vjerojatnost neovlaštenog pristupa i ograničiti širenje, ali pogrešna politika, ranjiva aplikacija, kompromitirana provedbena točka ili legitimna zlouporaba i dalje mogu uzrokovati incident. Potrebni su nadzor, odgovor i oporavak.

Povezani vodiči

• Kibernetički napadi: vrste i zaštita
• Penetracijski testovi i procjena ranjivosti
• Upravljanje kibernetičkim incidentima

Izvori i pregled

Sadržaj je stručno pregledan 8. kolovoza 2026. prema sljedećim primarnim i službenim izvorima:

• NIST SP 800-207 — Zero Trust Architecture
• NIST SP 800-207A — Zero Trust Architecture Model for Access Control in Cloud-Native Applications
• NIST — Planning for a Zero Trust Architecture
• Direktiva (EU) 2022/2555 — članak 21.
• Uredba o kibernetičkoj sigurnosti, NN 135/2024

Ovaj vodič daje arhitektonski i regulatorni okvir. Konkretne politike pristupa moraju se projektirati i testirati prema poslovnim procesima, sigurnosti ljudi, tehničkim ograničenjima i procjeni rizika.