Настройка безопасности на windows server 2012

Вопрос безопасности сервера был и будет актуальным. Рассмотрим базовые правила обеспечения безопасности серверов под управлением ОС семейства Window Server.

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

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

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

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

Чем меньше TCP/UDP портов доступно извне, тем меньше шансов провести атаку на сервер. В этом вопросе важно разобраться что блокировать. Если речь идет о web-сервере, то доступными необходимо оставить 80 и 443 TCP-порты (эти порты служба слушает по умолчанию).

Это были публичные порты, но не стоит забывать, что существуют порты, доступ к которым должен предоставляться по принципу “белого” списка, т.е. только определенному кругу лиц. Пример портов:

• 3389 — RDP (Remote Desktop Protocol);
• 135-139 — NetBIOS;
• 445 — Samba (общий доступ к файлам и папкам);
• 5000 — 5050 — FTP в пассивном режиме;
• 1433 — 1434 — порты SQL;
• 3306 — стандартный порт MySQL;
• 53 — DNS

Создать правило не сложно. Открываем Пуск → Панель управления → Система и безопасность → Администрирование → Брандмауэр Windows в режиме повышенной безопасности.

В окне программы кликаем правой кнопкой мыши по “Правила для входящих подключений”. В открывшемся контекстном меню выбираем “Создать правило...”.

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

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

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

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

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

При использовании физического сервера (не удаленного и не виртуального), рекомендуется включить запрос пароля пользователя при выходе из режима ожидания. Данный параметр настраивается в панели управления: Панель управления → Все элементы панели управления → Электропитание.

Также важно установить лимиты бездействия пользователя, а “по возвращении” запросить пароль. Это исключит возможность входа другого лица от имени пользователя, в случае если тот отлучился или забыл закрыть RDP-сессию. Чтобы настроить этот пункт, следует воспользоваться настройкой локальных политик secpol.msc.

Мастер настройки безопасности (SCW – Security Configuration Wizard) позволяет создавать XML-файлы политик безопасности, которые впоследствии, можно перенести на другие серверы. Эти политики включают в себя не только правила использования сервисов, но и общие параметры системы и правила Firewall.

Кроме первоначальной настройки групповых политик Active Directory, периодически следует проводить их ревизию и повторную настройку. Это один из основных способов обеспечения безопасности Windows-инфраструктуры.

Для удобства управления групповыми политиками, можно воспользоваться не только встроенной в Windows Server утилитой «gpmc.msc», но и предлагаемую Microsoft утилиту «Упрощенные параметры настройки безопасности» (SCM-Security Compliance Manager).

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

Для управления локальными политиками вы можете использовать соответствующую оснастку «Локальная политика безопасности», вызываемую командой secpol.msc из Пуск -> Выполнить (клавиша Windows + R).

1. Блокировать RDP-подключения для пользователей с пустым паролем.

Наличие пользователей без паролей недопустимо, но если этого миновать не удается, то можно хотя бы запретить подключение к RDP. Для этого открываем Пуск → Средства администрирования.

В открывшемся каталоге, запускаем Локальная политика безопасности.

В окне локальный политик безопасности, слева, выбираем Локальные политики → Параметры безопасности. В основной части окна, находим “Учетные записи: Разрешить использование пустых паролей только при консольном входе”.

Выбираем этот пункт двойным кликом и переводим переключатель в положение “Отключен”. Нажимаем кнопку “OK”.

2. Поменять стандартный TCP-порт RDP.

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

Для замены порта:

1. открываем редактор Реестра Windows — Windows + R

2. На всякий случай, создаем резервную копию реестра (Файл → Экспорт)

3. Разворачиваем ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp и, в правой доле окна, находим параметр PortNumber.

4. Открываем параметр двойным кликом мыши. В открывшемся окне выбираем Систему исчисления: Десятичная, указываем новое значение порта, нажимаем кнопку “OK” и закрываем окно редактора реестра.

5. Чтобы была возможность подключиться к серверу, создаем соответствующее правило для Брандмауэра Windows. Кликаем правой кнопкой мыши по “Правила для входящих подключений”, в контекстном меню выбираем “Создать правило”.

В окне “Мастера”, выбираем “Для порта”

Затем выбираем “Протокол TCP”, “Определенные локальные порты” и указываем новый номер порта.

Следующим шагом выбираем “Разрешить подключение”

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

На итоговом шаге, указываем название правила и описание к нему.

6. Перезагружаем сервер чтобы применить изменения.

7. Для подключения к удаленному рабочему столу теперь используем IP-адрес или доменное имя, а через двоеточие указываем порт.

Служба “Шлюз TS (служб удаленных рабочих столов)” позволяет обезопасить подключение к удаленному рабочему столу путем использования протокола HTTPS(SSL), тем самым избавляя системного администратора от необходимости настройки VPN. Инструмент способен комплексно контролировать доступ к машинам, а также устанавливать правила авторизации и требования к удаленным пользователям, например:

• Пользователи или группы пользователей, которым разрешено подключаться к внутренним сетевым ресурсам;
• Сетевые ресурсы, к которым могут подключаться пользователи;
• Должны ли клиентские компьютеры иметь членство в Active Directory;
• Необходимо ли клиентам использовать проверку подлинности на основе смарт-карт или пароля, или они могут использовать один из вышеперечисленных способов аутентификации.

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

1. Открываем Диспетчер серверов.

2. Выбираем “Добавить роли и компоненты”

3. На этапе “Тип установки”, выбираем “Установка ролей и компонентов«.

4. Следующим шагом выбираем текущий сервер.

5. Роль сервера — Служба удаленных рабочих столов.

6. Переходим к службе ролей. Выбираем “Шлюз удаленных рабочих столов”.

7. Переходим к этапу подтверждения, нажимаем кнопку “Установить”.

После установки роли, в окне Диспетчера серверов, выбираем Средства → Remote Desktop Services → Диспетчер шлюза удаленных столов.

В открывшемся окне, в левой его части, нажимаем по значку сервера. В основной части окна, выбираем “Просмотр и изменение свойств сертификата”.

В открывшемся окне “Свойства” переходим на вкладку “Сертификат SSL”. Выбираем пункт “Создать самозаверяющий сертификат”, нажимаем кнопку “Создать и импортировать сертификат”.

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

В новом окне следует проверить параметры. Если все верно — нажимаем “OK”.

Новым окном система оповестит об успешном создании сертификата и выдаст путь до файла.

Переходим к окну свойств сервера. Нажимаем “Применить”.

В окне “Диспетчер шлюза удаленных рабочих столов”, в левой колонке, раскрываем ветку сервера, выбираем “Политики”, затем “Политики авторизации подключений”. В правой колонке того же окна, выбираем “Создать новую политику”  → “Мастер”.

В новом окне выбираем ”Создать только политику авторизации подключений к удаленным рабочим столам”, нажимаем “Далее”.

Указываем желаемое имя для политики. Мы рекомендуем указывать имя латиницей.

Следующим шагом будет выбор удобного метода аутентификации — пароль или смарт-карта. Оставляем отмеченным только “Пароль”. Нажимаем кнопку “Добавить группу…”

В окне выбора групп кликаем по кнопке “Дополнительно”.

Размер окна изменится. Кликаем по кнопке “Поиск”. В найденных результатах выбираем “Администраторы домена” и нажимаем кнопку “OK”.

В окне выбора группы проверяем выбранные имена объектов и нажимаем “OK”.

Группа добавлена. Для перехода к следующему шагу нажимаем кнопку “Далее”.

На следующем этапе выбираем пункт “Включить перенаправление устройств для всех клиентских устройств” и нажимаем “Далее”.

Настраиваем таймауты сессий. И действия по их истечении. Рекомендуем отключать сеанс, чтобы фоновые пользовательские процессы не отнимали процессорное время. Нажимаем “Далее”.

На крайнем этапе просматриваем сводку, нажимаем “Готово”.
На подтверждение создания политики нажимаем “Закрыть”.

Настроим политику авторизации ресурсов.

Процесс выполняется подобно предыдущему.

В окне диспетчера шлюза удаленных рабочих столов, раскрываем ветку Политики → Политики авторизации подключений. В правой части окна выбираем “Создать новую политику” → “Мастер”.

В открывшемся окне выбираем “Создать только политику авторизации ресурсов удаленных рабочих столов”, нажимаем кнопку “Далее”.

Первым шагом указываем желаемое имя для политики авторизации. Настоятельно рекомендуем указывать имя латиницей. Нажимаем кнопку “Далее”.

В окне выбора групп кликаем по кнопке “Дополнительно”.

Окно изменит размеры. Нажимаем кнопку “Поиск”. В результатах поиска находим “Администраторы домена” и нажимаем кнопку “OK”.

В окне выбора группы проверяем выбранные имена объектов и нажимаем “OK”.

Группа добавлена. Для перехода к следующему шагу нажимаем кнопку “Далее”.

На следующем шаге разрешаем подключение пользователей к любому сетевому ресурсу. Для этого выбираем соответствующий параметр и нажимаем кнопку “Далее”.

Настраиваем разрешенные порты. сли порт RDP-сервера не был изменен, то оставляем 3389. Нажимаем “Далее”.

Финальным этапом проверяем настройки и нажимаем кнопку “Готово”.

В обновленном окне нажимаем “Закрыть”.

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

Идеальный случай — один сервер выполняет одну конкретную функцию, например Контроллер домена или файловый сервер, или сервер терминалов. На практике, подобное разделение ролей труднодостижимо.

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

Обзор Windows Nano Server.

Дальнейшим развитием Windows Server Core стал Nano Server. Данная версия дистрибутива исключает использование графического интерфейса пользователя. Всё управление сосредоточено на WMI — инструментарий управления Windows, а также Windows PowerShell. Данный дистрибутив Windows-сервер имеет на 92% меньше критических рекомендаций безопасности. Nano Server доступен только для клиентов Microsoft Software Assurance и на платформах облачных вычислений, например, Microsoft Azure и Amazon Web Services. Начиная со сборки Windows Server 1709, Nano Server можно устанавливать только внутри хоста контейнера .

Эта статья предназначена для тех, кто занят вопросом обеспечения безопасности серверов, управляемых серверной операционной системой версий Microsoft Windows Server 2008/2012. В инструкции мы подробно разберем, как обеспечить безопасность работы. Обратите внимание, что только соблюдение всех условий, которые мы детально привели ниже, можно создать полноценную защиту от несанкционированных вторжений в инфраструктуру и максимально усилить безопасность вашего сервера, а также и клиентов, заходящих в систему.

Своевременная установка обновлений операционной системы и программного обеспечения

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

Соблюдение этого условия необходимо для:

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

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

Только проверенное программное обеспечение

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

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

Правильно устанавливайте брандмауэр

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

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

• 80 – HTTP;
• 443 — HTTPS .

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

• Войдите в правила брандмауэра ОС;
• Создайте список адресов, обращения с которых будут разрешены.

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

• 3389 – Стандартный порт RDP;
• 990 – FTPS;
• 5000-5050 – порты FTP, работающие в пассивном режиме;
• 1433-1434 – порты SQL;
• 53 – DNS.

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

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

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

• Введите комбинацию (WIN+R), после чего откроется окно, куда необходимо напечатать значение «secpol.msc» (без кавычек);
• Войдите в редактор локальной политики безопасности так, как изображено на картинке ниже. Найдите строку меню «Локальные политики», в выпадающем списке выберите параметры, далее вам необходимо найти строчку переименования имени учетной записи с расширенными правами;

  

• Поменяйте название и сохраните внесенные изменения.

Расширение списка административных аккаунтов

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

Ограничение прав учетной записи

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

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

Установка пароля для общего доступа и разграничение прав

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

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

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

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

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

• Войдите в панель управления;
• Найдите пункт «Электропитание» и откройте его;
• Выберите строку «Выбрать план электропитания».

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

• Открыть окно командой Win+R;
• Ввести данные secpol.msc;
• Настроить опцию.

Мастер настройки безопасности

Этот инструмент позволит вам создать XML-файлы политики безопасности, в последствии переносимые на серверы системы. Данные содержат информацию о правилах употребления серверов и брандмауэра, а также настройку общих параметров системы.

Правильная настройка групповой политики безопасности

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

Чтобы настройка была максимально удобной, можно воспользоваться двумя способами:

• Утилитой «gpmc.msc», которая уже включена в саму ОС;
• Утилитой SCM-Security Compliance Manager. Перейдите по ссылке, чтобы загрузить программу с официального сайта.

Переход к локальным политикам

Мы обсудили групповые политики, теперь рассмотрим локальную безопасность. Это важно делать в обязательном порядке, так как они касаются как прав клиентов, входящих на сервер, так и самих локальных аккаунтов. Чтобы успешно управлять политиками, подключите опцию, которую можно вызвать путем ввода secpol.msc в окно, открывающееся командой WIN+R.

Безопасность служб удаленных рабочих столов

Сначала рассмотрим записи, которые не содержат данных о заданном пароле.

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

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

• Открыть программу «Computer Configuration»;
• Далее перейти через настройки ОС в локальные политики;
• Откройте вкладку «Параметры» и поставьте галочку напротив того, что отображен на приведенном ниже изображении.

  

Смена стандартного порта

Смена Remote Desktop Protocol с того, что был установлен по умолчанию, считается весьма эффективной мерой для защиты от вредоносных атак, которые совершаются с целью анализа well-known портов. Чтобы сменить порт, нужно осуществить такие манипуляции:

• Войти в редактор реестра;
• Создать копию существующего файла;
• Открыть следующую директорию HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp;
• Как показано ниже, отыщите требуемый параметр и дважды кликните кнопкой мыши;
• Откроется новая страница, где нужно кликнуть по десятичному способу исчисления, а также поменять указанное значение порта на то, что требуется вам (в строке «Значение»);

  

• Щелкните по кнопке ОК и выйдите из программы.

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

• Войти в брандмауэр;
• Открыть строку «Дополнительные параметры» с левой стороны экрана;
• Перейти на «Правила входящих подключений», кликните по кнопке создания нового правила;

  

• Выберите значение «Для порта» в новом окне;
• Пропишите номер вашего порта и щелкните по кнопке «Готово», а далее перезагрузите устройство.

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

Настройка шлюза

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

Шлюз TS помогает осуществлять контроль над доступом к частям системы, а также создавать правила и требования к пользователям, например, такие:

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

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

Инсталляция службы

Чтобы процесс установки прошел успешно, нужно:

• Войти в управление сервером, открыть вкладку «Роли» и перейти к пункту добавления;
• На этой вкладке нужно открыть пункт «Службы терминара»;
• Кликните на шлюз TS;
• Откроется страница выбора, где нужно кликнуть на строку «Позже». Так необходимо поступить, потому что нужный сертификат службы пока еще не был нами сгенерирован, это будет сделано впоследствии;

  

• В новом окне вновь нажмите на строку «Позже;
• Отметьте галочкой пункт Network Policy Server, указанный на приведенном ниже рисунке;

  

• Ориентируясь на изображение, определите необходимые службы ролей, подходящие именно вам.

  

Генерация сертификата

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

• Войти в меню администрирования и нажать на IIS Manager;
• Слева на открывшейся странице нужно найти ваш сервер, после чего войти в меню создания сертификата домена, как это показано на рисунке ниже;

  

• Перейдите к окну «Определенные свойства имени», где нужно будет указать необходимые параметры. Особое внимание следует уделить полю, где вводится общее имя, значение строки должно соответствовать тому названию, которое указывалось ранее при настройке служб RDP;
• Откроется окно центра сертификации, где нужно выбрать Enterprise CA, далее следует ввести то же значение, что и в строке «Сетевое имя».

Если все было сделано верно, то обновленные сведения о сгенерированном сертификате будут отображены в строке «Сертификаты сервера». Если нажать на нужный сертификат, то должна открыться вся подробная информация о ключе, без которого не будет работать сертификат и объекте назначения. (Посмотрите, как это выглядит на изображении ниже).

Конфигурация службы терминалов при работе сгенерированного сертификата

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

• Перейдите в строку «Шлюз терминальных серверов», которую можно найти в списке служб удаленных рабочих столов в меню администрирования;
• В левой части экрана кликните по тому серверу, который должен исполнять роль шлюза, далее вы увидите, что необходимо будет сделать для завершения настройки;

  

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

  

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

• Войдите в меню «Политики авторизации соединений»;
• Выберите пункт создания TS CAP;
• Создайте название создаваемой политики, например, как указано на изображении;
• Перейдите к вкладке «Требования», где нужно ввести группы пользователей, которые будут иметь доступ, а также активировать проверку пароля. Чтобы создать группу, введите ее название и нажмите на кнопку проверки имен;

  

• Далее нужно отключить перенаправление для определенных типов устройств и разрешить его для клиентов;
• Проверьте все параметры и закройте мастер настройки.

  

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

• Войдите в меню политики авторизации ресурсов;
• Откройте панель «Менеджер шлюзов», где вы найдете пункт создания новой политики. Здесь нужно будет выбрать выберите TS RAP в качестве способа;

  

• Придумайте имя политики. Откройте перечень групп, где нужно будет выбрать только относящиеся к действию данной создаваемой политики;
• Во вкладке «Группа компьютеров» введите значение тех устройств, которые осуществляют работу согласно RAP;
• Проверьте введенные данные и выйдите из настройщика.

  

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

Защита сессии, проводимой через Remote Desktop Protocol с помощью соединений SSL/TLS

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

Включить эту функцию можно таким образом:

• Ввод команды gpedit.msc;
• Или вход в меню администратора, где необходимо открыть папку «Компоненты»;
• Войдите в сервер удаленных рабочих столов, откройте вкладку «Безопасность» и введите следующее значение, которое желательно должно быть равно SSL (TLS 1.0) only.

Второй способ активации опции:

• Войдите в панель управления сервером;
• В списке доступных подключений выберите нужное и откройте его свойства;
• В открывшемся окне выберите «Security Level».

Чтобы настроить туннелирование путем TLS, нужно вновь войти в панель управления сервером удаленных рабочих столов. Далее:

• Откройте список доступных подключений, в нем найдите необходимое вам, для которого будет настраиваться уровень защиты. Далее откройте выпадающее меню и выберите пункт «Свойства»;
• Найдите вкладку «Общие», там укажите уровень шифрования RDP FIPS140-1 Encryption.

Отключение и изоляция ролей и сервисов

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

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

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

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

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

Windows Server Core

Напоследок скажем несколько слов о таком дистрибутиве, как Windows Server Core. Программа представляет собой продукт для виртуального сервера, который мы и обсуждаем в данной статье.

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

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

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

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

На этом разбор основных рекомендаций по обеспечению безопасности в Windows Server 2008/2012 окончен. В нашей базе знаний вы найдёте ещё множество статей посвящённых различным аспектам работы в Windows, а если вы ищете надежный виртуальный сервер под управлением Windows, обратите внимания на нашу услугу — Аренда виртуального сервера Windows.

Мастер SCW можно запустить из окна Диспетчера сервера (Server Manager), или выбрав одноименную ссылку в окне Администрирование (Administrative Tools) в панели управления.

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

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

Для создания новой политики SCW должен проанализировать компьютер, определяя какие компоненты и роли тот поддерживает.  При нажатии кнопки «Далее» мастер запрашивает, какой компьютер следует использовать как базовый вариант (прототип) для новой политики. Обычно стоит выбирать локальный компьютер, но можно использовать в качестве прототипа и удаленный компьютер.

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

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

После анализа переходим непосредственно к настройке. Нажимаем кнопку «Далее» и попадаем в первый из четырех разделов SCW — настройку служб на основе ролей. Обратите внимание, что имеющиеся в SCW роли не совсем совпадают с ролями в мастере добавления ролей. SCW предлагает некоторые роли, не включенные в мастер добавления ролей.

По умолчанию показываются установленные роли, то есть роли, которые сервер потенциально способен поддерживать без установки дополнительных компонентов. Выбранные роли – это роли, которые он поддерживает в настоящий момент. Также можно выбрать показ всех ролей, для чего просто укажите «Все роли» в раскрывающемся списке. Это может понадобится при необходимости создать политику на сервере, на котором еще не установлены все необходимые роли. В любом случае, нам надо отметить только те роли, которые будет исполнять данный сервер (в нашем случае это сервер удаленного доступа).

Далее следует диалог выбора клиентских возможностей. Любой сервер является еще и клиентом, например обращается с запросами к DNS-серверу, получает обновления с сервера WSUS и т.д., и все это нужно учесть.

В следующем окне выбираем параметры управления сервером. Выбор включает оснастки, необходимые для управления выбранными ролями сервера. Кроме того, здесь можно разрешить удаленное управление сервером с помощью средств администрирования (напр. Server Manager).

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

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

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

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

Можно не производить настроек в разделе работы с сетью, тогда SCW создаст правила брандмауэра, блокирующие сетевые интерфейсы так, что будут доступны только выбранные роли и компоненты. А можно усилить безопасность сервера, дополнительно настроив предложенные правила. Для этого выбираем правило и нажимаем кнопку «Изменить».  Здесь можно затребовать проверку подлинности IPsec, включить шифрование, а на вкладке «Область» можно ограничить подключение только с определенных IP-адресов.

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

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

Затем следует выбор метода проверки подлинности (аутентификации) при подключении к удаленным компьютерам. Если сервер является членом домена, то однозначно выбираем доменные учетные записи, если нет — то локальные.

Если выбрана доменная аутентификация, то здесь можем ограничить общение нашего сервера с системами не ниже Windows NT 4.0 SP6A (если такие еще остались). А если клиенты должны синхронизировать свои системы именно с этим сервером, мы также можем выбрать эту опцию здесь, хотя по умолчанию большинство систем синхронизируют системное время с контроллером домена Active Directory.

И в завершение смотрим изменения в реестре.

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

Затем смотрим изменения, внесенные в политику аудита. Обратите внимание на то, что опция, включающая шаблон безопасности SCWaudit.inf по умолчанию включена. Этот шаблон служит для упрощения аудита доступа к файловой системе. Будьте осторожны — когда шаблон SCWaudit.inf применен, его нельзя удалить с помощью функции отката вSCW.

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

В завершение мастер предлагает нам выбрать, применить сразу созданную политику или отложить решение этого вопроса. Отмечаем нужный вариант, жмем кнопку «Далее», затем «Готово». На этом работа мастера завершена.

Также следует упомянуть об утилите командной строки scwcmd.exe, при помощи которой можно производить некоторые действия с созданными политиками:

• scwcmd view /x:<Policyfile.xml> — просмотр созданной политики;
• scwcmd configure /p:<Policyfile.xml> — применение созданной политики;
• scwcmd rollback  — откат последней примененной политики;
• scwcmd transform /p:<Policyfile.xml> /g:<GPODisplayName> — преобразование политики в объект групповой политики (GPO).

Полный набор возможностей утилиты можно посмотреть командой scwcmd /?

Защита информации на уровне операционных систем Windows Server 2012

Защита информации на уровне операционных систем

Требования к защите информации

Обеспечение защиты средств вычислительной техники (СВТ) и
автоматизированных систем (АС) осуществляется системой разграничения
доступа субъектов и объектов доступа, а также обеспечивающими средствами
для этой системы.

Концепция защиты средств вычислительной техники и автоматизированных систем
от несанкционированного доступа к информации утверждена решением
Государственной технической комиссии при Президенте Российской Федерации от
30 марта 1992 г.

Способы реализации системы разграничения доступа (СРД) зависят от
конкретных особенностей СВТ и АС. Возможно применение следующих способов
защиты и любых их сочетаний:

• распределенная СРД и СРД, локализованная в программно-техническом комплексе (ядро защиты);
• СРД в рамках операционной системы, СУБД или прикладных программ;
• СРД в средствах реализации сетевых взаимодействий или на уровне приложений;
• использование криптографических преобразований или методов непосредственного контроля доступа;
• программная и (или) техническая реализация СРД.

В случае использования средств защиты от НСД в государственных информационных системах (ГИС) они должны
быть сертифицированы минимум по 6-ому классу. Средства вычислительной техники при этом должны быть
сертифицированы не менее чем по 5-ому классу.

Кроме того, в ГИС первого и второго классов защищенности
средства защиты от НСД должны быть сертифицированы не ниже чем по 4 уровню
контроля отсутствия недекларированных возможностей.

В информационных системах персональных данных (ИСПДн):

• в ИСПДн 1 уровня защищенности — средства защиты от НСД не ниже 4 класса, а СВТ — не ниже 5 класса;
• в ИСПДн 2 уровня защищенности — средства защиты от НСД не ниже 5 класса, а СВТ — не ниже 5 класса;
• в ИСПДн 3 уровня защищенности — средства защиты от НСД не ниже 6 класса, а СВТ — не ниже 5 класса;
• в ИСПДн 4 уровня защищенности — средства защиты от НСД не ниже 6 класса, а СВТ — не ниже 6 класса.

В ИСПДн первого и второго уровня защищенности должны использоваться
средства защиты информации, также сертифицированные не ниже чем
по 4 уровню
контроля отсутствия недокументированных возможностей (НДВ).

Данные о сертификации средств защиты находится в Государственном реестре
сертифицированных средств защиты информации, администрируемом ФСТЭК России.
В частности, для продукции компании Microsoft имеем:

Классы защищенности СВТ от НСД

ФСТЭК России устанавливает семь классов защищенности СВТ от НСД к
информации. Самый низкий класс — седьмой, самый высокий — первый. Классы
подразделяются на четыре группы, отличающиеся качественным уровнем защиты:

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

Требования безопасности информации к операционным системам

Требования безопасности информации к операционным системам утверждены
приказом ФСТЭК России от 19 августа 2016 г. №119, вступили в силу с 1 июня
2017 г. Устанавливают 3 типа (А, Б, В)
и 6 классов защиты ОС:

• Тип А – ОС общего назначения,
• Тип Б – встраиваемая ОС,
• Тип В – ОС реального времени.

6 класс – самый низкий, 1 класс – самый высокий

Операционные системы 6 класса защиты применяются
в ГИС 3 и 4 классов
защищенности, в АСУТП 3 класса защищенности, в ИСПДн при необходимости
обеспечения 3 и
4 уровней защищенности персональных данных

Операционные системы 1, 2, 3 класса применяются в информационных системах,
обрабатывающих государственную тайну.

Профили защиты операционных систем

Профили защиты операционных систем подробно рассмотрены в следующих методических документах ФСТЭК России:

• Методические документы. Профили защиты операционных систем типов «Б» и «В“. Утверждены ФСТЭК России 11 мая 2017 г.
• Методические документы. Профили защиты операционных систем типа «А“. Утверждены ФСТЭК России 8 февраля 2017 г.

Операционная система Microsoft Windows Server 2012 имеет развитые
встроенные механизмы и средства защиты, а именно:

• разграничение прав и полномочий пользователей с помощью учётных записей и групп;
• разграничение прав (разрешений) на доступ к объектам (на уровне объекта);
• локальная политика безопасности и групповые политики;
• защита реестра и ограничение прав доступа к нему;
• использование шифрующей файловой системы EFS и шифрование диска BitLocker;
• средства обеспечения безопасности сетевых подключений;
• средства аудита.

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

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

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

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

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

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

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

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

Для любого объекта вы можете предоставить разрешения:

• группы, пользователи и другие объекты с идентификаторами безопасности в домене;
• группы и пользователи в этом домене и любые доверенные домены;
• локальные группы и пользователи на компьютере, где находится объект.

Права доступа к объекту зависят от типа объекта. Например, разрешения,
которые можно прикрепить к файлу, отличаются от разрешений, которые можно
прикрепить к разделу реестра. Однако некоторые разрешения являются общими
для большинства типов объектов:

• чтение;
• изменение;
• смена владельца;
• удаление

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

Локальная групповая политика (gpedit.msc)

Политики параметров безопасности — это правила, которые можно настроить на
компьютере или нескольких компьютерах для защиты ресурсов на компьютере или
в сети. Расширение Параметры безопасности
оснастки Редактор локальной
групповой политики (Gpedit.msc)
позволяет определять конфигурации безопасности как часть объекта групповой политики
(GPO). Объекты групповой политики связаны с контейнерами Active Directory,
такими как сайты, домены и организационные единицы, и позволяют администраторам управлять
параметрами безопасности для нескольких компьютеров с любого компьютера,
присоединенного к домену.

Настройки безопасности могут контролировать:

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

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

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

Локальная политика безопасности

Помимо использования групповых политик безопасности Active Directory
следует также использовать локальные политики, так как они затрагивают не
только права пользователей, выполняющих вход через доменную учетную запись,
но и локальные аккаунты. Для управления локальными политиками нужно
использовать соответствующую оснастку Локальная политика безопасности,
вызываемую командой secpol.msc (Выполнить (WIN+R)).

Например, при помощи локальной политики безопасности можно блокировать
RDP-подключения для учетных записей с пустым паролем:

Computer Configuration — Настройки Windows — Настройки безопасности
— Локальные политики безопасности — Параметры безопасности и включите
(Enable) параметр Учетные записи: Разрешить использование пустых паролей
только при консольном входе:

Защита реестра Windows

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

Либо можно через редактор локальной групповой политики полностью запретить доступ к средствам редактирования реестра:

Нажать комбинацию клавиш Win+R, в окне редактирования
следует ввести: gpedit.msc Откроется редактор локальной
групповой политики. В нем в Конфигурация пользователя выбрать
Административные шаблоны далее Система. Из списка найти пункт
Запретить доступ к средствам редактирования реестра и кликнуть на нем
дважды. Выбрать Включить и затем нажать ОК

Шифрующая файловая система EFS

Шифрованная система Encrypting File System (EFS) позволяет быстро
зашифровать и поставить пароль на ваши файлы и папки в системе windows,
используя собственную учетную запись пользователя. Поскольку файлы или
папки были зашифрованы с использованием пароля учетной записи пользователя
windows, другие пользователи на вашей системе, включая администратора, не
может открыть, изменить или переместить папки, или файлы. Система EFS
является полезной, если вы не хотите, чтобы другие пользователи смотрели
ваши файлы и папки.

Encrypting File System и BitLocker это разные системы для шифрования. EFS
считается менее безопасной, чем BitLocker. Любое лицо, знающее пароль
учетной записи, под которой было произведено шифрование, может легко
получить доступ к зашифрованной информации. Вы не сможете шифровать целые
разделы диска, EFS работает только с файлами и папками, а BitLocker
наоборот, только с дисками и съемными носителями.

Средства безопасности сетевых подключений

Операционная система Windows Server 2012 имеет развитые средства
безопасности сетевых подключений:

• брандмауэр Windows в режиме повышенной безопасности;
• политика сети и удаленного доступа — служба маршрутизации и удалённого доступа;
• преобразование сетевых адресов NAT;
• криптографическая аутентификация, использование цифровых подписей и сертификатов безопасности;
• использование виртуальных частных сетей (VPN);
• шифрование передаваемых данных, возможность использования безопасного IP-протокола – Ipsec и протокола TLS.

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

Подробнее средства безопасности сетевых подключений рассмотрены в материале
Техническая защита информации в локальных и глобальных сетях»

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.

Доменом в  Windows Server называют отдельную область безопасности компьютерной сети.

В домене может быть один или несколько серверов выполняющих различные роли. Разрешения, применяемые администратором, распространяются на все компьютеры в домене.

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

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

Несколько доменов имеющих одну и ту же конфигурацию и глобальный каталог называют деревом доменов. Несколько деревьев могут быть объединены в лес.

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

Параметры групповой политики хранятся в виде объектов групповой политики (Group Policy Object, GPO). Эти объекты хранятся в каталоге подобно другим объектам. Различают два вида объектов групповой политики  –  объекты групповой политики, создаваемые в контексте службы каталога, и локальные объекты групповой политики.

Не будем подробно вдаваться в теорию и перейдем к практике.

Запускаем Диспетчер серверов -> «Добавить роли и компоненты».

На первой странице мастер напоминает, что необходимо сделать перед началом добавления роли на сервер. Нажмите «Далее».

На втором шаге нужно выбрать «Установка ролей и компонентов» и нажать «Далее».

Выбираем сервер, на который нужно установить Active Directory (он у нас один), «Далее».

Теперь нужно выбрать роль, которую нужно добавить. Выбираем «Доменные службы Active Directory». После чего откроется окно, в котором будет предложено установить службы ролей или компоненты, необходимые для установки роли Active Directory, нажмите кнопку «Добавить компоненты», после чего кликните «Далее».

PЗатем нажимайте «Далее», «Далее» и «Установить».

Перезапустите компьютер.

После того, как роль была добавлена на сервер, необходимо настроить доменную службу, то есть установить и настроить контроллер домена.

Настройка контроллера домена Windows Server

Запустите «Мастер настройки доменных служб Active Directory», для чего нажмите на иконку «Уведомления» в диспетчере сервера, затем нажмите «Повысить роль этого сервера до уровня контроллера домена».

Выберите пункт «Добавить новый лес», затем введите имя домена в поле «Имя корневого домена». Домены в сети Windows имеют аналогичные названия с доменами в интернете. Я ввел имя домена buzov.com. Нажимаем «Далее».

На этом шаге можно изменить совместимость режима работы леса и корневого домена. Оставьте настройки по умолчанию. Задайте пароль для DSRM (Directory Service Restore Mode – режим восстановления службы каталога) и нажмите «Далее».

Затем нажимайте «Далее» несколько раз до процесса установки.

Когда контроллер домена установиться компьютер будет перезагружен.

Добавление и настройка групп и пользователей в домене Windows Server

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

Отроем «Пользователи и компьютеры Active Directory». Для этого перейдите в Пуск –> Панель управления –> Система и безопасность –> Администрирование –> Пользователи и компьютеры Active Directory.

Создадим отдел «Бухгалтерия», для этого выделите название домена и вызовите контекстное меню, в котором выберите (Создать – Подразделение). Введите имя отдела (бухгалтерия) и нажмите «OK»

Подразделения служат для управления группами компьютеров пользователей. Как правило их именуют в соответствии с подразделениями организации.

Создайте учетную запись пользователя в новом подразделении. Для этого в контекстном меню нового подразделения выберите пункт Создать –> Пользователь. Пусть первым пользователем будет Бухгалтер.

После ввода имени пользователя и учетной записи нажмите «Далее». Теперь нужно ввести пароль. По умолчанию пароль должен соответствовать требованиям сложности, то есть содержать три из четырех групп символов: заглавные буквы, строчные буквы, цифры, специальные знаки ( . , + – = ? № $ и так далее). Установите параметр «Требовать смену пароля при следующем входе в систему».

Создайте учетную запись группы безопасности. Для этого в контекстном меню нового подразделения (бухгалтерия) выберите пункт (Создать – Группа). При создании новой группы безопасности необходимо ввести имя, область действия и тип группы. Область действия определяет видимость данной группы в службе каталога. Глобальная группа видна в любом домене службы каталога и ей могут назначаться привилегии доступа к ресурсам других доменов. Локальная группа видна только в своем домене, то есть ей будут доступны ресурсы только ее домена. Группы безопасности позволяют
объединять пользователей и другие группы для назначения им одинаковых привилегий на различные объекты. Группы распространения используются для рассылки сообщений, они не участвуют в разграничении прав доступа.

Теперь нужно ввести компьютер в домен и зайти под новым пользователем. Для этого на клиентском компьютере нужно указать DNS-адрес. Для этого откройте «Свойства сетевого подключения» (Пуск –> Панель управления –> Сеть и Интернет – >Центр управления сетями и общим доступом – Изменение параметров адаптера), вызовите контекстное меню подключения и выберите «Свойства».

Выделите «Протокол Интернета версии 4 (TCP/IPv4)», нажмите кнопку «Свойства», выберите «Использовать следующие адреса DNS-серверов» и в поле «Предпочитаемый DNS-сервер» укажите адрес вашего DNS-сервера. Проверьте, что задан IP-адрес и маска той же подсети, в которой находится сервер.

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

Откройте свойства системы (Пуск –> Панель управления –> Система и безопасность –> Система –> Дополнительные параметры системы). Выберите вкладку «Имя компьютера» и нажмите «Изменить». Выберите «Компьютер является членом домена» и введите имя домена.

После этого необходимо ввести логин и пароль пользователя с правами присоединения к домену (обычно администратора домена). Если вы всё указали правильно, то появиться приветственное сообщение «Добро пожаловать в домен …».

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

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

После ввода пароля операционная система попросит вас сменить пароль.

Вернемся на сервер. Нажмите «Пуск» -> Администрирование и перейдите в окно Управления групповой политикой. Выбираем наш лес, домен, Объекты групповой политики, щелкаем правой кнопкой мыши -> создать. Называем его buh (это объект групповой политики для группы Бухгалтерия).

Теперь необходимо привязать данный объект групповой политики к созданной группе. Для этого нажмите правой кнопкой на созданное подразделение (Бухгалтерия) и выберите «Связать существующий объект групповой политики…», затем выберите созданный ранее объект в списке и нажмите «ОК».

Далее выбираем созданный объект.

Выбранный объект должен появиться в списке связанных объектов групповой политики. Для редактирования параметров, определяемых данным объектом, нажмите на него правой кнопкой и выберите «Изменить».

Установка параметров безопасности

Установка параметров безопасности — завершающий этап настройка домена и групповых политик в Windows Server.

Ограничения парольной защиты

Ограничение на параметры парольной системы защиты задаются в контексте «Конфигурация компьютера». Выберите Конфигурация Windows –> Параметры безопасности –> Политики учетных записей –> Политика паролей.

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

1. «Минимальный срок действия пароля» задает периодичность смены пароля.
2. «Минимальная длина пароля» определяет минимальное количество знаков пароля.
3. «Максимальный срок действия пароля» определяет интервал времени, через который разрешается менять пароль.
4. «Пароль должен отвечать требованиям сложности» определяет требования к составу групп знаков, которые должен включать пароль.
5. «Хранить пароли, используя обратимое шифрование» задает способ хранения пароля в базе данных учетных записей.
6. «Вести журнал паролей» определяет количество хранимых устаревших паролей пользователя.

Тут нужно указать необходимые параметры (определите самостоятельно).

Политика ограниченного использования программ

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

Выберите раздел Конфигурация пользователя –> Политики –> Конфигурация Windows –> Параметры безопасности –> Политики ограниченного использования программ. Нажмите правой кнопкой на «Политики ограниченного использования программ», далее заходим в «Дополнительные правила» и жмем правой кнопкой мыши, затем выбираем «Создать правило для пути».

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

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

Запрет запуска командной строки (cmd.exe).

На этом все. Если у вас остались вопросы, обязательно задайте их в комментариях.

При попытке запустить командную строку на клиентской машине вы получите сообщение.