- Локальная политика безопасности. Часть 6: группы с ограниченным доступом, системные службы, реестр и файловая система
- Введение
- Группы с ограниченным доступом
- Системные службы
- Реестр
- Файловая система
- Заключение
- [конспект админа] Меньше администраторов всем
- Ограниченные группы
- Использование встроенных групп безопасности
- Достаточно администрирования
Локальная политика безопасности. Часть 6: группы с ограниченным доступом, системные службы, реестр и файловая система
Посетителей: 11495 | Просмотров: 15710 (сегодня 0)
Введение
Из цикла предыдущих статей, посвященных локальным политикам безопасности, вы уже узнали о многих средствах обеспечения безопасности пользователей вашей организации или домашних пользователей средствами групповых политик. Из этой статьи вы узнаете еще о четырех узлах локальных политик безопасности, а именно об управлении группами с ограниченным доступом, системных службах пользователей, которые попадают в область действия групповых политик, об ограничениях разделов системного реестра, а также о разрешениях файловой системы ваших рабочих станций. Эти политики безопасности позволят вам задать свойства для групп со специфическими требованиями, принудительно запускать или отключать службы согласно корпоративным требованиям, ограничить доступ к конкретным разделам системного реестра и управлять разрешениями доступа и параметрами аудита для файловой системы. Правильное использование этих политик безопасности позволит вам закрыть множество уязвимостей, от злоумышленников, которым все-таки удалось проникнуть в системы ваших пользователей, а также от самих пользователей, которые в связи с некомпетентностью могут нанести не менее значительный ущерб своему компьютеру и рабочим станциям организации в частности. Все четыре указанных ниже локальных политик безопасности вы не сможете найти в оснастке «Редактор локальной групповой политики» клиентских операционных систем.
Группы с ограниченным доступом
При помощи локальных политик безопасности и политик «Группы с ограниченным доступом» в частности, вы можете указать два свойства, определяющие членов данной группы, а также членства в группах для конкретной группы безопасности. Данная политика безопасности имеет особенную ценность для организаций, в которых присуща сложная иерархия групп безопасности. Как известно, группы – это важный класс объектов, поскольку они служат для единого управления коллекциями пользователей, компьютеров и других групп. Несмотря на то, что данные политики безопасности очень похожи на возможности функционала оснастки «Active Directory: Локальные пользователи и компьютеры», я рекомендую не игнорировать использование данных политик. В связи с тем, что на первый взгляд свойства «Члены группы» и «Член групп» очень похожи, между ними имеются существенные отличия.
Параметр «Член групп» указывает принадлежность данной группы к еще одной группе. Применение этого параметра гарантирует членство определяемой вами группы в указанной локальной группе. В том случае, если вы настроили локальные политики безопасности в нескольких объектах групповых политик, то для выбранных групп будет применяться каждый параметр членства группы. Например, если вы определили для группы «Отдел разработки», что пользователи данной группы являются членами группы «Разработчики», а второй объект, который привязан к дочернему подразделению, указывает что группа «Отдел тестирования» также является членом группы «Разработчики», то, в конечном счете, обе группы будут принадлежать к группе «Разработчики».
При помощи параметра «Члены группы», вы можете указать членство в определяемой группе. Данный параметр является авторитарным, и он определяет окончательный список членов. Если политика групп с ограниченным доступом определена в нескольких объектах групповых политик, то объект GPO с высшим приоритетом будет иметь преимущества над остальными объектами групповых политик.
Например, попробуем настроить группу «Отладчики» как ограниченную группу, в которую входит группа «Поддержка»:
- Откройте консоль «Управление групповой политикой», где выберите контейнер «Объекты групповой политики» и нажмите на этом контейнере правой кнопкой мыши для отображения контекстного меню;
- В контекстном меню выберите команду «Создать» и в отобразившемся диалоговом окне «Новый объект групповой политики» введите «Группы с ограниченным доступом», после чего нажмите кнопку «ОК»;
- Выберите данный объект групповой политики и из контекстного меню выберите команду «Изменить»;
- В окне оснастки «Редактор управления групповыми политиками» разверните узел Конфигурация компьютера/Политика/Конфигурация Windows/Параметры безопасности\Группы с ограниченным доступом и вызовите диалоговое окно добавления группы одним из следующих методов:
- В дереве консоли выберите узел «Группы с ограниченным доступом», нажмите на нем правой кнопкой мыши и из контекстного меню выберите команду «Добавить группу»;
- Нажмите правой кнопкой на панели сведений и из контекстного меню выберите команду «Добавить группу»;
- Если у вас отображается панель действий, то перейдите в ней по ссылке «Дополнительные действия» и выберите команду «Добавить группу».
- В диалоговом окне «Добавление группы» в текстовом поле «Группа» введите название необходимой группы или найдите ее, вызвав диалоговое окно «Выбор: Группы», нажав на кнопку «Обзор», после чего нажмите на кнопку «ОК»;
Рис. 1. Диалоговое окно добавления группы
В диалоговом окне «TESTDOMAIN\Отладчики Свойства» необходимо указать пользователей или группы, которые будут являться членами группы «Отладчики». Для этого возле области «Члены этой группы» нажмите на кнопку «Добавить». Откроется такое же окно, предназначенное для выбора группы, как и на предыдущем шаге. Выберем группу «Поддержка», которая была создана заранее. В нашем случае, группа отладчиков не должна входить в какие-либо группы, поэтому далее нажмите на кнопку «ОК».
Рис. 2. Диалоговое окно настройки группы с ограниченным доступом
Системные службы
Узел «Службы» локальных политик безопасности отвечает за централизованное управление службами ваших клиентских машин. Для повышения производительности компьютеров вашей организации вы можете определить службы, которые будут запущены автоматически, которые нужно запускать вручную, а также службы, которые принудительно будут остановлены. Для того чтобы определить параметры служб, вам нужно выполнить следующие действия:
- Откройте консоль «Управление групповой политикой», где выберите контейнер «Объекты групповой политики» и нажмите на этом контейнере правой кнопкой мыши для отображения контекстного меню;
- В контекстном меню выберите команду «Создать» и в отобразившемся диалоговом окне «Новый объект групповой политики» введите «Службы для компьютеров организации», после чего нажмите кнопку «ОК»;
- Выберите данный объект групповой политики и из контекстного меню выберите команду «Изменить»;
- В окне оснастки «Редактор управления групповыми политиками» разверните узел Конфигурация компьютера/Политика/Конфигурация Windows/Параметры безопасности\Системные службы. Область сведений системных служб вы можете увидеть ниже:
Рис. 3. Область сведений узла «Системные службы»
Как видно из предыдущей иллюстрации, по умолчанию для всех системных служб установлено состояние «Не определено». Для того чтобы настроить определенные системные службы, выберите любую службу, например, «Служба ввода планшетного ПК» и откройте ее свойства. Свойства данной службы отображены на следующей иллюстрации:
Рис. 4. Диалоговое окно свойств службы
Рис. 5. Область сведений после настройки режима запуска служб
Реестр
Используя политики из узла «Реестр» вы можете определить права доступа и аудита для различных разделов системного реестра компьютеров, которые указаны в области действия объектов групповых политик. Настройки данных политик идентичны тем настройкам, которые были описаны в статье «Работа с оснасткой «Шаблоны безопасности»». Например, для того чтобы запретить вашим пользователям изменять настройки автозапуска совместно с настройками режима запуска служб, выполните следующие действия:
- Откройте консоль «Управление групповой политикой», где выберите контейнер «Объекты групповой политики», затем выберите объект групповой политики «Службы для компьютеров организации», нажмите на нем правой кнопкой мыши и из контекстного меню выберите команду «Изменить»;
- В появившемся окне оснастки «Редактор управления групповыми политиками» разверните узел Конфигурация компьютера/Политика/Конфигурация Windows/Параметры безопасности\Реестр и вызовите диалоговое окно «Выбор раздела реестра» из контекстного меню узла, области сведений, области действий или из меню «Действие»;
- В диалоговом окне «Выбор раздела реестра», введите в текстовом поле «Выбранный реестр» путь к требуемому разделу (в нашем случае — MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run) или выберите необходимый раздел в области «Реестр». Данное диалоговое окно вы можете увидеть ниже:
Рис. 6. Диалоговое окно выбора раздела реестра
Рис. 7. Предупреждение об изменении разрешений
Прочитайте его и нажмите на кнопку «Да» для продолжения выполнения операции.
В диалоговом окне «Добавление объекта» вы можете указать разрешения для всех дочерних разделов. Выберите необходимые разрешения и нажмите на кнопку «ОК»;
Рис. 8. Диалоговое окно добавления раздела реестра
В области сведений будут отображаться все разделы реестра, для которых вы указали разрешения. По окончании добавления разделов реестра закройте оснастку «Редактор управления групповых политик»;
Рис. 9. Область сведений редактора управления групповых политик
Файловая система
При помощи этого узла вы можете настроить разрешения доступа пользователям или группам к объектам, расположенных на данном компьютере. Принцип добавления объекта файловой системы полностью идентичен добавлению разрешений на разделы реестра за исключением того, что на третьем шаге вместо диалогового окна выбора раздела реестра вам нужно будет указать файл или папку в диалоговом окне «Добавление файла или папки». На следующей иллюстрации отображено данное диалоговое окно:
Рис. 10. Диалоговое окно добавления файла или папки
Заключение
В данной статье вы узнали еще об одних локальных политиках безопасности: политиках групп с ограниченным доступом, которые предназначены для определения членов указанной группы и членства в группах, о политиках системных служб, используя которые вы можете указать режим запуска служб для своих клиентских компьютеров. Также были рассмотрены политики реестра, которые предназначены для указания разрешений к определенным разделам системного реестра и политики файловой системы, которые нужны для разрешения доступа пользователям или группам к объектам, расположенным на данном компьютере. В следующей статье вы узнаете о настройках политик проводной сети.
[конспект админа] Меньше администраторов всем
Продолжим про безопасность операционных систем – на этот раз «жертвой» станет 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 ведь тоже привыкли и не отключаем просто потому, что «заткнись, я и так знаю что мне делать со своими файлами!».
