Идентификация и аутентификация. Протокол Kerberos

Разбить на страницы

Показывать лекцию целиком

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

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

Рассматриваемые вопросы можно разделить на две группы:

вопросы, связанные с идентификацией и аутентификацией пользователей;

защита передаваемых сообщений.

Идентификация и аутентификация

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

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

Обычно выделяют 3 группы методов аутентификации.

Аутентификация по наличию у пользователя уникального объекта заданного типа. Иногда этот класс методов аутентификации называют по-английски "I have" ("у меня есть"). В качестве примера можно привести аутентификацию с помощью смарт-карт или электронных USB-ключей.

Аутентификация, основанная на том, что пользователю известна некоторая конфиденциальная информация - "I know" ("я знаю"). Например, аутентификация по паролю. Более подробно парольные системы рассматриваются далее в этом разделе.

Аутентификация пользователя по его собственным уникальным характеристикам - "I am" ("я есть"). Эти методы также называются биометрическими.

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

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

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

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

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

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

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

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

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

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

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

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

Но при внедрении новых механизмов защиты могут появиться и нежелательные последствия. Например, требования "сложности" паролей могут поставить в тупик недостаточно подготовленного пользователя. В данном случае потребуется объяснить, что с точки зрения операционной системы Windows надежный пароль содержит 3 из 4 групп символов (большие буквы, малые буквы, цифры, служебные знаки). Аналогичным образом, надо подготовить пользователей и к внедрению блокировки учетных записей после нескольких неудачных попыток ввода пароля. Требуется объяснить пользователям, что происходит, а сами правила блокировки должны быть хорошо продуманы. Например, если высока вероятность того, что пользователь заблокирует свою запись в период отсутствия администратора, лучше ставить блокировку не насовсем, а на какой-то срок (30 минут, час и т.д.).

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

При использовании ОС семейства Windows, выявить учетные записи со слабыми или отсутствующими паролями можно, например, с помощью утилиты Microsoft Baseline Security Analyzer. Она же позволяет выявить и другие ошибки администрирования. Вопросам использования этой утилиты, а также настройке политики паролей посвящена лабораторная работа № 3.

Протокол Kerberos

Протокол Kerberos был разработан в Массачусетском технологическом институте в середине 1980-х годов и сейчас является фактическим стандартом системы централизованной аутентификации и распределения ключей симметричного шифрования. Поддерживается операционными системами семейства Unix, Windows (начиная с Windows'2000), есть реализации для Mac OS.

В сетях Windows (начиная с Windows'2000 Serv.) аутентификация по протоколу Kerberos v.5 (RFC 1510) реализована на уровне доменов. Kerberos является основным протоколом аутентификации в домене, но в целях обеспечения совместимости c с предыдущими версиями, также поддерживается протокол NTLM.

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

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

Серверная часть Kerberos называется центром распределения ключей (англ. Key Distribution Center, сокр. KDC) и состоит из двух компонент:

сервер аутентификации (англ. Authentication Server, сокр. AS);

сервер выдачи разрешений (англ. Ticket Granting Server, сокр. TGS).

Каждому субъекту сети сервер Kerberos назначает разделяемый с ним ключ симметричного шифрования и поддерживает базу данных субъектов и их секретных ключей. Схема функционирования протокола Kerberos представлена на рис 5.1.

(рис 5.1) Протокол Kerberos

Пусть клиент C собирается начать взаимодействие с сервером SS (англ. Service Server - сервер, предоставляющий сетевые сервисы). В несколько упрощенном виде, протокол предполагает следующие шаги [19, 20]:

C->AS: {c}.

Клиент C посылает серверу аутентификации AS свой идентификатор c (идентификатор передается открытым текстом).

AS->C: {{TGT}K_{AS_TGS}, K_{C_TGS}}K_C,

где:

K_C - основной ключ C ;

K_{C_TGS} - ключ, выдаваемый C для доступа к серверу выдачи разрешений TGS ;

{TGT} - Ticket Granting Ticket - билет на доступ к серверу выдачи разрешений

{TGT}={c,tgs,t₁,p₁, K_{C_TGS}}, где tgs - идентификатор сервера выдачи разрешений, t₁ - отметка времени, p₁ - период действия билета.

Запись $$\{ \cdot \} K_{X}$$ здесь и далее означает, что содержимое фигурных скобок зашифровано на ключе K_X.

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

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

C->TGS: {TGT}K_{AS_TGS}, {Aut₁} K_{C_TGS}, {ID}

где {Aut₁} - аутентификационный блок - Aut₁ = {с,t₂}, t₂ - метка времени; ID - идентификатор запрашиваемого сервиса (в частности, это может быть идентификатор сервера SS ).

Клиент C на этот раз обращается к серверу выдачи разрешений ТGS. Он пересылает полученный от AS билет, зашифрованный на ключе K_{AS_TGS}, и аутентификационный блок, содержащий идентификатор c и метку времени, показывающую, когда была сформирована посылка.Сервер выдачи разрешений расшифровывает билет TGT и получает из него информацию о том, кому был выдан билет, когда и на какой срок, ключ шифрования, сгенерированный сервером AS для взаимодействия между клиентом C и сервером TGS. С помощью этого ключа расшифровывается аутентификационный блок. Если метка в блоке совпадает с меткой в билете, это доказывает, что посылку сгенерировал на самом деле С (ведь только он знал ключ K_{C_TGS} и мог правильно зашифровать свой идентификатор). Далее делается проверка времени действия билета и времени отправления посылки 3 ). Если проверка проходит и действующая в системе политика позволяет клиенту С обращаться к клиенту SS, тогда выполняется шаг 4 ).

TGS->C: {{TGS}K_{TGS_SS},K_{C_SS}}K_{C_TGS},

где K_{C_SS} - ключ для взаимодействия C и SS, {TGS} - Ticket Granting Service - билет для доступа к SS (обратите внимание, что такой же аббревиатурой в описании протокола обозначается и сервер выдачи разрешений). {TGS} ={с,ss,t₃,p₂, K_{C_SS} }.

Сейчас сервер выдачи разрешений TGS посылает клиенту C ключ шифрования и билет, необходимые для доступа к серверу SS. Структура билета такая же, как на шаге 2): идентификатор того, кому выдали билет; идентификатор того, для кого выдали билет; отметка времени; период действия; ключ шифрования.

C->SS: {TGS}K_{TGS_SS}, {Aut₂} K_{C_SS}

где Aut₂={c,t₄}.

Клиент C посылает билет, полученный от сервера выдачи разрешений, и свой аутентификационный блок серверу SS, с которым хочет установить сеанс защищенного взаимодействия. Предполагается, что SS уже зарегистрировался в системе и распределил с сервером TGS ключ шифрования K_{TGS_SS}. Имея этот ключ, он может расшифровать билет, получить ключ шифрования K_{C_SS} и проверить подлинность отправителя сообщения.

SS->C: {t₄+1}K_{C_SS}

Смысл последнего шага заключается в том, что теперь уже SS должен доказать C свою подлинность. Он может сделать это, показав, что правильно расшифровал предыдущее сообщение. Вот поэтому, SS берет отметку времени из аутентификационного блока C, изменяет ее заранее определенным образом (увеличивает на 1), шифрует на ключе K_{C_SS} и возвращает C.

Если все шаги выполнены правильно и все проверки прошли успешно, то стороны взаимодействия C и SS, во-первых, удостоверились в подлинности друг друга, а во-вторых, получили ключ шифрования для защиты сеанса связи - ключ K_{C_SS}.

Нужно отметить, что в процессе сеанса работы клиент проходит шаги 1) и 2) только один раз. Когда нужно получить билет на доступ к другому серверу (назовем его SS1 ), клиент С обращается к серверу выдачи разрешений TGS с уже имеющимся у него билетом, т.е. протокол выполняется начиная с шага 3).

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

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

После установки взаимных соглашений, клиент из области 1 (пусть это будет K₁₁ ) может установить сеанс взаимодействия с клиентом из области 2 (например, К₂₁ ). Для этого K₁₁ должен получить у своего сервера выдачи разрешений билет на доступ к Kerberos-серверу, с клиентом которого он хочет установить взаимодействие (т.е. серверу Kerberos KDC2). Полученный билет содержит отметку о том, в какой области зарегистрирован владелец билета. Билет шифруется на ключе, разделенном между серверами KDC1 и KDC2. При успешной расшифровке билета, удаленный Kerberos-сервер может быть уверен, что билет выдан клиенту Kerberos-области, с которой установлены доверительные отношения. Далее протокол работает как обычно.

(рис 5.2) Взаимодействие между Kerberos-областями

Кроме рассмотренных, Kerberos предоставляет еще ряд дополнительных возможностей. Например, указанный в структуре билета параметр p (период времени) задается парой значений "время начала действия" - "время окончания действия", что позволяет получать билеты отложенного действия.

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

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

Что касается реализации протокола Kerberos в Windows, то надо отметить следующее.

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

В роли Kerberos-серверов выступают контроллеры домена, на каждом из которых должна работать служба Kerberos Key Distribution Center (KDC). Роль хранилища информации о пользователях и паролях берет на себя служба каталога Active Directory. Ключ, который разделяют между собой сервер аутентификации и сервер выдачи разрешений формируется на основе пароля служебной учетной записи krbtgt - эта запись автоматически создается при организации домена и всегда заблокирована.

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

Использование Kerberos требует синхронизации внутренних часов компьютеров, входящих в домен Windows.

Для увеличения уровня защищенности процесса аутентификации пользователей, рекомендуется отключить использование менее надежного протокола NTLM и оставить только Kerberos (если использования NTLM не требуют устаревшие клиентские ОС).

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

Инфраструктура открытых ключей. Цифровые сертификаты

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

Но возникает другая проблема - как убедиться в том, что имеющийся у Вас открытый ключ другого абонента на самом деле принадлежит ему. Иными словами, возникает проблема аутентификации ключа. Без этого, на криптографический протокол может быть осуществлена атака типа "человек посередине" (man in the middle).

Идею данной атаки поясняет следующий пример. Абонент A (Алиса) хочет послать абоненту B (Боб) зашифрованное сообщение и берет его открытый ключ из общедоступного справочника. Но, на самом деле, ранее нарушитель E (Ева) подменил в справочнике открытый ключ Боба своим открытым ключом. Теперь Ева может расшифровать те сообщения, которые Алиса формирует для Боба, ознакомиться с их содержимым, возможно, зашифровать их на настоящем ключе Боба и переслать ему (рис 5.3).

(рис 5.3) Атака типа man-in-the-middle

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

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

Но вернемся к цифровым сертификатам. Для подтверждения подлинности открытых ключей создается инфраструктура открытых ключей (англ. Public Key Infrastructure, сокр. PKI). PKI представляет собой набор средств, мер и правил, предназначенных для управления ключами, политикой безопасности и обменом защищенными сообщениями. Структура PKI представлена на рис 5.4.

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

(рис 5.4) Структура PKI

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

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

(рис 5.5) Иерархия центров сертификации и клиентов

Перейдем к рассмотрению самих сертификатов. Наибольшее распространение получили цифровые сертификаты, формат которых определен стандартом X.509. На данный момент, принята третья версия стандарта. Формат сертификата изображен на рис 5.6 [21].

Номер версии содержит числовое значение, соответствующее номеру версии (для сертификата версии 1 равен 0 и т.д.). В первой версии X.509 не было уникальных номеров ("ID Изготовителя", "ID Субъекта") и полей расширения. Во второй версии добавились указанные идентификаторы, в третьей - расширения.

Серийный номер - уникальный номер, присваиваемый каждому сертификату.

Алгоритм подписи - идентификатор алгоритма, используемого при подписании сертификата. Должен совпадать с полем Алгоритм ЭЦП.

Изготовитель - имя центра сертификации, выдавшего сертификат. Записывается в формате Relative Distinguished Name - RDN (варианты перевода названия - "относительное отдельное имя", "относительное характерное имя"). Данный формат используется в службах каталога, в частности, в протоколе LDAP.

(рис 5.6) Сертификат формата X.509 v.3

При записи Relative Distinguished Name используются специальные ключевые слова:

CN (Common Name) - общее имя;

OU (Organization Unit) - организационная единица;

DC (Domain Component) - составная часть доменного имени.

Например, в сертификате Microsoft Windows Hardware Compatibility, который находится в хранилище сертификатов Windows'XP значение данного поля следующее:

CN = Microsoft Root Authority

OU = Microsoft Corporation

Как видно, указывается имя центра сертификации, компания, которой он принадлежит и т.д.

Субъект - имя владельца сертификата, представленное в том же формате RDN. Для указанного в предыдущем примере сертификата значения данного поля:

CN = Microsoft Windows Hardware Compatibility

OU = Microsoft Corporation

OU = Microsoft Windows Hardware Compatibility Intermediate CA

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

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

ID Изготовителя и ID Субъекта содержат уникальные идентификаторы центра сертификации и пользователя (на случай совпадения имен различных CA или пользователей).

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

Алгоритм электронной цифровой подписи (ЭЦП) - идентификатор алгоритма, используемый для подписи сертификата. Должен совпадать со значением поля Алгоритм подписи.

ЭЦП - само значение электронно-цифровой подписи для данного сертификата.

Расширения могут определять следующие дополнительные параметры:

идентификатор пары открытый/секретный ключ центра сертификации (изготовителя), если центр имеет несколько различных ключей для подписи сертификатов;

идентификатор конкретного ключа пользователя (субъекта), если пользователь имеет несколько сертификатов;

назначение ключа, например, ключ для шифрования данных, проверки ЭЦП данных, для проверки ЭЦП сертификатов и т.д.;

уточнение периода использования - можно сократить время действия сертификата, указанное в поле Период действия (т.е. период, в течение которого статус сертификата отслеживается, станет больше, чем разрешенное время использования сертификата);

политики использования сертификата;

выбор соответствия политик использования сертификата для центра сертификации и пользователя, если имеются различные варианты;

альтернативное имя пользователя и центра сертификации;

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

Предположим, что ключевые пары сгенерированы, открытые ключи заверены сертификатами и размещены в каталоге, реализованном с помощью web-сервера, ftp-сервера, службы каталога или другой технологии. Теперь, если абонент A желает проверить подпись абонента B под полученным сообщением (или зашифровать для B сообщение с помощью его открытого ключа и т.д.), он выполняет следующие действия [21]:

запрашивает в сетевом справочнике сертификат C_B открытого ключа подписи (шифрования,...) абонента B ;

проверяет достоверность сертификата C_B (см. ниже);

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

Процедура проверки достоверности сертификата C_B состоит в следующем:

проверяется срок действия сертификата C_B, если он закончился, сертификат считается недостоверным;

из C_B извлекается имя ЦС, подписавшего этот сертификат, обозначим его D ;

если D=B, то сертификат самоподписанный, он считается достоверным только, если D=ROOT (хотя, возможно, в некоторых сетях право выдавать самоподписанные сертификаты имеет не один ROOT, это - политика сети);

если же $$D \ne B$$, то из справочника запрашивается сертификат C_D открытого ключа подписи абонента D, проверяется на достоверность сертификат C_D ;

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

с помощью K_D проверяется подпись под сертификатом C_B, по результатам проверки этой подписи судят о достоверности C_B.

Если ключи шифрования досрочно вышли из обращения (причины могут быть различны - пользователь увольняется из компании, секретный ключ скомпрометирован и т.д.), центр сертификации извещает об этом остальных пользователей сети путем выпуска списка отозванных сертификатов (англ. Certificate Revocation List, сокр. CRL). Структура CRL представлена на рис 5.7.

(рис 5.7) Структура списка отозванных сертификатов

Поля списка содержат следующую информацию:

Номер версии определяет номер версии формата CRL. Текущая используемая версия - вторая.

Алгоритм подписи - идентификатор алгоритма, с помощью которого подписан CRL. Должен совпадать по значению с полем Алгоритм ЭЦП.

Изготовитель - имя центра сертификации в формате RDN.

Выпущен - дата выпуска CRL.

Следующий - дата, до которой будет выпущен следующий CRL.

Расширения - описывают центр сертификации, точку для поиска CRL данного центра, номер данного списка и т.д.

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

Алгоритм ЭЦП - идентификатор алгоритма ЭЦП, используемого для подписи списка.

ЭЦП - сама электронная цифровая подпись.

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

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

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

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

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

Надо отметить, что сфера применения цифровых сертификатов сейчас достаточно широка. В частности, они используются для распределения открытых ключей в протоколах защиты электронной почты S/MIME или PGP, с помощью цифровых сертификатов проверяется подлинность участников соединения по протоколу SSL и т.д.

Начиная с Windows 2000 Server в состав серверных ОС Microsoft входит программное обеспечение для создания центров сертификации. Создание корпоративного ЦС может понадобиться, если принято решение использовать защиту электронной почты с помощью S/MIME, шифрование данных при хранении средствами EFS (EFS - Encrypted File System - реализует шифрование данных на дисках с файловой системой NTFS), шифрование сетевого трафика с помощью протокола IPSec.

Различные практические аспекты использования цифровых сертификатов рассматриваются в лабораторных работах № 6 и 7. Первая из них посвящена работе с сертификатами с точки зрения конечного пользователя (в том числе, получение сертификата для защиты электронной почты с помощью S/MIME), а вторая - созданию и администрированию центра сертификации. Вопросы использования EFS рассматриваются в работе № 8.

Протокол защиты электронной почты S/MIME

Протокол Secure Multipurpose Internet Mail Extensions (S/MIME) предназначен для защиты данных, передаваемых в формате MIME, в основном - электронной почты. Он был предложен в 1995 году компанией RSA Data Security Inc. Дальнейшие работы над протоколом велись рабочей группой организации Internet Engineering Task Force (IETF), разрабатывающей стандарты сети Интернет. На данный момент, последней является версия 3.1 этого протокола, описываемая в документах RFC 3850, 3851, 3852. S/MIME предоставляет следующие криптографические услуги безопасности (криптографические сервисы):

проверка целостности сообщения;

установление подлинности отправителя (аутентификация);

обеспечение секретности передаваемых данных (шифрование).

Нужно отметить, что сам по себе MIME описывает порядок форматирования писем, содержащих различные типы данных (обычный текст, текст в формате html, видео и графические файлы различный типов и т.д.). S/MIME добавляет свои типы (например, application/pkcs7-mime и application/pkcs7-signature), что позволяет указать на то, что данные в этом разделе являются зашифрованными, подписанными и т.д. Протокол позволяет обычным почтовым клиентам защищать исходящую почту и интерпретировать криптографические сервисы, добавленные во входящую почту (расшифровывать сообщения, проверять их целостность и т.д.).

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

S/MIME позволяет использовать различные криптоалгоритмы, причем их список может расширяться. Изначально, из симметричных шифров могли использоваться RC2, DES или TripleDES. Для формирования дайджестов - алгоритмы MD5 и SHA1, причем версия 3 стандарта рекомендует использовать именно последний алгоритм (из-за того, что он формирует более длинный дайджест и считается более надежным). Защита симметричного ключа шифрования и ЭЦП в версии 2 осуществляется с помощью алгоритма RSA с ключом от 512 до 1024 бит. Версия 3 добавляет возможность использовать другие алгоритмы, например алгоритм Диффи-Хеллмана с ключом длиной до 2048 бит. Распределение и аутентификация открытых ключей производится с помощью цифровых сертификатов формата X.509. Таким образом, чтобы защищать переписку с помощью этого протокола оба абонента должны сгенерировать ключевые пары и удостоверить открытые ключи с помощью сертификатов. На рис 5.8 приведен фрагмент письма, содержащий открытый текст "This is a clear-signed message." и подпись к нему.

S/MIME поддерживается многими почтовыми клиентами: Microsoft Outlook (получение сертификата и настройка рассматривается в лабораторной работе 6), Mozilla, The Bat! и т.д. Более широкое применение протокола сдерживается необходимостью наличия сертификатов у абонентов и плохой совместимостью с системами Web-почты.

(рис 5.8) Фрагмент электронного письма с подписью

Протокол IPSec

Протокол IPSec или, если точнее, набор протоколов, разработан IETF как базовый протокол обеспечения безопасности на уровне IP-соединения. IPSec является дополнением к использующемуся сейчас протоколу IP ver.4 и составной частью IP ver.6. Возможности, предоставляемые IPSec:

контроль доступа;

контроль целостности данных;

аутентификация данных;

защита от повторений;

обеспечение конфиденциальности.

Основная задача IPSec - создание между двумя компьютерами, связанными через общедоступную (небезопасную) IP-сеть, безопасного туннеля (рис 5.9), по которому передаются конфиденциальные или чувствительные к несанкционированному изменению данные. Подобный туннель создается с использованием криптографических методов защиты информации.

Протокол работает на сетевом уровне модели OSI и, соответственно, он "прозрачен" для приложений. Иными словами, на работу приложений (таких как web-сервер, браузер, СУБД и т.д.) не влияет, используется ли защита передаваемых данных с помощью IPSec или нет.

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

(рис 5.9) Туннель безопасности

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

Процесс защищенной передачи данных регулируется правилами безопасности, принятыми в системе. Параметры создаваемого туннеля описывает информационная структура, называемая контекст защиты или ассоциация безопасности (от англ. Security Association, сокр. SA). Как уже отмечалось выше, IPSec является набором протоколов, и состав SA может различаться, в зависимости от конкретного протокола. SA включает в себя:

IP-адрес получателя;

указание на протоколы безопасности, используемые при передаче данных;

ключи, необходимые для шифрования и формирования имитовставки (если это требуется);

указание на метод форматирования, определяющий, каким образом создаются заголовки;

индекс параметров защиты (от англ. Security Parameter Index, сокр. SPI) - идентификатор, позволяющий найти нужный SA.

Обычно, контекст защиты является однонаправленным, а для передачи данных по туннелю в обе стороны задействуются два SA. Каждый хост имеет свою базу SA, из которой выбирается нужный элемент либо на основании SPI, либо по IP-адресу получателя.

Два протокола, входящие в состав IPSec это:

протокол аутентифицирующего заголовка - AH (от англ. Authentication Header), обеспечивающий проверку целостности и аутентификацию передаваемых данных; последняя версия протокола описана в RFC 4302 (предыдущие - RFC 1826, 2402);

протокол инкапсулирующей защиты данных - ESP (от англ. Encapsulating Security Payload) - обеспечивает конфиденциальность и, дополнительно, может обеспечивать проверку целостности и аутентификацию, описан в RFC 4303 (предыдущие - RFC 1827, 2406).

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

Транспортный режим ориентирован на соединение хост-хост. При использовании ESP в транспортном режиме защищаются только данные IP-пакета, заголовок не затрагивается. При использовании AH защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже.

Протокол AH

В IP ver.4 аутентифицирующий заголовок располагается после IP-заголовка. Представим исходный IP-пакет как совокупность IP-заголовка, заголовка протокола следующего уровня (как правило, это TCP или UDP, на рис 5.10 он обозначен как ULP - от англ. Upper-Level Protocol) и данных.

(рис 5.10) а) исходный IP-пакет; b) IP-пакет при использовании AH в транспортном режиме; c) IP-пакет при использовании AH в туннельном режиме

На рис 5.10 представлен исходный пакет и варианты его изменения при использовании протокола AH в разных режимах. В транспортном режиме заголовок исходного IP-пакета остается на своем месте, но в нем модифицируются некоторые поля. Например, меняется поле Next Header, указывающее на то, заголовок какого протокола следует за IP-заголовком. В туннельном режиме создается новый IP-заголовок, после которого идет заголовок AH, а за ним - полностью исходный IP-пакет.

Аутентификация производится путем создания имитовставки (MAC) для чего используется хэш-функция и секретный ключ. Во всех реализациях AH обязательно должно поддерживаться использование хэш-функций с ключом HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96, представляющих собой варианты хэш-функций MD5 и SHA-1, соответственно. Но могут использоваться и другие, "факультативные" алгоритмы хэширования. Полученное значение, называемое в описании протокола ICV (от англ. Integrity Check Value - значение контроля целостности) помещается в поле Authentication Data (рис 5.11). Это поле переменной длины, т.к. разные алгоритмы хеширования формируют разные по длине дайджесты.

(рис 5.11) Структура заголовка протокола AH

При использовании AH в транспортном режиме, ICV рассчитывается для ULP, данных и неизменяемых полей IP-заголовка. Изменяемые поля, такие как поле TTL, указывающее на время жизни пакета и изменяемое при прохождении маршрутизаторов, при расчете значения хэш-функции принимаются равными 0. В туннельном режиме аутентифицируется весь исходный IP-пакет и неизменяемые поля нового заголовка.

Рассмотрим формат заголовка AH (рис 5.11). Первые 8 бит заголовка (поле Next Header ) содержат номер, соответствующий протоколу следующего уровня. Номер для каждого протокола назначает организация IANA (Internet Assigned Numbers Authority). Например, номер TCP - 6, ESP - 50, AH - 51 и т.д.

Поле Payload Len указывает длину заголовка AH в 32-битных словах. Далее 16 бит зарезервировано.

Поле SPI содержит значение индекса параметров защиты, по которому получатель сможет найти нужный SA. Нулевое значение SPI показывает, что для данного пакета SPI не существует.

Поле Sequence Number было введено в RFC 2402. Значение счетчика, содержащееся в этом поле, может использоваться для защиты от атак путем повторных посылок перехваченных пакетов. Если функция защиты от повторов активирована (а это указывается в SA), отправитель последовательно наращивает значение поля для каждого пакета, передаваемого в рамках данной ассоциации (соединения, использующего единый SA).

Поле Authentication Data, как уже указывалось ранее, хранит значение ICV.

Протокол ESP

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

Так же как и AH, ESP может работать в транспортном и туннельном режимах. На рис 5.12 изображены варианты его использования (штриховкой выделены фрагменты пакета, которые защищаются с помощью шифрования). Для ESP определен следующий перечень обязательных алгоритмов, которые должны поддерживаться во всех реализациях:

для формирования имитовставки HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96;

для шифрования - DES (в режиме CBC, используется по умолчанию) и NULL (отсутствие шифрования).

Кроме того, зарегистрированы и могут быть реализованы еще ряд алгоритмов шифрования - Triple DES, CAST-128, RC5, IDEA, Blowfish, ARCFour (общедоступная версия RC4) [21].

Рассмотрим формат заголовка ESP (рис 5.13). Он начинается с двух 32-разрядных значений - SPI и SN. Роль их такая же, как в протоколе AH - SPI идентифицирует SA, использующийся для создания данного туннеля; SN - позволяет защититься от повторов пакетов. SN и SPI не шифруются.

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

(рис 5.13) а) исходный IP-пакет; b) ESP в транспортном режиме; c) ESP в туннельном режиме(рис 5.12) Структура заголовка ESP

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

Если ESP используется и для аутентификации данных, то завершает пакет поле переменной длины, содержащее ICV. В отличие от AH, в ESP при расчете значения имитовставки, поля IP-заголовка (нового - для туннельного режима, модифицированного старого - для транспортного) не учитываются.

При совместном использовании протоколов AH и ESP, после IP заголовка идет AH, после него - ESP. В этом случае, ESP решает задачи обеспечения конфиденциальности, AH - обеспечения целостности и аутентификации источника соединения.

Рассмотрим ряд дополнительных вопросов, связанных с использованием IPSec. Начнем с того, откуда берется информация о параметрах соединения - SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную, или формироваться с использованием специальных протоколов - SKIP, ISAKMP (Internet Security Association and Key Management Protocol) и IKE (Internet Key Exchange).

IPSec и NAT

При подключении сетей организаций к Интернет, часто используется механизм трансляции сетевых адресов - NAT (Network Address Translation). Это позволяет уменьшить число зарегистрированных IP-адресов, используемых в данной сети. Внутри сети используются незарегистрированные адреса (как правило, из диапазонов, специально выделенных для этой цели, например, адреса вида 192.168.x.x для сетей класса C). Если пакет из такой сети передается в Интернет, то маршрутизатор, внешнему интерфейсу которого назначен по крайней мере один зарегистрированный ip-адрес, модифицирует ip-заголовки сетевых пакетов, подставляя вместо частных адресов зарегистрированный адрес. То, как производится подстановка, фиксируется в специальной таблице. При получении ответа, в соответствии с таблицей делается обратная замена и пакет переправляется во внутреннюю сеть.

Рассмотрим пример использования NAT рис 5.14. В данном случае, во внутренней сети используются частные адреса 192.168.0.x. С компьютера, с адресом 192.168.0.2 обращаются во внешнюю сеть к компьютеру с адресом 195.242.2.2. Пусть это будет подключение к web-серверу (протокол HTTP, который использует TCP порт 80).

(рис 5.14) Пример использования NAT

Таблица NAT
Протокол	Внутренний локальный ip адрес : порт	Внутренний зарегистрированный ip-адрес: порт	Внешний ip адрес: порт
TCP	192.168.0.2: 2001	195.201.82.146: 2161	195.242.2.2 : 80

При прохождении пакета через маршрутизатор, выполняющий трансляцию адресов, ip-адрес отправителя (192.168.0.2) будет заменен на адрес внешнего интерфейса маршрутизатора (195.201.82.146), а в таблицу трансляции адресов будет добавлена запись, аналогичная приведенной в таблице 5.1.

Получив представление о механизме работы NAT, разберемся, какие сложности могут возникнуть, в случае использования IPSec. Предположим, с хоста с адресом 192.168.0.2 пытаются установить защищенное соединение с внешним хостом 195.242.2.2, используя протокол аутентифицирующего заголовка (AH). При прохождении маршрутизатора, ip-адрес отправителя меняется, как было описано выше. Протокол AH определяет, что значение имитовставки рассчитывается, включая неизменяемые поля IP-заголовка, в частности - адрес отправителя. Сторона-получатель, обнаружит неверное (из-за трансляции адресов) значение имитовставки и отбросит пакет.

Таким образом, NAT и AH несовместимы. В то же время, протокол ESP, который не контролирует целостность ip-заголовка, может использоваться совместно с NAT.

Кроме того, RFC 2709 определяет расширение NAT - IPC-NAT (IPSec policy Controlled NAT - NAT управляемый правилами IPSec), которое позволяет решить указанную проблему путем создания IP-IP туннеля, одной из конечных точек которого является узел NAT. В этом случае, вместо модификации IP-адреса отправителя в заголовке исходного пакета, NAT-устройство помещает без изменений весь исходный пакет (который аутентифицирован AH), в новый IP-пакет, в заголовке которого в качестве адреса отправителя ставится адрес NAT-устройства. На стороне получателя из полученного пакета изымают исходный пакет и далее обрабатывают его как обычно.

Отдельно необходимо решать вопрос с распределением ключей. Если для этой цели используется протокол IKE (а он использует UDP, порт 500), потребуется специально организовать пересылку соответствующих данных во внутреннюю сеть. В том, случае, если задействовать UDP-порт 500 не представляется возможным, можно использовать описываемый в RFC 3947, 3948 механизм NAT-T (от англ. NAT traversal), определяющий инкапсуляцию IKE и IPSec трафика в пакеты UDP. При этом задействуется порт 4500.

Вопросы, связанные настройкой и использованием реализации IPSec в ОС семейства Windows, рассматриваются в лабораторной работе №12. В ней, в частности, подробно рассматривается создание "политики" IPSec, определяющей для каких узлов и с какими параметрами будет создаваться туннель.

Лабораторная работа 6. Использование цифровых сертификатов

В ходе данной лабораторной работы мы познакомимся с некоторыми вопросами использования цифровых сертификатов.

Начнем с их использования протоколом SSL/TSL (на самом деле это два разных протокола, но т.к. TSL разработан на базе SSL, принцип использования сертификатов один и тот же). Этот протокол широко применяется в сети Интернет для защиты данных передаваемых между web-серверами и браузером клиента. Для аутентификации сервера в нем иcпользуется сертификат X.509.

Для примера обратимся на сайт Ситибанка (http://www.citibank.ru), в раздел ).

(рис 6.1) Защищенное соединение

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

Выбрав ).

(рис 6.2) Параметры сертификата

Задание

Посмотрите параметры сертификата "электронной сберкассы" Сбербанка - https://esk.sbrf.ru Опишите, кем на какой срок и для какого субъекта сертификат был выдан.

Теперь рассмотрим другой вариант - мы подключаемся по SSL к web-серверу, а браузер не может проверить его подлинность. Подобная ситуация произошла при подключении в раздел Интернет-обслуживания Санкт-Петербургского филиала оператора мобильной связи Tele2 - https://www.selfcare.tele2.ru/work.html (на рис 6.3).

(рис 6.3) Браузер сообщает о проблеме с сертификатом

Если нажать ссылку "Продолжить открытие этого web-узла" можно будет просмотреть сертификат.

Задание

Разберитесь, в чем проблема с указанным сертификатом.

Прим. На всякий случай в конце описания лабораторной приведен ответ.

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

Из меню Пуск —> Выполнить запустите консоль командой mmc. В меню Консоль выберите Добавить или удалить оснастку, а в списке оснасток выберите Сертификаты. Если будет предложен выбор (а это произойдет, если Вы работаете с правами администратора), выберите пункт "Моей учетной записи".

Таким образом, мы можем просматривать сертификаты текущего пользователя. Если ранее сертификаты не запрашивались, то в разделе "Личные сертификаты" элементов не будет.

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

Найдите в нем сертификат VeriSign Class 3 Public Primary CA. Благодаря тому, что он уже был установлен, в рассмотренном в начале работы примере с подключением к системам Интернет-банкинга браузер мог подтвердить подлинность узла.

Теперь перейдем к разделу ).

(рис 6.4) Отозванные сертификаты

Теперь рассмотрим процесс запроса сертификата. На сайте центра сертификации Thawte http://www.thawte.com можно бесплатно получить сертификат для электронной почты. Для этого в меню сайта Products выберите Free Personal E-Mail Certificates. После этого надо заполнить небольшую анкету, указав имя, фамилию, страну, предпочитаемую кодировку, адрес электронной почты (должен быть обязательно действующим), дальше - пароль и контрольные вопросы для восстановления. Когда все заполнено, на указанный адрес почты будет отправлено письмо со ссылкой для выполнения дельнейших шагов генерации ключей и двумя проверочными значениями, которые нужно ввести, перейдя по ссылке. Таким образом, подлинность и принадлежность адреса будет подтверждена.

Далее система предложит ввести адрес почты (в качестве имя пользователя) и выбранный ранее пароль. После чего можно запросить сертификат X.509. Понадобится указать тип браузера и почтового клиента (например, Internet Explorer и Outlook). После этого потребуется ответить на запросы системы, касающиеся генерации ключей (разрешить выполнение ActiveX элемента, выбрать криптопровайдер, разрешить генерацию).

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

Пройдя по ссылке, надо будет снова ввести имя и пароль и на странице нажать кнопку "Install Your Cert" и согласиться с добавлением сертификата.

В результате в оснастке ).

Если использовать сертификат для защиты почты, дальнейшая настройка зависит от почтового клиента. Если это Microsoft Outlook, можно использовать встроенную в него поддержку протокола S/MIME. В Outlook 2003 для выбора сертификата надо войти в меню ).

(рис 6.6) Полученный сертификат(рис 6.5) Выбор сертификата для защиты почты с помощью S/MIME в Outlook

Задание

Запросите сертификат в Thawte и настройте почтовый клиент для использования S/MIME.

Ответ на задание про сертификат на сайте Tele2

Проблема была в том, что сертификат "самоподписанный": он был выдан центром сертификации http://www.selfcare.tele2.ru самому себе. Браузер сообщает о невозможности удостовериться в подлинности узла из-за того, что данный центр сертификации отсутствует в списке доверенных, а проверить его подлинность с помощью "вышестоящего" по иерархии центра не представляется возможным (т.к. вышестоящего центра нет).

Доверять или нет такому сертификату - каждый решает самостоятельно.

Лабораторная работа 7. Создание центра сертификации (удостоверяющего центра) в Windows Server 2008

Предыдущая лабораторная работа была посвящена вопросам использования цифровых сертификатов X.509 конечными пользователями. А сейчас мы рассмотрим возможности, которые предоставляет Windows Server 2008 по созданию собственно центра сертификации (Certification Authority - CA) на предприятии.

Соответствующие службы присутствовали в серверных операционных системах семейства Windows, начиная с Windows 2000 Server.

В Windows Server 2008 для того, чтобы сервер смог работать как центр сертификации, требуется сначала добавить серверу роль Active Directory Certificate Services. Делается это помощью оснастки Server Manager, которую можно запустить из раздела Administrative Tools в стартовом меню.

В .

(рис 7.1) Добавление роли

В нашем примере, роль добавляется серверу, являющемуся членом домена Windows. Так как это первый CA в домене, он в нашей сети будет играть роль корневого ( Root ). Рассмотрим по шагам процедуру установки.

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

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

(рис 7.3) Выбор добавляемой роли(рис 7.2) Выбор устанавливаемых компонент

Следующий шаг - определения типа центра сертификации. Он может быть корпоративным ( . Разница заключается в том, что Enterprise CA может быть установлен только на сервер, являющийся членом домена, т.к. для его работы требуется служба каталога Active Directory. Standalone CA может работать вне домена, например, обрабатывая запросы пользователей, полученные через web-интерфейс. Для выполнения лабораторной работы нужно выбрать версию Enterprise.

Следующее окно мастера позволяет определить, создается корневой ( . В нашем примере создаваемый CA является первым и единственным, поэтому выбираем вариант Root.

(рис 7.5) Выбор типа центра сертификации(рис 7.4) Выбор типа центра сертификации (продолжение)

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

(рис 7.6) Выбор криптографического провайдера и алгоритма хеширования

Далее потребуется указать имя CA, размещение базы сертификатов и лог-файлов, и подтвердить сделанные настройки. После этого, роль будет установлена.

Задание

На учебном сервере или виртуальной машине установите роль Active Directory Certificate Services с настройками, аналогичными рассмотренным выше.

Управлять работой CA можно из оснастки ).

(рис 7.7) Управление центром сертификации

Как видно на рисунке, только что установленный Enterprise CA уже выпустил некоторое количество сертификатов для служебных целей (в частности, сертификаты контроллеров домена). В свойствах данного сервера (пункт ).

(рис 7.8) Настройки, определяющие порядок выпуска сертификатов

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

Задание

Ознакомьтесь с текущими настройками центра сертификации.

Опишите, какие шаблоны сертификатов (Certificate Templates) определены и для каких целей служит каждый тип сертификатов.

Посмотрите, какие сертификаты выпущены (Issued Certificates), есть ли отозванные сертификаты (Revoked Certificates).

Теперь рассмотрим процесс получения цифрового сертификата. Сделать это можно с помощью оснастки Certificates, с которой мы познакомились в лабораторной № 6. Если она не установлена, запустите консоль mmc и добавьте эту оснастку для текущей учетной записи.

Запустим оснастку, откроем раздел, посвященный сертификатам пользователя ( ). Из перечня предложенных шаблонов сертификатов выберем User. Данный тип сертификатов может использоваться для шифрования файлов с помощью EFS, защиты электронной почты и аутентификации пользователей.

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

Этот сертификат будет виден и в оснастке Certification Authority, в списке выпущенных данным сервером.

(рис 7.9) Запрос сертификата

Задание

Запросите сертификат для одного из пользователей.

После получения, изучите состав сертификата, его назначение.

Выполните экспорт сертификата (в оснастке Certificates выделите сертификат и в контекстном меню выберите All Tasks —> Export ). Обратите внимание, что можно экспортировать только сертификат или сертификат вместе с секретным ключом ( private key ). Второй вариант надо использовать аккуратно, чтобы кто-нибудь не узнал ваш секретный ключ шифрования. Такой тип экспорта нужен, если вы хотите сохранить резервную копию ключевой пары и сертификата.

Лабораторная работа 8. Шифрование данных при хранении - EFS

Шифрующая файловая система (Encrypting File System - EFS) появилась в операционных системах семейства Windows, начиная с Windows 2000. Она позволяет шифровать отдельные папки и файлы на томах с файловой системой NTFS. Рассмотрим этот механизм подробнее.

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

Следует учитывать, что для передачи по сети, зашифрованный EFS файл будет расшифрован, и для защиты данных в этих случаях надо использовать дополнительные механизмы.

Рассмотрим работу EFS. Пусть, у нас имеется сервер Windows Server 2008, входящий в домен, и три учетные записи, обладающие административными правами на сервере (одна из них - встроенная административная запись Administrator).

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

User1 с помощью оснастки Certificates запрашивает сертификат (можно выбрать шаблон User или Basic EFS). Теперь у него появляется ключевая пара и сертификат открытого ключа, и можно приступать к шифрованию.

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

(рис 8.1) В свойствах папки устанавливаем шифрование

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

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

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

Несмотря на то, что ).

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

(рис 8.2) Другой пользователь прочитать файл не сможет

Задание

Работая под первой учетной записью, запросите сертификат (если он не был получен ранее), после чего зашифруйте папку с тестовым файлом, который не жалко потерять. Проверьте, что будет происходить при добавлении файлов, переименовании папки, копировании ее на другой диск с файловой системой NFTS на том же компьютере, копировании папки на сетевой диск или диск с FAT.

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

Снова зайдите под первой учетной записью. В оснастке Certificates, удалите сертификат пользователя (несмотря на выдаваемые системой предупреждения). Завершите сессию пользователя в системе и войдите заново. Попробуйте открыть зашифрованный файл.

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

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

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

Задание

Зайдите в систему под встроенной учетной записью администратора и расшифруйте папку.

То, какой пользователь является агентом восстановления, задается с помощью групповых политик. Запустим оснастку ). Редактируя политику (пункт ).

(рис 8.4) Агент восстановления(рис 8.3) Изменение агента восстановления

Задание

Отредактируйте политику таким образом, чтобы убрать из системы агента восстановления (удалите в политике сертификат). Выполнив команду "gpupdate /force" (меню Start—>run—> gpupdate /force ) примените политику.

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

Теперь вернем в систему агента восстановления, но будем использовать новый сертификат. В редакторе политик находим политику Encrypting File System и в контекстном меню выбираем Create Data Recovery Agent. Это приведет к тому, что пользователь Administrator получит новый сертификат и с этого момента сможет восстанавливать шифруемые файлы.

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

В свойствах зашифрованного файла откроем окно с дополнительными параметрами, аналогичное представленному на рис 8.1 для папки. Если нажать кнопку видно, что в данный момент это пользователь User1 и агент восстановления Administrator. Нажав кнопку Add можно указать сертификаты других пользователей, которым предоставляется доступ к файлу.

(рис 8.5) Данные о пользователях, которые могут расшифровать файл

Задание

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

Лабораторная работа 9. Управление разрешениями на файлы и папки

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

Начнем с небольшого теоретического обзора.

Пользователи (как доменные, так и локальные), группы пользователей и компьютеры (далее будем называть их всех субъектами) имеют уникальные идентификаторы безопасности - SID. Под этим идентификатором система и "знает" субъекта. SID имеет уникальное значение в пределах домена и формируется во время создания пользователя или группы, либо когда компьютер регистрируется в домене.

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

Для объектов подлежащих защите (таких как файлы, папки, реестр Windows) создается дескриптор безопасности. С ним связывается список управления доступом (Access Control List - ACL), который содержит информацию о том, каким субъектам даны те или иные права на доступ к данному объекту. Чтобы определить, можно ли предоставить запрашиваемый субъектом тип доступа к объекту, ОС сравнивает SID в маркере доступа субъекта с SID, содержащимися в ACL.

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

Если говорить о файлах и папках, то механизмы защиты на уровне файловой системы поддерживаются только на дисках с файловой системой NTFS. Файловая система FAT (и ее разновидность - FAT32) не предполагает возможности хранения ACL, связанного с файлом.

Теперь перейдем к практической части работы. Выполняться она будет на компьютере с операционной системой Windows Server 2008, входящем в домен. Для выполнения работы понадобятся две учетные записи - администратора (далее будем называть его Administrator ) и пользователя, не входящего в группу администраторов (будем называть его TestUser ). Также понадобится тестовая группа ( TestGroup ). Все группы и учетные записи доменные, поэтому управление ими будем производить с помощью оснастки Active Directory Users and Computers.

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

(рис 9.2) Просмотр разрешений(рис 9.1) Изменение разрешений

Задание

Выполните действия, аналогичные описанным выше. Убедитесь, что пользователь TestUser отсутствует в списке доступа к папке, но есть в группе Users (последнее проверяется с помощью оснастки Active Directory Users and Computers, т.к. пользователь и группа доменные).

Выполните переключение пользователей, зайдите в систему под учетной записью TestUser, попробуйте открыть папку и создать в ней новый файл. Какие из этих действий удались? Почему ?

Снова выполните переключение пользователей. Под учетной записью Administrator добавьте в список доступа к файлу пользователя TestUser и дайте ему разрешение на изменение ( modify ). Пробуйте снова выполнить задание.

Как мы убедились, можно добавлять пользователей в список доступа. Теперь попробуем под учетной записью ) о том, что эти разрешения наследуются от родительского объекта. Для того, чтобы отменить наследование надо на вкладке ) нажать кнопку ) видно, что отмечено свойство Include inheritable permissions from this object's parent. Это значит, что объект наследует родительский ACL, а в его собственный можно только добавлять разрешения или запрещения. Если нажать кнопку Edit и сбросить эту галочку будет задан вопрос, что делать с унаследованным списком - его можно скопировать ( Copy ) в ACL объекта или убрать ( Remove ). Чаще всего, чтобы не потерять нужные настройки, выполняется копирование, а потом уже список исправляется.

(рис 9.4) Предупреждение(рис 9.3) Дополнительные параметры безопасности

Задание

Удалите группу Users из ACL для папки.

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

(рис 9.5) Специальные разрешения

Это так называемые специальные разрешения. Виденные ранее стандартные разрешения (чтение/read, запись/write и т.д.) состоят из специальных. Соответствие между ними описано на рис 9.6 (набор разрешений для папок и файлов несколько отличается, но понять какие к чему относятся можно по названиям). Более подробно с этой темой можно ознакомиться, например, по справочной системе Windows.

(рис 9.6) Соответствие между специальными и стандартными разрешениями

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

Задание

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

Не заканчивая сеанса пользователя, переключитесь в сеанс пользователя Administrator. Добавьте в список разрешений на папку запрещение для группы TestGroup всех видов доступа (выберите Deny для разрешения Full Control ). Внесите пользователя TestUser в группу TestGroup. Посмотрите эффективное разрешение для пользователя TestUser.

Переключитесь в сеанс пользователя TestUser. Попробуйте открыть папку и создать документ. Завершите сеанс TestUser (выполните выход из системы) и снова войдите в систему. Повторно попробуйте открыть папку и создать документ. Как можно объяснить полученный результат (подсказка есть в начале описания лабораторной)?

Теперь рассмотрим вопросы, связанные с владением папкой или файлом. Пользователь, создавший папку или файл, становится ее владельцем. Текущего владельца объекта можно узнать, если в окне дополнительных параметров безопасности (рис 9.4) выбрать вкладку Owner.

Владелец файла может изменять разрешения на доступ к этому файлу, даже в том случае, если ему самому доступ запрещен.

Порядок смены владельца файла в Windows Server 2008 отличается от того, что было в предыдущих версиях ОС. Ранее, администратор или пользователь, имеющий на файл (папку) право Take Ownership могли стать владельцами файла. Причем, владельцем мог быть или конкретный пользователь, или группа Администраторы ( Adminisrators ) - другую группу владельцем было не назначить.

В Windows Server 2008 администратор (или член группы администраторов) может не только сам стать владельцем, но и передать право владения произвольному пользователю или группе. Но эта операция рассматривается как привилегированная, и доступна не всякому пользователю, имеющему право на файл.

На рис 9.7 показано, что Администратор сделал владельцем папки Test группу TestGroup.

(рис 9.7) Смена владельца объекта

Задание

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

(рис 9.8) Разрешения на общую папку

При использовании компьютера с Windows Server 2008 в качестве файлового сервера, важно учитывать, что на предоставляемые в общий доступ папки, отдельно устанавливаются разрешения, регулирующие доступ к ним по сети. Сделать это можно в свойствах папки на вкладке Sharing (рис 9.8). В этом случае, при доступе по сети действуют и разрешения на общую папку, и разрешения NTFS. В результате получаем наиболее строгие ограничения. Например, если на общую папку установлено "только чтение", а в разрешениях NTFS - "изменение", то в итоге, подключающийся по сети пользователь сможет только читать файлы. А тот же пользователь при локальном доступе получает право на изменение (разрешения на общую папку влиять не будут).

Лабораторная работа 10. Резервное копирование в Windows Server 2008

Цель данной лабораторной работы - познакомиться со средствами организации резервного копирования в операционной системе Microsoft Windows Server 2008.

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

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

частоту выполнения резервных копий;

порядок восстановления данных из резервных копий;

объем носителей информации, выделяемых для хранения резервных копий;

количество хранимых копий;

вопросы обеспечения безопасности носителей резервных копий.

Утилиты резервного копирования Windows Server 2008 существенно отличаются от того, что было в Windows Server 2003 (где эти задачи решались с помощью утилиты ntbackup). Чтобы их использовать, для начала требуется их установить (по умолчанию, они не устанавливаются). Делается это с помощью оснастки ) и в появившемся списке выбрать пункт .).

(рис 10.1) Оснастка Server Manager позволяет добавить компоненты

Как видно на рис 10.2, предлагается выбрать следующие опции:

Windows Server Backup;

Command-line tools (утилиты командной строки).

Установка последних, позволяет управлять резервным копированием с помощью сценариев и требует установки Windows PowerShell. Но для выполнения лабораторной будет достаточно установить только Windows Server Backup.

(рис 10.2) Добавляем утилиты администрирования

После установки, в меню Administrative Tools становится доступной оснастка Windows Server Backup. С ее помощью можно проводить резервное копирование данных на локальном или удаленном компьютере (если это разрешено настройками).

Рассмотрим, как это происходит. Запустим утилиту. Резервное копирование может проводить пользователь, состоящий в группе Administrators (Администраторы) или Backup Operators (Операторы архива). При этом, у членов группы Backup Operators при запуске оснастки Windows Server Backup будет дополнительно запрашиваться пароль (в окне User Account Control ), т.к. эти операции относятся к разряду потенциально опасных.

В окне оснастки в списке доступных действий ( Actions ), расположенном в правой части экрана, выберем опцию Backup Once … (т.е. однократная архивация). Запустившийся мастер резервного копирования предложит выбор между настройками для уже запланированного копирования ( The same options that you used in the Backup Schedule Wizard for scheduled backups ) и новыми ( Different options ). Нужно выбрать второй вариант (если, как в нашем примере, утилита ранее не использовалась, то первый пункт списка будет неактивен).

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

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

Выберем вариант Custom.

Тогда на следующем экране появится список дисков (рис 10.4). Устанавливая или снимая отметки, можно указать, данные с каких дисков помещаются в резервную копию. Опция Enable System Recovery включает в архив разделы, где находятся компоненты операционной системы и файлы необходимые для загрузки (т.е. отметку напротив этих разделов будет не снять).

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

(рис 10.4) Выбор между полным резервным копированием и копированием отдельных дисков(рис 10.3) Выбор дисков для резервного копирования

Учитывая все вышеизложенное, в рассматриваемом примере можно сделать резервную копию диска E: на диск F:, в сетевую папку или на DVD-диск. Выберем первый вариант, что и укажем в следующем окне мастера. После чего будет предложено выбрать тип резервного копирования (рис 10.5).

(рис 10.5) Выбор типа копирования

Служба Volume Shadow Copy Service (VSS) может при резервном копировании отмечать файлы, как помещенные в архив, или не делать это. Если кроме средств Windows Server 2008 используются и другие продукты для резервного копирования, рекомендуется выбрать вариант VSS copy backup. Если такого нет, можно смело выбирать вариант VSS full backup.

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

В результате, в нашем примере на диске F: появится каталог WindowsImageBackup, в нем будет создан подкаталог, названный по имени архивируемого сервера, куда и попадет копия.

Задание

На учебном сервере (или виртуальной машине) выберите раздел для резервного копирования.

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

Выполните однократное резервное копирование выбранного раздела.

Теперь рассмотрим порядок восстановления данных из резервной копии.

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

Запускаем оснастку ).

(рис 10.6) Перечень доступных резервных копий для выбранного сервера

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

(рис 10.7) Выбор типа восстановления

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

(рис 10.8) Параметры восстановления

Кроме пути (исходный или альтернативный), выбирается вариант действий при совпадении имен файлов и папок. Это особенно актуально, если восстанавливать файлы в исходную папку. Вариантов три - создавать копии, перезаписывать имеющиеся объекты восстанавливаемыми, оставить имеющиеся объекты.

Последний из выбираемых в этом окне параметров указывает на то, восстанавливать ли настройки безопасности (т.е. списки доступа к файлам).

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

Задание

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

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

что будет копироваться (полное резервное копирование сервера или отдельные диски);

как часто надо проводить копирование;

где размещать копии.

При этом надо учитывать:

даже при выборе резервного копирования отдельных разделов, в их список обязательно должен быть внесен раздел (-ы) с операционной системой;

копирование может выполняться один или несколько раз в день;

для хранения результатов резервного копирования должен выделяться отдельный диск, внутренний или внешний (например, подключаемый по USB). Перед началом использования, он будет отформатирован мастером архивации. Рекомендуется, чтобы он был не менее чем в 1,5 раза больше по объему, чем архивируемые диски.

Пусть требуется ежедневно делать резервное копирование диска раздела с операционной системой. В окне мастера аналогичном рис 10.3, выбираем вариант Custom, в окне аналогичном рис 10.4 - диск C (на котором расположена операционная система). Указываем расписание (рис 10.9).

(рис 10.9) Расписание резервного копирования

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

(рис 10.10) Диск для хранения резервных копий

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

(рис 10.11) Выбор типа резервного копирования для диска

Порядок восстановления такой же, как и при однократном копировании.

Кстати, посмотреть параметры запланированного резервного копирования можно с помощью оснастки ).

(рис 10.12) Параметры созданного задания

Задание

Разработайте и реализуйте план ежедневного резервного копирования раздела с операционной системой.

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

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

После создания копии, восстановите какой-либо из файлов.

Используя опцию Backup Schedule оснастки Windows Server Backup, удалите запланированное задание на резервное копирование.

Страницы:

Рассматриваемые вопросы можно разделить на две группы:

вопросы, связанные с идентификацией и аутентификацией пользователей;

защита передаваемых сообщений.

Идентификация и аутентификация

Обычно выделяют 3 группы методов аутентификации.

Протокол Kerberos

сервер аутентификации (англ. Authentication Server, сокр. AS);

сервер выдачи разрешений (англ. Ticket Granting Server, сокр. TGS).

(рис 5.1) Протокол Kerberos

C->AS: {c}.

AS->C: {{TGT}K_{AS_TGS}, K_{C_TGS}}K_C,

где:

K_C - основной ключ C ;

K_{C_TGS} - ключ, выдаваемый C для доступа к серверу выдачи разрешений TGS ;

{TGT} - Ticket Granting Ticket - билет на доступ к серверу выдачи разрешений

Запись $$\{ \cdot \} K_{X}$$ здесь и далее означает, что содержимое фигурных скобок зашифровано на ключе K_X.

C->TGS: {TGT}K_{AS_TGS}, {Aut₁} K_{C_TGS}, {ID}

TGS->C: {{TGS}K_{TGS_SS},K_{C_SS}}K_{C_TGS},

C->SS: {TGS}K_{TGS_SS}, {Aut₂} K_{C_SS}

где Aut₂={c,t₄}.

SS->C: {t₄+1}K_{C_SS}

(рис 5.2) Взаимодействие между Kerberos-областями

Что касается реализации протокола Kerberos в Windows, то надо отметить следующее.

Использование Kerberos требует синхронизации внутренних часов компьютеров, входящих в домен Windows.

Инфраструктура открытых ключей. Цифровые сертификаты

(рис 5.3) Атака типа man-in-the-middle

(рис 5.4) Структура PKI

(рис 5.5) Иерархия центров сертификации и клиентов

Серийный номер - уникальный номер, присваиваемый каждому сертификату.

(рис 5.6) Сертификат формата X.509 v.3

При записи Relative Distinguished Name используются специальные ключевые слова:

CN (Common Name) - общее имя;

OU (Organization Unit) - организационная единица;

DC (Domain Component) - составная часть доменного имени.

CN = Microsoft Root Authority

OU = Microsoft Corporation

Как видно, указывается имя центра сертификации, компания, которой он принадлежит и т.д.

CN = Microsoft Windows Hardware Compatibility

OU = Microsoft Corporation

OU = Microsoft Windows Hardware Compatibility Intermediate CA

ЭЦП - само значение электронно-цифровой подписи для данного сертификата.

Расширения могут определять следующие дополнительные параметры:

идентификатор конкретного ключа пользователя (субъекта), если пользователь имеет несколько сертификатов;

политики использования сертификата;

альтернативное имя пользователя и центра сертификации;

запрашивает в сетевом справочнике сертификат C_B открытого ключа подписи (шифрования,...) абонента B ;

проверяет достоверность сертификата C_B (см. ниже);

Процедура проверки достоверности сертификата C_B состоит в следующем:

проверяется срок действия сертификата C_B, если он закончился, сертификат считается недостоверным;

из C_B извлекается имя ЦС, подписавшего этот сертификат, обозначим его D ;

(рис 5.7) Структура списка отозванных сертификатов

Поля списка содержат следующую информацию:

Номер версии определяет номер версии формата CRL. Текущая используемая версия - вторая.

Изготовитель - имя центра сертификации в формате RDN.

Выпущен - дата выпуска CRL.

Следующий - дата, до которой будет выпущен следующий CRL.

Расширения - описывают центр сертификации, точку для поиска CRL данного центра, номер данного списка и т.д.

Алгоритм ЭЦП - идентификатор алгоритма ЭЦП, используемого для подписи списка.

ЭЦП - сама электронная цифровая подпись.

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

Протокол защиты электронной почты S/MIME

проверка целостности сообщения;

установление подлинности отправителя (аутентификация);

обеспечение секретности передаваемых данных (шифрование).

(рис 5.8) Фрагмент электронного письма с подписью

Протокол IPSec

контроль доступа;

контроль целостности данных;

аутентификация данных;

защита от повторений;

обеспечение конфиденциальности.

(рис 5.9) Туннель безопасности

IP-адрес получателя;

указание на протоколы безопасности, используемые при передаче данных;

ключи, необходимые для шифрования и формирования имитовставки (если это требуется);

указание на метод форматирования, определяющий, каким образом создаются заголовки;

индекс параметров защиты (от англ. Security Parameter Index, сокр. SPI) - идентификатор, позволяющий найти нужный SA.

Два протокола, входящие в состав IPSec это:

Протокол AH

(рис 5.11) Структура заголовка протокола AH

Поле Payload Len указывает длину заголовка AH в 32-битных словах. Далее 16 бит зарезервировано.

Поле Authentication Data, как уже указывалось ранее, хранит значение ICV.

Протокол ESP

для формирования имитовставки HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96;

для шифрования - DES (в режиме CBC, используется по умолчанию) и NULL (отсутствие шифрования).

(рис 5.13) а) исходный IP-пакет; b) ESP в транспортном режиме; c) ESP в туннельном режиме(рис 5.12) Структура заголовка ESP

IPSec и NAT

(рис 5.14) Пример использования NAT

Таблица NAT
Протокол	Внутренний локальный ip адрес : порт	Внутренний зарегистрированный ip-адрес: порт	Внешний ip адрес: порт
TCP	192.168.0.2: 2001	195.201.82.146: 2161	195.242.2.2 : 80

Лабораторная работа 6. Использование цифровых сертификатов

Для примера обратимся на сайт Ситибанка (http://www.citibank.ru), в раздел ).

(рис 6.1) Защищенное соединение

Выбрав ).

(рис 6.2) Параметры сертификата

Задание

(рис 6.3) Браузер сообщает о проблеме с сертификатом

Если нажать ссылку "Продолжить открытие этого web-узла" можно будет просмотреть сертификат.

Задание

Разберитесь, в чем проблема с указанным сертификатом.

Прим. На всякий случай в конце описания лабораторной приведен ответ.

Теперь перейдем к разделу ).

(рис 6.4) Отозванные сертификаты

В результате в оснастке ).

(рис 6.6) Полученный сертификат(рис 6.5) Выбор сертификата для защиты почты с помощью S/MIME в Outlook

Задание

Запросите сертификат в Thawte и настройте почтовый клиент для использования S/MIME.

Ответ на задание про сертификат на сайте Tele2

Доверять или нет такому сертификату - каждый решает самостоятельно.

Лабораторная работа 7. Создание центра сертификации (удостоверяющего центра) в Windows Server 2008

В .

(рис 7.1) Добавление роли

(рис 7.3) Выбор добавляемой роли(рис 7.2) Выбор устанавливаемых компонент

(рис 7.5) Выбор типа центра сертификации(рис 7.4) Выбор типа центра сертификации (продолжение)

(рис 7.6) Выбор криптографического провайдера и алгоритма хеширования

Задание

Управлять работой CA можно из оснастки ).

(рис 7.7) Управление центром сертификации

(рис 7.8) Настройки, определяющие порядок выпуска сертификатов

Задание

Ознакомьтесь с текущими настройками центра сертификации.

Посмотрите, какие сертификаты выпущены (Issued Certificates), есть ли отозванные сертификаты (Revoked Certificates).

Этот сертификат будет виден и в оснастке Certification Authority, в списке выпущенных данным сервером.

(рис 7.9) Запрос сертификата

Задание

Запросите сертификат для одного из пользователей.

После получения, изучите состав сертификата, его назначение.

Лабораторная работа 8. Шифрование данных при хранении - EFS

(рис 8.1) В свойствах папки устанавливаем шифрование

Несмотря на то, что ).

(рис 8.2) Другой пользователь прочитать файл не сможет

Задание

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

Задание

Зайдите в систему под встроенной учетной записью администратора и расшифруйте папку.

(рис 8.4) Агент восстановления(рис 8.3) Изменение агента восстановления

Задание

(рис 8.5) Данные о пользователях, которые могут расшифровать файл

Задание

Лабораторная работа 9. Управление разрешениями на файлы и папки

Начнем с небольшого теоретического обзора.

(рис 9.2) Просмотр разрешений(рис 9.1) Изменение разрешений

Задание

(рис 9.4) Предупреждение(рис 9.3) Дополнительные параметры безопасности

Задание

Удалите группу Users из ACL для папки.

(рис 9.5) Специальные разрешения

(рис 9.6) Соответствие между специальными и стандартными разрешениями

Задание

На рис 9.7 показано, что Администратор сделал владельцем папки Test группу TestGroup.

(рис 9.7) Смена владельца объекта

Задание

(рис 9.8) Разрешения на общую папку

Лабораторная работа 10. Резервное копирование в Windows Server 2008

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

частоту выполнения резервных копий;

порядок восстановления данных из резервных копий;

объем носителей информации, выделяемых для хранения резервных копий;

количество хранимых копий;

вопросы обеспечения безопасности носителей резервных копий.

(рис 10.1) Оснастка Server Manager позволяет добавить компоненты

Как видно на рис 10.2, предлагается выбрать следующие опции:

Windows Server Backup;

Command-line tools (утилиты командной строки).

(рис 10.2) Добавляем утилиты администрирования

Выберем вариант Custom.

(рис 10.5) Выбор типа копирования

Задание

На учебном сервере (или виртуальной машине) выберите раздел для резервного копирования.

Выполните однократное резервное копирование выбранного раздела.

Теперь рассмотрим порядок восстановления данных из резервной копии.

Запускаем оснастку ).

(рис 10.6) Перечень доступных резервных копий для выбранного сервера

(рис 10.7) Выбор типа восстановления

(рис 10.8) Параметры восстановления

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

Задание

что будет копироваться (полное резервное копирование сервера или отдельные диски);

как часто надо проводить копирование;

где размещать копии.

При этом надо учитывать:

копирование может выполняться один или несколько раз в день;

(рис 10.9) Расписание резервного копирования

(рис 10.10) Диск для хранения резервных копий

(рис 10.11) Выбор типа резервного копирования для диска

Порядок восстановления такой же, как и при однократном копировании.

Кстати, посмотреть параметры запланированного резервного копирования можно с помощью оснастки ).

(рис 10.12) Параметры созданного задания

Задание

Разработайте и реализуйте план ежедневного резервного копирования раздела с операционной системой.

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

После создания копии, восстановите какой-либо из файлов.

Используя опцию Backup Schedule оснастки Windows Server Backup, удалите запланированное задание на резервное копирование.

Занятие пройдено

Предыдущее занятие Занятие пройдено Следующее занятие

Вернуться к учебному плану

Идентификация и аутентификация. Протокол Kerberos

Идентификация и аутентификация

Протокол Kerberos

Инфраструктура открытых ключей. Цифровые сертификаты

Протокол защиты электронной почты S/MIME

Протокол IPSec

Протокол AH

Протокол ESP

IPSec и NAT

Лабораторная работа 6. Использование цифровых сертификатов

Задание

Задание

Задание

Ответ на задание про сертификат на сайте Tele2

Лабораторная работа 7. Создание центра сертификации (удостоверяющего центра) в Windows Server 2008

Задание

Задание

Задание

Лабораторная работа 8. Шифрование данных при хранении - EFS

Задание

Задание

Задание

Задание

Лабораторная работа 9. Управление разрешениями на файлы и папки

Задание

Задание

Задание

Задание

Лабораторная работа 10. Резервное копирование в Windows Server 2008

Задание

Задание

Задание

Идентификация и аутентификация

Протокол Kerberos

Инфраструктура открытых ключей. Цифровые сертификаты

Протокол защиты электронной почты S/MIME

Протокол IPSec

Протокол AH

Протокол ESP

IPSec и NAT

Лабораторная работа 6. Использование цифровых сертификатов

Задание

Задание

Задание

Ответ на задание про сертификат на сайте Tele2

Лабораторная работа 7. Создание центра сертификации (удостоверяющего центра) в Windows Server 2008

Задание

Задание

Задание

Лабораторная работа 8. Шифрование данных при хранении - EFS

Задание

Задание

Задание

Задание

Лабораторная работа 9. Управление разрешениями на файлы и папки

Задание

Задание

Задание

Задание

Лабораторная работа 10. Резервное копирование в Windows Server 2008

Задание

Задание

Задание

Купить дополнительную попытку

Вы действительно хотите купить ещё одну попытку для прохождения тестирования?

Успешно!

Напишите нам, если у вас есть вопросы

Уважаемые пользователи ИНТУИТ!

Уважаемые пользователи ИНТУИТ!

Добро пожаловать на обновлённый сайт НОУ «ИНТУИТ»!