← Всички статии
Сигурност · Microsoft 365

Entra ID: десет проверки за сигурност, които правя във всяка Microsoft 365 среда

Практичен списък за администратори и собственици на фирми — администраторски акаунти, MFA, остаряла автентикация, достъп на гости и приложения. Какво да се провери първо и защо.

13 октомври 2026 г. · 4 мин четене

Когато поемам нова Microsoft 365 среда, първите въпроси не са за пощата или Teams, а за самоличностите. Entra ID (бившият Azure AD) е входната врата към всичко останало — имейл, файлове, приложения. Ако тя е открехната, останалите мерки нямат голямо значение.

Ето десетте проверки, с които започвам. Не са изчерпателни, но покриват повечето реални рискове, които виждам в малки и средни фирми.

1. Колко души са глобални администратори?

Отговорът трябва да е малко — Microsoft препоръчва под пет. Много често се оказват всички от IT, бивш доставчик и управителят „за всеки случай“.

  • Всеки администратор има отделен акаунт само за администриране, без пощенска кутия и без ежедневна работа с него.
  • Ролите са възможно най-тесни — за управление на потребители е достатъчна ролята User Administrator, за Exchange — Exchange Administrator.
  • Ако лицензите позволяват (Entra ID P2), ролите се активират само при нужда чрез Privileged Identity Management, вместо да са постоянно активни.

2. Има ли аварийни акаунти?

Ако условните правила за достъп (Conditional Access) или MFA се объркат, може да заключите всички — включително себе си. Затова се поддържат два аварийни акаунта („break-glass“):

  • облачни (не синхронизирани от локалния AD), с глобални права;
  • изключени от правилата, които биха могли да ги блокират;
  • със силна защита — за предпочитане ключ за сигурност (FIDO2), съхраняван физически сигурно;
  • с известяване при всяко влизане — те не трябва да се ползват в нормална работа.

3. MFA за всички — и устойчиво на фишинг за администраторите

Многофакторната автентикация е най-ефективната единична мярка срещу откраднати пароли. Проверявам:

  • задължителна ли е регистрацията за всички потребители, а не само за избрани;
  • какви методи се допускат — SMS и гласовите обаждания са най-слабите и е добре да се изключат, където е възможно;
  • администраторите ползват методи, устойчиви на фишинг — passkey, FIDO2 ключ или Windows Hello for Business.

Ако нямате лицензи за Conditional Access, включете поне Security Defaults. Безплатни са и дават разумна базова защита.

4. Блокирана ли е остарялата автентикация?

Старите протоколи (POP, IMAP, SMTP с основна автентикация, стари Office клиенти) не поддържат MFA. Ако са отворени, атакуващият просто ги заобикаля. Проверете дневниците за влизания дали има такива опити и ги блокирайте с правило за условен достъп или чрез Security Defaults.

5. Има ли правила за условен достъп — и тествани ли са?

Ако имате Entra ID P1, условният достъп е основният инструмент. Минималният набор, от който започвам:

  • MFA за всички потребители;
  • по-силна автентикация за администраторските роли;
  • блокиране на остарялата автентикация;
  • при наличие на P2 — ограничаване на влизанията с висок риск.

Новите правила първо се пускат в режим само за отчет (report-only), за да се види кого биха засегнали, преди да се включат.

6. Кой може да дава достъп на приложения?

По подразбиране потребителите често могат сами да разрешат на външно приложение достъп до пощата и файловете си. Това е любим метод за атака — фишинг, който не краде паролата, а иска „разрешение“.

  • Ограничете съгласието от потребители до проверени издатели или го изключете.
  • Включете процес за одобрение от администратор, за да има как потребителите да поискат приложение.
  • Прегледайте вече дадените разрешения — често има приложения, които никой не помни.

7. Гостите и външните потребители

Гостите се трупат с годините — бивши доставчици, временни партньори, еднократни проекти.

  • Кой може да кани гости? Препоръчително е не всеки и гостите да не могат да канят други гости.
  • Изискват ли се MFA и за гостите?
  • Има ли редовен преглед и премахване на неактивните?
  • Нито един гост не бива да има администраторска роля.

8. Неактивни и „осиротели“ акаунти

Акаунт на служител, напуснал преди година, със запазена лицензия и работеща парола, е отворена врата. Проверете:

  • влизания от повече от 90 дни;
  • деактивират ли се акаунтите в деня на напускане — и кой го прави;
  • споделени акаунти („office@“, „scanner@“) — с какви права са и дали могат да влизат интерактивно.

9. Самостоятелно нулиране на парола — правилно настроено

Самостоятелното нулиране (SSPR) намалява обажданията към поддръжката, но само ако е защитено. Без въпроси за сигурност („името на първия ви домашен любимец“) — те се отгатват. Използвайте същите методи като за MFA и включете известяване към администраторите, когато някой от тях смени паролата си.

10. Пазят ли се дневниците — и гледа ли ги някой?

Дневниците за влизания и одит в Entra ID се пазят ограничено време — според лиценза. При инцидент често се оказва, че точно нужният период вече е изтрит.

  • Изнасяйте дневниците към Log Analytics или SIEM за по-дълго съхранение.
  • Настройте известия поне за: влизане с авариен акаунт, нова глобална администраторска роля, промяна в правилата за условен достъп.

Откъде да започнете

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

За пълна и актуална проверка Microsoft поддържа препоръки за конфигуриране на сигурността в Entra, а Secure Score в Microsoft 365 дава бърза оценка къде се намирате. Част от мерките изискват лицензи Entra ID P1 или P2 — затова при планиране първо проверете какво вече имате.

Накратко

Сигурността на Microsoft 365 започва от самоличностите. Малко администратори с отделни акаунти, MFA за всички, затворени стари протоколи и контрол над гостите и приложенията — това е основата, върху която останалото има смисъл.