Pe scurt: ISO 27001 și TISAX privesc serverele web în special prin trei cerințe: vulnerabilitățile trebuie recunoscute și tratate, furnizorii de servicii precum furnizorii de hosting și agențiile trebuie conduși, iar incidentele de securitate necesită o procedură reglementată. O situație precum PHP2Shell este pentru orice SMSI un test practic. Cine documentează clar evaluarea, patchul și repornirea are o bază bună pentru următorul audit. Un certificat sau o etichetă nu înlocuiește patchul.
Ce sunt ISO 27001 și TISAX, în două paragrafe
ISO/IEC 27001 descrie cerințele pentru un sistem de management al securității informațiilor, pe scurt SMSI. Este vorba despre un ciclu ordonat: evaluarea riscurilor, stabilirea măsurilor, implementarea, verificarea și îmbunătățirea. Ediția actuală din 2022 conține în Anexa A un catalog de 93 de măsuri în patru teme. Care dintre ele se aplică decide compania pe baza evaluării proprii a riscurilor și consemnează în declarația de aplicabilitate.
TISAX este mecanismul de verificare și schimb răspândit în industria auto. El este condus de ENX Association, baza fiind catalogul de cerințe ISA, întreținut de ENX și publicat de VDA (asociația germană a industriei auto). Furnizori independenți de servicii de audit realizează o evaluare, al cărei domeniu depinde de necesarul de protecție și variază de la verificări de documente până la vizite la fața locului. Rezultatele sunt atribuite, potrivit ENX, sub formă de etichete, sunt valabile trei ani și sunt partajate prin portalul ENX doar cu parteneri selectați.
ISO 27001 la serverul web: ce cerințe se aplică?
Un server web este rareori un capitol aparte în SMSI. El apare în mai multe locuri, iar exact acolo apar lacunele. Prezentarea următoare ordonează principalele teme în mod general. Ea nu înlocuiește o privire în propria declarație de aplicabilitate.
| Temă în SMSI | Ce înseamnă pentru serverul web | Dovada care ajută la audit |
|---|---|---|
| Inventarul activelor | Fiecare site, fiecare server, fiecare versiune PHP este înregistrată | Listă actuală cu operator, versiune, responsabil |
| Gestionarea vulnerabilităților tehnice | Avertizări precum PHP2Shell sunt evaluate și tratate | Tichet cu evaluare, decizie, data patchului |
| Relațiile cu furnizorii | Furnizorul de hosting și agenția au obligații clare de securitate | Contract, repartizarea sarcinilor, confirmare scrisă a stării patchurilor |
| Înregistrare și monitorizare | Jurnalele serverului web sunt păstrate și evaluate | Regulă de păstrare, exemplu de evaluare |
| Managementul incidentelor | Bănuiala este raportată, evaluată și închisă | Proces-verbal de incident, lessons learned |
| Managementul configurației | Setările PHP și ale serverului web sunt stabilite | Configurație țintă și verificarea abaterilor |
La TISAX se aplică teme comparabile, deoarece catalogul ISA este coordonat cu alte standarde importante. În plus, unele obiective de verificare, de exemplu protecția prototipurilor, cer o grijă deosebită la sistemele prin care partenerii schimbă date. Acestea pot fi și portaluri bazate pe PHP.
PHP2Shell ca test practic pentru SMSI
La 21.10.2026, proiectul PHP a publicat versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Pentru PHP 8.1 și mai vechi nu mai există actualizări oficiale. Un SMSI funcțional ar trebui să declanșeze în această situație un lanț care poate fi dovedit ulterior.
- Primire: Cine a primit avertizarea și când, și unde este înregistrată?
- Evaluare: Ce sisteme sunt afectate? Aceasta presupune un inventar actual, vezi Să știți ce rulează.
- Decizie: Patch, măsură provizorie sau oprire temporară, cu motivare și numele persoanei care decide.
- Implementare: Starea pachetului, repornirea tuturor proceselor PHP, verificare. La backporturile distribuției contează changelog-ul pachetului, nu numărul de versiune afișat; cum se dovedește arată Verificarea corectă a versiunii PHP și a nivelului de patch.
- Furnizori: Confirmarea scrisă a furnizorului de hosting că s-a aplicat patchul și s-a repornit.
- Verificare ulterioară: Controlul semnelor unei compromiteri începând cu 17.10.2026, deoarece un patch nu anulează intruziunile anterioare.
Cum transformați acest lanț unic într-o procedură permanentă descriu Managementul vulnerabilităților în întreprinderile mijlocii și Patch management ca proces.
Puncte slabe frecvente în documentație
În practică, dovada eșuează rareori din cauza tehnicii, ci din cauza lacunelor din lanț. Tipic este un site pe care un departament îl operează cu o agenție și care lipsește din inventar. La fel de frecvente sunt contractele cu furnizorul de hosting fără nicio mențiune despre cât de repede se instalează actualizările de securitate și dacă clienții sunt informați.
Un alt clasic: tichetul de patch este închis, dar nimeni nu a repornit procesele PHP. Formal, punctul este rezolvat, tehnic rulează în continuare codul vechi. O dovadă bună conține de aceea nu doar „actualizare instalată”, ci și repornirea și o verificare ulterioară.
Devine dificil și la sistemele care nu pot fi actualizate imediat, de exemplu o aplicație pe PHP 8.1. Aici un SMSI nu cere minuni, dar cere o decizie conștientă: ce măsuri provizorii se aplică, cine a acceptat riscul rămas și până când este planificată trecerea? O acceptare scrisă a riscului, cu dată de expirare, este mult mai bună la audit decât un sistem vechi care rulează tacit mai departe. La fel de importante sunt jurnalele. Presa de specialitate și autorii de specialitate au recomandat după PHP2Shell păstrarea jurnalelor serverului începând cu 20.10.2026. Dacă regula dumneavoastră de păstrare permite acest lucru și dacă jurnalele se află la furnizorul de hosting sau la dumneavoastră ar trebui clarificat înainte de următorul incident, nu în timpul lui.
Dacă firma dumneavoastră intră în plus sub incidența NIS2, aceste cerințe se întăresc. Principiile se află la NIS2 și securitatea serverelor web. Aceasta este informație generală, nu consultanță juridică.
Un certificat sau o etichetă descrie starea unui sistem de management la momentul verificării. Ele nu protejează un server individual împotriva unei noi breșe. Decisiv este ca procedura să funcționeze efectiv în caz de urgență.
Cum ajută PHP SOS concret?
- Înregistrăm serverele dumneavoastră web și instalările PHP astfel încât să se potrivească în inventarul SMSI-ului dumneavoastră.
- Aplicăm patchuri și documentăm prin serviciul nostru de patch PHP: starea pachetului, repornirea, verificarea, cu dată și dovezi.
- Formulăm întrebările către furnizorii de hosting și agenții și evaluăm răspunsurile lor pentru managementul furnizorilor dumneavoastră.
- Livrăm responsabililor SMSI faptele tehnice. Evaluarea în sistemul de management și auditul rămân la dumneavoastră și la organismul dumneavoastră de audit.
Concluzie
ISO 27001 și TISAX nu cer un anumit server web, dar cer o gestionare verificabilă a lui. PHP2Shell arată dacă inventarul, tratarea vulnerabilităților și conducerea furnizorilor funcționează împreună. Cine dovedește corect lanțul de primire, evaluare, patch, repornire și verificare ulterioară nu are doar auditul, ci mai ales serverul sub control.
Întrebări frecvente
Intră site-ul companiei în domeniul de aplicare al unui ISO 27001?
Depinde de cum a stabilit compania dumneavoastră domeniul de aplicare. Dacă site-ul prelucrează date ale clienților, este conectat la sisteme interne sau este operat de un furnizor de servicii, sunt multe argumente pentru a-l include sau cel puțin pentru a-l cuprinde prin managementul furnizorilor.
Este TISAX un certificat?
ENX Association vorbește despre o evaluare realizată de furnizori independenți de servicii de audit, ale cărei rezultate sunt atribuite sub formă de etichete TISAX. Etichetele sunt valabile, potrivit ENX, trei ani și sunt partajate țintit cu parteneri prin portalul ENX; ele nu sunt publice.
Trebuie să îmi informez auditoarea după PHP2Shell?
Nu există o obligație generală în acest sens. SMSI-ul dumneavoastră ar trebui însă să documenteze cum ați evaluat și tratat vulnerabilitatea. Aceste documente sunt de obicei consultate la următorul audit.
Care este versiunea actuală a ISO 27001?
Determinantă este ediția ISO/IEC 27001:2022. Anexa A a acesteia ordonează măsurile în patru teme: organizatorice, privind persoanele, fizice și tehnologice.