Технологии безопасности Windows Server 2012

В корпоративной сети могут работать сотни компьютеров, география подключений нередко охватывает все регионы планеты. Повальный переход на облачные технологии, рост объема информации, доступ к ней из разных точек требует обеспечить безопасность данных и управляемость инфраструктуры. И в первую очередь необходим контроль пользователей и устройств.

Службы политики сети и доступа

Сегодня очень популярна технология BYOD (Bring Your Own Device), когда сотрудники используют в работе свои личные устройства, за которыми следят самостоятельно. Это удобно всем: компания избавляется от постоянной заботы закупать и обновлять оборудование, а пользователи работают с любимыми и современными гаджетами. Однако ради удобства пользователь может отключить службу установки обновлений, переконфигурировать брандмауэр или работать с устаревшими антивирусными базами. Это приводит к увеличению рисков, такие устройства несут потенциальную опасность для остальных систем. Чтобы избежать проблем при подключении личных устройств к корпоративной сети, следует контролировать их состояние.

Новая функция Network Access Protection, появившаяся в Win2k8, проверяет ОС на соответствие принятым политикам. На основе анализа состояния для конкретного устройства можно ограничить доступ, разрешить полный доступ временно или постоянно. Все события журналируются, и админ всегда располагает свежей информацией о проблемах.

В карантинной подсети располагаются коррекционные серверы (Remediation Server), предоставляющие ресурсы для устранения выявленных недостатков (сервер обновлений WSUS, антивирусная база). После устранения проблем система повторно подключается и проверяется, если все в норме, она получает полноценный доступ в сеть. В процессе работы состояние системы контролируется постоянно, и если оно перестает удовлетворять требованиям политик, то устройство снова переводится в карантин (или выполняется любое другое действие, предписанное админом). По сути, контроль состояния и карантин — это вся роль NAP, все остальное реализуется сторонними механизмами. При настройке NAP используется несколько механизмов принуждения (DHCP, VPN, IPsec, IEEE 802.1x и другие).

На удаленной системе устанавливается клиент NAP, состоящий из агента NAP, агента состояния системы (Windows Security Health Agent) и клиента принуждения (NAP Enforcement Client). Последний и отвечает за взаимодействие с механизмом принуждения. Собранные данные клиент отправляет серверу сетевых политик (NPS, Network Policy Server) в виде SHV-маркера (System Health Validators).

Агент уже включен во все версии Windows от XP SP3, поддерживается интеграция с Cisco Network Admission Control (NAC). Сторонние фирмы предлагают клиенты NAP для OS X и Linux и могут добавлять требуемую функциональность в NAP. Например, решение Symantec Endpoint Protection содержит дополнительные модули, позволяющие проверять состояние при помощи NPS.

Роль сервера «Службы политики сети и доступа» можно использовать для развертывания собственно службы NPS либо сервера и прокси-сервера RADIUS, выполняющего авторизацию при запросах на подключение со стороны клиентов RADIUS (коммутаторы Ethernet с поддержкой 802.1X, хотспоты). Все настройки производятся при помощи диспетчера сервера или утилиты netsh (контекст netsh nps, все команды можно узнать в документации).

В Win2k8R2 служба NPS получила возможность использовать несколько конфигураций SHV, что позволяет создавать свои политики для систем, подключающихся по разным каналам (LAN, VPN). Также появились новые шаблоны, упрощающие создание и экспорт элементов конфигурации NPS.

В Win2012 служба маршрутизации и удаленного доступа, которая раньше была частью NPS, выведена в отдельную роль сервера удаленного доступа. Сделано это, чтобы уменьшить путаницу при развертывании. Для роли сервера NPS понадобится физический или виртуальный (Hyper-V) сервер, кластеры не поддерживаются.

Установка сервера NPS производится при помощи мастера добавления ролей и компонентов, просто отмечаем пункт «Службы политики сети и доступа» и следуем его указаниям. Роль содержит три службы ролей:

• сервер политики сети — используется для централизованного управления доступом к сети через разнообразные серверы доступа, включая точки беспроводного доступа, VPN, серверы удаленного доступа и 802.1X-коммутаторы;
• центр регистрации работоспособности (HRA) — компонент, отвечающий за выпуск сертификатов работоспособности для клиентов, проходящих проверку политики. Используется только с принудительным методом протокола IPsec;
• протокол авторизации учетных данных узлов (HCAP) — позволяет объединить решение для защиты доступа к сети от MS с сервером управления сетевым доступом от компании Cisco.

В случае выбора HRA потребуется связать его с центром сертификации (это можно сделать позднее, после установки). Выдача сертификатов возможна как зарегистрированным в домене пользователям, так и анонимным (всем). Если NPS работает в доменной сети, то предпочтителен первый вариант.

Все установки производятся из консоли «Сервер групповых политик». Первоначальные настройки задаются при помощи готового сценария, просто выбираем нужный из списка и следуем указаниям мастера. Политики позволяют задать группы (Windows, компьютеров или пользователей), HCAP (группы пользователей и размещения), ограничения по дням недели и времени, типу удостоверения, классу IP, ОС и архитектуре, критерию политики работоспособности и другим параметрам.

У каждого контроллера домена, работающего на Win2012, должна быть та же настройка политики административных шаблонов (Конфигурация компьютера -> Политики -> Административные шаблоны -> Система -> KDC -> Поддержка динамического контроля доступа и защиты Kerberos).

В Win2012 также добавилась возможность использовать PowerShell для установки и настройки некоторых параметров роли NPS, поэтому многие операции можно выполнить из консоли. Ставим и смотрим новый набор из 13 командлетов).

PS> ADD-WindowsFeature NPAS-Policy-Server -includemanagementtools PS> Import-Module NPS PS> Get-Command –Module NPS

Например, командлеты Export/Import-NPSConfiguration позволяют сохранить и восстановить конфигурацию NPS-сервера. Они заменят netsh nps export/import, выполняющие аналогичную функцию. Вызов прост. Сохраняем:

PS> Export-NpsConfiguration –Path C:NPSTemp -Path Npsconfig.xml

Файл содержит данные RADUIS-клиентов, поэтому необходимо позаботиться, чтобы никто не получил к нему доступ. Теперь на другом сервере импортируем, просто указав на файл.

PS> Import-NpsConfiguration -Path C:Npsconfig.xml

Как и netsh, командлеты PowerShell не поддерживают перенос настроек шаблонов. Это доступно через интерфейс консоли.

Другие статьи в выпуске:

Хакер #172. Спецвыпуск о Raspberry Pi!

• Содержание выпуска
• Подписка на «Хакер»-60%

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

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

Особо остро этот вопрос стоит сегодня, так как по статистике большинство утечек происходит по вине инсайдеров (намеренной или случайной), которые имеют легальный доступ к некоторой информации. В результате, чтобы перекрыть все потребности, создается большое количество групп, что серьезно усложняет администрирование, в частности понимание того, кто и куда действительно имеет доступ. Малейшая ошибка пользователя или админа — и документ оказывается не на своем месте и имеет ненадлежащие права доступа. Современным организациям остро необходим простой в использовании механизм предотвращения утечки информации (DLP, Data Leak Prevention).

Защитить содержимое можно при помощи службы управления правами (Rights Management Services), но она снимает только часть проблем. Более глобально задачу управления доступом и аудита призвана решить технология динамического управления доступом (Dynamic Access Controls, DAC). Технология базируется на трех основных понятиях:

• классификация документов — на основе тегов, которые добавляются пользователем при создании/редактировании документа (в свойствах), приложением, наследуются от каталога или присваиваются по контексту. Если документ не классифицирован, то используются только традиционные средства доступа;
• политики — состоят из одного или нескольких правил, основанных на выражениях, описывающих условия доступа для утверждений пользователей/устройств и тегов. Выражения содержат атрибуты Active Directory и, по сути, являются основой DAC, показывая, кто и на каких условиях может получить доступ;
• аудит — расширенные политики аудита, позволяющие получить информацию о попытках доступа к конфиденциальной информации.

Реализована интеграция DAC со службой RMS, что позволяет в реальном времени защищать документы, которым присвоен соответствующий тег. Настройки упрощает автоматическое тегирование документов, которое создается при помощи правил, настраиваемых в диспетчере ресурсов файлового сервера (File Server Resource Manager).

Для реализации DAC система безопасности Win2012 получила новый механизм утверждения claims, такие утверждения существуют для ресурсов, пользователей и учетных записей компьютеров. При входе в систему помимо идентификатора безопасности SID (Security Identifier) учетной записи в маркер добавляются claims (просмотреть их можно, введя «whoami /claims»). Вот эти утверждения, вместе с данными об участии в группах, и используются при доступе к объектам файловой системы. При этом старые механизмы никуда не исчезли. Вначале применяются права доступа к сетевому ресурсу, затем NTFS и, наконец, вступает в работу DAC.

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

Учитывая, что в современных условиях ситуация быстро меняется, необходим механизм быстрого решения проблем с доступом, и DAC его предоставляет. Пользователю, получившему отказ, приходит сообщение с вариантами восстановления доступа — прямая ссылка на сайт или справка с объяснением. На сайте пользователь получает дополнительную информацию, например соглашение о неразглашении, которое нужно подтвердить. После выполнения требований claims обновляются, и пользователь получает доступ.

Политики задаются централизованно на уровне домена, распространяются при помощи GPO и указываются в настройках конкретного ресурса. В первом случае установки задаются в консоли центра администрирования Active Directory (ADAC, Active Directory Administrative Center), в котором находится специальный подраздел, содержащий восемь пошаговых настроек. На каждом необходимо будет заполнить предложенные мастером поля.

Первым идет настройка утверждений, где доступно более 100 атрибутов Active Directory, каждый из которых может присутствовать в claims. Для удобства поиска предложен фильтр. Например, атрибут departament описывает отдел, в котором работает пользователь. Последовательно отбираем нужные, создавая claims. Поле «Предложенные значения» позволяет указать требуемые значения атрибутов. Например, для departament прописываем названия отделов, для которых будем создавать политики.

Вторым шагом идет настройка свойств ресурсов (Resource Properties), позволяющих классифицировать конкретные файлы и папки. По умолчанию уже создано несколько свойств, которые нужно отредактировать и включить или добавить новые. Переходим к шагу три — созданию централизованного правила доступа (Central Access Rule), где выбираем критерии целевых ресурсов и разрешения. Процесс прост: выбираем из списков свойства, указываем значение и задаем права (система предложит разрешения, их можно отредактировать и применить). В итоге все ресурсы, которые будут помечены соответствующим тегом (указанным в значении), будут попадать под правило. Так как правил может быть несколько, то для удобства применения на следующем шаге их объединяют в политики (Central Access Policies).

После создания политик они должны быть опубликованы на файловом сервере. Для этого вызываем редактор групповой политики, переходим в «Конфигурация компьютера -> Политики -> Конфигурация Windows -> Файловая система -> Централизованная политика доступа». Выбираем в контекстном меню пункт «Управление централизованными политиками доступа» и в списке созданные ранее политики, которые необходимо применить. Собственно, это все.

Для управления аудитом следует перейти в «Конфигурация расширенной политики аудита -> Политика аудита -> Доступ к объектам», где в Win2012 появился новый пункт «Аудит сверки с централизованной политикой доступа».

Теперь применяем политику. Переходим в свойства документа/каталога, выбираем «Дополнительно» и переходим во вкладку «Централизованная политика», выбираем в раскрывающемся списке нужную политику.

Традиционно новая возможность получила свой набор из 58 командлетов PowerShell, которые относятся к модулю Active Directory (goo.gl/304CC). Например, при помощи Get-ADCentralAccessPolicy можем получить информацию обо всех центральных политиках доступа.

PS> Get-ADCentralAccessPolicy -Filter *

Аутентификация пользователей с Windows Azure AppFabric

Сегодня организация может использовать десятки серверов и приложений, размещенных на разных платформах, к которым необходимо обеспечить безопасный доступ. Если приложения разнородные и для идентификации используют разные стандарты, это становится проблемой. Microsoft предлагает для ее решения сервис Windows Azure AppFabric Access Control Service (ACS, goo.gl/2dmqR), позволяющий реализовать механизмы федеративной авторизации и обработку запросов на основе декларативных правил. Сервис, к которым обеспечивается доступ, не обязательно должен работать в среде Azure, это может быть любая (в том числе не Windows) платформа или приложение, работающее на популярных языках, включая Java, Ruby, PHP. Как ясно из названия, сервис относится к Azure Fabric и выступает в роли посредника между приложением и провайдерами идентификаций (identity providers) — базой данных пользователей. ACS использует принцип идентификации на основе заявок (claims-based identity), каждая сущность в процессе идентификации играет одну или более канонических ролей: субъект (subject), провайдер идентификации (identity provider), доверяющая сторона (relying party) и провайдер федерации (federation provider).

Поддерживаются стандартные механизмы аутентификации (OpenID, OAuth WRAP, OAuth 2.0, WS-Trust и WS-Federation), интеграция с Windows Live ID, Active Directory, Google, Yahoo!, Facebook и так далее. Сам AppFabric Access Control (ASC) базируется на Windows Identity Foundation (WIF, расширение Microsoft .NET Framework) и представляет собой сервис, специально созданный для обеспечения безопасности облачных вычислений. Модель WIF отделяет приложение от деталей того, как происходит аутентификация, и от низкоуровневых деталей, предлагая удобную абстракцию, позволяющую просто указывать внешний механизм. Все установки можно выполнить с помощью специального мастера в Visual Studio, писать код не требуется. Для новичков будут интересны примеры, позволяющие разобраться, как интегрировать ACS с веб-сервисами.

INFO

Windows Azure AppFabric состоит из трех основных компонентов: Access Control (управление доступом), Bus Service (Сервис шины) и Cache (Кеш — Ассоциативная память).

 

Биометрическая аутентификация

Требования к сложности пароля с каждым днем ужесточаются, также растет количество сервисов, с которыми приходится работать пользователю. Все это удержать в голове затруднительно, да и сотрудники часто забывают пароли, нагружая саппорт. Поэтому нередко юзеры идут на упрощения, используя одну комбинацию на разных ресурсах. Достаточно взломать один пасс, и получаем доступ ко всему остальному. Выхода два — использовать биометрическую или аппаратную (смарт-карты) аутентификацию. Это как минимум удобно, ведь уже не нужно ничего запоминать. При биометрии все необходимое у пользователя всегда с собой: для идентификации используются уникальные характеристики человека, наиболее популярен из методов отпечаток пальца. Раньше поддержка средств биометрической аутентификации обеспечивалась специальными драйверами и ПО, поставляемыми производителями. Для программистов производители предлагали собственный SDK (известны как коммерческие, так и опенсорсные решения). Каждый реализовывал механизм как хотел, единого стандарта не было. Начиная с Windows 7, Microsoft предлагает свой вариант — специальный фреймворк Windows Biometric Framework (WBF, goo.gl/QzYZK).

Управляют процессом при помощи четырех объектов групповой политики, которые находятся в «Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Биометрия». Изменилась в Win2012/8 и поддержка смарт-карт: появились виртуальные смарт-карты, изменился порядок взаимодействия с пользователем и логика запуска/остановки службы.

Заключение

Механизмы управления доступом, применяющиеся в различных ОС, сегодня вряд ли можно назвать достаточными. Новшества, которые появились в Win2012, позволяют на порядок снизить риски и обеспечить максимальную безопасность данных. Дело осталось за малым — их внедрить.

Сергей Яремчук, grinder@synack.ru