Г л а в а 14 Безопасность при пересылке данных в этой главе



Скачать 177.78 Kb.
Pdf просмотр
Дата24.12.2016
Размер177.78 Kb.
Просмотров148
Скачиваний0

Г Л А В А
14
Безопасность при
пересылке данных
В ЭТОЙ ГЛАВЕ...
Введение в безопасность при пересылке данных

в Windows Server 2012
Развертывание инфраструктуры открытых ключей

с помощью Windows Server 2012
Служба сертификации Active Directory в Windows Server 2012

Служба управления правами AD CS

Шифрование IPsec в Windows Server 2012


Безопасность при пересылке данных
451
Глава 14
В прошлом сети представляли собой замкнутые среды, изолированные друг от друга и доступные только во внутренних сегментах. Обмен данными был ограничен отдельными сетями и редко выходил за их пределы. Со временем, когда появилась необходимость обме- на информацией между этими сетями, были установлены соединения для передачи данных из одной сети в другую. Однако вначале передача этой информации была незащищенной, и в случае перехвата информация легко могла быть прочитана посторонними. Поэтому не- обходимость защиты такой информации стала одним из основных приоритетов и жизнен- но важным компонентом сетевой инфраструктуры.
Со временем была разработана как технология защиты этой информации, так и техно- логия взлома и получения несанкционированного доступа к данным. Несмотря на эту опас- ность, продуманное проектирование и конфигурирование безопасных транспортных реше- ний с помощью Windows Server 2012 способно существенно повысить безопасность сети. Во многих случаях применение таких решений совершенно обязательно, особенно для данных, которые пересылаются через неконтролируемые сегменты сети наподобие Интернета.
В этой главе основное внимание уделено существующим механизмам защиты и шифро- вания информации, пересылаемой между компьютерами сети. Особое внимание уделено новым и усовершенствованным средствам безопасности транспортного уровня в Windows
Server 2012, с разбором конкретных ситуаций. Более подробно рассмотрены и проиллюс- трированы возможности IPsec, инфраструктуры общедоступных ключей (PKI) и виртуаль- ных частных сетей (VPN). Кроме того, здесь описаны специфические средства — служба сертификации Active Directory ( Active Directory Certificate Services — AD CS) и служба уп- равления правами Active Directory ( Active Directory Rights Management Services — AD RMS)
Windows Server 2012.
Введение в безопасность при передаче
данных в Windows Server 2012
Защита данных при их передаче означает предотвращение несанкционированного до- ступа к данным в процессе обмена информацией между клиентом и сервером или между серверами. В дополнение к физической и сетевой защите, реализация безопасности на транспортном уровне является еще одним уровнем защиты, важным для проектирования и создания защищенной сетевой среды.
Необходимость безопасности транспортного уровня
В связи с природой взаимосвязанных сетей вся информация должна пересылаться в формате, доступном для перехвата любым клиентом в каком-либо физическом сегменте сети. Данные должны быть организованы в однотипные структуры, чтобы сервер-адресат мог преобразовать их в соответствующую информацию. Однако эта простота порождает и проблемы безопасности, поскольку перехваченные данные при попадании в чужие руки легко могут быть использованы в неблаговидных целях.
Необходимость обеспечения неприменимости информации в случае ее перехвата ле- жит в основе всех методов шифрования на транспортном уровне. Обе противоборствую- щие стороны предпринимают значительные усилия: специалисты по безопасности разра- батывают схемы шифрования и маскирования данных, а хакеры и другие специалисты по безопасности разрабатывают способы успешной расшифровки и перехвата данных. К счас- тью, технология шифрования разработана уже до такой степени, что правильно сконфи- гурированные среды могут достаточно успешно защитить свои данные при использовании надлежащих средств. Windows Server 2012 предоставляет большое количество средств бе- зопасности транспортного уровня, и для надежной защиты важных данных рекомендуется использовать одну или несколько из этих технологий.

Безопасность
452
Часть IV
На современных предприятиях и необходимых для их работы технологиях существуют различные группы пользователей и прочие сущности, которые взаимодействуют с систе- мами и надежны в разной степени. Такая разнообразная среда усложняет защиту данных в сети, и необходим дополнительный слой гибких и динамичных инструментов, которые могут защищать будет с учетом их внутреннего содержимого и внешнего контекста.
Обеспечение безопасности с помощью многоуровневой защиты
Поскольку даже наиболее защищенные инфраструктуры имеют уязвимые места, ре- комендуется применять многоуровневую защиту особо важных сетевых данных. В случае взлома одного уровня защиты взломщику для получения доступа к важным данным придет- ся преодолеть второй или даже третий уровень системы безопасности. Например, слож- ная, “не поддающаяся взлому” 256-битовая схема шифрования оказывается бесполезной, если взломщик просто выведает пароль или PIN-код у законного пользователя с помощью социотехнических приемов. Дополнение системы безопасности вторым или третьим уров- нем сделает взлом всех уровней значительно более сложной задачей.
Средства защиты данных при их передаче в Windows Server 2012 используют несколько уровней аутентификации, шифрования и авторизации для повышения уровня безопаснос- ти сети. Возможности конфигурирования, предоставляемые Windows Server 2012, позволя- ют установить несколько уровней безопасности транспортного уровня, обеспечивающих защиту конфиденциальности и целостности данных.
Н
А ЗАМЕТКУ
Безопасность с несколькими уровнями защиты — концепция не новая, она заимствована из военной стратегии, которая справедливо утверждает, что несколько линий обороны более эффективны, нежели одна.
Понятие шифрования
В упрощенной формулировке шифрование — это процесс такого искажения осмыслен- ной информации, чтобы она стала бессмысленной для любого, кроме пользователя или ком- пьютера, для которого она предназначена. Если не слишком вникать в нюансы конкретных методов шифрования данных, то важно лишь понять, что правильное шифрование позво- ляет передавать данные по незащищенным сетям наподобие Интернета и преобразовывать их в пригодную для использования форму только в пункте назначения. В случае перехвата пакетов надежно зашифрованной информации они окажутся бесполезными, поскольку ин- формация искажена до неузнаваемости. Все описанные в этой главе механизмы используют ту или иную форму шифрования для защиты содержимого пересылаемых данных.
Развертывание инфраструктуры открытых
ключей с помощью Windows Server 2012
Понятие инфраструктуры открытых ключей ( Public Key Infrastructure — PKI) употреб- ляется везде и вовсю, но нечасто сопровождается подробным объяснением. Если говорить кратко, инфраструктура открытых ключей — это совокупность цифровых сертификатов, бюро регистрации и центров сертификации, которые проверяют подлинность каждого участника обмена зашифрованными сообщениями. По сути, сама по себе инфраструктура открытых ключей — просто концепция, которая определяет механизмы защиты данных от чтения при их передаче и проверки подлинности пользователя, передавшего эти данные.
Реализации PKI широко распространены и становятся исключительно важным компонен- том современных реализаций сетей. Как описано в последующих разделах, Windows Server
2012 полностью поддерживает развертывание нескольких конфигураций PKI.

Безопасность при пересылке данных
453
Глава 14
Реализации PKI могут быть как простыми, так и сложными, а некоторые применяют массивы смарт-карт (или другие способы двухфакторной аутентификации) и сертифика- ты для проверки подлинности всех пользователей с высокой степенью достоверности.
Поэтому каждая организация должна разобраться в возможностях PKI и выбрать нужную реализацию.
Сравнение шифрования секретным ключом
и шифрования открытым ключом
Технологии шифрования можно разделить на симметричные и асимметричные.
Симметричное шифрование требует, чтобы каждая сторона схемы шифрования владела копией секретного ключа (private key), используемого для шифрования и расшифровки ин- формации, пересылаемой между сторонами. Проблема с шифрованием секретным ключом состоит в том, что секретный ключ нужно как-то передать второй стороне, чтобы он не был перехвачен и использован для расшифровки информации. Кроме того, каждая уни- кальная пара сторон должна использовать отдельный уникальный ключ для защиты дан- ных. Результирующая сложность управления ключами является основным препятствием для реализации шифрования секретным ключом.
Шифрование открытым ключом (public key), или асимметричное шифрование, исполь- зует комбинацию двух ключей, которые математически связаны друг с другом. Первый ключ, являющий секретным ключом, хранится в строгой тайне и используется для цифро- вой подписи или расшифровки информации. Второй — открытый — ключ может исполь- зоваться для проверки цифровой подписи или шифрования информации. Целостность открытого ключа обеспечивается сертификатами, которые подробно описаны в последу- ющих разделах этой главы. Асимметричный подход к шифрованию значительно облегчает управление ключами, т.к. открытый ключ не нужно защищать, и у каждого пользователя имеется лишь один секретный ключ. Правда, это упрощение управления достигается за счет снижения производительности из-за усложнения математических операций.
Многие реализации шифрования и асимметричных ключей (включая и большинство реа- лизаций PKI) используют асимметричный процесс выбора секретного ключа, который затем применяется для защиты данных. При этом сочетаются преимущества обоих подходов.
Знакомство с цифровыми сертификатами
Сертификат (certificate) представляет собой цифровой документ, который выдается доверяемым центром (централизованным, внутренним или локальным) и используется им для подтверждения подлинности пользователя. Доверяемые центры сертификации, такие как VeriSign, широко используются в Интернете, чтобы, например, подтверждать, что про- граммное обеспечение Microsoft действительно разработано компанией Microsoft, а не слу- жит маскировкой какого-либо вируса.
Сертификаты применяются для выполнения нескольких функций, которые перечисле- ны ниже.
Защита электронной почты.

Аутентификация во всемирной Сети.

Защита данных в Интернете (IPsec).

Подписание кода.

Создание иерархий сертификации.

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

Безопасность
454
Часть IV
Сертификаты подписываются с помощью информации из открытого ключа субъекта и идентификационной информации — имя, адрес электронной почты и тому подобные сведения, — а также цифровой подписи организации, выпустившей сертификат, которая называется центром сертификации (Certificate Authority — CA). Если оба пользователя или компьютера доверяют одному и тому же центру сертификации, который выпустил серти- фикаты, они могут доверять и друг другу.
Служба сертификации Active
Directory в Windows Server 2012
Windows Server 2012 содержит встроенную технологию CA, называемую службой сер- тификации Active Directory ( Active Directory Certificate Services — AD CS). Первый вариант
AD CS появился в Windows Server 2008, а раньше эта технология называлась просто служ- бой сертификации (Certificate Services). AD CS может использоваться для создания сер- тификатов и последующего управления ими и отвечает за обеспечение их подлинности, отзыв и сроки годности. Зачастую AD CS в Windows Server 2012 используется без особой необходимости проверки сертификатов организации какой-либо независимой стороной.
Поэтому если сертификаты требуются только для участников внутри организации, часто применяется развертывание внутреннего CA для нужд внутренних пользователей и систем.
Широко используются и сторонние центры сертификации наподобие VeriSign, но они тре- буют дополнительного вложения средств.
Н
А ЗАМЕТКУ
Хотя в новом названии службы сертификации Windows упоминается Active Directory, сле- дует понимать, что для работы AD CS совсем не требуется интеграция с существующей средой леса доменной службы Active Directory (Active Directory Domain Services (AD DS)).
Обычно это все же так, но важно понимать, что AD CS не зависит от структуры леса AD DS.
Более подробно об AD DS можно прочитать в главах 4 и 5.
В Windows Server 2012 добавлено несколько новых возможностей AD CS.
Веб-служба развертывания сертификатов и веб-служба политики развертывания


сертификатов. Это наиболее значительное усовершенствование, которое появилось в Windows Server 2008 R2, позволяет развертывать сертификаты непосредственно по протоколу HTTP и дает возможность клиентам, не принадлежащим домену или под- ключенным к Интернету, обращаться к серверу CA и запрашивать сертификаты.
Автоматическое обновление серверов, не входящих в домен.


В рамках расшире- ния поддержки не членов домена веб-служба политик развертывания сертификатов
(Certificate Enrollment Policy Web Service) в Windows Server 2012 теперь поддерживает автоматическое обновление.
Поддержка Windows Server 2012 Core Edition.


Теперь AD CS поддерживается на серверах, работающих в режиме Core Edition.
Поддержка развертывания сертификатов между лесами.


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

Безопасность при пересылке данных
455
Глава 14
Головной центр сертификации предприятия.


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


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


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


Самостоятельные подчи- ненные CA получают свои сертификаты от самостоятельного головного CA, и затем могут использоваться для распространения сертификатов пользователям и компью- терам, связанным с этим самостоятельным CA.
В
НИМАНИЕ
!
Принятие решений по структуре AD CS — задача нетривиальная, и к ней не следует под- ходить легкомысленно. Простое помещение AD CS на сервер в качестве CA предпри- ятия и ее запуск — далеко не лучший подход с точки зрения безопасности, поскольку компрометация такого сервера может обернуться катастрофой. Поэтому, прежде чем приступить к развертыванию AD CS, важно тщательно обдумать ее структуру. Например, одной из лучших тактик является развертывание самостоятельного головного CA, затем нескольких подчиненных CA в предприятии, а затем физическое отключение самосто- ятельного головного CA и помещение в очень защищенное место, чтобы включать его, только если требуется обновление сертификатов подчиненных CA.
Описание служб ролей в AD CS
AD CS состоит из нескольких служб ролей, который выполняют для клиентов различ- ные задачи. При необходимости одну или несколько этих ролей можно установить на сер- вере. Эти службы кратко описаны ниже.
Центр сертификации.


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


Данная служба управляет распространением сертификатов клиентам через Интернет. Для ее работы нужно, чтобы на сервере была установлена служба информации Интернета (Internet Information Services — IIS).

Безопасность
456
Часть IV
Онлайновый ответчик.


Данная служба отвечает на запросы индивидуальных кли- ентов по поводу проверки конкретных сертификатов. Она применяется для слож- ных или больших сетей, которые должны выдерживать интенсивные периоды ак- тивности по отзыву или загрузку больших списков отзывов сертификатов ( Certificate
Revocation List — CRL).
Веб-служба развертывания сертификатов.


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


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


Данная служба упрощает получение серти- фикатов сетевыми устройствами наподобие маршрутизаторов.
Установка AD CS
Для установки AD CS в Windows Server 2012 вначале нужно выбрать сервер, который бу- дет работать в качестве головного CA. Не забывайте о настоятельных рекомендациях, что это должен быть выделенный сервер, защищенный физически и выключенный большую часть времени для обеспечения целостности цепочки сертификатов. Обратите внимание на важный момент: CA предприятия нельзя отключать, а вот самостоятельный головной центр с подчиненными CA предприятия отключить можно. Если выбран вариант самосто- ятельного головного центра с подчиненными CA предприятия, то вначале необходимо со- здать и сконфигурировать головной CA, а затем создать подчиненные CA предприятия.
В несложных ситуациях можно ограничиться головным CA предприятия, хотя во мно- гих случаях небольшие предприятия также хотят иметь самостоятельный головной центр и подчиненные CA предприятия. Если все-таки принят вариант с одним головным CA пред- приятия, то для создания сервера сертификации можно выполнить следующие шаги:
В
НИМАНИЕ
!
После установки AD CS на сервере имя и доменный статус этого сервера изменять не- льзя. Кроме того, нельзя изменять имя сервера, пока он выполняет функции CA.
Откройте диспетчер серверов (Server Manager).
1.
В меню
2.
Manage
(Управление) выберите пункт Add Roles and Features (Добавление ролей и компонентов).
На странице
3.
Before You Begin
(Первоначальные сведения) щелкните на кнопке Next
(Далее).
Согласитесь с предложенным по умолчанию типом установки и щелкните на кнопке
4.
Next
Выберите из списка нужный сервер AD CS и щелкните на кнопке
5.
Next
На странице
6.
Select Server Roles
(Выбор серверных ролей) отметьте флажок Active
Directory Certificate Services
(Служба сертификации Active Directory), а затем щелк- ните на кнопке Next.
Согласитесь со списком компонентов, щелкнув на кнопке
7.
Next
На странице
8.
Introduction
(Введение) просмотрите информацию об AD CS и щелкни- те на кнопке Next.

Безопасность при пересылке данных
457
Глава 14
На странице
9.
Select Role Services
(Выбор служб ролей), показанной на рис. 14.1, укажите нужные службы ролей. Для базовой установки необходима только роль
Certificate Authority
(Центр сертификации). Щелкните на кнопке Next.
Рис. 14.1. Установка AD CS
Щелкните на кнопке
10.
Install
(Установить).
После завершения установки щелкните на ссылке
11.
Configure Active Directory
Certificate Services on the Destination Server
(Настроить службу сертификации Active
Directory на целевом сервере).
При необходимости щелкните на кнопке
12.
Change
(Изменить), чтобы изменить вход- ные полномочия, и щелкните на кнопке Next.
Выберите службу роли центра сертификации, которую нужно настроить, и щелкните
13. на кнопке Next.
На следующей странице укажите, нужно ли устанавливать центр сертификации пред-
14. приятия (Enterprise CA), интегрированный с AD CS, или самостоятельный центр сертификации (Stand-alone CA). Щелкните на кнопке Next.
На странице
15.
Specify CA Type
(Укажите тип CA), показанной на рис. 14.2, выберите нужный тип CA. В данном случае мы устанавливаем на сервер головной CA (Root CA).
Щелкните на кнопке Next.
На следующей странице
16.
Private Key
(Секретный ключ) можно указать либо создание нового секретного ключа с нуля, либо использование существующего ключа из пре- дыдущей реализации CA. В данном примере мы создаем новый ключ. Щелкните на кнопке Next.
На странице
17.
Configure Cryptography for CA
(Настройка криптографии для CA) вве- дите параметры шифрования секретным ключом, как показано на рис. 14.3. Обычно вполне годятся значения, предложенные по умолчанию, но бывают случаи, когда нужно изменить CSP, длину ключа и другие настройки. Щелкните на кнопке Next.
Выберите имя, которое будет использоваться для идентификации данного CA.
18.
Учтите, что это имя будет фигурировать на всех сертификатах, выпущенных данным
CA. В нашем примере мы ввели имя
CompanyABC-CorpCA
. Щелкните на кнопке Next.

Безопасность
458
Часть IV
Укажите срок годности сертификата, который будет установлен на данном сервере
19.
CA. Если это головной CA, сервер должен будет повторно выпустить цепочку серти- фикатов после истечения срока годности. В данном примере мы выбрали 5-летний срок годности, хотя во многих реальных ситуациях для головного центра создается
20-летний CA. Щелкните на кнопке Next.
Укажите место хранения базы данных сертификатов и местоположения для хране-
20. ния журналов, а затем щелкните на кнопке Next.
На странице подтверждения (рис. 14.4) просмотрите параметры предстоящей уста-
21. новки и щелкните на кнопке Configure (Настроить).
После завершения работы мастера щелкните на кнопке
22.
Close
(Закрыть).
Рис. 14.2. Указание типа CA
Рис. 14.3. Выбор криптографических параметров

Безопасность при пересылке данных
459
Глава 14
Рис. 14.4. Просмотр параметров установки AD CS
После установки AD CS можно установить дополнительные (подчиненные) CA и выпол- нять администрирование PKI с консоли центра сертификации. для этого в диспетчере сер- веров выберите пункт меню Tools Certification Authority (Сервис Центр сертификации).
Настройка автоматического развертывания
После установки CA можно приступить к выпуску сертификатов. Сертификаты для при- кладных серверов — веб-серверов, серверов Microsoft Exchange, серверов Microsoft Lync и т.д. — часто развертываются администраторами. Но в более крупных развертываниях могут быть сотни, тысячи и даже больше сертификатов, поэтому нужен процесс автоматического развертывания. Такой автоматизированный процесс предусмотрен в Windows Server 2012, как для членов доменов, так и для не входящих в домен компьютеров.
Сейчас мы рассмотрим пример, демонстрирующий развертывание сертификата ком- пьютеров для всех членов домена. Для этого будут выполнены следующие высокоуровне- вые шаги.
Назначение шаблонных прав доступа.
1.
Активизация шаблона в CA.
2.
Настройка объекта групповой политики (GPO) на автоматическое развертывание
3. членов домена.
Настройка автоматического развертывания для не членов домена.
4.
Для назначения нужных шаблонных прав доступа выполните перечисленные ниже шаги.
Щелкните на кнопке
1.
Start
(Пуск), чтобы открыть экран Metro.
Введите текст
2. mmc
, чтобы открыть поле поиска и найти исполняемый файл mmc
Запустите утилиту
3. mmc из результата поиска.
Выберите пункт меню
4.
File Add/Remove Snap-In
(Файл Добавление или удаление оснастки).
Добавьте оснастку
5.
Certificate Templates
(Шаблоны сертификатов) и щелкните на кнопке OK.

Безопасность
460
Часть IV
Выберите корневую папку
6.
Certificate
Templates
В панели результатов щелкните правой
7. кнопкой мыши на шаблоне Workstation
Authentication и выберите в контекстном меню пункт Duplicate Template (Создать копию шаблона). Введите имя для создава- емого шаблона.
Перейдите на вкладку
8.
Security
(Безопас- ность).
Выберите элемент
9.
Domain Computers
(Ком пьютеры домена) и отметьте флажок
Auto-Enroll
(Авторазвертывание) в стол- бце Allow (Разрешить), как показано на рис. 14.5.
Щелкните на кнопке
10.
OK
Чтобы активиизровать шаблон в CA, выпол- ните на сервере AD CS следующие шаги.
Откройте диспетчер серверов (Server
1.
Manager).
Выберите пункт меню
2.
Tools Certification
Authority
(Сервис Центр сертификации).
Раскройте папку головного центра.
3.
Щелкните правой кнопкой мыши на папке
4.
Certificates Templates
(Шаблоны сер- тификатов) и выберите в контекстном меню пункт New Certificate Template
(Создать Шаблон сертификата).
Выберите только что созданную копию шаблона
5.
Workstation Authentication
(Аутен- тификация рабочей станции) и щелкните на кнопке OK.
Для настройки GPO на автоматическое развертывание выполните на контроллере до- мена следующие шаги.
Откройте диспетчер серверов (Server Manager).
1.
Выберите пункт меню
2.
Tools Group Policy Management
(Сервис Управление груп- повыми политиками).
Раскройте папку леса
3.
Domains
(Домены), в которой находятся папки с именами до- менов.
Щелкните правой кнопкой мыши на нужном домене и выберите в контекстном меню
4. пункт Create a GPO in This Domain, and Link It Here (Создать GPO в этом домене и привязать его к нему).
Введите имя для нового GPO — например,
5.
Computer certificate auto-enrollment
(Авторазвертывание сертификатов) — и щелкните на кнопке OK.
Щелкните правой кнопкой мыши на только что созданном GPO и выберите в кон-
6. текстном меню пункт Edit (Правка).
Разверните узел
7.
Computer Configuration \ Policies \ Windows Settings \ Security
Settings \ Public Key Policies
(Конфигурация компьютера \ Политики \ Параметры
Windows \ Настройки безопасности \ Политики открытого ключа).
Рис. 14.5. Настройка прав доступа
шаблона для авторазвертывания

Безопасность при пересылке данных
461
Глава 14
В панели результатов дважды щелкните на элементе
8.
Certificate Services Client —
Auto-Enrollment
(Клиент службы сертификатов — Авторазвертывание).
Смените значение параметра
9.
Configuration Model
(Модель настройки) на Enabled
(Включено).
Отметьте два флажка:
10.
Renew Expired Certificates, Update Pending Certificates, and
Remove Revoked Certificates
(Обновлять устаревшие сертификаты, обновлять ожи- дающие сертификаты и удалять отозванные сертификаты) и Update Certificates That
Use Certificate Templates
(Обновить сертификаты, использующие шаблоны сертифи- катов). Затем щелкните на кнопке OK.
Для проверки развертывания сертификатов выполните следующие шаги.
Щелкните на кнопке
1.
Start
(Пуск), чтобы открыть экран Metro.
Введите текст
2. mmc
, чтобы открыть поле поиска и найти исполняемый файл mmc
Запустите утилиту
3. mmc из результата поиска.
Выберите пункт меню
4.
File Add/Remove Snap-In
(Файл Добавление или удаление оснастки).
Выберите оснастку
5.
Certificate
(Сертификаты) и щелкните на кнопке Add (Доба вить).
Выберите вариант
6.
Computer Account Management Scope
(Область управления учет- ными записями компьютера) и щелкните на кнопке Next (Далее).
Согласитесь с вариантом
7.
Local Computer
(Локальный компьютер), щелкните на кнопке Finish (Готово), а затем на кнопке OK.
Раскройте папку
8.
Certificates (Local Computer)
(Сертификаты (Локальный компью- тер)), в ней папку Personal (Личные), а в ней — папку Certificates (Сертификаты).
Просмотрите и проверьте сертификат, который находится на панели результатов.
9.
Смарт карты в инфраструктуре открытых ключей
Надежным решением инфраструктуры открытых ключей может быть аутентификация пользователей с помощью смарт-карт. Смарт-карты — это пластиковые карточки со встро- енным микрочипом, USB-ключи или другие устройства.
Смарт-карта может содержать информацию входной регистрации пользователя, а так- же сертификаты, выданные сервером CA. Когда пользователю нужно войти в систему, он вставляет карточку в специальное считывающее устройство или просто проводит по нему карточкой. Устройство считывает сертификат и предлагает пользователю ввести только уникальный PIN-код, присвоенный каждому пользователю. После проверки PIN-кода и сер- тификата пользователь может войти в домен.
Смарт-карты выполняют аутентификацию по двум факторам и обладают очевидными преимуществами по сравнению со стандартными формами аутентификации. При их ис- пользовании невозможно просто похитить или угадать чье-то имя пользователя и пароль, поскольку имя пользователя можно ввести только с помощью уникальной смарт-карты.
Если смарт-карта похищена или утеряна, ее можно тут же отключить, а сертификат отоз- вать. Даже если функционирующая карточка попадет в чужие руки, для доступа к системе нужен еще и PIN-код. Смарт-карты быстро становятся все более распространенным спосо- бом сочетания защиты, предоставляемой сертификатами и PKI.
Использование шифрованной файловой системы ( EFS)
Точно так же, как на транспортном уровне информация может быть зашифрована с помощью сертификатов и PKI, в Windows Server 2012 можно зашифровать файловую

Безопасность
462
Часть IV
систему Resilient File System (ReFS) для предотвращения несанкционированного доступа.
Шифрованная файловая система ( Encrypting File System — EFS) в Windows Server 2012 рас- ширяет возможности предыдущей модели EFS, позволяя хранить наборы шифрования в автономных папках на сервере. Эта модель особенно удобна для пользователей ноутбуков, которые разъезжают с секретной информацией. В случае похищения ноутбука или его жес- ткого диска информация, хранящаяся в файлах, оказывается бесполезной, поскольку она искажена до неузнаваемости и может быть расшифрована только с помощью соответствую- щего ключа. Поэтому модель EFS — важная часть в реализациях инфраструктуры открытых ключей.
Технология Windows BitLocker идет еще дальше, чем EFS, и позволяет зашифровать весь жесткий диск, за исключением нескольких загрузочных файлов.
Интеграция PKI с зонами Kerberos
Компонент Active Directory из Windows Server 2012 может использовать инфраструктуру
PKI, в которой применяются отношения доверия между зонами Kerberos и Active Directory.
Инфраструктура PKI служит механизмом аутентификации для запросов на установление безопасных доверительных отношений между различными зонами, которые могут быть созданы в Active Directory.
Служба управления правами Active Directory
Служба управления правами Active Directory ( Active Directory Rights Management Services —
AD RMS) представляет собой технологию управления цифровыми правами (Digital Rights
Management — DRM), позволяющую устанавливать ограничения на управление, пересылку и просмотр содержимого. В RMS используется технология PKI для шифрования такого содер- жимого, как документы и почтовые сообщения, а также для просмотра этой информации без возможности ее печати, копирования-вставки и/или перенаправления.
AD RMS в Windows Server 2012 является усовершенствованием технологии сервера уп- равления правами Windows (Windows Rights Management Server), которая развивается уже несколько лет. Кроме уже существующих возможностей в ней усилена интеграция со служ- бой доменов Active Directory (Active Directory Domain Services (AD DS) и повышена масшта- бируемость.
Зачем нужна AD RMS
Многие организации сталкиваются с проблемой управления их интеллектуальной собс- твенностью после ее распространения. Несколько серьезных утечек внутренней секретной переписки в крупных корпорациях продемонстрировали необходимость управления и ог- раничения в случаях распространения конфиденциальной корпоративной информации.
Источник проблемы состоит в том, что исторически компьютерные системы хорошо справляются с ограничением доступа к информации для неавторизованных лиц, но после авторизации управление действиями с информацией теряется. Авторизованные лица мо- гут копировать документы “на вынос”, отправлять секретную информацию по электронной почте, у них могут пропадать ноутбуки — и вообще может существовать множество различ- ных способов утраты контроля над конфиденциальной информацией организации.
Служба Active Directory RMS предназначена для возврата возможностей контроля в та- кие организации. Она позволяет уполномоченному персоналу ограничивать возможности пересылки, печати, копирования и указания срока годности документов. Кроме того, ин- теграция со службой доменов Active Directory разрешает дешифровать информацию только лицам, специально указанным в политиках.

Безопасность при пересылке данных
463
Глава 14
Н
А ЗАМЕТКУ
Для отображения изменений в документах, защищенных службой RMS, их необходимо
“переопубликовать”, а у клиентов наряду с наличием локальной копии такого документа должны быть кешированы лицензии на использование. Если срок годности лицензии на использование не истек, пользователи будут все так же иметь доступ к защищенным документам, которые либо не опубликованы заново, ли перемещены из места переопуб- ликования документа.
В состав AD RMS входит также служба роли Identity Federation Support (Поддержка ин- тегрированного контроля подлинности). Установка этой службы позволяет организациям делиться закрытой информацией с другими организациями.
Условия, необходимые для работы AD RMS
Прежде чем приступать к установке AD RMS, необходимо обеспечить выполнение сле- дующих условий.
Нужно создать в AD DS учетную запись службы для RMS. Она не должна совпадать с

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

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

Нужно создать полностью определенное доменное имя (FQDN), известное в тех мес-

тах, где будут использоваться RMS-файлы. Например, можно создать доменное имя rms.companyabc.com для клиентов, которым нужно будет подключаться к серверу
AD RMS для проверки своих RMS-прав.
Необходим доступный работающий SQL Server для хранения баз данных AD RMS.

Настоятельно рекомендуется использовать сервер, отличный от того сервера, на ко- тором установлена служба AD RMS.
Установка AD RMS
Для установки AD RMS можно добавить на сервер роль AD RMS с помощью утилиты
Server Manager.
Откройте диспетчер серверов (Server Manager).
1.
В меню
2.
Manage
(Управление) выберите пункт Add Roles and Features (Добавление ролей и компонентов).
Щелкните на кнопке
3.
Next
(Далее) на странице приветствия, а затем на странице
Installation Type
(Тип установки).
Выберите из списка сервер AD RMS и щелкните на кнопке
4.
Next
На странице
5.
Select Server Roles
(Выбор ролей сервера) установите флажок Active
Directory Rights Management Services
(Служба управления правами Active Directory).
Если появится сообщение о необходимости дополнительных компонентов, щелкни- те на кнопке Add Features (Добавить компоненты), чтобы согласиться с добавлением нужных служб ролей, а затем щелкните на кнопке Next.
Щелкните на кнопке
6.
Next
, чтобы принять список компонентов.
На странице
7.
Introduction
(Введение) просмотрите информацию об AD RMS и щелк- ните на кнопке Next.

Безопасность
464
Часть IV
На странице
8.
Select Role Services
(Выбор служб ролей) укажите службы, которые нужно установить. В данном случае будет установлена только служба роли Active
Directory Rights Management Server (Сервер управления правами Active Directory).
Щелкните на кнопке Next.
Щелкните на кнопке
9.
Install
(Установить) и наблюдайте за процессом установки, как показано на рис. 14.6.
Рис. 14.6. Установка AD RMS
После завершения установки щелкните на ссылке
10.
Perform Additional Configuration
(Выполнить дополнительную настройку).
Теперь завершите работу в мастере настройки следующим образом.
Просмотрите вводное описание и щелкните на кнопке
1.
Next
(Далее).
Согласитесь со стандартным вариантом (создание нового кластера) и щелкните на
2. кнопке Next.
Выберите вариант
3.
Use Windows Internal Database on This Server
(Использовать на этом сервере внутреннюю СУБД Windows).
Н
А ЗАМЕТКУ
Внутренняя СУБД Windows годится для непроизводственных сред и для целей данного при- мера, однако она не пригодна для масштабирования и не поддерживает состояние высокой готовности. Поэтому в производственных развертываниях ее лучше не использовать.
Введите данные учетной записи службы и щелкните на кнопке
4.
Next
Согласитесь с предложенным по умолчанию криптографическим режимом и щелк-
5. ните на кнопке Next.
Согласитесь с предложенным по умолчанию централизованным хранилищем ключей
6. и щелкните на кнопке Next.
Введите пароль для ключа и щелкните на кнопке
7.
Next
Согласитесь с предложенным стандартным веб-сайтом и щелкните на кнопке
8.
Next

Безопасность при пересылке данных
465
Глава 14
Введите тип подключения безопасности, введите URL-адрес RMS и щелкните на
9. кнопке Next.
Н
А ЗАМЕТКУ
В производственных развертываниях настоятельно рекомендуется для всех обращений к RMS использовать протокол HTTPS. В средах, где имеются лишь внутренние потреби- тели контента, можно применять Интернет-сертификаты. А если требуется интеграция с внешними потребителями, следует использовать сторонние сертификаты.
Выберите нужный сертификат для кластера и щелкните на кнопке
10.
Next
Введите описательное имя для сертификата, который будет удостоверять вашу под-
11. линность в RMS. Рекомендуется применять в качестве имени хоста тот же URL-адрес.
Затем щелкните на кнопке Next.
Выберите, когда нужно регистрировать точку подключения к службе AD (Service
12.
Connection Point — SCP). В проектах SCP обычно публикуется позже, после настрой- ки и тестирования шаблонов RMS. Сразу после опубликования SCP компоненты и шаблоны RMS станут доступными для пользователей Office и Windows. Щелкните на кнопке Next.
Просмотрите выбранные параметры и щелкните на кнопке
13.
Install
(Установить).
После завершения установки щелкните на кнопке
14.
Close
(Закрыть).
Шифрование IPsec в Windows Server 2012
Протокол защиты данных в Интернете (IP Security — IPsec), уже упоминавшийся в пред- шествующих разделах, представляет собой механизм для оперативного шифрования всех пакетов, пересылаемых между компьютерами. IPsec действует на уровне 3 модели OSI и, значит, для передачи всего трафика между членами процесса использует пакеты.
Протокол IPsec часто считают одним из лучших способов защиты генерируемого в сре- де трафика: он удобен для защиты серверов и рабочих станций как в случаях небезопасно- го доступа к Интернету, так и в конфигурациях частных сетей для создания дополнитель- ного уровня безопасности.
Принцип работы IPsec
Основной принцип IPsec таков: весь трафик между клиентами — инициируемый при- ложениями, операционной системой, службами и прочими элементами — полностью шиф- руется протоколом IPsec, который затем вставляет в каждый пакет свой заголовок и от- правляет пакеты серверу назначения для расшифровки. Поскольку все фрагменты данных зашифрованы, это препятствует электронному прослушиванию сети для получения несан- кционированного доступа к данным.
Возможно несколько функциональных реализаций IPsec. Некоторые из наиболее перс- пективных решений встроены непосредственно в сетевые интерфейсные платы (NIC) каж- дого компьютера, что позволяет выполнять шифрование и расшифровку без какого-либо участия операционной системы. Кроме этих вариантов, Windows Server 2012 по умолчанию содержит надежную реализацию IPsec, которую можно сконфигурировать для применения аутентификации с помощью сертификатов PKI.
Основные возможности IPsec
IPsec в Windows Server 2012 предоставляет следующие возможности, которые при их сочетании дают наиболее надежные решения шифрования для клиент-серверных систем.

Безопасность
466
Часть IV
Конфиденциальность данных.


Вся информация, пересылаемая с одного IPsec- компьютера на другой, полностью шифруется с помощью таких алгоритмов, как
3DES, что эффективно препятствует несанкционированному просмотру секретных данных.
Целостность данных.


Целостность пакетов IPsec обеспечивается с помощью заго- ловков ESP, которые позволяют проверить, что информация, содержащаяся внутри пакета IPsec, не была подменена.
Возможность предотвращения повторной передачи.


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


IPsec использует сертификаты или аутен- тификацию Kerberos для проверки того, что отправителем пакета IPsec действитель- но является законный пользователь.
NAT Traversal или Teredo.


Теперь реализация IPsec в Windows Server 2012 допускает маршрутизацию пакетов IPsec через существующие реализации трансляции сетевых адресов (Network Address Translation — NAT). Подробнее эта концепция будет рас- смотрена в последующих разделах.
Поддержка 2048-битного ключа Диффи-Хеллмана.


Реализация IPsec в Windows
Server 2012 поддерживает применение практически недоступных для взлома 2048- битных ключей, что, по сути дела, обеспечивает невозможность взлома ключа IPsec.
NAT Traversal в IPsec
Как уже было сказано, теперь IPsec в Windows Server 2012 поддерживает концепцию прохождения с трансляцией сетевых адресов ( Network Address Translation Traversal — NAT
Traversal, или NAT-T). Чтобы понять, как работает NAT-T, вначале следует разобраться, для чего необходима сама трансляция сетевых адресов.
Трансляция сетевых адресов ( Network Address Translation — NAT) была разработана по той простой причине, что в Интернете не хватало IP-адресов для всех клиентов. Поэтому были определены частные IP-диапазоны (10.x.x.x, 192.168.x.x и 172.16–31.x.x), чтобы всем клиентам в данной организации можно было присваивать уникальный IP-адрес в собствен- ном частном адресном пространстве. Эти IP-адреса не предназначены для маршрутизации через пространство общедоступных IP-адресов, и для их преобразования в действующий уникальный общедоступный IP-адрес требовался специальный механизм.
В качестве этого механизма была разработана технология NAT. Обычно эта функция вы- полняется в серверах брандмауэров или маршрутизаторах, обеспечивая трансляцию сете- вых адресов между частными и общедоступными сетями. Сервер RRAS Windows Server 2012 также предоставляет возможности NAT.
Поскольку в структуре пакета IPsec адреса NAT невозможны, раньше серверы NAT просто отсекали трафик IPsec, поскольку не существовало способа физической маршрути- зации информации в соответствующий пункт назначения. Это и было основным барьером на пути повсеместного распространения IPsec, поскольку в настоящее время адресация многих клиентов в Интернете выполняется посредством NAT.
NAT Traversal (или NAT-T), присутствующий в реализации IPsec в Windows Server 2012 –– это Интернет-стандарт, совместно разработанный компаниями Microsoft и Cisco Systems.
NAT-T осуществляется посредством определения, требуется ли прохождение сети NAT, и последующей инкапсуляции всего пакета IPsec в пакет UDP (User Datagram Protocol — про- токол пользовательских дейтаграмм) с обычным заголовком UDP. NAT беспрепятственно

Безопасность при пересылке данных
467
Глава 14
выполняет обработку пакетов UDP, а затем они пересылаются по соответствующему адресу на другой конец NAT.
Для успешной работы NAT Traversal требуется, чтобы оба участника IPsec-транзакции поддерживали этот протокол и могли правильно извлекать пакет IPsec из пакета UDP.
С появлением последних версий клиента и сервера IPsec NAT Traversal становится реаль- ностью и создает предпосылки значительно более успешного применения технологии
IPsec, чем в настоящее время.
Н
А ЗАМЕТКУ
Технология NAT-T была разработана для сохранения существующих технологий NAT без изменений. Однако в некоторых реализациях NAT были предприняты попытки своего преобразования пакетов IPsec без применения NAT-T. Но при использовании NAT-T, возможно, будет лучше отключить эту функцию: она может вступить в противоречие с
IPsec, поскольку и NAT-T, и брандмауэр NAT будут пытаться преодолеть барьер NAT.
Резюме
В современных взаимосвязанных сетях безопасность транспортного уровня является важным (если не одним из главных) фактором обеспечения безопасности в любой органи- зации. Защита коммуникаций между пользователями и компьютерами в сети — очень важ- ное условие, а в некоторых случаях оно требуется законом. Система Windows Server 2012 построена на надежном фундаменте системы безопасности Windows Server 2003 и Windows
Server 2008 и включает в себя поддержку таких механизмов безопасности транспортного уровня, как IPsec и PKI, с помощью технологий наподобие AD CS и AD RMS. Правильное конфигурирование и применение этих средств может эффективно защитить передачу дан- ных в организации и обеспечить их использование только теми, для кого эти данные пред- назначены.
Полезные советы
Ниже перечислены полезные советы этой главы.
Для защиты сетевой среды используйте одну или несколько доступных технологий

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

дуется создать несколько уровней безопасности для особо важных сетевых данных.
Настоятельно рекомендуется не устанавливать локально базу данных AD RMS на сер-

вер RMS. Лучше используйте удаленный полный экземпляр SQL Server.
Уделите самое серьезное внимание защите сервера головного CA службы сертифика-

ции Active Directory, т.к. брешь в безопасности этого сервера скомпрометирует всю цепочку CA.
Храните самостоятельный головной сервер CA в физически запертом месте и вы-

ключайте его, если он в данный момент не нужен. Этот совет не относится к голо- вным CA предприятия, которые нельзя отключать на длительное время.
Используйте технологию IPsec для защиты сгенерированного в данной среде трафи-

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


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал