Zero Trust u srednjim preduzećima: mrežna segmentacija, usklađenost uređaja i pragmatične roadmap-e umjesto buzzworda

„Zero Trust“ na prvi pogled djeluje kao program velikih korporacija. U mnogim srednjim preduzećima to je ipak prije pragmatičan odgovor na ustaljenu realnost: filijale, hibridni timovi, pristupi partnera, cloud-servisi, mobilni uređaji i paralelno s tim klasične serverske usluge, ERP-Clients, Fileshares i specijalizovana oprema. Stari model „unutra je pouzdano, vani je opasno“ više ne vrijedi – jer kompromitovani klijent u internoj mreži često nađe previše puteva.

Zero Trust u srednjim preduzećima znači stoga prije svega: pristupi se ne odobravaju automatski na osnovu mrežne lokacije, već se odlučuje na osnovu identiteta, stanja uređaja (Device Compliance), konteksta i minimalno neophodnih prava. I: arhitektura se gradi tako da probijanje ne preraste automatski u široko rasprostranjen incident.

Ovaj članak odbacuje buzzword-e i koncentrira se na tri poluge koje u praksi donose najveći efekt: Netzwerksegmentierung (ko smije kamo komunicirati?), Device Compliance (koje stanje uređaja je preduvjet?) i Roadmaps, koje isporučuju u etapama umjesto čekanja na savršenu ciljnu sliku. Fokus je na posljedicama za operacije, administraciju, poslovni softver, sučelja i rollout.

Što Zero Trust praktično znači – a što ne

Ako „Zero Trust“ ne smije postati projekcijsko platno, pomaže jasna radna definicija. Prakticno, Zero Trust obuhvata tri principa:

• Eksplizitna verifikacija: Svaka odluka o pristupu zasniva se na signalima (identitet, MFA-status, stanje uređaja, rizik, osjetljivost ciljnog sistema).
• Least Privilege (minimalno potrebna prava): Korisnici, servisi i administratori dobivaju samo ono što im je za proces zaista potrebno – po mogućnosti vremenski ograničeno i provjerljivo.
• Assume Breach: Arhitektura i operacije pretpostavljaju da endpoint može biti kompromitovan. Cilj je ograničenje štete (Containment), a ne obećanje „spriječit ćemo sve“.

Nije riječ o: „sve iznova“, „samo Cloud“, „zamijenit ćemo LAN potpuno mikrosegmentacijom“ ili „blokirat ćemo sve dok poslovne jedinice ne odustanu“. Zero Trust mora raditi u svakodnevici: skeneri skeniraju, ERP-Clients rade, sučelja funkcioniraju, batch-procesi se pokreću noću, i postoji hitan put za administraciju.

Zašto srednja preduzeća s Zero Trust često napreduju brže nego što se misli

U srednjim preduzećima putevi odlučivanja su često kraći i ima manje paralelnih konkurentnih sigurnosnih inicijativa. Istovremeno su resursi ograničeniji, a poslovni softver ima duge životne cikluse. To može funkcionirati ako su mjere usmjerene na tipične pokretače rizika:

• Ransomware-lanci: Phishing → kompromitovani klijent → lateralno kretanje (npr. SMB/RDP) → identitet/Backup/Storage → šifrovanje.
• „Schatten“-pristupi: zaboravljeni VPN-nalozi, dijeljeni service accounts, pristupi partnera bez jasno definiranog vlasništva, trajna administratorska prava.
• Legacy-integracije: Fileshares kao „Integrationsbus“, fiksne IP-Whitelists, otvoreni portovi bez provjere stanja uređaja i bez datuma isteka.

Velika korist nije toliko „više sigurnosti u osjećaju“, koliko kontroliran efekt: manje dostupnih ciljeva iz klijentske zone, manje privilegovanih naloga u svakodnevnom radu i jasniji putevi za podatke i sučelja.

Netzwerksegmentierung als Zero-Trust-Baustein

Segmentacija mreže je najpristupačniji ulaz jer direktno ograničava lateralno kretanje. Radi se o svjesnom odvajanju dijelova sistema, tipično putem VLAN-ova/VRF-ova (logička segmentacija mreže na razini switch-a odnosno rutinga) plus Firewall-pravila između segmenata. Cilj nije izolovati svaki sistem pojedinačno, nego stvoriti zone s malom komunikacijom u kojima su dostupni samo definirani protokoli i ciljevi.

Pragmatična ciljna slika: zone koje spajaju operacije i sigurnost

Realistična ciljna slika u rastućim okruženjima često je u tri nivoa i po potrebi se proširuje:

• Client-Zone: uredski klijenti, laptopi, mobilni uređaji. Iz ove zone po mogućnosti nema pristupa admin-protokolima i upravljačkim sistemima.
• Server-/Workload-Zone: poslovni softver (ERP/CRM/portali), baze podataka, integracijski servisi, fajl-servisi. Pristup samo preko definiranih portova i poželjno preko aplikacijskih puteva.
• Admin-/Management-Zone: identitet (npr. Domain Controller/IdP), backup, virtualizacija, monitoring, mrežno upravljanje. Pristup samo s admin-radnih stanica ili preko bastion-hostova, restriktivno i evidentirano.

Ovo razdvajanje nije samo „mreža“. Ono je preduvjet da kasnije kontrole (usklađenost uređaja, privilegovani pristupi, zaštita između servisa) ne budu razorene plitkom Any-to-Any dostupnošću.

Stolperfallen: SMB, štampači/IoT i „privremeno“ otvoreni portovi

Segmentacija rijetko zakaže zbog switch-eva ili firewall-a, već zbog nejasnih tokova prometa. Tri obrasca su tipična:

• SMB/Fileshares kao integracijski bus: aplikacije upisuju fajlove u foldere, partneri ih preuzimaju, Excel-workflowi pristupaju mrežnim diskovima. Segmentacija tada zahtijeva odluke: koji putovi su zaista potrebni? Gdje je prelazak na SFTP/HTTPS, portale ili Message Broker smislen?
• Print/Scan/IoT: multifunkcijski uređaji, pisači etiketa, skeneri, proizvodni uređaji često komuniciraju s više servera. Ti uređaji trebaju vlastiti segment s minimalnim, dokumentiranim izuzecima i urednom inventarizacijom.
• „Jednom otvoreno, uvijek otvoreno“: RDP, SQL-portovi ili WinRM su otvoreni za projekt i ostanu. Segmentacija funkcionira samo uz vlasnike pravila i datum isteka za izuzetke.

Pokazalo se korisnim provoditi segmentaciju kao change-program: prvo vidljivost (Netflow/Firewall-Logs), zatim pilot-segmenti, pa rollout u valovima. Tko odmah provede politiku „Default Deny“ između svih VLAN-ova, izazvat će kvarove i izgubiti prihvaćenost.

Segmentacija za poslovni softver, baze podataka i integracije

Za individualni poslovni softver i softverska rješenja bliska procesima, segmentacija donosi dvostruki efekat: manji rizik i jasnije operativne slike. Tipične smjernice:

• App-Server → Datenbank: samo neophodan DB-port, samo iz definiranih app-subneta; nema direktnih klijentskih veza prema bazi podataka.
• Clients → Anwendung: po mogućnosti HTTPS prema web-frontendu ili API-ju, umjesto direktnog pristupa internim servisima ili dijeljenim mrežnim resursima.
• Integrationszone: dedikirani sistemi za REST/SOAP/SFTP/Message Broker, s kontroliranim putovima u ERP/CRM i prema partnerima.

Time postaju vidljive arhitektonske teme koje su inače „skrivene“ u mreži: fat-klijenti koji direktno komuniciraju s bazama podataka; batch-procesi kojima su potrebna admin-odobrenja; ili sučelja koja „samo rade“ bez jasne odgovornosti.

Usklađenost uređaja: stanje uređaja kao preduvjet pristupa

Drugi poluga je usklađenost uređaja, jer su krajnji uređaji često ulazna tačka. „Compliance“ ovdje ne znači pravnu usklađenost, već tehničke minimalne zahtjeve: nivo patchanja, enkripcija (z. B. BitLocker/FileVault), aktivna zaštita od malwarea, status firewalla, Secure Boot sowie der Nachweis, dass das Gerät verwaltet ist (MDM/Endpoint Management).

U Microsoft-Umgebungen wird das häufig mit Intune/Endpoint Manager plus Conditional Access umgesetzt. Conditional Access sind Richtlinien, die beim Login entscheiden, ob Zugriff erlaubt ist (z. B. nur mit MFA und nur von compliant Devices). In anderen Stacks passiert Vergleichbares über MDM, Identity Provider (IdP) und ZTNA/SSE-Lösungen. Entscheidend ist nicht das Werkzeug, sondern die betrieblich durchhaltbare Policy.

Politike koje podržavaju rad i podršku

Čest uzrok frustracije su preoštra pravila bez stepenovanih scenarija pristupa. Praktično je model s nivoima:

• Osnovno: MFA za sve; blok za nepoznate uređaje kod kritičnih aplikacija (Admin-Portale, Finance, HR, Remotezugänge).
• Standard: Pristup centralnim portalima i kolaboraciji samo s registriranih uređaja; neregistrirani uređaji samo ograničeno (z. B. Web-only), wenn die Plattform das unterstützt.
• Visoko: Administratorski pristupi samo s dedikovanih Admin-Workstations (PAW, Privileged Access Workstation) s strožim pravilima usklađenosti i bez lokalnih administratorskih prava u svakodnevnom radu.

Važno: „compliant“ nije trajno stanje. Uređaji mogu izaći iz usklađenosti (Update-Rückstand, Verschlüsselungsfehler, veraltetes OS). Zero Trust znači then: ne diskutieren, sondern kontrolliert zurückstufen. Beispiel: Portalzugriff bleibt möglich, VPN oder Zugriff in Management-Zonen wird gesperrt, bis Remediation erfolgt.

BYOD, specijalni uređaji i neupravljivi Endpoints

Srednja preduzeća često imaju klase uređaja koje se ne mogu upravljati kao standardni laptopi: mjerni uređaji, mašinski PC-ovi, terminalni sistemi, skeneri, alte Windows-verzije für Spezialsoftware. Das wird handhabbar, wenn die IT Gerätekategorien definiert und daran Zugriffsrechte knüpft:

• Managed Standard Devices: puna usklađenost putem MDM/GPO, standard za poslove zasnovane na znanju i administraciju.
• RESTricted Devices: ograničeno upravljivi; smiju ići samo u izolirane segmente i samo do definisanih ciljnih sistema (z. B. Produktionsnetz → Integrationsgateway).
• Unmanaged/BYOD: pristup samo ograničenim servisima (z. B. Webmail/Portal) s MFA i jasnim ograničenjima za podatkovni tok.

Tako od „geht nicht“ nastaje stabilan kompromis: specijalni uređaji ostaju mogući, ali opseg je ograničen i time je rizik pod kontrolom.

NAC und 802.1X: Wenn das Netz nur noch bekannte Geräte zulässt

Usklađenost uređaja ne završava pri prijavi. Sljedeći korak je Network Access Control (NAC): uređaji dobivaju pristup mreži samo ako se identificiraju na switchu ili WLAN-u. 802.1X je standardni postupak pri kojem se uređaj putem certifikata ili korisničkog identiteta autentificira na mreži. Za uređaje bez 802.1X često se koristi MAB (MAC Authentication Bypass) – kao izuzetak, manje sigurno, ali ponekad neizbježno.

NAC je vrlo djelotvoran, ali operativno zahtjevan. Realnost: mnogi izuzeci (Drucker, IoT, Gäste, Altgeräte) su normalni. Ein NAC-Vorhaben bleibt beherrschbar, wenn es gestaffelt wird:

• Pilot na jednoj lokaciji ili isprva samo u korporativnom WLAN-u.
• Početak u Monitor-/Alert-Modu, radi učenja stvarne slike uređaja.
• Karantenski mrežni segment za nepoznate uređaje s jasnim procesima helpdeska i, gdje je moguće, samoposlužnom registracijom.

Dodatna korist: bolja inventarizacija. NAC prisiljava na „istinu o uređajima“ i time pruža temelje za segmentaciju, odgovor na incidente i odluke o životnom ciklusu.

Identiteti, uloge i servisni nalozi: Bez IAM-higijene ostaje fragmentirano

Zero Trust se često razumije kao mrežno ili endpoint pitanje. U provedbi, međutim, strana identiteta odlučuje o preciznosti i održivosti. IAM (Identity and Access Management) obuhvaća prijavu, uloge/grupe, procese Joiner‑Mover‑Leaver i tehničke račune (servisni nalozi).

Least Privilege u poslovnom softveru: konsolidirati uloge, odvojiti administratorske ovlasti

U ERP/CRM i portalima prava često nastaju povijesno: nova funkcija, nova uloga, pa zatim iznimka. Rezultat su preklapajuće dozvole i nejasni odgovori na „tko smije što?“. Pogodno za Zero Trust postaje kada se uloge modeliraju kao poslovne sposobnosti (npr. „odobriti račun“, „izmijeniti osnovne podatke“, „pokrenuti izvoz“) i tehničke administratorske privilegije su od njih dosljedno odvojene.

Za operativu je važno da se uloge mogu re‑certificirati: u fiksnim ciklusima odgovorne osobe potvrđuju da su pristupi i dalje potrebni. To ne mora biti birokratski, ali zahtijeva jasne vlasnike po području podataka.

Zaštititi servisne naloge i pristupe sučeljima

Mnogi kritični pristupi ne rade korisnici, nego servisi: integracijski poslovi, ETL, partner‑sučelja, batch procesi, Windows-Servisi ili Linux-servisi. Tipični rizici su statične lozinke, preširoka prava, nedostatak rotacije i nejasno vlasništvo. U Zero‑Trust kontekstu vrijedi:

• Poseban identitet po servisu: ne koristiti dijeljene naloge za više zadataka.
• Minimalna prava: npr. samo pravo pisanja u SFTP‑inbox umjesto potpunog pristupa dijeljenom resursu.
• Tajne profesionalno tretirati: ključevi/lozinke ne smiju biti u konfiguracijskim datotekama; omogućiti planiranu rotaciju, imenovati odgovorne.
• Mrežni putevi u skladu sa segmentacijom: integracijski servis komunicira s jasno definiranim ciljevima, ne „s cijelom serverskom mrežom“.

Pogotovo kod sučelja Zero Trust time postaje i arhitekturni zadatak: API‑Gateway ili Integration‑Proxy može centralizirati autentikaciju, ograničenja brzine (rate‑limits) i logiranje te smanjiti divlji rast. To ne zamjenjuje sigurnost aplikacija, ali stvara bolju kontrolu u radu.

Zero Trust u srednjem poduzetništvu kao roadmap: isporučivati u etapama

Funkcionalna roadmap ima dvije osobine: stvara vidljiva poboljšanja u nekoliko tjedana i ostaje prikladna za naredne faze proširenja. U praksi se pokazao fazni model koji je optimiziran ne za potpunost, već za poluge rizika.

Faza 0: identificirati kritične sustave, tokove podataka i vanjske pristupne točke

Prije nego što se blokira i segmentira, treba minimalna razina transparentnosti:

• Koji sustavi su kritični (ERP/DMS, baze podataka, backup, identitet, virtualizacija, integracijski serveri)?
• Koji putevi pristupa postoje (VPN, RDP/SSH, admin‑alati, API, SMB, SFTP)?
• Koje vanjske pristupne točke postoje (partneri, lokacije, Cloud‑Tenants, vanjski admin‑pristupi)?

Ovo nije poziv na savršenu CMDB. Ovo je radni popis koji kasnije omogućava održive izuzetke, pravila vatrozida i odgovornosti.

Faza 1: Ojačavanje identiteta – MFA, hitni pristupi, odvajanje admin-prijava

Mnoge okoline imaju MFA, ali ne uredno. Pouzdani minimalni standardi su:

• MFA za sve korisnike, posebno za udaljene pristupe i administrativne površine.
• Definisan hitni pristup („Break Glass“): odvojeno zaštićen, nadziran i namijenjen isključivo incidentima.
• Razdvajanje korisničkih i administratorskih računa, kako phishing ne bi automatski prenosio privilegije.

Korist je neposredna: mnogi napadi zapnu na drugom faktoru, a kompromitovani standardni računi rjeđe vode direktno na upravljački nivo.

Faza 2: Prvo nametnuti usklađenost uređaja na kritičnim ciljevima

Umjesto „svi uređaji odmah compliant“ obično je učinkovitije pravila vezati za krunske dragulje:

• Administrativni portali (virtualizacija, backup, upravljanje mrežom) samo s usklađenih uređaja.
• VPN samo s usklađenih uređaja ili s jako ograničenim ciljanim mrežama.
• Finance/HR-portali i osjetljivi izvoz podataka samo uz provjeru uređaja i jasna pravila sesije.

To stvara smisleni pritisak za migraciju: ko treba puni pristup, mora dovesti uređaj pod upravljanje. Istovremeno ne blokirate odmah sva radna mjesta.

Faza 3: Segmentacija mreže u talasima – prvo zaštititi backup i management

Ako se kratkoročno može provesti samo jedno pravilo segmentacije, često je to: Backup- i management-sistemi nisu direktno dostupni iz klijentske zone. To je snažan mehanizam koji usporava eskalaciju ransomwarea. Nakon toga slijede server-zone i definisana integracijska zona.

Za svaki talas treba plan povratka: šta se u hitnom slučaju privremeno smije otvoriti, kako se to dokumentuje, ko to ponovo zatvara? Bez tog mehanizma segmentacija će se u svakodnevici postepeno erodirati.

Faza 4: Upravljanje privilegovanim pristupom (PAM) i admin-radne stanice

Upravljanje privilegovanim pristupom (PAM) obuhvata tehnologiju i procese za ograničavanje privilegovanih pristupa: Just-in-Time prava (vremenski ograničena), putevi odobrenja, rotacija lozinki/ključeva i evidentiranje. Praktican početak u srednjim preduzećima često izgleda ovako:

• Posvećene admin-radne stanice (PAW) ili bastion-okruženje za RDP/SSH.
• Nijedna administratorska aktivnost sa svakodnevnih laptopa.
• Runbooki i logovi koji su u incidentu zaista upotrebljivi.

To smanjuje vjerovatnost da kompromitovani korisnički uređaj posluži kao odskočna daska u upravljačku zonu.

Operativna realnost: Gdje Zero Trust djeluje (i kako ga upravljati)

Zero Trust nije besplatan. Ko ga otvoreno planira, kasnije ima manje političkih trzavica. Tipične posljedice u radu:

Više upravljanja politikama i izuzecima

Na početku rastu prilagodbe: politika usklađenosti djeluje previše strogo, jedna lokacija ima specijalan hardver, neki servis ipak treba vezu. Razlika između haosa i napretka je jasan proces izuzetka: vremenski ograničen, s vlasnikom, dokumentiran, redovno provjeravan. Inače Zero Trust brzo opet postane „Any-to-Any, jer je hitno“.

Logiranje postaje preduvjet za otklanjanje problema

Kada se pristupi odlučuju na osnovu konteksta, logovi moraju biti pouzdani: IdP- i logovi autentifikacije, status endpointa, firewall-/VPN-logovi i idealno centralna analiza (SIEM ili konsolidovano upravljanje logovima). Bez logova pitanje „Zašto korisnik ne može pristupiti?“ nije reproducibilno, i politike se iz frustracije popuštaju.

Utjecaji na poslovni softver: autentifikacija, putevi podataka, certifikati

Mnogi sistemi ne moraju biti iznova izgrađeni, ali moraju odgovarati novim sigurnosnim pretpostavkama. Tipične prilagodbe:

• SSO preko OIDC/SAML umjesto lokalnih lozinki, gdje ima smisla. OIDC (OpenID Connect) je moderan protokol za prijavu preko IdP-a; SAML je i dalje raširen u enterprise-SSO.
• API umjesto Fileshare, tamo gdje bi segmentacija inače trajno zahtijevala iznimke.
• Zaštita servis‑na‑servis (npr. mTLS): mTLS je TLS sa uzajamnom provjerom certifikata, čime je i pozivajući servis jednoznačno identificiran.

Ove stavke nisu samo „sigurnost“. One se tiču operacija: rokovi valjanosti certifikata, rotacija tajni (Secret‑Rotation), deployments, monitoring i jasne odgovornosti za interfejse.

Mjeriti uspjeh, bez utapanja u metrike

Nekoliko mjerila je dovoljno da napredak bude upravljiv:

• Udio upravljanih uređaja (managed vs. unmanaged) i trend.
• Omjer compliant vs. non-compliant po grupi uređaja plus najčešći uzroci (ažuriranja, enkripcija, AV).
• Smanjenje ravnih mrežnih prava: broj Any‑to‑Any‑pravila između segmenata, broj privremenih iznimaka i njihova starost.
• Privileged Access: udio administratorskih prijava koje i dalje dolaze s uređaja koji nisu PAW; smanjenje trajnih administratorskih prava.
• Incident‑Signale: blokirani pristupi management‑zonama, neuobičajene autentifikacije, ponavljajući nalazi malwarea.

Pitanje je uvijek: Koja mjera mjerljivo smanjuje rizik, a da ne blokira rad?

Zaključak: Zero Trust je operativna odluka, a ne debata o alatima

Zero Trust u srednjim preduzećima funkcioniše ako se shvati kao kombinacija arhitekture, operacija i jasne kontrole pristupa. Segmentacija ograničava mogućnost kretanja u mreži, usaglašenost uređaja (Device Compliance) povećava prag ulaska, a etapna roadmap prvo štiti identitet, backup i upravljanje. Ključno je da se iznimke ne razvijaju neformalno, nego da se vode kao privremeni, dokumentovani proces – i da se rano planiraju utjecaji na poslovni softver, interfejse i životni ciklus certifikata/Secrets.

Razgovarati o projektu ili modernizacijskom poduhvatu s Net-Base.