Cloudflare a oferit primele explicații detaliate după întreruperea majoră de pe 18 noiembrie, care a scos din funcțiune numeroase site-uri și servicii la nivel global. Într-o postare pe blog, CEO-ul Matthew Prince a admis că, inițial, compania a suspectat în mod eronat un atac de tip DDoS.
Investigațiile ulterioare au arătat însă că nu a fost vorba de un atac cibernetic sau de activitate malițioasă, ci de o problemă internă, cauzată de o modificare a permisiunilor unui sistem de baze de date. Această schimbare a afectat un fișier esențial pentru modulul de Bot Management, declanșând un lanț de erori în infrastructura de bază.
Ce s-a întâmplat, tehnic, în infrastructura Cloudflare
Sistemul de Bot Management al Cloudflare folosește un model de machine learning pentru a acorda un „scor de bot” fiecărei cereri care traversează rețeaua companiei. Clienții se bazează pe aceste scoruri pentru a decide dacă permit, limitează sau blochează traficul generat de anumite roboți.
Printre utilizări:
- filtrarea bot-urilor malițioase sau a traficului automatizat agresiv;
- controlul accesului pentru roboții companiilor de AI care doresc să folosească conținutul unui site pentru antrenarea modelelor de limbaj;
- participarea la experimente precum „pay per crawl”, prin care administratorii de site-uri pot permite indexarea de către boți AI în schimbul unei plăți.
Potrivit lui Matthew Prince, modelul de ML se bazează pe un fișier de configurație pentru „features” (parametri de intrare) care este actualizat la câteva minute. O schimbare în mecanismul care generează acest fișier a modificat dimensiunea acestuia într-un mod neașteptat, ceea ce a dus la o eroare în procesare.
Consecința:
- pentru traficul care depindea de modulul de bots, sistemele proxy centrale ale Cloudflare au început să returneze coduri HTTP 5xx, blocând fluxul normal al cererilor prin rețea pentru un număr mare de clienți.
De ce a fost întreruperea atât de gravă
Cloudflare descrie incidentul drept cea mai serioasă întrerupere din ultimii ani. Compania a precizat că nu a mai avut un eveniment în care „majoritatea traficului de bază să fie oprit” din 2019.
Pentru utilizatorii finali și companiile care se bazează pe Cloudflare pentru:
- protecție DDoS;
- livrare de conținut (CDN);
- protecție web și routare,
efectul s-a tradus în:
- indisponibilitatea completă sau intermitentă a unor site-uri;
- mesaje de eroare de tip „internal server error pe rețeaua Cloudflare”;
- întreruperea unor servicii critice pentru trafic, plăți sau autentificare.
Inițiala suspiciune de atac DDoS nu este surprinzătoare, având în vedere rolul Cloudflare în protecția împotriva acestui tip de amenințări. Analiza ulterioară a arătat însă clar că problemele erau generate de un bug intern și de o modificare de permisiuni la nivel de infrastructură.
Bot Management, AI și experimentul „pay per crawl”
Un element important de context este utilizarea tot mai intensă a infrastructurii Cloudflare pentru a gestiona relația dintre site-uri și boții companiilor de inteligență artificială.
Sistemul de Bot Management permite clienților:
- să blocheze boții AI care încearcă să folosească conținutul pentru antrenarea modelelor LLM;
- sau, dimpotrivă, să participe la experimentul „pay per crawl”, prin care accesul acestor boți este permis în schimbul unei remunerații.
Fișierul de „features” care a generat eroarea este parte a fluxului prin care modelul ML decide dacă o cerere este automată sau umană și ce scor de încredere primește.
Faptul că o problemă la acest nivel a putut afecta atât de puternic infrastructura arată, pe de o parte, cât de mult s-a integrat logica de ML în „miezul” rețelei Cloudflare, iar pe de altă parte, cât de importantă devine ingineria de fiabilitate atunci când sistemele de AI devin componente critice, nu doar servicii auxiliare.
Reacția companiei: asumare și promisiuni de îmbunătățire
Matthew Prince a subliniat în mesajul său că problema a fost identificată ca fiind internă și că echipele tehnice au reușit să restaureze funcționarea rețelei după ce au înțeles eroarea legată de fișierul de configurare.
CEO-ul și-a cerut scuze în numele companiei pentru impactul asupra clienților și a recunoscut că:
- diagnosticarea inițială, care a indicat un posibil atac DDoS, a fost greșită;
- va fi nevoie de schimbări procedurale și tehnice pentru a preveni ca o modificare de acest tip să oprească din nou traficul la scară largă.
În mod tradițional, Cloudflare folosește astfel de post-mortem-uri publice pentru a detalia cauzele tehnice ale incidentelor și pentru a recâștiga încrederea clienților, mai ales când este vorba de întreruperi rare, dar extinse.
Ce înseamnă incidentul pentru viitorul infrastructurii bazate pe AI
Evenimentul din 18 noiembrie scoate în evidență o tendință majoră în infrastructura internetului:
- modelele de AI și sistemele de scoring automat nu mai sunt doar un „strat suplimentar”, ci parte integrantă din modul în care traficul este filtrat, prioritizat și securizat;
- o eroare de configurare într-un astfel de sistem poate avea efecte în cascadă, afectând nu doar un subset de funcții (de exemplu, doar detecția de boți), ci și fluxul corect al cererilor pentru un număr mare de clienți.
Pe măsură ce experimente precum „pay per crawl” și controlul accesului pentru boți de AI devin mai importante economic și tehnic, presiunea pe fiabilitatea acestor componente va crește.
Pentru clienți, mesajul implicit este dublu:
- integrarea AI în securitate și gestionarea traficului aduce beneficii, dar și noi riscuri de complexitate;
- transparența asupra cauzelor incidentelor și a măsurilor corective rămâne esențială pentru încrederea în furnizori de infrastructură precum Cloudflare.
