Na kratko: Dvofaktorska avtentikacija za skrbniške dostope poskrbi, da ukradeno ali ugibano geslo samo ne zadošča. Veljati mora povsod, kjer lahko nekdo spremeni vašo spletno stran ali strežnik: CMS, gostovanje, panel, SSH, domena, DNS in poštni predali skrbnikov. Enako pomembni kot nastavitev so zasilne kode in jasno pravilo, kdo ima za kaj lasten dostop.
Zakaj gesla same za skrbnike ne zadoščajo
Gesla se izgubijo na mnogo načinov: z lažnimi e-sporočili (phishing), škodljivo programsko opremo na delovnem računalniku, uhajanjem podatkov pri drugih storitvah ali preprosto s ponovno uporabo. Samodejni napadi neprestano preizkušajo ukradene dostopne podatke na znanih prijavnih straneh.
Z drugim faktorjem napadalec dodatno potrebuje nekaj, kar ima samo pooblaščeni uporabnik, na primer pametni telefon z aplikacijo za avtentikacijo ali varnostni ključ. To oviro občutno dvigne, še posebej pri računih z obsežnimi pravicami.
Za vodstvo je pomembna razmejitev: dvofaktorska prijava ščiti dostope, ne programske opreme za njimi. Ranljivosti, kot je PHP2Shell, ki omogoča izvajanje kode brez prijave, s tem ne zaprete. Oboje sodi skupaj: aktualna programska oprema in dobro zaščiteni dostopi.
Kateri postopki dvofaktorske avtentikacije so primerni
Postopki se razlikujejo po varnosti in udobju uporabe. Za skrbniške račune uporabite vsaj aplikacije za avtentikacijo, za posebej kritične dostope varnostne ključe ali passkeys.
| Postopek | Zaščita pred phishingom | Primernost za skrbnike |
|---|---|---|
| Koda SMS | nizka | samo kot prehod |
| Aplikacija za avtentikacijo (TOTP) | srednja | dober standard |
| Potrditev s potisnim obvestilom | srednja, dovzetna za napade z utrujanjem | primerna z ujemanjem številk |
| Varnostni ključ ali passkey (FIDO2/WebAuthn) | visoka | priporočeno za kritične dostope |
| Ključ SSH s frazo za geslo | visoka | standard za dostope do strežnikov |
Enkratne kode iz aplikacije je mogoče prestreči na zavajajoče pristni phishing strani in jih takoj uporabiti naprej. Postopki FIDO2 pa preverijo naslov strani in na ponarejeni strani ne delujejo. To je razlog, zakaj so za skrbnike z dostopom do številnih sistemov najboljša izbira.
Dvofaktorska avtentikacija za skrbniške dostope: popoln seznam
Napadalci izberejo najšibkejši dostop. Zato pojdite skozi vsa mesta, kjer lahko nekdo spremeni vašo spletno stran, strežnik ali domeno:
- CMS in zaledje trgovine: WordPress, Shopware, TYPO3 in drugi ponujajo dvofaktorsko prijavo v jedru ali prek vzdrževanih razširitev. Katera različica je priporočena, piše v dokumentaciji proizvajalca.
- Račun stranke pri ponudniku gostovanja: Kdor pride sem, lahko pogosto ponastavi gesla, prenese varnostne kopije ali strežnik znova namesti.
- Panel strežnika, kot sta Plesk ali cPanel, če obstaja.
- SSH in SFTP: ključ namesto gesla, glejte naslednji razdelek.
- Registrar domene in DNS: Spremenjena nastavitev DNS vaše obiskovalce in pošto preusmeri, ne da bi bil strežnik prizadet.
- Poštni predali skrbnikov: Prek njih tečejo ponastavitve gesel za skoraj vse druge storitve.
- Repozitorij kode in deployment: Kdor tam sme pisati, lahko uvede škodljivo kodo.
- CDN, WAF, Google Search Console in ponudniki plačil.
Za vsak vnos določite, kdo ima dostop, ali je drugi faktor aktiven in kje so obnovitvene kode. Ta seznam je hkrati pomemben del vašega načrta za nujne primere, saj je treba po incidentu prav te dostope v kratkem času preveriti in obnoviti.
SSH: ključ namesto gesla
Za dostope do strežnikov je prijava s ključem SSH običajna močna zaščita. Zasebni ključ je na napravi skrbnika in zaščiten s frazo za geslo; pri posebej varovanih strežnikih je lahko na strojnem ključu. Ko je prijava s ključem za vse skrbnike nastavljena in preizkušena, prijavo z geslom izklopite:
# /etc/ssh/sshd_config (izvleček)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Preverite konfiguracijo, preden storitev znova naložite
sshd -t && systemctl reload ssh # pri sistemih RHEL: sshd
Pri preklopu pustite obstoječo sejo odprto in prijavo preizkusite v drugem oknu. Tako se ob napaki ne zaklenete. Vsak skrbnik dobi lasten ključ; skupnih ključev za celotno ekipo ob odhodu posameznih oseb ni mogoče čisto odvzeti. Dodatne osnove opisuje stran Samostojna zaščita root strežnika in vServerja.
Zasilni dostop in obnovitvene kode
Dobra uvedba vnaprej upošteva izpad. Pametni telefoni se izgubijo, zaposleni zapustijo podjetje, varnostni ključi se pokvarijo. Brez načrta potem ob napačnem trenutku nihče nima dostopa.
Za vsak kritičen račun registrirajte dva faktorja, na primer varnostni ključ v pisarni in aplikacijo za avtentikacijo, obnovitvene kode pa hranite ločeno od gesla.
Dodatna pravila, ki so se obnesla:
- Osebni računi namesto skupno rabljenih skrbniških prijav, da so spremembe sledljive.
- Dokumentiran zasilni dostop z ločeno hranjenimi dostopnimi podatki, katerega uporaba je opazna in se beleži.
- Ob odhodu zaposlenih ali izvajalcev vse dostope in ključe odvzeti isti dan.
- Po varnostnem incidentu preveriti ne le gesla, ampak tudi registrirane faktorje in aktivne seje.
Pri uvedbi v ekipi se je obnesel jasen potek. Začnite z računi, ki lahko povzročijo največ škode: gostovanje, domena, DNS in poštni predali skrbnikov. Nato sledijo strežniki, CMS in storitve. Določite datum, od katerega prijave brez drugega faktorja niso več mogoče, in vnaprej zagotovite, da so vsi udeleženci nastavljeni.
Ekipi na kratko razložite, zakaj je preklop potreben in kako deluje v vsakdanu. Enostransko navodilo s posnetki zaslona občutno zmanjša število vprašanj. Zunanji izvajalci in agencije naj dobijo lastne, osebne dostope z drugim faktorjem namesto skupne prijave, da dostopi ostanejo pripisljivi in jih je po koncu projekta mogoče čisto odvzeti.
Kako prijavne strani dodatno zaščitite pred samodejnimi poskusi, piše v vodniku Zaščita skrbniških prijav pred brute force.
Kako PHP SOS pomaga konkretno?
- Z vami pripravimo popoln seznam vseh skrbniških dostopov in pokažemo, kje drugi faktor manjka.
- Dostope do strežnikov preklopimo na ključe SSH in prijave z geslom nadzorovano izklopimo v okviru utrjevanja strežnika.
- Zasilne dostope in poti obnovitve dokumentiramo tako, da v nujnem primeru delujejo.
- V vzdrževalni pogodbi za varnost dostope redno preverjamo in odstranjujemo osirotele račune.
Pogosta vprašanja
Kateri postopek dvofaktorske avtentikacije je najvarnejši?
Strojni varnostni ključi in passkeys po standardu FIDO2 veljajo za posebej odporne proti phishingu, ker so vezani na pravi naslov. Aplikacije za avtentikacijo z enkratnimi kodami so dober standard. SMS je boljši kot nič, vendar najšibkejša različica.
Kaj se zgodi, če izgubim pametni telefon z aplikacijo za avtentikacijo?
Za to obstajajo obnovitvene kode, ki se prikažejo ob nastavitvi. Hraniti jih je treba varno, na primer v trezorju ali v zaščitenem upravljalniku gesel. Poleg tega naj dostop lahko ponastavi vsaj še en skrbnik.
Ali dvofaktorska prijava ščiti tudi pred PHP2Shell?
Ne. PHP2Shell omogoča izvajanje kode brez prijave, prijava se pri tem sploh ne uporablja. Proti PHP2Shell pomaga samo posodobitev na odpravljeno različico PHP s ponovnim zagonom vseh workerjev. Dvofaktorska prijava ščiti pred ukradenimi ali ugibanimi gesli.
Ali zadošča dvofaktorska prijava v CMS-ju?
Ne, napadalec izbere najšibkejši dostop. Račun za gostovanje, panel strežnika, SSH, upravljanje domene, DNS in poštni predali skrbnikov morajo biti prav tako zaščiteni, sicer je zaščito CMS-ja mogoče zaobiti.