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:
# /etc/ssh/sshd_config (izvadak)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# 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.
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.
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.
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.
- Hitne pristupe i putove oporavka dokumentiramo tako da u kritičnom slučaju funkcioniraju.
- U ugovoru o sigurnosnom održavanju 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.