Din când în când, un client ne trimite un articol de presă despre o vulnerabilitate de securitate și ne întreabă dacă site-ul lui e afectat. E unul dintre mesajele la care ne place cel mai mult să răspundem, pentru că răspunsul e aproape întotdeauna același: da, am văzut-o, iar actualizarea de securitate e deja aplicată. Apoi fiecare se întoarce la treaba lui.
Schimbul ăsta scurt de mesaje spune multe despre cum credem că ar trebui să arate întreținerea de securitate văzută dinspre client. Nu alarmantă, nu dramatică, nu o factură cu cuvântul urgent pe ea. Doar o rutină care rula deja înainte să-ți treacă prin cap să întrebi de ea.
Articolul de față explică în ce constă de fapt rutina asta. Nu ca să impresionăm pe cineva cu procedurile noastre, ci pentru că noi credem că clienții dorm mai bine când înțeleg ce se întâmplă în numele lor, și pentru că aplicarea actualizărilor de securitate e genul de serviciu care merge cel mai bine când e vizibil în explicații și invizibil în practică.
Două fluxuri, un singur obicei
Actualizările de securitate ajung pe un site din două direcții și e util să le ținem separate.
Primul flux e aplicația în sine: Drupal core și modulele contribuite de comunitate pe care le folosește un site. Echipa de securitate Drupal publică avertizări într-un ritm săptămânal previzibil, iar cei care întrețin modulele lansează remedieri odată cu ele. E unul dintre atuurile discrete ale Drupal ca platformă. Munca de securitate e coordonată, făcută la vedere și anunțată din timp, ceea ce înseamnă că o echipă atentă își poate construi o rutină calmă în jurul ei, în loc să reacționeze la surprize.
Al doilea flux stă sub aplicație: pachetele sistemului de operare, runtime-ul PHP, serverul web, tot software-ul pe care stă site-ul tău. Vulnerabilitățile apar și acolo, după propriul calendar, și contează la fel de mult, chiar dacă nu pomenesc niciodată de Drupal.
Ambele fluxuri sunt treaba noastră. Un site e la zi doar în măsura în care e la zi cel mai neglijat strat de sub el, așa că să ai grijă de un flux și să-l ignori pe celălalt ar fi ca și cum ai face curat doar în jumătate de cameră.
Partea de aplicație: actualizările ca ritm
Pentru Drupal core și module, rutina noastră e construită în jurul calendarului de avertizări. Când sunt publicate versiunile de securitate, verificăm ce se aplică fiecărui site pe care îl avem în grijă, aplicăm actualizările și trecem fiecare site prin verificările lui înainte ca schimbarea să intre live. Pentru că fiecare lansare a noastră e o versiune înregistrată, cu o cale clară de revenire, o actualizare de securitate parcurge același drum sigur ca orice altă schimbare: e aplicată, verificată și înregistrată, iar istoricul lansărilor arată exact când a intrat live.
Verificarea merită propria ei frază, pentru că aplicarea unei actualizări e jumătatea ușoară. Site-urile diferă, iar o remediere banală pe un site poate intra în conflict cu o personalizare de pe altul. Lansările noastre ne lasă timp să verificăm fiecare site cum trebuie înainte ca actualizarea să intre live, iar mediile de staging ne permit să testăm orice e neobișnuit mai întâi departe de producție. Actualizarea care ajunge la vizitatorii tăi a rulat deja undeva unde totul arată exact ca site-ul tău, pentru că practic este site-ul tău, cu un pas mai devreme.
Rostul ritmului ăsta e că nimic nu e improvizat. Nu decidem pe moment dacă o avertizare merită efortul. Fiecare avertizare aplicabilă e tratată, de fiecare dată, ca parte din fluxul obișnuit al întreținerii. Judecata noastră stă în felul în care verificăm o anumită actualizare pe un anumit site, nu în întrebarea dacă aplicăm sau nu actualizările.
Partea de platformă: reconstruită la bază, distribuită peste tot
Pentru straturile de sub aplicație, rulăm propria noastră platformă de găzduire, iar fiecare site de pe ea rulează în containere securizate, construite din imagini de bază pe care le întreținem centralizat. Când apare o vulnerabilitate în runtime sau în pachetele de sistem, nu umblăm pe servere unul câte unul. Reconstruim imaginile de bază o singură dată, cu remedierile incluse, și le distribuim, împrospătate, pe fiecare site găzduit, ca operațiune de rutină.
E partea de serviciu la care clienții se gândesc cel mai rar, și tocmai aici întreținerea centralizată își merită banii. O singură reconstrucție acoperă întreaga flotă. Fiecare site beneficiază de aceeași remediere, la același standard, inclusiv site-urile ai căror proprietari nu citesc niciodată știri de securitate. Nu există serverul uitat, rămas în urmă fără să observe nimeni, pentru că niciun server nu e actualizat separat, ca o favoare. Platforma se mișcă la unison.
Ce observi tu: nimic, și asta e intenția
Din perspectiva clientului, toate astea se reduc la o experiență simplă. Actualizările de securitate sosesc ca parte a serviciului normal. Nu există telefon de urgență, nu există linie separată pe factură pentru muncă de panică, nu există fereastră în care ești rugat să decizi dacă o remediere de securitate încape în luna asta. Costul și efortul sunt deja incluse în relația de întreținere, distribuite uniform, așa cum ar trebui să fie o asigurare.
Credem că ăsta e felul onest de a tarifa munca de securitate, pentru că urgența e în mare parte un simptom al amânării. O actualizare de securitate aplicată în săptămâna în care e publicată e o sarcină mică și calmă. Aceeași actualizare amânată multă vreme se transformă într-un proiect, pentru că actualizările se adună una peste alta și fiecare strat de întârziere înseamnă mai mult de testat. Pentru că ținem fiecare site la zi din obișnuință, fiecare actualizare rămâne mică, iar actualizările mici nu au de ce să devină urgențe.
De ce refuzăm să vindem frică
Securitatea e un subiect ușor de dramatizat, iar noi, dinadins, nu o facem. N-o să ne auzi descriind internetul ca pe o zonă de război sau fluturând un titlu înfricoșător ca să grăbim o decizie. Nu pentru că riscurile ar fi imaginare, ci pentru că frica e o bază proastă pentru o relație lungă, și pentru că versiunea adevărată a poveștii e, de fapt, liniștitoare: software-ul are vulnerabilități, cercetătorii le găsesc, cei care îl întrețin le repară, iar echipele de întreținere aplică remedierile. Ciclul ăsta se învârte de zeci de ani. Singura întrebare care contează pentru site-ul tău e dacă cineva face ultimul pas, de fiecare dată.
Când există cineva care face pasul ăsta, știrile de securitate arată altfel. O avertizare nu mai e o amenințare, ci o sarcină de lucru. Un titlu de presă nu mai e un motiv de îngrijorare, ci un motiv să te uiți în istoricul lansărilor, unde răspunsul te așteaptă de obicei deja.
Așa arată întreținerea, pur și simplu
Nimic din ce am descris nu e eroic, și tocmai asta e ideea. Aplicarea actualizărilor de securitate nu e un eveniment special într-o practică de întreținere bine pusă la punct. Este practica însăși. Aceeași atenție săptămânală, aceleași reconstrucții centralizate, aceleași distribuiri discrete, repetate indiferent dacă a apărut sau nu ceva în presă, astfel încât, în săptămânile în care chiar apare ceva, noi să nu avem nimic de schimbat în felul în care lucrăm.
Dacă ai un site și nu știi sigur cine face munca asta pentru el, merită o discuție, și nu trebuie să fie neapărat cu noi. Întreabă-l pe cel care are grijă de site-ul tău cum ajung actualizările la el, în ce ritm, și cum și-ar da seama că un strat a rămas în urmă. Răspunsuri bune există, și meriți să auzi unul. Iar dacă vrei să discutăm cum am avea noi grijă de al tău, suntem ușor de găsit, iar prima discuție nu costă nimic.