Trumpai: Dviejų veiksnių autentifikacija administratorių prieigoms užtikrina, kad pavogto ar atspėto slaptažodžio vieno nepakaktų. Ji turi galioti visur, kur kas nors gali keisti jūsų svetainę ar serverį: CMS, hostinge, skydelyje, SSH, domene, DNS ir administratorių pašto dėžutėse. Taip pat svarbūs kaip ir nustatymas yra avariniai kodai ir aiški taisyklė, kas kam turi savo prieigą.
Kodėl administratoriams vien slaptažodžių nepakanka
Slaptažodžiai prarandami įvairiais keliais: per sukčiavimo (phishing) laiškus, kenkėjišką programinę įrangą darbo kompiuteryje, kitų paslaugų duomenų nutekėjimus ar tiesiog pakartotinį naudojimą. Automatizuotos atakos nenustygstamai išbando pavogtus prisijungimo duomenis prieš žinomus prisijungimo puslapius.
Su antru veiksniu užpuolikui papildomai reikia kažko, ką turi tik teisėtas naudotojas, pavyzdžiui, išmaniojo telefono su autentifikavimo programėle ar saugumo rakto. Tai gerokai pakelia kartelę, ypač paskyroms su plačiomis teisėmis.
Vadovybei svarbi viena atskirtis: dviejų veiksnių autentifikacija saugo prieigas, o ne už jų esančią programinę įrangą. Pažeidžiamumas, kaip PHP2Shell, leidžiantis vykdyti kodą be prisijungimo, tuo neuždaromas. Abu dalykai priklauso kartu: atnaujinta programinė įranga ir gerai apsaugotos prieigos.
Kurie dviejų veiksnių metodai tinka
Metodai skiriasi saugumu ir patogumu. Administratorių paskyroms turėtumėte naudoti bent autentifikavimo programėles, ypač kritinėms prieigoms saugumo raktus ar passkey.
| Metodas | Apsauga nuo sukčiavimo | Tinkamumas administratoriams |
|---|---|---|
| SMS kodas | maža | tik kaip pereinamasis |
| Autentifikavimo programėlė (TOTP) | vidutinė | geras standartas |
| Push patvirtinimas | vidutinė, jautrus nuovargio atakoms | tinka su skaičiaus suderinimu |
| Saugumo raktas arba passkey (FIDO2/WebAuthn) | didelė | rekomenduojama kritinėms prieigoms |
| SSH raktas su slaptafraze | didelė | serverio prieigų standartas |
Vienkartinius kodus iš programėlės galima perimti apgaulingai tikroje sukčiavimo svetainėje ir iškart panaudoti. FIDO2 metodai, priešingai, tikrina svetainės adresą ir suklastotoje svetainėje neveikia. Tai priežastis, kodėl jie yra geriausias pasirinkimas administratoriams su prieiga prie daugelio sistemų.
Dviejų veiksnių autentifikacija administratorių prieigoms: pilnas sąrašas
Užpuolikai renkasi silpniausią prieigą. Todėl peržiūrėkite visas vietas, kur kas nors gali keisti jūsų svetainę, serverį ar domeną:
- CMS ir parduotuvės administravimo sritis: WordPress, Shopware, TYPO3 ir kiti siūlo dviejų veiksnių autentifikaciją branduolyje arba per prižiūrimus plėtinius. Kuris variantas rekomenduojamas, nurodyta gamintojo dokumentacijoje.
- Hostingo kliento paskyra: kas čia patenka, dažnai gali atstatyti slaptažodžius, atsisiųsti atsargines kopijas ar iš naujo įdiegti serverį.
- Serverio skydelis, pavyzdžiui, Plesk ar cPanel, jei yra.
- SSH ir SFTP: raktai vietoj slaptažodžio, žr. kitą skyrių.
- Domenų registratorius ir DNS: pakeistas DNS nustatymas nukreipia jūsų lankytojus ir laiškus, serveriui nesant paveiktam.
- Administratorių pašto dėžutės: per jas vyksta beveik visų kitų paslaugų slaptažodžių atstatymas.
- Kodo saugykla ir diegimas: kas ten gali rašyti, gali išleisti kenkėjišką kodą.
- CDN, WAF, Google Search Console ir mokėjimų teikėjas.
Kiekvienam įrašui užfiksuokite, kas turi prieigą, ar antras veiksnys aktyvus ir kur laikomi atkūrimo kodai. Šis sąrašas kartu yra svarbi jūsų avarinio plano dalis, nes po incidento būtent šias prieigas reikės per trumpą laiką patikrinti ir atnaujinti.
SSH: raktai vietoj slaptažodžio
Serverio prieigoms įprasta stipri apsauga yra prisijungimas su SSH raktu. Privatus raktas yra administratoriaus įrenginyje ir apsaugotas slaptafraze; ypač saugotinuose serveriuose jis gali būti aparatiniame rakte. Kai prisijungimas raktu visiems administratoriams įrengtas ir išbandytas, išjunkite prisijungimą slaptažodžiu:
# /etc/ssh/sshd_config (ištrauka)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Patikrinti konfigūraciją prieš perkraunant tarnybą
sshd -t && systemctl reload ssh # RHEL sistemose: sshd
Perjungdami palikite esamą sesiją atvirą ir išbandykite prisijungimą antrame lange. Taip klaidos atveju neužblokuosite savęs. Kiekvienas administratorius gauna savo raktą; bendri raktai visai komandai, kai kas nors išeina, tvarkingai nebeatimami. Kitus pagrindus aprašo Root serverio ir vServer apsauga savo jėgomis.
Avarinė prieiga ir atkūrimo kodai
Gerame įvedime numatomas ir sutrikimas. Išmanieji telefonai pametami, darbuotojai palieka įmonę, saugumo raktai sugenda. Be plano tuomet netinkamu momentu niekas neturi prieigos.
Kiekvienai kritinei paskyrai užregistruokite du veiksnius, pavyzdžiui, saugumo raktą biure ir autentifikavimo programėlę, o atkūrimo kodus laikykite atskirai nuo slaptažodžio.
Kitos pasiteisinusios taisyklės:
- Asmeninės paskyros vietoj bendrai naudojamų administratoriaus prisijungimų, kad pakeitimai būtų atsekami.
- Dokumentuota avarinė prieiga su atskirai saugomais prisijungimo duomenimis, kurios naudojimas krenta į akis ir registruojamas.
- Darbuotojams ar paslaugų teikėjams išeinant visas prieigas ir raktus atimti tą pačią dieną.
- Po saugumo incidento tikrinti ne tik slaptažodžius, bet ir užregistruotus veiksnius bei aktyvias sesijas.
Įvedant komandoje pasiteisino aiški eiga. Pradėkite nuo paskyrų, galinčių padaryti didžiausią žalą: hostingo, domeno, DNS ir administratorių pašto dėžučių. Po to eina serveris, CMS ir paslaugos. Nustatykite dieną, nuo kurios prisijungimas be antro veiksnio nebebus įmanomas, ir prieš tai užtikrinkite, kad visi dalyviai yra nustatyti.
Trumpai paaiškinkite komandai, kodėl perėjimas būtinas ir kaip jis veikia kasdienybėje. Vieno puslapio instrukcija su ekrano nuotraukomis gerokai sumažina klausimų. Išoriniai paslaugų teikėjai ir agentūros turėtų gauti savo asmenines prieigas su antru veiksniu, o ne bendrą prisijungimą, kad prieigos išliktų priskiriamos ir pasibaigus projektui jas būtų galima tvarkingai atimti.
Kaip prisijungimo puslapius papildomai apsaugoti nuo automatizuotų bandymų, aprašo vadovas Administratoriaus prisijungimų apsauga nuo brute force.
Kaip PHP SOS padeda konkrečiai?
- Kartu su jumis sudarome pilną visų administratorių prieigų sąrašą ir parodome, kur trūksta antro veiksnio.
- Serverio prieigas perkeliame į SSH raktus ir prisijungimus slaptažodžiu kontroliuojamai išjungiame pagal serverio sutvirtinimą.
- Avarines prieigas ir atkūrimo kelius dokumentuojame taip, kad jie veiktų kritiniu atveju.
- Per saugumo priežiūros sutartį reguliariai tikriname prieigas ir pašaliname paliktas paskyras.
Dažni klausimai
Kuris dviejų veiksnių metodas saugiausias?
Aparatinės saugumo raktai ir FIDO2 standarto passkey laikomi ypač atspariais sukčiavimui (phishing), nes susieti su tikruoju adresu. Autentifikavimo programėlės su vienkartiniais kodais yra geras standartas. SMS geriau nei nieko, bet silpniausias variantas.
Kas nutinka, jei pamestas išmanusis telefonas su autentifikavimo programėle?
Tam yra atkūrimo kodai, rodomi nustatant. Juos reikia saugiai laikyti, pavyzdžiui, seife ar apsaugotoje slaptažodžių tvarkyklėje. Be to, bent vienas antras administratorius turėtų galėti atstatyti prieigą.
Ar dviejų veiksnių autentifikacija saugo ir nuo PHP2Shell?
Ne. PHP2Shell leidžia vykdyti kodą be prisijungimo, prisijungimas čia net nenaudojamas. Nuo PHP2Shell padeda tik atnaujinimas iki ištaisytos PHP versijos su visų darbinių procesų paleidimu iš naujo. Dviejų veiksnių autentifikacija saugo nuo pavogtų ar atspėtų slaptažodžių.
Ar pakanka dviejų veiksnių autentifikacijos CMS?
Ne, užpuolikas renkasi silpniausią prieigą. Hostingo paskyra, serverio skydelis, SSH, domenų valdymas, DNS ir administratorių pašto dėžutės taip pat turi būti apsaugoti, kitaip CMS apsaugą galima apeiti.