Lühidalt: Kaheastmeline autentimine halduse ligipääsudele tagab, et varastatud või äraarvatud parool üksi ei piisa. See peab kehtima kõikjal, kus keegi saab teie veebisaiti või serverit muuta: sisuhaldussüsteem, hosting, paneel, SSH, domeen, DNS ja administraatorite postkastid. Sama tähtsad kui seadistamine on hädakoodid ja selge reegel, kellel on mille jaoks oma ligipääs.
Miks paroolidest administraatoritele üksi ei piisa
Paroolid lähevad kaotsi mitmel viisil: andmepüügikirjade, töötaja arvutis oleva kahjutarkvara, teiste teenuste andmelekete või lihtsalt taaskasutuse kaudu. Automatiseeritud rünnakud proovivad varastatud ligipääsuandmeid katkematult teadaolevate sisselogimislehtede vastu.
Teise faktoriga vajab ründaja lisaks midagi, mis on ainult õigustatud kasutajal, näiteks autentimisrakendusega nutitelefoni või turvavõtit. See tõstab lati oluliselt, eriti laiaulatuslike õigustega kontode puhul.
Juhatuse jaoks on oluline piiritlus: kaheastmeline autentimine kaitseb ligipääse, mitte nende taga olevat tarkvara. Turvaauku nagu PHP2Shell, mis lubab koodi käivitamist ilma sisselogimiseta, see ei sulge. Mõlemad kuuluvad kokku: ajakohane tarkvara ja hästi kaitstud ligipääsud.
Millised kaheastmelise autentimise meetodid sobivad
Meetodid erinevad turvalisuse ja kasutusmugavuse poolest. Halduskontode jaoks peaksite kasutama vähemalt autentimisrakendusi, eriti kriitiliste ligipääsude jaoks turvavõtmeid või passkey'sid.
| Meetod | Kaitse andmepüügi vastu | Sobivus administraatoritele |
|---|---|---|
| SMS-kood | väike | ainult üleminekuks |
| Autentimisrakendus (TOTP) | keskmine | hea standard |
| Push-kinnitus | keskmine, vastuvõtlik väsitusrünnakutele | numbrivõrdlusega sobib |
| Turvavõti või passkey (FIDO2/WebAuthn) | suur | soovitatav kriitilistele ligipääsudele |
| SSH-võti paroolifraasiga | suur | standard serveriligipääsudele |
Rakenduse ühekordseid koode saab petlikult ehtsal andmepüügilehel kinni püüda ja kohe edasi kasutada. FIDO2-meetodid kontrollivad seevastu lehe aadressi ja võltsitud lehel ei toimi. Seetõttu on need parim valik administraatoritele, kellel on juurdepääs paljudele süsteemidele.
Kaheastmeline autentimine halduse ligipääsudele: täielik nimekiri
Ründajad otsivad nõrgima ligipääsu. Käige seetõttu läbi kõik kohad, kus keegi saab teie veebisaiti, serverit või domeeni muuta:
- Sisuhaldussüsteem ja poe haldusala: WordPress, Shopware, TYPO3 ja teised pakuvad kaheastmelist autentimist tuumas või hooldatud laienduste kaudu. Millist varianti soovitatakse, on kirjas tootja dokumentatsioonis.
- Hostingu kliendikonto: Kes siia sisse pääseb, saab sageli paroole lähtestada, varukoopiaid alla laadida või serveri uuesti paigaldada.
- Serveripaneel nagu Plesk või cPanel, kui see on olemas.
- SSH ja SFTP: võti parooli asemel, vt järgmist lõiku.
- Domeeniregistripidaja ja DNS: muudetud DNS-seade suunab teie külastajad ja kirjad ümber, ilma et server oleks mõjutatud.
- Administraatorite e-posti postkastid: nende kaudu käivad peaaegu kõigi teiste teenuste parooli lähtestamised.
- Koodihoidla ja juurutus: kes seal kirjutada tohib, saab kahjuliku koodi välja rullida.
- CDN, WAF, Google Search Console ja maksepakkujad.
Fikseerige iga kirje kohta, kellel on ligipääs, kas teine faktor on aktiivne ja kus taastekoodid asuvad. See nimekiri on samal ajal oluline osa teie hädaolukorra plaanist, sest pärast intsidenti tuleb just need ligipääsud lühikese ajaga üle kontrollida ja uuendada.
SSH: võti parooli asemel
Serveriligipääsude jaoks on tavaline tugev kaitse sisselogimine SSH-võtmega. Privaatvõti asub administraatori seadmes ja on kaitstud paroolifraasiga; eriti kaitsmist vajavates serverites võib see asuda riistvaralisel võtmel. Kui võtmega sisselogimine on kõigile administraatoritele seadistatud ja testitud, lülitage paroolisisselogimine välja:
# /etc/ssh/sshd_config (väljavõte)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Kontrollida seadistust enne teenuse uuestilaadimist
sshd -t && systemctl reload ssh # RHEL-süsteemides: sshd
Jätke ümberseadistamisel olemasolev sessioon lahti ja testige sisselogimist teises aknas. Nii ei lukusta te vea korral end välja. Iga administraator saab oma võtme; ühiseid võtmeid kogu meeskonnale ei saa üksikute isikute lahkumisel puhtalt tühistada. Lisaalused kirjeldab leht Root-serveri ja vServeri enda turvamine.
Hädajuurdepääs ja taastekoodid
Hea kasutuselevõtt arvestab ka tõrkega. Nutitelefonid lähevad kaotsi, töötajad lahkuvad ettevõttest, turvavõtmed lähevad katki. Ilma plaanita ei ole siis valel hetkel kedagi ligipääsuga valmis.
Registreerige igale kriitilisele kontole kaks faktorit, näiteks turvavõti kontoris ja autentimisrakendus, ning hoidke taastekoode paroolist eraldi.
Muud reeglid, mis on end tõestanud:
- Isiklikud kontod ühiskasutatavate haldussisselogimiste asemel, et muudatused oleksid jälgitavad.
- Dokumenteeritud hädajuurdepääs eraldi hoitavate ligipääsuandmetega, mille kasutus silma jääb ja logitakse.
- Töötajate või teenusepakkujate lahkumisel tühistage kõik ligipääsud ja võtmed samal päeval.
- Pärast turvaintsidenti kontrollige mitte ainult paroole, vaid ka registreeritud faktoreid ja aktiivseid sessioone.
Meeskonnas kasutuselevõtul on end tõestanud selge kulg. Alustage kontodest, mis võivad tekitada suurima kahju: hosting, domeen, DNS ja administraatorite e-posti postkastid. Seejärel järgnevad serverid, sisuhaldussüsteem ja teenused. Määrake tähtpäev, millest alates ei ole sisselogimised ilma teise faktorita enam võimalikud, ja veenduge enne, et kõik osalised on seadistatud.
Selgitage meeskonnale lühidalt, miks üleminek on vajalik ja kuidas see igapäevaselt toimib. Ühelehekülgne juhend ekraanipiltidega vähendab järelepärimisi oluliselt. Välised teenusepakkujad ja agentuurid peaksid saama oma isiklikud ligipääsud teise faktoriga ühise sisselogimise asemel, et juurdepääsud jääksid seostatavaks ja projekti lõppedes puhtalt tühistatavaks.
Kuidas sisselogimislehti automatiseeritud katsete vastu lisaks kaitsta, on kirjas juhendis Halduse sisselogimised toorjõurünnaku eest kaitsta.
Kuidas PHP SOS konkreetselt aitab?
- Koostame koos teiega täieliku nimekirja kõigist halduse ligipääsudest ja näitame, kus teine faktor puudub.
- Viime serveriligipääsud üle SSH-võtmetele ja lülitame paroolisisselogimised serveri karastamise raames kontrollitult välja.
- Dokumenteerime hädajuurdepääsud ja taastetee nii, et need toimivad tõsiolukorras.
- Turvahoolduslepingu raames kontrollime ligipääse regulaarselt ja eemaldame hüljatud kontod.
Korduma kippuvad küsimused
Milline kaheastmelise autentimise meetod on kõige turvalisem?
Riistvaralised turvavõtmed ja FIDO2-standardi järgi passkey'd on andmepüügi vastu eriti vastupidavad, sest need on seotud tegeliku aadressiga. Autentimisrakendused ühekordsete koodidega on hea standard. SMS on parem kui mitte midagi, kuid kõige nõrgem variant.
Mis juhtub, kui autentimisrakendusega nutitelefon kaotsi läheb?
Selleks on taastekoodid, mis seadistamisel kuvatakse. Need tuleb turvaliselt hoida, näiteks seifis või kaitstud paroolihalduris. Lisaks peaks vähemalt üks teine administraator saama ligipääsu lähtestada.
Kas kaheastmeline autentimine kaitseb ka PHP2Shelli eest?
Ei. PHP2Shell võimaldab koodi käivitamist ilma sisselogimiseta, sisselogimist ei kasutatagi. PHP2Shelli vastu aitab ainult uuendus parandatud PHP versioonile koos kõigi töötajate taaskäivitamisega. Kaheastmeline autentimine kaitseb varastatud või äraarvatud paroolide eest.
Kas kaheastmelisest autentimisest sisuhaldussüsteemis piisab?
Ei, ründaja valib nõrgima ligipääsu. Hostingukonto, serveripaneel, SSH, domeenihaldus, DNS ja administraatorite e-posti postkastid peavad olema sama kaitstud, muidu saab sisuhaldussüsteemi kaitsest mööda minna.