# ISO 27001 и TISAX: какво засяга уеб сървърите

> ISO 27001 и TISAX при уеб сървъра: кои изисквания засягат пачовете, доставчиците и инцидентите и какви доказателства след PHP2Shell влизат в досието.

Източник: https://phpsos.de/bg/blog/iso-27001-tisax-webserver/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** ISO 27001 и TISAX засягат уеб сървърите най-вече чрез три изисквания: уязвимостите трябва да се откриват и третират, доставчиците като хостинг и агенции трябва да се управляват, а инцидентите със сигурността изискват уреден ред. Ситуация като PHP2Shell е практически тест за всеки ISMS. Който документира проследимо оценката, пача и рестарта, има добра основа за следващия одит. Сертификатът или етикетът не заменя пача.

## Какво са ISO 27001 и TISAX, в два абзаца

ISO/IEC 27001 описва изискванията към система за управление на информационната сигурност, накратко ISMS. Има се предвид подреден цикъл: оценка на рисковете, определяне на мерки, изпълнение, проверка и подобрение. Актуалното издание от 2022 г. съдържа в Приложение А каталог от 93 мерки в четири теми. Кои от тях важат, решава фирмата на основата на своята оценка на риска и го записва в декларацията за приложимост.

TISAX е разпространеният в автомобилната индустрия механизъм за проверка и обмен. Управлява се от ENX Association, основа е каталогът с изисквания ISA, който ENX поддържа, а VDA публикува. Независими доставчици на услуги по проверка провеждат оценка, чийто обхват зависи от нуждата от защита и варира от проверка на документи до посещения на място. Според ENX резултатите се присъждат като етикети, важат три години и се споделят през портала на ENX само с избрани партньори.

## ISO 27001 при уеб сървъра: кои изисквания действат?

Уеб сървърът рядко е самостоятелна глава в ISMS. Той се появява на няколко места и точно там възникват пропуските. Следният преглед подрежда най-важните теми общо. Той не заменя поглед в собствената Ви декларация за приложимост.

| Тема в ISMS | Какво означава при уеб сървъра | Доказателство, което помага при одит |
|---|---|---|
| Инвентар на активите | Всеки уебсайт, всеки сървър, всяка версия на PHP е отчетена | Актуален списък с оператор, версия, отговорно лице |
| Работа с технически уязвимости | Съобщения като PHP2Shell се оценяват и третират | Тикет с оценка, решение, дата на пача |
| Отношения с доставчици | Хостинг доставчикът и агенцията имат ясни задължения за сигурност | Договор, разпределение на задачите, писмено потвърждение на състоянието на пача |
| Протоколиране и наблюдение | Логовете на уеб сървъра се съхраняват и анализират | Правило за съхранение, пример за анализ |
| Управление на инциденти | Подозрението се съобщава, оценява и приключва | Протокол за инцидента, Lessons Learned |
| Управление на конфигурацията | Настройките на PHP и уеб сървъра са определени | Целева конфигурация и проверка за отклонения |

При TISAX важат съпоставими теми, защото каталогът ISA е съгласуван с други значими стандарти. Освен това някои цели на проверка, например защитата на прототипи, изискват особена грижа към системи, чрез които партньори обменят данни. Това могат да бъдат и портали на основата на PHP.

## PHP2Shell като практически тест за ISMS

На 21.10.2026 г. PHP проектът публикува версиите 8.5.12, 8.4.27, 8.3.36 и 8.2.35. За PHP 8.1 и по-стари вече няма официални ъпдейти. Работещият ISMS трябва в това положение да задейства верига, която по-късно може да се докаже.

1. **Получаване:** Кой кога е получил съобщението и къде е отчетено?
2. **Оценка:** Кои системи са засегнати? Това предполага актуален инвентар, вижте [Да знаем какво работи](https://phpsos.de/bg/blog/inventar-websites-server/).
3. **Решение:** Пач, временна мярка или временно изключване, с обосновка и името на решаващото лице.
4. **Изпълнение:** Състояние на пакета, рестарт на всички PHP процеси, контрол. При backport-ове на дистрибуцията важи changelog-ът на пакета, а не показаният номер на версията; как се доказва това, показва [Как да проверите правилно версията на PHP и състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).
5. **Доставчици:** Писмено потвърждение от хостинг доставчика, че е пачнато и рестартирано.
6. **Последващ контрол:** Проверка за признаци на компрометиране от 17.10.2026 г. насам, защото пачът не отменя по-ранни прониквания.

Как от тази еднократна верига да направите траен процес, описват [Управление на уязвимостите в средния бизнес](https://phpsos.de/bg/blog/schwachstellenmanagement-mittelstand/) и [Управление на пачовете като процес](https://phpsos.de/bg/blog/patch-management-prozess/).

## Чести слабости в документацията

На практика доказването рядко се проваля заради техниката, а заради пропуски във веригата. Типичен е уебсайт, който отдел поддържа с агенция и който липсва в инвентара. Също толкова чести са договори с хостинг доставчици без изказване за това колко бързо се инсталират ъпдейтите за сигурност и дали клиентите се информират.

Друга класика: тикетът за пача е затворен, но никой не е рестартирал PHP процесите. Формално точката е изпълнена, технически старият код продължава да работи. Доброто доказателство затова съдържа не само „ъпдейтът е инсталиран“, но и рестарта и контрол след него.

Трудно става и при системи, които не могат да се пачнат веднага, например приложение на PHP 8.1. Тук ISMS не изисква чудеса, но изисква съзнателно решение: кои временни мерки важат, кой е приел остатъчния риск и до кога е планиран преходът? Писмено приемане на риска със срок на валидност е на одит значително по-добро от мълчаливо продължаващо да работи старо решение. Също толкова важни са логовете. След PHP2Shell специализираната преса и авторите съветваха да се съхраняват сървърните логове от 20.10.2026 г. нататък. Дали Вашето правило за съхранение позволява това и дали логовете са при хостинг доставчика или при Вас, трябва да се изясни преди следващия инцидент, а не по време на него.

Ако Вашата фирма допълнително попада под NIS2, тези изисквания се засилват. Основните положения са в [NIS2 и сигурност на уеб сървърите](https://phpsos.de/bg/compliance/nis2/). Това е обща информация, не е правен съвет.

> **Важно:**
> Сертификатът или етикетът описва състоянието на една система за управление към момента на проверката. Той не защитава отделен сървър от нова уязвимост. Решаващо е редът в критичен момент действително да работи.

## Как помага PHP SOS конкретно?

- Описваме Вашите уеб сървъри и PHP инсталации така, че да пасват в инвентара на Вашия ISMS.
- Пачваме и документираме с нашата [услуга за PHP пачове](https://phpsos.de/bg/leistungen/php-patch-service/): състояние на пакета, рестарт, контрол, с дата и доказателства.
- Формулираме въпросите към хостинг доставчици и агенции и оценяваме отговорите им за Вашето управление на доставчиците.
- Предоставяме на отговорните за Вашия ISMS техническите факти. Оценката в системата за управление и одитът остават у Вас и у Вашата проверяваща институция.

## Извод

ISO 27001 и TISAX не изискват определен уеб сървър, но изискват проследимо отношение към него. PHP2Shell показва дали инвентарът, третирането на уязвимостите и управлението на доставчиците работят заедно. Който доказва прецизно веригата получаване, оценка, пач, рестарт и последващ контрол, има под контрол не само одита, а преди всичко сървъра.


## Често задавани въпроси

**Влиза ли фирменият уебсайт в обхвата на ISO 27001?**  
Това зависи от начина, по който Вашата фирма е определила обхвата. Ако уебсайтът обработва данни на клиенти, е свързан с вътрешни системи или се поддържа от доставчик, има много основания да се включи или поне да се отчете чрез управлението на доставчиците.

**Сертификат ли е TISAX?**  
ENX Association говори за оценка (assessment) от независими доставчици на услуги по проверка, чиито резултати се присъждат като етикети TISAX. Според ENX етикетите важат три години и се споделят целенасочено с партньори през портала на ENX, те не са публични.

**Трябва ли след PHP2Shell да информирам одитора си?**  
Общо задължение за това няма. Вашият ISMS обаче трябва да документира как сте оценили и третирали уязвимостта. Тези документи обикновено се разглеждат при следващия одит.

**Коя версия на ISO 27001 е актуална?**  
Меродавно е изданието ISO/IEC 27001:2022. Приложение А към него подрежда мерките в четири теми: организационни, свързани с хората, физически и технологични.

## Източници

- [ENX Association: TISAX](https://www.enx.com/de-DE/TISAX/)
- [BSI: IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP: Поддържани версии](https://www.php.net/supported-versions.php)
