Un site modern e asamblat din foarte mult software pe care nu l-a scris nimeni din echipa ta. Drupal core, zeci de module contribuite, bibliotecile PHP de care depind, pachetele JavaScript din spatele frontend-ului, serverul web, baza de date, sistemul de operare din container. Fiecare e întreținut de altcineva, după propriul program, și fiecare publică din când în când o remediere pentru o problemă de securitate. Să știi ce e în site-ul tău, și să știi în câteva ore când o parte din el are nevoie de atenție, e una dintre cele mai puțin vizibile și mai importante sarcini din rularea unui site. Articolul e despre cum o facem.
Începe cu o listă completă
Nu poți urmări ce n-ai listat. Pentru fiecare site pe care îl rulăm, versiunile exacte ale tuturor componentelor sunt înregistrate în fișiere de blocare consemnate împreună cu codul: modulele Drupal și bibliotecile PHP într-unul, pachetele de frontend în altul. Imaginile de container care rulează site-ul sunt construite dintr-un manifest care fixează versiunile de PHP, server web, client de bază de date și fiecare pachet de sistem. Nimic nu se instalează manual pe un server, niciodată, pentru că un pachet instalat manual e unul de care lista nu știe.
Această disciplină e și ceea ce face o construcție reproductibilă: același commit produce același site, azi sau peste un an, ceea ce contează atât pentru livrări, cât și pentru a răspunde la întrebarea „ce anume rulam la data aceea?”.
Compară lista cu problemele cunoscute, continuu
Bazele de date publice înregistrează fiecare vulnerabilitate cunoscută din fiecare pachet larg folosit, cu versiunile afectate și versiunea care o repară. Echipa de securitate Drupal își publică propriile avize pentru core și pentru modulele contribuite. Comparăm listele noastre cu aceste surse automat, în fiecare zi, pe trei niveluri.
- Dependențele aplicației. Fișierele de blocare PHP și JavaScript sunt verificate față de bazele de date de vulnerabilități și de fluxul de avize Drupal. O potrivire produce o constatare cu pachetul, versiunea instalată, versiunea reparată și severitatea.
- Imaginile de container. Fiecare imagine pe care o construim e scanată pentru vulnerabilități cunoscute în pachetele sistemului de operare și în binarele incluse, înainte să fie folosită și din nou după un program, pentru că vulnerabilități noi în pachete vechi se dezvăluie tot timpul.
- Propriul nostru cod. Analiza statică rulează la fiecare schimbare a modulelor și componentelor noastre personalizate, căutând categoriile de greșeli pe care bazele de date de vulnerabilități nu le pot ști, pentru că codul e al nostru.
O constatare la oricare nivel devine un tichet cu o severitate și o dată țintă, vizibil în portalul de client. Constatările extrem de critice sunt tratate în aceeași zi.
Scanarea trebuie să fie de încredere
Un scaner care eșuează în tăcere e mai rău decât niciun scaner, pentru că produce încredere fără informație. Tratăm o scanare eșuată sau imposibil de citit ca pe o constatare în sine: dacă verificarea dependențelor n-a rulat sau n-a putut citi fișierul de blocare, asta se ridică la rang de incident până e reparată. Fiecare constatare e urmărită și până la închidere prin rescanare, nu prin marcarea ei ca rezolvată de către cineva. O vulnerabilitate e rezolvată când două scanări curate consecutive spun asta.
Repararea la nivelul potrivit
Cele mai multe constatări se rezolvă prin actualizarea pachetului afectat, ceea ce pentru dependențele aplicației e aceeași rutină ca orice lansare de securitate: actualizează, testează pe staging, livrează. Pentru imaginile de container, remediul e reconstruirea imaginii cu pachetul reparat și distribuirea ei, ceea ce se întâmplă pe fiecare site de pe platformă într-o singură actualizare coordonată, nu site cu site. Ocazional, o vulnerabilitate nu are încă remediu, sau remediul e într-o versiune incompatibilă. Acele cazuri primesc o decizie documentată: atenuare la alt nivel, cum ar fi o regulă de firewall, și consemnarea raționamentului și a datei la care revenim asupra ei. Nimic nu se filtrează din raport fără un motiv scris.
Lista ținută mică
Cea mai ușor de gestionat vulnerabilitate e cea dintr-un pachet pe care nu-l ai. O parte din igiena dependențelor e curățarea regulată: module instalate, dar nefolosite, biblioteci aduse pentru o funcție eliminată, pachete de frontend care dublează ceva deja prezent. Fiecare modul e evaluat înainte să fie adăugat, iar lista e revizuită la fiecare actualizare majoră. O suprafață mai mică e o sarcină mai mică, în fiecare săptămână, pentru totdeauna.
De ce e o sarcină a platformei
Niciunul dintre pașii de mai sus nu e dificil. Ce îi face eficienți e că rulează pentru fiecare site, în fiecare zi, fără să depindă de memoria cuiva. Pe platforma noastră administrată, scanarea, reconstruirea imaginilor și tichetele sunt proprietăți ale infrastructurii, așa că un site adăugat luni e acoperit marți. E unul dintre felurile în care platforma oferă un strat de apărare pe care un site individual, întreținut manual, rar îl susține.
Produce și ceva de care clienții au tot mai mult nevoie: un răspuns. Când un client întreabă dacă ai fost afectat de o vulnerabilitate care a ajuns în știri, răspunsul e o căutare, nu o investigație. Ce versiuni rulăm, dacă au fost afectate, când s-a aplicat remediul. Acesta e nivelul de certitudine pe care vrem să-l poată da fiecare client, și vine din munca plictisitoare de a ține lista și de a o verifica zilnic.
Dacă vrei să știi ce e de fapt în site-ul tău și dacă ceva are nevoie de atenție, putem rula scanarea ca parte a unei revizii. Lista e de obicei mai lungă decât se așteaptă oamenii, iar numărul de constatări de obicei mai mic.