Pe scurt: Autentificarea cu doi factori pentru accesurile de admin face ca o parolă furată sau ghicită să nu mai fie suficientă. Ea trebuie să se aplice peste tot unde cineva poate modifica site-ul sau serverul dumneavoastră: CMS, hosting, panou, SSH, domeniu, DNS și căsuțele de e-mail ale adminilor. La fel de importante ca configurarea sunt codurile de urgență și o regulă clară despre cine are ce acces propriu.
De ce nu sunt suficiente parolele singure pentru admini
Parolele se pierd pe multe căi: prin e-mailuri de phishing, software malițios pe un calculator de lucru, scurgeri de date la alte servicii sau pur și simplu prin reutilizare. Atacurile automatizate încearcă neîncetat datele de acces furate împotriva paginilor de autentificare cunoscute.
Cu un al doilea factor, un atacator are nevoie în plus de ceva ce deține doar utilizatorul autorizat, de exemplu un smartphone cu aplicație de autentificare sau o cheie de securitate. Aceasta ridică sensibil obstacolul, mai ales la conturile cu drepturi extinse.
Pentru conducere este importantă o delimitare: autentificarea cu doi factori protejează accesurile, nu software-ul din spatele lor. O vulnerabilitate precum PHP2Shell, care permite executarea de cod fără autentificare, nu este închisă prin aceasta. Ambele aparțin împreună: software actual și accesuri bine protejate.
Ce metode cu doi factori se potrivesc
Metodele diferă prin securitate și comoditate. Pentru conturile de admin ar trebui să folosiți cel puțin aplicații de autentificare, iar pentru accesurile deosebit de critice chei de securitate sau passkey-uri.
| Metodă | Protecție împotriva phishingului | Potrivire pentru admini |
|---|---|---|
| Cod SMS | redusă | doar ca tranziție |
| Aplicație de autentificare (TOTP) | medie | standard bun |
| Confirmare push | medie, vulnerabilă la atacuri prin oboseală | potrivită cu potrivire de numere |
| Cheie de securitate sau passkey (FIDO2/WebAuthn) | ridicată | recomandată pentru accesuri critice |
| Cheie SSH cu passphrase | ridicată | standard pentru accesul la server |
Codurile unice dintr-o aplicație pot fi interceptate pe o pagină de phishing foarte asemănătoare cu originalul și folosite imediat mai departe. Metodele FIDO2 verifică, în schimb, adresa paginii și nu funcționează pe o pagină falsă. Acesta este motivul pentru care sunt cea mai bună alegere pentru adminii cu acces la multe sisteme.
Autentificarea cu doi factori pentru accesurile de admin: lista completă
Atacatorii își aleg accesul cel mai slab. Parcurgeți de aceea toate locurile în care cineva poate modifica site-ul, serverul sau domeniul dumneavoastră:
- CMS și backend de magazin: WordPress, Shopware, TYPO3 și altele oferă autentificare cu doi factori în nucleu sau prin extensii întreținute. Ce variantă este recomandată se află în documentația producătorului.
- Contul de client al furnizorului de hosting: Cine ajunge aici poate adesea reseta parole, descărca backupuri sau reinstala serverul.
- Panoul serverului, precum Plesk sau cPanel, dacă există.
- SSH și SFTP: cheie în loc de parolă, vezi secțiunea următoare.
- Registrar de domenii și DNS: O setare DNS modificată redirecționează vizitatorii și e-mailurile, fără ca serverul să fie afectat.
- Căsuțele de e-mail ale adminilor: Prin ele trec resetările de parolă pentru aproape toate celelalte servicii.
- Depozit de cod și deployment: Cine are voie să scrie acolo poate lansa cod malițios.
- CDN, WAF, Google Search Console și furnizori de plăți.
Stabiliți pentru fiecare intrare cine are acces, dacă al doilea factor este activ și unde se află codurile de recuperare. Această listă este totodată o parte importantă a planului dumneavoastră de urgență, deoarece după un incident tocmai aceste accesuri trebuie verificate și reînnoite într-un timp scurt.
SSH: cheie în loc de parolă
Pentru accesul la server, autentificarea cu cheie SSH este protecția puternică obișnuită. Cheia privată se află pe dispozitivul adminului și este protejată cu o passphrase; la serverele deosebit de sensibile poate fi pe o cheie hardware. Dacă autentificarea cu cheie este configurată și testată pentru toți adminii, dezactivați autentificarea cu parolă:
# /etc/ssh/sshd_config (extras)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Verificați configurarea înainte ca serviciul să fie reîncărcat
sshd -t && systemctl reload ssh # pe sisteme RHEL: sshd
La trecere, lăsați deschisă o sesiune existentă și testați autentificarea într-o a doua fereastră. Astfel nu vă blocați singur în caz de eroare. Fiecare admin primește o cheie proprie; cheile comune pentru o echipă întreagă nu pot fi retrase curat atunci când pleacă persoane individuale. Alte bazele le descrie Cum securizați singur serverele root și vServer.
Acces de urgență și coduri de recuperare
O introducere bună planifică și defectarea. Smartphone-urile se pierd, angajații părăsesc compania, cheile de securitate se strică. Fără plan, în momentul nepotrivit nu există nimeni cu acces.
Înregistrați pentru fiecare cont critic doi factori, de exemplu o cheie de securitate la birou și o aplicație de autentificare, și păstrați codurile de recuperare separat de parolă.
Alte reguli care s-au dovedit utile:
- Conturi personale în loc de autentificări de admin partajate, pentru ca modificările să fie trasabile.
- Un acces de urgență documentat, cu date de acces păstrate separat, a cărui utilizare se observă și este înregistrată.
- La plecarea angajaților sau a prestatorilor, retrageți toate accesurile și cheile în aceeași zi.
- După un incident de securitate, verificați nu doar parolele, ci și factorii înregistrați și sesiunile active.
La introducerea în echipă s-a dovedit utilă o procedură clară. Începeți cu conturile care pot provoca cea mai mare pagubă: hosting, domeniu, DNS și căsuțele de e-mail ale adminilor. Apoi urmează serverele, CMS-ul și serviciile. Stabiliți o dată-limită de la care autentificările fără al doilea factor nu mai sunt posibile și asigurați-vă în prealabil că toți cei implicați sunt configurați.
Explicați pe scurt echipei de ce este necesară trecerea și cum funcționează în activitatea zilnică. Un ghid de o pagină cu capturi de ecran reduce sensibil întrebările. Prestatorii externi și agențiile ar trebui să primească accesuri proprii, personale, cu al doilea factor, în loc de o autentificare comună, pentru ca accesările să rămână atribuibile și să poată fi retrase curat după încheierea proiectului.
Cum protejați suplimentar paginile de autentificare împotriva încercărilor automate se află în ghidul Cum protejați autentificările de admin împotriva brute force.
Cum ajută PHP SOS concret?
- Întocmim împreună cu dumneavoastră o listă completă a tuturor accesurilor de admin și arătăm unde lipsește al doilea factor.
- Trecem accesurile la server la chei SSH și dezactivăm controlat autentificările cu parolă, în cadrul securizării serverului.
- Documentăm accesurile de urgență și căile de recuperare astfel încât să funcționeze în caz real.
- În contractul de întreținere de securitate verificăm periodic accesurile și eliminăm conturile orfane.
Întrebări frecvente
Care metodă cu doi factori este cea mai sigură?
Cheile hardware de securitate și passkey-urile conforme cu standardul FIDO2 sunt considerate deosebit de rezistente la phishing, deoarece sunt legate de adresa reală. Aplicațiile de autentificare cu coduri unice sunt un standard bun. SMS-ul este mai bun decât nimic, dar este varianta cea mai slabă.
Ce se întâmplă dacă pierd smartphone-ul cu aplicația de autentificare?
Pentru aceasta există coduri de recuperare, afișate la configurare. Ele trebuie păstrate în siguranță, de exemplu într-un seif sau într-un manager de parole protejat. În plus, cel puțin un al doilea admin ar trebui să poată reseta accesul.
Protejează autentificarea cu doi factori și împotriva PHP2Shell?
Nu. PHP2Shell permite executarea de cod fără autentificare, iar autentificarea nu este deloc folosită. Împotriva PHP2Shell ajută doar actualizarea la o versiune PHP corectată, cu repornirea tuturor workerilor. Autentificarea cu doi factori protejează împotriva parolelor furate sau ghicite.
Este suficientă autentificarea cu doi factori în CMS?
Nu, un atacator alege accesul cel mai slab. Contul de hosting, panoul serverului, SSH, administrarea domeniilor, DNS și căsuțele de e-mail ale adminilor trebuie protejate la fel, altfel protecția CMS poate fi ocolită.