Как проверяются права доступа пользователя к ресурсам в ОС Windows

Обновлено: 21.11.2024

На этой странице описывается, как работает система управления идентификацией и доступом (IAM) Google Cloud и как ее можно использовать для управления доступом в Google Cloud.

IAM позволяет предоставлять детальный доступ к определенным ресурсам Google Cloud и помогает предотвратить доступ к другим ресурсам. IAM позволяет вам принять принцип безопасности с наименьшими привилегиями, согласно которому ни у кого не должно быть больше разрешений, чем им действительно нужно.

Как работает IAM

С помощью IAM вы управляете контролем доступа, определяя, кто (удостоверение) имеет какой доступ (роль) для какого ресурса. Например, экземпляры виртуальных машин Compute Engine, кластеры Google Kubernetes Engine (GKE) и корзины Cloud Storage — все это ресурсы Google Cloud. Организации, папки и проекты, которые вы используете для организации своих ресурсов, также являются ресурсами.

В IAM разрешение на доступ к ресурсу не предоставляется напрямую конечному пользователю. Вместо этого разрешения группируются в роли, а роли предоставляются прошедшим проверку подлинности участникам. (Раньше IAM часто называл принципалов участниками. В некоторых API до сих пор используется этот термин.)

Политика IAM определяет и обеспечивает соблюдение ролей, которые предоставляются участникам, и эта политика привязана к ресурсу. Когда участник, прошедший проверку подлинности, пытается получить доступ к ресурсу, IAM проверяет политику ресурса, чтобы определить, разрешено ли действие.

На следующей диаграмме показано управление разрешениями в IAM.

Эта модель управления доступом состоит из трех основных частей:

Директор. Принципал может быть аккаунтом Google (для конечных пользователей), сервисным аккаунтом (для приложений и вычислительных рабочих нагрузок), группой Google, аккаунтом Google Workspace или доменом Cloud Identity, который может получить доступ к ресурсу. Личность принципала — это адрес электронной почты, связанный с пользователем, учетной записью службы или группой Google; или доменное имя, связанное с аккаунтом Google Workspace или доменом Cloud Identity.
Роль. роль – это набор разрешений. Разрешения определяют, какие операции разрешены для ресурса. Когда вы предоставляете роль участнику, вы предоставляете все разрешения, содержащиеся в этой роли.
Политика. IAM-политика – это набор привязок ролей, которые связывают одного или нескольких участников с отдельными ролями. Если вы хотите определить, кто (участник) имеет какой тип доступа (роль) к ресурсу, вы создаете политику и прикрепляете ее к ресурсу.

В остальной части этой страницы эти понятия описываются более подробно.

Концепции, связанные с идентичностью

В IAM вы предоставляете доступ принципалам. Субъекты могут быть следующих типов:

Аккаунт Google
Сервисный аккаунт
Группа Google
Аккаунт Google Workspace
Домен Cloud Identity
Все пользователи, прошедшие проверку подлинности
Все пользователи

Аккаунт Google

Сервисный аккаунт

Служебный аккаунт — это аккаунт для приложения или вычислительной рабочей нагрузки, а не для отдельного конечного пользователя. Когда вы запускаете код, размещенный в Google Cloud, код запускается от имени указанной вами учетной записи. Вы можете создать столько учетных записей служб, сколько необходимо для представления различных логических компонентов вашего приложения. Дополнительные сведения об использовании сервисного аккаунта в приложении см. в разделе Начало работы с аутентификацией.

Группа Google

Группа Google – это именованная коллекция аккаунтов Google и сервисных аккаунтов. Каждая группа Google имеет уникальный адрес электронной почты, связанный с группой. Адрес электронной почты, связанный с группой Google, можно найти, нажав О программе на главной странице любой группы Google. Дополнительную информацию о группах Google см. на главной странице групп Google.

Группы Google — это удобный способ применить политику доступа к группе пользователей. Вы можете предоставлять и изменять элементы управления доступом сразу для всей группы вместо предоставления или изменения элементов управления доступом по одному для отдельных пользователей или учетных записей служб. Вы также можете легко добавлять участников и удалять участников из группы Google вместо обновления политики IAM для добавления или удаления пользователей.

Группы Google не имеют учетных данных для входа, и вы не можете использовать группы Google для установления личности, чтобы сделать запрос на доступ к ресурсу.

Аккаунт Google Workspace

Как и группы Google, учетные записи Google Workspace нельзя использовать для установления личности, но они обеспечивают удобное управление разрешениями.

Домен Cloud Identity

Домен Cloud Identity похож на учетную запись Google Workspace, поскольку представляет собой виртуальную группу всех учетных записей Google в организации. Однако пользователи домена Cloud Identity не имеют доступа к приложениям и функциям Google Workspace. Дополнительную информацию см. в разделе Об Cloud Identity.

Все пользователи, прошедшие проверку подлинности

Значение allAuthenticatedUsers — это специальный идентификатор, представляющий все сервисные аккаунты и всех пользователей в Интернете, прошедших аутентификацию с помощью аккаунта Google. Этот идентификатор включает учетные записи, которые не связаны с учетной записью Google Workspace или доменом Cloud Identity, например личные учетные записи Gmail. Пользователи, не прошедшие проверку подлинности, например анонимные посетители, не учитываются.

Некоторые типы ресурсов не поддерживают этот основной тип.

Все пользователи

Значение allUsers — это специальный идентификатор, представляющий всех, кто находится в Интернете, включая пользователей, прошедших и не прошедших проверку подлинности.

Некоторые типы ресурсов не поддерживают этот основной тип.

Концепции, связанные с управлением доступом

Когда участник, прошедший проверку подлинности, пытается получить доступ к ресурсу, IAM проверяет политику IAM ресурса, чтобы определить, разрешено ли действие.

В этом разделе описываются объекты и концепции, задействованные в процессе авторизации.

Ресурс

Если пользователю нужен доступ к определенному ресурсу Google Cloud, вы можете предоставить пользователю роль для этого ресурса. Некоторыми примерами ресурсов являются проекты, экземпляры Compute Engine и сегменты Cloud Storage.

Некоторые сервисы поддерживают предоставление разрешений IAM с большей детализацией, чем на уровне проекта. Например, вы можете предоставить роль администратора хранилища ( roles/storage.admin ) пользователю для определенного сегмента Cloud Storage или вы можете предоставить роль администратора вычислительного экземпляра ( roles/compute.instanceAdmin ) пользователю для определенного вычислительного сегмента. Экземпляр двигателя.

В других случаях вы можете предоставить разрешения IAM на уровне проекта. Затем разрешения наследуются всеми ресурсами в этом проекте. Например, чтобы предоставить доступ ко всем сегментам Cloud Storage в проекте, предоставьте доступ к проекту, а не к каждому отдельному сегменту. Или, чтобы предоставить доступ ко всем экземплярам Compute Engine в проекте, предоставьте доступ к проекту, а не к каждому отдельному экземпляру.

Информацию о том, какие роли и какие ресурсы можно назначать, см. в разделе Общие сведения о ролях и в столбце Минимальный ресурс для данной роли.

Разрешения

Разрешения определяют, какие операции разрешены для ресурса. В мире IAM разрешения представлены в виде службы. ресурс . глагол , например pubsub.subscriptions.consume .

Разрешения часто полностью соответствуют методам REST API. То есть у каждой службы Google Cloud есть связанный набор разрешений для каждого метода REST API, который она предоставляет. Вызывающему объекту этого метода нужны эти разрешения для вызова этого метода. Например, если вы используете Pub/Sub и вам нужно вызвать метод Topics.publish(), у вас должно быть разрешение pubsub.topics.publish для этой темы.

Вы не предоставляете разрешения пользователям напрямую. Вместо этого вы определяете роли, которые содержат соответствующие разрешения, а затем предоставляете эти роли пользователю. Список всех доступных разрешений и ролей, которые их содержат, см. в справочнике по разрешениям.

Роли

Роль – это набор разрешений. Вы не можете предоставить разрешение пользователю напрямую. Вместо этого вы предоставляете им роль. Когда вы предоставляете роль пользователю, вы предоставляете ему все разрешения, содержащиеся в этой роли.

В IAM существует несколько видов ролей:

Базовые роли: роли, исторически доступные в Google Cloud Console. Этими ролями являются Владелец, Редактор и Наблюдатель.

Предопределенные роли. Роли, обеспечивающие более детальное управление доступом, чем базовые роли. Например, предопределенная роль Pub/Sub Publisher ( roles/pubsub.publisher ) предоставляет доступ к только публикации сообщений в теме Pub/Sub.

Пользовательские роли: роли, которые вы создаете для адаптации разрешений к потребностям вашей организации, когда предопределенные роли не соответствуют вашим потребностям.

Дополнительную информацию о ролях см. в следующих ресурсах:

Чтобы узнать, как назначить роль пользователю, см. статью Предоставление, изменение и отзыв доступа.
Информацию о доступных предопределенных ролях IAM см. в разделе Общие сведения о ролях.
Информацию о настраиваемых ролях см. в разделах Общие сведения о настраиваемых ролях и Создание настраиваемых ролей и управление ими.

IAM-политика

Вы можете предоставить пользователям роли, создав политику IAM, которая представляет собой набор утверждений, определяющих, кто имеет какой тип доступа. Политика прикрепляется к ресурсу и используется для обеспечения контроля доступа при каждом доступе к этому ресурсу.

IAM-политика представлена объектом IAM-политики. Объект IAM-политики состоит из списка привязок ролей. Привязка роли привязывает список субъектов к роли.

role : роль, которую вы хотите предоставить участнику. Роль указывается в виде roles/service . имя_роли . Например, Cloud Storage предоставляет роли roles/storage.objectAdmin , roles/storage.objectCreator и roles/storage.objectViewer , среди прочих.

В следующем фрагменте кода показана структура IAM-политики.

IAM и API политик

IAM предоставляет набор методов, которые можно использовать для создания и управления политиками контроля доступа к ресурсам Google Cloud. Эти методы предоставляются службами, поддерживающими IAM. Например, методы IAM предоставляются API Resource Manager, Pub/Sub и Cloud Life Sciences, и это лишь некоторые из них.

setIamPolicy(): устанавливает политики для ваших ресурсов.
getIamPolicy(): получает ранее установленную политику.
testIamPermissions(): проверяет, есть ли у вызывающего абонента указанные разрешения для ресурса.

Справочные разделы по API для этих методов можно найти в документации каждой службы, поддерживающей IAM.

Иерархия ресурсов

Ресурсы Google Cloud организованы иерархически:

Организация — это корневой узел в иерархии.
Папки являются дочерними элементами организации.
Проекты являются дочерними элементами организации или папки.
Ресурсы для каждой службы являются потомками проектов.

Каждый ресурс имеет только одного родителя. Дополнительные сведения см. в иерархии ресурсов Resource Manager.

На следующей диаграмме показан пример иерархии ресурсов Google Cloud.

Можно задать IAM-политику на любом уровне иерархии ресурсов: на уровне организации, на уровне папки, на уровне проекта или на уровне ресурса. Ресурсы наследуют политики всех своих родительских ресурсов. Эффективная политика для ресурса — это объединение политики, установленной для этого ресурса, и политик, унаследованных от более высоких уровней иерархии.

Это наследование политики является транзитивным; другими словами, ресурсы наследуют политики от проекта, которые наследуют политики от папок, которые наследуют политики от организации. Поэтому политики на уровне организации также применяются на уровне ресурсов.

Политики для дочерних ресурсов наследуются от политик для их родительских ресурсов. Например, если вы предоставляете пользователю роль редактора для проекта и предоставляете роль наблюдателя тому же пользователю для дочернего ресурса, то пользователь по-прежнему имеет право на роль редактора для дочернего ресурса. Если вы измените иерархию ресурсов, наследование политики также изменится. Например, перемещение проекта в организацию приводит к тому, что проект наследует политику IAM организации.

Поддержка IAM для сервисов Google Cloud

При использовании IAM каждый метод API во всех сервисах Google Cloud проверяется, чтобы убедиться, что учетная запись, отправляющая запрос API, имеет соответствующее разрешение на использование ресурса.

Облачные сервисы Google предлагают предопределенные роли, обеспечивающие детальный контроль доступа. Например, Compute Engine предлагает такие роли, как администратор вычислительного экземпляра и администратор вычислительной сети, а App Engine предлагает такие роли, как администратор App Engine и администратор службы App Engine.

Предопределенные роли доступны для большинства сервисов Google Cloud. Подробнее см. в списке всех предопределенных ролей. Если вам нужен еще больший контроль над разрешениями, рассмотрите возможность создания пользовательской роли.

Вы можете предоставить пользователям определенные роли для доступа к ресурсам с точностью более тонкой, чем на уровне проекта. Например, вы можете создать политику управления доступом к IAM, которая предоставляет пользователю роль подписчика для определенной темы Pub/Sub. В списке всех предопределенных ролей показан тип ресурса самого низкого уровня или наиболее детализированного типа, который принимает каждую роль.

Модель согласованности для IAM API

Когда вы читаете данные из IAM API, каждое чтение в конечном итоге становится согласованным. Другими словами, если вы записываете данные с помощью IAM API, а затем сразу читаете эти данные, операция чтения может вернуть более старую версию данных. После небольшой задержки вы можете прочитать новую версию данных. Эта задержка обычно измеряется в секундах, а не в минутах.

Наоборот, запись данных в IAM API осуществляется последовательно. Другими словами, операции записи всегда выполняются в том порядке, в котором они были получены.

Эти модели согласованности влияют на работу IAM API. Например, если вы создаете учетную запись службы, а затем сразу же ссылаетесь на эту учетную запись службы в другом запросе, IAM API может сказать, что учетная запись службы не может быть найдена. Такое поведение возникает из-за того, что операции чтения в конечном счете непротиворечивы; может пройти некоторое время, прежде чем новый сервисный аккаунт станет видимым.

Чтобы справиться с таким поведением, ваше приложение может повторить запрос с усеченной экспоненциальной задержкой.

Что дальше

Список доступных ролей IAM см. в разделе Общие сведения о ролях.
Чтобы получить помощь в выборе наиболее подходящих предопределенных ролей, ознакомьтесь со статьей Выбор предопределенных ролей.
Чтобы узнать о создании ролей для ваших конкретных нужд, прочитайте статью Общие сведения о настраиваемых ролях.
Инструкции о том, как предоставлять, изменять и отзывать роли IAM участникам, см. в разделе Предоставление, изменение и отзыв доступа к ресурсам.
Изучите инструменты анализа политик, которые помогут вам понимать политики и управлять ими, чтобы заранее улучшать конфигурацию безопасности.
Чтобы узнать, как защитить ваши приложения, см. раздел Обзор прокси-сервера с идентификацией.

Попробуйте сами

Если вы новичок в Google Cloud, создайте учетную запись, чтобы оценить, как наши продукты работают в реальных сценариях. Новые клиенты также получают бесплатные кредиты в размере 300 долларов США для запуска, тестирования и развертывания рабочих нагрузок.

Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

В этом разделе для ИТ-специалистов описывается управление доступом в Windows, то есть процесс авторизации пользователей, групп и компьютеров для доступа к объектам в сети или на компьютере. Ключевыми понятиями, из которых состоит управление доступом, являются разрешения, владение объектами, наследование разрешений, права пользователей и аудит объектов.

Описание функции

Компьютеры с поддерживаемой версией Windows могут контролировать использование системных и сетевых ресурсов с помощью взаимосвязанных механизмов проверки подлинности и авторизации. После аутентификации пользователя операционная система Windows использует встроенные технологии авторизации и управления доступом для реализации второго этапа защиты ресурсов: определения наличия у аутентифицированного пользователя правильных разрешений на доступ к ресурсу.

Общие ресурсы доступны пользователям и группам, не являющимся владельцем ресурса, и их необходимо защищать от несанкционированного использования. В модели управления доступом пользователи и группы (также называемые субъектами безопасности) представлены уникальными идентификаторами безопасности (SID). Им назначаются права и разрешения, которые информируют операционную систему о том, что может делать каждый пользователь и группа. У каждого ресурса есть владелец, который предоставляет разрешения субъектам безопасности. Во время проверки управления доступом эти разрешения проверяются, чтобы определить, какие участники безопасности могут получить доступ к ресурсу и как они могут получить к нему доступ.

Субъекты безопасности выполняют действия (включая чтение, запись, изменение или полный доступ) над объектами. К объектам относятся файлы, папки, принтеры, ключи реестра и объекты доменных служб Active Directory (AD DS). Общие ресурсы используют списки управления доступом (ACL) для назначения разрешений. Это позволяет менеджерам ресурсов применять контроль доступа следующими способами:

Запретить доступ неавторизованным пользователям и группам

Установите четко определенные ограничения на доступ, предоставляемый авторизованным пользователям и группам

Владельцы объектов обычно предоставляют разрешения группам безопасности, а не отдельным пользователям. Пользователи и компьютеры, добавляемые в существующие группы, получают разрешения этой группы. Если объект (например, папка) может содержать другие объекты (например, вложенные папки и файлы), он называется контейнером. В иерархии объектов отношение между контейнером и его содержимым выражается обращением к контейнеру как к родителю. Объект в контейнере называется дочерним, и дочерний объект наследует параметры управления доступом родителя. Владельцы объектов часто определяют разрешения для объектов-контейнеров, а не для отдельных дочерних объектов, чтобы упростить управление контролем доступа.

Контроль учетных записей пользователей (UAC) — это фундаментальный компонент общей концепции безопасности Microsoft. UAC помогает смягчить воздействие вредоносного ПО.

Процесс и взаимодействие UAC

Каждое приложение, которому требуется токен доступа администратора, должно запрашивать согласие. Единственным исключением являются отношения, существующие между родительским и дочерним процессами. Дочерние процессы наследуют маркер доступа пользователя от родительского процесса. Однако и родительский, и дочерний процессы должны иметь одинаковый уровень целостности. Windows защищает процессы, помечая их уровни целостности. Уровни честности являются мерой доверия. Приложение с «высокой» целостностью — это приложение, которое выполняет задачи, изменяющие системные данные, например приложение для создания разделов диска, а приложение с «низкой» целостностью — это приложение, выполняющее задачи, которые потенциально могут скомпрометировать операционную систему, например веб-браузер. Приложения с более низким уровнем целостности не могут изменять данные в приложениях с более высоким уровнем целостности. Когда обычный пользователь пытается запустить приложение, для которого требуется маркер доступа администратора, UAC требует, чтобы пользователь предоставил действительные учетные данные администратора.

Чтобы лучше понять, как происходит этот процесс, давайте рассмотрим процесс входа в систему Windows.

Процесс входа

Ниже показано, чем процесс входа в систему для администратора отличается от процесса входа в систему для обычного пользователя.

По умолчанию обычные пользователи и администраторы получают доступ к ресурсам и запускают приложения в контексте безопасности обычных пользователей. Когда пользователь входит в систему на компьютере, система создает маркер доступа для этого пользователя. Маркер доступа содержит информацию об уровне доступа, предоставленном пользователю, включая конкретные идентификаторы безопасности (SID) и привилегии Windows.

Когда администратор входит в систему, для пользователя создаются два отдельных маркера доступа: стандартный маркер доступа пользователя и маркер доступа администратора. Маркер доступа стандартного пользователя содержит ту же информацию о пользователе, что и маркер доступа администратора, но административные привилегии Windows и SID удалены. Маркер доступа стандартного пользователя используется для запуска приложений, которые не выполняют административные задачи (стандартные пользовательские приложения). Затем маркер доступа стандартного пользователя используется для отображения рабочего стола (explorer.exe). Explorer.exe — это родительский процесс, от которого все другие инициированные пользователем процессы наследуют свои маркеры доступа. В результате все приложения запускаются от имени обычного пользователя, если пользователь не предоставит согласие или учетные данные для утверждения приложения для использования маркера полного административного доступа.

Пользователь, являющийся членом группы администраторов, может входить в систему, просматривать веб-страницы и читать электронную почту, используя маркер доступа стандартного пользователя. Когда администратору необходимо выполнить задачу, для которой требуется маркер доступа администратора, Windows 10 или Windows 11 автоматически запрашивает у пользователя подтверждение. Этот запрос называется запросом на повышение прав, и его поведение можно настроить с помощью оснастки «Локальная политика безопасности» (Secpol.msc) или групповой политики. Дополнительные сведения см. в разделе Параметры политики безопасности контроля учетных записей.

Пользовательский интерфейс UAC

Когда контроль учетных записей включен, взаимодействие с обычными пользователями отличается от взаимодействия с администраторами в режиме одобрения администратором. Рекомендуемый и более безопасный метод запуска Windows 10 или Windows 11 — сделать вашу основную учетную запись пользователя стандартной учетной записью пользователя. Запуск от имени обычного пользователя помогает максимально повысить безопасность управляемой среды. Благодаря встроенному компоненту повышения прав UAC обычные пользователи могут легко выполнять административные задачи, вводя действительные учетные данные для учетной записи локального администратора. По умолчанию встроенным компонентом повышения прав UAC для обычных пользователей является запрос учетных данных.

Альтернативой запуску от имени обычного пользователя является запуск от имени администратора в режиме одобрения администратором. Благодаря встроенному компоненту повышения прав UAC члены локальной группы администраторов могут легко выполнять административные задачи, предоставив одобрение. Встроенный по умолчанию компонент повышения прав UAC для учетной записи администратора в режиме одобрения администратором называется запросом согласия.

Запросы согласия и учетных данных

При включенном UAC Windows 10 или Windows 11 запрашивает согласие или запрашивает учетные данные действительной учетной записи локального администратора перед запуском программы или задачи, требующей маркера полного доступа администратора. Это приглашение гарантирует, что никакое вредоносное программное обеспечение не может быть установлено без вывода сообщений.

Запрос согласия

Запрос согласия отображается, когда пользователь пытается выполнить задачу, для которой требуется маркер административного доступа пользователя. Ниже приведен пример запроса согласия UAC.

Запрос учетных данных

Запрос учетных данных отображается, когда обычный пользователь пытается выполнить задачу, для которой требуется маркер административного доступа пользователя. От администраторов также может потребоваться предоставить свои учетные данные, установив для параметра политики Контроль учетных записей: поведение запроса на повышение прав для администраторов в режиме одобрения администратором значение Запрашивать учетные данные.

Ниже приведен пример запроса учетных данных UAC.

Запросы на повышение прав UAC

Запросы на повышение прав UAC имеют цветовую кодировку для конкретных приложений, что позволяет сразу определить потенциальную угрозу безопасности приложения. Когда приложение пытается запуститься с маркером полного доступа администратора, Windows 10 или Windows 11 сначала анализирует исполняемый файл, чтобы определить его издателя. Сначала приложения делятся на три категории в зависимости от издателя файла: Windows 10 или Windows 11, проверенный издатель (подписанный) и непроверенный издатель (неподписанный). На следующей диаграмме показано, как Windows определяет, какой запрос на повышение прав цвета должен быть представлен пользователю.

Цветовая кодировка подсказки о высоте выглядит следующим образом:

Красный фон с красным значком щита: приложение заблокировано групповой политикой или принадлежит заблокированному издателю.
Синий фон с сине-золотым значком щита. Приложение представляет собой административное приложение для Windows 10 и Windows 11, например элемент панели управления.
Синий фон со значком синего щита: приложение подписано с использованием Authenticode и является доверенным для локального компьютера.
Желтый фон с желтым значком щита: приложение не подписано или подписано, но еще не является доверенным для локального компьютера.

Значок щита

Некоторые элементы панели управления, такие как свойства даты и времени, содержат комбинацию действий администратора и стандартных пользователей. Обычные пользователи могут просматривать часы и изменять часовой пояс, но для изменения локального системного времени требуется маркер полного доступа администратора. Ниже приведен снимок экрана элемента панели управления «Свойства даты и времени».

Значок щита на кнопке "Изменить дату и время" указывает на то, что для процесса требуется токен полного доступа администратора, и будет отображаться запрос на повышение прав UAC.

Защита запроса на повышение прав

Процесс повышения прав дополнительно защищен за счет направления приглашения на защищенный рабочий стол. Запросы согласия и учетных данных отображаются на защищенном рабочем столе по умолчанию в Windows 10 и Windows 11. Только процессы Windows могут получить доступ к защищенному рабочему столу. Для более высокого уровня безопасности мы рекомендуем оставить включенным контроль учетных записей: переключаться на безопасный рабочий стол при запросе параметра политики повышения прав.

Когда исполняемый файл запрашивает повышение прав, интерактивный рабочий стол, также называемый рабочим столом пользователя, переключается на безопасный рабочий стол. Защищенный рабочий стол затемняет рабочий стол пользователя и отображает запрос на повышение прав, на который необходимо ответить, прежде чем продолжить. Когда пользователь нажимает «Да» или «Нет», рабочий стол снова переключается на рабочий стол пользователя.

Вредоносное ПО может имитировать защищенный рабочий стол, но если для параметра политики Контроль учетных записей: поведение запроса на повышение прав для администраторов в режиме одобрения администратором задано значение Запрашивать согласие, вредоносное ПО не получает повышение прав, если пользователь щелкает Да на подражание. Если для параметра политики задано значение Запрашивать учетные данные, вредоносное ПО, имитирующее запрос учетных данных, может получить учетные данные от пользователя. Однако вредоносная программа не получает повышенных привилегий, а в системе есть другие средства защиты, которые не позволяют вредоносным программам получить контроль над пользовательским интерфейсом даже с помощью собранного пароля.

Хотя вредоносное ПО может имитировать безопасный рабочий стол, эта проблема не может возникнуть, если пользователь предварительно не установил вредоносное ПО на ПК. Поскольку процессы, требующие маркера доступа администратора, не могут устанавливаться автоматически, когда включен контроль учетных записей, пользователь должен явным образом дать согласие, нажав Да или предоставив учетные данные администратора. Конкретное поведение запроса на повышение прав UAC зависит от групповой политики.

Групповой доступ в Центре администрирования Windows не поддерживается в средах рабочих групп или в доменах, не являющихся доверенными.

Определения ролей доступа к шлюзу

Существует две роли для доступа к службе шлюза центра администрирования Windows:

Пользователи шлюза могут подключаться к службе шлюза Центра администрирования Windows для управления серверами через этот шлюз, но они не могут изменять права доступа или механизм проверки подлинности, используемый для аутентификации на шлюзе.

Администраторы шлюза могут указать, кто будет получать доступ, а также как пользователи будут проходить аутентификацию на шлюзе. Только администраторы шлюза могут просматривать и настраивать параметры доступа в Windows Admin Center. Локальные администраторы на компьютере шлюза всегда являются администраторами службы шлюза Центра администрирования Windows.

Существует также дополнительная роль, связанная с управлением CredSSP:

Администраторы CredSSP Центра администрирования Windows зарегистрированы в конечной точке CredSSP Центра администрирования Windows и имеют разрешения на выполнение предопределенных операций CredSSP. Эта группа особенно полезна для установки Центра администрирования Windows в режиме рабочего стола, когда эти разрешения по умолчанию предоставляются только учетной записи пользователя, установившего Центр администрирования Windows.

Доступ к шлюзу не означает доступ к управляемым серверам, видимым шлюзом. Для управления целевым сервером подключающийся пользователь должен использовать учетные данные (либо с помощью своих переданных учетных данных Windows, либо с помощью учетных данных, предоставленных в сеансе центра администрирования Windows с помощью действия «Управление как»), которые имеют административный доступ к этому целевому серверу.

Active Directory или группы локальных компьютеров

По умолчанию Active Directory или локальные группы компьютеров используются для управления доступом к шлюзу. Если у вас есть домен Active Directory, вы можете управлять доступом пользователей и администраторов шлюза из интерфейса Windows Admin Center.

На вкладке "Пользователи" вы можете указать, кто может получить доступ к Центру администрирования Windows в качестве пользователя шлюза. По умолчанию, и если вы не укажете группу безопасности, любой пользователь, обращающийся к URL-адресу шлюза, имеет доступ. После того как вы добавите одну или несколько групп безопасности в список пользователей, доступ будет ограничен членами этих групп.

Если вы не используете домен Active Directory в своей среде, доступ контролируется локальными группами пользователей и администраторов на компьютере шлюза Windows Admin Center.

Аутентификация с помощью смарт-карты

Вы можете применить проверку подлинности с помощью смарт-карт, указав дополнительную обязательную группу для групп безопасности на основе смарт-карт. После добавления группы безопасности на основе смарт-карт пользователь может получить доступ к службе Центра администрирования Windows, только если он является членом какой-либо группы безопасности И группы смарт-карт, включенной в список пользователей.

На вкладке "Администраторы" вы можете указать, кто может получить доступ к Центру администрирования Windows в качестве администратора шлюза. Группа локальных администраторов на компьютере всегда будет иметь полный доступ администратора и не может быть удалена из списка. Добавляя группы безопасности, вы даете членам этих групп право изменять параметры шлюза Windows Admin Center. Список администраторов поддерживает аутентификацию с помощью смарт-карт так же, как и список пользователей: с условием И для группы безопасности и группы смарт-карт.

Azure Active Directory

Если ваша организация использует Azure Active Directory (Azure AD), вы можете добавить дополнительный уровень безопасности в Центр администрирования Windows, требуя проверки подлинности Azure AD для доступа к шлюзу. Чтобы получить доступ к центру администрирования Windows, учетная запись Windows пользователя также должна иметь доступ к серверу шлюза (даже если используется проверка подлинности Azure AD). При использовании Azure AD вы будете управлять разрешениями на доступ пользователей и администраторов Центра администрирования Windows с портала Azure, а не из пользовательского интерфейса Центра администрирования Windows.

Доступ к Центру администрирования Windows при включенной проверке подлинности Azure AD

В зависимости от используемого браузера некоторые пользователи, получающие доступ к Центру администрирования Windows с настроенной проверкой подлинности Azure AD, получат дополнительный запрос от браузера, в котором им необходимо указать учетные данные своей учетной записи Windows для компьютера, на котором установлен Центр администрирования Windows. После ввода этой информации пользователи получат дополнительный запрос проверки подлинности Azure Active Directory, для которого требуются учетные данные учетной записи Azure, которой предоставлен доступ в приложении Azure AD в Azure.

Пользователям, чьи учетные записи Windows имеют права администратора на компьютере шлюза, не будет предлагаться пройти аутентификацию Azure AD.

Настройка проверки подлинности Azure Active Directory для Windows Admin Center Preview

Перейдите в раздел "Параметры центра администрирования Windows" > "Доступ" и с помощью переключателя включите параметр "Использовать Azure Active Directory для добавления уровня безопасности к шлюзу". Если вы не зарегистрировали шлюз в Azure, вам будет предложено сделать это сейчас.

По умолчанию все члены арендатора Azure AD имеют пользовательский доступ к службе шлюза Windows Admin Center. Только локальные администраторы на компьютере шлюза имеют административный доступ к шлюзу центра администрирования Windows. Обратите внимание, что права локальных администраторов на компьютере шлюза не могут быть ограничены — локальные администраторы могут делать все, что угодно, независимо от того, используется ли Azure AD для аутентификации.

Если вы хотите предоставить определенным пользователям или группам Azure AD пользователю шлюза или администратору шлюза доступ к службе Центра администрирования Windows, необходимо сделать следующее:

Перейдите в приложение Azure AD центра администрирования Windows на портале Azure, используя гиперссылку, указанную в параметрах доступа. Обратите внимание, что эта гиперссылка доступна, только если включена проверка подлинности Azure Active Directory.
- Вы также можете найти свое приложение на портале Azure, выбрав Azure Active Directory > Корпоративные приложения > Все приложения и выполнив поиск WindowsAdminCenter (приложение Azure AD будет называться WindowsAdminCenter-). Если вы не получили никаких результатов поиска, убедитесь, что для параметра «Показать» установлено значение «Все приложения», а для состояния приложения установлено значение «Любое», и выберите «Применить», а затем попробуйте выполнить поиск. Найдя приложение, перейдите в раздел Пользователи и группы.
На вкладке "Свойства" установите для параметра "Требуется назначение пользователя" значение "Да". После этого только участники, указанные на вкладке "Пользователи и группы", смогут получить доступ к шлюзу центра администрирования Windows.
На вкладке "Пользователи и группы" выберите "Добавить пользователя". Вы должны назначить роль пользователя или администратора шлюза для каждого добавленного пользователя/группы.

После включения проверки подлинности Azure AD служба шлюза перезапускается, и вам необходимо обновить браузер. Вы можете обновить доступ пользователей к приложению Azure AD для малого и среднего бизнеса на портале Azure в любое время.

Пользователям будет предложено войти в систему, используя свою учетную запись Azure Active Directory, когда они попытаются получить доступ к URL-адресу шлюза центра администрирования Windows. Помните, что для доступа к Центру администрирования Windows пользователи также должны быть членами локальной группы пользователей на сервере шлюза.

Пользователи и администраторы могут просматривать свою текущую учетную запись, вошедшую в систему, а также выходить из этой учетной записи Azure AD на вкладке «Учетная запись» в настройках центра администрирования Windows.

Настройка аутентификации Azure Active Directory для Windows Admin Center

Чтобы настроить аутентификацию Azure AD, сначала необходимо зарегистрировать шлюз в Azure (это нужно сделать только один раз для шлюза Windows Admin Center). На этом шаге создается приложение Azure AD, из которого можно управлять доступом пользователей и администраторов шлюза.

Перейдите к приложению Azure AD для малого и среднего бизнеса на портале Azure.
- Если вы выберете Изменить контроль доступа, а затем выберите Azure Active Directory в параметрах доступа Windows Admin Center, вы сможете использовать гиперссылку, указанную в пользовательском интерфейсе, для доступа к приложению Azure AD на портале Azure. Эта гиперссылка также доступна в настройках доступа после того, как вы нажмете «Сохранить» и выберете Azure AD в качестве поставщика удостоверений управления доступом.
- Вы также можете найти свое приложение на портале Azure, выбрав Azure Active Directory > Корпоративные приложения > Все приложения и выполнив поиск SME (приложение Azure AD будет называться SME-). Если вы не получили никаких результатов поиска, убедитесь, что для параметра «Показать» установлено значение «Все приложения», а для состояния приложения установлено значение «Любое», и выберите «Применить», а затем попробуйте выполнить поиск. Найдя приложение, перейдите в раздел Пользователи и группы.
На вкладке "Свойства" установите для параметра "Требуется назначение пользователя" значение "Да". После этого только участники, указанные на вкладке "Пользователи и группы", смогут получить доступ к шлюзу центра администрирования Windows.
На вкладке "Пользователи и группы" выберите "Добавить пользователя". Вы должны назначить роль пользователя или администратора шлюза для каждого добавленного пользователя/группы.

После сохранения элемента управления доступом Azure AD на панели "Изменить контроль доступа" служба шлюза перезапускается, и вам необходимо обновить браузер. Вы можете в любое время обновить доступ пользователей к приложению Windows Admin Center Azure AD на портале Azure.

Используя вкладку Azure общих настроек Центра администрирования Windows, пользователи и администраторы могут просматривать свои текущие учетные записи, а также выходить из этой учетной записи Azure AD.

Условный доступ и многофакторная аутентификация

Одним из преимуществ использования Azure AD в качестве дополнительного уровня безопасности для управления доступом к шлюзу центра администрирования Windows является то, что вы можете использовать мощные функции безопасности Azure AD, такие как условный доступ и многофакторная проверка подлинности.

Настроить единый вход

Единый вход при развертывании в качестве службы на Windows Server

При установке Центра администрирования Windows в Windows 10 он готов к использованию единого входа. Однако если вы собираетесь использовать Windows Admin Center на Windows Server, вам необходимо настроить некоторую форму делегирования Kerberos в вашей среде, прежде чем вы сможете использовать единый вход. Делегирование настраивает компьютер шлюза как доверенный для делегирования целевому узлу.

Чтобы удалить эту связь, запустите следующий командлет:

Управление доступом на основе ролей (RBAC)

Управление доступом на основе ролей позволяет предоставлять пользователям ограниченный доступ к компьютеру вместо того, чтобы делать их полноправными локальными администраторами. Узнайте больше об управлении доступом на основе ролей и доступных ролях.

Настройка RBAC состоит из двух шагов: включение поддержки на целевых компьютерах и назначение пользователям соответствующих ролей.

Убедитесь, что у вас есть права локального администратора на компьютерах, на которых вы настраиваете поддержку управления доступом на основе ролей.

Применить управление доступом на основе ролей к одному компьютеру

Модель развертывания с одним компьютером идеально подходит для простых сред с несколькими компьютерами для управления. Настройка машины с поддержкой управления доступом на основе ролей приведет к следующим изменениям:

Модули PowerShell с функциями, необходимыми для Центра администрирования Windows, будут установлены на системный диск в папку C:\Program Files\WindowsPowerShell\Modules. Все модули будут начинаться с Microsoft.Sme
Desired State Configuration запустит однократную настройку для настройки конечной точки Just Enough Administration на компьютере с именем Microsoft.Sme.PowerShell. Эта конечная точка определяет три роли, используемые Windows Admin Center, и будет работать как временный локальный администратор, когда пользователь подключается к ней.
Будут созданы три новые локальные группы для управления доступом пользователей к тем или иным ролям:
- Администраторы центра администрирования Windows
- Администраторы Hyper-V Центра администрирования Windows
- Читатели Центра администрирования Windows
Управление доступом на основе ролей не поддерживается для управления кластером (т. е. функции, зависящие от RBAC, такие как CredSSP, не будут работать).

Чтобы включить поддержку управления доступом на основе ролей на одном компьютере, выполните следующие действия:
1. Откройте Центр администрирования Windows и подключитесь к компьютеру, который вы хотите настроить с помощью управления доступом на основе ролей, используя учетную запись с правами локального администратора на целевом компьютере.
2. В инструменте «Обзор» выберите «Настройки» > «Управление доступом на основе ролей».
3. Нажмите «Применить» внизу страницы, чтобы включить поддержку управления доступом на основе ролей на целевом компьютере. Процесс приложения включает копирование сценариев PowerShell и вызов конфигурации (с использованием конфигурации желаемого состояния PowerShell) на целевой машине. Это может занять до 10 минут и приведет к перезапуску WinRM. Это временно отключит пользователей Центра администрирования Windows, PowerShell и WMI.
4. Обновите страницу, чтобы проверить статус управления доступом на основе ролей. Когда он будет готов к использованию, его статус изменится на Применено.
После применения конфигурации вы можете назначить пользователям роли:
1. Откройте инструмент "Локальные пользователи и группы" и перейдите на вкладку "Группы".
2. Выберите группу читателей Центра администрирования Windows.
3. На панели сведений внизу выберите Добавить пользователя и введите имя пользователя или группы безопасности, которые должны иметь доступ только для чтения к серверу через Центр администрирования Windows. Пользователи и группы могут находиться на локальном компьютере или в вашем домене Active Directory.
4. Повторите шаги 2–3 для групп администраторов Windows Admin Center Hyper-V и администраторов Windows Admin Center.
Вы также можете единообразно заполнить эти группы в своем домене, настроив объект групповой политики с параметром политики групп с ограниченным доступом.

Применить управление доступом на основе ролей к нескольким компьютерам

В крупном предприятии вы можете использовать имеющиеся у вас инструменты автоматизации, чтобы внедрить функцию управления доступом на основе ролей на свои компьютеры, загрузив пакет конфигурации со шлюза Windows Admin Center. Пакет конфигурации предназначен для использования с PowerShell Desired State Configuration, но вы можете адаптировать его для работы с вашим предпочтительным решением для автоматизации.

Загрузить конфигурацию управления доступом на основе ролей

Чтобы загрузить пакет конфигурации управления доступом на основе ролей, вам потребуется доступ к центру администрирования Windows и командная строка PowerShell.

Если вы используете шлюз Центра администрирования Windows в сервисном режиме на Windows Server, используйте следующую команду для загрузки пакета конфигурации. Обязательно обновите адрес шлюза, указав правильный для вашей среды.

Если вы используете шлюз Центра администрирования Windows на компьютере с Windows 10, вместо этого выполните следующую команду:
- InstallJeaFeatures.ps1
- JustEnoughAdministration (каталог)
- Модули (каталог)
  - Microsoft.SME.* (каталоги)
  - WindowsAdminCenter.Jea (каталог)
  Чтобы настроить поддержку управления доступом на основе ролей на узле, необходимо выполнить следующие действия:
  1. Скопируйте модули JustEnoughAdministration, Microsoft.SME.* и WindowsAdminCenter.Jea в каталог модулей PowerShell на целевом компьютере. Обычно он находится в папке C:\Program Files\WindowsPowerShell\Modules .
  2. Обновите файл InstallJeaFeature.ps1, чтобы он соответствовал желаемой конфигурации конечной точки RBAC.
  3. Запустите InstallJeaFeature.ps1, чтобы скомпилировать ресурс DSC.
  4. Разверните конфигурацию DSC на всех своих компьютерах, чтобы применить конфигурацию.
  В следующем разделе объясняется, как это сделать с помощью PowerShell Remoting.
  
  Развертывание на нескольких компьютерах
  
  Чтобы развернуть загруженную конфигурацию на несколько компьютеров, вам потребуется обновить сценарий InstallJeaFeatures.ps1, включив в него соответствующие группы безопасности для вашей среды, скопировать файлы на каждый из ваших компьютеров и вызвать сценарии конфигурации. Для этого вы можете использовать предпочитаемые инструменты автоматизации, однако в этой статье основное внимание будет уделено чистому подходу на основе PowerShell.
  
  По умолчанию сценарий конфигурации создает локальные группы безопасности на компьютере для управления доступом к каждой из ролей. Это подходит для компьютеров, присоединенных к рабочей группе и домену, но если вы развертываете в среде только для домена, вы можете захотеть напрямую связать группу безопасности домена с каждой ролью. Чтобы обновить конфигурацию для использования групп безопасности домена, откройте InstallJeaFeatures.ps1 и внесите следующие изменения:
  1. Удалите 3 ресурса группы из файла:
    1. "Группа MS-Readers-Группа"
    2. "Группа MS-Hyper-V-Administrators-Group"
    3. "Группа MS-Администраторы-Группа"