Incidentul Heartbleed, o scăpare de natură criptografică apărută în biblioteca OpenSSL ce permite atacatorilor să fure informaţii sensibile de pe servere şi dispozitive aflate la distanţă, a afectat aproape două treimi din serverele din întreaga lume. După apariţia informaţiilor legate de acest incident, furnizorii de hardware, software şi ISP-iştii au început repede să aplice “petice” şi să-şi sfătuiască clienţii să-şi schimbe parolele de acces.
Care sunt însă lecţiile pe care centrele de date le-au putut învăţa din acest incident? Heartbleed a fost introdus în codul OpenSSL în decembrie 2011, însă incidentul a fost făcut public la începutul lui aprilie 2014, după ce cercetătorii de la Google şi de la firma de securitate finlandeză Codenomicon au descoperit că o eroare de cod le permite hacker-ilor să acceseze date necriptate în mod repetat din memoria sistemelor care rulează versiuni vulnerabile de OpenSSL.
Vestea proastă în cazul acestui incident a fost aceea că nu există date stocate în servere care să poată fi folosite pentru determinarea compromiterii sistemelor. Iar asta a însemnat că răspunsurile la ameninţare trebuie să fie rapide, holistice şi strategice.
Una din cele mai importante lecţii pe care profesioniştii care operează centre de date o pot învăţa este aceea că este nevoie de automatizarea aplicaţiilor din aceste centre de date. Automatizarea aplicaţiilor oferă un răspuns mai bun în cazul fisurilor de securitate din servere. Iar acest fapt este important deoarece un centru de date reprezintă gazda a mii de servere, iar actualizarea acestor servere prin intermediul instrumentelor de automatizare se va desfăşura mai rapid şi mai uşor.
Un incident fără precedent precum Heartbleed necesită o acţiune de tip holistic. Tocmai de aceea, companiile care au prevăzut instrumente de management centralizat în centrele lor de date, au putut răspunde cu celeritate la criza declanşată.
Chiar dacă din punct de vedere tehnic lecţiile oferite au fost puţine, incidentul Heartbleed a oferit lecţii legate de modul în care deţinătorii de centre de date ar trebui să reacţioneze la apariţia unor astfel de incidente. O astfel de lecţie a fost aceea că soluţiile de tip open source nu sunt neapărat lipsite de riscuri.
Mai importantă este o altă lecţie, cea legată de existenţa unei strategii de recuperare în caz de dezastre pentru centrele de date. Experţii avertizează de multă vreme asupra necesităţii existenţei unei astfel de strategii, însă ceea ce s-a constatat în urma studiilor de piaţă efectuate a fost, mai degrabă, lipsa unei astfel de strategii.
Un centru de date profesionist bine gestionat ar trebui să dispună de servicii de consultanţă disponibile pentru ajutarea clienţilor să-şi testeze sistemele în avans. În plus, ar trebui să implementeze training-uri pentru personalul de operare astfel încât acesta să fie conştientizat în legătură cu ameninţările legate de securitate.
Un exemplu în acest sens este dat de “testul de penetrare”, cunoscut şi sub numele de “hacking etic”, în cadrul căruia un expert încearcă să treacă de barierele de securitate impuse de compania ţintă şi să obţină acces la informaţii confidenţiale. Expertul raportează apoi companiei despre succesul tentativei, oferind recomandări de îmbunătăţiri.
Chestiunile cele mai importante pentru operatorii de centre de date sunt legate de gestionarea dispozitivelor clientului şi de modalitatea de tratatre a vulnerabilităţii OpenSSL. Un nou incident Heartbleed poate apărea oricând, iar în acest caz cel mai probabil că operatorii de tip Google şi Amazon vor gestiona problema cu eficienţă sporită.
Problema răspunsului eficient cade în parohia furnizorilor de centre de date de dimensiuni mijlocii şi mici, deoarece aceştia vor răspunde cu întârzieri. De aceea, sfatul dat de experţi directorilor IT din firme sună cam aşa: “Citiţi acordurile SLA şi vedeţi ce scrie acolo despre chestiunile legate de securitate, apoi verificaţi cu furnizorii de servicii de centre de date dacă au avut de furcă cu astfel de incidente şi modul de gestionare a lor.”
de Bogdan Marchidanu
