Конфигуриране на MFA и условен достъп в Windows 11

Последна актуализация: 07/05/2026
Автор: Isaac
  • Условният достъп на Entra ID прилага многофакторна автентификация (MFA) и други контроли въз основа на потребител, устройство, мрежа, риск и заявен ресурс.
  • Глобална политика за всички ресурси позволява изискването на MFA и сила на удостоверяване за всеки достъп от Windows 11 и други клиенти.
  • Контроли като съвместимо устройство, хибридно свързване, одобрени приложения и смекчаване на риска засилват сигурността отвъд обикновената многофакторна автентикация (MFA).
  • Комбинацията от условен достъп, Intune и управление на идентичността с най-малко привилегии създава много по-устойчив периметър, базиран на идентичност.

Конфигуриране на MFA и условен достъп в Windows 11

Защитете входа Windows 11 за бизнес с MFA и условен достъп Това се е превърнало в основно изискване за всяка организация, използваща Microsoft 365, Power Platform или облачни услуги. Сложната парола вече не е достатъчна: нападателите са се научили да я заобикалят, а истинската сигурност се крие в многофакторното удостоверяване и интелигентните политики за достъп.

Ако работите с Устройства с Microsoft Entra ID (преди Azure AD), Intune и Windows 11Вероятно сте чували за условен достъп, но може би не сте напълно сигурни как всичко се вписва заедно: многофакторна автентичност (MFA), сила на удостоверяване, съвместими устройства, външни потребители, Power Platform и т.н. Това ръководство ще сглоби всички части, като обясни подробно какво прави всеки контрол, как се комбинират и какви реални ограничения ще срещнете, когато го прилагате към Windows 11, включително уникалния случай на уеб вход.

Какво е условен достъп и как се свързва с многофакторна автентичност (MFA) в Windows 11?

El Идентификатор за вход в Microsoft за условен достъп Това е по същество система от правила „ако това се случи, направете онова“, която определя дали потребителят може да получи достъп до ресурс: облачно приложение, конкретно действие (като например регистриране на информация за сигурност) или специален контекст за удостоверяване. Политиките комбинират сигнали като самоличност на потребителя, устройство, мрежа, риск при влизане и тип клиент, за да прилагат контроли като MFA, съвместими изисквания за устройство или пълно блокиране.

Всяка директива е изградена с два основни блока: задачи (кой, какво и при какви условия) y контрол на достъпа (какво е задължително или блокирано)Могат да се прилагат множество контроли едновременно и ако са изпълнени условията на повече от една политика, потребителят ще трябва да спазва всички приложими изисквания (напр. MFA + съвместимо устройство + приемане на условията за ползване).

В среди с Windows 11, съчетани с Entra ID и Intune, условният достъп действа в момента, в който се изисква токен за защитен ресурс. Тази точка е ключова.Механизмът за условен достъп не се задейства всеки път, когато потребител въведе идентификационни данни, а по-скоро когато приложение (или системата) поиска маркер за конкретен ресурс (Exchange, SharePoint, Power BI и др.).

Следователно, дори ако целта ви е „винаги да изисквате MFA при влизане в Windows 11“, на практика Техническото предизвикателство е къде да се оценят тези политики и кои приложения или ресурси задействат оценката на условния достъп.

Панел с настройки за условен достъп

Многофакторна автентикация и интензивност на удостоверяването: нива и стратегии

В Microsoft Entra ID многофакторното удостоверяване не е просто превключвател „да/не“. Има много важна концепция, наречена сила на удостоверяванекоето определя колко надежден трябва да бъде методът, за да отговаря на политиката. Microsoft предоставя три вградени нива:

Многофакторна автентикация (Най-малко рестриктивният, но препоръчителният базов метод в повечето сценарии). Приема стандартни MFA методи като SMS, гласови повиквания, push известия в Microsoft Authenticator, OATH токени и др. Това е най-често срещаната отправна точка за изискване на двуфакторно удостоверяване при достъп до корпоративни ресурси от Windows 11.

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

Устойчивост на фишинг MFAНай-строгото ниво, предназначено за критични акаунти (администратори, акаунти с високи привилегии, достъп до силно чувствителни данни). Това ниво обикновено изисква комбинация от методи, които не могат да бъдат лесно прихванати (например FIDO2 или Windows Hello for Business).

В допълнение към тези предварително дефинирани опции, можете създаване на персонализирани интензитетиСъставяне на собствена комбинация от приети методи, нещо много полезно, ако искате например да принудите администраторите си да използват Windows Hello или FIDO2 за определени задачи в Windows 11 и да им забраните да валидират чрез SMS.

Конфигурация на MFA и сила на удостоверяване

Създаване на базова политика за многофакторно удостоверяване (MFA) с условен достъп

Най-чистият начин за налагане на МФП в световен мащаб (включително достъп от Windows 11 до услуги на Microsoft 365, корпоративни приложения и Power Platform) се постига чрез политика за условен достъп, насочена към всички потребители и всички ресурси. Типичният работен процес за изграждане на тази политика би бил:

Първо, достъп до Вход в центъра за администрация на Microsoft Използвайки акаунт, който има поне ролята на администратор за условен достъп, отидете на ИД за вход > Условен достъп > Политики и създайте нова политика с ясно и стандартизирано име.

  Поправка за размазано изображение и неправилна честота на кадрите в Windows 11

В Потребители или служебни идентичностиИзберете „Всички потребители“ под „Включи, но изключи акаунти с break-glass и акаунти за синхронизация (като тези от Entra Connect), за да избегнете блокиране на администраторския достъп или синхронизирането на самоличност. Ако управлявате гости със специфични правила, можете да изключите външни потребители от това глобално правило.

En Целеви ресурси (преди „Облачни приложения“)Изберете „Всички ресурси“. По този начин всяка заявка за токен към услуги като Exchange Online, SharePoint, Teams, Power BI, бизнес приложения и дори Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) ще бъде засегната от политиката.

В Контрол на достъпаВ настройките за предоставяне изберете „Предоставяне на достъп“ и активирайте „Изискване на сила на удостоверяване“. Изберете „Многофакторно удостоверяване“ като минимална сила. Първоначално е силно препоръчително да активирате политиката в режим „Само отчет“, за да видите действителното въздействие, преди да я активирате напълно.

След като прегледате лог файловете и се уверите, че няма случайно да спрете половината от средата, можете да промените състоянието на „Активирано“. От този момент нататък, всички заявки за достъп до защитени ресурси Те ще преминават през този MFA слой, също и от компютри с Windows 11, присъединени към директорията, с изключение на изключенията, които сте дефинирали.

Пример за политики за условен достъп

Разширен контрол върху безвъзмездните средства: отвъд „изискването за многостранна финансова помощ“

След като сте усвоили основите на MFA, можете да започнете да експериментирате с останалото. контрол на концесиите който предлага условен достъп за устройства с Windows 11 и други системи. Логиката е подобна: вие избирате дали да блокирате достъпа или да го предоставите, като изисквате комбинация от условия.

Контролът на „Блокиране на достъпа“ То е толкова мощно, колкото и опасно. Ако съпоставянето (потребители, ресурс, условия) съвпада, достъпът се отказва без опция за MFA или други смекчаващи мерки. Идеално е за премахване на остарели протоколи, блокиране на конкретни държави или прекъсване на достъпа до остарели приложения, но винаги е препоръчително първо да се тества в режим „само за отчети“ и да се използват инструменти като What If.

Когато изберете „Предоставяне на достъп“, можете комбинират няколко изискванияМожете да изисквате MFA, съвместимо устройство, хибридна Entra облигация, одобрено клиентско приложение, политика за защита на приложения, промяна на парола или смекчаване на риска. Можете да решите дали потребителят трябва да спазва всички избрани контроли (И) или само един (ИЛИ).

Контролът на „Изискване устройството да бъде маркирано като съвместимо“ Разчита на Intune. Устройството трябва да е регистрирано с Entra ID и да отговаря на политиките за съответствие (антивирусна програма, криптиране, версия на операционната система и др.). Поддържа Windows 10 / 11iOS, Android, macOS и Ubuntu Linux с Intune. Този подход е идеален за гарантиране, че достъпът до чувствителни данни винаги е от управлявани устройства.

Ако сте в хибридна организация, контролът „Изисква хибридно устройство, свързано с Microsoft. Вход„Това ви позволява да гарантирате, че само компютри, присъединени към домейн, регистрирани с Entra ID (преди и текущи версии на Windows 10), имат достъп до определени ресурси. Този подход се използва широко за ограничаване на администрирането до корпоративни устройства.“

Можете също така да поискате одобрени клиентски заявления (класическият списък с приложения на Office, Outlook, OneDrive, Teams, Power BI и др.) или политика за защита на приложенията от Intune, което гарантира, че данните се отварят само в приложения, защитени от MAM, предимно на iOS и Android (и в предварителен преглед за Edge на Windows).

Накрая, контролите на „Изискване за промяна на паролата“ Настройките „Изискване за смекчаване на риска“ са интегрирани с Microsoft Entra ID Protection: те се използват, когато потребителят е маркиран като високорисков. В тези сценарии се принуждава защитено нулиране или процес на отстраняване на риска, винаги предшестван от MFA, за да се спрат компрометирането на акаунта без постоянна намеса на администратора.

Устройства, съвместими с MFA и Intune

Условен достъп: задачи, условия и ред на оценяване

За да бъде внедрена политика, трябва да дефинирате поне една минимален набор от задачиПотребители или групи, целеви ресурси и контрол за предоставяне или заключване. Оттам можете да прецизирате с допълнителни условия.

В частта на Потребители и групи Вие решавате кого засяга политиката: всички потребители, конкретни групи, роли в директории (например глобални администратори) или самоличности на работно натоварване (главни услуги). Оценката се извършва при издаване на нов токен, така че ако потребител се присъедини към група, след като има валиден токен, политиката няма да го засегне, докато не поднови идентификационните си данни.

En Ресурси на дестинацията Можете да маркирате облачни приложения на Microsoft (Office 365, Azure Service Management API, портали за администриране и др.), приложения, публикувани чрез Application Proxy, потребителски действия, като например регистриране на информация за сигурност или регистриране/присъединяване към устройства, и дори специфични контексти за удостоверяване, които след това се използват от SharePoint, PIM или други приложения.

на мрежови условия Те ви позволяват да използвате именувани местоположения въз основа на IP диапазони или географски местоположения. Типичен модел е да не се изисква MFA, когато потребителят е в надеждната корпоративна мрежа, и да се изисква, когато се свързва от публичния интернет.

  Как да затворите приложението Bing Maps в Windows и да деактивирате Bing

Освен това имате допълнителни условия, като например платформи на устройства (Windows, iOS, Android, macOS, Linux), тип клиентско приложение (браузър, мобилно/настолно приложение, наследени протоколи), филтри за устройства (базирани на атрибути на обекти на устройства) и риск от влизане (ако имате Entra ID Protection).

Когато множество правила се прилагат за един и същ потребител и ресурс, Те се комбинират кумулативноСледователно, ако една политика изисква MFA, а друга изисква съвместимо устройство, потребителят трябва да спазва и двете. Редът за валидиране обикновено следва логиката MFA – състояние на устройството – условия за ползване и ще видите тази последователност отразена в логове за вход.

Ограничения на MFA с уеб вход в Windows 11

В среди, където Вход в уеб системата в Windows 11 (За директно удостоверяване на заключения екран), много администратори са се сблъскали с проблем: Политиките за условен достъп, изискващи MFA, не се оценяват според очакванията. Потребителят вижда формуляра за вход, но MFA предизвикателството не се появява.

Това обикновено не се случва с влизания в браузър, мобилни приложения или Office в Windows 11, където същите правила за условен достъп се прилагат без проблем. Ако активирате многофакторна автентичност (MFA) за всеки потребител (класическият модел) вместо условен достъп, тогава MFA се налага при уеб влизания, което предполага, че проблемът се крие в това как този поток взаимодейства с механизма за правила за условен достъп.

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

Следователно, ако вашето изискване е, че Влизането в заключен екран на Windows 11 винаги изисква MFAЕдинственият надежден начин да се направи това днес е да се използва многофакторна автентикация (MFA) за всеки потребител, което налага втори фактор за удостоверяване за всеки потребител, независимо от ресурса, до който ще има достъп след това. Не е толкова гъвкаво или детайлно, колкото условния достъп, но решава това специфично ограничение.

Условен достъп за приложения, Power Platform и API

Обхватът на условния достъп далеч надхвърля Windows 11 и Microsoft 365. Power Platform (Power Apps, Power Automate, Power BI, Copilot Studio и др.) За удостоверяване и оторизация се разчита изцяло на Entra ID, така че същите правила за достъп важат и за използването на приложения, потоци и конектори.

На ниво клиент, Entra ID гарантира, че потребителят има активен акаунт, е преминал през политики за достъп (MFA, местоположение, устройство, риск) и има лиценз. Но За Power Platform това е само първият слойСлед това влизат в действие сервизни роли (Администратор на Power Platform, Администратор на Dynamics 365), групи за сигурност, които контролират достъпа до среди, и най-вече моделът за сигурност на Dataverse (RBAC, разрешения по таблица, ред и колона).

Ако искате сериозно да защитите бизнес решенията си, трябва да комбинирайте условен достъп със строг дизайн на ролите за сигурностНапример, разработчиците често се нуждаят от достъп на създатели в среди за разработка, но не и от администраторски разрешения в производствена среда. Политиките за условен достъп ви позволяват да изисквате MFA, да ограничавате местоположенията или да налагате съвместими устройства, но това, което те могат да правят, се определя от ролите и разрешенията на Dataverse.

Друг важен момент е непрекъсната оценка на достъпа (Непрекъсната оценка на достъпа). Вместо да чакат изтичането на токените (обикновено до един час), някои услуги като Dataverse могат да отменят достъпа почти в реално време, когато открият критични промени: отмяна на разрешения, промени в местоположението, промени в правилата и др. Този подход намалява времето за излагане, ако достъпът на потребителя бъде отменен или бъде открито рисково събитие.

Условен достъп за външни потребители и B2B сътрудничество

Много организации споделят ресурси с външни потребителиПартньори, доставчици, клиенти, консултанти… В тези случаи, Microsoft Entra External ID влиза в действие, позволявайки B2B сътрудничество и директна B2B свързаност. Външните потребители могат да се удостоверяват със собствения си клиент или с доставчици на социална идентификация (Google, Facebook, SAML и др.), но клиентът на ресурса решава кои политики за условен достъп се прилагат.

За сценарии между наематели на Entra можете да конфигурирате Многофакторна автентичност (MFA) и доверие при въвеждане на данни от устройствотоТова позволява на вашия клиент да приеме сигнала, ако потребителят вече е завършил MFA или устройството му е валидирано като съвместимо или присъединено към Hybrid Entry в неговата организация, от която е изготвен, и да не изисква друго предизвикателство. Ако не конфигурирате това доверие, поведението варира: B2B гостите ще трябва да завършат MFA във вашия клиент; B2B потребителите с директно свързване може да бъдат блокирани, ако се изисква MFA или съответствие на устройството и не може да бъде оценено.

  Как да създадете невидима, безименна папка в Windows 11 стъпка по стъпка

В случай на потребители, които не са от Entra (социални идентичности, лични акаунти в Microsoft или OTP удостоверяване чрез имейл), Наемателят на ресурса винаги е отговорен за многофакторната автентикация (MFA).С други думи, ако вашата политика изисква многофакторна автентичност (MFA), това ще се извърши във вашата директория; не можете да го делегирате на друг външен доставчик.

Можете също така да дефинирате специфични правила въз основа на типа външен потребител: B2B гости (UserType=Guest), B2B членове (третирани почти като вътрешни потребители), B2B потребители с директна връзка (без потребителски обект във вашата директория), наследени локални гост потребители, доставчици на услуги и т.н. Това ниво на гранулираност ви позволява например да изисквате устойчива на фишинг MFA само за външни връзки с висок риск.

Защита на директории, рискове и домейни с ниски привилегии

Деликатен детайл, който често се пренебрегва, е, че много приложения изискват сфери с ниски привилегии свързани с директорията, като например User.Read, People.Read, GroupMember.Read.All и т.н. Традиционно, когато създавахте политики „Всички ресурси“ с някакво изключение, тези области бяха пропуснати, за да не се повреди работата на приложения, които четат само основния потребителски профил или членството му в група.

Microsoft промени това поведение и сега Тези области се оценяват като достъп до ресурса на Windows Azure Active Directory. (00000002-0000-0000-c000-000000000000). Това означава, че ако имате политика, насочена към „Всички ресурси“ с изключения или специфична политика в Windows Azure AD, заявките за маркери, които изискват само тези обхвати, могат да задействат условен достъп и да наложат MFA или съответствие на устройството.

На практика потребителите могат да започнат да се сблъскват с проблеми с MFA при влизане в инструменти като Visual Studio Code, Azure CLI или други приложения, които изискват само openid, profile, User.Read или подобни обхвати. Ако вашата организация също възнамерява да защити този тип достъп до информация за директорията, това е логична стъпка; в противен случай ще трябва да коригирате правилата или да създадете специфични правила за Windows Azure Active Directory.

За да определите кои приложения ще бъдат засегнати, можете да използвате PowerShell скриптове и отчети за употреба и активност Инструментите за вход на Microsoft ви позволяват да изброите главните услуги и делегираните обхвати, които използват, както и броя на последните влизания, за да откриете приложения, които изискват само тези обхвати с ниски привилегии, и да прецените дали се нуждаете от изключения.

Добри практики за управление на сигурността и идентичността

Настройването на MFA и условен достъп в Windows 11 и останалата част от вашата среда е само половината от историята. Останалите 50% са в... модел за управление на идентичносттакой има разрешения, за колко време и с какви привилегии.

Сред най-важните препоръки са минимизиране на броя на акаунтите с голямо въздействиеРазделете ролите, вместо да повишавате привилегиите на обикновените потребителски акаунти, и използвайте модели Just-In-Time (JIT) с инструменти като Microsoft Entra Privileged Identity Management (PIM), за да предоставяте повишени разрешения само когато е необходимо.

Препоръчително е също да се избягва постоянен административен достъп, за да се поддържа документирани и наблюдавани сметки за спешни случаиЗасилете удостоверяването на администратора с методи без парола или надеждна многофакторна автентикация (MFA) и приложете по-строги правила за условен достъп към тези роли (напр. изисквайте съвместими устройства и устойчива на фишинг MFA за всяка административна операция от Windows 11).

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

По-специално за Power Platform, силно се препоръчва да насочите разработчиците към собствените си среди за разработкаОграничете масовото споделяне (например, избягвайте леко опцията „Всички“), контролирайте достъпа до среди, използвайки групи от Entra ID, използвайте Dataverse като основно хранилище с гранулиран RBAC и прилагайте политики за данни, които ограничават конекторите, които могат да се използват в среди по подразбиране или за разработка.

Когато всичко това се комбинира – надеждна многофакторна автентификация (MFA), добре разработени политики за условен достъп, защита на устройства с Windows 11 чрез Intune, стабилно управление на самоличността и модел на разрешения с минимални привилегии – се изгражда модерен, базиран на самоличността периметър, който далеч надхвърля простите пароли и традиционната мрежова защитна стена. Потребителското изживяване е подобрено (с по-малко пароли за запомняне и повече еднократно влизане) и същевременно рискът от компрометиране е драстично намален, дори срещу напреднали фишинг атаки и атаки за кражба на токени.

Ръководство за сигурност на Windows 11 за фирми
Свързана статия:
Пълно ръководство за сигурност в Windows 11 за фирми