O dată la câteva luni, o firmă vine la noi cu un site pe care l-a construit altcineva, adesea cu ani în urmă, și cu o întrebare simplă: e în stare bună? Uneori întrebarea e stârnită de o știre. Uneori de o persoană nouă care preia bugetul de marketing. Uneori de echipa de achiziții a unui client care cere o declarație de securitate pe care nimeni nu știe cum s-o scrie. Oricare ar fi declanșatorul, răspunsul trebuie să vină din verificare, nu din încurajări, iar noi am transformat, de-a lungul anilor, această verificare într-o rutină.
Iată ce acoperă revizia, aproximativ în ordinea în care o facem. Nu pentru că ne așteptăm să găsim probleme, ci pentru că cel mai rapid mod de a ști că un site e solid e să verifici aceleași lucruri de fiecare dată, în aceeași ordine, și să notezi ce vezi.
Mai întâi, inventarul
Nu poți proteja ce nu poți enumera. Prima zi se duce pe construirea unei imagini exacte a ceea ce există: versiunea de Drupal core, fiecare modul și temă cu versiunea sa, versiunile de PHP și de bază de date, serverul web, unde e găzduit site-ul, care domenii și certificate indică spre el și cu ce servicii externe comunică. Enumerăm și oamenii: cine are cont, ce roluri deține și când s-a autentificat ultima dată.
Inventarul singur răspunde la un număr surprinzător de întrebări. Un site care rulează o versiune de core rămasă cu câteva lansări în urmă are un pas următor clar. Un modul pe care menținătorul nu l-a mai actualizat de ani sau care nu are acoperire de securitate merită atenție, indiferent dacă e exploatabil acum sau nu. Doisprezece conturi de administrator pentru o echipă de patru e o discuție de purtat. Niciuna dintre aceste constatări nu e dramatică; toate se pot rezolva.
Comparația cu avizele publicate
Drupal are o echipă de securitate dedicată care publică avize pentru core și pentru fiecare modul contribuit acoperit, după un program săptămânal fix. Asta ne dă ceva rar în software: o listă autoritară a ceea ce s-a reparat, când și în ce versiune. Comparăm inventarul cu ea. Fiecare diferență între versiunea instalată și ultima lansare de securitate devine un rând în raport, cu gradul de severitate dat chiar de aviz alături.
Aceeași comparație rulează și pe stratul de sub Drupal. PHP, baza de date și sistemul de operare au propriile avize, iar un site e la zi doar cât e la zi stratul lui cel mai lent. Pe infrastructura pe care o administrăm, această comparație rulează automat în fiecare zi, așa că revizia unui site aflat deja pe platforma noastră pornește de la o bază curată, iar pasul de inventar e mai degrabă o confirmare.
Cum e servit site-ul
Următorul set de verificări privește drumul dintre vizitator și aplicație. E fiecare pagină servită prin HTTPS, cu certificate care se reînnoiesc singure? Sunt la locul lor anteturile standard de securitate, ca browserele să aplice protecțiile pe care pot să le aplice? Sunt căile administrative, scripturile de instalare și fișierele de versiune accesibile de pe internetul public? Există un firewall în fața aplicației care filtrează cele mai frecvente tipare de atac înainte să ajungă la PHP?
Acestea sunt verificările la care majoritatea reviziilor găsesc ceva, de obicei pentru că n-au fost niciodată treaba cuiva. Sunt și cele mai ieftine de rezolvat. Un edge bine configurat, ca firewall-ul de aplicații web din fața fiecărui site pe care îl găzduim, scoate definitiv de pe masă cea mai mare parte a acestei categorii.
Conturi, permisiuni și pagina de login
Apoi ne uităm la cine poate face ce. Ce roluri există, ce are voie fiecare și dacă oamenii care le dețin chiar au nevoie de ele. Dacă conturile de administrator aparțin unor persoane cu nume sau unor loginuri partajate. Dacă autentificarea în doi pași e activă pentru oricine poate schimba conținut sau configurație. Dacă pagina de login limitează încercările repetate. Dacă foștii angajați și foștii colaboratori mai au acces.
Permisiunile alunecă în timp în orice organizație, iar descâlcirea lor ține mai mult de conversație decât de tehnologie. Propunem o structură de roluri care se potrivește cu felul în care lucrează echipa de fapt și aplicăm obiceiurile de cont pe care le recomandăm peste tot, începând cu conturile care au cea mai mare putere.
Backup-uri, și dovada că se restaurează
Un backup care n-a fost niciodată restaurat e o speranță, nu un plan. Verificăm ce se salvează, cât de des, unde stau copiile, cât timp sunt păstrate și dacă cineva a restaurat vreodată una. Unde putem, facem o restaurare de test într-un mediu izolat și o cronometrăm. Acel număr, timpul în care site-ul revine dintr-o copie, e unul dintre cele mai utile lucruri pe care o firmă le poate ști despre site-ul ei, și cele mai multe nu l-au măsurat niciodată. Facem aceste exerciții după un program pentru site-urile pe care le găzduim, iar o revizie e un moment bun ca să începi.
Cod personalizat și configurație
La final, citim. Modulele și temele personalizate sunt locul în care un site e unic, și locul în care avizele generale nu pot ajuta. Căutăm categoriile obișnuite: date introduse de utilizator care ajung într-o interogare de bază de date sau într-o pagină fără să fie tratate corespunzător, fișiere scrise acolo unde pot fi executate, secrete stocate în repository și cod care ocolește propriile verificări de acces ale Drupal. Revizuim și configurația pentru setările care contează cel mai mult: formatele de text, regulile de încărcare a fișierelor, afișarea erorilor și permisiunile acordate utilizatorilor anonimi și autentificați.
Această parte e cea mai lungă și cea mai valoroasă, pentru că aici trăiește istoria proprie a site-ului. Constatările de aici sunt aproape întotdeauna rezultatul unor decizii rezonabile luate sub presiunea timpului cu ani în urmă, și așa le și descriem în raport.
Ce primești
Rezultatul e un document scurt, ordonat după impact, cu o estimare lângă fiecare punct și o recomandare clară pentru primele treizeci de zile. Unele puncte țin o după-amiază. Altele au locul lor într-un plan. Cele mai multe site-uri pe care le revizuim au nevoie de mai puțină muncă decât se tem proprietarii lor, iar munca în sine e liniștită: actualizări, configurare, un firewall, autentificare în doi pași, o restaurare testată. Valoarea reviziei nu e lista; e faptul că știi unde te afli și poți spune asta, în scris, oricui întreabă.
Dacă site-ul tău rulează de o vreme și nimeni nu s-a uitat la el în felul ăsta, o facem cu plăcere. O revizie durează câteva zile și e primul pas firesc, indiferent dacă ajungi să lucrezi cu noi sau nu.