Группа авторизации доступа windows что это
Обновлено: 05.07.2024
Настройка и управление безопасностью SQL Server является важной частью построения и обслуживания среды вашего SQL Server. Безопасность SQL Server - это огромная тема, которая не может быть полностью раскрыта в одной статье. Данная статья начинает с нескольких фундаментальных вопросов безопасности SQL Server: методов авторизации SQL Server, логинов и пользователей базы данных.
Поддерживаемые методы авторизации
Имеется два различных метода авторизации для подключения к SQL Server: Windows и SQL Server.
Для авторизации Windows требуется, чтобы пользователь сначала авторизовался в Windows со своим логином и паролем. После этого он может подключиться к SQL Server, используя авторизацию Windows. То есть при условии, что их учетной записи Windows был предоставлен доступ к SQL Server через логин (подробнее о логинах ниже). Авторизация Windows тесно связана с безопасностью Windows и называется интегрированной безопасностью (Integrated Security). Авторизация Windows прекрасно работает, когда лицо является частью домена Windows.
Но бывают случаи, когда люди не могут подключиться к Windows; это имеет место при авторизации SQL. Авторизация SQL является менее безопасной, чем авторизация Windows. Для подключения к SQL Server с помощью авторизации SQL, пользователь должен указать логин и пароль при подключении. Пароль логина при авторизации SQL хранится в базе данных master. Т.к. пароль хранится в базе данных, его легче взломать. Поскольку можно сделать бэкап базы с последующим восстановлением, этот способ авторизации менее безопасен, чем при использовании авторизации Windows.
Поскольку авторизация SQL менее безопасна, чем авторизация Windows, рекомендуется при установке экземпляра SQL Server выбирать смешанный режим, если вам требуется поддержка пользователей или приложений, которые не могут подключаться к Windows. Несмотря на то, что авторизация Windows более безопасна и является рекомендуемой практикой для подключения к SQL Server, многие поставщики нестандартного прикладного программного обеспечения до сих пор не поддерживают подключение посредством авторизации Windows.
Установка SQL Server с поддержкой различных режимов авторизации
При установке SQL Server вы можете выбрать поддержку только авторизации Windows или обоих методов авторизации, которая называется смешанным режимом. В процессе установки при определении конфигурации ядра базы данных вы решаете использовать ли смешанный режим, что показано на рис.1.
Рис.1 Выбор режима авторизации
Авторизация Windows выбирается по умолчанию (красная стрелка на рис.1). Если вам требуется поддержка авторизации как Windows, так и SQL Server, вам следует выбрать вариант “Mixed Mode”. При этом становится доступным установка пароля аккаунта SA, и вам потребуется задать пароль SA. При выборе только авторизации Windows, аккаунт SA недоступен. Чтобы защитить учетную запись SA при использовании смешанного режима, вы можете отключить ее после включения.
Как определить, какие методы авторизации поддерживаются
Вы можете проверить установленный метод авторизации несколькими способами. Один из способов - использовать SQL Server Management Studio (SSMS). Для этого выполните щелчок правой кнопкой на имени экземпляра и выберите команду Properties (свойства). В моем случае окно свойств показано на рис.2.
Рис.2 Определение режима авторизации
На рис.2 показывается, что мой экземпляр поддерживает смешанный режим авторизации (красная стрелка).
Другой способ - это использовать код T-SQL. На листинге ниже представлен код для вывода режима авторизации.
Листинг 1: отображение режима авторизации
Изменение методов авторизации после установки SQL Server
Вы можете захотеть изменить установки авторизации для экземпляра SQL Server. Вы могли использовать настройки по умолчанию при установке для поддержки авторизации Windows, а затем приобрели программу, которая может подключаться к серверу только при использовании авторизации SQL Server. Или вы захотели сделать ваш экземпляр более безопасным, удалив поддержку авторизации SQL Server. Опции авторизации можно легко изменить, используя страницу свойств в SSMS, показанную на рис.2.
Если бы я захотел изменить поддержку авторизации только на Windows, все, что мне потребовалось бы сделать, это щелкнуть на кнопке “Windows authentication mode”, а затем на кнопке ОК для сохранения изменений. После изменения этого свойства, необходимо перезапустить экземпляр, чтобы изменения вступили в силу.
Логины SQL Server
Для подключения к SQL Server вы должны иметь доступ к серверу. Доступ гарантируется посредством логина. Логин также называют участником безопасности (security principal), он хранится в базе данных master. Есть одно исключение - это доступ к автономной базе данных. Пользователи автономных баз данных напрямую подключаются к базе данных без необходимости иметь логин в базе данных master. Автономные базы данных - это тема для последующих статей.
Имеется три типа логинов, которые хранятся в базе данных master: пользователь Windows, группа Windows и SQL. Давайте рассмотрим каждый из этих трех типов логинов.
Логин пользователя Windows предоставляет доступ отдельному пользователю Windows. При создании логина этого типа не требуется задавать пароль. Этот тип логина требует, чтобы пользователь сначала прошел валидацию, подключившись к домену Windows. Пароль хранится в домене Windows.
Логин SQL Server подобен логину Windows в том, что он предоставляет доступ к SQL Server для отдельного пользователя, но отличается тем, что пароль логина SQL хранится в базе данных master. Следовательно, при создании логина SQL Server требуется указывать пароль, а также некоторые другие опции, как показано на рис.3.
Рис.3 Настройка логина при авторизации SQL Server
На рис.3 показано, что для входа в SQL Server может быть применена политика паролей Windows и истечения срока действия, а также может потребовать от пользователя изменить пароль при первом входе в систему. Microsoft добавила эти новые возможности в SQL Server 2005. Для поддержки этих новых возможностей в приложениях может использоваться API NetValidatePasswordPolicy.
Последний тип логина, логин группы Windows, подобен логину Windows с незначительными отличиями. Логин группы Windows обеспечивает доступ к экземпляру SQL Server каждому логину Windows, который является членом группы. Группы Windows являются хорошим способом предоставить доступ множеству логинов Windows при наличии только одного логина SQL Server. Используя группу Windows, доступ к экземпляру SQL Server может регулироваться добавлением или удалением членов группы. Использование групп Windows помогает минимизировать усилия по обеспечению безопасности и решению проблем безопасности, связанных с логинами.
Внизу скриншота на рис.3 вы видите настройку для логина “Default Database” (база данных по умолчанию). При создании логина базой данных по умолчанию является база данных master. Вы можете поменять эту настройку на любую базу данных на сервере. Лучший вариант - установить по умолчанию базу данных, которую пользователь будет использовать при подключении к SQL Server.
Логины Windows считаются более безопасными из-за способа, каким сохраняется пароль для логина. Пароль для логина Windows сохраняется при использовании настоящего шифрования. В то время как пароль для логина SQL не шифруется, а хэшируется. Поэтому пароль SQL легче взломать. Для установки логинов и паролей Windows требуется администратор доменов, а для логинов SQL администраторы базы данных заводят логины и пароли. Использование админов доменов для управления паролями логинов обеспечивает еще один слой безопасности, обычно называемый разделением обязанностей. Разделение обязанностей по созданию и управлению логинами Windows от управления базами данных и доступа к ним обеспечивает дополнительный контроль безопасности по предоставлению доступа к данным, хранящимся на SQL Server.
Создание логина для SQL Server позволяет пользователям подключаться к серверу. Но один лишь логин не предоставляет пользователю доступ к каким-либо данным в различных базах данных на сервере. Чтобы логин мог читать и записывать данные в базу, он должен иметь доступ к тем или иным базам данных. Если требуется, для логина может быть установлен доступ к нескольким базам данных экземпляра.
Пользователи базы данных
Пользователь базы данных - это не то же самое, что и логин. Логин предоставляет пользователю или приложению возможность подключаться к экземпляру SQL Server, в то время как пользователь базы данных дает пользователю права на доступ к базе данных. В каждой базе данных, к которой логину требуется доступ, требуется определить пользователя; исключение составляет логин с правами системного администратора. Если логин имеет права сисадмина, он имеет доступ ко всем базам данных без необходимости связывать его с пользователем базы данных. Эта связь между логином и пользователем базы данных называется мэппингом пользователей. Мэппинг пользователя для логина может быть создан во время создания логина или позже для уже установленных логинов.
Создание пользователя базы данных при создании нового логина
Чтобы показать обеспечение мэппинга пользователя при создании нового логина, я создам новый логин SQL Server с именем “Red-Gate”. На скриншоте (рис.4) показано окно “Login – new”, где я определяю новый логин. Чтобы вывести это окно, я разворачиваю вкладку “Security” в дереве объектов моего экземпляра, а затем выполняю щелчок правой кнопкой на строке "Logins" и выбираю пункт “New Login…” из выпадающего списка.
Рис.4 Создание логина Red-Gate
На рис.4 я ввожу "Red-Gate" в качестве имени логина и пароль этого логина SQL в соответствующих полях диалога. Для предоставления доступа этому новому логину я выполняю щелчок на пункте “User Mapping” в левой панели. После этого откроется окно, показанное на рис.5.
Рис.5 Окно мэппинга пользователя
В красном прямоугольнике выводится список баз данных, с которыми можно связать мой новый логин. Для мэппинга логина “Red-Gate” с базой данных “AdventureWorks2019” мне нужно просто щелкнуть на флажке "Map" рядом с базой данных AdventureWorks2019. Теперь я получу то, что показано на скриншоте (рис.6).
Рис.6 Мэппинг логина с базой данных
После установки флажка Map имя “Red-Gate” автоматически заносится в столбец "User" для базы данных AdventureWorks2019. В интерфейсе автоматически генерируется имя пользователя базы данных, совпадающее с логином. Имена пользователей базы данных не обязательно должны совпадать с логинами. Если вы хотите использовать другое имя, просто наберите желаемое имя вместо предложенного (в моем случае “Red-Gate”). Мэппинг логина с пользователями базы данных обеспечивает только доступ к базе данных, но не предоставляет прав на чтение или обновление данных в базе. В следующих статьях я буду обсуждать предоставление доступа к объектам базы данных на чтение/запись.
Предположим я хочу связать мой новый логин “Red-Gate” и с другими пользовательскими базами данных. В этом случае мне нужно просто проставить флажки рядом с требуемыми базами данных. В данном примере я осуществляю мэппинг логина “Red-Gate” только с базой данных AdventureWorks2019. Для завершения процедуры мэппинга моего логина “Red-Gate” с пользователем базы данных “Red-Gate” нужно щелкнуть кнопку "ОК".
Создание нового пользователя базы данных и связывание его с существующим логином
Иногда, когда логин уже существует, требуется предоставить ему доступ к тем или иным базам данных. Предположим, что теперь я хочу установить доступ моему логину Red-Gate к базе данных с именем MyDatabase. Чтобы предоставить логину Red-Gate доступ к еще одной базе данных, у меня есть несколько вариантов. Одним из них может быть просто модификация мэппинга пользователя путем изменения свойств логина. Это подобно тому, как я только что показал, добавляя мэппинг пользователя при создании логина Red-Gate.
Другой вариант - это добавление нового пользователя в базу данных MyDatabase, а затем связывание этого нового пользователя базы данных с логином Red-Gate. Чтобы создать нового пользователя в базе данных MyDatabase, нужно сначала развернуть базу данных, щелкнуть правой кнопкой на пункте “Security”, переместить указатель на пункт "New", а затем щелкнуть на пункте "User. ", как показано на рис.7.
Рис.7 Диалог ввода нового пользователя базы данных
При щелчке на пункте меню "User. " откроется окно, показанное на рис.8.
Рис.8 Добавление нового пользователя базы данных
Чтобы предоставить логину Red-Gate доступ к MyDatabase, нужно заполнить форму на рис.8. Сначала рассмотрим пункт “User Type” (тип пользователя). Значением по умолчанию для этого поля является “SQL User with Login” (пользователь SQL с логином). Имеется четыре других типа: SQL user without login (пользователь SQL без логина), User mapped to a certificate (пользователь, связанный с сертификатом), User mapped to an asymmetric key (пользователь, связанный с асимметричным ключом) и пользователи Window. Поскольку я создаю пользователя, который будет связан с логином SQL, я использую значение по умолчанию. Затем я ввожу имя создаваемого пользователя базы данных. Это может быть любое имя, но я предпочитаю использовать имена, совпадающие с соответствующими логинами. Поэтому я введу "Red Gate" в поле "User name". Затем я свяжу нового пользователя с логином. Для этого я могу либо набрать "Red Gate" для логина, либо использовать кнопку ". " для навигации по списку существующих логинов и выбрать нужный.
Последнее, что требуется, это определить схему по умолчанию для этого логина. Имя схемы ассоциируется с коллекцией объектов базы данных, владельцем которых является пользователь базы данных. По умолчанию каждая база данных имеет схему с именем "dbo", владельцем которой является учетная запись пользователя "dbo". При задании нового пользователя базы данных не обязательно указывать схему. Если схема не задана, будет использоваться схема по умолчанию "dbo". Я оставлю обсуждение различных аспектов схем для другой статьи. Когда я создаю нового пользователя базы данных Red-Gate, я оставляю пустым поле схемы по умолчанию и позволяю процессу создания нового пользователя автоматически установить схему по умолчанию в "dbo".
После создания нового пользователя я могу проверить его существование в базе данных, развернув ветку "User" в папке "Security" браузера объектов. Вы также можете создать нового пользователя базы данных и связать его с логином с помощью скрипта. В листинге 2 приводится пример использования T-SQL для создания того же пользователя, которого я только что создал визуальными средствами.
Сегодня прихожу - а пользователи не могут войти в домен (интерактивный вход запрещен локальной политикой) и политика для WSUS не действует!
у пользователей WinXP Win2000.
вот листинг команды gpresult на контролере домена
Программа формирования отчета групповой политики операционной системы
Microsoft (R) Windows (R) версии 2.0
(С) Корпорация Майкрософт, 1981-2001
Создано на 07.11.2005 в 9:41:30
Конфигурация компьютера
------------------------
CN=SIBGATEWAY,OU=Domain Controllers,DC=sibntc
Последнее применение групповой политики: 07.11.2005 в 9:39:32
Групповая политика была применена с: sibgateway.sibntc
Порог медленного канала для групповой политики: 500 kbps
Имя домена: SIBNTC
Тип домена: Windows 2000
Примененные объекты групповой политики
---------------------------------------
Default Domain Controllers Policy
Default Domain Policy
wsus
Local Group Policy
Конфигурация пользователя
--------------------------
CN=admin,CN=Users,DC=sibntc
Последнее применение групповой политики: 07.11.2005 в 9:19:35
Групповая политика была применена с: sibgateway.sibntc
Порог медленного канала для групповой политики: 500 kbps
Имя домена: SIBNTC
Тип домена: Windows 2000
Примененные объекты групповой политики
---------------------------------------
Default Domain Policy
Следующие политики GPO не были приняты, поскольку они отфильтрованы
--------------------------------------------------------------------
wsus_test
Фильтрация: Не применяется (пусто)
Local Group Policy
Фильтрация: Не применяется (пусто)
а это листинг комманды на машине пользователя (WinXP).
Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.
Программа формирования отчета групповой политики операционной системы
Microsoft (R) Windows (R) XP версии 2.0
(С) Корпорация Майкрософт, 1981-2001
Создано на 07.11.2005 в 10:06:21
Конфигурация компьютера
------------------------
CN=COMPUTER5,CN=Computers,DC=sibntc
Последнее применение групповой политики: 07.11.2005 at 10:01:12
Групповая политика была применена с: sibgateway.sibntc
Порог медленной связи групповой политики: 500 kbps
Примененные объекты групповой политики
---------------------------------------
Default Domain Policy
wsus
Политика локальной группы
Компьютер является членом следующих групп безопасности:
-------------------------------------------------------
Администраторы
Все
Пользователи
СЕТЬ
Прошедшие проверку
COMPUTER5$
Компьютеры домена
Конфигурация пользователя
--------------------------
CN=lev,CN=Users,DC=sibntc
Последнее применение групповой политики: 07.11.2005 at 9:30:09
Групповая политика была применена с: sibgateway.sibntc
Порог медленной связи групповой политики: 500 kbps
Примененные объекты групповой политики
---------------------------------------
Default Domain Policy
Следующие политики GPO не были приняты, поскольку они отфильтрованы
--------------------------------------------------------------------
Политика локальной группы
Фильтрация: Не применяется (пусто)
Пользователь является членом следующих групп безопасности:
----------------------------------------------------------
Администраторы домена
Все
Администраторы
Пользователи
ИНТЕРАКТИВНЫЕ
Прошедшие проверку
ЛОКАЛЬНЫЕ
Проблема - пользователею admin (доменный админ, админ схемы, все операции выполнялись под этим пользователем) - не разрешен интерактивный вход в систему, не разрешен вход через службу терминалов!
Зашел локально под стандартным пользователем "администратор" - удалил политику, подождал часа 2. перезагрузил контроллер -
под admin-ом вхожу, НО не могу открыть(промостреть) журнал безопасноти, не могу останавливать/запускать службы и.т.д.
Продолжим про безопасность операционных систем – на этот раз «жертвой» станет MS Windows и принцип предоставления минимальных прав для задач системного администрирования.
Сотрудникам, ответственным за определенные серверы и рабочие станции совсем не обязательно выдавать права «администратор домена». Хоть не по злому умыслу, по ошибке, но это может подпортить всем жизнь, а то и стоить чьих-то выходных. Под катом детально разберем принцип предоставления минимальных прав как одну из технологий предоставления минимальных прав.
В качестве примера из практики могу привести грустную историю со счастливым концом. В организации исторически сложилось, что сервер печати находился на контроллере домена. В один прекрасный момент сотруднику отдела IT понадобилось перепрошить принтер, что он и проделал, запустив китайскую утилиту на сервере. Принтер заработал, но вот утилита в процессе перепрошивки перевела время на несколько лет назад. Active directory не очень любит путешественников во времени, и контроллер домена благополучно отправился в «захоронение» (tombstone).
Инцидент добавил седых волос, но второй контроллер домена спас ситуацию: роли FSMO перевели на него, а путешественника во времени повторно сделали контроллером домена. С тех пор в компании права «администратора домена» нужно заслужить.
Для профилактики подобных ситуаций неплохо будет выдавать желающим ровно столько прав, сколько нужно: если нужно администрировать только рабочие станции, достаточно выдать права только на компьютеры пользователей.
Когда компьютеров немного, включить доменную группу безопасности «helpdesk» в локальную группу «администраторы» можно и руками. А вот на большом объеме приходят на помощь групповые политики. Удобных способов два.
Первый способ: через Группы с ограниченным доступом (Restricted groups), расположенные в групповых политиках по адресу Конфигурация компьютера – Политики – Параметры безопасности.
Расположение политик Restricted groups.
Далее нужно создать группу «Администраторы» и добавить в нее нужную группу. Есть только один нюанс – если сделать именно так, то из локальной группы «Администраторы» исчезнут все, кроме встроенного администратора и самой группы. Даже Domain Admins:
Добавляем группу «Администраторы», в которую добавляем группу helpdesk.
И получаем локальную группу «Администраторы» без Domain admins.
Конечно, эту возможность можно использовать и во благо – зачистить локальные группы от лишних участников. Если же хочется избежать такой зачистки, то можно создать в «Группах ограниченного доступа» доменную группу и ее же назначить входящей в группу «Администраторы»:
При такой настройке локальная группа «Администраторы» не будет зачищена.
Вторым способом является настройка Предпочтения Групповых Политик (Group Policy Preference, далее – GPP). Искать следует в Конфигурации компьютера – Настройка – Локальные пользователи и группы.
Настройка группы безопасности через GPP.
Как и все настройки в GPP, эта проще в понимании и с более дружелюбным интерфейсом. Но если у вас в инфраструктуре присутствуют не обновленные Windows XP или даже Windows 2000, то остается только первый вариант.
Таким же способом можно дать права и на определенные серверы нужным сотрудникам. Например, дать права группе разработчиков на тестовый стенд.
Конечно, сотрудников отдела IT и системные учетные записи (например, под которыми выполняются задачи резервного копирования) проще сразу включить в группу «Enterprise Admins» и не знать горя.
Но из соображений безопасности лучше так не делать. В Windows существует набор встроенных учетных записей с набором типовых прав. Группы немного различаются для компьютера и для домена, а также ряд сервисов привносит свои группы.
Под спойлером предлагаю ознакомится с набором основных групп безопасности.| Группа | Описание |
| Администраторы | Полные права на систему. |
| Пользователи | Возможность пользоваться без изменения системных параметров и без записи в системные разделы. Фактически пользователь – полноценный хозяин только в папке своего профиля. |
| Операторы архива | Группа, предназначенная для выполнения резервного копирования и восстановления. Участники группы могут завершать работу системы на серверах и переопределять права доступа в целях резервного копирования. |
| Опытные пользователи | Участники этой группы могут администрировать локальные учетные записи и группы (кроме администраторов), создавать сетевые ресурсы и управлять доступом на них, менять NTFS ACL (кроме смены владельца папки). |
| Пользователи удаленного рабочего стола | Членство дает возможность подключаться к компьютеру по RDP |
| Операторы печати | Операторы могут устанавливать и удалять принтеры, изменять их драйвера и настройки, останавливать и чистить очередь печати. |
| Операторы настройки сети | Могут менять настройки сетевых интерфейсов. Это полезная группа на случай если нужно переназначать получение адреса сетевой картой с автоматического на статическое. Мобильные пользователи скажут спасибо, если добавить их в эту группу. |
| Операторы учета | Пользователи в этой группе могут создавать/удалять/редактировать/перемещать учетные записи в Active Directory. Удобно дать эти права для сервиса, автоматически заводящего учетки сотрудников после приема на работу. |
Познакомиться со всеми группами и более полным описанием можно в официальной документации.
Если стандартных групп не хватает, то Windows позволяет настроить права доступа более тонко. Например, выдать отдельной группе пользователей право менять время или возможность принудительно завершать работу сервера по сети. Для этого существует механизм «назначение прав пользователей». Искать можно в локальной политике безопасности – secpol.msc или в групповой политике по адресу Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Назначение прав пользователя.
Настройка прав доступа через групповые политики.
Использовать эту настройку я рекомендую в крайних случаях, и ее обязательно надо документировать. Помните о том, что когда-нибудь вас кто-то сменит и будет разбираться, почему работает так, а не иначе.
Вообще лучше всегда все документировать. Представьте ситуацию, что вы уволились из организации и вместо вас пришел человек с улицы. Поставьте себя на место этого человека. Если начал дергаться глаз или зашевелились волосы – посвятите время написанию документации. Пожалуйста!
Существует еще один хороший метод ограничения доступа к объектам – делегирование. Про эту технологию на Хабре уже писали, поэтому я лишь добавлю, что с помощью делегирования удобно выдаются права для ввода нового компьютера в домен.
Все эти технологии довольно давно существуют в системах Windows. С появлением Windows 10\2016 появилась еще одна интересная возможность ограничить учетные записи – речь о ней пойдет далее.
Just Enough Administration (JEA) – технология предоставления доступа к командлетам PowerShell. Работает на операционных системах вплоть до Windows 7 при установке Windows Management Framework 5.1 (правда, в самых старых операционных системах поддержка ограничена). Работа производится через так называемые «виртуальные аккаунты» и специально подготовленные файлы конфигурации. Примером использования JEA является выдача ограниченных прав на управление определенными виртуальными машинами – например, для ваших разработчиков.
Подробнее про JEA можно почитать в официальной документации, поэтому разберем конкретный пример предоставления возможности перезапуска виртуальной машины.
Сначала нам нужно разрешить удаленное подключение к серверу с помощью командлета Enable-PSRemoting, а заодно убедимся, что у нас Windows Management Framework нужной версии при помощи командлета $PSVersionTable.PSVersion.
Проверка версии и разрешение удаленных подключений при помощи PS.
Создадим группу безопасности и специального пользователя:
Теперь создадим нужные для работы конфигурационные файлы и папки. Сначала общие:
А затем создадим конкретный файл конфигурации для нашего оператора виртуальной машины с именем win. Для примера разрешим запуск и остановку виртуальной машины:
Теперь необходимо подготовить файл сессии PowerShell:
Зарегистрируем файл сессии:
Теперь все готово для проверки. Попробуем подключиться к серверу с учетными данными созданного пользователя командлетом:
Проверим список доступных команд командой get-command и попробуем остановить нашу виртуальную машину win, а затем другую машину win2.
Доступ к серверу ограничен управлением одной виртуальной машиной.
Для облегчения создания файлов конфигурации сообществом была создана утилита под названием JEA Toolkit Helper, где графический интерфейс поможет создать файлы с необходимыми параметрами.
Интерфейс JEA Toolkit Helper.
При необходимости есть возможность через групповые политики включить аудит выполнения модулей по адресу Конфигурация компьютера – Административные шаблоны – Windows Powershell – Включить ведение журнала модулей. Тогда в журнале Windows будут отображаться записи о том что, где и когда.
Журнал выполнения PowerShell.
Альтернативой будет включение записи в файл. Также через групповые политики настраивается параметр «Включить транскрипции PowerShell». Путь можно задать как в самой политике (и тогда запись туда будет вестись для всех модулей), так и в файле конфигурации сессии JEA в параметре TranscriptDirectory.
Файловый журнал JEA.
С помощью делегирования, назначения прав и JEA можно добиться отказа от использования учетных записей с администраторскими правами в повседневной работе. В конце-концов, к UAC в Windows ведь тоже привыкли и не отключаем просто потому, что «заткнись, я и так знаю что мне делать со своими файлами!».
Эта справочная тема для ИТ-специалистов описывает принципы безопасности в отношении Windows учетных записей и групп безопасности, а также технологий безопасности, связанных с принципами безопасности.
Что такое принципы безопасности?
Принципы безопасности — это любая сущность, которая может быть аутентификацией операционной системы, например учетной записью пользователя, учетной записью компьютера, потоком или процессом, который выполняется в контексте безопасности учетной записи пользователя или компьютера, или группами безопасности для этих учетных записей. Принципы безопасности уже давно являются основой для управления доступом к защищаемым ресурсам на Windows компьютерах. Каждый руководитель безопасности представлен в операционной системе уникальным идентификатором безопасности (SID).
Следующий контент применяется к версиям Windows, указанным в списке Applies To в начале этой темы.
Работа принципов безопасности
Основными объектами безопасности, созданными в домене Active Directory, являются объекты Active Directory, которые можно использовать для управления доступом к ресурсам домена. Каждому принципу безопасности назначен уникальный идентификатор, который он сохраняет на протяжении всего срока службы. Локальные учетные записи пользователей и группы безопасности создаются на локальном компьютере, и их можно использовать для управления доступом к ресурсам на этом компьютере. Локальные учетные записи пользователей и группы безопасности управляются диспетчером учетных записей безопасности (SAM) на локальном компьютере.
Компоненты управления авторизацией и доступом
Следующая схема иллюстрирует процесс Windows и управления доступом. На этой схеме субъект (процесс, инициированный пользователем) пытается получить доступ к объекту, например к общей папке. Сведения в маркере доступа пользователя сравниваются с записями управления доступом (ACEs) в дескрипторе безопасности объекта, и принимается решение о доступе. В маркере доступа пользователя и в acEs в дескрипторе безопасности объекта используются СИД основных объектов безопасности.
Процесс управления авторизацией и доступом
Принципы безопасности тесно связаны со следующими компонентами и технологиями:
Идентификаторы безопасности
Идентификаторы безопасности (SID) обеспечивают фундаментальный строительный блок Windows безопасности. Они работают с определенными компонентами технологий управления авторизацией и доступом в инфраструктуре безопасности операционных систем Windows Server. Это помогает защитить доступ к сетевым ресурсам и обеспечивает более безопасную вычислительную среду.
SID — это значение переменной длины, которое используется для уникальной идентификации доверника безопасности, который представляет любую сущность, которая может быть аутентификацией системы. Эти сущности включают учетную запись пользователя, учетную запись компьютера или поток или процесс, который выполняется в контексте безопасности учетной записи пользователя или компьютера. Каждому принципу безопасности автоматически назначен SID при его создания. SID хранится в базе данных безопасности. Когда SID используется в качестве уникального идентификатора для пользователя или группы, его нельзя использовать для идентификации другого пользователя или группы.
При каждом входе пользователя система создает маркер доступа для этого пользователя. Маркер доступа содержит ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС пользователя, права пользователя и СИД для групп, к которой принадлежит пользователь. Этот маркер обеспечивает контекст безопасности для любых действий, выполняемых пользователем на этом компьютере.
Помимо уникально созданных ИИИ, определенных для домена, которые назначены определенным пользователям и группам, существуют хорошо известные СИД, которые определяют общие группы и общих пользователей. Например, СИД "Все" и "Мир" определяют группы, включив в себя всех пользователей. Известные SID-системы имеют значения, которые остаются неизменными во всех операционных системах.
Маркеры доступа
Маркер доступа — это защищенный объект, содержащий сведения о удостоверениях и правах пользователей, связанных с учетной записью пользователя.
Когда пользователь во время интерактивного входа или пытается сделать сетевое подключение к компьютеру с Windows, процесс входа подает проверку подлинности учетных данных пользователя. Если проверка подлинности будет успешной, процесс возвращает sid для пользователя и список SID для групп безопасности пользователя. Локализованная служба безопасности (LSA) на компьютере использует эти сведения для создания маркера доступа (в данном случае основного маркера доступа). Это включает ВИИ, возвращаемые процессом регистрации, и список прав пользователей, которые назначены локальной политикой безопасности пользователю и группам безопасности пользователя.
После создания маркера первичного доступа к каждому потоку и процессу, который выполняется от имени пользователя, прикрепляются копии маркера доступа. Всякий раз, когда поток или процесс взаимодействует с защищаемым объектом или пытается выполнить системную задачу, требуемую правами пользователя, операционная система проверяет маркер доступа, связанный с потоком, чтобы определить уровень авторизации.
Существует два типа маркеров доступа, первичные и вымывка. Каждый процесс имеет основной маркер, описывая контекст безопасности учетной записи пользователя, связанной с процессом. Основной маркер доступа обычно назначен процессу представления сведений о безопасности по умолчанию для этого процесса. Маркеры обезличения, с другой стороны, обычно используются для клиентских и серверных сценариев. Маркеры impersonation позволяют потоку работать в контексте безопасности, который отличается от контекста безопасности процесса, владеющем потоком.
Дескрипторы безопасности и списки управления доступом
Дескриптор безопасности — это структура данных, связанная с каждым защищаемым объектом. Все объекты Active Directory и все объекты с безопасностью на локальном компьютере или в сети имеют дескрипторы безопасности, которые помогают контролировать доступ к объектам. Дескрипторы безопасности включают сведения о том, кто владеет объектом, кто может получить к нему доступ и каким образом и какие типы доступа проверяются. Дескрипторы безопасности содержат список управления доступом (ACL) объекта, который включает все разрешения безопасности, применимые к этому объекту. Дескриптор безопасности объекта может содержать два типа acLs:
Дискреционный список управления доступом (DACL), который определяет пользователей и групп, которым разрешен или отказано в доступе.
Список управления доступом к системе (SACL), который контролирует проверку доступа
Эту модель управления доступом можно использовать для индивидуальной защиты объектов и атрибутов, таких как файлы и папки, объекты Active Directory, ключи реестра, принтеры, устройства, порты, службы, процессы и потоки. Благодаря этому индивидуальному контролю можно настроить безопасность объектов для удовлетворения потребностей организации, делегировать полномочия объектам или атрибутам, а также создавать настраиваемые объекты или атрибуты, которые требуют определения уникальных защитных объектов.
Разрешения
Разрешения позволяют владельцу каждого защищаемого объекта, например файла, объекта Active Directory или ключа реестра, контролировать, кто может выполнять операцию или набор операций на объекте или свойстве объекта. Разрешения выражаются в архитектуре безопасности в качестве записей управления доступом (ACEs). Поскольку доступ к объекту по усмотрению владельца объекта, тип управления доступом, используемый в Windows, называется дискреционным управлением доступом.
Разрешения отличаются от прав пользователей тем, что разрешения присоединены к объектам, а права пользователей применяются к учетным записям пользователей. Администраторы могут назначать права пользователей группам или пользователям. Эти права разрешают пользователям выполнять определенные действия, например вход в систему в интерактивном режиме или архивировать файлы и каталоги.
На компьютерах права пользователей позволяют администраторам контролировать, кто обладает полномочиями для выполнения операций, затрагивающих весь компьютер, а не определенный объект. Администраторы назначают права пользователей отдельным пользователям или группам в рамках параметров безопасности компьютера. Хотя права пользователей могут управляться централизованно с помощью групповой политики, они применяются локально. Пользователи могут (и обычно имеют) различные права пользователей на разных компьютерах.
Сведения о том, какие права пользователей доступны и как их реализовать, см. в статью Назначение прав пользователей.
Контекст безопасности при проверке подлинности
Учетная запись пользователя позволяет пользователю войти в компьютеры, сети и домены с удостоверением, которое может быть аутентификацией компьютера, сети или домена.
В Windows, любой пользователь, служба, группа или компьютер, которые могут инициировать действия, является основным источником безопасности. У глав служб безопасности есть учетные записи, которые могут быть локальными для компьютера или на основе домена. Например, клиентские компьютеры Windows присоединившись к домену, могут участвовать в сетевом домене, общаясь с контроллером домена, даже если пользователь не вошел.
Этот контекст безопасности определяет удостоверение и возможности пользователя или службы на определенном компьютере или пользователя, службы, группы или компьютера в сети. Например, он определяет ресурсы (например, файл или принтер), к ним можно получить доступ, а также действия (например, чтение, записи или изменение), которые могут выполняться пользователем, службой или компьютером на этом ресурсе.
Контекст безопасности пользователя или компьютера может отличаться от одного компьютера к другому, например при проверке подлинности пользователя на сервер или на рабочей станции, кроме основной рабочей станции пользователя. Он также может отличаться от одного сеанса к другому, например, когда администратор изменяет права и разрешения пользователя. Кроме того, контекст безопасности обычно отличается, когда пользователь или компьютер работают самостоятельно, в смешанном сетевом домене или в составе домена Active Directory.
Учетные записи и группы безопасности
Учетные записи и группы безопасности, созданные в домене Active Directory, хранятся в базе данных Active Directory и управляются с помощью инструментов Active Directory. Эти принципы безопасности являются объектами каталогов и могут использоваться для управления доступом к ресурсам домена.
Локальные учетные записи пользователей и группы безопасности создаются на локальном компьютере, и их можно использовать для управления доступом к ресурсам на этом компьютере. Локальные учетные записи пользователей и группы безопасности хранятся и управляются диспетчером учетных записей безопасности (SAM) на локальном компьютере.
Учетные записи пользователей
Учетная запись пользователя однозначно идентифицирует пользователя, используювшего компьютерную систему. Учетная запись сигнализирует системе о необходимости применения соответствующей авторизации, чтобы разрешить или запретить пользователю доступ к ресурсам. Учетные записи пользователей можно создавать в Active Directory и на локальных компьютерах, а администраторы используют их для:
Представлять, идентифицировать и аутентификацию удостоверения пользователя. Учетная запись пользователя позволяет пользователю войти в компьютеры, сети и домены с уникальным идентификатором, который может быть аутентификацией компьютера, сети или домена.
Авторизуйте (предоставляете или отказывайте) доступ к ресурсам. После проверки подлинности пользователь получает авторизованный доступ к ресурсам на основе разрешений, которые назначены этому пользователю для ресурса.
Аудит действий, которые осуществляются в учетной записи пользователя.
Windows и операционные системы Windows Server имеют встроенные учетные записи пользователей, или вы можете создавать учетные записи пользователей для удовлетворения требований организации.
Группы безопасности
Группа безопасности — это коллекция учетных записей пользователей, учетных записей компьютеров и других групп учетных записей, которые можно управлять как единым подразделением с точки зрения безопасности. В Windows операционных системах существует несколько встроенных групп безопасности, которые предварительно сконфигурировали соответствующие права и разрешения для выполнения определенных задач. Кроме того, можно (и, как правило, будет) создавать группу безопасности для каждого уникального сочетания требований безопасности, которые применяются к нескольким пользователям в вашей организации.
Группы могут быть на основе Active Directory или локальными для определенного компьютера:
Группы безопасности Active Directory используются для управления правами и разрешениями на доменные ресурсы.
Локальные группы существуют в базе данных SAM на локальных компьютерах (на Windows компьютерах), кроме контроллеров домена. Вы используете локальные группы для управления правами и разрешениями только для ресурсов на локальном компьютере.
С помощью групп безопасности для управления управлением доступом можно:
Упрощение администрирования. Вы можете назначить общий набор прав, общий набор разрешений или обеих учетных записей одновременно, а не назначать их каждой учетной записи по отдельности. Кроме того, когда пользователи передают задания или покидают организацию, разрешения не привязаны к учетным записям пользователей, что упрощает перенанаменование или удаление разрешений.
Реализация модели управления доступом на основе ролей. Эту модель можно использовать для предоставления разрешений с помощью групп с различными сферами для соответствующих целей. Области, доступные в Windows, включают локальные, глобальные, локальные домены и универсальные.
Свести к минимуму размер списков управления доступом (ACLs) и проверку безопасности скорости. Группа безопасности имеет собственный SID; таким образом, групповой SID можно использовать для указания разрешений для ресурса. В среде с более чем несколькими тысячами пользователей, если СИИ отдельных учетных записей пользователей используются для указания доступа к ресурсу, ACL этого ресурса может стать неуправляемо большим, а время, необходимое системе для проверки разрешений на ресурс, может стать неприемлемым.
Сведения о группах безопасности домена, определенных в Active Directory, см. в описании и параметрах групп безопасности Active Directory.
Сведения об описаниях и параметрах группы Special Identities см. в специальной информации.
Читайте также: