Защитные механизмы ос windows server 2012

Windows Server 2012 и Hyper-V  —  фундаментальные строительные блоки частного «облака» Microsoft. Вместе с новейшей серверной операционной системой Microsoft поставляется гипервизор Hyper-V 3.0, в котором произошли многочисленные изменения. Hyper-V 3.0 может стать первой платформой виртуализации Microsoft, по своим достоинствам вполне сопоставимой с VMware vSphere.

Среди изменений Hyper-V  —  несколько новых функций, направленных на повышение безопасности. Виртуализация сети Network Virtualization  —  первый шаг Microsoft к централизованно программируемым сетям Software-Defined Networking (SDN). В SDN управление сетевым трафиком возлагается на программы, исполняемые не на физическом оборудовании сети. В результате мы получаем более гибкое управление и точную настройку сети. С точки зрения безопасности, благодаря SDN и виртуализации сети компании и поставщики услуг «облака» могут надежнее изолировать виртуальные машины на сетевом уровне.

В Hyper-V 3.0 также реализовано множество мелких, но не менее важных изменений, относящихся к безопасности. Например, это расширяемый коммутатор виртуальной сети, новая группа администраторов Hyper-V и усовершенствованное шифрование дисков BitLocker.

Определение виртуализации сети

Благодаря виртуализации сети возможности изолирования виртуальных машин расширяются с узла на сетевой уровень. Изоляция  —  необходимое условие многоабонентских «облачных» решений, в которых приложения и службы различных компаний или подразделений размещаются в одном физическом сервере и сетевой инфраструктуре. Например, поставщик «облака», который размещает службы для компаний Apple и Samsung, наверняка не заинтересован в том, чтобы сотрудники Apple заглядывали в виртуальные машины и сеть Samsung, и наоборот.

Подобно тому, как виртуализация сервера дает возможность установить несколько изолированных виртуальных машин на одном узле, виртуализация сети Hyper-V 3.0 позволяет запускать несколько изолированных виртуальных сетей в одной физической сети. В виртуализации сети задействован программный уровень абстракции, расположенный поверх физической сети и основанный на концепции виртуальных подсетей. Виртуальная подсеть образует границу широковещательной передачи пакетов, и только виртуальные машины в одной виртуальной подсети могут устанавливать связь друг с другом. Таким образом, с помощью виртуальных подсетей администраторы могут организовать различные изолированные домены широковещательной передачи между виртуальными машинами.

Hyper-V поддерживает использование виртуальных локальных сетей VLAN для создания изолированных виртуальных сетей с момента выхода Windows Server 2008, но масштабируемость и гибкость виртуальных локальных сетей ограничены. Виртуальные локальные сети поддерживают лишь определенное число изолированных сетей клиентов. Основная причина в том, что коммутаторы, как правило, поддерживают не более 1000 идентификаторов VLAN из теоретического максимума 4096. По данным Microsoft, виртуализация сети обеспечивает функционирование более 16 млн виртуальных сетей.

Кроме того, виртуальным локальным сетям не хватает гибкости. Они плохо приспособлены для динамической «облачной» среды, в которой виртуальные машины клиентов регулярно появляются и исчезают в центре обработки данных и перемещаются между физическими серверами в целях балансировки нагрузки и управления вычислительными ресурсами. Управление VLAN отличается сложностью и требует изменения конфигурации на уровне коммутатора при перемещениях виртуальных машин на другой уровень. Операционная система Server 2012 также совместима с частными виртуальными локальными сетями PVLAN благодаря расширению на уровне виртуального коммутатора Hyper-V. PVLAN увеличивают уровень изоляции между виртуальными машинами, но не решают проблему сложности управления VLAN на виртуальных и физических сетевых устройствах. С этой проблемой можно справиться только с помощью виртуализации сетей.

Внутренний механизм виртуализации сетей

Для виртуализации сети каждой виртуальной машине назначается два IP-адреса. Один IP-адрес видим для виртуальных машин и имеет значение только в контексте данной виртуальной или централизованно программируемой сети клиентов. Этот адрес называется адресом клиента Customer Address (CA). Второй IP-адрес имеет значение только в контексте физической сети. Этот адрес называется адресом поставщика Provider Address (PA). Разделение на CA и PA приносит ряд преимуществ.

Прежде всего, это позволяет переносить виртуальные машины между центрами обработки данных. Благодаря новому уровню абстракции можно переместить виртуальные машины в центр обработки данных другого поставщика «облачных» услуг без изменения IP-адреса виртуальных машин или конфигурации сети и всех основанных на IP-адресе политик внутри компании. Кроме того, более не нужно беспокоиться о конфигурации IP-адресов виртуальных машин других клиентов, размещенных в том же центре обработки данных. При включенной виртуализации сети виртуальные машины с одинаковыми IP-адресами могут сосуществовать на одном узле Hyper-V и даже в одной сети без конфликтов IP-адресов.

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

Помимо адресов CA и PA, при виртуализации сети используется третий важный компонент: идентификатор виртуальной подсети VSID. Каждая виртуальная подсеть при виртуализации сети уникально идентифицируется посредством VSID. С помощью идентификаторов VSID узлы Hyper-V отмечают трафик из различных виртуальных подсетей соответствующими тегами и различают трафик виртуальных машин с одинаковыми CA. Программная логика виртуализации сети инкапсулирует VSID, CA и PA в каждый сетевой пакет.

Чтобы распространить конкретные сети клиентов на несколько виртуальных подсетей (и таким образом IP-подсетей), идентификаторы VSID можно сгруппировать в одну сеть клиентов, которая уникально идентифицируется с использованием идентификатора домена маршрутизации RDID. В этих ситуациях изоляция виртуализации сети будет применяться на уровне определенных сетей клиентов. В этом еще одно отличие между виртуальными сетями Network Virtualization и традиционными VLAN: сети VLAN могут быть связаны только с одной IP-подсетью.

Виртуализация сети требует только узла Hyper-V Server 2012. При виртуализации сети гостевой операционной системе в виртуальной машине неизвестно, что ее IP-адрес виртуализован. С точки зрения виртуальных машин все связи устанавливаются с использованием CA. Это также означает, что виртуальная машина, которая является частью сети на основе Network Virtualization, может работать с любой операционной системой: не только Windows 8 и Server 2012, но и более старыми версиями Windows и других операционных систем.

На экране 1 показаны принципы организации виртуализации сети. В сущности, виртуализация сети реализуется как новый сетевой драйвер (ms_netwnv), который может быть привязан к физическим сетевым адаптерам на каждом физическом сервере и виртуальном сервере Server 2012. Новый виртуальный коммутатор Hyper-V, к которому мы еще вернемся в данной статье, вызывает этот сетевой драйвер для инкапсуляции и деинкапсуляции сетевых пакетов при сетевой виртуализации.

Экран 1. Реализация виртуализации сети в качестве драйвера сетевого фильтра

Транспортировка и маршрутизация при виртуализации сети

Для транспортировки и маршрутизации IP-пакетов с виртуализованными адресами CA через физическую сеть могут использоваться два механизма. В основе первого из них лежит протокол туннелирования Generic Routing Encapsulation (GRE), определенный в документах RFC 2784 и 2890. В этом контексте GRE используется для инкапсуляции сетевых пакетов, формируемых виртуальной машиной (с адресом CA), в пакеты, формируемые узлом (с адресом PA). Совместно с другими компаниями, занимающимися «облачными» технологиями (HP, Intel, Emulex, Dell и другими), Microsoft представила в комитет IETF проект, цель которого  —  сделать стандартом разновидность GRE для Network Virtualization (под названием NVGRE).

Второй механизм, переопределение IP-адреса, можно сравнить с преобразованием сетевых адресов Network Address Translation (NAT). Этот механизм переопределяет пакеты с виртуализованными адресами CA в пакеты с PA, которые можно маршрутизировать по физической сети.

На момент подготовки данной статьи переопределение IP-адреса больше подходит для виртуальных машин с высокими требованиями к пропускной способности (10 Гбит/с) благодаря использованию механизмов разгрузки сетевого адаптера на аппаратном уровне, таких как разгрузка больших пакетов large send offload (LSO) и очередь виртуальных машин virtual machine queue (VMQ). Существенный недостаток переопределения IP-адреса заключается в необходимости одного уникального PA для каждого CA виртуальной машины. В противном случае было бы невозможно распознавать и маршрутизировать сетевые пакеты, исходящие и поступающие в виртуальные машины разных клиентов с перекрывающимися IP-адресами.

Для GRE требуется только один PA на узел, поэтому Microsoft рекомендует использовать NVGRE при переопределении IP-адресов для виртуализации сети. NVGRE можно реализовать, не внося изменений в архитектуру физического сетевого коммутатора. Туннели NVGRE завершаются на узлах Hyper-V и выполняют всю инкапсуляюцию и деинкапсуляюцию сетевого трафика GRE.

Недостаток GRE состоит в невозможности задействовать механизмы разгрузки сетевого адаптера на аппаратном уровне. Поэтому, если вы планирует использовать NVGRE для виртуализации сети с высокой пропускной способностью, рекомендуется подождать выпуска сетевых адаптеров с функцией разгрузки NVGRE. Microsoft ожидает, что такие платы для Server 2012 появятся в продаже в 2013 году. При использовании GRE не забудьте о брандмауэрах, в которых по умолчанию могут быть заданы правила для блокирования GRE. Всегда проверяйте, разрешен ли туннельный трафик GRE (IP Protocol 47) в брандмауэре.

Реализация Network Virtualization

Процесс реализации и настройки Network Virtualization в Hyper-V 3.0 отличается от настройки частных локальных сетей в Hyper-V. Частные локальные сети можно настроить из диспетчера Hyper-V в настройках сетевого адаптера виртуальных машин. Настройка виртуализации сети не является частью настройки виртуальных машин и не может быть выполнена из диспетчера Hyper-V. Это объясняется тем, что виртуализация сети основывается на определенных политиках, применяемых на уровне виртуального коммутатора узла Hyper-V.

Чтобы определить политики виртуализации сети локально на узле, необходимо использовать сценарии Windows PowerShell. Для централизованного определения политик можно задействовать графический интерфейс диспетчера Microsoft System Center Virtual Machine Manager (VMM) с пакетом обновления 1 (SP1). VMM  —  унифицированное решение Microsoft для управления виртуальными машинами. В крупной среде Network Virtualization настоятельно рекомендуется использовать VMM. VMM может запускать нужные команды PowerShell от имени пользователя и применять политики виртуализации сети на узле Hyper-V через локальные агенты узла System Center. Важное ограничение, существующее на данный момент, заключается в том, что графический интерфейс VMM можно использовать только для задания политик переопределения IP-адресов. Чтобы назначить политики NVGRE, необходимо задействовать сценарии PowerShell. Начинающие пользователи могут освоить приемы настройки Network Virtualization через PowerShell с помощью примера сценария на PowerShell в демонстрационном пакете Simple Hyper-V Network Virtualization Demo, подготовленном компанией Microsoft (http://gallery.technet.microsoft.com/scriptcenter/Simple-Hyper-V-Network-d3efb3b8).

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

Шлюзы Network Virtualization поставляются в различных конструктивных вариантах. Они могут быть построены на шлюзе VPN, который формирует VPN-соединение, чтобы связать две виртуальные сети через физическую сеть. Для этой цели можно использовать сервер Server 2012, на котором выполняется служба маршрутизации RRAS. Функциональность шлюза Network Virtualization может быть предоставлена и выделенным сетевым устройствам (например, коммутаторам, сетевым устройствам), которые действуют как шлюз маршрутизации для виртуализации сети. На данный момент шлюзовые устройства Network Virtualization выпускаются или готовятся к выпуску компаниями F5 Networks и nAppliance Networks. Настроить шлюзы Network Virtualization можно с помощью PowerShell. Начинающим полезно познакомиться с примером сценария в статье Microsoft «Simple Hyper-V Network Virtualization Script with Gateway» (http://gallery.technet.microsoft.com/scriptcenter/Simple-Hyper-V-Network-6928e91b).

К счастью, существуют расширения VMM SP1 для централизованного и автоматического управления политиками шлюза Network Virtualization. При создании или обновлении виртуальной машины VMM может автоматически обновить топологию маршрутизации каждого устройства шлюза Network Virtualization. Дополнительные сведения о шлюзах Network Virtualization можно найти в статье Microsoft «Hyper-V Network Virtualization Gateway Architectural Guide» (http://technet.microsoft.com/en-us/library/jj618319.aspx).

Гораздо более подробная общая информация о виртуализации сети приведена в статье Microsoft «Microsoft Windows Server 2012 Hyper-V Network Virtualization Survival Guide» (http://social.technet.microsoft.com/wiki/contents/articles/11524.windows-server-2012-hyper-v-network-virtualization-survival-guide.aspx). Хорошую сводку шагов для настройки виртуализации сети можно найти в блоге Microsoft TechNet «Step-by-Step: Hyper-V Network Virtualization» (http://blogs.technet.com/b/keithmayer/archive/2012/10/08/gettingstartedwithhypervnetworkvirtualization.aspx).

Расширяемый виртуальный коммутатор

В Hyper-V 3.0 появились важные изменения в архитектуре виртуального коммутатора (теперь именуемого расширяемым коммутатором). Этот виртуальный сетевой коммутатор уровня 2 может быть настроен на каждом узле Hyper-V и находится на перекрестке сетевого трафика между виртуальными машинами, между виртуальными машинами и узлом Hyper-V и трафиком с внешними компьютерами. Расширяемый коммутатор  —  компонент Hyper-V, который применяет политики виртуализации сети и располагает другими интересными функциями, относящимися к безопасности.

Партнеры Microsoft могут расширять возможности коммутаторов с использованием платформы Windows Filtering Platform (WFP) или фильтров network device interface specification (NDIS) для мониторинга и изменения сетевых пакетов, авторизации соединений или фильтрации трафика. Благодаря новой архитектуре расширяемый коммутатор поможет применить политики безопасности и изолирования при подключении виртуальных машин к сети. Виртуальный коммутатор  —  идеальное место для проверки данных, пересылаемых между виртуальными машинами, при поиске опасных программ. Классические средства противодействия вредоносному программному обеспечению и несанкционированному доступу обычно не проверяют этот трафик с его помощью и анализируют только трафик между физическими узлами. Некоторые партнеры Microsoft уже работают с расширяемыми коммутаторами: компания sFlow со своим расширением для мониторинга; 5nine, которая выпустила расширение виртуального брандмауэра; NEC, подготовившая расширение для мониторинга на основе OpenFlow. OpenFlow  —  важный открытый протокол для сетей SDN.

Новый расширяемый коммутатор также поддерживает определение PVLAN. Администраторы могут строить частные виртуальные локальные сети, назначая виртуальную машину основной виртуальной локальной сети, а затем одной или нескольким вторичным виртуальным локальным сетям. Используя эти частные виртуальные локальные сети, администраторы обеспечивают связь виртуальных машин только с виртуальными машинами с таким же идентификатором или идентификаторами VLAN, или с любой другой виртуальной машиной с таким же основным идентификатором VLAN, независимо от дополнительного идентификатора VLAN. Как отмечалось выше, использование частных виртуальных локальных сетей не позволяет уменьшить сложность управления VLAN с охватом виртуальных и физических сетевых устройств. Эти проблемы можно решить только с помощью виртуализации сети.

Еще одна мощная функция расширяемого коммутатора  —  политики изоляции на основе списков контроля доступа ACL, которые можно определить и применять на виртуальных портах расширяемого коммутатора. В сущности, в этих политиках перечислены правила разрешения и запрета, которые изолируют виртуальные машины и не позволяют им связываться с другими виртуальных машин в зависимости от IP- или MAC-адресов. Политики изоляции расширяемого коммутатора можно определить и из диспетчера VMM.

Наконец, в расширяемом коммутаторе реализованы такие новые функции безопасности, как DHCP Guard, разгрузка операций IPsec Task Offload, задачи IPsec и защита от подделки протокола разрешения адресов Address Resolution Protocol (ARP). С помощью DHCP Guard можно запретить виртуальным машинам работать в качестве сервера DHCP. DHCP Guard отвергает любые пакеты, отправляемые виртуальными машинами, которые указывали бы, что это сервер DHCP. DHCP Guard  —  свойство, которое можно настроить для любого сетевого адаптера виртуальной машины. Сделать это можно из диспетчера Hyper-V, в разделе дополнительных параметров сетевого адаптера в свойствах виртуальных машин, как показано на экране 2. Рекомендуется включить этот режим при создании «золотого» образа виртуальных машин.

Экран 2. Включение DHCP Guard

Разгрузка операций IPsec позволяет Hyper-V передать обработку, связанную с IPsec, в сетевой адаптер. Это возможно только в том случае, если сетевой адаптер поддерживает данную функцию. Разгрузка операций IPsec позволяет сократить рабочую нагрузку на процессор узла Hyper-V, связанную с использованием алгоритмов шифрования IPsec. Можно также включить этот режим из диспетчера Hyper-V: используйте раздел Hardware Acceleration в параметрах сетевого адаптера в свойствах виртуальных машин, как показано на экране 3.

Экран 3. Включение разгрузки операций IPsec

Расширяемый коммутатор обеспечивает защиту от подмены ARP, чтобы вредоносные виртуальные машины не могли предпринять атаку типа man-in-the-middle. В ходе такой атаки вредоносная машина использует ложные сообщения ARP, чтобы связать фальшивые MAC-адреса с не принадлежащими ей IP-адресами. В результате обманутые машины могут отправлять сообщения вредоносной машине. Чтобы включить защиту от подмены ARP, необходимо оставить флажок Enable MAC address spoofing (включить спуфинг MAC-адресов) в изначальном состоянии (сброшен).

Чтобы упростить настройку расширяемого коммутатора и его расширений, Microsoft предоставляет команды PowerShell. Вы можете использовать их для создания автоматизированных сценариев для настройки, мониторинга и диагностики расширяемого коммутатора.

Упрощенное делегирование и расширение BitLocker

В Hyper-V 3.0 упрощено административное делегирование благодаря появлению локальной группы безопасности Hyper-V Administrators. Члены новой группы имеют полный доступ ко всем функциям Hyper-V. Администраторам следует использовать эту группу для управления доступом к Hyper-V вместо того, чтобы добавлять пользователей к локальной группе Administrators. Кроме того, новая группа отчасти заменяет диспетчер Windows Authorization Manager (AzMan), который в прошлом был единственным доступным способом организации административного делегирования в Hyper-V. Администраторы могут по-прежнему использовать AzMan для делегирования, требующего большего уровня детализации и выходящего за рамки назначения полной роли администратора Hyper-V.

Наконец, нужно указать, что в Server 2012 можно воспользоваться новыми функциями шифрования BitLocker на уровне томов для защиты конфиденциальности и целостности образов виртуальных машин, хранящихся в местах с ненадежной физической защитой. В Server 2012 технология BitLocker расширена для шифрования томов операционной системы и данных на дисках в отказоустойчивых кластерах, в том числе общих томах кластеров. Дополнительные сведения можно найти в статье «BitLocker в Windows 8», опубликованной в Windows IT Pro/RE № 10 за 2012 год.

Важные отличия от средств безопасности vSphere

Новые функции безопасности  —  важное отличие Hyper-V от ближайшего конкурента, VMware vSphere. Хороший пример  —  расширяемый коммутатор Hyper-V. VMware также предоставляет виртуальный сетевой коммутатор, но он доступен только в редакции высокого уровня vSphere Enterprise Plus, цена которой, естественно, выше. Коммутатор vSphere не открытый, не расширяемый и не располагает передовыми функциями защиты (например, DHCP Guard и списки ACL виртуального порта) коммутатора Hyper-V. Чтобы дополнить vSphere такими функциями, необходимо приобрести дополнительные программы, например компонент App комплекса VMware vCloud Networking and Security (vCNS).

То же справедливо и для компонента Hyper-V Network Virtualization. Чтобы получить аналогичную функциональность в среде vSphere, потребителям необходимо обратиться к комплексу vCNS, в котором реализована технология VXLAN. Для VXLAN требуется коммутатор vSphere Distributed Switch (VDS), который есть только в редакции высокого уровня vSphere. Ожидается, что VMware скоро реализует централизованно программируемые сети SDN благодаря приобретению компании Nicira.

Отменная гибкость

Таким образом, Hyper-V 3.0 располагает мощными новыми функциями безопасности, которые позволят повысить гибкость и управляемость многоабонентских «облаков» на основе Hyper-V. Пришло время поближе познакомиться с новым продуктом Hyper-V. Кроме того, обязательно изучите новые возможности VVM SP1, незаменимый инструмент для управления развертыванием Hyper-V.

 АНДРЕЙ БИРЮКОВ, специалист по информационной безопасности. Работает в крупном системном интеграторе. Занимается внедрением решений по защите корпоративных ресурсов, mex_inet@rambler.ru

Новое в Windows Server 2012 R2:
целостность, конфиденциальность и доступность

Новая операционная система Windows Server 2012 R2 содержит ряд нововведений в области защиты информации. Хотя основные изменения связаны с виртуализацией, разработчики ОС подумали и о безопасности

Информационные технологии не стоят на месте, и с каждым годом все новые требования предъявляются и к встроенным механизмам безопасности операционных систем.

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

Существенные изменения также происходят с приложениями и данными. Современные бизнес-приложения становятся все более сложными и более требовательными к производительности систем. Объемы данных постоянно увеличиваются, что тоже сказывается на требованиях к оборудованию.

Как известно, основу информационной безопасности составляют три понятия: конфиденциальность, целостность, доступность. Посмотрим на то, как эти принципы реализованы в новой операционной системе в Windows Server 2012 R2. Начнем с изучения механизма работы с файлами и папками как средствами обеспечения целостности хранимой информации.

Work Folders локальный DropBox

Проблема контроля версий при работе с документами с нескольких устройств всегда была актуальна, однако с развитием мобильности пользователей стала еще важнее. Традиционным решением является синхронизация файлов между устройствами. Конечно, можно хранить данные в облаке, однако для тех, кто по каким-либо причинам (безопасность, медленные каналы доступа в Интернет и т.д.) не хочет размещать данные на сторонних ресурсах, в новой операционной системе предлагается использовать Work Folders (Рабочие папки). С помощью этой службы можно синхронизировать свои папки с любыми устройствами посредством корпоративного файлового сервера. К данным пользователей на внутреннем хранилище применяются такие стандартные политики, как квотирование, блокировка запрещенных типов файлов, а также динамический контроль доступа. Последний мы рассмотрим более подробно.

Процесс работы достаточно прост: при каждом подключении пользователя к серверу Work Folders производится синхронизация с сохранением более новых версий документов. Пользователь может редактировать файлы оффлайн, после подключения они будут перенесены на сервер.

Для работы Work Folders требуется наличие установленной роли файлового сервера, которая в случае отсутствия добавляется автоматически.

Рисунок 1. Выбор роли Work Folders

Для настройки используется мастер создания общего ресурса синхронизации. Рабочие папки также возможно интегрировать со службой Active Directory Rights Management Services, позволяющей обеспечить защиту пользовательских данных.

К сожалению, не все так хорошо с поддержкой данной технологии со стороны клиентов. На данный момент Work Folders работает только с ОС Windows 8.1. Планируется появление клиента для Windows 7, Windows 8, Android и iOS. Обсудив обеспечение целостности, перейдем к вопросам конфиденциальности.

Статью целиком читайте в журнале «Системный администратор», №11 за 2013 г. на страницах 36-39.

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

Список использованной литературы:

1. 3ds Max 9: трехмерное моделирование и анимация / В.Т. Тозик, А.В. Меженин. — СПб.: БХВ-Петербург, 2007.

2. Меженин А.В., Семёнова Е.Е. Оценка методов построения пространственных моделей // Образование и наука: современное состояние и перспективы развития. Том 3 — 2015. — С. 64-65

3. Augment Reality. Мобильное приложение дополненной реальности. URL: http://www.augmentedev.com/

4. Unity3d. Игровой движок. URL: https://unity3d.com/ru

© А.В. Меженин, © Ю.В. Бочарова, 2016

УДК 004

К.В. Мисюрина, М.Н. Рудикова, Н.А. Овчинников

Студент

Институт приоритетных технологий Волгоградский Государственный Университет Г. Волгоград, Российская Федерация

ИССЛЕДОВАНИЕ ПРОГРАММНЫХ ИНТЕРФЕЙСОВ УПРАВЛЕНИЯ МЕХАНИЗМАМИ ЗАЩИТЫ, ВСТРОЕННЫХ В ОПЕРАЦИОННУЮ СИСТЕМУ WINDOWS SERVER 2012 R2

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

В результате исследования данного вида системы на основе анализа требований к функциональности сервера был получен следующий минимальный список ролей и служб, необходимый для работы сети: AD DS, DNS, DHCP, RDS, «Файловый сервер».

Программные интерфейсы, позволяющие выполнить автоматизированную настройку механизмов защиты Windows Server 2012 R2:

1) PowerShell (интерактивная командная строка и среда исполнения сценариев Windows, позволяет управлять пользователями и группами, организационными подразделениями в организации и т.д.);

2) Microsoft Visual Studio Express C# (среда разработки программного обеспечения на языке С#, позволяющая обеспечить доступ к GPO — Объектам групповой политики);

3) Реестр Windows Server 2012 R2 (база данных, где хранятся значения параметров операционной системы и установленных приложений).

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

Роли и службы AD DS DNS DHCP RDS ФнiLшвый сервер

Управление User/OU/ Group ( i )

Создание G PO ( II )

Настройка парольной политики (II)

Настройка 1 User-1 АРМ { (I)

Отключение па 1 ом ати чес кого обновления PNS-AD

Ис по Львова F не D N SS ЕС

Мониторинг DNS-адресов

Мониторинг аренды DHCP

Резервация IP-Адресов

Фильтрация по M АС-адресам

Подхват службы DHCP

Вкл/Выкл RDP ( III )

Отключение нескольких сеансов IUW 1 user ( III )

Включение HTI_Mv2 Принудительно < IЕI>

Ограничение перечня пользователей, которым доступен RDP ( II )

Применение

файловой системы Rc F S

Настройка нрав доступа

Шифрование при помощи ЕРБ

Использование ВйЬосксг(Ш)

Создание резервной коини

Аудит доступа к файлам((I )

Способ пля авт оматшацин

Управление пользователями/ Организационными il од р а Ч: i с л с 11 и п м ц/ Группами

(POWERSHELL)

IIJ.

Доступ к ключам реестра (С#М ic roso ft. Regis t г y)

Рисунок 1 — Механизмы защиты Windows Server 2012 R2

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

Список использованной литературы

1. Рэнд Моримото, Майкл Ноэл, Гай Ярдени, Омар Драуби, Эндрю Аббат, Крис Амарис. Microsoft Windows Server 2012. Полное руководство.-Москва,2013. -1456с.

2. Громов, Ю.Ю. Информационная безопасность и защита информации: Учебное пособие / Ю.Ю. Громов, В.О. Драчев, О.Г. Иванова. — Ст. Оскол: ТНТ, 2010. — 384 с.

3. Руслан Карманов. Основы Windows Server 2012 Я2.-Россия, 2013.-765 с.

4. Партыка, Т.Л. Информационная безопасность: Учебное пособие / Т.Л. Партыка, И.И. Попов. — М.: Форум, 2012. — 432 с.

5. Бабаш, А.В. Информационная безопасность. Лабораторный практикум: Учебное пособие / А.В. Бабаш, Е.К. Баранова, Ю.Н. Мельников. — М.: КноРус, 2013. — 136 с.

© К.В. Мисюрина, М.Н. Рудикова, Овчинников Н.А. 2016

В серии прошлых публикаций посвященных безопасности серверных платформ мы неоднократно рассказали о GNU Linux, его механизмах и средствах защиты. Сегодня очередь дошла и до «золотого стандарта» — платформы Microsoft Windows Server. В сегодняшней статье будут обзорно собраны общие рекомендации и технологии применимые для повышения уровня безопасности Windows Server 

1. Изоляция серверных ролей

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

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

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

Дополнительную экономию средств на серверы можно получить за счет виртуализации серверов. Например, лицензия на редакцию Windows Server 2008 R2 Enterprise предусматривает возможность размещения до четырех виртуальных машин при условии, что на сервере установлена только роль Hyper-V.

2. Форсирование безопасности DNS  с помощью DNSSEC

Недостатки открытого DNS-севера

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

Проблема в том, достоверность ответа DNS-сервера никак не проверяется, это означает, что в случае взлома DNS сервера (и перенаправления его на ложные DNS сервера), подделки DNS записи, отравлении кэша DNS (DNS cache poisoning), можно отправить пользователя на произвольный IP адрес, причем пользователь будет находится в полной уверенности, что он работает с легитимным сайтом или сервисом. Этими методиками широко используют злоумышленники, перенаправляя пользователей на сайты, содержащие вредоносные коды или собирая их личные данные (пароли, номера кредиток и т.п.) с помощью т.н. pharming атак.

Зачем нужна технология DNSSEC

DNS Security Extensions (DNSSEC) – технология, предназначена для повышения безопасности службы DNS за счет использования криптографических подписей, позволяющих однозначно удостоверится в подлинности информации, полученной от DNS сервера. Т.е. все запросы и ответы DNS сервера с поддержкой DNSSEC должны обладать цифровой подписью, верность которой может проверить клиент с помощью открытого ключа. Эти цифровые подписи создаются при подписывании зоны (применения к ней DNSSEC).

Упрощенно механизм проверки DNSSEC работает так: клиент отправляет запрос на DNS сервер, сервер возвращает DNS ответ с цифровой подписью. Т.к. клиент обладает открытым ключом центра сертификации, подписавшего записи DNS, он может расшифровать подпись (хэш-значение) и проверить ответ DNS. Для этого и клиент и сервер DNS должны быть настроены на использование одного якоря доверия (trust anchor).Trust anchor – предварительно настроенный открытый ключ, связанный с конкретной зоной DNS. Если DNS сервер поддерживает несколько зон, то может использоваться несколько якорей доверия.

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

Основные компоненты DNSSEC определены в следующих стандартах RFC:

RFC 4033

RFC 4034

RFC 4035

DNSSEC в системах Windows

Поддержка технология DNSSEC появилась еще в Windows Server 2008 R2 и Windows 7. Однако из-за сложности и неочевидности настроек, широкого распространения она не получила. Свое дальнейшее развитие DNSSEC получила в Windows Server 2012, в котором функционал DNSSEC был существенно расширен, и предполагает возможность настройки через графический интерфейс.

3. Изменяем стандартный порт RDP-сессий

По умолчанию RDP слушает tcp порт 3389, брутфорсеры и прочие злодеи постоянно сканируют сеть на наличие открытого порта 3389 и 445, подбирая пароли, кормят протокол эксплоитами, сервер из за этого в лучшем случае может зависнуть или уйти в BSOD, а в худшем он может быть скомпрометирован. Поэтому стоит изменить стандартный порт 3389 на любой другой, свободный порт. Сделать это можно специальной утилитой от microsoft или изменив ключ реестра. 

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

4. Конфигурируем брендмауэр: запрещаем всё кроме нужного

Редактируем правила входящих подключений в брандмауре, отключаем всё что не нужно, например обычно на веб-сервере не нужно ничего кроме:

5. Защита от намеренного подбора паролей к учетных записям

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

Заходим в локальную политику Control PanelSystem and SecurityAdministrative ToolsLocal Security Policy

Переходим в Account Policies — Account Lockout Police

Account lockout threshold — Тут задается кол-во неудачных попыток входа до блокировки учетной записи (Устанавливаем 5 попыток, этого вполне достаточно)

Account lockout duration — Через сколько учетная запись будет автоматически разблокирована (Устанавливаем 20 минут)

Reset account lockout counter after — Сброс счетчика неудачных попыток входа (Устанавливаем 20 минут)

6. Изменяем имя локального администратора

Заходим в локальную политику Control PanelSystem and SecurityAdministrative ToolsLocal Security Policy

Переходим в Local Policies — Security Options — Account: Rename administrator account

Открываем правило и вводим новое имя учетной записи администратора.

Примечание: Выше есть правило отключения аккаунта администратора (Accounts: Administrator account status), но лучше просто переименовать, дело в том что учетные записи пользователей блокируются после определенного кол-ва неудачных попыток входа в систему, и только аккаунт администратора не подвержен блокировкам, сделано это специально, чтобы администратор не потерял контроль над сервером в период блокировки всех остальных учетных записей.

7. Отключаем показ пользователей сервера при интерактивном подключении.

Переходим в Local Policies — Security Options и меняем следующие привила:

Interactive logon: Display user information when the session is locket

Открываем правило и в выпадающем меню выбираем «Do not display user information»

Interactive logon: Do not display last user name

Открываем правило и выставляем «Enabled»

8. Patch-менеджмент (политика обновлений)

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

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

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

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

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

Технология базируется на трех основных понятиях:

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

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

10.  Используйте технологию доступа к сети NAP

Microsoft разработала технологию NAP (Network Access Protection), которая представлена в серверной операционной системе Windows Server 2008. Данная технология предназначена для блокирования/постановки в карантин компьютеров, не соответствующих политикам, принятым в локальной сети. Таким образом обеспечивается защита локальной сети. 

Технология NAP предлагает различные варианты реализации: выдача IP-адресов из различных диапазонов для «хороших» и «плохих» компьютеров; установление соединения IPSec с «хорошими» компьютерами, в то время как «плохим» компьютерам в соединении будет отказано. 

С помощью NetWork Access Protection администраторы компании могут поддерживать состояние «здоровья» сети. Параметры системы клиента проверяются на соответствие политике безопасности, например: наличие свежих обновлений операционной системы, наличие антивирусной программы и состояние её обновлений, установлен и работает ли на клиенте сетевой экран. На основе этих параметров каждый компьютер получает свою оценку безопасности. Компьютер, удовлетворяющий требованиям системы контроля, получает доступ в сеть предприятия. Компьютеры, не удовлетворяющие требованиям безопасности, не смогут получить доступа в сеть или смогут получить доступ лишь в изолированную часть сети, предоставляющую сервисы для достижения клиентом требуемого уровня безопасности.

На WindowsITPro вышла интересная статья Windows Server 2012 Active Directory Security Changes, посвященная ключевым изменениям Active Directory в Windows Server 2012.
Статья большая, поэтому я решил разбить ее на две части. В первой части мы остановимся на динамическом контроле доступа (Dynamic Access Control), который представляет собой большой шаг вперед в модели авторизации в Windows и Active Directory. Во второй части будут рассмотрены другие изменения в AD Server 2012, которые касаются вопросов безопасности, а именно:

• Новые функции управления безопасностью в ADAC (графический интерфейс корзины AD и гранулярных политик паролей),
• Сервисные учетные записи, управляемые группами (Group Managed Service Accounts)
• Первичные компьютеры.

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

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

Динамический контроль доступа представляет собой наиболее фундаментальное изменение в плане безопасности, которое включено в Server 2012. Динамический контроль доступа интегрирует в себе модель контроля доступа на основе заявок (claims-based access control — CBAC) с моделью ОС Windows и AD. Заявки (claims) представляют собой своеобразные утверждения о пользователях или устройствах (например, “Имя моей учетной записи JanDC”, “Я состою в отделе продаж” и т.д.), которые выпускаются доверенными источниками (trusted authority). Microsoft впервые представила CBAC в Active Directory Federation Services v 1.0 (ADFS v1) в Windows Server 2003.

Заявки могут представить гибкий механизм для обмена доверенными идентификационными атрибутами между ADFS серверами. Организации теперь могут использовать заявки для защиты данных в файле и папке, хранящихся на доменных (domain-joined) машинах под Windows Server 2012 или Windows 8. Контроллеры домена в Server 2012 могут выпускать заявки (claim statements) в ходе аутентификации пользователя или машины; осуществляется это путем включения заявки в аутентификационный билет (authentication ticket) пользователя или машины. (Более подробная информация о заявках и том, как Microsoft использует их, находится на MSDN A Guide to Claims-based Identity and Access Control.)

Динамический контроль доступа основан на нескольких новых и усовершенствованных функциях авторизации данных в Windows, которые предназначены для:

• Классификации и тегирования данных
• Применения настроек контроля доступа на основе заявок (CBAC)
• Аудита доступа к данным
• Шифрования данных.

С точки зрения разработчиков в динамический контроль доступа были внесены многочисленные изменения в ключевые компоненты, службы и протоколы Windows. Они касаются AD, объектов групповых политик, DNS, Kerberos, Local Security Authority (LSA) и Netlogon процессов, равно как и такие сетевых протоколов как Server Message Block (SMB), LDAP и удаленный вызов процедур (remote procedure call – RPC). Microsoft привнесла несколько изменений в Server 2012, которые были обусловлены появлением динамического контроля доступа:

• Расширение логики контролера домена и Kerberos Key Distribution Center (KDC) для того, чтобы активировать выпуск заявок и токенах аутентификации (authentication tokens)
• Изменение формата токена Kerberos для осуществления транспортировки заявок
• Добавлены альтернативные потоки данных (alternate data streams — ADS) в NTFS, добавлена поддержка кастомных свойств для файлов и папок
• Включено хранение конфиденциальных выражений в ACL файла и папки для осуществления гибкого контроля доступа и настройки аудита
• Расширена схема AD, что теперь позволяет осуществлять централизованное хранение свойств и политик динамического контроль доступа.

Политики центрального доступа

Динамический контроль доступа может использовать AD для хранения политик центрального доступа (central access policies — CAP); делается это для того, чтобы применить эти политики к членам домена. В диалоговом окне Advanced Security Settings для папок была добавлена вкладка Central Policy (показано на рисунке 1). Из этой вкладки, администраторы могут выбрать политику центрального доступа (CAP), которую они хотят присвоить заданной папке. Теперь можно задавать политику доступа к файлам и папкам в вашем домене или лесе, основываясь на значениях стандартных и кастомных атрибутов ваших объектов AD (пользователи или компьютеры). Например, вы можете отказать пользователю в доступе к сетевой папке на файловом сервере, если атрибут Department пользовательского объекта AD не содержит значение “Sales» или «Marketing.» Эта гибкая логика авторизации очень отличается от той логики, которая была раньше (SID пользователя и группы).

Центральные политики доступа (CAP) можно задать из контейнера динамического контроля доступа (DAC), который представлен в обновленном Active Directory Administrative Center (ADAC), что показан на рисунке 2, или c помощью PowerShell комендлетов. С помощью тех же инструментов можно активировать поддержку заявок (claim statements) для объектов AD (пользователи и компьютеры) и добавить значения этим атрибутам. Контроллер домена Server 2012 добавит заявки (claim statements) к токенам авторизации пользователя и компьютера только в том случае, если атрибуты этих объектов действительно содержат информацию и связаны с активированным типом заявки. Перед тем как ваш контроллер домена в Windows Server 2012 сможет выпускать заявки, эту фунцию необходимо включить; имейте ввиду, что КД в Server 2012 по умолчанию не активны для использования CBAC. Чтобы включить CBAC, используйте настройку объекта групповой политики Domain Controller support for Dynamic Access Control and Kerberos armoring в контейнере Computer ConfigurationPoliciesAdministrative TemplatesSystemKDC. Чтобы использовать объекты групповых политик для распространения CAP на ваши машины, вы можете использовать опцию объекта групповой политики Central Access Policy в контейнере Computer ConfigurationPoliciesWindows SettingsSecurity SettingsFile System.

Аудит доступа к файлам и папкам в Windows Server 2012

С введением динамического контроля доступа заявки можно гибко использовать не только для делегирования доступа к файлам и папкам, но и для аудита доступа к ним. Например, в Server 2012 мы можете настроить правило аудита для отслеживания всех пользователей, которым был предоставлен или запрещен доступ к папкам, которые помечены как “конфиденциальные” (свойство “confidential”). Чтобы централизованно задать настройки аудита для файлов и папок на основании заявок, используйте объект групповой политики Global Object Access Auditing, который Microsoft представила в Windows Server 2008 R2 и который теперь расширен с помощью динамического контроля доступа.

Администраторы могут задавать гибкие настойки контроля доступа и аудита доступа к файлам и папкам; это осуществлять как в качестве добавления, так и независимо от централизованно определённых CAP’ов. Были изменены диалоговые окна в Advanced Security Settings в Windows 8 и Server 2012, чтобым можно было задавать условные выражения (conditional expressions) при настройке авторизации и аудита файлов и папок. Рисунок 3 показывает этот новый интерфейс, иллюстрируя тем самым определение разрешения, которые включает условное выражение в папку, названную SharedData.

Классификация данных

Помимо аудита и контроля доступа Dynamic Access Control также дает новые гибкие механизмы классификации данных. Теперь можно добавить кастомные свойства файлу или папке, которые получили название свойства глобальных ресурсов (global resource properties); это осуществляется через диалоговые окна настроек аудита и контроля доступа. Снова, вы можете сделать то же самое с помощью ADAC или PowerShell командлетов. Чтобы распространить (propagate) эти кастомные свойства на ваши доменные компьютеры, Microsoft оснастила клиенты Windows 8 и Server 2012 специальными расширениями, которые используют LDAP, чтобы подключиться к AD и извлечь эти свойства. Эта новая функция классификации дает вам осуществлять гибкую классификацию данных на основе выбранных вами атрибутов и, соответственно, применять защиту.

Вы можете классифицировать файлы и папки вручную, используя вкладку Classification в свойствах файла или папки, как показано на рисунке 4. Эта вкладка появляется только в системах, в которых присутствует установленная функция Desktop Experience и которая хостит (host) File Server Resource Manager role service

Автоматизация процесса классификации файлов

Процесс классификации файлов можно автоматизировать, если использовать функцию File Classification Infrastructure (FCI). FCI была представлена в Server 2008 R2 и позволяет администраторам определять кастомные классификационные ярлыки (теги), устанавливать правила классификации и истечения ее срока и формировать отчеты по классификациям. Администраторы могут управлять FCI прямо из File Server Resource Manager (FSRM). FCI может быть использована с RMS Bulk Protection Tool, чтобы автоматически применять RMS защиту к файлам.

Это довольно короткое введение в динамический контроль доступа. Подробную информацию (настройка, конфигурирование, решение проблем) можно найти в white paper от Microsoft («Understand and Troubleshoot Dynamic Access Control in Windows Server 8 Beta».)