# Настройване на двуфакторно удостоверяване за администраторски достъпи

> Двуфакторно удостоверяване за администратори: подходящи методи, всички важни достъпи от CMS до SSH, аварийни кодове и чисто въвеждане в екипа.

Източник: https://phpsos.de/bg/ratgeber/zwei-faktor-admin/  
Актуалност: 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, хостинг, панел, SSH, домейн, DNS и пощенските кутии на администраторите. Също толкова важни като настройването са аварийните кодове и ясното правило кой за какво има собствен достъп.

## Защо паролите сами не са достатъчни за администраторите

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

С втори фактор атакуващият допълнително се нуждае от нещо, което притежава само упълномощеният потребител, например смартфон с приложение Authenticator или ключ за сигурност. Това значително повишава прага, особено при акаунти с широки права.

За ръководството е важно разграничението: двуфакторното удостоверяване защитава достъпите, не софтуера зад тях. Уязвимост като PHP2Shell, която позволява изпълнение на код без вход в системата, по този начин не се затваря. И двете принадлежат заедно: актуален софтуер и добре защитени достъпи.

## Кои методи за двуфакторно удостоверяване са подходящи

Методите се различават по сигурност и удобство. За администраторски акаунти трябва да използвате най-малко приложения Authenticator, а за особено критични достъпи ключове за сигурност или passkeys.

| Метод | Защита от фишинг | Пригодност за администратори |
|---|---|---|
| SMS код | ниска | само като преход |
| Приложение Authenticator (TOTP) | средна | добър стандарт |
| Push потвърждение | средна, податлива на атаки чрез умора | подходящо със сверяване на число |
| Ключ за сигурност или passkey (FIDO2/WebAuthn) | висока | препоръчва се за критични достъпи |
| SSH ключ с парола за ключа | висока | стандарт за достъпи до сървъри |

Еднократните кодове от приложение могат да бъдат прихванати на измамно истинска фишинг страница и веднага използвани отново. Методите FIDO2, напротив, проверяват адреса на страницата и не работят на фалшива страница. Това е причината те да са най-добрият избор за администратори с достъп до много системи.

## Двуфакторно удостоверяване за администраторски достъпи: пълният списък

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

- **CMS и административна част на магазина:** WordPress, Shopware, TYPO3 и други предлагат двуфакторно удостоверяване в ядрото или чрез поддържани разширения. Кой вариант се препоръчва, е посочено в документацията на производителя.
- **Клиентски акаунт при хостинг доставчика:** Който проникне там, често може да нулира пароли, да изтегля резервни копия или да инсталира сървъра наново.
- **Панел на сървъра** като Plesk или cPanel, ако има такъв.
- **SSH и SFTP:** ключ вместо парола, вижте следващия раздел.
- **Регистратор на домейни и DNS:** Променена DNS настройка пренасочва Вашите посетители и поща, без сървърът да е засегнат.
- **Пощенски кутии на администраторите:** През тях минават нулирането на пароли за почти всички други услуги.
- **Хранилище на код и deployment:** Който има право да записва там, може да внедри злонамерен код.
- **CDN, WAF, Google Search Console и доставчици на плащания.**

Фиксирайте за всеки запис кой има достъп, активен ли е вторият фактор и къде са кодовете за възстановяване. Този списък е същевременно важна част от Вашия авариен план, защото след инцидент точно тези достъпи трябва за кратко време да бъдат проверени и подновени.

## SSH: ключ вместо парола

За достъпи до сървъри влизането със SSH ключ е обичайната силна защита. Частният ключ е на устройството на администратора и е защитен с парола за ключа; при особено защитавани сървъри той може да е на хардуерен ключ. Когато влизането с ключ е настроено и тествано за всички администратори, изключете влизането с парола:

```text
# /etc/ssh/sshd_config (откъс)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
```

```bash
# Проверка на конфигурацията, преди услугата да се презареди
sshd -t && systemctl reload ssh   # при RHEL системи: sshd
```

При превключването оставете съществуваща сесия отворена и тествайте влизането във втори прозорец. Така при грешка няма да заключите сами себе си. Всеки администратор получава собствен ключ; общи ключове за цял екип не могат да се отнемат чисто при напускане на отделни лица. Допълнителни основи описва страницата [Сигурност на root сървъри и vServer със собствени сили](https://phpsos.de/bg/server/root-server-vserver/).

## Авариен достъп и кодове за възстановяване

Доброто въвеждане планира и отказа. Смартфоните се губят, служителите напускат фирмата, ключовете за сигурност се чупят. Без план в неподходящия момент няма кой да е с достъп.

> **Съвет:**
> Регистрирайте за всеки критичен акаунт два фактора, например ключ за сигурност в офиса и приложение Authenticator, и съхранявайте кодовете за възстановяване отделно от паролата.

Други правила, които са се доказали:

- Лични акаунти вместо споделяни администраторски входове, за да са проследими промените.
- Документиран авариен достъп с отделно съхранявани данни за достъп, чието използване се забелязва и протоколира.
- При напускане на служители или изпълнители отнемайте всички достъпи и ключове в същия ден.
- След инцидент със сигурността проверявайте не само паролите, но и регистрираните фактори и активните сесии.

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

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

Как допълнително да защитите страниците за вход срещу автоматизирани опити, е описано в наръчника [Защита на админ входовете от brute force](https://phpsos.de/bg/ratgeber/brute-force-login-schutz/).

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

- Изготвяме заедно с Вас пълен списък на всички администраторски достъпи и показваме къде липсва вторият фактор.
- Преминаваме достъпите до сървъри към SSH ключове и изключваме контролирано влизането с парола в рамките на [заздравяването на сървъра](https://phpsos.de/bg/leistungen/server-haertung/).
- Документираме аварийните достъпи и пътищата за възстановяване така, че да работят в критичен момент.
- В [договора за поддръжка на сигурността](https://phpsos.de/bg/leistungen/security-wartungsvertrag/) проверяваме редовно достъпите и премахваме осиротели акаунти.


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

**Кой метод за двуфакторно удостоверяване е най-сигурен?**  
Хардуерните ключове за сигурност и passkeys по стандарта FIDO2 се смятат за особено устойчиви на фишинг, защото са обвързани с истинския адрес. Приложенията Authenticator с еднократни кодове са добър стандарт. SMS е по-добре от нищо, но е най-слабият вариант.

**Какво става, ако смартфонът с приложението Authenticator се изгуби?**  
За това има кодове за възстановяване, които се показват при настройването. Те трябва да се съхраняват сигурно, например в сейф или в защитен мениджър на пароли. Освен това поне още един администратор трябва да може да нулира достъпа.

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

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

## Източници

- [BSI: Двуфакторно удостоверяване](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series (Multifactor Authentication)](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)