ZSIS preporuke za sigurnost e-pošte: čitanje svih 38 stranica, parametar po parametar

O ovom se dokumentu u Hrvatskoj govori uglavnom u jednoj rečenici — da postoji. Rijetko se prolazi kroz ono što u njemu doista piše. A piše dosta konkretno: koje inačice protokola koristiti, koje algoritme, koje veličine ključeva, kojim redoslijedom uvoditi mehanizme i kako na kraju provjeriti da je sve postavljeno kako treba.

Prošli smo cijeli dokument i usporedili svaku preporuku s aktualnim stanjem standarda. Ovdje je rezultat: što se traži, gdje se preporuka razilazi s onim što uobičajeni alati mjere, što se u međuvremenu promijenilo i kako svaku stavku provjeriti na vlastitoj domeni.

Što je taj dokument i tko stoji iza njega

Izdavač je Zavod za sigurnost informacijskih sustava — državno tijelo nadležno za sigurnost informacijskih sustava u Republici Hrvatskoj. Dokument ima 38 stranica i jasnu strukturu koja prati redoslijed uvođenja:

• STARTTLS — zaštita samog prijenosa poruke između poslužitelja, uključujući postavke TLS-a i certifikata.
• SPF — popis poslužitelja koji smiju slati poštu u ime domene.
• DKIM — kriptografski potpis kojim poruka nosi dokaz o podrijetlu.
• DMARC — politika koja povezuje prethodna dva i govori primatelju što učiniti kad provjera padne.
• Provjera dostupnosti i ispravnosti mehanizama — zasebno poglavlje o tome kako potvrditi da sve doista radi.

Svako poglavlje razdvaja konfiguraciju na strani pošiljatelja (izlaz poruka) od konfiguracije na strani primatelja (ulaz poruka). To je razlika koju većina vodiča preskoči, a bitna je: postaviti SPF zapis za vlastitu domenu i provjeravati tuđi SPF pri primitku pošte dvije su različite stvari i rade se na različitim mjestima.

Prvo pošteno: dokument je pisan kad je TLS 1.3 bio novost

U tekstu stoji da je TLS 1.3 objavljen krajem 2018. i da još nije u širokoj upotrebi. To dobro smješta dokument u vrijeme i objašnjava zašto neke formulacije danas zvuče oprezno. Otada se promijenilo dvoje, i profesionalno je to znati prije nego se dokument primijeni doslovno.

TLS 1.3 danas više nije novost nego zadana vrijednost. Ono što je tada bilo „poželjno“ danas je uobičajeno, i nema razloga da ga poslužitelj nema.

Veća promjena dogodila se u svibnju 2026.: DMARC je dobio nove dokumente standarda (RFC 9989, 9990 i 9991) koji zamjenjuju dotadašnji RFC 7489. DMARC je time iz kategorije „informativno“ prešao u standard. Uz to je parametar pct= povučen, a organizacijska domena više se ne izvodi iz javne liste sufiksa nego iz DNS-a.

Redoslijed koji ZSIS propisuje — i zašto baš taj

Redoslijed poglavlja nije slučajan i vrijedi ga poštovati. Prvo se štiti prijenos (STARTTLS), zatim se utvrđuje tko smije slati (SPF), pa se porukama daje potpis (DKIM), i tek na kraju dolazi politika koja na temelju prethodnog nešto odbija (DMARC).

Obrnut redoslijed je najčešći uzrok problema u praksi. Tko prvo objavi strogu DMARC politiku, a tek onda počne slagati SPF i DKIM, sam si blokira vlastitu poštu — i to najčešće onu koju šalju sustavi na koje je zaboravio: računovodstveni program, webshop, alat za newsletter, pisač koji šalje skenove.

Parametar po parametar: što se točno traži

STARTTLS i postavke TLS-a

• Koristiti TLS inačice 1.2 ili 1.3.
• Izričito onemogućiti zastarjele inačice — SSLv2, SSLv3 i TLSv1.
• Za razmjenu ključeva koristiti Diffie-Hellman s efemernim ključem (forward secrecy).
• Za sažimanje koristiti SHA-256 ili SHA-384.
• Posložiti skup algoritama po prioritetu, od najsigurnijeg prema manje sigurnom — i osigurati da poslužitelj taj redoslijed doista primjenjuje, a ne da izbor prepusti drugoj strani.

Zadnja stavka je ona koju alati najčešće ne provjere. Jedna veza pokaže samo šifru koju je poslužitelj u tom trenutku odabrao — ne i cijeli popis onoga što bi prihvatio da ga se pita drugačije. Da bi se to vidjelo, treba postaviti više odvojenih upita, po jedan za svaku skupinu algoritama.

Certifikat

• Privatni ključ od barem 2048 bita, uz SHA-256.
• Kao Common Name postaviti ime MX poslužitelja — dakle ono ime na koje se druga strana doista spaja.
• Certifikat potpisati kod općeprihvaćenog izdavatelja, ne vlastitim potpisom.
• Poslužitelj podesiti da taj potpisani certifikat i koristi.

SPF

Kod SPF-a se preporuka tiče završnog kvalifikatora. Dvije su uobičajene mogućnosti: ~all (SoftFail, „vjerojatno nije naše, ali propusti“) i -all (Fail, „nije naše“). ZSIS preporučuje stroži oblik, uz izričitu napomenu da treba biti siguran da su svi legitimni pošiljatelji doista pokriveni prije nego se stegne.

tvrtka.hr.    TXT    "v=spf1 include:spf.protection.outlook.com -all"

# -all  = sve što nije gore navedeno nije naše (preporučeno)
# ~all  = blaži oblik, koristan samo tijekom uvođenja

DKIM

Preporuka je ključ od barem 2048 bita. Zvuči kao tehnička sitnica, ali upravo je to mjesto na kojem hrvatska preporuka odstupa od međunarodne — o tome odmah niže.

DMARC

Ovdje je dokument najprecizniji i, po našem mišljenju, najkorisniji. Preporučuje se početi od politike koja ništa ne odbija, pustiti da stignu izvještaji, prepoznati probleme s isporukom, i tek onda stezati. Izričito se napominje da prijelaz ne treba biti brz.

# 1. početak — ništa se ne odbija, samo se skupljaju izvještaji
_dmarc.tvrtka.hr.  TXT  "v=DMARC1;p=none;rua=mailto:[email protected]"

# 2. međukorak — glavna domena još popušta, poddomene su već zaključane
_dmarc.tvrtka.hr.  TXT  "v=DMARC1;p=none;sp=reject;rua=mailto:[email protected]"

# 3. preporučeno završno stanje, uz strogo poravnanje
_dmarc.tvrtka.hr.  TXT  "v=DMARC1;p=reject;aspf=s;adkim=s;rua=mailto:[email protected]"

Onaj međukorak sa sp=reject rijetko se vidi u vodičima, a rješava stvaran problem: poddomene se gotovo nikad ne koriste za legitimno slanje, pa se mogu zaključati odmah, dok glavna domena još prolazi kroz razdoblje promatranja. Napadači poddomene vole upravo zato što ostanu otvorene.

Dva mjesta gdje preporuka traži više nego što alati provjeravaju

Ovo je dio zbog kojeg dokument vrijedi pročitati čak i ako već slijedite međunarodne preporuke. Ne zato što bi ZSIS izmislio strože pragove — nego zato što na dva mjesta imenuje ono što standard ostavlja kao preporuku, a alati je uglavnom ne provjeravaju.

1. Duljina DKIM ključa

Ovdje treba biti precizan, jer se lako pogriješi. RFC 8301 postavlja dvije različite stvari: potpisnik MORA koristiti ključ od barem 1024 bita, ali BI TREBAO koristiti barem 2048. Prvo je tvrda granica, drugo je preporuka. ZSIS preporučuje 2048 — dakle poklapa se s preporukom standarda, ne nadmašuje je.

2. Strogo poravnanje

U preporučenom završnom DMARC zapisu stoje aspf=s i adkim=s — strogo poravnanje. Zadana vrijednost u standardu je blaža (relaxed) i dopušta da se domena u zaglavlju i domena u potpisu razlikuju do razine organizacijske domene. Strogo poravnanje traži da se poklapaju točno. To je uži i sigurniji izbor, i mnogi vodiči ga ni ne spominju.

Poglavlje 6: ZSIS traži provjeru iz perspektive treće strane

Zasebno poglavlje posvećeno je provjeri da su mehanizmi doista ispravno postavljeni. Ključna je rečenica da provjeru treba provesti iz perspektive neovisne organizacije — dakle izvana, tako da se simuliraju uvjeti stvarnog prijenosa poruke.

To je tehnički važna uputa, a ne formalnost. Konfiguracija koja iznutra izgleda ispravno može se izvana ponašati drukčije: DNS može odgovarati različito ovisno o tome tko pita, poslužitelj može stajati iza raspoređivača opterećenja pa svaka veza završi na drugom stroju, a certifikat koji lokalno prolazi može pasti kod stvarnog pošiljatelja.

Dokument potom imenuje i konkretne javno dostupne servise za takvu provjeru — među njima internet.nl, MXToolbox i MECSA. Vrijedi to znati jer je rijetkost da nacionalni dokument ovako izravno uputi na alate.

Što ovaj dokument ne pokriva

Pošteno je reći i gdje su granice. Dokument je nastao prije nego što su neke stvari postale uobičajene, pa u njemu nećete naći:

• BIMI — prikaz logotipa uz poruku; još uvijek nije formalni standard, pa je izostanak razumljiv.
• Ovlaštenje za vanjske primatelje DMARC izvještaja — ako izvještaje šaljete na tuđu domenu, ona to mora potvrditi posebnim zapisom, inače ih smije odbiti.
• TLS-RPT — izvještaje o neuspjelim pokušajima šifriranog prijenosa.
• Novije DMARC parametre koji su uvedeni 2026. godine.

DANE i MTA-STS dokument spominje kao alternativne mehanizme zaštite prijenosa, uz točnu napomenu da DANE traži prethodno uspostavljen DNSSEC i da ga tada mnogi poslužitelji još nisu podržavali. Ta napomena danas je manje ograničavajuća nego što je bila.

Kako ovo primijeniti bez lutanja

• Izmjerite postojeće stanje izvana, prije nego išta mijenjate — bez toga ne znate što ste popravili.
• Krenite od zaštite prijenosa: TLS 1.2 i 1.3, zastarjele inačice isključene, uredan certifikat na ime MX poslužitelja.
• Popišite sve koji legitimno šalju u Vaše ime, pa tek onda stegnite SPF na -all.
• Postavite DKIM s ključem od 2048 bita, ne 1024 — i provjerite da potpisuje svaki izlazni tok, ne samo glavni.
• DMARC vodite postupno: p=none uz izvještaje, zatim sp=reject za poddomene, pa tek onda p=reject sa strogim poravnanjem.
• Na kraju ponovite mjerenje izvana i sačuvajte nalaz — to je dokaz koji vrijedi pred upravom i u dokumentaciji.

Cijeli postupak nije ni dug ni skup. Najveći dio posla nije tehnički nego evidencijski: doznati tko sve šalje poštu u ime domene. Tu se gubi vrijeme i tu nastaju blokade — ne u samim DNS zapisima.

Partner

PowerDMARC

Sloj autentikacije domene

Zaštitom upravljamo s centralnog panela, čitamo izvještaje umjesto Vas i pišemo mjesečni nalaz na hrvatskom — u dvije verzije, za upravu i za IT. Pristup platformi je i Vaš.

Hornetsecurity Authorized Partner

Hornetsecurity by Proofpoint

Sloj oko sandučića

Radimo audit, plan, uvođenje i izvještavanje. Ako procijenimo da Vam ovaj sloj ne treba, reći ćemo to prije nego što ga ponudimo.

Posao radimo mi; platforme partnera koristimo za nadzor i za sloj oko sandučića. Njihovi certifikati opisuju njihov proizvod, ne našu uslugu.