# Postavljanje dvofaktorske autentifikacije za admin pristupe

> Dvofaktorska autentifikacija za admine: prikladni postupci, svi važni pristupi od CMS-a do SSH-a, kodovi za hitne slučajeve i uredno uvođenje u timu.

Izvor: https://phpsos.de/hr/ratgeber/zwei-faktor-admin/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Dvofaktorska autentifikacija za admin pristupe osigurava da ukradena ili pogođena lozinka sama ne bude dovoljna. Mora vrijediti posvuda gdje netko može mijenjati Vašu web-stranicu ili poslužitelj: CMS, hosting, panel, SSH, domena, DNS i poštanski sandučići admina. Jednako važni kao postavljanje su kodovi za hitne slučajeve i jasno pravilo tko za što ima vlastiti pristup.

## Zašto same lozinke nisu dovoljne za admine

Lozinke se gube na mnogo načina: phishing porukama, zlonamjernim softverom na radnom računalu, curenjem podataka kod drugih usluga ili jednostavno ponovnom uporabom. Automatizirani napadi neprekidno isprobavaju ukradene pristupne podatke na poznatim stranicama za prijavu.

S drugim faktorom napadaču je dodatno potrebno nešto što posjeduje samo ovlašteni korisnik, primjerice pametni telefon s authenticator aplikacijom ili sigurnosni ključ. To znatno podiže prepreku, osobito kod računa sa širokim ovlastima.

Za upravu je važno razgraničenje: dvofaktorska prijava štiti pristupe, a ne softver iza njih. Ranjivost poput PHP2Shella, koja omogućuje izvršavanje koda bez prijave, time se ne zatvara. Jedno i drugo ide zajedno: aktualan softver i dobro zaštićeni pristupi.

## Koji su dvofaktorski postupci prikladni

Postupci se razlikuju po sigurnosti i udobnosti rada. Za admin račune trebali biste koristiti barem authenticator aplikacije, a za osobito kritične pristupe sigurnosne ključeve ili passkeyove.

| Postupak | Zaštita od phishinga | Prikladnost za admine |
|---|---|---|
| SMS kod | mala | samo kao prijelaz |
| Authenticator aplikacija (TOTP) | srednja | dobar standard |
| Push potvrda | srednja, podložna napadima iscrpljivanjem | prikladna uz usporedbu brojeva |
| Sigurnosni ključ ili passkey (FIDO2/WebAuthn) | visoka | preporučeno za kritične pristupe |
| SSH ključ s passphraseom | visoka | standard za pristupe poslužitelju |

Jednokratni kodovi iz aplikacije mogu se presresti na varljivo pravoj phishing stranici i odmah ponovno upotrijebiti. FIDO2 postupci, nasuprot tome, provjeravaju adresu stranice i na krivotvorenoj stranici ne rade. To je razlog zašto su najbolji izbor za admine s pristupom mnogim sustavima.

## Dvofaktorska autentifikacija za admin pristupe: potpuni popis

Napadači biraju najslabiji pristup. Zato prođite sva mjesta na kojima netko može mijenjati Vašu web-stranicu, poslužitelj ili domenu:

- **CMS i shop backend:** WordPress, Shopware, TYPO3 i drugi nude dvofaktorsku prijavu u jezgri ili putem održavanih ekstenzija. Koja se varijanta preporučuje, navedeno je u dokumentaciji proizvođača.
- **Korisnički račun za hosting:** Tko ovdje uđe, često može ponovno postaviti lozinke, preuzeti sigurnosne kopije ili ponovno instalirati poslužitelj.
- **Panel poslužitelja** poput Plesk ili cPanel, ako postoji.
- **SSH i SFTP:** ključ umjesto lozinke, vidi sljedeći odjeljak.
- **Registrar domene i DNS:** Promijenjena DNS postavka preusmjerava Vaše posjetitelje i poštu, a da poslužitelj nije pogođen.
- **Poštanski sandučići admina:** Preko njih idu ponovna postavljanja lozinki za gotovo sve druge usluge.
- **Repozitorij koda i deployment:** Tko tamo smije pisati, može isporučiti zlonamjerni kod.
- **CDN, WAF, Google Search Console i pružatelji plaćanja.**

Za svaku stavku utvrdite tko ima pristup, je li drugi faktor aktivan i gdje se nalaze kodovi za oporavak. Taj je popis ujedno važan dio Vašeg plana za hitne slučajeve jer se nakon incidenta upravo ti pristupi moraju u kratkom roku provjeriti i obnoviti.

## SSH: ključ umjesto lozinke

Za pristupe poslužitelju prijava SSH ključem uobičajena je jaka zaštita. Privatni ključ nalazi se na uređaju admina i zaštićen je passphraseom; kod osobito osjetljivih poslužitelja može biti na hardverskom ključu. Kad je prijava ključem postavljena i testirana za sve admine, isključite prijavu lozinkom:

```text
# /etc/ssh/sshd_config (izvadak)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
```

```bash
# Provjeriti konfiguraciju prije ponovnog učitavanja servisa
sshd -t && systemctl reload ssh   # na RHEL sustavima: sshd
```

Pri prebacivanju ostavite postojeću sesiju otvorenom i testirajte prijavu u drugom prozoru. Tako se kod pogreške nećete isključiti. Svaki admin dobiva vlastiti ključ; zajednički ključevi za cijeli tim ne mogu se uredno oduzeti kad pojedine osobe odu. Daljnje osnove opisuje vodič [Samostalno osiguravanje root poslužitelja i vServera](https://phpsos.de/hr/server/root-server-vserver/).

## Hitni pristup i kodovi za oporavak

Dobro uvođenje uračunava i ispad. Pametni telefoni se gube, zaposlenici napuštaju tvrtku, sigurnosni ključevi se kvare. Bez plana tada u krivom trenutku nitko nema pristup.

> **Savjet:**
> Za svaki kritičan račun registrirajte dva faktora, primjerice sigurnosni ključ u uredu i authenticator aplikaciju, a kodove za oporavak pohranite odvojeno od lozinke.

Daljnja pravila koja su se pokazala dobrima:

- Osobni računi umjesto zajednički korištenih admin prijava, kako bi promjene bile sljedive.
- Dokumentiran hitni pristup s odvojeno pohranjenim pristupnim podacima, čije se korištenje primjećuje i bilježi.
- Pri odlasku zaposlenika ili pružatelja usluga oduzeti sve pristupe i ključeve istog dana.
- Nakon sigurnosnog incidenta provjeriti ne samo lozinke, nego i registrirane faktore i aktivne sesije.

Pri uvođenju u timu pokazao se dobrim jasan tijek. Počnite s računima koji mogu napraviti najveću štetu: hosting, domena, DNS i poštanski sandučići admina. Zatim slijede poslužitelji, CMS i usluge. Odredite datum od kojeg prijave bez drugog faktora više nisu moguće i prethodno osigurajte da su svi sudionici postavljeni.

Timu ukratko objasnite zašto je prelazak potreban i kako funkcionira u svakodnevici. Jednostranična uputa sa snimkama zaslona znatno smanjuje broj pitanja. Vanjski pružatelji usluga i agencije trebali bi dobiti vlastite, osobne pristupe s drugim faktorom umjesto zajedničke prijave, kako bi pristupi ostali dodjeljivi i kako bi se nakon završetka projekta mogli uredno oduzeti.

Kako stranice prijave dodatno zaštititi od automatiziranih pokušaja, nalazi se u vodiču [Zaštita admin prijava od brute forcea](https://phpsos.de/hr/ratgeber/brute-force-login-schutz/).

## Kako PHP SOS konkretno pomaže?

- S Vama izrađujemo potpuni popis svih admin pristupa i pokazujemo gdje drugi faktor nedostaje.
- Pristupe poslužitelju prebacujemo na SSH ključeve i kontrolirano isključujemo prijave lozinkom u okviru [ojačavanja poslužitelja](https://phpsos.de/hr/leistungen/server-haertung/).
- Hitne pristupe i putove oporavka dokumentiramo tako da u kritičnom slučaju funkcioniraju.
- U [ugovoru o sigurnosnom održavanju](https://phpsos.de/hr/leistungen/security-wartungsvertrag/) redovito provjeravamo pristupe i uklanjamo napuštene račune.


## Česta pitanja

**Koji je dvofaktorski postupak najsigurniji?**  
Hardverski sigurnosni ključevi i passkeyi prema FIDO2 standardu smatraju se osobito otpornima na phishing jer su vezani uz pravu adresu. Authenticator aplikacije s jednokratnim kodovima dobar su standard. SMS je bolji nego ništa, ali najslabija varijanta.

**Što ako se izgubi pametni telefon s authenticator aplikacijom?**  
Za to postoje kodovi za oporavak koji se prikazuju pri postavljanju. Treba ih sigurno pohraniti, primjerice u sef ili zaštićeni upravitelj lozinki. Dodatno bi barem još jedan admin trebao moći ponovno postaviti pristup.

**Štiti li dvofaktorska prijava i od PHP2Shella?**  
Ne. PHP2Shell omogućuje izvršavanje koda bez prijave, a prijava se pritom uopće ne koristi. Protiv PHP2Shella pomaže samo ažuriranje na ispravljenu verziju PHP-a uz ponovno pokretanje svih workera. Dvofaktorska prijava štiti od ukradenih ili pogođenih lozinki.

**Je li dvofaktorska prijava u CMS-u dovoljna?**  
Ne, napadač bira najslabiji pristup. Hosting račun, panel poslužitelja, SSH, upravljanje domenom, DNS i poštanski sandučići admina moraju biti jednako zaštićeni, inače se zaštita CMS-a može zaobići.

## Izvori

- [BSI: dvofaktorska autentifikacija](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series (Multifactor Authentication)](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)