# Осведоменост за сигурността при администратори и редактори: Security Awareness в уеб екипа

> Осведоменост за сигурността при администратори и редактори: рискове по роли, кратки обучения и как да подготвите целия уеб екип за 90 дни.

Източник: https://phpsos.de/bg/blog/sicherheitsbewusstsein-redaktion/  
Актуалност: 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

**Накратко:** Осведоменост за сигурността при служителите в уеб екипа означава: всеки, който поддържа уебсайт, познава трите-четири риска на своята роля, разпознава необичайното и го съобщава бързо и без страх от упреци. Редакторите се нуждаят от друго съдържание, отколкото администраторите. Кратки, повтарящи се занятия с примери от собствения CMS действат по-добре от годишно задължително обучение.

## Защо именно сега уеб екипът е в центъра

Положението около PHP2Shell показа колко много неща се стоварват върху операторите на уебсайтове за няколко дни: предупреждения на BSI (Федералната служба за информационна сигурност на Германия), съобщения от хостинг доставчици, съвети във форуми и социални мрежи, сред тях и неверни. В такива седмици решават не само администраторите, но и редакторите, маркетингът и асистентите кой имейл да отворят и върху коя връзка да кликнат.

Големите новинарски ситуации според опита са повод за измамници. Разчитайте на имейли, които се представят за хостинг доставчик, производител на CMS или „ИТ отдел“ и призовават към спешен вход или уж ъпдейт за сигурност. Който познава истинското положение, по-рядко се връзва. Самата техническа уязвимост не се затваря от редактор, но откраднат администраторски достъп отваря вратата и без уязвимост.

## Осведоменост за сигурността на служителите: кой от какво се нуждае?

Обучение за всички със същите слайдове обикновено не постига целта си. По-смислено е нагаждане по роли. Следният преглед помага при планирането:

| Роля | Типични рискове | Какво трябва да може лицето |
|---|---|---|
| Редактор, маркетинг | фишинг имейли, несигурно качване на файлове, споделени достъпи | да проверява подателя, да качва само очаквани видове файлове, никога да не предава собствените си данни за достъп |
| CMS администратор | добавки от неизвестен източник, твърде много администраторски акаунти, стари акаунти на бивши служители | да дава права пестеливо, да проверява акаунтите редовно, разширения само след одобрение |
| Сървърен администратор | непроверени съвети от мрежата, промени без протокол, забравени тестови файлове | да оценява източниците, да документира промените, да познава пътя при извънредни случаи |
| Управител | натиск за бързи решения, неясни отговорности | да определи пътищата за вземане на решения, да приема сериозно съобщенията, да отпусне бюджет за превенция |
| Външна агенция | общи достъпи, липса на уговорки | да използва собствени, лични акаунти, да обявява промените |

Таблицата показва и къде техниката трябва да помогне. Лични акаунти вместо общи достъпи и двуфакторно удостоверяване за всички с права за запис снемат много натиск от обучението. Как става това, е описано в [Двуфакторно удостоверяване за администраторски достъпи](https://phpsos.de/bg/ratgeber/zwei-faktor-admin/).

## Какво трябва да знаят редакторите, без да стават техници

Редакторите не е нужно да знаят какво е PHP worker. Трябва обаче да владеят сигурно три неща. Първо: покана да влезете наново „поради инцидент със сигурността“ никога не се изпълнява чрез връзката в имейла, а по обичайния път към CMS или чрез запитване до администратора.

Второ: съобщаване на необичайното. Към него спадат непознати потребителски акаунти в списъка с потребители, страници или публикации, които никой не е създал, внезапни пренасочвания и предупреждения в браузъра. Редакторът често вижда уебсайта по-често от администратора и забелязва промените по-рано.

Трето: съзнателно отношение към качваните файлове. Изображения и PDF са ежедневие, но файл с необичайно разширение, архив „за препращане“ или документ с макроси не принадлежи в CMS. Ако един файл не може да бъде качен, това обикновено е нарочно, а не грешка, която да се заобикаля.

## От какво се нуждаят допълнително администраторите

За администраторите става дума по-малко за фишинг, а повече за преценка под натиск на времето. През седмицата на PHP2Shell циркулираха съвети, които специалистите изрично отхвърлят, например да се блокират всички заявки с `PHPSESSID`. Преглед на такива заблуди предлага материалът [Опасни фалшиви съвети за PHP2Shell](https://phpsos.de/bg/blog/gefaehrliche-falschtipps/). Добрите администратори първо проверяват първичния източник, тоест php.net, BSI или производителя, преди да променят конфигурация.

Към това спада дисциплина при промените: какво е променено, кога и защо и как може да се върне назад? Достатъчен е кратък запис в тикета или уикито. В критичен момент този списък струва злато, защото показва коя промяна е от Вас и коя не.

Накрая администраторите трябва да знаят по какво се разпознава възможно проникване и какво тогава не бива да се прави: не се трие трескаво, не се преинсталира веднага, а се запазва и се съобщава. Типичните признаци обобщава [Вече компрометирани ли сме?](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/).

## За 90 дни до бдителен уеб екип

Една програма не е нужно да е голяма, за да действа. Тези стъпки са се доказали:

1. **Изяснете състоянието (седмица 1 до 2):** Кой какви достъпи има до CMS, хостинг, домейн и сървър? Разпуснете общите акаунти, блокирайте старите.
2. **Определете пътя за съобщаване (седмица 2):** Един адрес или канал за „нещо ми се струва странно“. На всяко съобщение се отговаря, дори да е било безобидно.
3. **Първо кратко занятие за всяка роля (седмица 3 до 4):** 20 минути, примери от собствения CMS, екранни снимки на истински менюта.
4. **Въведете двуфакторно удостоверяване (до седмица 6):** За всички с права за запис, с аварийни кодове на сигурно място.
5. **Учебен имейл и оценка (седмица 8):** Обявена тестова кампания без излагане на отделни лица. Оценява се дали е съобщено, а не кой е кликнал.
6. **Второ занятие по повод (седмица 10 до 12):** Например актуална ситуация със сигурността, изиграна върху собствената система.

Измервайте успеха по съобщенията, а не по процента кликове. Екип, който съобщава много, е бдителен. Екип, който никога не съобщава, е или съвършен, или несигурен, а първото е рядкост.

## Как помага PHP SOS конкретно?

- Установяваме заедно с Вас кой какви достъпи има и показваме общи акаунти, излишни администратори и забравени достъпи.
- Провеждаме кратки занятия за всяка роля отдалечено, с примери от Вашия CMS и Вашата сървърна среда.
- Помагаме да се настрои пътят за съобщаване и оценяваме постъпилите сигнали за подозрения, ако желаете.
- В рамките на [договор за поддръжка на сигурността](https://phpsos.de/bg/leistungen/security-wartungsvertrag/) повтаряме занятията по актуални поводи и проверяваме акаунтите редовно.

## Извод

Осведомеността за сигурността в уеб екипа не се поражда от страх, а от яснота: всеки познава своята роля, типичните си рискове и пътя за съобщаване на необичайното. В съчетание с лични акаунти и двуфакторно удостоверяване това е защита, която издържа и в следващата кризисна седмица.


## Често задавани въпроси

**Нужно ли е на редакторите изобщо обучение по сигурност?**  
Да. Редакторите имат достъп до CMS, качват файлове и получават имейли, които изглеждат като системни съобщения. Не е нужно да разбират от техника, но трябва да познават кога нещо е необичайно и на кого да го съобщят.

**Колко често трябва да се обучава уеб екипът?**  
По-добре кратко и редовно, отколкото дълго веднъж годишно. Доказали са се занятия от 15 до 20 минути през няколко седмици, допълнени с повод като актуална ситуация със сигурността.

**Какво да се направи, ако служител е кликнал върху фишинг връзка?**  
Да се съобщи веднага, без упреци. След това се сменя засегнатата парола, прекратяват се активните сесии и се проверява дали нещо е променено с акаунта. Колкото по-рано дойде съобщението, толкова по-малка е обикновено щетата.

**Заменя ли обучението техническите защитни мерки?**  
Не. Обучението и техниката се допълват. Двуфакторното удостоверяване, разделените роли и актуалният софтуер улавят грешки, които се случват и на добре обучени хора.

## Източници

- [BSI: Информация за фирми](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: Съобщения за сигурност](https://www.php.net/)