Накратко: ИТ аварийният план за уеб сървъри определя предварително кой решава при истински случай, кого можете да намерите, кои системи може да са засегнати и какви стъпки в какъв ред следват. Който иска да изготви ИТ авариен план, няма нужда от дебел наръчник, а от няколко актуални страници, достъпни и без работеща ИТ. Ситуацията около PHP2Shell е добър повод да го направите сега.
Защо аварийният план спестява време и щети
При истински случай първите часове често се губят в търсене: кой има достъп до доставчика на хостинг? Къде са резервните копия? Кой решава дали магазинът да бъде изключен? Кой трябва да бъде информиран? Аварийният план отговаря на тези въпроси предварително, на спокойствие.
PHP2Shell показа колко кратко може да е времето. На 20.10.2026 г. php.net обяви пачовете, на 21.10. в 16:00 ч. германско време те бяха публикувани, а BSI (Федерална служба за информационна сигурност на Германия) препоръча незабавна актуализация или временно изключване. Фирмите с план знаеха кого да извикат и кои сървъри трябва да проверят. Другите първо трябваше да установят къде изобщо работи PHP.
Изготвяне на ИТ авариен план: градивните елементи
Практичният план за уеб сървъри обхваща тези части:
1. Роли и решения. Кой ръководи при извънредна ситуация, кой го замества, кой има право да изключва системи, кой говори навън? Запишете имена и заместници.
2. Списък с контакти. Вътрешни лица за контакт, доставчик на хостинг, агенция, ИТ доставчик на услуги, длъжностно лице по защита на данните, правна консултация, киберзастраховка с номер на полицата, компетентен надзорен орган по защита на данните, Zentrale Ansprechstelle Cybercrime на Вашата федерална провинция. Този списък трябва да е на разположение разпечатан.
3. Опис на системите. Всеки уебсайт, всеки магазин и всеки портал със сървър, доставчик на хостинг, режим на работа, версия на PHP, приложение, отговорно лице и вид на обработваните данни.
4. Правила за решения. При какви условия изключваме дадена система от мрежата? Кой може да реши това? Какво важи през нощта и през почивните дни?
5. Процедури. Кратки последователности от стъпки за типични случаи: позната критична уязвимост, подозрение за проникване, обезобразен уебсайт, изтекли данни, изнудване.
6. Пътища за уведомяване. Кой проверява задължение за уведомяване по чл. 33 от ОРЗД, по възможност в рамките на 72 часа от узнаването? Кой уведомява BSI при задължение по NIS2? Кой информира застрахователя?
7. Възстановяване. Къде са резервните копия, кой може да ги възстанови, колко време отнема това, кога последно е тествано?
Пример: процедура „критична уязвимост в PHP“
Така може да изглежда процедура, каквато беше нужна при PHP2Shell:
| Стъпка | Кой | Резултат |
|---|---|---|
| Оценка на съобщението (php.net, BSI) | Отговорни за ИТ | засегнати системи според описа |
| Внасяне на актуализацията, рестарт на всички работни процеси | Администратор или доставчик на услуги | Доказателство със състоянието на пакета и времето на процеса |
| Където не е възможна актуализация: временни мерки или изключване от мрежата | Ръководството решава | документирано решение |
| Запазване на логове, проверка за следи | Администратор или криминалистика | Находка или липса на находка |
| При находка: стартиране на процедурата за инцидент | Ръководство при извънредна ситуация | проверка на пътищата за уведомяване |
Важно при това: пачът затваря уязвимостта, но не премахва зловреден софтуер, внесен преди това. Затова търсенето на следи принадлежи твърдо в процедурата.
Определете колко дълго се пазят логовете на уеб сървъра и къде се намират извън сървъра. При PHP2Shell специализираната преса препоръчваше логовете да се пазят от 20.10.2026 г. нататък. Който пази логовете само няколко дни, не може да изпълни такива препоръки.
Превенция, която прави плана действителен
Планът е толкова добър, колкото са предпоставките зад него. Проверете дали има резервни копия по правилото 3-2-1 и дали са тествани, вж. Резервни копия по правилото 3-2-1. Изяснете писмено с доставчика на хостинг и с агенцията кой какво поема при критични уязвимости. Съхранявайте данните за достъп за извънредни ситуации сигурно, но достъпно, например в защитен трезор за пароли с авариен достъп.
Подгответе освен това текстови образци: вътрешна информация, съобщение до клиентите, бележка на статична страница за поддръжка. Указания има в Кризисна комуникация след атака.
Упражнения и поддържане на актуалността
План, който никога не е упражняван, почти винаги съдържа пропуски. Разиграйте веднъж годишно сценарий, например „критична уязвимост в PHP в петък следобед“, и отбележете къде засича. За начало е достатъчен прост тест: може ли второ лице без помощта на първото да се свърже с доставчика на хостинг, да възстанови резервно копие и да премести уебсайта в режим на поддръжка? Ако не, в плана липсва нещо, най-често достъп, телефонен номер или описание. Именно такива пропуски упражненията трябва да направят видими, преди да стане сериозно. Актуализирайте плана след всяко упражнение и след всяка съществена промяна. Като методическа рамка са подходящи IT-Grundschutz на BSI и BSI-Standard 200-4 за Business Continuity Management.
Правните въпроси, например за задълженията за уведомяване, планът не изяснява окончателно. Той гарантира, че подходящите лица ще бъдат привлечени навреме. Тази страница е обща информация и не представлява правен съвет.
Как помага PHP SOS конкретно?
- Изготвяме с Вас описа на системите на Вашите уеб сървъри, включително режим на работа и версия на PHP.
- Пишем техническите процедури за типични сценарии и ги съгласуваме с доставчика на хостинг и с агенцията.
- Провеждаме упражнение и внасяме констатациите в плана.
- При истински случай поемаме техническата страна чрез Incident Response, при желание подсигурено с договор за поддръжка на сигурността.
Често задавани въпроси
Колко обемен трябва да е ИТ аварийният план?
Колкото може по-кратък, колкото е необходимо подробен. За уеб сървърите често са достатъчни няколко страници с контакти, списък на системите, правила за решения и процедури. По-важно от обема е да е актуален и да може да се намери при истински случай.
Къде да съхранявам аварийния план?
На поне едно място, достъпно и без работеща ИТ, например разпечатан или на отделно устройство. План, който стои само на засегнатия сървър или в блокираната фирмена мрежа, при истински случай не помага.
Колко често трябва да се проверява планът?
Най-малко веднъж годишно и след всяка съществена промяна, например смяна на доставчика на хостинг или нов софтуер. Смисъл има кратко упражнение, при което се разиграва сценарий.
Има ли образци от BSI?
BSI разглежда управлението при извънредни ситуации в рамките на IT-Grundschutz и в BSI-Standard 200-4 за Business Continuity Management. Те са подходяща рамка; за уеб сървърите си струва кратка, практична версия.