Īsi: Divu faktoru autentifikācija administratoru piekļuvēm nodrošina, ka nozagta vai uzminēta parole vien nepietiek. Tai jādarbojas visur, kur kāds var mainīt jūsu vietni vai serveri: CMS, hostings, panelis, SSH, domēns, DNS un administratoru pastkastes. Tikpat svarīgi kā iestatīšana ir ārkārtas kodi un skaidrs noteikums, kuram kam ir sava piekļuve.
Kāpēc administratoriem ar parolēm vien nepietiek
Paroles tiek zaudētas daudzos veidos: pikšķerēšanas e-pastos, ļaunprogrammatūrā uz darba datora, datu noplūdēs citos pakalpojumos vai vienkārši atkārtotas lietošanas dēļ. Automatizēti uzbrukumi nozagtos piekļuves datus nepārtraukti izmēģina pret zināmām pieteikšanās lapām.
Ar otro faktoru uzbrucējam papildus vajadzīgs kaut kas, kas pieder tikai tiesīgajam lietotājam, piemēram, viedtālrunis ar autentifikatora lietotni vai drošības atslēga. Tas būtiski paaugstina barjeru, īpaši kontiem ar plašām tiesībām.
Vadībai svarīgs ir norobežojums: divu faktoru autentifikācija aizsargā piekļuves, nevis aiz tām esošo programmatūru. Ievainojamība, piemēram, PHP2Shell, kas ļauj izpildīt kodu bez pieteikšanās, tādējādi netiek aizvērta. Abi pieder kopā: aktuāla programmatūra un labi aizsargātas piekļuves.
Kuras divu faktoru metodes der
Metodes atšķiras drošībā un ērtībā. Administratoru kontiem jāizmanto vismaz autentifikatora lietotnes, īpaši kritiskām piekļuvēm drošības atslēgas vai passkeys.
| Metode | Aizsardzība pret pikšķerēšanu | Piemērotība administratoriem |
|---|---|---|
| SMS kods | zema | tikai kā pārejas risinājums |
| Autentifikatora lietotne (TOTP) | vidēja | labs standarts |
| Push apstiprinājums | vidēja, uzņēmīga pret nogurdināšanas uzbrukumiem | piemērota ar numura salīdzināšanu |
| Drošības atslēga vai passkey (FIDO2/WebAuthn) | augsta | ieteicama kritiskām piekļuvēm |
| SSH atslēga ar paroles frāzi | augsta | standarts servera piekļuvēm |
Vienreizējus kodus no lietotnes uz šķietami īstas pikšķerēšanas lapas var pārtvert un nekavējoties izmantot tālāk. FIDO2 metodes turpretī pārbauda lapas adresi un uz viltotas lapas nedarbojas. Tāpēc tās administratoriem ar piekļuvi daudzām sistēmām ir labākā izvēle.
Divu faktoru autentifikācija administratoru piekļuvēm: pilns saraksts
Uzbrucēji izvēlas vājāko piekļuvi. Tāpēc izejiet cauri visām vietām, kur kāds var mainīt jūsu vietni, serveri vai domēnu:
- CMS un veikala administrēšanas sadaļa: WordPress, Shopware, TYPO3 un citi piedāvā divu faktoru autentifikāciju kodolā vai ar uzturētiem paplašinājumiem. Kuru variantu iesaka, rakstīts ražotāja dokumentācijā.
- Hostinga klienta konts: Kas šeit tiek iekšā, bieži var atiestatīt paroles, lejupielādēt dublējumus vai serveri uzstādīt no jauna.
- Servera panelis, piemēram, Plesk vai cPanel, ja ir.
- SSH un SFTP: atslēgas nevis paroles, skatiet nākamo sadaļu.
- Domēnu reģistrators un DNS: Mainīts DNS iestatījums novirza jūsu apmeklētājus un pastu, neskarot serveri.
- Administratoru e-pasta pastkastes: Caur tām notiek paroļu atiestatīšana gandrīz visiem citiem pakalpojumiem.
- Koda repozitorijs un izvietošana: Kas tur drīkst rakstīt, var izvērst ļaunprātīgu kodu.
- CDN, WAF, Google Search Console un maksājumu pakalpojumu sniedzēji.
Katram ierakstam fiksējiet, kam ir piekļuve, vai otrais faktors ir aktīvs un kur atrodas atjaunošanas kodi. Šis saraksts vienlaikus ir svarīga jūsu ārkārtas rīcības plāna daļa, jo pēc incidenta tieši šīs piekļuves īsā laikā jāpārbauda un jāatjauno.
SSH: atslēgas nevis parole
Servera piekļuvēm pieteikšanās ar SSH atslēgu ir ierastā spēcīgā aizsardzība. Privātā atslēga atrodas administratora ierīcē un ir aizsargāta ar paroles frāzi; īpaši aizsargājamos serveros tā var atrasties aparatūras atslēgā. Ja atslēgu pieteikšanās ir iestatīta un pārbaudīta visiem administratoriem, paroļu pieteikšanos izslēdziet:
# /etc/ssh/sshd_config (fragments)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Pārbaudīt konfigurāciju, pirms pakalpojums tiek pārlādēts
sshd -t && systemctl reload ssh # RHEL sistēmās: sshd
Pārslēdzot atstājiet esošu sesiju atvērtu un pieteikšanos pārbaudiet otrā logā. Tā kļūdas gadījumā neizslēgsit sevi pašu. Katrs administrators saņem savu atslēgu; kopīgas atslēgas visai komandai atsevišķu personu aiziešanas gadījumā nevar tīri atsaukt. Papildu pamatus apraksta Root serveru un vServer pašu nostiprināšana.
Ārkārtas piekļuve un atjaunošanas kodi
Laba ieviešana plāno arī atteikumu. Viedtālruņi tiek pazaudēti, darbinieki atstāj uzņēmumu, drošības atslēgas saplīst. Bez plāna nepareizā brīdī neviens ar piekļuvi nav pieejams.
Reģistrējiet katram kritiskam kontam divus faktorus, piemēram, drošības atslēgu birojā un autentifikatora lietotni, un atjaunošanas kodus glabājiet atsevišķi no paroles.
Citi noteikumi, kas sevi pierādījuši:
- Personīgie konti, nevis koplietojami administratora pieteikšanās dati, lai izmaiņas būtu izsekojamas.
- Dokumentēta ārkārtas piekļuve ar atsevišķi glabātiem piekļuves datiem, kuras lietošana krīt acīs un tiek protokolēta.
- Darbiniekiem vai pakalpojumu sniedzējiem aizejot, visas piekļuves un atslēgas atņemt tajā pašā dienā.
- Pēc drošības incidenta pārbaudīt ne tikai paroles, bet arī reģistrētos faktorus un aktīvās sesijas.
Ieviešanā komandā ir noderējusi skaidra norise. Sāciet ar kontiem, kas var nodarīt vislielāko kaitējumu: hostings, domēns, DNS un administratoru e-pasta pastkastes. Pēc tam seko serveri, CMS un pakalpojumi. Nosakiet datumu, no kura pieteikšanās bez otrā faktora vairs nav iespējama, un iepriekš pārliecinieties, ka visi iesaistītie ir iestatīti.
Īsi paskaidrojiet komandai, kāpēc pāreja nepieciešama un kā tā darbojas ikdienā. Vienas lapas instrukcija ar ekrānuzņēmumiem būtiski samazina jautājumus. Ārējiem pakalpojumu sniedzējiem un aģentūrām jāsaņem savas personīgas piekļuves ar otro faktoru, nevis kopīga pieteikšanās, lai piekļuves paliktu piesaistāmas un pēc projekta beigām tās varētu tīri atsaukt.
Kā pieteikšanās lapas papildus aizsargāt pret automatizētiem mēģinājumiem, rakstīts ceļvedī Administratoru pieteikšanās aizsardzība pret Brute Force.
Kā PHP SOS palīdz konkrēti?
- Kopā ar jums izveidojam pilnu visu administratoru piekļuvju sarakstu un parādām, kur trūkst otrā faktora.
- Servera piekļuves pārslēdzam uz SSH atslēgām un paroļu pieteikšanos kontrolēti izslēdzam servera nostiprināšanas ietvaros.
- Ārkārtas piekļuves un atjaunošanas ceļus dokumentējam tā, lai tie darbotos kritiskā brīdī.
- Security uzturēšanas līgumā regulāri pārbaudām piekļuves un noņemam pamestus kontus.
Biežāk uzdotie jautājumi
Kura divu faktoru metode ir drošākā?
Aparatūras drošības atslēgas un passkeys pēc FIDO2 standarta tiek uzskatītas par īpaši noturīgām pret pikšķerēšanu, jo ir piesaistītas īstajai adresei. Autentifikatora lietotnes ar vienreizējiem kodiem ir labs standarts. SMS ir labāk nekā nekas, bet vājākais variants.
Kas notiek, ja tiek pazaudēts viedtālrunis ar autentifikatora lietotni?
Tam paredzēti atjaunošanas kodi, kas tiek parādīti iestatīšanas laikā. Tie jāglabā droši, piemēram, seifā vai aizsargātā paroļu pārvaldniekā. Papildus vismaz vienam otram administratoram jāspēj piekļuvi atiestatīt.
Vai divu faktoru autentifikācija aizsargā arī pret PHP2Shell?
Nē. PHP2Shell ļauj izpildīt kodu bez pieteikšanās, pieteikšanās pie tā netiek izmantota. Pret PHP2Shell palīdz tikai atjauninājums uz izlabotu PHP versiju ar visu darbprocesu pārstartēšanu. Divu faktoru autentifikācija pasargā no nozagtām vai uzminētām parolēm.
Vai pietiek ar divu faktoru autentifikāciju CMS?
Nē, uzbrucējs izvēlas vājāko piekļuvi. Hostinga konts, servera panelis, SSH, domēnu pārvaldība, DNS un administratoru e-pasta pastkastes jāaizsargā tāpat, citādi CMS aizsardzību var apiet.