Аутентификация
Теория и практика
обеспечения безопасного доступа
к информационным ресурсам
Рекомендовано Учебно-методическим объединением
по образованию в области информационной безопасности
и одобрено ФСТЭК России
в качестве учебного пособия для студентов высших
учебных заведений, обучающихся по специальностям
090102 — «Компьютерная безопасность»,
090105 — «Комплексное обеспечение информационной
безопасности автоматизированных систем»
Под редакцией
А. А. Шелупанова, С. Л. Груздева, Ю. С. Нахаева
Москва
Горячая линия—Телеком
2009
УДК 004.732.056(075.8)
ББК 32.973.2-018.2я73
А93
Авторы: А. А. Афанасьев, Л. Т. Веденьев, А. А. Воронцов, Э. Р. Газизова, А. Л. Додохов,
А. В. Крячков, О. Ю. Полянская, А. Г. Сабанов, М. А. Скида, С. Н. Халяпин,
А. А. Шелупанов
А93 Аутентификация. Теория и практика обеспечения безопасного доступа к инфор-
мационным ресурсам. Учебное пособие для вузов / А. А. Афанасьев, Л. Т. Веденьев,
А. А. Воронцов и др.; Под ред. А. А. Шелупанова, С. Л. Груздева, |Ю. С. Нахаева|. —
М.: Горячая линия—Телеком, 2009. — 552 с.: ил.
ISBN 978-5-9912-0110-0
Книга посвящена одному из аспектов проблемы управления доступом к информации в
компьютерных системах — аутентификации.
Фактически защита информации начинается с аутентификации пользователей. Каждый
пользователь современных компьютерных систем сталкивается с процедурами аутенти-
фикации неоднократно в течение рабочего дня. Книга описывает достоинства и недостатки
практически всех существующих и используемых на настоящий момент способов аутенти-
фикации и ориентирована на широкий круг читателей.
Книга адресована студентам вузов и аспирантам, обучающимся по специальностям,
связанным с защитой информации, ИТ-специалистам и специалистам по информацион-
ной безопасности; специалистам, получающим второе высшее образование в области за-
щиты информации, и слушателям курсов переподготовки.
ББК 32.973.2-018.2я73
Адес издательства в Интернет WWW.TECHBOOK.RU
Учебное издание
Аутентификация
Теория и практика обеспечения безопасного доступа
к информационным ресурсам
Учебное пособие для вузов
Редактор И. Н. Андреева
Обложка художника В. Г. Ситникова
Компьютерная верстка Е. В. Конова, Е. М. Патрушева
Подписано в печать 15.08.09. Формат 70x100/16. Усл. печ. л. 45,75. Тираж 1000 экз. Изд. № 9110
ООО «Научно-техническое издательство «Горячая линия—Телеком»
Отпечатано в ООО ПФ «Полиграфист», 160001, г. Вологда, ул. Челюскинцев, 3.
Зак. 5680
ОГЛАВЛЕНИЕ
ПРЕДИСЛОВИЕ	7
ЧАСТЬ I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ	9
Глава 1. ОБЩИЕ СВЕДЕНИЯ	10
1.1.	Основные понятия и определения..........................10
1.2.	Роль и задачи аутентификации. Место аутентификации
в структуре основных направлений защиты информации..........10
1.3.	Факторы аутентификации...................................13
Контрольные вопросы...........................................15
Глава 2. ПАРОЛЬНАЯ АУТЕНТИФИКАЦИЯ	16
2.1.	Аутентификация с помощью запоминаемого пароля............16
2.2.	Методы парольной аутентификации..........................16
2.3.	Парольные политики.......................................19
2.4.	Недостатки методов аутентификации с запоминаемым паролем.19
Контрольные вопросы...........................................22
Глава 3. АУТЕНТИФИКАЦИЯ С ПОМОЩЬЮ
БИОМЕТРИЧЕСКИХ ХАРАКТЕРИСТИК.....................................23
3.1.	Биометрические характеристики............................23
3.2.	Как работают биометрические системы......................24
3.3.	Аутентификация и биометрическое распознавание............26
3.4.	Реализация биометрических систем.........................27
3.5.	Недостатки аутентификации с помощью биометрических характеристик.
Возможные атаки.............................................28
Контрольные вопросы...........................................29
Глава 4. АУТЕНТИФИКАЦИЯ С ПОМОЩЬЮ
ОДНОРАЗОВЫХ ПАРОЛЕЙ..............................................30
4.1.	Аппаратно-программные ОТР-токены.........................32
4.2.	Как работают ОТР-токены..................................32
4.3.	Методы аутентификации с помощью ОТР-токенов..............32
4.4.	Сравнение методов ОТР-аутентификации.....................36
4.5.	Системы одноразовых паролей..............................37
4.6.	Недостатки методов аутентификации с помощью ОТР.
Возможные атаки.............................................41
Контрольные вопросы...........................................42
Глава 5. КРИПТОГРАФИЯ С ОТКРЫТЫМ КЛЮЧОМ............ .............43
5.1.	Общие сведения о криптографии с открытым ключом..........43
3
5.2.	Авторизация и обеспечение юридической значимости электронных
документов....................................................47
5.3.	Конфиденциальность и контроль целостности передаваемой
информации....................................................48
5.4.	Аутентификация связывающихся сторон.......................48
5.5.	Установление аутентичного защищенного	соединения..........48
5.6.	Инфраструктура открытых ключей (PKI)......................49
5.7.	Аутентификация с помощью открытого ключа на основе сертификатов ... 49
5.8.	Организация хранения закрытого ключа......................50
5.9.	Интеллектуальные устройства и аутентификация с помощью
открытого ключа...............................................52
5.10.	Недостатки аутентификации с помощью открытых ключей.
Возможные атаки...............................................54
Контрольные вопросы............................................56
Глава 6. ПРОТОКОЛЫ АУТЕНТИФИКАЦИИ В ЛОКАЛЬНОЙ СЕТИ................57
6.1.	Протоколы LAN Manager	и	NT LAN Manager....................57
6.2.	Протокол Kerberos.........................................62
6.3.	Протокол Kerberos + PKINIT................................73
Контрольные вопросы............................................76
Глава 7. МЕХАНИЗМЫ АУТЕНТИФИКАЦИИ ПРИ ОСУЩЕСТВЛЕНИИ
ПОДКЛЮЧЕНИЙ.......................................................77
7.1.	Протокол PPP РАР..........................................77
7.2.	Протокол PPP CHAP.........................................78
7.3.	Протокол PPP ЕАР..........................................79
7.4.	Протокол TACACS+..........................................81
7.5.	Протокол RADIUS...........................................84
7.6.	Стандарт IEEE 802.1х и протокол EAPOL.....................86
7.7.	Протокол EAP-TLS с использованием российской криптографии.89
7.8.	Стандарт IEEE 802.1х в операционных системах Microsoft....93
7.9.	Cisco NAC.................................................94
Контрольные вопросы............................................97
Глава 8. АУТЕНТИФИКАЦИЯ В ЗАЩИЩЕННЫХ СОЕДИНЕНИЯХ..................98
8.1.	Протоколы SSL, TLS........................................98
8.2.	Протокол SSH.............................................100
8.3.	Протокол S-HTTP..........................................101
8.4.	Протокол SOCKS...........................................102
8.5.	Семейство протоколов IPSec...............................103
8.6.	Протоколы защищенного взаимодействия и аутентификации
для корпоративных беспроводных локальных сетей...............116
Контрольные вопросы............................................124
4
Глава 9. ПРИМЕНЕНИЕ АППАРАТНЫХ СРЕДСТВ АУТЕНТИФИКАЦИИ
И ХРАНЕНИЯ КЛЮЧЕВОЙ ИНФОРМАЦИИ.................................125
9.1.	Аппаратные средства защиты в современных РК1-решениях..125
9.2.	Необходимость применения аппаратных средств аутентификации
и хранения ключевой информации..............................126
9.3.	Типовые требования к средствам аутентификации и хранения
ключевой информации..........................................135
9.4.	Особенности корпоративного использования персональных средств
аутентификации и хранения ключевой информации................139
9.5.	Централизованная система управления средствами аутентификации
и хранения ключевой информации пользователей................142
9.6.	Типовые требования к системе управления токенами.......145
9.7.	Token Management System (TMS) компании Aladdin.........146
9.8.	Практика: комплексная система на базе единого персонального
средства аутентификации и хранения ключевой информации......149
Контрольные вопросы.........................................153
Список использованной литературы.................................153
ЧАСТЬ II. ПРАКТИКА...............................................155
Введение.......................................................156
Глава 1. ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ДОСТУПА К ДАННЫМ
И ПРИЛОЖЕНИЯМ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОРГАНИЗАЦИИ
НА ОСНОВЕ РЕКОМЕНДАЦИЙ И ПРОДУКТОВ MICROSOFT.
ТИПОВЫЕ РЕШЕНИЯ................................................157
1.1.	Основные сервисы для обеспечения надежной аутентификации
и управления доступом.......................................157
1.2.	Авторизация при доступе к объекту......................169
1.3.	Система аудита Active Directory........................170
1.4.	Назначение и решаемые задачи инфраструктуры открытых ключей.172
1.5.	Управление идентификацией (1LM)........................173
1.6.	Microsoft Identity Integration Server (M11S)...........173
1.7.	Системы обеспечения....................................175
Глава 2. ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ДОСТУПА К ДАННЫМ
И ПРИЛОЖЕНИЯМ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОРГАНИЗАЦИИ
НА ОСНОВЕ РЕКОМЕНДАЦИЙ И ПРОДУКТОВ ORACLE И ALADDIN.
ТИПОВЫЕ РЕШЕНИЯ................................................177
2.1. Управление доступом в СУБД Oracle с помощью встроенных механизмов
безопасности и криптографических средств защиты..........177
5
Глава 3. ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ДОСТУПА К ДАННЫМ
И ПРИЛОЖЕНИЯМ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОРГАНИЗАЦИИ
НА ОСНОВЕ ПРОДУКТОВ КОМПАНИИ CITRIX SYSTEMS....................226
3.1. Описание продуктов компании Citrix Systems..............226
3.2. Компоненты систем, построенных с использованием ХепАрр..228
Список использованной литературы..................................244
Источники.......................................................  245
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ....................................247
Лабораторная работа № 1. Подготовка стенда, установка и настройка ПО,
подготовка электронных ключей eToken...........................248
Лабораторная работа № 2. Установка и настройка Центра сертификации,
использование ключей eToken в домене Windows Server 2003 ......282
Лабораторная работа № 3. Использование eToken для безопасного доступа
к информационным ресурсам, для шифрования и для ЭЦП............326
Лабораторная работа № 4. Сопровождение функционирования Центра
сертификации, повышение защищенности систем на основе
Windows Server 2003 ...........................................399
Лабораторная работа № 5. Доступ в СУБД Oracle с аутентификацией
по имени пользователя и паролю в LDAP-каталоге.................428
Лабораторная работа № 6. Доступ в СУБД Oracle с аутентификацией
на основе сертификатов.........................................458
Лабораторная работа № 7. Режимы работы протокола IPSec на модуле
NME-RVPN при использовании программного обеспечения CSP VPN Gate
для аутентификации и защиты данных.............................491
Лабораторная работа № 8. Настройка Web Interface 4.x для использования
смарт-карт.....................................................509
Лабораторная работа № 9. Настройка Secure Gateway для безопасного
подключения к опубликованным приложениям из недоверенных сред
передачи данных................................................530
ПРЕДИСЛОВИЕ
Судьба данного учебного пособия весьма необычна. На партнерской конференции по
информационной безопасности компании Aladdin у нас появилась идея создать книгу по
теоретическим и практическим вопросам аутентификации. Эту книгу можно было бы
использовать не только при обучении студентов и аспирантов ВУЗов и СУЗов по учеб-
ным дисциплинам «Безопасность баз данных», «Программно-аппаратные средства обес-
печения информационной безопасности», «Безопасность операционных систем», «Ком-
пьютерная безопасность» и т. д., но и в практической деятельности ИТ-специалистов,
системных администраторов, администраторов безопасности различных сетей и систем.
Любая поисковая система в Интернет по запросу «аутентификация» предоставляет
более 1 миллиона ссылок на различные информационные ресурсы. Этот очевидный факт
подтверждает широкое распространение и использование механизмов аутентификации
в практике обеспечения безопасности сетей, систем, различных приложений. Оценив
интерес и востребованность данной технологии, мы решили взяться за дело.
Всю сложность воплощения нашей идеи мы поняли несколько позже, когда взялись
за ее реализацию. Первая трудность состояла, главным образом, в том, чтобы объединить
усилия специалистов зарубежных и российских компаний, признанных лидеров на рынке
информационных технологий, таких, как компании Microsoft, Aladdin, Cisco Systems, Citrix,
Oracle, Крипто-Про. При этом, помимо необходимых теоретических сведений, мы соби-
рались предложить читателю различные решения, технологии и продукты для реализации
задач по обеспечению безопасности доступа к данным и приложениям информационной
системы организации, защищенных соединений. Речь идет как о представлении типо-
вых решений, так и о возможной кастомизации продуктов под конкретные системы.
Другая сложность состояла в том, чтобы систематизировать, порой весьма противоречи-
вые сведения, стили изложения, подходы к реализации решений в различных компаниях,
и представить методически выверенные теоретические и практические материалы, в том
числе и в виде готовых лабораторных работ для использования их в учебном процессе
Третья сложность состояла в том, чтобы преодолев препоны конкурентного противостоя-
ния компаний, создать полезную и, на наш взгляд, весьма своевременную и актуальную
книгу без рекламы конкретных компаний. И наконец, любая работа, которая делается
на общественных началах, зачастую страдает недостатком времени или возможности до-
вести идею создания учебного пособия до логического завершения. Это обстоятельство
явилось причиной отсутствия материалов в данной книге еще нескольких ведущих компа-
ний — вендоров (IBM, Check Point Software Technologies, Сигнал-Ком, SUN и т. д.). На-
деемся, что эти материалы войдут во второе издание данного учебного пособия. Потре-
бовался весьма продолжительный период времени для решения организационных меро-
приятий, экспертизы и апробации материалов в учебных заведениях России, при
проведении тренингов ИТ-специалистов, сотрудников служб информационной безопас-
ности, студентов профильных ВУЗов и т. п.
К счастью, нам удалось преодолеть все эти трудности, и мы надеемся, что книга ока-
жется полезной как в учебном процессе, так и в практической работе.
Учебное пособие состоит из теоретической и практической частей. Практическая часть
содержит 9 лабораторных работ по типовым решениям с использованием продуктов раз-
личных компаний. Описание лабораторных работ можно найти по адресу в Интернет:
http://www.aladdin.ru/book/
Согласно замыслу авторов, книга, которую Вы держите в руках, призвана открыть перед
читателем суть и возможности технологии аутентификации, как базового элемента любой
системы информационной безопасности современных компаний.
7
Специалистам, уже знакомым с данными технологиями, книга поможет систематизи-
ровать и расширить свои знания в части прикладного применения средств аутентифи-
кации и интеграции их с другими продуктами и решениями для защиты информации.
Развивать рынок аутентификации, способствовать повышению уровня и качества про-
ектов в области ИТ-безопасности, а, главное, содействовать формированию четкого по-
нимания ценности информации в современном мире — основная цель данной книги.
Мы искренне благодарим всех, кто поддерживал и продолжает поддерживать этот
проект, помогает в его продвижении, а также распространении книги.
Особую благодарность выражаем Федеральной службе безопасности России (ФСБ Рос-
сии), Федеральной службе по техническому и экспортному контролю России (ФСТЭК
России), Совету Безопасности Российской Федерации и Учебно-методическому объеди-
нению по образованию в области информационной безопасности за проявленный ин-
терес, полезные замечания и конструктивную критику.
Отдельно хочется отметить вклад в работу при подготовке рукописи данной книги
безвременно ушедшего из жизни руководителя аналитического отдела компании
Aladdin, кандидата физико-математических наук Нахаева Ю.С.
Мы не планируем останавливаться на достигнутом результате и рассматриваем идею
выпуска второго расширенного издания данной книги. Приглашаем к сотрудничеству
всех заинтересованных специалистов, компании, ВУЗы.
Замечания, предложения и пожелания просьба направлять по адресу:
634050, Томск, пр-т Ленина, д.40
Институт системной интеграции и безопасности ТУСУР, Шелупанову А. А.
saa@udcs.ru
тел. 8 (3822) 413 426
129226 Москва, ул. Докукина, д. 16 корп. 1
ЗАО «Аладдин Р.Д.», генеральному директору Груздеву С. Л.
pr@aladdin.ni
тел. 8 (495) 223 0001
С уважением,
А. А. ШЕЛУПАНОВ,
Директор Института системной
интеграции и безопасности ТУСУР,
доктор технических наук, профессор
С. Л. ГРУЗДЕВ,
Генеральный директор компании Aladdin
ЧАСТЬ I
ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Глава 1
ОБЩИЕ СВЕДЕНИЯ ОБ АУТЕНТИФИКАЦИИ
1.1.	Основные понятия и определения
Процесс регистрации пользователя в любой системе состоит из трех взаимосвязанных
последовательно выполняемых процедур: идентификации, аутентификации и авторизации.
Идентификация — процедура распознавания субъекта по его идентификатору. В про-
цессе регистрации субъект предъявляет свой идентификатор системе, которая проверяет
его наличие в своей базе данных. Субъекты с известными системе идентификаторами
считаются легальными (законными), остальные относятся к нелегальным.
Аутентификация — процедура проверки подлинности субъекта, которая позволяет
достоверно убедиться в том, что субъект, предъявивший свой идентификатор, на самом
деле является именно тем субъектом, идентификатор которого он использует. Для этого
он должен подтвердить факт обладания некоторой информацией, которая может быть
доступна только ему одному (пароль, ключ и т. п.).
Авторизация — процедура предоставления субъекту определенных прав доступа к ресур-
сам системы после прохождения им процедуры аутентификации. Для каждого субъекта
в системе определяется набор прав, которые он может использовать при обращении к ее
ресурсам.
Для того чтобы обеспечить управление и контроль над данными процедурами, до-
полнительно используются процессы администрирования и аудита.
Администрирование — процесс управления доступом субъектов к ресурсам системы.
Данный процесс включает:
•	создание идентификатора субъекта (учетной записи пользователя) в системе;
•	управление данными субъекта, используемыми для его аутентификации (смена
пароля, издание сертификата и т. п.);
•	управление правами доступа субъекта к ресурсам системы.
Аудит — процесс контроля (мониторинга) доступа субъектов к ресурсам системы,
включающий протоколирование действий субъектов при их доступе к ресурсам системы
в целях обнаружения несанкционированных действий
Таким образом, в общем случае речь идет о пяти основных процедурах предоставле-
ния доступа к информации. При этом возможен различный подход к расстановке при-
оритетов при выполнении этих процедур.
1.2.	Роль и задачи аутентификации.
Место аутентификации в структуре
основных направлений защиты информации
Независимо от типа системы аутентификации в ней всегда присутствуют пять эле-
ментов.
Первый элемент — конкретный человек или процесс, который должен проходить
аутентификацию, — субъект доступа.
Второй элемент — опознавательный знак, идентификатор, который выделяет этого
человека или этот процесс среди других.
Третий элемент — отличительная характеристика (аутентификатор), подтверждаю-
щая принадлежность идентификатора субъекту доступа.
Глава 1. Общие сведения об аутентификации
Четвертый элемент — владелец системы (администратор), который несет ответствен-
ность за использование системы, и в разграничении авторизованных пользователей и ос-
тальных полагается на механизм аутентификации.
Пятый элемент — механизм аутентификации, который позволяет проверить присут-
ствие отличительной характеристики.
При успешном прохождении аутентификации субъекту доступа должны быть выданы
некоторые права (привилегии).
Для этого служит механизм управления доступом. С помощью этого же механизма
субъект доступа лишается прав (привилегий), если аутентификация была неуспешной.
Независимо от типа системы аутентификации в ней всегда
присутствуют пять элементов.
Примером аутентификации является вход физического лица в систему по паролю.
Физическое лицо — это человек, которому разрешено пользоваться компьютером. Обычно
в системе физическому лицу назначается символическое имя или идентификационный
код пользователя, который мы будем называть именем пользователя. Например, если поль-
зователь является авторизованным пользователем системы, то администратор присва-
ивает ему имя пользователя «Пользователь» Отличительной характеристикой пользова-
теля будет его секретный пароль, например, «qwerty». Данная процедура знакома, так как
в процессе регистрации компьютер выдает запрос на ввод имени пользователя и пароля.
Процесс включает в себя процедуру аутентификации, т.е. сравнение пароля, введенного
с клавиатуры, с паролем, установленным либо самим пользователем, либо администрато-
ром системы. Процедура завершается успешно, если оба пароля совпадают. В этом случае
механизм управления доступом разрешает пользователю продолжать работу на компью-
тере, и система использует имя пользователя каждый раз, когда ей требуется решение
службы управления доступом к защищенному ресурсу.
Рассматривая проблемы защиты компьютеров, следует всегда проводить различие
между тем, что мы хотим сделать, и тем, что мы в действительности делаем.
Первый вопрос «чего мы хотим» обычно озвучивают в виде целей защиты. Например,
целью шайки сорока разбойников была защита добычи от воровства. В этом они полагались
на механизм защиты — дверь пещеры. В вычислительной системе целью владельца системы
является предоставление доступа только авторизованным (законным) пользователям.
На практике же всегда существует зазор между тем, что мы хотим, и что происходит на
самом деле. Так, замок позволяет войти каждому, у кого есть экземпляр нужного ключа,
однако посторонние смогут войти тоже, если мы не предотвратим попадание к ним ключа.
Это может оказаться трудным делом, особенно если те, кого мы стремимся не впус-
тить с помощью замка, действительно хотят попасть внутрь. Более того, мы не всегда мо-
жем позволить себе поставить замки на все на свете. Часто имеется один большой замок
на входной двери, и нам приходится доверять тем, кого мы впустили внутрь.
В компьютерных системах аутентификация и управление доступом обычно реализу-
ются как две разные функции. Хотя иногда имеет смысл проводить различие между задвиж-
кой, удерживающей дверь закрытой, и замком, который управляет задвижкой, задвижка и
замок часто встроены в один механизм. В компьютерных системах процесс аутентифика-
ции подтверждает подлинность имени пользователя, а управление доступом осуществля-
ется путем сравнения имени пользователя с правилами доступа, связанными с конкретным
файлом или другим ресурсом. Если правила разрешают доступ пользователю с этим име-
нем, то он получает возможность использовать ресурс.
Н
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
В компьютерных системах аутентификация и управление
доступом обычно реализуются как две разные функции.
Процесс аутентификации подтверждает подлинность имени
пользователя. Управление доступом осуществляется путем
сравнения имени пользователя с правилами доступа,
связанными с конкретным файлом или другим ресурсом.
Сорок разбойников стремились к тому, чтобы в пещеру имели доступ только члены
шайки, но их механизм не мог предотвратить использование пароля другими людьми.
Эта проблема свойственна как процессу аутентификации, так и механизму управления
доступом.
Механизмы аутентификации несовершенны. Неавторизованные люди могут замаски-
роваться под легального пользователя.
Такая же проблема возникает и при управлении доступом: необходимо авторизовать
на пользование системой только определенных людей и именно для этого устанавлива-
ется система управления доступом. В идеальном мире техники со средствами защиты до-
ступ выдается по принципу «наименьшей привилегии», в соответствии с которым люди
имеют ровно столько разрешений и привилегий, сколько им требуется: не больше и не
меньше. Но в реальном мире система управления доступом не может дать людям ровно
столько привилегий, сколько им требуется: мы вынуждены либо предоставлять им
слишком много привилегий, либо отнимать некоторые из тех, которые действительно
необходимы. На практике мера доверия авторизованным пользователям обычно расши-
ряется, так что у них есть инструментарий для выполнения своей работы, даже если тех-
нически это позволяет им делать такие вещи, которые они делать не должны.
В идеале доступ к информации выдается по принципу
«наименьшей привилегии», в соответствии с которым люди
имеют ровно столько разрешений и привилегий, сколько им
требуется, но на практике мера доверия пользователям
обычно расширяется.
Управление доступом может быть очень сложным даже в отсутствие попытки добиться
выполнения принципа наименьших привилегий. Современные вычислительные систе-
мы обеспечивают широкий диапазон подходов и механизмов управления доступом. Ме-
ханизмы управления доступом даже в таких относительно простых системах, как Unix
или Windows, позволяют пользователям и администраторам устанавливать весьма слож-
ные наборы правил получения и лишения прав на использование различных ресурсов
компьютера. Однако многие организации придерживаются относительно простого под-
хода, связывая управление доступом и аутентификацию, так что прошедшие аутентифи-
кацию пользователи имеют всего лишь небольшое количество ограничений доступа.
Хотя проблема аутентификации пользователей сама по себе является серьезной пробле-
мой для компьютерных систем, пользователи не являются единственными субъектами,
которые подлежат аутентификации.
В настоящее время необходимо аутентифицировать
и системы действующие без вмешательства человека.
Глава 1 Общие сведения об аутентификации
В отличие от процесса аутентификации пользователя, здесь нет реального человека,
стоящего рядом с сервером, чтобы выполнить аутентификацию Мы же хотим иметь га-
рантию, что взаимодействуем с нужным оборудованием, которое находится под управ-
лением нужных людей или предприятия. Никто не захочет заказывать туфли через
компьютер, объявляющий себя «Shoes», если в конечном итоге он эти туфли не получит.
Когда мы выполняем аутентификацию субъекта, представляющегося сервером компа-
нии Shoes, мы должны быть уверены, что именно он управляется и контролируется
предприятием, принадлежащим компании Shoes. Обычно браузер предупреждает поль-
зователя, если он не может аутентифицировать сервер и оставляет решение по управле-
нию доступом за пользователем (Должен ли я оформлять заказ на туфли, с учетом того,
что этот сервер, похоже, не является сервером компании Shoes? Полагаю, нет). В неко-
тором смысле такой процесс переворачивает функцию автоматической аутентификации
с ног на голову, но лежащие в основе концепции по-прежнему те же.
1.3.	Факторы аутентификации
Для подтверждения свой подлинности субъект должен предоставить некоторую секрет-
ную информацию, которая должна быть доступна только ему одному. Он может предъ-
являть системе различные виды информации.
Фактор аутентификации — определенный вид информации, предоставляемый субъ-
ектом системе при его аутентификации.
1.3.1.	Описание факторов аутентификации
Выделяют три фактора аутентификации, используемые в различных комбинациях: на
основе знания чего-либо, обладания чем-либо на основе биометрических характеристик
(табл. 1.1).
Таблица 1.1
Факторы аутентификации
Фактор аутентификации	Классификация типов факторов аутентификации NCSC-TG-0171	Примеры факторов аутентификации
На основе знания чего-либо (1-й)	Туре 1: Authentication by Knowledge	•	Пароль или парольная фраза •	PIN-код (Personal Identification Number)
На основе обладания чем-либо (2-й)	Type 2: Authentication by Ownership	•	Физический ключ •	Карта с магнитной полосой •	OTP-токен, генерирующий од- норазовый пароль
На основе биометриче- ских характеристик (3-й)	Type 3: Authentication by Characteristic	* Отпечаток пальца •	Рисунок сетчатки глаза •	Голос
1 NCSC-TG-017 — документ «А Guide to Understanding Identification and Authentication in Trusted
Systems», опубликованный U.S. National Computer Security Center Руководство содержит комплект
рекомендуемых инструкции по процедурам идентификации и аутентификации.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Выделяют три фактора аутентификации, используемые
в различных комбинациях: на основе знания чего-либо,
обладания чем-либо, на основе биометрических
характеристик.
В некоторых компаниях организуется «строгий контроль» доступа в помещение, т, е.
в определенные помещения доступ предоставляется только ограниченному числу лиц.
Например, в серверную комнату может войти только администратор или в комнату фи-
нансового отдела компании могут иметь доступ только его сотрудники. Если при этом
установить для компьютеров, находящихся в этих помещениях, строго определенные
IP-адреса, то тогда появляется возможность более качественно выполнять аутентифи-
кацию при доступе сотрудников к ресурсам компьютерной сети. Им предоставляется до-
ступ к определенным действиям или данным только в том случае, если они это делают
в строго определенном помещении и соответственно с определенных компьютеров, имею-
щих определенные IP-адреса. В этом случае иногда говорят об использовании «четвер-
того» типа фактора аутентификации — на основе места проведения процедуры. Данный
фактор не считается дополнительным, так как его нельзя использовать отдельно от других
факторов для аутентификации субъекта. Например, нельзя обеспечить, чтобы только оп-
ределенный сотрудник работал, на строго определенном рабочем месте (компьютере).
В последнее время наметились тенденции интеграции логических средств аутентифи-
кации и средств контроля и управления доступом (СКУД). Смарт-карты, используемые
для аутентификации пользователя при доступе к ресурсам компьютерной системы, ин-
тегрируются с RFID (радиочастотной идентификацией). В этом случае появляется воз-
можность дополнительно использовать их для аутентификации человека при его доступе
в различные помещения. По-прежнему в этом случае речь будет идти об использовании
аутентификации «на основе обладания чем-либо». Это расширяет возможности использо-
вания смарт-карты, дает дополнительные удобства для пользователя, но не повышает ка-
чество аутентификации.
1.3.2.	Многофакторная аутентификация
Аутентификация может быть реализована с помощью одного из трех факторов аутен-
тификации. Например, в процессе аутентификации у пользователя может быть запрошен
пароль, либо потребуется представить отпечаток пальца.
Аутентификация, в процессе которой используется только один фактор аутентифи-
кации, называется однофакторной.
Аутентификация, в процессе которой используется несколько факторов аутентифи-
кации, называется многофакторной.
Например, в процессе аутентификации пользователь должен использовать смарт-карту
и дополнительно пароль (или PIN-код) Также используются понятия двухфакторной
и трехфакторной аутентификации при использовании комбинации двух и трех факторов
аутентификации соответственно.
В документе NCSC-TG-017 вводятся термины для различных видов многофакторной
аутентификации: типа 12, типа 23 и типа 123. Аутентификация типа 12 (произносится
как «аутентификация типа один два»), например использует два фактора аутентифика-
ции: первый (на основе знания чего-либо) и второй (на основе обладания чем-либо).
Глава 1 Общие сведения об аутентификации
В документе NCSC-TG-017 вводятся термины для различных
видов многофакторной аутентификации: типа 12, типа 23
и типа 123. Аутентификация типа 12 (произносится как
«аутентификация типа один два»), например, использует
два фактора аутентификации: первый (на основе знания
чего-либо) и второй (на основе обладания чем-либо).
Трехфакторная аутентификация использует комбинацию трех факторов аутентифи-
кации («на основе знания чего-либо», «на основе обладания чем-либо» и «на основе био-
метрии»). Эту аутентификацию называют аутентификация типа 123.
Если для аутентификации используется только один фактор аутентификации, она ока-
зывается уязвимой. При многофакторной аутентификации используется несколько (два
и более) факторов аутентификации, что обеспечивает большую безопасность.
При многофакторной аутентификации используется
несколько (два и более) факторов аутентификации,
что обеспечивает большую безопасность.
Наиболее распространено использование комбинации двух факторов при аутентифика-
ции пользователя в банкомате. Требуется одновременно использовать карту с магнитной
полосой и PIN-код.
Контрольные вопросы
1.	Назовите процедуры, выполняемые при регистрации пользователя в системе.
2.	Что такое аутентификация?
3.	Что такое идентификация?
4.	Что такое авторизация?
5.	Что такое аудит?
6.	Что такое администрирование?
7.	Перечислите элементы аутентификации.
8.	Для чего служит механизм управления доступом?
9.	Перечислите факторы аутентификации.
10.	Приведите примеры факторов аутентификации.
Глава 2
ПАРОЛЬНАЯ АУТЕНТИФИКАЦИЯ
2.1.	Аутентификация
с помощью запоминаемого пароля
Для проверки подлинности пользователей в информационных системах наиболее
широко используется аутентификация по секретной информации, которая неизвестна
непосвященным людям. При некомпьютерном использовании это может быть произ-
носимый голосом пароль или запоминаемая комбинация для замка. В компьютерных
системах — это пароль, вводимый с помощью клавиатуры.
Парольная аутентификация — аутентификация на основе обладания неким секрет-
ным знанием («на основе знания чего-либо»).
В системах различной степени защищенности используют постоянные, условно-пос-
тоянные и временные пароли.
Чем длиннее пароль, тем он более стойкий (сложнее поддается подбору и другим ти-
пам атак). Не меньшее значение имеют алфавит пароля, предельное количество попыток
его ввода, минимальное время, которое должно пройти между попытками, и другие па-
раметры механизма аутентификации.
К сожалению, длинные и сложные пароли обладают и недостатками:
•	их труднее запомнить;
•	их медленнее набирают — соответственно, их проще подсмотреть.
Современные парольные политики (см. раздел 2.3) задают минимальную длину па-
ролей (обычно 6—8 символов) и их рекомендуемую длину (10—12 символов). Макси-
мальная длина пароля, как правило, ограничена особенностями реализации механизма
аутентификации.
Чем длиннее и сложнее пароль, тем он более стойкий.
Компьютерная система для аутентификации вместо запроса пароля может исполь-
зовать другой метод («на основе знания чего-либо») — метод секретных запросов
и ответов.
Парольная аутентификация является наиболее простым
методом аутентификации с точки зрения реализации
2.2.	Методы парольной аутентификации
2.2.1.	Аутентификация на основе открытого пароля
Самым старым и простым методом парольной аутентификации является аутентифи-
кация на основе открытого пароля (рис. 2.1).
Гпава 2. Парольная аутентификация
Сервер аутентификации
Рис. 2.1. Аутентификация на основе открытого пароля
Пример аутентификации пользователя на основе открытого пароля:
1.	Пользователь вводит свои имя пользователя «Пользователь» и пароль «qwerty» на ра-
бочей станции.
2.	Имя пользователя и пароль передаются по сети в открытом виде.
3.	Сервер аутентификации находит учетную запись пользователя в базе данных аутен-
тификации и сравнивает введенные данные с ее содержимым.
В случае совпадения аутентификация признается успешной.
Простым методом парольной аутентификации является
аутентификация на основе открытого пароля
2.2.2.	Аутентификация на основе хэшированного пароля
В большинстве используемого в настоящее время программного обеспечения приме-
няются пароли не в чистом виде, а их хэш-значения, получаемые с помощью вычисления
криптографической хэш-функции.
Однонаправленные хэш-функции (далее — хэш-функции) — это функции, которые при-
нимают на входе строку переменной длины и преобразуют ее в выходную строку фиксиро-
ванной (обычно меньшей) длины, называемую значением хэш-функции (хэш-значением).
Пример прохождения пользователем процедуры аутентификации на основе хэширо-
ванного пароля (рис. 2.2.):
1.	Пользователь вводит свои имя «Пользователь», и пароль «qwerty» на рабочей станции.
2.	Рабочая станция вычисляет хэш-значение N4a#@JD от введенного пароля. Имя
пользователя и хэш-значение передаются по сети серверу аутентификации.
3.	Сервер аутентификаци сравнивает результат вычисления хэш-значения (N4a#@JD)
от введенного пользователем пароля с хэш-значением, хранящимся в учетной записи
пользователя (N4a#@JD).
4.	В случае совпадения аутентификация признается успешной
Основным свойством однонаправленных хэш-функций является невозможность вос-
становления исходной информации при обладании полученным из нее хэш-значением.
Восстановить открытое значение пароля из файла паролей, где он хранится в виде
хэш-значения, практически невозможно
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Сервер аутентификации
Рис. 2.2. Аутентификация на основе хэшированного пароля
Таким образом, если злоумышленник получит доступ к базе данных аутентификации,
это ему ничего не даст, так как. он не сможет восстановить пароль пользователя из хра-
нящегося в базе хэш-значения.
Однонаправленные хэш-функции не позволяют восстановить
исходную информацию. Поэтому, если посторонний человек
получит доступ к базе данных аутентификации, он не сможет
восстановить пароль из хранящегося в базе хэш-значения.
2.2.3.	Аутентификация на основе PIN-кода
PIN-код (Personal Identification Number) — это разновидность пароля, обычно исполь-
зуемого для аутентификации на локальном устройстве.
Несмотря на слова identification (идентификационное) и number (число), послужившие
основой для аббревиатуры, PIN-код редко служит в качестве идентификатора пользова-
теля, а символы, входящие в PIN-код, необязательно являются цифрами. В торговых авто-
матах и банкоматах применяется карта с магнитной полосой или смарт-карта. PIN-коды
часто используются с другими видами устройств аутентификации, например смарт-картами.
Обычно PIN-код торгового автомата или банкомата состоит из четырех цифр. Таким
образом, один из каждых 10000 клиентов имеют один и тот же PIN-код PIN-код похож
на простой «пароль».
Разница между PIN-кодом и паролем состоит в области и условиях их использования
Обычно для решений, в которых используется PIN-код, характерно следующее:
•	в локальном устройстве, в котором осуществляется аутентификация с помощью
PIN-кода, имеется интерфейс для пользователя, а не для программ. Никто не мо-
жет ввести PIN-код, не используя клавиатуру данного устройства.
•	PIN-код не передается по сети и не может быть перехвачен.
Гпава 2. Парольная аутентификация
Иногда термин PIN-код используют неправильно, применяя его для обозначения корот-
ких и простых паролей. Между этими терминами есть функциональная разница Аутен-
тификация по PIN-коду обычно используется в двухфакторной аутентификации типа 12.
Неправильно использовать термин PIN-код для обозначения
коротких и простых паролей Между этими терминами есть
функциональная разница.
2.3.	Парольные политики
В связи с тем что парольная аутентификация основана на запоминании некоторой
информации, многие пользователи информационных систем с парольной аутентифика-
цией выбирают в качестве секрета не произвольную и трудно угадываемую информацию,
а легко запоминаемые выражения или свои личные данные. Это могут быть имена, имена
членов семьи, названия компьютеров, даты рождения и другие очевидные комбинации.
Для повышения стойкости парольной защиты к перебору, во многих информацион-
ных системах реализуется проверка пароля на соответствие определенным требованиям
и блокирование выбора простых паролей.
Обычно термины «правила формата пароля», «опции автоматического блокирования»,
«политика смены паролей» не различаются и называются одним общим термином — па-
рольные политики. Парольные политики необходимы для повышения стойкости пароль-
ной защиты.
Парольные политики необходимы для повышения стойкости
парольной защиты.
2.4.	Недостатки методов аутентификации
с запоминаемым паролем
Методы аутентификации с запоминаемым паролем обладают многими недостатками —
пароль можно украсть, подсмотреть, подобрать (угадать) и т.д. Кроме того, довольно
легко ввести в заблуждение пользователей и администраторов системы, заставив их от-
крыть свой пароль, или же просто принудить их к открытию своего пароля.
Ниже в табл. 2.1 приведены известные атаки на системы, в которых используется
аутентификация на основе пароля, а также способы защиты от подобных атак.
Атаки на пароли и защита от них
Таблица 2.1
Описание атаки	Защита от данной атаки
Кража парольного файла	
Злоумышленник может прочи- тать пароли пользователя из парольного файла или резерв- ной копии	Хэширование пароля Каждая организация, разрабатывающая парольную аутентифи- кацию, должна снабжать свои приложения этой защитой.
19
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Прод(нжение табищы 2.1
Описание атаки	Защита от данной атаки
Атака со словарем	
Злоумышленник, перебирая пароли, производит в файле паролей или его копии поиск, используя слова из большого заранее подготовленного им словаря. Злоумышленник вы- числяет хэш-значение для каж- дого пробного пароля с помо- щью того же алгоритма, что и программа аутентификации.	Безопасность файла Доступ на чтение к файлу паролей должен быть предоставлен лишь небольшому числу доверенных пользователей. Хэшированные с шумами (помехами) пароли Генерирование хэш-значения различным способом для каждого пользователя намного усложняет атаку со словарем: злоумыш- ленник должен при подборе пароля каждого пользователя еще и подбирать способ хэширования пароля. Это достигается в сис- темах с помощью использования меняющегося значения, назы- ваемого шумом. Правила фор мата пароля Такие правила могут требовать, чтобы пароль содержал как ми- нимум одну цифру, как минимум один «специальный» символ, комбинации заглавных и строчных букв, и т.д.
Подбор пароля	
Исходя из знаний личных дан- ных пользователя, злоумышлен- ник пытается войти в систему с помощью имени пользователя и одного или нескольких паро- лей, которые он мог бы исполь- зовать (в том числе пароля, ус- тановленного по умолчанию).	Правила формата пароля Как для «атаки со словарем» выше. Изменение пароля, установленного по умолчанию Пароль, установленный по умолчанию, должен изменяться сразу после первого использования. По возможности следует вовсе исключить практику использования общеизвестных паролей. Автоматическое блокирование После нескольких безуспешных попыток входа система или бло- кирует учетную запись пользователя на некоторое время, или вовсе аннулирует ее.
Социотехника	
На пользователей' Злоумышленник представляет- ся администратором и вынуж- дает пользователя или открыть свой пароль, или сменить его на указанный им пароль. На администраторов: Злоумышленник представляет- ся законным пользователем и просит администратора заме- нить пароль для данного поль- зователя.	Поттика нераскрытая паролей В организации должны быть разработаны административные процедуры, запрещающие сообщать пароли другим лицам при любых обстоятельствах. Организация должна также извещать пользователей о том, что администратор никогда не обратится к пользователю с таким требованием. Политика смены паролей В организации должна действовать политика, согласно которой администратор меняет пароль пользователя только при условии, что он может установить его личность и передать новый пароль пользователю безопасным способом. Средства! самостоятельного управления паролями могут удовлетворять обоим критериям.
Принуждение	
Для того чтобы заставить поль- зователя открыть свой пароль, злоумышленник использует уг- розы или физическое принуж- дение.	Сигнал о принуждении В некоторых системах предусматривается возможность для поль- зователя подавать сигнал о том, что вход осуществляется под при- нуждением Обычно это реализуется с помощью специального пароля при входе в систему — пароль «вход под принуждением».
Гпава 2. Парольная аутентификация
Продолжение таблицы 2.	
Описание атаки	Защита от данной атаки
Подглядывание из-за плеча	
Расположенный рядом зло- умышленник или видеокамера следит за тем, как пользователь вводит свой пароль.	Неотображение пароля В большинстве систем пароли либо не отображаются на экране либо отображаются незначащими символами. В некоторых сис- темах отображается количество таких символов, отличное от введенного. Вопреки этом технологии, злоумышленник может видеть, на какие непосредственно клавиши нажимает пользова- тель. Также применяются технологии, которые дают пользова- телю строго ограниченное время для ввода пароля, тем самым заставляя его вводить пароль максимально быстро. Таким обра- зом, уменьшается вероятность его подсматривания, а также ус- ложняется его подбор злоумышленником.
Троянский конь	
Злоумышленник скрытно уста- навливает программное обеспе- чение, имитирующее обычный механизм аутентификации, но собирающее имена пользовате- лей и пароли при попытках пользователей войти в систему.	Особый режим интерактивного взаимодействия для механизма аутентификации В некоторых системах механизм аутентификации вызывается специально выделенным для этого сочетанием клавиш, недоступ- ным для других программ. В ОС Microsoft Windows в качестве та- кого сочетания клавиш используется [Ctrl]—[Alt]—[Delete] Антивирусное программное обеспечение Организация может обнаруживать программы типа «троянский конь» с помощью антивирусного программного обеспечения. Средства обеспечения контроля целостности файлов В организации может использоваться система обнаружения вторжений (intrusion detection system) для определения модифи- кации важных файлов, например, программы регистрации.
Аппаратный сниффер клавиатуры	
Злоумышленник скрыто уста- навливает в компьютер пользо- вателя аппаратное средство, со- бирающее информацию, кото- рую вводит пользователь при входе в систему, например, Keykeriki для беспроводных клавиатур, KeyCarbon, Key Devil или KeyGhost для проводных клавиатур.	Безопасность рабочих помещений Служба безопасности компании должна предоставлять доступ в помещения, в которых располагаются компоненты информа- ционной системы предприятия, только тем, кому он разрешен. Безопасность рабочих мест Служба безопасности компании должна обеспечить возможность контроля компонентов информационной системы предприятия для защиты от возможности установки в них незаконных аппарат ных средств. Контроль над соответствующими компонентами информационной системы предприятия возлагается на сотруд- ников компании, службу ИТ или службу безопасности компании
Трассировка памяти	
Злоумышленник использует программу для копирования пароля пользователя из буфера клавиатуры.	Защита памяти Некоторые ОС используют аппаратную защиту буферов клави- атуры от возможности ее трассировки.
Отслеживание нажатия клавиш программными средствами	
Для предотвращения использо- вания компьютеров не по на- значению некоторые организа- ции используют программное обеспечение, следящее за на- жатием клавиш. Злоумышлен- ник может для получения паро- лей просматривать журналы соответствующей программы.	Безопасность файлов Доступ на чтение к журналам должен быть предоставлен лишь узкому кругу доверенных пользователей (администраторов) с по мощью собственной или резидентной службы контроля доступа
ЧАСТЬ I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Окончание таблицы 2.1
Описание атаки	Защита от данной атаки
Регистрация излучения (перехват Ван Эка или фрикинг Ван Эка)	
Вим Ван Эк описал метод, ко- торым злоумышленник может перехватывать информацию с монитора путем регистрации его излучения. Вин Швартау высказал идею приемников Ван Эка, регистрирующих не только видеосигналы.	Неотображение пароля Как для «подглядывания из-за плеча» выше Безопасность излучений Модернизация устройств для уменьшения излучения с помощью использования современных микрокомпонент, специально раз- работанных с учетом необходимости уменьшения излучения. Проектирование помещении и планирование расположения оборудования в нем с учетом предотвращения возможности утечки информации через паразитное излучение оборудования.
Анализ сетевого трафика	
Злоумышленник анализирует сетевой трафик, передаваемый от клиента к серверу, для восстановления из него имен пользователей и их паролей.	Шифрование Весь сетевой трафик или только пароли могут шифроваться для передачи по сети (использование протокола SSL или VPN-соеди- нений). Одноразовые пароли Использование методов аутентификации, в которых «пароли» пользователей изменяются каждый раз при входе в систему.
Атака на «золотой пароль»	
Злоумышленник ищет пароли пользователя, применяемые им в различных системах — домаш- няя почта, игровые серверы и т. п. Есть большая вероят- ность того, что пользователь применяет один и тот же па- роль во всех системах.	Шифрование Как для «анализа сетевого трафика» (см. выше). Одноразовые пароли Как для «анализа сетевого трафика» (см. выше).
Атака методом воспроизведения	
Злоумышленнк записывает последовательность передавае- мых и получаемых субъектом доступа в процессе аутентифи- кации данных. Позднее он осу- ществляет попытку аутентифи- кации, передавая и получая записанные данные в той же последовательности.	Использование надежных протоколов аутентификации Надежные протоколы аутентификации предполагают использование при обмене данными с субьъектом доступа криптографически защищенных меток времени. Одноразовые пароли Как для «анализа сетевого трафика» (см. выше).
Контрольные вопросы
1.	Назовите методы парольной аутентификации.
2.	Приведите пример аутентификации пользователя на основе открытого пароля
3.	Что такое однонаправленные хэш-функции?
4.	Что такое PIN-код?
5.	Назовите области и условия использования PIN-кода
6.	Для чего необходимы парольные политики?
7.	Приведите примеры атак на системы, в которых используется аутентификация на
основе пароля.
Глава 3
АУТЕНТИФИКАЦИЯ С ПОМОЩЬЮ
БИОМЕТРИЧЕСКИХ ХАРАКТЕРИСТИК
Издавна люди узнавали друг друга по чертам лица, по голосу и другим приметам, харак-
терным только для определенного человека. Даже сейчас лицо является основным при-
знаком, по которому производят удостоверение личности человека, когда проверяют его
паспорт, водительские права, пропуск для доступа в организацию — все они содержат
фотографию человека, предъявляющего данные документы.
Современные технологии способны обеспечить удостоверение личности человека,
используя характерные только ему одному характеристики. Данные технологии основаны
на использовании знаний биометрики (или биометрии). Данная дисциплина занимается
статистическим анализом биологических наблюдений и явлений.
Биометрическая характеристика — это измеримая физиологическая или поведен-
ческая черта живого человека, которую можно использовать для установления личности
или проверки декларируемых личных данных.
Поскольку биометрический параметр уникален для данного человека, его можно исполь-
зовать для однофакторной аутентификации пользователя. Его можно использовать сов-
местно с паролем или с устройством аутентификации (например, таким, как смарт-карта)
для обеспечения двухфакторной аутентификации.
Биометрическая аутентификация обычно является одним из наиболее простых методов
для пользователей, которые должны проходить аутентификацию. В большинстве случаев
хорошо спроектированная биометрическая система просто снимает показания с человека
и правильно выполняет аутентификацию
3.1.	Биометрические характеристики
Биометрические характеристики делятся на физиологические и поведенческие.
Биометрические характеристики делятся
на физиологические и поведенческие.
Физиологические биометрические характеристики (физические биометрические ха-
рактеристики, статические биометрические характеристики) — биометрические харак-
теристики на основе данных, полученных путем измерения анатомических характеристик
человека.
К физиологическим биометрическим характеристикам можно отнести:
•	радужную оболочку глаза;
•	отпечаток пальца;
•	лицо;
•	кисть;
•	сетчатку.
Поведенческие биометрические характеристики (динамические биометрические харак-
теристики) — биометрические характеристики на основе данных, полученных путем из-
мерения действий человека.
23
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Характерной чертой для поведенческих параметров является их протяженность во
времени — измеряемое действие имеет начало, середину и конец.
К поведенческим биометрическим характеристикам можно отнести:
•	голос;
•	подпись;
•	ритм работы сердца.
Различия между поведенческими и физиологическими характеристиками являются
достаточно искусственными.
Поведенческие биометрические параметры зависят от физиологии: голос зависит от фор-
мы голосовых связок, подпись — от ловкости кисти и пальцев Некоторые физиологиче-
ские биометрические характеристики (например, лицо) могут изменяться в зависимости от
возраста или поведения человека Поведение человека (например, то, как он кладет палец
или смотрит в камеру) может влиять на эффективность работы системы аутентификации
Физиологические биометрические характеристики обычно неизменны в течение
жизни человека. Использование этих характеристик для аутентификации обычно восп-
ринимается как насильственное воздействие, часто как вмешательство в частную жизнь
человека. Поведенческие биометрические характеристики воспринимаются менее бо-
лезненно, но они менее стабильны, чем физиологические черты. Они могут изменяться
под влиянием стресса и болезни и в целом обеспечивают, по сравнению с физиологи-
ческими параметрами, менее качественную аутентификацию
Поведенческие биометрические параметры достаточно
зависимы от физиологии. Физиологические биометрические
характеристики обычно неизменны в течение жизни человека
и не могут быть изменены без существенного воздействия
на человека.
3.2.	Как работают биометрические системы
Хотя биометрические технологии различаются объектами и способами измерений,
все биометрические системы работают одинаково (рис. 3.1). Пользователь предоставляет
образец (sample) — опознаваемое необработанное изображение или запись физиологи-
ческой или поведенческой характеристики. С помощью регистрирующего устройства
(например, сканера или камеры), этот биометрический образец обрабатывается для по-
лучения информации об отличительных признаках, в результате чего получается конт-
рольный шаблон (или шаблон для проверки). Шаблоны представляют собой достаточно
большие числовые последовательности; сам образец невозможно восстановить из шаб-
лона. Контрольный шаблон и есть «пароль» пользователя.
Все биометрические системы работают одинаково:
пользователь предоставляет образец, с помощью
регистрирующего устройства этот биометрический образец
обрабатывается, в результате чего получается
контрольный шаблон.
24
Гпава 3 Аутентификация с помощью биометрических характеристик
Пользователь
Реагирующее |
устройство у
Сервер и база
данных аутентификации
Образец
0111
ртОТТ
юою
поог
OHIO
ртОТТр-
19ЯА91 Пользователь jooic
Пользователь,
эталонный
шаблон
JOTOTT]—
10010
11001
OHIO
11001
о
0101
Сравнение
Решение

Рис 3.1. Схема работы биометрических систем
| 98 % | <$/$ |> 90 %|
Степень Пороговая
совпадения величина
Контрольный шаблон сравнивается с эталонным шаблоном (или зарегистрированным
шаблоном), созданным на основе нескольких образцов определенной физиологической
или поведенческой характеристики пользователя, взятых при его регистрации в биомет-
рической системе. Поскольку эти два параметра (контрольный и эталонный шаблон)
полностью никогда не совпадают, то биометрической системе приходится принимать ре-
шение о том, «достаточно» ли они совпадают. Степень совпадения должна превышать
определенную настраиваемую пороговую величину.
Биометрические системы могут ошибаться, контрольный шаблон может быть ошибочно
признан:
•	соответствующим эталонному шаблону другого лица;
•	несоответствующим эталонному шаблону данного пользователя, несмотря на то что
этот пользователь зарегистрирован в биометрической системе.
Точность биометрической системы измеряется двумя параметрами:
•	коэффициентом неверных совпадении (FMR), также известным под названием
ошибка типа I или вероятность южного допуска (FARy,
•	коэффициентом неверных несовпадений (FNMR), также известным под названием
ошибка типа II или вероятность ложного отказа в доступе (FRR).
Биометрические системы могут ошибаться, их точность
измеряется коэффициентом неверных совпадений (FMR)
и коэффициентом неверных несовпадений (FNMR)
Оба коэффициента отражают способность системы предоставлять ограниченный вход
авторизованным пользователям Системы с низким значением FMR более защищены,
а системы с низким значением FNMR более просты в использовании. В общем случае для
25
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
данных систем при задании пороговой величины действует правило: чем ниже FMR, тем
выше FNMR. Таким образом, часто безопасность и простота использования конкурируют
между собой.
Простота регистрации и качество «шаблонов» — важные факторы общей эффективности
биометрической системы. Некачественный «шаблон» может осложнить работу пользова-
теля, вынуждая его прибегнуть к повторной регистрации в биометрической системе.
3.3.	Аутентификация и биометрическое распознавание
В режиме аутентификации биометрическая система проверяет заявленную личность,
сверяя контрольный шаблон, сгенерированный из образца, с эталонным шаблоном (1:1 или
сравнение один с одним). Для аутентификации необходимо, чтобы идентификатор личности
был заявлен, например, вводом имени пользователя с клавиатуры, после чего контроль-
ный шаблон данного лица сравнивается с эталонным шаблоном.
Некоторые системы аутентификации осуществляют очень ограниченный поиск среди
многочисленного числа зарегистрированных записей. Например, пользователь с тремя
эталонными шаблонами отпечатков пальцев может иметь возможность предоставить для
проверки любой из трех пальцев, и система предпримет поиск совпадения 1:1 среди эта-
лонных шаблонов данного пользователя.
Биометрическое распознавание — это процесс определения личности пользователя,
состоящий из одного шага. В режиме распознавания система определяет личность поль-
зователя, осуществляя сравнение контрольного шаблона со многими биометрическими
эталонными шаблонами (7:7V или сравнение один ко многим). В случае нахождения совпа-
дения одновременно определяется и удостоверяется личность пользователя.
Биометрическая идентификация широко распространена и нашла применение в таких
областях, как судебная медицина и деятельность правоохранительных органов.
В режиме аутентификации биометрическая система
проверяет заявленную личность, сверяя контрольный
шаблон, сгенерированный из образца, с эталонным
шаблоном. Для аутентификации необходимо, чтобы
идентификатор личности был заявлен.
В биометрических системах, работающих только в режиме аутентификации, возможно
использование негативной идентификации в процессе регистрации пользователя в био-
метрической системе, когда один контрольный шаблон сравнивается со многими, чтобы
проверить, что данное лицо не зарегистрировано в базе данных, и таким образом, пред-
отвратить двойную регистрацию в системе. Этот режим часто используется в крупных
программах по предоставлению социальных пособий, в которых пользователи пытаются
регистрироваться несколько раз для получения пособий под разными именами.
Существует нечто среднее между аутентификацией и распознаванием — «сравнение один
к нескольким» (l:few). Этот тип приложений предполагает идентификацию пользователя
по очень маленькой базе зарегистрированных пользователей. Четкого количественного
разграничения между системами 1:N и l:few нет, но любую систему, в которой поиск
осуществляется среди более чем 500 записей, следует относить к типу 1:N.
26
Глава 3 Аутентификация с помощью биометрических характеристик
3.4.	Реализация биометрических систем
3.4.1.	Физиологические биометрические характеристики
Основные физиологические биометрические характеристики, а также виды их реали-
зации приведены в табл. 3.1.
Таб шца 3.1
Реализация физиологических биометрических характеристик
Биометрическая характеристика	Регистрирующее устройство	Образец	Исследуемые черты
Радужная оболочка глаза	Видеокамера, способная работать в инфракрасном диапазоне, камера для ПК	Черно-белое изображе- ние радужной оболоч- ки глаза	Полоски и бороздки в ра- дужной оболочке глаза
Отпечаток пальца	Периферийное устройство настольного компьютера, карта стандарта PC card, мышь, микросхема или считыватель, встроенный в клавиатуру	Изображение отпечат- ка пальцев (оптическое, на кремниевом фото- приемнике, ультразву- ковое, или бесконтакт- ное)	Расположение и направ- ление гребешковых вы- ступов и разветвлений на отпечатке пальцев, мел- кие детали
Лицо	Видеокамера, камера для ПК, цифровой фотоаппа- рат	Изображение лица (оп- тическое, двумерное (2О-фото) или трех- мерное (ЗИ-фото))	Форма черепа, относи- тельное расположение и форма носа, расположе- ние скул
Кисть	Настенное устройство	Трехмерное изображе- ние верха и боков кисти	Высота и ширина костей и суставов кисти и пальцев
Сетчатка	Настольное или настенное устройство	Изображение сетчатки	Расположение кровенос- ных сосудов на сетчатке
В стадии разработки находятся новые биометрические технологии, связанные с дру-
гими физиологическими характеристиками:
•	Сравнение ДНК — это самая совершенная биометрическая технология, дающая
прямое доказательство идентичности личности (кроме однояйцевых близнецов,
у которых одинаковый генотип). Этот метод иногда называется дактилоскопией
ДНК, что сбивает с толку и вводит в заблуждение, поскольку отпечатки пальцев
не «проникают до уровня генома». Биометрические системы, основанные на срав-
нении ДНК, могут быть введены в действие лишь через много лет.
•	Отпечаток ладони — в этой системе используется расположение линий на ладони че-
ловека, также, как в биометрической технологии, использующей отпечатки пальцев.
•	Сосудистые рисунки — расположение вен в различных частях тела человека, вклю-
чая запястье и тыльную сторону ладони, а также лицо.
•	Сигналы, вырабатываемые сердцем (мозгом, легкими), — в этой системе пользова-
тель прикасается к датчику «биодинамической подписи» и остается с ним в контакте
некоторое время (в зависимости от точности измерения — до 8 с). За это время
датчик идентифицирует индивидуальные параметры человека.
В стадии разработки находятся новые биометрические
технологии: сравнение ДНК, отпечаток ладони, сосудистые
рисунки, сигналы, вырабатываемые сердцем (мозгом, легкими).
27
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
3.4.2.	Поведенческие биометрические характеристики
Основные физиологические биометрические характеристики, а также виды их ре-
ализации приведены в таблице 3.2.
Реализация поведенческих биометрических характеристик
Табпща 3.2
Биометрическ ая характеристика	Регистрирующее устройство	Образец	Исследуемые черты
Голос	Микрофон телефон	Запись голоса	Частота, модуляция и продолжитель- ность голосового образа
Подпись	Планшет для подписи, перо для ввода дан- ных	Изображение подпи- си и показания соот- ветствующих дина- мических измерении	Скорость, порядок линий, давление и внешний вид подписи
Динамика нажатия клавиш	Клавиатура	Ритм машинописи	Время задержки (промежуток времени в течение которого пользователь удер- живает конкретную клавишу) время «полета» (промежуток времени, который требуется пользователю для перехода с одной клавиши на другую)
3.5.	Недостатки аутентификации с помощью
биометрических характеристик. Возможные атаки
В табл. 3.3 приведены известные методы атак на системы, использующие аутентифи-
кацию с помощью биометрических характеристик, а также способы защиты от подобных
атак.
К недостаткам аутентификации с помощью биометричесских характеристик можно
отнести следующие:
Вмешательство в частную жизнь. Пользователям-клиентам в большей степени, чем
пользователям-сотрудникам организаций, небезразличен факт хранения и распростра-
нения их биометрических данных. Если в организации устроено централизованное хра-
нилище биометрических параметров, пользователи, не имея возможности контролиро-
вать распространение этих данных, опасаются:
•	злоупотреблений (например, незаконного обмена с другими организациями):
•	нецелевого использования («подмены функции»).
Личные, культурные и религиозные аспекты. Дактилоскопические системы вызывают
неприятие у пользователей которые считают, что их использование бросает на них тень
преступного свойства, поскольку отпечатки пальцев, как известно, применяются в кри-
миналистике.
Возникают также вопросы гигиены (будет ли прибор, регистрирующий геометрию
руки, обрабатываться антисептическим раствором после каждого использования?) и
травмоопасности (например, в системах сканирования сетчатки, в которых свет направ-
ляется в глаз), а также осознание того факта, что пользователи подвергаются риску при-
чинения вреда со стороны преступников — от копирования или использования объектов
биометрии под физическим принуждением до потери кисти или пальца.
28
Глава 3. Аутентификация с помощью биометрических характеристик
Таблица 3.3
Атаки на биометрические системы и гащита от них
Описание атаки	Защита от данной атаки
Подделка отличительной черты	
Злоумышленник изготавливает ко- пию физической отличительном черты законного пользователя и предъявляет эту копию биометри- ческому датчику.	Снятие показателей с высоким уровнем детализации При изготовлении эталонного шаблона с иконного пользо- вателя снимают дополнительные биометрические показате- ш, так что простая копия физической отличительном черты законного пользователя не будет отражать все ее параметры.
Воспроизведение поведения пользователя	
Злоумышленник записывает пове- денческую отличительную черту пользователя и воспроизводит на биометрическом датчике.	Изменяемое поведение При каждой попытке аутентификации система требует от пользователя различного проявления его поведенческой биометрической характеристики, так что просто ее запись и воспроизведение не будут приниматься.
Перехват биометрических показателей	
Злоумышленник перехватывает биометрические показатели закон- ного пользователя в момент их пе- редачи между устройствами.	Шифрование биометрических данных Биометрические данные шифруются сразу после их получения от пользователя устройством считывания, их передача между устройствами осуществляется только в шифрованном виде.
Воспроизведение биометрической «подписи*	
Злоумышленник воспроизводит по- казатель биометрического датчика — «подпись», которая далее обраба- тывается системой так, словно бы- ла получена от реального человека.	Аутентификация биометрической «подписи» Меры аутентификации принимаются в отношении биомет- рических данных, чем гарантируется их поступление только из заслуживающих доверия источников. Использование ЭЦП для обеспечения целостности биометрической «подписи».
Непригодность для всех пользователей. Oi 1 до 3% процентов людей не имеют частей
тела, необходимых для внесения в систему хотя бы одного биометрического параметра.
Немые пользователи не могут использовать голосовые системы. Пользователи, у кото-
рых по причине врожденной болезни, хирургического вмешательства или ранения не
хватает пальцев или кистей, не могут использовать системы, регистрирующие отпечатки
пальцев и параметры кисти.
Контрольные вопросы
1.	Перечистите физиологические биометрические характеристики.
2.	Назовите поведенческие биометрические характеристики.
3.	Опишите принцип работы биометрических систем
4.	Назовите параметры, определяющие точность биометрических систем.
5.	Приведите примеры атак на системы, использующие аутентификацию с помощью
биометрических характеристик, и способы зашиты от подобных атак.
29
Глава 4
АУТЕНТИФИКАЦИЯ
С ПОМОЩЬЮ ОДНОРАЗОВЫХ ПАРОЛЕЙ
В основе всех методов аутентификации на основе пароля лежит предположение
о том, что только законный пользователь может пройти проверку, так как только он зна-
ет свой пароль.
Заметим, что используемый при этом идентификатор пользователя злоумышленник
может легко узнать. Особенно, если в качестве идентификатора пользователя использу-
ется не назначаемый пользователю идентификационный номер — ID (случайная строка
символов, состоящая из букв и цифр), а так называемое «имя пользователя».
Так как обычно «имя пользователя» — это различные варианты комбинации имени
и фамилии пользователя, то определить его не составляет большого труда. Соответствен-
но, если злоумышленнику удастся узнать и пароль пользователя, то ему будет легко
представиться этим пользователем. Насколько бы ни был пароль засекреченным, узнать
его иногда не слишком трудно. Злоумышленник может сделать это, используя различ-
ные способы атак (см. выше раздел «Недостатки методов аутентификации с запоминае-
мым паролем» в гл. 2)
Для каждой из этих атак есть методы защиты. Но большинство из этих вариантов за-
щиты обладают различными недостатками. Некоторые виды защиты достаточно дороги
(например, борьба с побочным электромагнитным излучением и наводками оборудова-
ния), другие создают неудобства для пользователей (правила формирования пароля, ис-
пользование длинного пароля). Один из вариантов защиты от различных атак на аутен-
тификацию на основе пароля — переход на аутентификацию с помощью одноразовых
паролей.
Применение схем одноразовых паролей стало заметным шагом вперед по сравнению
с использованием фиксированных паролей. Выше мы говорили, что злоумышленник,
узнавший фиксированный пароль, может повторно его использовать с целью выдачи се-
бя за легального пользователя. Частным решением этой проблемы как раз и является
применение одноразовых паролей: каждый пароль в данном случае используется только
один раз.
Одним из вариантов защиты от различных атак на
аутентификацию по паролю является аутентификация
с использованием одноразовых паролей.
Одноразовые пароли (OTP, One-Time Passwords) — динамическая аутентификацион-
ная информация, генерируемая для единичного использования с помощью аутентифи-
кационных устройств (программных или аппаратных).
Одноразовый пароль (ОТР) неуязвим для атаки методом анализа сетевого трафика,
что является значительным преимуществом перед запоминаемыми паролями Несмотря
на то, что злоумышленник может перехватить пароль методом анализа сетевого трафика,
поскольку пароль действителен лишь один раз и в течение ограниченного промежутка
времени, у злоумышленника в лучшем случае есть весьма ограниченная возможность
представиться пользователем с помощью перехваченной информации.
30
Гпава 4. Аутентификация с помощью одноразовых паролей
Одноразовый пароль действителен один раз в течение
ограниченного времени и при перехвате такого пароля
злоумышленник имеет ограниченную возможность
представиться пользователем.
В качестве возможных устройств для генерации одноразовых паролей обычно ис-
пользуются ОТР-токены.
ОТР-токен — мобильное персональное устройство, которое принадлежит определенно-
му пользователю и генерирует одноразовые пароли, используемые для аутентификации
данного пользователя.
Таким образом, аутентификация с помощью одноразовых паролей, по сравнению
с аутентификацией на основе пароля, является аутентификацией с помощью другого
фактора аутентификации — аутентификацией «на основе обладания чем-либо».
Другим важным преимуществом применения аутентификационных устройств явля-
ется то, что многие из них требуют от пользователя введения PIN-кода:
•	для активации ОТР-токена;
•	в качестве дополнительной информации, используемой при генерации ОТР;
•	для предъявления серверу аутентификации вместе с ОТР.
Если дополнительно применяется еще и PIN-код, в методе аутентификации исполь-
зуются два фактора аутентификации, т. е. данный метод относится к двухфакторнои
аутентификации.
Простейшей схемой применения одноразовых паролей служит разделяемый список.
В этом случае пользователь и проверяющий применяют последовательность секретных
паролей, где каждый пароль используется только один раз
Естественно данный список заранее распределяется между сторонами аутентифика-
ционного обмена.
Такая схема применяется в настоящее время в некоторых системах «Интернет-банк».
Модификацией этого метода является таблица вопросов и ответов, которая содержит
вопросы и ответы, используемые сторонами для проведения аутентификации, причем
каждая пара используется только один раз. Существенным недостатком этой схемы яв-
ляется необходимость предварительного распределения аутентифицирующей информа-
ции. После того как выданные пароли закончатся, пользователю необходимо получить
новый список. Такое решение, во-первых, не удовлетворяет современным представле-
ниям об информационной безопасности, поскольку злоумышленник может украсть или
скопировать список паролей пользователя. Во-вторых, постоянно получать новые спи-
ски паролей вряд ли кому-нибудь понравится.
Вместе с тем, в настоящее время разработано несколько методов реализации техно-
логии одноразовых паролей, исключающих указанные недостатки. В их основу легли
различные криптографические алгоритмы.
Простейшей схемой применения одноразовых паролей
служит разделяемый список Существенным недостатком
этой схемы является необходимость предварительного
распределения аутентифицирующей информации.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
4.1.	Аппаратно-программные ОТР-токены
ОТР-токены имеют небольшой размер и выпускаются в виде:
•	карманного калькулятора;
•	брелока;
•	смарт-карты;
•	устройства, комбинированного с USB-ключом;
•	специального программного обеспечения для карманных компьютеров, смартфо-
нов, настольных компьютеров.
4.2.	Как работают ОТР-токены
Для генерации одноразовых паролей ОТР-токены используют хэш-функции или
криптографические алгоритмы:
•	симметричная криптография (криптография с одним ключом) — в этом случае поль-
зователь и сервер аутентификации используют один и тот же секретный ключ;
•	асимметричная криптография (криптография с открытым ключом) — в этом слу-
чае в устройстве хранится закрытый ключ, а сервер аутентификации использует
соответствующий открытый ключ.
Для генерации одноразовых паролей ОТР-токены используют
хэш-функции или криптографические алгоритмы.
Существуют различные комбинации использования данных криптографических ал-
горитмов в реализациях ОТР-токенов.
Соответственно механизмы аутентификации, используемые OTP-токенами. можно
разделить на две группы:
•	аутентификация с одним секретным ключом,
•	аутентификация с открытым ключом
4.3.	Методы аутентификации с помощью ОТР-токенов
Обычно в OTP-токенах применяется симметричная криптография Устройство каждо-
го пользователя содержит уникальный персональный секретный ключ, используемый для
шифрования некоторых данных (в зависимости от реализации метода) для генерации
ОТР. Этот же ключ хранится на сервере аутентификации, который выполняет аутентифи-
кацию данного пользователя. Сервер шифрует те же данные и сравнивает два результата
шифрования: полученный им и присланный от клиента. Если результаты совпадают, то
пользователь успешно проходит аутентификацию.
ОТР-токены, использующие симметричную криптографию, могут работать в асинхрон-
ном или синхронном режиме. Соответственно методы, используемые ОТР-токенами.
можно разделить на две группы, работающие:
•	в асинхронном режиме («запрос-ответ»);
•	в синхронном режиме («только ответ», «синхронизация по времени», «синхрони-
зация по событию»).
32
Гпава 4 Аутентификация с помощью одноразовых паролей
4.3.1.	Метод «запрос—ответ» (Challenge—response)
В методе «запрос—ответ» ОТР является ответом пользователя на случайный запрос
от сервера аутентификации (рис. 4.1).
С
 -	хэш-функция	данных а^ификации
Рис. 4.1. Метод •Запрос—ответ»
Пример аутентификации пользователя при использовании OTP-токеном метода «за-
прос-ответ»:
1.	Пользователь вводит свое имя пользователя на рабочей станции
2.	Имя пользователя передается по сети в открытом виде.
3.	Сервер аутентификации генерирует случайный запрос («31415926»)
4.	Запрос передается по сети в открытом виде.
5.	Пользователь вводит запрос в свой ОТР-токен.
6.	ОТР-токен шифрует запрос с помощью секретного ключа пользователя («cft6yhnj»)5
в результате получается ответ («27182818»), который отображается на экране ОТР-токена.
7.	Пользователь вводит этот ответ на рабочей станции.
8.	Ответ передается по сети в открытом виде.
9.	Аутентификационный сервер находит запись пользователя в аутентификационной
базе данных и с помощью хранимого им секретного ключа пользователя зашифровывает
тот же запрос.
10.	Сервер сравнивает представленный ответ от пользователя («27182818») с вычис-
ленным им самим ответом («27182818»).
11.	При совпадении значений аутентификация считается успешной.
4.3.2.	Метод «только ответ» (Response only)
В методе «только ответ» аутентификационное устройство и сервер аутентификации
генерируют «скрытый» запрос, используя значения предыдущего запроса Для начальной
инициализации данного процесса используется уникальное случайное начальное значе-
ние, генерируемое при инициализации ОТР-токена.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Хэш-функция
Сервер и база
данных аутентификации
Пример аутентификации пользователя при использовании OTP-токеном метода
«только ответ» (рис. 4.2):
1.	Пользователь активизирует свой OTP-токен, который вычисляет и отображает от-
вет на «скрытый» запрос.
2.	Пользователь вводит свое «имя пользователя» и этот ответ («66260689») на рабочей
станции.
3.	Имя пользователя и ответ («66260689») передаются по сети в открытом виде
4.	Сервер находит запись пользователя, генерирует такой же скрытый запрос и шиф-
рует его с помощью секретного ключа пользователя, получая ответ на свои запрос
5.	Сервер сравнивает представленный ответ от пользователя («66260689») с вычис-
ленным им самим ответом («66260689»).
6.	При совпадении значений аутентификация считается успешной.
4.3.3.	Метод «Синхронизация по времени» (Time synchronous)
В режиме «синхронизация по времени» аутентификационное устройство и аутентифи-
кационный сервер генерируют ОТР на основе значения внутренних часов. OTP-токен может
использовать не стандартные интервалы времени, измеряемые в минутах, а специальные
интервалы времени обычно равные 30 с.
Пример аутентификации пользователя при использовании OTP-токеном метода «син-
хронизация по времени» (рис. 4.3):
1	Пользователь активизирует свой OTP-токен, который генерирует ОТР («96823030»),
зашифровывая показания часов с помощью своего секретного ключа.
Гпава 4 Аутентификация с помощью одноразовых паролей
Хэш-функния
Рабочая станция и ОТР-токен
Сервер и база
данных аутентификации
Рис. 4.3. Метод «Синхронизация по времени*
2.	Пользователь вводит свое «имя пользователя» и этот ОТР на рабочей станции.
3.	Имя пользователя и ОТР передаются по сети в открытом виде.
4.	Аутентификационный сервер находит запись пользователя и шифрует показание
своих часов с помощью хранимого им секретного ключа пользователя, получая в ре-
зультате ОТР.
5.	Сервер сравнивает ОТР, представленный пользователем, и ОТР, вычисленный им
самим.
6.	При совпадении значений аутентификация считается успешной.
4.3.4. Метод «синхронизация по событию» (Event synchronous)
В режиме «синхронизация по событию» ОТР-токен и сервер аутентификации ведут
количественный учет прохождения аутентификации данным пользователем, и на основе
этого числа генерируют ОТР.
Пример аутентификации пользователя при использовании OTP-токеном метода
«синхронизация по событию» (рис. 4.4):
1.	Пользователь активизирует свой ОТР-токен, который генерирует ОТР
(«59252459»). зашифровывая число раз прохождения аутентификации данного пользо-
вателя с помощью своего секретного ключа.
2.	Пользователь вводит свое «имя пользователя» и этот ОТР на рабочей станции.
3.	Имя пользователя и ОТР передаются по сети в открытом виде
4.	Аутентификационный сервер находит запись пользователя и шифрует значение
числа раз прохождения аутентификации данного пользователя с помощью хранимого им
секретного ключа пользователя, получая в результате ОТР.
5.	Сервер сравнивает ОТР, представленный пользователем, и ОТР, вычисленный им
самим.
6.	При совпадении значений аутентификация считается успешной
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Сервер и база
данных аутентификации
Некоторые OTP-токены могут использовать несколько различных методов реализа-
ции аутентификации с помощью ОТР. Наиболее часто комбинируются методы «синх-
ронизация по времени» и «синхронизация по событию»
4.4.	Сравнение методов ОТР-аутентификации
Метод «запрос—ответ», работающий в асинхронном режиме, предполагает большее
количество шагов, совершаемых пользователем, чем любой из синхронных режимов.
Потенциальная проблема всех методов реализации аутентификации с помощью ОТР,
работающих в синхронном режиме, — возможность рассинхронизации ОТР-токена и
сервера, например:
•	в режимах «только ответ» или «синхронизации по событию» сбой при аутентифи-
кации может привести к «отставанию» сервера от аутентификационного устройства;
•	в режиме «синхронизации по времени» часы аутентификационного устройства
могут уйти вперед или отстать от часов сервера.
Потенциальная проблема всех методов реализации
аутентификации с помощью ОТР, работающих в синхронном
режиме, — возможность рассинхронизации ОТР-токена
и сервера.
При аутентификации с попощью OTP-токенов, как правило, предусматривается ва-
риант решения проблемы рассинхронизации: сервер генерирует несколько возможных
вариантов ОТР — «ответов» от пользователя за некоторый короткий промежуток вре-
мени (для нескольких событий или единиц измерения времени).
36
Гпава 4. Аутентификация с помощью одноразовых паролей
4.5.	Системы одноразовых паролей
4.5.1.	Система S/Key
Система S/Key— система одноразовых паролей, разработанная в Беллкоре (Bell Com-
munication Research Labs Bellcore Labs) в начале 1990-х гг в качестве метода регистрации
для UNIX-систем.
Техническая концепция была впервые предложена Лесли Лэмпортом (Leslie Lamport) и
опубликована в 1981 г. Основное отличие подхода Лэмпорта от других методик на основе
принципа «запрос—ответ» состояло в том, что не было базы данных секретных ключей,
поэтому взломщики не могли поставить под угрозу работу системы, украв эту базу данных.
В схеме Лэмпорта (рис. 4.5) используется последовательность значений односторонних
хэш-функций, вычисляемых из базового секрета. Как и в случае традиционной пароль-
ной аутентификации в UNIX-системах, в схеме Лэмпорта использован тот факт, что вы-
числение хэшированного значения пароля не представляет сложности, а вот обратное
получение пароля по значению хэша невозможно. В схеме Лэмпорта используется по-
следовательность значений хэш-функции, каждое из которых вычисляется из предыдуще-
го члена последовательности. Сервер хранит последнее значение хэш-функции в после-
довательности.
Схему Лэмпорта для трех актов аутентификации можно представить в виде последо-
вательности следующих шагов:
1.	Четыре раза последовательно’вычисляется значение хэш-функции базового секрета
пользователя. Конечный результат этих вычислений сохраняется в базе данных аутен-
Хэш-функция
Рис. 4.5. Схема Лэмпорта
---| d215F54f	|—
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
тификации, а промежуточные выдаются пользователю либо повторно вычисляются им
при каждом акте аутентификации.
2.	Пользователь в качестве одноразового пароля предоставляет предпоследнее в по-
следовательности значение хэш-функции.
3.	Сервер принимает одноразовый пароль, вычисляет значение хэш-функции и срав-
нивает со значением хэш-функции, хранящимся в базе данных аутентификации. Эти
значения должны совпасть.
4.	При совпадении (успешной аутентификации) сервер заменяет значение хэш-функции
в учетной записи пользователя (четвертое значение хэш-функции) значением пароля, толь-
ко что принятым от пользователя {третьим значением хэш-функции). При следующем вхо-
де пользователя в систему он должен предоставить второе значение хэш-функции, а при
последнем входе — первое значение.
Схема Лэмпорта реализована в системе S/Key. В этой методике используются синхрон-
ные одноразовые пароли. В качестве одноразового пароля пользователь должен предос-
тавлять предпоследнее значение хэш-функции. Это требует точного учета использован-
ных паролей, а пользователи не очень сильны в подобной бухгалтерии. Но, как правило,
S/Кеу-серверы подсказывают пользователю порядковый номер ожидаемого значения
хэш-функции. Таким образом, в системе S/Key используется как бы «запрос—ответ», хотя
в действительности эта информация опционна и предоставляется только для удобства
пользователя.
В системе S/Key функция хэширования также включает в себя и случайное число, на-
зываемое «примесью», которое объединяется с базовым секретом при генерации значении
хэш-функции. «Примесь» не позволяет системе S/Key генерировать одинаковые последо-
вательности значений хэш-функции, если пользователь попытается повторно восполь-
зоваться базовым секретом или использовать один и тот же базовый секрет для разных
компьютеров. Хотя на рисунке показано, что в файле паролей хранится только значение
хэш-функции, система S/Key хранит также значение «примеси» и порядковый номер зна-
чения хэш-функции. Когда S/Кеу-сервер выдает запрос, содержащий текущий поряд-
ковый номер хэш-функции пользователя, он одновременно выводит и значение «при-
меси», используемое для генерации значений хэш-функции.
Как правило, пользователи системы S/Key используют для генерации одноразовых
паролей программно реализованные ОТР-токены. Чтобы воспользоваться программным
OTP-токеном для данной системы, пользователь вводит базовый секрет (пароль), по-
рядковый номер и значение «примеси». ОТР-токен итеративно использует функцию хэ-
ширования для генерации правильного значения в последовательности и затем выводит
результирующее значение хэш-функции. После этого пользователь копирует значение
хэш-функции в ожидающее окно запроса пароля
Как правило, пользователи системы S/Key используют для
генерации одноразовых паролей программно реализованные
ОТР-токены.
Программные реализации устройства аутентификации существуют для операционных
систем типа UNIX, Microsoft и Macintosh. Программное устройство аутентификации
обычно само обнаруживает запрос системы S/Key, так что оно способно автоматически
вычислять правильное значение одноразового пароля. Когда это возможно, устройство
аутентификации поддерживает функцию вырезания и вставки через буфер, что позволяет
избегать ошибок набора при копировании запроса или ответа. Кроме того, для пользо-
38
Гпава 4. Аутентификация с помощью одноразовых паролей
вателей, которые не имеют возможности запускать на выполнение программу устройства
аутентификации, имеется утилита, распечатывающая значения хэш-функции на бумаге
Хотя аппаратная реализация устройства аутентификации для системы S/Key технически
несложна, на данный момент промышленных моделей не существует.
До тех пор пока сервер хранит только последнее значение хэш-функции из последо-
вательности, а пользователь предоставляет в качестве пароля предпоследнее значение
\зш-функнии, злоумышленнику непросто получить действующее значение пароля. Он
не может извлечь значение хэш-функции из файла паролей и произвести обратные вы-
числения предыдущего значения хэш-функции из последовательности или исходного
значения базового секрета.
Аппаратная реализация устройства аутентификации для
системы S Key технически несложна, на данный момент
промышленных не существует.
4.5.2.	Гоуппа OATH и система НОТР
Система НОТР (HMAC-based One-Time Password System) была разработана в 2005 г.
в рамках инициативы группы открытой аутентификации OATH (Open AuTHentification)
и описана в документе RFC 4226. Данная система основана на концепции ОТР-аутен-
тификации с синхронизацией по событию. Для генерации одноразового пароля исполь-
зуется алгоритм HMAC (Hashed Message Authentication Code).
Система НОТР основана на концепции ОТР-аутентификации
с синхронизацией по событию.
Этот алгоритм публичен и доступен для изучения любыми специалистами. Он обеспе-
чивает возможность аутентификации в широком спектре программного обеспечения, в том
числе и серверного.
Система НОТР предусматривает возможность задания «окна» попыток аутентифика-
ции и синхронизацию сервера аутентификации с OTP-токеном после успешного про-
хождения аутентификации.
Значение одноразового пароля вычисляется по формуле
НОТР(К. С) = Truncate(HMAC-SHA-\(K, С)),
где
•	К — секретный ключ;
•	С — счетчик числа раз прохождения аутентификации;
•	HMAC-SHA-1 — процедура генерации НМАС, основанная на функции хэширо-
вания SHA-1;
•	Truncate — процедура усечения 20-байтового значения HMAC-SHA-1 до 4 байт.
Пример аутентификации пользователя с помощью НОТР (рис. 4.6):
1.	Пользователь генерирует значение НОТР с использованием хранимого на ОТР-то-
кене значения числа раз прохождения аутентификации и секретного ключа
(592524594012).
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
2.	Пользователь вводит свое «имя пользователя» и ОТР на рабочей станции.
3.	Имя пользователя и ОТР (592524594012) передаются по сети в открытом виде.
4.	Аутентификационный сервер находит запись пользователя и генерирует ОТР, ис-
пользуя хранимые на сервере значения числа раз прохождения аутентификации данного
пользователя и секретного ключа пользователя и получая в результате ОТР
(592524594012).
5.	Сервер сравнивает ОТР, представленный от пользователя, и ОТР, вычисленный им
самим.
а.	Если значения не совпадают, сервер увеличивает значение числа раз прохождения
аутентификации пользователя на единицу и повторяет попытку.
Ь.	Если значения совпадают — на сервере сохраняется новое значение числа раз про-
хождения аутентификации пользователя.
Аутентификация считается успешной.
с.	Если достигнуто максимальное число неуспешных повторов процедуры аутенти-
фикации (задаваемое шириной «окна»), аутентификация считается неуспешной.
Гпава 4. Аутентификация с помощью одноразовых паролей
4.6. Недостатки методов аутентификации
с помощью ОТР. Возможные атаки
Ниже приведены известные атаки на системы, использующие аутентификацию с по-
мощью ОТР-токенов, и защиты от них.
Таблица 4. /
Атаки на одноразовые пароли и защита от них
Описание атаки	Защита от данной атаки
Атака «Человек посередине*	
Злоумышленник перехватывает одноразо- вый пароль, посланный законным пользо- вателем при аутентификации, блокирует законного пользователя и использует пе- рехваченный пароль для входа в систему.	Использование метода «запрос—ответ» Использование вместо синхронных одноразовых паро- лей, имеющих легитимность «в продолжительном» пе- риоде времени, одноразовых паролей, работающих по принципу «запрос-ответ». Каждое новое соединение тре- бует выполнения аутентификации заново.
Кража аутентификационного токена	
Злоумышленник похищает аутентифика- ционный токен законного пользователя и использует его для входа в систему.	PIN-коды в аутентификационных токенах Использование аутентификационных токенов, тре- бующих от владельца ввода PIN-кода перед началом генерации ОТР
Подбор PIN-кода аутентификационного токена	
Злоумышленник вручную производит пе- ребор всех возможных значений PIN-кода похищенного им аутентификационного токена законного пользователя.	Блокирование после ввода неправильного PIN-кода Аутентификационный токен отключается после того, как пользователь вводит неправильное значение PIN-кода подряд более заданного количества раз. Уве шчение задержки для каждого ввода неправильного PIN-кода Если вводится неправильное значение PIN-кода, то следующая попытка ввода PIN-кода возможна только через определенный промежуток времени, с каждым неправильным вводом эта задержка увеличивается.
Извлечение значения секретного ключа из программного аутентификационного токена	
Злоумышленник копирует программный аутентификационный токен (програм- мное обеспечение), пытается найти в нем хранимый секретный ключ, чтобы потом его использовать для аутентификации под видом законного пользователя	PIN-код является частью секретного ключа Частью секретного ключа аутентификационного токена является PIN-код, без его знания нельзя сгенерировать правильный ОТР, даже зная часть секретного ключа, ко- торый хранится в программном аутентификационном токене.
Подбор PIN-кода аутентификационного токена с помощью известных ОТР	
Злоумышленник перехватывает несколь- ко правильных ОТР, использованных для входа в систему, копирует программный аутентификационный токен (программное обеспечение), «тем он пытается подобрать PIN-код путем перебора его возможных значений, для тестирования пробного значения PIN-кода используются пере- хваченные ОТР.	Использование «аппаратных» аутентификационных токенов В этом случае достаточно сложно произвести «в реальные сроки» перебор возможных значении Р1\-кода до мо- мента обнаружения владельцем пропажи гокена и «ин- формирования аутентификационного сервера* о том, что данный токен может быть использован злоумыш- ленником.
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Окончание тай ищы 4.1
Описание атаки	Защита от данной атаки
Нечестный администратор аутентификационных токенов	
Злоумышленник является доверенным лицом либо является посредником дове- ренного лица, производящего инициали- зацию аутентификационного устройства до передачи его владельцу. Он может со- здать дубликат токена и, используя его, выдавать себя за владельца.	Ра/деление ответственности при инициализации аутен- тификационных токенов В процессе программирования и активирования токена должны участвовать двое или более людей, каждый из которых выполняет строго ограниченный набор опе- раций.
Примечание
При использовании программных аутентификационных токенов строго говоря эму-
лятор или отдельный закрытый ключ подтверждает подлинность только рабочей станции,
а не пользователя. Даже при условии защиты с помощью PIN-кода, строгая двухфак-
торная аутентификация заменяется на однофакторную. Любому лицу, имеющему физи-
ческий доступ к рабочей станции, чтобы представиться пользователем, остается только
узнать его PIN-код. Этот подход может оказаться достаточно эффективным для сотруд-
ников и клиентов работающих дома, но он неприемлем для использования в офисе, его
целесообразность для мобильных сотрудников сомнительна.
Контрольные вопросы
1.	Что такое одноразовые пароли?
2.	Опищите принцип работы ОТР-токенов.
3.	Приведите пример аутентификации пользователя при использовании ОТР-токеном
метода «запрос—ответ».
4.	Приведите пример аутентификации пользователя при использовании ОТР-токеном
метода «только ответ».
5.	Приведите пример аутентификации пользователя при использовании ОТР-токеном
метода «синхронизация по времени».
6.	Приведите пример аутентификации пользователя при использовании ОТР-токеном
метода «синхронизация по событию».
Глава 5
КРИПТОГРАФИЯ С ОТКРЫТЫМ КЛЮЧОМ
5.1.	Общие сведения
о криптографии с открытым ключом
5.1.1.	Использование криптографии с открытым ключом
В криптографии с открытым ключом (асимметричная криптография) алгоритмы исполь-
зуют связанные между собой пары ключей, состоящие из открытого и закрытого ключа.
Для каждого человека или объекта генерируется ключевая пара:
•	открытый ключ, доступный для всех;
•	закрытый ключ, известный только человеку, которому он выдан, и никому другому
не раскрывается и никуда не передается.
Информация, зашифрованная с помощью одного ключа из ключевой пары, может быть
расшифрована только с помощью другого ключа из этой же пары Ключи математически
связаны между собой так, что, зная открытый ключ, практически невозможно вычис-
лить закрытый. Пользователь может повсеместно распространять свой открытый ключ,
но он должен обязательно защищать свой закрытый ключ.
Криптографические методы защиты используют операцию преобразования информа-
ции. которая может выполняться одним или несколькими пользователями, обладающими
некоторым секретом, без знания которого (с вероятностью, близкой к единице за раз-
умное время) невозможно осуществить эту операцию
К криптографическим методам защиты в общем случае относятся:
•	шифрование информации (термин шифрование объединяет в себе два процесса:
зашифровывание и расшифровывание информации);
•	формирование и проверка цифровой подписи электронных документов.
Электронная цифровая подпись (ЭЦП) — это реквизит электронного документа, ко-
торый предназначен для защиты данного электронного документа от подделки, получен
в результате криптографического преобразования информации с помощью закрытого
ключа электронной цифровой подписи и позволяющий идентифицировать владельца
сертификата ключа подписи, а также установить отсутствие искажения информации
в электронном документе.
Применение электронной цифровой подписи позволяет:
•	обеспечить подтверждение авторства (аутентичность) информации;
•	обеспечить контроль целостности (в том числе истинности) информации;
•	решать вопрос о юридическом статусе электронных документов, а значит, решать
задачу разграничения ответственности между взаимодействующими абонентами
(субъектами).
Таким образом, криптографию с открытым ключом можно использовать для:
•	предотвращения возможности несанкционированного ознакомления с информа-
цией при ее хранении в компьютере или на отчуждаемых носителях, а также при
передаче по каналам связи;
•	подтверждения подлинности электронного документа, доказательства авторства
документа и факта его получения от соответствующего источника информации;
•	обеспечения гарантий целостности (имитостоикости) — исключение возможности
необнаружения несанкционированного изменения информации;
•	аутентификации пользователей системы — владельцев секретных ключей.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Ниже приведен пример использования криптографии с открытым ключом для шиф-
рования сообщения.
Для обеспечения конфиденциальности данных Автор может отправить личное сооб-
щение Получателю, зашифровав его с помощью открытого ключа Получателя (находя-
щегося в свободном доступе), потому что только Получатель обладает закрытым ключом
и может расшифровать данное сообщение.
Поскольку ассиметричная криптография требует достаточно больших вычислитель-
ных ресурсов, обычно на практике она применяется в комбинации с симметричной
криптографией. Само сообщение шифруется с помощью использования симметричного
алгоритма, а секретный (сеансовый) ключ, использованный при шифровании данного
сообщения, шифруется с помощью ассиметричного алгоритма для передачи сеансовых
ключей по сети.
Пример использования криптографии с открытым ключом для электронной цифро-
вой подписи сообщения приведен на рис. 5.1
Сервер аутентификации хранит файл открытых ключей всех пользователей.
Для обеспечения удостоверения подлинности источника данных Автор может отпра-
вить Получателю сообщение, зашифровав его с помощью своего закрытого ключа. По-
лучатель может быть уверен, что сообщение поступило именно от Автора, если он смо-
жет расшифровать его с помощью использования его открытого ключа. Таким образом,
личность отправителя может быть однозначно удостоверена, поскольку по определению
только Автор имеет доступ к своему закрытому ключу.
Поскольку данные криптографические преобразования производятся над значением
хэш-функции документа, любое изменение содержания документа приводит к уничто-
жению подписи автора документа. Таким путем можно гарантировать, что в документ,
если он «содержит подпись» Автора, никто не вносил каких-либо изменений, кроме са-
мого Автора данного документа.
Закрытым ключ
Хэш I
Сервер аутентификации
хранит файл открытых
ключей всех пользователей
Получатель
Открытый ключ
Гпава 5. Криптография с открытым ключом
5.1.2.	Аутентификация с помощью открытого ключа
Аутентификационный сервер хранит файл открытых ключей всех пользователей, а все
пользователи хранят свои закрытые ключи. Пример аутентификации пользователя с по-
мощью открытых ключей (упрощенный вариант) приведен на рис. 5.2:
1.	Сервер посылает пользователю случайную строку, созданную генератором случай-
ных чисел (ГСЧ).
2.	Пользователь шифрует эту строку своим закрытым ключом и посылает ее обратно
серверу вместе со своим именем.
3.	Сервер находит в базе данных открытый ключ пользователя и расшифровывает со-
общение, используя этот открытый ключ.
4.	Если отправленная и расшифрованная строки совпадают, сервер предоставляет
пользователю доступ к системе.
Никто другой не может воспользоваться закрытым ключом Пользователя, следова-
тельно, никто не сможет выдать себя за него. Что более важно, Пользователь никогда не
посылает на компьютер свой закрытый ключ. Злоумышленник, перехватывая сообщения,
не получит никаких сведений, которые позволили бы ему вычислить закрытый ключ
Пользователя и выдать себя за него.
Рис. 5.2. Аутентификация с помощью открытого ключа (упрощенный вариант)
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
В данной процедуре на шаге 1 производится шифрование «случайной строки, прислан-
ной от сервера», что служит потенциальной уязвимостью процедуры, так как этим может
воспользоваться злоумышленник для взлома данного протокола с помощью подобран-
ного шифртекста. Безопасные идентификационные протоколы имеют более сложную
форму (рис. 5.3):
1.	Пользователь выполняет вычисление, основанное на некоторых случайных числах
в своем закрытом ключе, и посылает результат серверу.
2.	Сервер посылает другое случайное число.
3.	Пользователь выполняет некоторое вычисление, основанное на случайных числах
(как созданных им. так и полученных от сервера) в своем закрытом ключе, и посылает
результат серверу.
4.	Сервер выполняет некоторое вычисление для различных чисел, полученных от
Пользователя, и его открытого ключа, проверяя, что Пользователю известен его закры-
тый ключ.
5.	Если проверка завершается успешно, личность Пользователя подтверждается.
В этом случае шаг 1 позволяет защитить протокол от вскрытия с помощью подобран-
ного шифртекста.
Данный протокол широко используется, если криптография с открытым ключом
применяется в рамках одного небольшого предприятия, когда число пользователей не-
велико. Если же криптографию с открытым ключом используют для большого числа
пользователей или нескольких предприятий, необходимо иметь инфраструктуру для управ-
ления ключами.
5.1.3.	Аутентификация с помощью открытого ключа
на основе российских криптографических алгоритмов
В 2001 г. по инициативе российской компании «КРИПТО-ПРО» предложены «Ре-
комендации к средствам криптографической защиты информации на взаимодействие
удостоверяющих центров, реестров сертификатов, сертификаты ключей формата Х.509
и электронные документы формата CMS». Указанные Рекомендации составлены с уче-
том международных стандартов и рекомендаций, директивы Европейского парламента
«Об электронной цифровой подписи» (1999/С 243/02) и рабочих документов Европей-
ского института стандартов по телекоммуникациям ETSI (European Telecommunications
Standards Institute).
Рекомендации описывают способ реализации и содержат требования на форматы от-
крытых ключей и электронной цифровой подписи при использовании российских крип-
тографических стандартов ГОСТ Р 34.10—94, ГОСТ Р 34.11—94. В рамках проходившего
57 заседания IETF (Internet Engineering Task Force) в Вене компания «КРИПТО-ПРО»
представила три проекта информационных документов (Internet-Drafts), которые были
приняты к дальнейшему рассмотрению. В проектах приводится описание использования
криптографических алгоритмов ГОСТ 28147—89, ГОСТ Р 34.10—94, ГОСТ Р 34.10—2001,
ГОСТ Р 34.11—94 в сертификатах открытых ключей, криптографических сообщениях и
протоколе TLS. Впоследствии к существующим документам были добавлены еще два
проекта, в которых приводятся описания ЭЦП в формате XML и криптографических ал-
горитмов шифрования и преобразования ключей.
В начале 2006 г. на официальном сайте IETF был опубликован первый в истории сооб-
щества Интернет-стандарт для применения указанных российских криптографических
алгоритмов — RFC 4357. В настоящее время комитет IETF утвердил и опубликовал новые
Гпава 5. Криптография с открытым ключом
стандарты: RFC 4490 и RFC 4491, определяющие использование алгоритмов российских
стандартов ГОСТ Р 34.11-94, ГОСТ Р 34 10-94, ГОСТ Р 34 10—2001. ГОСТ 28147-89
с включением их в документацию IETF (RFC) со статусом Internet-стандартов. RFC 4357 —
INFORMATIONAL (стандартом не является, но на него нормативно ссылаются RFC 4490
и RFC 4491).
В настоящее время действуют следующие признанные на международном уровне до-
кументы. касающиеся использования российских криптографических алгоритмов:
•	RFC4357 — описание дополнительных криптографических алгоритмов для исполь-
зования совместно с ГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001 и
ГОСТ Р 34.11-94;
•	RFC4490 — описание использования в CMS (Cryptographic Message Syntax) алгорит-
мов ГОСТ 28147-89, ГОСТ Р 34.10-94. ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94;
•	RFC4491 — описание использования алгоритмов ГОСТ 28147—89, ГОСТ Р 34.10—94,
ГОСТ Р 34.10—2001 и ГОСТ Р 34.11—94 в сертификатах открытых ключей и в CRL;
•	draft-chudov-cryptopro-cptls — описание использования алгоритмов ГОСТ 28147—89,
ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94 в протоколе TLS;
•	draft-chudov-cryptopro-cpxmldsig — описание использования алгоритмов ГОСТ
Р 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94 в XML.
Эти документы разработаны в рамках соглашения о совместимости криптографиче-
ских продуктов между ведущими российскими разработчиками средств криптографиче-
ской защиты конфиденциальной информации.
Российские криптографические алгоритмы позволяют обеспечить реализацию сле-
дующих функций защиты информации:
•	авторизация и обеспечение юридической значимости электронных документов;
•	конфиденциальность и контроль целостности передаваемой информации:
•	аутентификация связывающихся сторон;
•	установление аутентичного защищенного соединения для обмена информацией.
5.2.	Авторизация и обеспечение
юридической значимости электронных документов
Авторизация и обеспечение юридической значимости электронных документов при
обмене ими между пользователями осуществляется с помощью процедур формирования
и проверки ЭЦП. Алгоритмы формирования и проверки ЭЦП определяются криптогра-
фическими стандартами:
•	ГОСТР 34.10—94. «Информационная технология. Криптографическая защита ин-
формации. Процедуры выработки и проверки электронной цифровой подписи на
базе асимметричного криптографического алгоритма» (этот стандарт действителен до
31.12.2007). Данный стандарт определяет процедуры формирования и проверки ЭЦП
с выполнением криптографических преобразовании в экспоненциальной логике
•	ГОСТ Р 34.10—2001 «Информационная технология. Криптографическая защита
информации. Процессы формирования и проверки электронной цифровой подпи-
си». Этот стандарт определяет процедуры формирования и проверки ЭЦП с вы-
полнением криптографических преобразовании на базе эллиптических кривых.
•	ГОСТР34.11—94. «Информационная технология. Криптографическая защита ин-
формации. Функция хэширования». Этот стандарт определяет процедуру хэши-
рования подписываемых данных.
ЧАСТЫ ТЕОРЕТИЧЕСКИЕОСНОВЫ
5.3.	Конфиденциальность
и контроль целостности передаваемой информации
Конфиденциальность и контроль целостности информации обеспечивается путем ее
шифрования и имитозащиты. Алгоритмы шифрования и имитозащиты определяются стан-
дартом ГОСТ28147—89. Этот стандарт определяет следующие режимы шифрования данных:
•	простая замена, тип шифрования — ЕСВ (Electronic Codebook);
•	гаммирование, тип шифрования — ССВ (CipherCountBlock);
•	гаммирование с обратной связью, тип шифрования — CFB (Cipher Feedback).
Алгоритмы, определяемые ГОСТ 28147—89, являются симметричными и используют
ключи длиной 256 бит.
Алгоритм шифрования стандарта ГОСТ 28147—89 используется в условиях открыто-
го распределения ключей с выработкой симметричного ключа парной связи, которая
осуществляется с помощью алгоритма Диффи-Хеллмана на базе операций алгоритма
ГОСТ Р 34.10—94 или ГОСТ Р 34.10—2001. Ключ Диффи-Хеллмана К(х, у) вырабаты-
вается на каждой стороне информационного обмена из собственного закрытого ключа
и открытого ключа противоположной стороны, при использовании алгоритма:
•	ГОСТ Р 34 10—94 ключ К(х, у) вычисляется по формуле К(х, у) = ^(modp);
•	ГОСТ Р 34.10—2001 ключ К(х, у) вычисляется по формуле К(х, у) = ((а х x)(mod^))<>
°0>°Р), где Р— стартовая точка на цикле эллиптической кривой (две координаты
по 256 бит), а — синхровектор (64 бит).
Ключ парной связи образуется хэшированием ключа К(х, у) по алгоритму ГОСТ
Р 34.11—94. Этот ключ имеет длину 256 бит и используется в установленной парной свя-
зи для шифрования случайных симметричных ключей сообщений по алгоритму ГОСТ
28147-89.
5.4.	Аутентификация связывающихся сторон
Аутентификация связывающихся сторон осуществляется с помощью сертификатов
открытых ключей сторон. Используются сертификаты стандарта Х.509, выпущенные
удостоверяющим центром или другим доверенным издателем. Для удостоверения сер-
тификата используется ЭЦП его издателя в соответствии с алгоритмом ГОСТ Р 34 10—94
или ГОСТ Р 34.10-2001.
5.5.	Установление
аутентичного защищенного соединения
Для установления аутентичного защищенного соединения используется реализация
протокола TLS (Transport Lauer Security, TLS 1.0, RFC 2246) на базе российских крип-
тографических алгоритмов. Этим обеспечивается сетевая аутентификация клиент-сервер,
конфиденциальность и целостность данных при работе клиент-серверных приложений,
в частности, в Интернете.
Для установления аутентичного соединения между клиентом и сервером, ключи кото-
рых соответствуют алгоритмам ГОСТ Р 34.10—94 или ГОСТ Р 34.10—2001, в реализации
протокола TLS используются российские криптографические алгоритмы ГОСТ 28147—89,
хэширования ГОСТ Р 34.11—94 и обмена ключей по алгоритму Диффи-Хеллмана на базе
алгоритма ГОСТ Р 34.10—94 или ГОСТ Р 34.10-2001.
48
Гпава 5. Криптография с открытым ключом
5.6.	Инфраструктура открытых ключей (PKI)
Для использования криптографии с открытым ключом необходимо гарантировать,
что каждый закрытый и открытый ключ управляются корректным образом
Инфраструктура открытых ключей (Public Key Infrastructure — PKI) предназначена
для управления открытыми ключами и сертификатами с целью поддержки услуг аутен-
тификации, шифрования, целостности и неотказуемости.
Открытый ключ, связанный с определенным пользователем, должен быть удостоверен
сертификатом открытого ключа Более того, подлинность сертификата открытого ключа
должна проверяться доверенным учреждением — центром сертификации (СА — certifi-
cation autority).
Сертификат открытого ключа — структура данных, состоящая их раздела данных и
раздела подписи.
Раздел данных содержит открытые данные, которые включают, как минимум, откры-
тый ключ и строку, идентифицирующую сторону (представляемый объект) для связы-
вания с ним при условии, что открытый ключ подписывающего известен заранее.
Раздел подписи состоит из цифровой подписи органа сертификации под разделом данных.
Тождественность представляемого объекта, таким образом, связывается с заданным откры-
тым ключом. На практике наиболее часто используются сертификаты формата Х.509 v3.
Орган сертификации (СА — certification autority) — доверенная третья сторона, чья
подпись под сертификатом подтверждает подлинность открытого ключа, связанного с пред-
ставляемым объектом.
Простейшую модель PKI можно построить из одного компонента, который называется
издателем (issuer). Он выполнял бы все необходимые функции. Пользователи использо-
вали бы криптографию с открытым ключом в своих приложениях, получая и обрабатывая
сертификаты и список аннулированных сертификатов (CRL). В рамках одного компо-
нента трудно обеспечить необходимый уровень защищенности при выполнении всех не-
обходимых задач, связанных с созданием и распространением сертификатов и CRL. По-
этому обычно PKI строится из различных компонентов, каждый из которых предназна-
чен для специализированного выполнения нескольких задач.
5.7.	Аутентификация с помощью открытого ключа
на основе сертификата
Механизмы аутентификации на основе сертификатов обычно используют режим за-
прос-ответ. Пользователь, или точнее, программное обеспечение компьютера для ге-
нерирования ответа вырабатывает с помощью закрытого ключа пользователя цифровую
подпись для случайного запроса от сервера аутентификации. Пользователь возвращает
эту подпись серверу вместе с сертификатом открытого ключа. Сервер аутентификации
проверяет подлинность сертификата открытого ключа, и, если она подтверждается, он
проверяет подлинность цифровой подписи, используя открытый ключ пользователя из
сертификата, таким образом, удостоверяя подлинность пользователя.
Механизмы аутентификации на основе сертификатов
обычно используют режим запрос—ответ.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Общий процесс, с помощью которого аутентификационным сервер использует серти-
фикат открытого ключа для получения подлинного открытого ключа пользователя, со-
стоит из следующих этапов:
1.	Получение подлинного открытого ключа СА (одноразовый процесс).
2.	Получение идентификатора пользователя.
3.	Получение по незащищенному каналу от этого пользователя его сертификата откры-
того ключа (согласующегося с его идентификатором).
4.	Проверка текущей даты и времени относительно срока действия, указанного в сер-
тификате (при проверке используются локальные доверенные часы):
5.	Проверка текущей действительности открытого ключа СА.
6.	Проверка подписи под сертификатом пользователя с помощью открытого ключа СА;
7.	Проверка того, что сертификат не был отозван.
8.	Если все проверки успешны, то сервер аутентификации принимает открытый ключ
в сертификате как подлинный открытый ключ данного пользователя.
5.8.	Организация хранения закрытого ключа
Несмотря на то, что криптография с открытым ключом может обеспечивать надеж-
ную аутентификацию пользователя, сам по себе закрытый ключ никак с ним не связан.
Поэтому необходимо хранить закрытый ключ, обеспечивая его защиту от компрометации.
Существует несколько способов хранения закрытого ключа.
5.8.1.	Профиль пользователя/реестр
Самый простой вариант — хранить закрытые ключи внутри локального хранилища
операционной системы, которое связано с учетной записью пользователя и защищено
с помощью криптографических методов. Однако такое решение ассоциирует пользова-
теля с его закрытым ключом только после авторизации в операционной системе и. сле-
довательно, ключ нельзя использовать для начальной аутентификации.
Простой вариант — ключи хранятся внутри локального
хранилища операционной системы. Закрытый ключ
связан с конкретным компьютером.
Кроме того, закрытый ключ, хранящийся на жестком диске владельца компьютера,
уязвим по отношению к прямым и сетевым атакам. Достаточно подготовленный злоу-
мышленник может похитить закрытый ключ пользователя и с помощью этого ключа
представляться этим пользователем.
Закрытый ключ в данном случае связан с конкретным компьютером.
5.8.2.	Незащищенные носители
Для переноса закрытого ключа можно исполь ювать любые сменные носители инфор-
мации (дискеты, карты памяти, USB-флеш и пр.). В этом случае на носителе создается
ключевой контейнер, содержащий зашифрованное значение закрытого ключа с помощью
запоминаемого пароля.
50
Гпава 5 Криптография с открытым ключом
Однако такая защита недостаточно эффективна — пароли уязвимы по отношению ко
многим атакам, а зашифрованный контейнер беспрепятственно можно скопировать на
любой другой носитель, обеспечивая создание дубликата для злоумышленников.
Незащищенные носители — на сменном носителе информации
создается ключевой контейнер, содержащий зашифрованное
значение закрытого ключа
5.8.3.	Touch Memory, Memory-карты
В качестве носителя информации можно использовать специализированные устройст-
ва аутентификации — touch memory (электронные ключи в виде так называемых «табле-
ток») и Memory-карты, выполненные в виде пластиковых карт примерно такого же размера,
как и кредитные карты, но с встроенной микросхемой. И тот и другой тип устройств
представляют собой сменный носитель информации с уникальным номером, прошивае-
мым при изготовлении, и памятью, в которой можно хранить данные пользователя.
Некоторые типы подобных устройств аутентификации предусматривают возмож-
ность двухфакгорной аутентификации, требуя ввод PIN-кода для доступа к содержимо-
му пользовательской памяти.
5.8.4.	Смарт-карты и USB-ключи
Смарт-карты ( как и Memory-карты) представляют собой пластиковые карты с встро-
енной микросхемой. Однако смарт-карты представляют собой более сложное устройство
аутентификации, содержащее микропроцессор и операционную систему, контролирую-
щую устройство и доступ к объектам в его памяти Кроме того, смарт-карты, как пра-
вило, обладают возможностью проводить криптографические вычисления.
Смарт-карты находят все более широкое применение в различных областях, от систем
накопительных скидок до кредитных и дебетовых карт, студенческих билетов и телефо-
нов стандарта GSM.
Несмотря на название — устройства для чтения смарт-карт, как и большинство око-
нечных устройств или устройств сопряжения (IFD) способны как считывать, так и запи-
сывать информацию, если позволяют возможности смарт-карты и права доступа. Устрой-
ства для чтения смарт-карт могут подключаться к компьютеру с помощью:
•	последовательного порта;
•	слота PCMCIA;
•	порта USB.
Устройства чтения смарт-карт могут быть интегрированы в клавиатуру.
Некоторые производители выпускают другие виды аппаратных устройств, в которых
смарт-карты объединены с устройством чтения смарт-карты. По свойствам памяти и вы-
числительным возможностям они полностью аналогичны смарт-картам.
Наиболее популярны аппаратные «ключи», использующие порт USB. USB-ключи
привлекательны для некоторых организации, поскольку USB становится стандартом,
находящим все большее распространение в новых компьютерах: организации не нужно
приобретать для пользователей какие бы то ни было считыватели.
Смарт-карты и USB-ключи по своим возможностям являются интеллектуальными
устройствами.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
5.9.	Интеллектуальные устройства
и аутентификация с помощью открытого ключа
Смарт-карты и USB-ключи могут повысить надежность служб инфраструктуры от-
крытых ключей PKI (Public Key Infrastructure): смарт-карта может использоваться для
безопасного хранения закрытых ключей пользователя, а также для безопасного выпол-
нения криптографических преобразовании. Безусловно, интеллектуальные устройства
аутентификации не обеспечивают абсолютную защиту, но их защита намного превос-
ходит возможности обычного компьютера.
Для хранения и использования закрытого ключа разработчики используют различ-
ные подходы. Наиболее простой из них — использование интеллектуального устройства
в качестве дискеты: при необходимости карта экспортирует закрытый ключ, и криптог-
рафические операции осуществляются на рабочей станции. Этот подход является не са-
мым совершенным с точки зрения безопасности, зато относительно легко реализуемым
и предъявляющим невысокие требования к интеллектуальному устройству.
Два других подхода более безопасны, поскольку предполагают выполнение интел-
лектуальным устройством криптографических операций. При первом пользователь ге-
нерирует ключи на рабочей станции и сохраняет их в памяти устройства. При втором
пользователь генерирует ключи при помощи самого устройства и хранит их в его памяти.
В обоих случаях, после того как закрытый ключ сохранен, его нельзя извлечь из уст-
ройства и получить любым другим способом.
Пользователь генерирует ключи на рабочей станции
и сохраняет их в памяти устройства
5.9.1.	Генерация ключей вне устройства (рис. 5.4)
В этом случае пользователь может сделать резервную копию закрытого ключа. Если
устройство выйдет из строя, будет потеряно, повреждено или уничтожено, пользователь
сможет сохранить тот же закрытый ключ на новой карте. Это необходимо, если пользо-
вателю требуется расшифровать какие-либо данные сообщения, и т. д., зашифрованные
с помощью соответствующего открытого ключа Однако закрытый ключ пользователя
в этом случае может быть похищен
5.9.2.	Генерация ключей с помощью устройства (рис. 5.5)
В этом случае закрытый ключ не выходит из устройства, а также нет риска, что зло-
умышленник украдет его резервную копию. Способ использования закрытого ключа —
обладание интеллектуальным устройством. Будучи безопасным, это решение выдвигает вы-
сокие требования к возможностям интеллектуального устройства: оно должно генериро-
вать ключи и осуществлять криптографические преобразования. Также предполагается,
чго закрытый ключ не может быть восстановлен в случае выхода устройства из строя.
Гпава 5. Криптография с открытым ключом
Выполнение
Смарт-карта
криптографических
операций
Рис. 5.4. Генерация ключей вне устройства
Рис. 5.5. Генерация ключей с помощью устройства
Пользователь генерирует к. личи с помощью самого устройства и хранит их в его памяти
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
5.10.	Недостатки аутентификации
с помощью открытых ключей. Возможные атаки
Ниже приведены известные атаки на системы, использующие аутентификацию с по-
мощью открытых ключей, и защита от них (табл. 5.1).
Методы атак на системы с открытым ключом и борьба с ними
Таб ища 5.1
Описание атаки	Защита от данной атаки
Факторы шция ключа	
Злоумышленник может разложить ключ на множители и вывести значение лич- ного ключа пользователя.	Существенное увеличение размеров ключей — на данный момент рекомендуется использовать ключи длиной не менее 512 бит. Для центров сертификации рекоменду- ется использовать ключи длиной 2048 бит.
Атака по известным сообщениям	
Злоумышленник подготавливает специ- альное сообщение и принуждает вла- дельца подписать его личным ключом. Данный результат после преобразования может быть использован злоумышленни- ком для формирования нового сообще- ния и выдачи его >а сообщение от вла- дельца личного ключа.	Хэшированная цифровая подпись — владелец формирует подпись для сообщения, подписывая своим личным ключом хэшированное значение сообщения.
Подделка открытого ключа	
Злоумышленник может подставить свой собственный открытый ключ, если полу- чатель принимает неаутентифицирован- ные ключи.	Сертификаты открытого ключа — публикуется назна- чение ключа владельца, и под этой публикацией ста- вится заслуживающая доверия подпись.
Атака ♦ Человек посередине*	
Злоумышленник подставляет свой собст- венный открытый ключ вместо другого ключа и заново шифрует сообщения между объектами.	Сертификаты открытого ключа — как для «Подделки открытого ключа» (см. выше).
Фиктивное имя в сертификате	
Злоумышленник ставит имя жертвы в за- явке на получение сертификата открыто- го ключа.	Требование владения ключом — Сертификаты выдаются только лицу, которое владеет запрошенным именем.
Подмена сертификата	
Злоумышленник использует законный сертификат для поддельного сервера с другим IP-адресом	Проверка достоверности имени хоста в сертификате — имя в сертификате сравнивается с именем хост-маши- ны от который полнен данный сертификат.
Фиктивный центр выдачи сертификатов	
Злоумышленник использует фиктивный орган выдачи сертификатов для создания поддельных сертификатов и «тем за- ставляет браузеры принять его открытый ключ данного центра.	Эффективной защиты на данный момент нет.
Гпава 5 Криптография с открытым ключом
Окончание таб шцы 5.1
Описание атаки	Защита от данной атаки
Использование личного ключа	
Злоумышленник использует украденный личный ключ	Список отозванных сертификатов — периодически вы- пускается список сертификатов, которые были отозва- ны. Интерактивный отзыв сертификатов — обеспечивает- ся механизм выполнения запроса органу по выдаче сертификатов для подтверждения того, что сертификат не был отозван. Периодическая сертификация — выдвигается требова- ние, чтобы все сертификаты были «свежими» и обес- печивался механизм, который позволял бы динамиче- ски затребовать и получить от сертифицирующих ор- ганов «свежий» сертификат.
Взлом парольной фразы личного ключа	
Злоумышленник использует программу взлома для получения доступа к личному ключу законного пользователя, хранимо- го на локальном компьютере.	Личный ключ на смарт-карте — личный ключ хранится на смарт-карте, а не в зашифрованном файле.
Активная разведка личного ключа	
Злоумышленник внедряет в систему жертвы программу, которая перехваты- вает.шчныи пароль жертвы в момент его использования.	Реализация функции шифрования по шчному к иочу на смарт-карте — личный ключ хранится на смарт-карте, которая реализует функцию шифрования, т. е. личный ключ никогда ее не покидает.
Кража резервной копии личного ключа	
Злоумышленник крадет резервную ко- пию личного ключа, хранимого на дис- кете или в другом устройстве.	Создание шчного ключа на смарт-карте — личный ключ генерируется на смарт-карте и никогда ее не по- кидает
Примечания
•	При аутентификации с помощью открытых ключей целесообразно использовать
интеллектуальные устройства аутентификации. При этом весьма важным является
исключительное владение пользователя закрытым ключом, т.е. обеспечение его за-
шиты от компрометации. Это невозможно, если закрытый ключ хранится или крип-
тографические преобразования осуществляются на компьютере пользователя.
•	При аутентификации с помощью открытых ключей пользователь может допустить
халатность 1-го типа: интеллектуальные устройства могут быть оставлены на ра-
бочей станции. Если пользователь, отходя от своего рабочего места, оставляет
смарт-карту в устройстве чтения или USB-ключ в порту, кто-то другой в офисе
может легко представиться данным пользователем. Защита с помощью PIN-кода
эффективна, если сеансы пользователей блокируются после определенного проме-
жутка бездействия, а для разблокирования необходима повторная аутентификация
Но PIN-коды можно узнавать, например, «подглядывая из-за плеча». Организа-
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
ции должны призывать пользователей всегда носить интеллектуальные устройства
с собой. Это обеспечивается автоматически, если устройства используются для
контроля физического доступа в помещения.
• При аутентификации с помощью открытых ключей пользователь может допустить
халатность 2-го типа: интеллектуальные устройства могут быть утеряны. Органи-
зация, в которой используются интеллектуальные устройства аутентификации,
будет вынуждена каждому пользователю, потерявшему свое устройство, выдавать
новое временное устройство или временно осуществлять аутентификацию с по-
мощью альтернативного метода. При этом организация должна следить за тем,
чтобы подобные мероприятия не ослабляли безопасность.
• Интеллектуальные устройства могут быть уязвимы по отношению к логическим
и физическим атакам, а также атакам «троянских коней». Каждая организация,
использующая интеллектуальные устройства с целью обеспечения безопасности,
должна быть уверена в том, что производители устройств и разработчики про-
граммного обеспечения позаботились о принятии соответствующих логических и
архитектурных контрмер. Правда, эти меры могут отрицательно повлиять на удобство
использования интеллектуального устройства. Логические атаки осуществляются,
когда интеллектуальное устройство работает в обычных физических условиях,
а важная информация в виде байтов поступает на вход или снимается с выхода
интеллектуального устройства. Физические атаки возможны, когда изменяются
физические параметры, такие как: температура, частота, напряжение — с целью
получения доступа к важной информации в памяти интеллектуального устройства.
Атаки «троянских коней» предполагают размещение несанкционированного при-
ложения на рабочей станции пользователя. Троянская программа ждет, пока поль-
зователь введет действительный PIN-код в приложении, которому он доверяет,
что сделает возможным использование закрытого ключа, а после этого предложит
интеллектуальному устройству выработать цифровую подпись несанкциониро-
ванных данных.
Контрольные вопросы
1.	Из каких элементов состоит ключевая пара и для чего предназначен каждый эле-
мент?
2.	Что такое электронная цифровая подпись? Приведите примеры использования.
3.	В каких случаях можно использовать криптографию с открытым ключом?
4.	Приведите пример использования криптографии с открытым ключом для шифро-
вания сообщения.
5.	Приведите пример аутентификации пользователя с помощью открытых ключей.
6.	Для чего предназначена инфраструктура открытых ключей (РК1)?
7.	Назовите способы хранения закрытого ключа.
8.	Назовите недостатки аутентификации с помощью открытых ключей.
9.	Приведите примеры атак на системы, использующие аутентификацию с помощью
открытых ключей, и способы ищиты от подобных атак
Глава 6
ПРОТОКОЛЫ АУТЕНТИФИКАЦИИ
В ЛОКАЛЬНОЙ СЕТИ
Существует несколько протоколов, описывающих процесс аутентификации субъектов
в локальной сети. Например, в рамках операционных систем семейства Windows ком-
пании Microsoft использовались протоколы LAN Manager (LANMAN), NT LAN Manager
(NTLM), NT LAN Manager версии 2 (NTLM v2) и Kerberos. В течение 1990-х гг. разра-
ботчики компании Microsoft придерживались в отношении аутентификации эволюцион-
ного подхода так что новые продукты могли работать совместно с существующим уста-
новленным программным обеспечением:
•	аутентификация в настольных системах в исполнении компании Microsoft начи-
налась с типовых методик блокирования экрана и введения менеджера локальной
сети — LANMAN, использовавшего для аутентификации сетевых служб метод
«запрос—ответ»;
•	ОС Windows NT 4.0 привнесла в контроллеры доменов функцию непрямой аутен-
тификации и протокол NTLM;
•	в ОС Windows 2000 появилась возможность использовать протокол Kerberos.
6.1.	Протоколы LAN Manager и NT LAN Manager
6.1.1.	Архитектура, компоненты, участники, описание протоколов
LAN- и NT-технология паролей компании Microsoft включала в себя две важные осо-
бенности. Во-первых, все базы данных паролей содержали значения хэш-функции паро-
лей. Во-вторых, чтобы помешать активной разведке паролей, аутентификация основы-
валась на использовании технологии «запрос—ответ». Эти особенности, да еще после пе-
рехода от LANMAN к NTLM, создавали достаточно сложную паролевую среду
Работающие под управлением Windows системы хранят значения хэш-функции паро-
лей в системном файле и по возможности обеспечивают защиту файла с паролями от кра-
жи В современных Windows-системах имеется специальная область хранения, называемая
реестром. Находящаяся в реестре база данных администратора учетных записей пользо-
вателей (Security Account Manager, SAM), содержит записи всех авторизованных пользо-
вателей, а также хранит значения хэш-функции от их паролей. В ОС Windows NT на доступ
к записям в файле реестра накладываются ограничения на доступ пользователей, а до-
ступ к записям в базе SAM ограничен особенно жестко. Это не предотвращает все по-
пытки извлечь файл паролей Windows, однако увеличивает сложность подобных атак.
Работающие под управлением Windows системы хранят
значения хэш-функции паролей в системном файле и по
возможности обеспечивают защиту файла с паролями от кражи
Оказалось, что аутентификация в ОС Windows уязвима к атакам двух типов: к атакам на
базу данных SAM выполняемым с помощью автономно работающих программ-взлом-
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
щиков и к атакам программ-вхтомшиков, работающих с перехваченными парами «за-
прос-ответ».
Классические варианты атак на базу данных SAM появились как результат работ
в рамках проекта Samba и привели к разработке бесплатно распространяемого пакета,
позволявшего коллективно пользоваться файлами между UNIX-серверами и NT-клиен-
тами. Для синхронизации паролей UNIX-серверу необходимо получение копии значе-
ний хэш-функции паролей NT-пользователей. Чтобы извлекать значения хэш-функции
с целью выполнения над ними атаки угадывания методом проб и ошибок, взломщиками
также использовалось инструментальное средство типа pwdump или его разновидности.
6.1.2.	Хэширование в LAN MAN
Рассмотрим, как функция хэширования в LAN MAN преобразует принадлежащий
пользователю длинный пароль (рис. 6.1).
Сначала функция изменяет пароль до вида 14-символьной цепочки, при необходи-
мости добавляя или удаляя символы. Затем преобразует все символы в символы верхнего
регистра. Это хорошим ход с точки фения удобства пользования, так как, несмотря на
ошибки, сделанные пользователем при работе с клавишей <Shifl>, система все равно
распознает его пароль. Однако это снижает энтропию пароля.
После этого функция разделяет результат на два семибайтовых фрагмента и использует
каждый из них в качестве 56-разрядного ключа для шифрования с помощью алгоритма DES.
Каждый такой ключ используется для отдельного шифрования 64-разрядной константы.
В ОС UNIX алгоритм DES используется так же, только IANMAN опускает добавку.
Длинным LAN MAN-пароль пользователя
’ LongSiringofLctters
Преобразование
в 14 или менее
символов верхнего
регистра, разделение
на две половины,
добавление знаков
четности для
алгоритма DES
LONGSTR
Константа
/ CXB4053KS
14023322425
DES-
шифрованис
Ключ для DES
из левой половины
Ключ для DES
из правой половины
INGOFLE
ХЭШ строится путем
стыковки левого и правого
шифрованных значений
27F83K5K9465490F9GOWEVJU67098JSON76956KYSHD76J5C3
DES-
шифрование
Рис. 6.1. Хэширование в LAN MAN
58
Гпава 6 Протоколы аутентификации в локальной сети
Результаты шифрования соединяются в одну цепочку, образуя окончательный хэширо-
ванный результат.
При создании или изменении пароля пользователя система вычисляет значение
хэш-функции и сохраняет его значение в базе данных SAM. Проверяя пароль, исполь-
зуемый для локального входа, система хэширует вводимый Пользователем пароль и
сравнивает полученный результат с х шшрованным значением в базе данных SAM.
6.1.3.	Пароли в Windows в виде открытого текста
LAN MAN не всегда использует пароли типа «запрос—ответ», так как другие сетевые
продукты требуют применения паролей в виде открытого текста. Это особенно важно при
совместной работе с другими продуктами. Например, некоторые версии пакета Samba
для размещения Windows-совместимых сетевых служб на UNIX-системах использовали
прямые текстовые пароли. Продукты семейства Windows, включая NT, имеют необходи-
мые специальные программные модули, которые позволяют до некоторой степени авто-
матизировать процесс регистрации в службах, требующих пароли в виде открытого текста.
Администраторы могут устанавливать специальный конфигурационный флаг в реестре
ОС Windows, позволяющий использовать прямые текстовые пароли. В ОС Windows NT
использование подобных паролей затруднено, так что администраторы предупреждаются
о потенциальном риске перехвата паролей.
Поддержка прямых текстовых паролей служит причиной потенциальной проблемы,
называемой «атакой под старину». В процессе этой атаки взломщик заставляет клиента
поверить, что он должен предоставить серверу данные аутентификации в виде открытого
текста. Клиент отвечает, автоматически предоставляя прямой текстовый пароль вместо
его хэширования и использования.
Поддержка прямых текстовых паролей служит причиной
потенциальной проблемы, называемой «атакой под старину».
6.1.4.	Метод «запрос—ответ» в LAN MAN, NTLM
В отличие от реализации метода «запрос—ответ» на основе устройств аутентификации,
протокол регистрации в ОС Windows автоматически перехватывает запрос и генерирует
ответ на основе пароля владельца. Когда пользователь запрашивает у сервера разрешение на
вход, тот в ответ посылает случайное 8-байтовое число. Пользователь в ответ вводит «имя
пользователя» и пароль, если этого еще не было сделано. Получив эти данные, рабочая
станция вычисляет значение хэш-функции от пароля (поэтому его копия не хранится в виде
открытого текста).
Протокол регистрации в ОС Windows автоматически
перехватывает запрос и генерирует ответ на основе
пароля владельца.
В общем случае рабочая станция хранит копию хэша пароля, и пользователю не при-
дется вводить его снова при следующем входе в систему. Наконец, рабочая станция вы-
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
числяет ответ, трижды используя алгоритм DES для полученного случайного числа Про-
граммное обеспечение ОС Windows вычисляет ответ на запрос аутентификации следую-
щим образом (это реализовано как для LANMAN, так и для NTLM):
1.	На первом этапе процедура использует 128-разрядное хэшированное значение па-
роля пользователя и получает из него три 56-разрядных фрагмента.
2.	Затем она трижды выполняет шифрование специального одноразового числа, исполь-
зуя каждый из фрагментов в качестве ключа шифрования алгоритма DES.
3.	На конечном этапе процедура объединяет результаты трех шифрований в 24-баито-
вый ответ.
6.1.5.	Протокол NTLM
ОС Microsoft Windows NT 4.0 поддерживает три разных типа аутентификации — локаль-
ную доменную и удаленную.
•	Термин «локальная аутентификация» означает то, что физическое лицо регистри-
руется в устройстве непосредственно, не устанавливая удаленного соединения
•	Доменная аутентификация соответствует модели прямой аутентификации и от-
ражает ситуацию, когда человек использует свой компьютер для входа в другой
компьютер по сети. Примером является аутентификация реализуемая менедже-
ром локальной сети LANMAN.
•	Удаленная аутентификация соответствует модели непрямой аутентификации,
когда клиент регистрируется на сервере, который для верификации ответа поль-
зователя обращается к другому серверу (контроллеру домена системы NT).
Под аутентификацией в NTLM обычно понимаются два последних типа аутентифи-
кации. которые представляют собой сетевую аутентификацию в системе NT.
Разработчики ОС Windows NT существенно улучшили механизм аутентификации по
сравнению с тем. что был реализован в LANMAN. Ведь система NT поддерживала рас-
ширенный набор символов, что могло значительно увеличить количество возможных
паролей. Появилось и несколько новых алгоритмов шифрования, которые уменьшали
вычислительные накладные расходы и при этом сохраняли или даже увеличивали уро-
вень защиты.
В результате в Windows NT используется новая процедура хэширования паролей
В NT сохраняется 14-символьное ограничение на длину пародя. но можно пользоваться
любыми символами из набора символов Unicode. Пароли считываются и хранятся в виде
последовательности из четырнадцати 16-битовых Unicode-символов. Для получения
128-разрядного хэшированного значения пароля в NT используется разработанный
Роном Ривестом (Ron Rivest) коммерческий алгоритм хэширования Message Digest #4
(MD4) (более новый алгоритм MD5 широко используется в Internet-протоколах). Такой
усовершенствованный хэш обычно называют NTLM-хэшем.
Хотя реализованный в NTLM механизм аутентификации использует для кодирова-
ния паролей улучшенную функцию хэширования, в нем по-прежнему применяется про-
токол «запрос—ответ». Однако для поддержки совместимости с LANMAN NTLM-аутен-
тификация усложнена. NTLM-аутентификация требует вычислений как NTLM-хэша,
так и LANMAN-хэша. Каждая парольная запись пользователя в базе данных SAM со-
держит два хэшированных значения пароля: вычисленные с помощью NTLM-хэширо-
вания и с помощью LANMAN-процедуры. При аутентификации по методу «запрос—от-
вет» NT-клиент вычисляет два ответа: с помощью NTLM-хэша и LANMAN-хэша. Такой
подход позволяет NT-системам обеспечить преемственность со старым сетевым про-
Гпава 6. Протоколы аутентификации в локальной сети
граммным обеспечением. Но подобная совместимость часто сводит на нет повышение
уровня зашишенности, получаемое благодаря перепроектированной процедуре хэширо-
вания в NTLM.
6.1.6.	Возможные атаки на LAN MAN и NTLM
Ниже приведены известные атаки на системы, использующие аутентификацию с по-
мощью протоколов LANMAN и NTLM, и защита от них (табл. 6.1).
Таблица 6.1
Возможные атаки на LANMAN и NTLM и защита от них
Описание атаки	Защита от данной атаки
Маскировка под другого человека	
Осуществляется перехват нескольких одно- разовых паролей пользователя, пользую- щегося протоколом Х9.9.	Использование более длинных ключей шифрования Существующие технические меры заменяются механиз- мами, в которых используются более длинные ключи шифрования, в результате чего увеличивается устойчи- вость к атакам методом проб и ошибок
Восстановление шачения паром пользователя	
Взлом паролей по частям. Пароль взламы- вается по частям, так что атака линейна для каждой части, но не топологическая	Взаимозависимое вычисление хэшированного значения Вид каждой части хэшированного значения пароля зави- сит от значения всех частей пароля. Возможность взло- ма части пароля отсутствует.
Восстановление значения пароля пользователя	
Использование хэшированного значения LANMAN-пароля для взлома NT-хэша. Копирование хэшированных значений паролей из файлов восстановления ОС Windows NT.	Шифрование базы данных Шифруется вся база данных паролей, в результате чего взломщики уже не могут атаковать хэшированные зна- чения.
Принуждение к использованию пароля в виде открытого текста	
Взломщик заставляет сервер запросить у пользователя пароль в виде открытого текста, который может быть перехвачен в сети методами активной разведки.	Блокирование работы более слабого механизма аутенти- фикации Система конфигурируется таким образом, что использо- вание слабых механизмов, введенных для обеспечения обратной совместимости, запрещается.
Подстановка хэшированного значения, прошедшего процедуру регистрации в системе	
Внедрение украденного значения хэша в базу данных SAM и такая модификация ОС Windows NT, в результате которой пользователь выглядит успешно прошед- шим процедуру регистрации в системе.	Исключение хранения базового секрета в ОС ОС Windows роль базового секрета играет хэш. Такая атака может быть сорвана, только если исключить хране- ние базового секрета внутри уязвимой операционной системы Windows. В рамках протоколов LANMAN и NTLM решения нет. Один из возможных подходов ис- пользуется в протоколе Kerberos
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
6.2.	Протокол Kerberos
Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную
аутентификацию пользователей.
Он может использовать централизованное хранение аутентификационных данных и
является основой для построения механизмов Single Sign-On (возможность одноразовой
аутентификации в нескольких приложениях). Протокол Kerberos предлагает механизм
взаимной аутентификации клиента и сервера перед устаноатением связи между ними с уче-
том того, что начальный обмен информацией между клиентом и сервером может проис-
ходить в незащищенной среде, а передаваемые пакеты — перехвачены и модифицированы.
Протокол Kerberos может использовать централизованное
хранение аутентификационных данных и является основой
для построения механизмов Single Sign-On.
Протокол основан на понятии ticket (билет, удостоверение, мандат). Ticket является
шифрованным пакетом данных, который выдан выделенным доверенным центром аутен-
тификации. В терминах протокола Kerberos — Key Distribution Center (KDC, центр рас-
пределения ключей).
Когда пользователь выполняет первичную аутентификацию, после успешного подтверж-
дения его подлинности KDC выдает первичное удостоверение пользователя для доступа
к сетевым ресурсам — Ticket Granting Ticket (TGT) В дальнейшем, при обращении к от-
дельным сетевым ресурсам пользователь, предъявляя TGT, получает от KDC удостове-
рение для доступа к конкретному сетевому ресурсу — Service Ticket
Протокол основан на понятии ticket, который является
зашифрованным пакетом данных, выданным центром
аутентификации.
Одним из преимуществ протокола Kerberos, обеспечивающим очень высокий уровень
сетевой безопасности, является то, что во всех сетевых взаимодействиях не передаются
ни пароли, ни значения хэша паролей в открытом виде. Все удостоверения являются
шифрованными пакетами данных.
Примером реализации протокола Kerberos служит доменная аутентификация пользо-
вателей в операционных системах компании Microsoft, начиная с Windows 2000.
6.2.1.	Архитектура, компоненты, участники протокола
В 1983 г. в МТИ (Массачусетском Технологическом институте) был начат проект
«Афина», целью которого было создание модели предполагаемой среды распределенных
вычислений следующего поколения для академических организации. Группа участников
проекта «Афина» решила задачу безопасности, связанную с KDC, на основе протокола
Нидхэма—Шредера, но с учетом результатов работы Деннинга и Сакко Чтобы обеспечить
работу протокола Kerberos в крупномасштабных средах, проект «Афина» должен был
предложить программное обеспечение для обработки процедуры регистрации на клиент-
ских рабочих станциях и адаптировать серверы для работы с протоколом Kerberos Про-
граммное обеспечение, адаптированное под работу с протоколом Kerberos, обычно на-
з ы ва ют керберезированным.
62
Гпава 6. Протоколы аутентификации в локальной сети
К 1989 г. Стив Миллер (Steve Miller) и Клиффорд Ньюмэнн (ClitTord Neumann) с по-
мощью других сотрудников МТИ сделали четыре версии протокола Kerberos. Версия 4
была первой выпущенной в общее пользование версией протокола, которая использу-
ется io сих пор. Однако стандартной версией для Internet-сообщества стала версия 5
Сервер аутентификации
Центр распределения ключей протокола Kerberos состоит из нескольких серверов,
которые выполняют различные функции Сервер аутентификации реализует протокол,
сходный с протоколом Нидхэма—Шредера. Теоретически этот сервер может выдавать
мандаты для обмена данными с любой керберезированнои службой. На практике боль-
шинство рабочих станций использует сервер аутентификации только в целях выдачи
мандатов для связи со службой выдачи разрешении на получение мандатов.
Чтобы получить мандат от сервера аутентификации, пользователь должен сконстру-
ировать сообщение KRBASREQ. Сервер аутентификации отвечает сообщением
KRB_AS_REP. которое содержит мандат и соответствующую статусную информацию.
Запрашивая мандат, он предоставляет данные о своей личности, имя сервера и случай-
ное одноразовое число. Протокол устанавливает временной период, в течение которого
булет действовать коллективно используемый ключ, называемый в протоколе Kerberos
ключом сеанса. Протокол также вводит в шифруемую по ключу часть идентификатор рабочей
станции, с помощью которого он может контролировать, каким рабочим станциям разре-
шено использовать конкретный мандат. Это снижает вероятность несанкционированного
использования мандата. Сервер аутентификации отвечает сообщением KRB_AS_REP,
которое содержит мандат и соответствующую статусную информацию.
Чтобы получить мандат от сервера аутентификации
пользователь должен сконструировать сообщение
KRB_AS_REQ. Сервер аутентификации отвечает сообщением
KRB_AS_REP, которое содержит мандат и соответствующую
статусную информацию.
Пользователь удостоверяется в правильности мандата, проверяя статусную информа-
цию, предоставляемую сервером в сообщении KRB_AS_REP. В частности, ему необхо-
димо проверить, что ответ содержит правильные имя сервера, случайное число и период
действия. После этого он может спокойно пользоваться мандатом и ключом сеанса для
связи с сервером.
Аутентификация для сервера
Пользователь использует мандат протокола Kerberos и соответствующий ключ сеанса
для создания сообщения KRB_AP_REQ. чтобы аутентифицировать себя, например,
почтовому серверу Кроме мандата, пользователь предоставляет еще и так называемый
аутентификатор протокола Kerberos, который представляет собой шифрованный эле-
мент данных, содержащий имя пользователя (Пользователь) и временною метку. Для
шифрования аутентификатора пользователь применяет тот же ключ сеанса, который
был в мандате (рис. 6.2).
Сервер дешифрует полученный мандат, извлекает из него ключ сеанса и использует
его для дешифровки аутентификатора. Имя пользователя в аутентификаторе должно
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
совпадать с именем пользователя в мандате, а временная метка должна быть не очень
старой — обычно в пределах последних пяти минут.
Если запрос проходит эти тесты, сервер посылает ответное сообщение KRBAP_REP
(если пользователь о нем просит) В этом ответе посылается временная метка из запроса,
шифрованная с использованием ключа сеанса. Как и в случае протокола Нидхэма—Шре-
дера, ответ имеет смысл, только если алгоритм шифрования не допускает выполнения
атак с помощью переписывания или редактирования методом вырезки и копирования.
Запрос от пользователя (сообщение протокола Ktuberos KRB_AS_REP)
Имя сервера	Период действия	Случайное число	Ключ сеанса
Ответ, посланный пользователю (сообщение протокола Ktuberos KRB_AS_REP)
Рис. 6.2. Аутентификация для сервера (табл. 6.2)
Таблица 6.2
Состав и наименование полей
//о w	Назначение
Имя пользователя	Клиент, который запрашивает мандат
Имя сервера	Нужная служба. Этот мандат шифруется с использованием мастер-ключа сервера
Период Действия	Время, когда мандат и соответствующий ему ключ сеанса начинают дейст- вовать, и время, когда ключ и мандат теряют свою дееспособность
Ключ ccd|ica	Секретный ключ, коллективно используемый сервером и пользователем
Рабочая станция	Идентификатор компьютера (или компьютеров), на котором «может» рабо- тать пользователь
Гпава 6. Протоколы аутентификации в локальной сети
Служба выдачи разрешений на получение мандата (рис. 6.3)
Хотя сервер аутентификации протокола Kerberos можно использовать для генерации
мандатов на работу с отдельной службой, однако проблема заключается в том, что прото-
кол Kerberos требует использования мастер-ключа для обработки сообщений, которыми
обменивается пользователь с сервером аутентификации, а большинство людей, работая на
компьютере, обычно используют множество служб. Если мастер-ключ хранится на рабо-
чей станции в то время, когда на ней кто-то работает, то существует риск его похищения.
Чтобы устранить эту проблему, мастер-ключом надо пользоваться как можно более
короткий промежуток времени и убирать его из рабочей станции как можно быстрее. Но
это приводит к другой проблеме: если мы стираем мастер-ключ после завершения под-
ключения к одному серверу, то нам надо прочитать его снова при попытке подключиться
к другому.
Традиционно в протоколе Kerberos в качестве мастер-ключей пользователей исполь-
зуются запоминаемые пароли, так что в этом случае придется мириться с бесконечными
запросами на ввод пароля. Ни одна из альтернатив не является практичной.
В протоколе Kerberos в качестве мастер-ключей
пользователей используются запоминаемые пароли.
Таким образом, возникает та же дилемма, которая привела к возникновению ключей
сеанса: нужно вводить временный ключ, который можно использовать для выдачи дру-
гих временных ключей. Действительно, проблема решается таким же образом: вместо
того чтобы оставлять мастер-ключ в рабочей станции во время регистрации пользова-
теля, вводится специальный ключ сеанса, который можно использовать для выпуска
мандатов. Здесь используется хорошо известная в вычислительной технике практика:
часто проблему можно решить, введя еще один уровень косвенности.
В протоколе Kerberos этот дополнительный временный ключ реализуется путем до-
бавления к серверу KDC специального сервера, называемого сервером выдачи разрешений
на получение мандатов. Этот сервер работает с мандатами, которые, конечно, называются
Рис. 6.3. Запрос серверу от пользователя (Сообщение протокола Kerberos KRB_AP_REQ)
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Запрос на
регистрацию
Пользователь
TG
TGT
База данных
секретных ключей
Служба \
аутентификации у
Ответ
почтового
сервера
Ключ мандата
Запрос почтовому
серверу, содержащий
разрешения
С Служба выдачи
разрешения
КОС
протокола
Kerberos
Мандат
почтового
сервера
Почтовый
сервер
Рис 6,4. Взаимодействие рабочей станции KDC протокола Kerberos и почтового сервера
разрешениями на получение мандатов (ticket-granting ticket, TGT). Пользователи могут по-
сылать свои TGT этому специальному серверу, чтобы запрашивать мандаты для других
служб.
В предыдущих примерах рассматривался случай установления Пользователем соеди-
нения с почтовым сервером через KDC (рис. 6.4). На практике Пользователь будет
устанавливать связь не только с почтовым сервером. Скорее всего, он, как обычно, под-
ключится к двум или более файл-серверам, одному или двум серверам печати, а также
к другим службам. Несомненно, рабочая станция пользователя будет подключаться к не-
которым из этих служб автоматически в момент его регистрации в системе Но могут
быть и другие службы, которые не входят в список регулярно используемых, или такие,
к которым нет смысла подключаться без необходимости.
Благодаря серверу выдачи разрешений на получение мандатов обеспечивается относи-
тельно безопасный и дружественный к пользователю механизм однократной регистрации.
Когда пользователь регистрируется на своей рабочей станции, она немедленно свя-
зывается с сервером аутентификации KDC протокола Kerberos и получает TGT. После
этого рабочая станция получает пароль пользователя (или другие данные аутентифика-
ции) и использует их для дешифровки ответа от сервера аутентификации.
Затем она пересылает TGT серверу выдачи разрешений на получение мандатов, чтобы
получить мандаты на доступ к службам. немедленно необходимым пользователю: к обычно
используемым им файл-серверам, почтовому серверу, серверу печати. Позднее рабочая
станция может снова обратиться к серверу выдачи разрешений за дополнительными
мандатами, если пользователю понадобятся дополнительные серверы Рабочей станции
больше не надо запрашивать у пользователя ввод пароля, так как для получения допол-
нительных мандатов она просто использует TGT и соответствующий ключ сеанса.
Гпава 6. Протоколы аутентификации в локальной сети
Сервер выдачи разрешении имеет собственный ключ, который используется протоколе
Kerberos для шифрования его мандатов Получив TGT, сервер дешифрует его и извл
кает ключ сеанса, который используется при выдаче мандатов пользователю и назыв
ется ключом для выдачи мандатов. Сервер использует ключ для выдачи мандатов, чтоб
дешифровать аутентификатор и проверить его достоверность. Сервер также сверяет п<
риод действия TGT с текущим временем Кроме того, он проверяет период действия, з;
прошенный рабочей станцией пользователя для нового мандата. На следующем эта!
сервер генерирует случайным образом ключ сеанса, который будет использоваться р;
бочей станцией пользователя и почтовым сервером.
Сервер выдачи разрешений имеет собственный клю
который используется протоколом Kerberos для шифрована
его мандатов
Сервер выдачи разрешений берет данные, подлежащие возврату пользователю,
шифрует их для доставки. Сначала сервер создает мандат почтового сервера и шифруй
его с помощью мастер-ключа почтового сервера. Затем группирует остальные данньп
необходимые ему для ответа, и шифрует их с использованием ключа для выдачи разре
шений пользователю. Оба блока шифрованных данных объединяются, формируя ответ
ное сообщение, которое сервер посылает пользователю.
Аутентификация пользователей и рабочих станций
Протоколы KDC, подобные протоколу Kerberos, в действительности уделяют основ
ное внимание аутентификации пользователей сетевым службам. Классические прото
колы слабо или вообще никак не обеспечивают установление личности пользователя дл
рабочей станции или даже KDC. Ничто не мешает кому угодно, включая взломщика, об
ратиться с запросом на получение мандатов для аутентификации конкретному серверу
Имея возможность устанавливать связь с KDC пользователя, любой может послать со
общение, заявляющее, что он — пользователь, и получить мандат для аутентификаци]
почтовому серверу. Рассматриваемые далее протоколы гарантируют невозможность ис
пользования взломщиками полученных ими мандатов.
Данная ситуация имеет два интересных следствия. Во-первых, это означает, что про
токол Kerberos не обязательно рассматривает сами рабочие станции как отдельные объ
екты, которые требуют аутентификации. Вместо этого подразумевается, что они явля
ются взаимозаменяемыми устройствами, как это и имеет место в среде академически
лабораторий. Во-вторых, у взломщиков есть возможность получить достаточное числ<
мандатов, относящихся к конкретному человеку, чтобы провести атаку на его мае
тер-ключ. К счастью, эти следствия можно устранить, используя некоторые варианте
реализации протокола Kerberos.
Аутентификация рабочих станций
Особенность протоколов КОС, рассмотренных в предыдущих разделах, состоит
том, что для обеспечения безопасности действий рабочей станции они используют одш
ключ. В отличие от протокола ОС Windows NT, рабочая станция не имеет отдельное
ключа для обмена данными с KDC или любой другой службой защиты. Поскольку в про
токоле Kerberos реализована модель непрямой аутентификации, сама рабочая станци
не может аутентифицировать отдельных пользователей. Она просто играет роль транс
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
портного средства, с помощью которого авторизованные пользователи манипулируют
ресурсами на серверах. Имея физический доступ, любой человек может воспользоваться
рабочей станцией, так как протокол Kerberos не обеспечивает аутентификации, ориен-
тированной на рабочую станцию.
Поскольку в протоколе Kerberos реализована модель
непрямой аутентификации, он не помогает самой рабочей
станции аутентифицировать отдельных пользователей
Реализованный в протоколе Kerberos подход отражает идеологию распределенных
вычислений с «тонким клиентом». Если клиентские рабочие станции просты и достаточно
однородны в сети, то они могут быть взаимозаменяемыми. Не имеет значения, какая ра-
бочая станция обслуживает пользователя; основной целью аутентификации является за-
прет использования не принадлежащих ему ресурсов.
Однако подобное видение не соответствует реальной практике, существующей в орга-
низациях. где преобладают персональные компьютеры на столах сотрудников В каждом
персональном компьютере имеются локальные файлы, принадлежащие конкретному
владельцу или хранителю. Во многих случаях на нем установлено программное обеспе-
чение, лицензированное на имя его владельца. Если протокол Kerberos будет аутенти-
фицировать любого на каждой рабочей станции, то он не позволит контролировать доступ
к таким персональным ресурсам. В подобных случаях рабочая станция должна иметь до-
полнительную процедуру аутентификации. Это может быть прямая аутентификация или
основанная на протоколе Kerberos предаутентификация, которая описывается ниже
в этом разделе. Компания Microsoft в ОС Windows 2000 использовала комбинацию этих
методик.
В случае мандатов протокола Kerberos риск состоит в том, что взломщики могут получить
достаточное число мандатов предназначаемых какому-нибудь важному пользователю,
чтобы провести успешную атаку на его мастер-ключ. В классической среде Kerberos это
является серьезной угрозой, так как основой персональных мастер-ключей служат за-
поминаемые пароли.
Предаутентификация
В протоколе Kerberos версии 5 была введена предаутентификация поэтому серверы
могли аутентифицировать запросы, посылаемые KDC, а не полагаться на аутентификацию
запросов, выполняемую ими потом. Администраторы могут сконфигурировать Kerberos
таким образом, что он будет требовать аутентификации при запросе мандатов или TGT.
При этом KDC осуществляют рассылку шифрованных данных только тем, кто уже знает
соответствующий ключ. Обычно процесс используется для аутентификации пользова-
теля, получающего от KDC начальный TGT, хотя протокол способен поддерживать ши-
рокий набор альтернатив. Начальная предаутентификация должна быть доступна в виде
опции в любой совместимой версии протокола Kerberos.
При традиционной Kerberos-аутентификации рабочая станция получает ключи от KDC
до того, как ей нужен мастер-ключ пользователя. Так как в протоколе Kerberos в качестве
мастер-ключа обычно используются пароли пользователей, то рабочая станция может
отложить запрос пароля до момента получения отклика от KDC. В случае предаутенти-
фикации рабочая станция должна сначала получить мастер-ключ пользователя, что
обычно означает получение пароля.
Глава 6. Протоколы аутентификации в локальной сети
Рабочая станция посылает начальный запрос KDC, который обычно является зап]
сом TGT Для предаутентификации рабочая станция добавляет специально сформа'
рованную шифрованную временную метку. Временная метка включает в себя текуи
время суток и одностороннее хэшированное значение остальной части KDC-запро
шифрованное с помощью мастер-ключа пользователя.
Получив запрос, KDC проверяет, требуется ли предаутентификация и если это т
отвергает запрос в случае отсутствия метки. Если предаутентификационная времен!
метка присутствует, то KDC ищет мастер-ключ пользователя и использует его для ,
шифрования временной метки. Если время суток во временной метке приемлемо, К1
вычисляет одностороннее хэшированное значение остальной части запроса и сравни
ет его с хэшем из временной метки. Если они совпадают, KDC удовлетворяет запро
Заметим, что рабочая станция может рассматривать ответ KDC в качестве подтвер
дения личности пользователя. KDC пошлет законное ответное сообщение, а не со<
щение об ошибке, только в том случае, если предаутентификация прошла успешно. I
бочая станция может дешифровать ответ KDC и проверить, содержит ли он правили
значение случайного числа имени сервера и периода действия. В противном случае ।
бочая станция может сделать вывод, что пользователь пытается (безуспешно) выдать
бя за кого-нибудь другого.
Табшць
Возможные атаки на Kerberos и защита от них
Описание атаки	Защита от данной атаки
Повторное воспроизведение со старыми ключами	
Маскировка под другого человека Взломщик посылает серверу ранее выпу- щенный мандат и воспроизводит послан- ные клиентом ранее сообщения, шифро- ванные с помощью этого ключа.	Механизм «запрос—ответ» в работе протокола KD с сервером Сервер посылает пользователю запрос который т] бует ответа, зависящего от данных пользователя, шг рованных с помощью ключа сеанса
Автономный взлом и воспроизведение	
Атакующая сторона в автономном режиме взламывает ключ сеанса и использует полу- ченные сведения для повторного использо- вания мандата, выпущенного с этим ключом.	Временная метка в протоколе KDC Сообщения KDC включают информацию о време! суток, что позволят обнаруживать попытки повтор! го использования мандатов.
Автономный взлом мастер-ключа	
Атакующая сторона запрашивает мандаты от имени жертвы и использует их для взло- ма мастер-ключа жертвы грубой силой.	Предаутентификация в KDC При запросе TGT пользователь должен предоставлю личную аутентификационную информацию.
Поддельное изменение времени	
Взломщик посылает серверу запрос с под- дельным временем суток, так что недействи- тельные мандаты становятся действующими.	Аутентифицируемые сообщения о времени Сообщения, которые изменяют время на системн часах сервера, должны аутентифицироваться.
Восстановление или модификация закрытых данных	
Взломщик перехватывает запрос клиента К DC и возвращает другой набор ключей, которые ему неизвестны.	Случайное разовое число, ко иективно испо 1ьзуемое с Л Случайное число включается в запросы, посылаем в KDC, и в ответы.
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
6.2.2.	Возможные атаки
Фундаментальной особенностью философии протокола Kerberos является четкое пони-
мание, что находящиеся в сети компьютеры рано или поздно будут успешно атакованы
(табл. 6.3). Это должно быть очевидным, так как в протоколе Kerberos в качестве базовых
секретов служат пароли многократного использования. Конструкция Kerberos создава-
лась в попытке минимизировать общесистемные последствия вторжения на отдельные
рабочие станции и серверы. Общая безопасность сервера, использующего протокол Ker-
beros. также основывается на предположении, что системные часы всех участвующих
в обмене данными компьютеров хотя бы грубо, но синхронизированы. Протокол Kerberos
будет выполнять свои защитные функции до тех пор, пока эти условия выполняются.
6.2.3.	Реализация протокола Kerberos
в ОС Windows 2000 и последующих ОС
Начиная с ОС Windows 2000, компания Microsoft заменила механизм доменной аутен-
тификации ОС Windows NT, основанный на NTLM, на протокол Kerberos. Процедура
доменной регистрации Windows превратилась в транзакцию, результатом которой явля-
ется получение TGT. Отображение на файл-сервер теперь связано с обменом мандатами
и ключами сеанса. Мастер-ключи и другая важная с точки зрения защиты информация
хранятся в так называемой активной директории. Хотя реализация протокола Kerberos
в ОС Windows имеет ряд отличительных элементов, компания Microsoft заявляет, что ее
вариант будет удовлетворять всем требованиям совместимости со стандартным протоко-
лом Kerberos. В частности, керберезированные He-Windows-приложения будут способны
обрабатывать мандаты Windows, обеспечивая возможность однократной регистрации
между Windows- и He-Windows-приложениями.
Благодаря протоколу Kerberos ОС Windows 2000 и последующие ОС по сравнению
с более ранними продуктами семейства Windows имеют три существенных преимущества:
1.	Обеспечивается более быстрая аутентификация на сервере, так как серверу не надо
связываться с контроллером домена для непрямой аутентификации. Вместо этого сервер
просто обрабатывает мандат.
2.	Windows использует функции делегирования мандатов для передачи прав доступа
пользователя к серверу посредством другого сервера
3.	Windows использует протоколы Kerberos, которые позволяют центрам распростране-
ния ключей, принадлежащим другим организациям, выдавать права доступа пользова-
телям, работающим через другие центры распределения ключей контролируемым образом.
Мастер-ключи и аутентификация рабочих станций
Конечно, при вводе технологии Kerberos в продуктовую линию Windows неизбежны до-
работки. Компании Microsoft надо было придерживаться основной линии, чтобы сохранить
совместимость с существующими продуктами и одновременно извлечь хотя бы некоторые
преимущества из защитных функций протокола Kerberos Это особенно заметно в том, как
Microsoft адаптировала Kerberos к процессу регистрации в рабочей станции ОС Windows
Как и предполагается, пользователь рабочей станции не видит ничего нового. Когда
пользователь пытается зарегистрироваться, он нажимает на клавиатуре обычные клавиши
и видит на экране паролевый диалог. Он вводит свое имя пользователя, выбирает домен
и набирает на клавиатуре пароль. Но на системном уровне Windows преобразует все это
в транзакции протокола Kerberos.
70
Гпава 6. Протоколы аутентификации в локальной сети
Пользователь
Winlogon
1. Регистрация
пользователь:
«Пользователь»
пароль: asdt
2. Регистрация /
пользователь: 1
• Пользователь»
ключ: 32F89C
Ресурсы
станции bat
/ Служба локальной
(защиты на станции bat
5. Предоставление
мандата пользователь:
• Пользователь»
для станции bat
Мастер-ключ
станции bat
KDS домена
4. Извлечение TGT
для пользователя
«Пользователь»
erberos
SSP
4. Использование
мандата
пользователь:
«Пользователь»
для станции bat
Рис. 6.5. Процесс входа в систему
Существенным отличием реализации протокола Kerberos в ОС Windows от традици-
онного варианта является то, что в ОС Windows рабочие станции рассматриваются как
различные объекты. Каждая рабочая станция имеет в ареале свои особенности и собст-
венный мастер-ключ, отличный от мастер-ключа регистрирующегося пользователя. Если,
например, пользователь назвал свою рабочую станцию bat, то это будет ее имя внутри
домена (рис. 6.5). Процесс регистрации в дополнение к другим мандатам, которые могут
понадобиться, также организует получение мандата для аутентификации пользователя
рабочей станции.
В ОС Windows 2000 и выше процесс входа в систему распределяется между тремя
основными процессами: процессом Winlogon, который подсказывает пользователю
о необходимости ввода его «имени пользователя» и пароля, процессом провайдера под-
держки защиты Security Support Provider (SSP), который осуществляет связь с протоколом
Kerberos, и процессом службы локальной защиты Local Security Authority (LSA), который
защищает станцию.
Процессы протекают следующим образом:
•	Получив аутентификационные данные пользователя, процесс Winlogon передает
их процессу LSA.
•	Процесс LSA путем хэширования преобразует пароль в мастер-ключ, который должен
будет использоваться протоколом Kerberos.
В ОС Windows 2000 процесс входа в систему распределяется
между тремя основными процессами: процессом
Winlogon, процессом провайдера поддержки защиты Security
Support Provider (SSP), процессом службы локальной защиты
Local Security Authority (LSA)
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
•	Затем LSA инициирует SSP-процесс протокола Kerberos и передает ему имя поль-
зователя и мастер-ключ. В отличие от традиционного протокола Kerberos, в ОС
Windows 2000 мастер-ключ оставляется в кэше. Это позволяет рабочей станции
использовать механизм доменной аутентификации ОС Windows NT, если необхо-
димо обмениваться данными с более старыми серверами. Очевидно, что держать
такую информацию в кэше — это риск, причем совершенно ненужный, если во
всей организации используется механизм аутентификации протокола Kerberos.
•	Процесс SSP протокола Kerberos пытается связаться со своим контроллером до-
мена и получить начальный TGT на имя пользователя. Запрос использует пред-
аутентификацию, основанную на мастер-ключе пользователя.
•	Если выбранный домен управляется более старым Windows NT-сервером и про-
токол Kerberos недоступен, то процесс LSA выполняет откат и использует
N LTM - протокол.
•	Если процесс SSP получает свой TGT протокола Kerberos, то он использует его
для получения мандата для рабочей станции bat от имени пользователя. Получив
мандат для рабочей станции, процесс SSP обеспечивает получение мандата для
процесса LSA, который использует мастер-ключ станции bat для ее аутентифика-
ции. Если ключ аутентичен, то процесс LSA регистрирует пользователя в стан-
ции bat.
Избыточный шаг получения мандата для самой рабочей станции является необычной
особенностью в сравнении с другими Kerberos-средами. Ключ сеанса в мандате не служит
реальной цели. Этот подход в ОС Windows 2000 используется из-за того, что KDC хранит
полномочия пользователя в каждом мандате, и это относительно ясный и непротиворе-
чивый способ получения списка полномочий пользователя от KDC. Каждый мандат со-
держит авторизационную информацию и другие полномочия, необходимые для связы-
вания пользователя с нужными ресурсами рабочей станции и правами доступа к ним.
Процесс LSA на Windows-сервере работает таким же образом: он извлекает из мандата
пользователя данные о полномочиях и использует их для запуска серверного процесса
от имени и с разрешениями этого пользователя. На рабочей станции же процесс LSA
обеспечивает работу приложений с именем этого пользователя.
Поддерживаемые службы и протоколы
Службы и протоколы, которые в ОС Windows 2000 используют механизм аутентифи-
кации протокола Kerberos:
•	файловые службы, включая службы доступа к файлам в Интернете и службы обмена
с серверами (CIFS/SMB), а также службы системы управления распределенной
файловой системой;
•	службы вывода на печать;
•	аутентификация Web-сервера информационному Интернет-серверу;
•	службы аутентифицируемых вызовов удаленных процедур для удаленного управле-
ния серверами и рабочими станциями;
•	запросы в активную директорию с использованием облегченного протокола до-
ступа к директории (Lightweight Directory Access Protocol, LDAP);
•	аутентификация для конфигурирования шифрованного канала связи хост-хост
с использованием протокола IPSEC;
•	аутентификация запросов об уровнях качества обслуживания.
Гпава 6. Протоколы аутентификации в локальной сети
6.3. Протокол Kerberos + PKINIT
6.3.1. Архитектура, компоненты, участники протокола
Сертификаты в протоколе Kerberos
Существуют способы интеграции шифрования на основе открытого ключа в прот<
Kerberos. Хотя эти методы не обязательно преобразовывают среду Kerberos в архитек
с истинно автономной аутентификацией (процесс всегда будет зависеть от присутс
KDC протокола Kerberos), они исключают необходимость в коллективно используе
секрете, основанном на пароле многократного применения.
Рассмотрим методику, называемую PKINIT (public key initialization — инициализг
открытого ключа). PKINIT (рис. 6 6) использует пару закрытого и открытого ключа п
зователя в специальной версии процесса предаутентификации. Пользователь регистр
ется в своей рабочей станции и предоставляет личный ключ. Рабочая станция связыва
с KDC, посылая предаутентификационныи запрос на получение TGT-мандата. В зап
содержится обычная информация и копия сертификата открытого ключа пользован
Запрос подписывается цифровой подписью, получаемой с помощью его личного кл
PKINIT использует пару закрытого и открытого кг
пользователя в специальной версии прощ
предаутентифика
Получив запрос, KDC сначала пытается проверить достоверность сертификата п
зователя. Он должен быть выпущен органом, известным KDC, иначе он будет отвер]
Затем KDC генерирует TGT для пользователя и шифрует соответствующий ключ се
с использованием открытого ключа пользователя. После этого ответ подписывается с
мощью собственного ключа KDC, так что пользователь имеет возможность после п
чения проверить его целостность. После того как пользователь дешифрует ключ сеанс
может использовать его вместе с TGT для аутентификации себя другим серверам. Лич
ключ ему не понадобится до следующей регистрации в системе.
Это не единственный способ использования методики PKINIT. Также ее можно йен
зовать для генерации коллективно используемого секрета временными ключами а
ритма Диффи—Хеллмана. В этом случае предаутентификационный запрос пользова
содержит временный ключ Диффи—Хеллмана. По-прежнему пользователь должен
Рис. 6.6. Методика PKINIT (Public Key Initialization)
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
писать запрос отдельным ключом и предоставить копию сертификата ключа его подписи.
Перед генерацией TGT с помощью коллективного секрета Диффи—Хеллмана KDC ве-
рифицирует сертификат и подпись пользователя на основе данных предаутентификации.
Метод PKINIT обладает важным свойством: он может исключить KDC из процесса
аутентификации, полностью полагаясь на сертификаты пользователей. Ответственность
за верификацию личности пользователя несет тот орган, который выпустил сертификат.
Приняв сертификат, протокол KDC фактически аутентифицировал соответствующего
пользователя. По этой причине KDC должен скрупулезно проверять сертификаты и вы-
давать мандаты только в том случае, если сертификат признается им без оговорок.
В ОС Windows метод PKINIT используется для интеграции открытых ключей в свою
среду аутентификации на основе протокола Kerberos. Запрос TGT содержит копию сер-
тификата пользователя и подписывается с помощью его личного ключа. Протокол KDC
ОС Windows 2000 подтверждает достоверность сертификата и факт его выдачи органом,
который ему известен. После этого KDC верифицирует временную метку процесса пред-
аутентификации и цифровую подпись.
В ОС Windows метод PKINIT используется для интеграции
открытых ключей в свою среду аутентификации на основе
протокола Kerberos.
Проверив достоверность предаутентификационных данных, KDC строит TGT, вклю-
чающий специфические для ОС Windows 2000 авторизационные данные — идентифика-
торы пользователя и группы, к которой он относится. После этого KDC шифрует ответ
с помощью открытого ключа из сертификата пользователя и подписывает его собственным
ключом. Получив ответ, система пользователя дешифрует и верифицирует его и затем, как
того требует протокол Kerberos, использует TGT для запроса доступа к другим серверам.
Использование смарт-карт и USB-ключей
Для получения доступа к сертификатам пользователя на этапе аутентификации
в систему и для хранения закрытых ключей пользователей для связки Kerberos+ PKINIT
в ОС Windows 2000 используются смарт-карты и USB-ключи. Служба управления ре-
сурсами смарт-карт была интегрирована в операционную систему, и для настройки аутен-
тификации по сертификатам достаточно активизировать данную службу, установив
драйверы считывателей смарт-карт. При нахождении в домене графический интерфейс
ОС Windows 2000 (GINA) заменяется вариантом с поддержкой работы со смарт-картами.
На смарт-карту записывается сертификат и связанный с ним закрытый ключ, выписан-
ные на доменном центре сертификации с использованием политик, предусматривающих
возможность его использования для интерактивной аутентификации пользователя
в системе.
При подключении смарт-карты к рабочей станции для аутентификации пользователя,
хранящийся на ней сертификат используется для запроса TGT. а операция с закрытым
ключом, возможная после ввода PIN-кода, используется для подписания этого запроса.
На смарт-карту записывается сертификат и связанный с ним
закрытый ключ
Гпава 6. Протоколы аутентификации в локальной сети
6.3.2. Возможности использования
российских криптографических алгоритмов
Процесс аутентификации в протоколе Kerberos состоит из двух этапов: начг
аутентификация субъекта и последующая аутентификация сервисов. Для решение
чи начальной аутентификации широко используется технология PKINIT, пос колы
позволяет использовать сертификат открытого ключа вместо пароля.
Для решения задачи начальной аутентифи
используется технология Р
Начальная аутентификация осуществляется путем отправки CMS (Cryptog
Message Syntax)-сообщения. При этом используются следующие криптографическ
горитмы:
•	формирования/проверки подписи (алгоритм ГОСТ Р 34.10—94 или
Р 34.10-2001);
•	шифрования/дешифрования информации (алгоритм ГОСТ 28147—89);
•	контроля целостности передаваемой информации (ключевой хэш на базе
ритма хэширования ГОСТ Р 34.11-94):
•	обмена ключей (с использованием алгоритма Диффи—Хеллмана на базе алг
мов ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001).
Подробное описание специфики формирования CMS сообщения на базе россш
криптографических алгоритмов приводится в утвержденном и опубликованном »
тетом IETF стандарте RFC 4490 [CPCMS].
Связь документа с международными стандартами показаны на рис. 6.7.
Рис. 6.7. RFC 4490 и международные стандарты
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
6.3.3. Возможные атаки (табл. 6.4)
Таблица 6.4
Возможные атаки на Kerberos + PKINIT и методы защиты от них
Описание атаки	Защита от данной атаки
Подделка открытого ключа	
Если получатель принимает неаутен- тифицированный ключ, то взломщик просто подставляет свой собственный ключ вместо правильного ключа.	Сертификаты открытого ключа Публикуется назначение открытого ключа владельцу, и под этой публикацией ставится заслуживающая доверия циф- ровая подпись.
Человек посередине	
Взломщик представляет собственный открытый ключ вместо другого ключа и заново шифрует сообщения между двумя объектами.	Сертификаты открытого ключа Публикуется назначение открытого ключа владельцу, и под этой публикацией ставится заслуживающая доверия циф- ровая подпись.
Фиктивное имя в сертификате	
Взломщик ставит имя жертвы в заявке на получение сертификата открытого ключа.	Требование владения ключом Сертификаты выдаются только лицу, которое владеет запро- шенным именем.
Подмена сертификата	
Взломщик использует законный серти- фикат для реализации протокола SSL на поддельном сервере который вы- дает себя за другой сервер.	Проверка достоверности имени хоста в сертификате Имя в сертификате сравнивается с именем хост-машины, участвующей в SSL-соединении.
Использование личного ключа	
Взломщик полагается на автономную аутентификацию и использует укра- денный личный ключ.	Список аннулированных сертификатов Периодически выпускается список всех сертификатов, ко- торые были аннулированы. Интерактивный отзыв сертификатов Обеспечивается механизм выполнения запроса органа по выдаче сертификатов для подтверждения того, что сертифи- кат не был аннулирован. Периодическая выдача сертификатов Выдвигается требование, чтобы все сертификаты были вы- даны недавно, и обеспечивается механизм, который позво- лял бы сертифицирующим органам выпускать такие серти- фикаты. если сертификат не был аннулирован
Контрольные вопросы
1.	Назовите основные особенности протоколов LAN Manager и NT LAN Manager.
2.	Назовите типы аутентификации в NTLM.
3.	Приведите примеры атак на системы, использующие аутентификацию с помощью
протоколов LANMAN и NTLM, и защиты от них.
4.	Перечислите преимущества протокола Kerberos
5.	Опишите функции сервера аутентификации, входящего в состав центра распреде-
ления ключей протокола Kerberos.
6.	Приведите примеры атак на Kerberos и способы защиты от них.
7.	Перечислите преимущества реализации протокола Kerberos в ОС Windows 2000 и
последующих ОС в сравнении с более ранними продуктами семейства Windows.
8.	Приведите пример способа интеграции шифрования в протокол Kerberos.
9.	Возможные атаки на Kerberos + PKINIT и методы защиты от них?
Глава 7
МЕХАНИЗМЫ АУТЕНТИФИКАЦИИ
ПРИ ОСУЩЕСТВЛЕНИИ ПОДКЛЮЧЕНИЙ
В настоящее время методы использования паролей по-прежнему применяются ши-
роко. Механизмы аутентификации по протоколу Point-to-Point Protocol (PPP) часто ис-
пользуются в среде модемного доступа и включают протоколы Password Authentication
Protocol (PAP), Challenge Handshake Protocol (CHAP) и Extensible Authentication Protocol
(EAP). Разработка протокола EAP продолжается, но уже сейчас он использует сущест-
вующие и только появляющиеся технологии аутентификации в каналах РРР. Протоколы
TACACS+ и Remote Access Dial-In User Service (RADIUS) поддерживают масштабируе-
мые решения в области аутентификации.
Все протоколы рассмотрены ниже на примерах, в которых при аутентификации взаи-
модействуют два или более типовых устройств. Инициатором процесса, как правило,
выступает устройство маршрутизатор отделения (назовем его Twiggi). которое обращается
к серверу сетевого доступа (или NAS) Последний выполняет аутентификацию маршрути-
затора Twiggi и принимает решение. Мы будем называть его аутентификатором, а марш-
рутизатор Twiggi — аутентифицируемым устройством.
7.1.	Протокол PPP РАР
Аутентификация с помощью протокола РАР выполняется следующим образом (рис. 7.1).
I.	Инициатор аутентификации, в нашем примере маршрутизатор отделения Twiggi.
обращается к серверу сетевого доступа и устанавливает с ним связь.
2.	После установления связи маршрутизатор передает пару «имя устройства—пароль»
серверу NAS до тех пор, пока аутентификация не будет завершена или пока связь не пре-
рвется.
3.	После успешной аутентификации маршрутизатор отделения Twiggi получает под-
тверждение.
Протокол РАР не является сильным аутентификационным методом. Он аутентифици-
рует только вызывающего оператора, а пароли пересылаются по каналу, который счи-
тается уже «защищенным». Таким образом, этот метод не дает защиты от использования
чужих паролей и неоднократных попыток подбора пароля. Частота и количество неудач-
ных попыток входа в сеть контролируются на уровне вызывающего оператора.
NAS
Маршрутизатор
отделения Twiggy
(Twiggy, LetMelm)
Посылка подтверждения
ID Password
Twiggy LetMelm
Сравнение
имени и пароля
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
7.2. Протокол PPP CHAP
CHAP используется для периодической аутентификации центрального компьютера
или конечного пользователя с помощью согласования по трем параметрам. Аутентифика-
ция происходит в момент установления связи, но может быть повторена и после ее уста-
новления.
Аутентификация с помощью протокола CHAP проходит следующим образом (рис. 7.2):
1. Маршрутизатор отделения Twiggi устанавливает связь с сервером сетевого доступа
(NAS). CHAP обеспечивает безопасность сети, требуя от операторов обмена «текстовым
секретом». Этот секретный ключ никогда не передается по каналу связи.
Маршрутизатор и сервер доступа
используют общий секретный ключ «trustme»
Маршрутизатор
отделения	NIAC Name: Password ** “Twiggy”	, Twiggy trustme	'	T imbukt^' Установление соединения ф	* -		(D Запрос (ID, случайное число, Timbuktu) (5) Секретный ключ Timbuktu ID и случайное число 1 ^(эш-функци^ 1 Хэш [BADFOOD] Ответ на запрос (BADFOOD, Twiggy) ©	► ф Сообщение об успешной идентификации 	— 6	е Name: Password Twiggy trustme Секретный ключ Twiggy ID и случайное число 1 ^Сэш-функци^ 1 Хэш [BADFOOD] Если значения совпадают, то идентификация успешна
Глава 7. Механизмы аутентификации при осуществлении подключений
2	После установления связи аутентификатор передает вызывающему устройству за-
111 юс который состоит из имени устройства (или его ID), случайного числа и дополнитель-
н атрибутов, например имени центрального сервера (при аутентификации в локаль-
1Ц*и сети) или имени пользователя (при удаленной аутентификации).
3	Вызывающее устройство проводит вычисления с помощью хэш-функции Имя уст-
ройства, случайное число и общий «текстовый секрет» один за другим подаются на вход
х иц-функции После этого вызывающее устройство отправляет серверу ответ, который
состоит из значения хэш-функции и имени центрального сервера (при аутентификации
в локальной сети) или имени пользователя (при удаленной аутентификации).
4	. При получении ответа аутентификатор проверяет поставленное в ответе имя и вы-
полняет ге же вычисления.
5	. Затем результат этих вычислении сравнивается с величиной, поставленной в ответе.
гъли эти величины совпадают, аутентификация считается успешной, система выдает со-
ответствующее уве юмление и устанавливает связь.
Секретные пароли на локальном и удаленном устройстве должны быть идентичны.
Поскольку «текстовый секрет» никогда не передается по каналам связи, никто не может
подслушать его с помощью каких-либо устройств и использовать для нелегального входа
в систему. Пока сервер не получит адекватный ответ, удаленное устройство не сможет
подключиться к местному устройству.
CHAP обеспечивает защиту от использования чужих паролей за счет пошаговых изме-
нений аутентификатора и применения переменной величины запроса. Повторяющиеся
запросы предназначены для ограничения времени, в течение которого система теорети-
чески остается подверженной любой отдельной хакерской атаке. Частоту и количество
неудачных попыток входа в систему контролирует аутентификатор.
CHAP обеспечивает защиту от использования чужих паролей
за счет пошаговых изменений аутентификатора и
применения1 переменной величины запроса.
примечание
Обычно в качестве односторонней хэш-функции CHAP используется MD5, а общий
с/крет хранится в текстовой форме. У компании Microsoft есть свой вариант протокола
С пдр (MS-CHAP), где пароль (на вызывающей машине и на аутентификаторе) хранится
в шифрованном виде. Это дает протоколу MS-CHAP некоторое преимущество. В отли-
ч,1е от стандартного протокола CHAP он может использовать доступные базы данных
и/Ифрованных паролей.
7-3. Протокол PPP ЕАР
тот общий протокол аутентификации РРР поддерживает множество аутентифика-
ц Нных механизмов. ЕАР не выбирает конкретный аутентификационный механизм на
э е к°йтроля соединения и откладывает этот выбор до аутентификации. Такой сценарий
ПР воляет аутентификатору запросить больше информа ции до определения конкретного
а' ентиФикационного механизма. Кроме того, это лает возможность использовать
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
«внутренний» сервер, который реально запускает различные механизмы, тогда как
аутентификатор РРР служит лишь для обмена аутентификационными данными.
Аутентификация с помощью протокола ЕАР проходит следующим образом (рис. 7.3):
1.	Маршрутизатор отделения Twiggi начинает аутентификацию, устанавливая связь
с сервером сетевого доступа NAS (далее аутентификатором).
2.	После установления связи аутентификатор отправляет один или несколько запросов
для аутентификации вызывающего его устройства (маршрутизатора Twiggi). В запросе
имеется поле, где указано, что именно запрашивается. Так, например, здесь можно ука-
зать такие типы запросов, как аутентификация MD5, аутентификация с помощью сер-
тификатов Х.509, одноразовых паролей и т. д. При этом запрос типа MD5 сходен с про-
токолом аутентификации CHAP.
3.	Как правило, аутентификатор отправляет первоначальный аутентификационный
запрос, за которым следуют один или несколько дополнительных запросов о предостав-
лении аутентификационной информации. При этом первоначальный запрос не является
обязательным и может опускаться в случаях, когда аутентификация обеспечивается иными
способами (при связи по выделенным каналам, выделенным номерам и т. д.). В этих слу-
чаях вызывающая сторона отправляет пакет ответных данных на каждый запрос. Как и
пакет запроса, пакет ответных данных содержит поле, соответствующее полю запроса.
4.	Аутентификатор завершает процесс отправлением пакета, который свидетельству-
ет об успешной или неуспешной аутентификации.
NAS
Timbuktu
Маршрутизатор
Twiggy
Установление соединения
Запрос о методе идентификации
Запрос о на идентификацию
Ответ
Ответ на идентификационный запрос
Информация об успешной/неуспешнои идентификации
Рис. 7.3. Аутентификация с помощью протокола ЕАР
Гпава 7 Механизмы аутентификации при осуществлении подключений
7.4.	Протокол TACACS+
TACACS+ является протоколом последнего поколения из серии протоколов TACACS.
TACACS — это простой протокол управления доступом, основанный на стандартах User
Datagram Protocol (UDP), разработанных Bolt, Beranek, and Newman, Inc. (BBN) для
Military Network (MILNET) Компания Cisco несколько раз совершенствовала и расши-
ряла протокол TACACS, и в результате появилась ее собственная версия TACACS, из-
вестная как TACACS+.
TACACS — это протокол управления доступом, основанный
на стандартах User Datagram Protocol (UDP).
TACACS+ пользуется транспортным протоколом TCP. Модуль-демон (процесс, за-
пускаемый на машине UNIX или NT) сервера «слушает» порт 49, который является пор-
том протокола IP, выделенным для протокола TACACS. Этот порт зарезервирован для
выделенных номеров RFC в протоколах UDP и TCP Все текущие версии TACACS и рас-
ширенные варианты этого протокола используют порт 49.
Протокол TACACS+ работает по технологии клиент/сервер, где клиентом TACACS+
обычно является NAS, а сервером TACACS+, как правило, считается «демон» (т. е. про-
цесс, запускаемый на машине UNIX или NT). Фундаментальным структурным компо-
нентом протокола TACACS+ является разделение аутентификации, авторизации и учета
(AAA — Authentication, Authorization, Accounting). Это позволяет обмениваться аутенти-
фикационными сообщениями любой длины и содержания, и, следовательно, использо-
вать для клиентов TACACS+ любой аутентификационный механизм, в том числе РРР
PAP, PPP CHAP и Kerberos. Аутентификация не является обязательной. Она рассмат-
ривается как опция, которая конфигурируется на месте. В некоторых местах она вообще
не требуется, в других местах она может применяться лишь для ограниченного набора
услуг.
Обычно аутентификация предшествует авторизации, однако это не обязательно.
В запросе на авторизацию можно указать, что аутентификация пользователя не прове-
дена (личность пользователя не подтверждена). В этом случае лицо, отвечающее за авто-
ризацию, должно самостоятельно решить, допускать такого пользователя к запрашивае-
мым услугам или нет. Протокол TACACS+ допускает только успешную или неуспешную
авторизацию, однако этот результат допускает настройку на потребности конкретного
заказчика. Авторизация может проводиться на разных этапах, например, когда пользо-
ватель впервые входит в сеть и хочет открыть графический интерфейс или когда поль-
зователь запускает РРР и пытается использовать поверх РРР протокол IP с конкретным
адресом 1Р. В этих случаях «демон» сервера TACACS+ может разрешить предоставление
услуг, но наложить ограничения по времени или потребовать список доступа IP для ка-
нала РРР.
Учет представляет собой запись действий пользователя и обычно следует за аутен-
тификацией и авторизацией. В системе TACACS+ учет может выполнять две задачи:
1)	учитывать использованные услуги (например, выставление счетов);
2)	обеспечивать безопасность. Для этого TACACS+ поддерживает три типа учетных
записей. Записи «старт» указывают, что услуга должна быть запущена. Записи «стоп» говорят
о том, что услуга только что окончилась. Записи «обновление» (update) являются про-
межуточными и указывают на то, что услуга все еще предоставляется. Учетные записи
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
зашифрованный пакет серверу TACACS+
инициирует соединение
РРР с сервером доступа
5. Сервер TACACS+ сообщает
результаты идентификации
2. Сервер доступа
запрашивает у пользователя
имя и пароль
6 Клиент и сервер обмениваются
авторизационной информацией
3. Пользователь
отвечает на запрос
7. Клиент TACACS+
обрабатывает параметры, полученные
во время авторизации
Рис. 7.4. Взаимодействие пользователя, клиента и сервера TACACS+
TACACS+ содержат всю информацию, которая используется в ходе авторизации, а также
другие данные, например, время начала и окончания (если это необходимо) и данные
об использовании ресурсов.
Транзакции между клиентом TACACS+ и сервером TACACS+ идентифицируются
с помощью общего «секрета», который никогда не передается по каналам связи. Обычно
этот секретный ключ вручную устанавливается на сервере и на клиенте. TACACS+ можно
настроить на шифрование всего трафика, который передается между клиентом TACACS+
и демоном сервера TACACS+.
Взаимодействие между пользователем, с одной стороны, и клиентом и сервером
TACACS+, с другой, происходит так, как показано на рис. 7.4.
В ходе аутентификации TACACS+ используются пакеты трех типов: START,
CONTINUE и REPLY. START и CONTINUE всегда отправляются клиентом a REPLY —
сервером.
Аутентификация начинается, когда клиент отправляет серверу сообщение START,
которая описывает тип будущей аутентификации и может содержать имя пользователя
и некоторые аутентификационные данные. Пакет START отправляется только в каче-
стве первого сообщения аутентификационной сессии TACACS+ или сразу же после по-
вторного запуска этой сессии. (Повторный запуск может проводиться по просьбе сер-
вера, которая содержится в пакете REPLY). Пакет START всегда имеет порядковый но-
мер, равный единице.
В ответ на пакет START сервер отправляет пакет REPLY. Сообщение REPLY указы-
вает. завершилась ли аутентификация или ее следует продолжить. Если пакет REPLY
требует продолжения аутентификации, он также указывает, какую дополнительную ин-
Гпава 7 Механизмы аутентификации при осуществлении подключений
Username
Сервер доступа
Password = foopass
PASS/FAIL
Рис. 7.5. Аутентификация по протоколу TACACS+
Final status
формацию ему нужно предоставить. Клиент собирает эту информацию и отправляет €
серверу в сообщении CONTINUE.
После аутентификации клиент может начать процесс авторизации (если она треб}
ется). Сессия авторизации состоит из двух сообщений: сообщения REQUEST (запрос
и следующего за ним сообщения RESPONSE (ответ) Сообщение REQUEST содержг
фиксированное число полей, которые описывают пользователя или процесс, и перемег
ный набор аргументов, которые описывают услуги и опции, требующие авторизации.
Аутентификация по протоколу TACACS+ происходит так, как показано на рис. 7.
Авторизация TACACS+ показана на рис. 7.6.
Сервер
доступа
START
• Пакеты содержат пары «атрибут-значение»
• Эти пары определяют авторизационные
параметры пользователя
Рис. 7.6. Авторизация по протоколу TACACS+
Сервер
безопасности
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
7.5.	Протокол RADIUS
Протокол RADIUS был разработан компанией Livingston Enterprises, Inc., в качестве
протокола аутентификации серверного доступа и учета. В июне 1996 года, пятый проект-
ный вариант протокола RADIUS был представлен на рассмотрение IETF. В настоящее
время спецификация RADIUS (RFC 2058) и стандарт учета RADIUS (RFC 2059) пред-
ложены для утверждения в качестве общепринятых стандартов.
Протокол RADIUS разработан в качестве протокола
аутентификации серверного доступа и учета.
Связь между NAS и сервером RADIUS основана на UDP. В целом считается, что про-
токол RADIUS не имеет отношения к подключению. Все вопросы, связанные с доступ-
ностью сервера, повторной передачей данных и отключениями по истечении времени
ожидания, контролируются устройствами, работающими под управлением протокола
RADIUS, но не самим протоколом передачи.
Протокол RADIUS основан на технологии клиент/сервер. Клиентом RADIUS обыч-
но является NAS. а сервером RADIUS считается «демон», работающий на машине UNIX
или NT. Клиент передает пользовательскую информацию на определенные серверы
RADIUS, а затем действует в соответствии с полученными от сервера инструкциями.
Серверы RADIUS принимают запросы пользователей на подключение, проводят аутен-
тификацию пользователей, а затем отправляют всю конфигурационную информацию,
которая необходима клиенту для обслуживания пользователя. Для других серверов
RADIUS или аутентификационных серверов других типов сервер RADIUS может вы-
ступать в роли клиента-посредника (proxy)
Взаимодействие между пользователем, с одной стороны, и клиентом и сервером
RADIUS, с другой, происходит так, как показано на рис. 7.7.
Сервер RADIUS может поддерживать разные методы аутентификации пользователя.
Если пользователь предоставит ему свое имя и оригинальный пароль, этот сервер может
поддержать РРР РАР или CHAP, UNIX login и другие механизмы аутентификации.
Обычно регистрация пользователя состоит из запроса (Access Request), который поступает
из NAS на сервер RADIUS, и соответствующего ответа (положительного или отрицатель-
ного), который выдает сервер. Пакет Access Request содержит имя пользователя, шифро-
ванный пароль. IP-адрес системы NAS и номер порта. Формат запроса дает возможность
пользователю запросить определенный тип сессии. Например, если запрос производит-
ся в алфавитно-цифровом режиме, из этого следует, что запрашивается услуга одного
типа ("Service-Type = Exec-User"), но если запрос делается в пакетном режиме РРР, зна-
чит услуга должна быть другой ("Service Туре = Framed User" или "Framed Type = РРР").
Сервер RADIUS может поддерживать разные методы
аутентификации пользователя: РРР РАР или CHAP,
UNIX login и другие механизмы аутентификации
Когда сервер RADIUS получает от NAS запрос Access Request, он проводит поиск
указанного имени пользователя в базе данных. Если в базе данных такого имени нет. то
сервер загружает стандартный профиль, используемый по умолчанию, или отправляет
Гпава 7 Механизмы аутентификации при осуществлении подключений
пароль серверу RADIUS
доступа
2. Сервер доступа запрашивает
у пользователя имя и пароль
5. Сервер RADIUS отвечает
сообщениями Accept,
Reject или Challenge
3. Пользователь
отвечает на запрос
6.	Клиент RADIUS обрабатывает
параметры, полученные от
сервера вместе с сообщениями
Accept или Reject
Рис. 7.7. Взаимодействие между пользователем, клиентом и сервером RADIUS
пользователю отрицательным ответ. Этот отрицательный ответ может при необходимос-
ти сопровождаться текстом, поясняющим причины отказа
В системе RADIUS функции аутентификации и авторизации совмещены. Если имя
пользователя найдено в базе данных и пароль указан верно, сервер RADIUS выдает по-
ложительный ответ, в котором приводится список пар атрибутов для данной сессии. Ти-
пичными параметрами являются тип услуги (shell или framed), тип протокола, адрес IP,
присваиваемый пользователю (статический или динамический), список объектов досту-
па или статический маршрут, который необходимо добавить в таблицу маршрутизации
NAS. Конфигурационная информация на сервере RADIUS определяет, какие средства
следует установить на машине NAS.
В системе RADIUS функции аутентификации и авторизации
совмещены.
Аутентификация и авторизация RADIUS показаны на рис. 7.8.
Учетные функции протокола RADIUS могут использоваться независимо от функций
аутентификации и авторизации. Они позволяют в начале и в конце каждой сессии от-
правлять данные о количестве ресурсов (т. е. времени, пакетов, байтов и т. д.). исполь-
зованных в ходе этой сессии. Провайдер услуг Интернет (ISP) может использовать про-
граммные средства контроля доступа и учета RADIUS для удовлетворения специальных
требований безопасности и биллинга.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Сервер
доступа
Packet Туре = Access Request
Сервер
безопасности
Username, Password
Access Accept/ Access Reject
User Service, Framed Protocol
Access Challenge (Optional)
Reply Message
Рис. 7.8. Аутентификация и авторизация по протоколу RADIUS
Транзакции между клиентом и сервером RADIUS аутентифицируются с помощью
общего «секрета», который никогда не передается по сетевым каналам. Кроме того, обмен
любыми пользовательскими паролями между клиентом и сервером RADIUS идет только
в шифрованном виде, что исключает подслушивание чужих паролей и последующее
злоупотребление ими.
7.6.	Стандарт IEEE 802.1 х и протокол EAPOL
Стандарт сетевой аутентификации IEEE 802.1х нашел широкую поддержку у произво-
дителей сетевого оборудования и ПО как для беспроводных, так и для проводных сетей.
Говоря о технологии сетевой аутентификации пользователей, стоит упомянуть протокол
РРР, который наиболее часто используется для подключения клиентов по коммутируе-
мым линиям к Интернет-провайдерам. Протокол РРР также используется некоторыми
сервис-провайдерами для аутентификации пользователей, применяющих xDSL или ка-
бельные модемы. Кроме того, РРР является частью протокола L2TP, на котором основан
безопасный удаленный доступ к системам на базе Windows 2000 и выше.
Итак, протокол РРР изначально использовался для подключения удаленных пользо-
вателей, и поэтому он должен был иметь механизмы аутентификации пользователей.
Первоначально поддерживалась только передача имени пользователя или пароля в нешиф-
рованном виде, что не соответствует современным требованиям сетевой безопасности.
В последнее время для протокола были разработаны новые механизмы аутентифи-
кации под общим названием ЕАР (Extensible Authentication Protocol). Принципы работы
данного протокола были рассмотрены выше. Протокол ЕАР был создан с целью упразд-
нения частных механизмов аутентификации и распространения стандартизированных
подходов — схем типа «запрос—ответ» (challenge-response) и инфраструктуры, основан-
ной на публичных ключах и пользовательских сертификатах. Стандартизация механиз-
мов ЕАР позволила сделать аутентификацию прозрачной для серверов доступа различ-
ных производителей. Например, при подключении пользователя к серверу удаленного
доступа и использовании механизма ЕАР протокола РРР для аутентификации сам сервер
доступа не должен знать или поддерживать конкретные механизмы или алгоритмы
аутентификации, его задача в этом случае — лишь передать пакеты ЕАР-сообшений
RADIUS-серверу, на котором фактически производится аутентификация. В этом случае
сервер доступа исполняет роль посредника между клиентом и RADIUS-сервером, в за-
дачи которого входит передача ЕАР-сообщений между ними. Модель контроля доступа
к портам стандарта 802.1х показана на рис. 7.9.
Глава 7. Механизмы аутентификации при осуществлении подключений
Запрос на обслуживание
(соединение)
Клиент
ПК/Ноутбук
] Р -телефон
Точка доступа
WLAN
Коммутатор
Аутентификатор
Коммутатор
Маршрутизатор
Точка доступа
WLAN
Аутентификация
Сервер
аутентификации
•	IAS
•	ACS
•	Любой сервер
IETF RADIUS
Хранилище
идентификационной
информации
MS AD
LDAP
NDS
ODBC
/ Взаимодействие с
I хранилищем
идентификационной
информации
Рис. 7.9. Модель контроля доступа к портам стандарта 802.1х. Основные элементы
Стандарт 802.1х описывает процедуру передачи EAP-сообщений сервером доступа
(например, коммутатором или беспроводной точкой доступа) в проводных или беспро-
водных Ethemet-сетях При этом стандарт 802.1х напрямую упаковывает ЕАР-сообщения
в Ethernet-кадры. не применяя для их передачи протокол РРР. Это вызвано тем, что ис-
пользовать протокол РРР во многих случаях не обязательно, например, при подключении
Ethemet-рабочей станции, не поддерживающей протокол TCP/IP, или в том случае, когда
использование протокола РРР является избыточным.
В стандарте 802.1х определяется три основных элемента:
•	Суппликант (Supplicant) — пользователь, который нуждается в сетевой аутенти-
фикации.
•	Сервер аутентификации (Authentication Server) — обычно RADIUS-сервер, который
производит фактическую аутентификацию, например Cisco ACS или Microsoft IAS
•	Аутентификатор (Authenticator) — сетевое устройство, находящееся между суппли-
кантом и сервером аутентификации и предоставляющее доступ в сеть, например,
точка доступа или Ethernet-коммутатор.
Кл ючевым моментом является то, что сетевые устройства — аутентификаторы — могут
быть достаточно простыми, поскольку для реализации функций 802.1х в них требуются
минимальные аппаратные затраты, в то время как весь интеллект концентрируется
в RADIUS-сервере. Такая схема имеет дополнительные выгоды и позволяет организовать
тесную интеграцию управления сетевым оборудованием и сетевым ПО, что значительно
облегчает управление информационной системой большого предприятия.
Аутентификаторы могут быть достаточно простыми,
поскольку для реализации функций 802.1х в них требуются
минимальные аппаратные затраты.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Запрос на регистрацию
Обмен идентиф. информацией
Принятие
Обмен идентиф информацией
с сервером ААА
Успешная аутентификация
«< —
Правила политики безопасности
Обмен идентификационной информацией между клиентом
и сервером аутентификации производится по протоколу ЕАР;
коммутатор при этом является посредником, но он «осведомлен» о происходящем
Г 802.1Х J I	RADIUS
Рис. 7.10. Модель контроля доступа к портам стандарта 802.1х. Схема работы
Протокол передачи ЕАР-сообщений в стандарте 802.1х называется EAPOL (ЕАР encap-
sulation over LAN) и в настоящее время определен для Ethernet ЛВС, а также беспроводных
сетей стандартов серии IEEE 802.11 и ЛВС, использующих технологии token ring и FDDI.
На рис. 7.10 показана модель контроля доступа к портам стандарта 802.1х.
Протокол передачи ЕАР-сообщений в стандарте 802.1х
называется EAPOL (ЕАР encapsulation over LAN) и в настоящее
время определен для Ethernet ЛВС, а также беспроводных
сетей стандартов серии IEEE 802.11 и ЛВС.
Схема работы протокола EAPOL достаточно проста. При этом можно выделить сле-
дующие основные режимы работы:
1.	Аутентификатор посылает запрос на аутентификацию (EAP-Request/ldentity) суп-
пликанту, как только он определит, что какой-то из его Ethemet-портов перешел в актив-
ное состояние (link active), то есть к нему подключен сетевой адаптер. Таким образом,
если отключить клиентскую станцию, которая уже прошла аутентификацию, и снова
подключить к сетевому порту, то потребуется пройти аутентификацию еще раз.
2.	Суппликант посылает сообщение/ответ (EAPResponse/ldentity) аутентификатору,
которое затем передается им на сервер аутентификации (RADIUS).
3.	Сервер аутентификации в ответ посылает пакет-запрос (challenge) аутентификато-
ру, который затем переупаковывает его из IP-транспорта в EAPOL и передает суппли-
канту. В различных схемах аутентификации число таких сообщении может изменяться.
В ЕАР поддерживается как аутентификация клиентской стороны, так и взаимная «силь-
ная» аутентификация клиента и сервера. Заметим, что только последний вариант счи-
тается приемлемым для использования в беспроводных сетях.
4.	Суппликант отвечает на запрос в соответствие с выбранным алгоритмом и передает
его аутентификатору, который пересылает его на сервер аутентификации.
5.	Если суппликант предоставляет правильный ответ на запрос, сервер посылает со-
общение об успешной аутентификации супйликанту. В этой ситуации аутентификатор
Гпава 7. Механизмы аутентификации при осуществлении подключений
открывает клиенту доступ к ЛВС, который может зависеть от дополнительных параметров,
передаваемых ему RADIUS-сервером, например, от номера ВЛВС (VLAN) или опреде-
ленного уровня качества обслуживания (QoS).
Таким образом, использование сетевой аутентификации позволяет предоставлять поль-
зователю определенный номер ВЛВС или уровень качества обслуживания независимо от
точки подключения в корпоративную ЛВС. Это обеспечивает как мобильность пользо-
вателей, так и постоянное соблюдение профиля безопасности сети — если даже сетевые
кабели будут случайно перепутаны, пользователь не сможет войти в ВЛВС (подключиться
не к своему сегменту сети), доступ к которой ему запрещен. Стандарт включает три вида
протокола ЕАР:
•	EAP-MD5 — с хэшированием имени пользователя и пароля по алгоритму MD5;
•	ЕАР-ОТР — с поддержкой доступа по одноразовым паролям;
•	EAP-TLS — аутентификация с установлением защищенного канала (SSL).
7.7.	Протокол EAP-TLS
с использованием российской криптографии
7.7.1.	Общие сведения
Протокол ЕАР предоставляет стандартный механизм поддержки дополнительных ме-
тодов аутентификации в протоколе РРР. При использовании ЕАР можно добавить не-
сколько схем аутентификации, включая смарт-карты, Kerberos, открытые ключи, одно-
разовые пароли и др. Существующие в настоящее время реализации протокола ЕАР фо-
кусируются на аутентификации клиента к серверу. Однако зачастую требуется взаимная
аутентификация клиента и сервера.
Протоколы РРР (такие, как 3DES, Triple-DES Encryption Protocol) используют сес-
сионные ключи, поэтому необходимо иметь механизм получения таких ключей. Такой
механизм реализован в протоколе EAP-TLS. Этот протокол позволяет обеим сторонам,
взаимодействующим по протоколу РРР, осуществлять защищенный обмен по заданным
алгоритмам, взаимную аутентификацию и управление ключами на основе протокола TLS
Протокол EAP-TLS используется в стандарте сетевой аутентификации IEEE 802.1х
для осуществления первоначальной аутентификации субъекта локальной вычислитель-
ной сети (виртуальной частной сети. VPN).
Протоколы РРР (такие, kskDES, Triple-DES Encryption
Protocol) используют сессионные ключи, поэтому
необходимо иметь механизм получения таких ключей.
Такой механизм реализован в протоколе EAP-TLS.
Обмен по протоколу EAP-TLS начинается со стандартного обмена аутентификатора
и аутентифицируемого субъекта в соответствии с протоколом ЕАР. Аутентификатор отправ-
ляет пакет ЕАР-запроса на аутентификацию субъекту, который в свою очередь отправ-
ляет аутентификатору пакет ЕАР-ответа, содержащий его идентификатор.
С этой точки зрения в процессе обмена по протоколу ЕАР между аутентификатором
и субъектом аутентификатор может действовать как промежуточное устройство, накапли-
вающее приходящие от противоположной стороны пакеты для передачи их RADIUS-cep-
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
веру или защищенному серверу. В протоколе EAP-TLS под понятием EAP-сервер под-
разумевается конечная точка в такой цепи, которая общается с субъектом, нуждающим-
ся в аутентификации.
Субъекта, взаимодействующего с EAP-сервером, в дальнейшем будем называть
EAP-клиентом. Получив идентификатор ЕАР-клиента, EAP-сервер отправляет старто-
вый пакет EAP-TLS. Последний представляет собой пакет EAP-запроса, в котором
EAP-Type=EAP-TLS, выставлен стартовый бит (S) и отсутствуют данные.
После этого начинается непосредственный обмен по протоколу EAP-TLS. ЕАР-клиент
отправляет пакет EAP-ответа, в котором EAP-Type=EAP-TLS. Поле данных этого пакета
инкапсулируется из сообщения clieni_hello протокола TLS. Шифрование и компрессия
пакета не производятся.
Сообщение client_hello содержит версию протокола TLS, идентификатор сессии, слу-
чайные данные клиента, а таюке набор поддерживаемых клиентом шифр-сюит. Отправ-
ляемая клиентом версия должна быть не ниже, чем TLS версии 1.0.
После этого EAP-сервер отвечает пакетом EAP-запроса, в котором ЕАР-Туре=EAP-TLS.
Поле данных этого пакета инкапсулируется из одного или более TLS-пакетов. Эти пакеты
содержат в своей совокупности ряд сообщений, формируемый в зависимости оттого, со-
здается ли новая сессия или восстанавливается предыдущая. Если создается новая сессия,
то отправляются сообщения server_hello, certificate, certificate_request и server_hello_done.
В случае восстановления предыдущей сессии отправляются сообщения server_hello,
change_cipher_spec и finished.
Сообщение server_hello содержит версию протокола TLS, идентификатор сессии,
случайные данные сервера и выбранную сервером шифр-сюиту.
Если отправленный клиентом идентификатор сессии был нулевым или он не поддер-
живается сервером, то сервер выбирает идентификатор для установления новой сессии.
В противном случае сервер пытается восстановить ранее установленную сессию с заданным
идентификатором.
Идентификатор сессии в рамках протокола TLS служит для повышения эффективнос-
ти в тех случаях, когда клиент повторно производит аутентификацию для сервера через
небольшой промежуток времени. То же самое можно сказать и для РРР-аутентификации.
Сообщение certificate представляет собой сертификат, содержащий открытый ключ
сервера, соответствующий выбранной им шифр-сюите в сообщении server_hello.
Сообщение certificate_request (запрос на сертификат клиента) оправляется в том случае,
если сервер требует аутентификацию клиента В случае EAP-сервера создание такого за-
проса желательно, но не обязательно.
После получения этих сообщений ЕАР-клиент отправляет пакет EAP-ответа, в котором
EAP-Type=EAP-TLS. Поле данных этого пакета инкапсулируется из одного или более
TLS-пакетов, содержащих сообщения change_cipher_spec, clieni_key_exchange, finished,
а также возможно сообщения certificate и certificate_verify. Если сервер восстановил пре-
дыдущую сессию, то клиент отправляет только сообщения change_cipher_spec и finished.
Что касается сообщения certificate, то возможны следующие варианты ответной ре-
акции клиента:
1.	Сервер не запросил сертификат клиента. В зависимости от настройки верхнего уров-
ня связь прервется, или продолжается установление связи в соответствии с пунктом 4).
2.	Сервер запросил сертификат клиента. У клиента есть сертификат, соответствующий
параметрам Диффи—Хеллмана сертификата сервера. Он передает сообщением certificate
этот сертификат серверу.
3.	Сервер запросил сертификат клиента, но у клиента нет сертификата, соответствую-
щего параметрам Диффи—Хеллмана сертификата сервера. Если клиент не хочет аутенти-
Гпава 7. Механизмы аутентификации при осуществлении подключений
фикации его сервером, он посылает сообщение certificate пустым. В этом случае система
может быть настроена как на прекращение связи, так и на ее продолжение. Если связь
продолжается, осуществляется переход к пункту 4).
4.	У клиента нет сертификата, соответствующего параметрам Диффи—Хеллмана сер-
тификата сервера, но есть сертификат, соответствующий другим параметрам или соот-
ветствующий закрытый ключ предназначен только для подписи. В этом случае клиент
передает свой сертификат сообщением certificate и генерирует эфемеральную пару ключей
(за крыты й/открытый) с параметрами сертификата сервера. Если у клиента нет никакого
сертификата, то он генерирует эфемеральную пару ключей (закрытый/открытый) с па-
раметрами сертификата сервера, но сообщение certificate не передает.
Клиент на основе своего закрытого ключа, соответствующего сертификату с пара-
метрами Диффи—Хеллмана сервера, или закрытого ключа выработанной им эфе-
меральной пары и открытого ключа сертификата сервера формирует ключ Диффи—Хел-
лмана (ключ обмена), генерирует премастер-ключ (32 случайных байта) и сообщением
client_key_exchange передает ее серверу. Если клиент вырабатывал эфемерную пару клю-
чей Диффи—Хеллмана, то в этом же сообщении он отправляет также открытый ключ
эфемеральной пары.
После этого у клиента имеются пары ключей Диффи—Хеллмана (закрытый, открытый),
шифр-сюита сессии, премастер-ключ и случайные данные клиента и сервера (32 байта
каждая).
Если клиент в сообщении client_key_exchange передал открытый ключ из эфемеральной
пары и передал свой сертификат, он передает сообщение certificate_verify, содержащее
подпись на закрытом ключе из этого сертификата (с параметрами, отличными от параметров
сертификата сервера) хэш-значения всего диалога клиент/сервер до данного момента.
Клиент переключается на криптографические алгоритмы, соответствующие выбран-
ной сервером шифр-сюите, и сообщает об этом переходе серверу сообщением
change_ci pher_spec.
Из имеющихся данных клиент вырабатывает мастер-ключ (48 байт), а из него и рабо-
чие ключи. Помимо этого из мастер-ключа и хэш-значения всего диалога клиент/сервер
до данного момента вырабатывается сообщение finished и отправляется серверу.
В случае восстановления сессии сообщение finished вырабатывается из сохраненного
в сессии мастер-ключа.
После этого ЕАР-сервер отвечает пакетом ЕАР-запроса, в котором EAP-Type=EAP-TLS
Поле данных этого пакета инкапсулируется из одного или более TLS-пакетов. Эти пакеты
содержат сообщения change_cipher_spec, finished.
Сервер, если клиент использует эфемеральную пару ключей, вычисляет хэш-значение
всего диалога клиент-сервер до данного момента и проверяет подпись хэша из сообще-
ния certificate_verify. Этим он проверяет одновременно открытый ключ эфемеральной
пары, переданный клиентом в сообщении client_key_exchange.
Сервер на основе своего закрытого ключа (соответствующего его сертификату) и от-
крытого ключа клиента (из сертификата клиента с параметрами сервера или из вырабо-
танной им эфемеральной пары) формирует ключ Диффи—Хеллмана, ключ обмена и де-
шифрует премастер-ключ.
Сервер переключается на криптографические алгоритмы, соответствующие вы-
бранной сервером шифр-сюите, и сообщает об этом переходе клиенту сообщением
change=cipher_spec.
После всех операции у сервера имеются пары ключей Диффи—Хеллмана (закрытый,
открытый), шифр-сюита сессии, премастер-ключ и случайные данные клиента и сервера
(32 байта каждая).
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Из этих данных сервер вырабатывает мастер-ключ (48 байт), а из него и рабочие ключи
Помимо этого, из мастер-ключа и хэш-значения всего диалога клиент/сервер до данного
момента вырабатывается сообщение finished, шифруется и отправляется клиенту.
Если аутентификация пройдена успешно, то ЕАР-клиент отправляет пакет ЕАР-от-
вета. в котором EAP-Туре = EAP-TLS. Поле данных этого пакета пустое
ЕАР-сервер в случае успешной аутентификации отвечает аналогичным пакетом
ЕАР-запроса.
Если аутентификация оказывается неуспешной, то формируется пакет, в котором
ЕАР-Туре=EAP-TLS. а в поле запроса содержится TLS-сообщение об ошибке
7.7.2.	Получение ключей
Ключи шифрования, используемые для PPP-шифрования, получаются из TLS мас-
тер-ключа. Ключи для обеих сторон производятся следующим образом: из мастер-ключа,
полученного в процессе обмена, псевдослучайной функции PRF и случайных данных,
получаемых конкатенацией случайных данных клиента и сервера, вычисляется значение
функции PRF (master secret, "client ЕАР encryption", random) — 128 байт, после чего вы-
числяется значение PRF (“”, "client ЕАР encryption", random) — 64 байта (где —пустая
строка).
Из полученных первым преобразованием PRF 128 байт последовательно создаются
4 ключа по 32 байта каждый: ключ шифрования клиента (используется для шифрования
данных, отправляемых ЕАР-серверу), ключ шифрования сервера (используется для
шифрования данных, отправляемых клиенту), ключ аутентификации клиента (исполь-
зуется для подсчета МАС при отправке сообщений серверу) и ключ аутентификации сер-
вера (используется для подсчета МАС при отправке сообщений клиенту).
Из полученных вторым преобразованием PRF 64 байт последовательно создаются два
вектора инициализации — клиента и сервера — используемые в процессе шифрования
сообщений.
Поскольку в основе протокола EAP-TLS лежит механизм установления аутентичного
соединения в соответствии с протоколом TLS, то использование российской криптогра-
фии целесообразно проводить именно для выполнения основных функций протокола
TLS.
В реализации протокола TLS на базе российской криптографии используются сле-
дующие алгоритмы:
•	формирования/проверки подписи при аутентификации клиента и сервера (алго-
ритмы ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001);
•	шифрования/дешифрования информации (алгоритм ГОСТ 28147—89);
•	контроля целостности передаваемой информации (ключевой хэш на базе алго-
ритма хэширования ГОСТ Р 34.11—94);
•	обмена ключей (с использованием алгоритма Диффи—Хеллмана на базе алгорит-
мов ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001).
Подробное описание данных алгоритмов приводится в стандартах RFC 4490 и
RFC 4491. Описание специфичных для российских криптографических алгоритмов
шифр-сюит, функций выработки и шифрования ключей приводится в информацион-
ном документе RFC 4357.
Кроме того, компанией «КРИПТО-ПРО - был разработан и опубликован документ
draft-chudov-cryptopro-cptls, в котором приводится подробное описание использования
российских криптографических алгоритмов в протоколе TLS
92
Гпава 7 Механизмы аутентификации при осуществлении подключений
7.8.	Стандарт IEEE 802.1х
в операционных системах Microsoft
До последнего времени клиент IEEE 802.1х в операционных системах компании
Microsoft 802.1х был изначально встроен только в ОС Windows ХР, однако относи-
тельно недавно компания выпустила свободно распространяемое дополнение для
Windows 2000, позволяющее и данной ОС производить сетевую аутентификацию по
протоколу 802.1х.
В стандартной комплектации Windows ХР поддерживает три метода ЕАР:
•	ЕАР-М D5. Сервер аутентификации запрашивает идентификационные данные у ини-
циатора взаимодействия. Инициатор взаимодействия объединяет запрос со своим
идентификатором и паролем, создает хэш MD5 из всех этих данных и посылает
его обратно на сервер аутентификации. Последний дешифрует принятые данные,
и в случае совпадения их с исходным запросом аутентификация завершается ус-
пешно. Заметим, что Windows не позволяет использование метода EAP-MD5 для
беспроводных подключений по протоколу 802.1х.
•	EAP-TLS. Сервер аутентификации открывает сеанс TLS с инициатором взаимо-
действия. Сервер посылает свой цифровой сертификат инициатору взаимодейст-
вия, а он проверяет действительность этого сертификата После этого инициатор
взаимодействия посылает свой цифровой сертификат на сервер, а тот проверяет
действительность сертификата. Таким образом, клиент и сеть производят взаим-
ную проверку подлинности, и если каждая из сторон доверяет сертификату другой
стороны и этот сертификат является действительным, аутентификация заверша-
ется успешно.
•	Защищенный ЕАР (РЕАР). Обмен данными по протоколу РЕАР начинается так же.
как и в случае ЕАР: сервер аутентификации открывает сеанс TLS с инициатором
взаимодействия и посылает ему свой цифровой сертификат для проверки. Если
инициатор взаимодействия доверяет этому сертификату, он удостоверяет свою
подлинность серверу одним из нескольких методов. В настоящее время единствен-
ным доступным методом аутентификации со стороны просителя в Windows является
MS-CHAPv2, в котором инициатор взаимодействия использует традиционные
учетные записи (имена и пароли пользователей и компьютеров) для проверки под-
линности. Это называется PEAP-EAP-MS-CHAPv2. Обратите внимание, что мож-
но также выбрать вариант РЕАР-EAP-TLS. хотя на самом деле в его использова-
нии нет смысла. Он предусматривает открытие независимого второго сеанса TLS
внутри первого; такое удвоение сеансов TLS замедляет работу по сравнению с ме-
тодом EAP-TLS.
ПК с установленными ОС семейства Windows 2000/2003 Server и службой 1AS может
исполнять функции RADIUS-сервера, который, в свою очередь, выполняет аутентифика-
цию и авторизацию клиентов, использующих протоколы EAP-TLS, PEAP-MS-CHAP v2
или PEAP-EAP-TLS.
Клиенты Microsoft 802. lx Authentication Client packages для Windows 98 и Windows NT 4.0
Workstation доступны только партнерам компании Microsoft, которые имеют контракты
по технической поддержке уровня Premier и Alliance. Однако для версий Windows 98,
NT 4.0 или Linux можно использовать утилиты от ряда независимых производителей,
например. Funk Software (http://www.funk.com/).
93
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
7.9.	Cisco NAC
Технология Cisco Network Admission Control (NAC) усиливает сетевую инфраструктуру,
сокращая вред от воздействия вирусов и «червей». С помощью Cisco NAC организации
могут обеспечить сетевой доступ для таких оконечных устройств, как персональные
компьютеры, карманные компьютеры и серверы, полностью соблюдая при этом задан-
ную политику безопасности. Cisco NAC позволяет отказать в доступе устройствам, ко-
торые не соответствуют политике защиты, и поместить их в карантинную область или
предоставить им ограниченный доступ к информационным ресурсам Cisco NAC — пер-
вый шаг многоэтапной концепции защиты Cisco Self-Defending Network по идентифи-
кации угроз и их предотвращению.
С помощью Cisco NAC организации могут обеспечить сетевой
доступ для таких оконечных устройств, как персональные
компьютеры, карманные компьютеры и серверы.
Существующие антивирусные решения, опирающиеся на распознавание сигнатур
атаки, не содержат и не могут распознавать вирусы с момента их появления (Day-zero)
и атаки типа «отказ в обслуживании», которые этими вирусами порождаются. Особенность
саморазмножения новейших атак делает их особенно опасными и разрушительными
Персональные компьютеры и серверы, которые не соответствуют корпоративной по-
литике безопасности, являются повсеместным явлением и их трудно обнаружить, огра-
ничить и очистить. Блокирование и изоляция таких систем требуют много времени и ре-
сурсов и приводят к тому, что заражение, которое, казалось бы, излечено, проявляется
снова через некоторый срок. Проблема заключается в сложности нынешней сетевой сре-
ды, которая состоит из следующих элементов:
•	типы пользователей — сотрудники, поставщики, подрядчики;
•	типы конечных точек — персональные компьютеры в офисе, домашние ПК, сер-
веры;
•	типы доступа — кабельный, беспроводной, виртуальные частные сети и доступ по
коммутируемым линиям связи.
Cisco NAC учитывает увеличивающуюся угрозу сетям, усложнение сетевой среды, и
обеспечивает, в первую очередь, технологию защиты хостов, но не фокусируется на до-
ступности и отказоустойчивости всей сети компании.
Cisco NAC предлагает полнофункциональное решение, которое позволяет организа-
циям проводить политику применения «заплаток» на оконечных узлах, а также поме-
щать несоответствующие политике безопасности и потенциально уязвимые системы
в карантинные области с ограниченным сетевым доступом или без него. Предлагаемая
Cisco NAC возможность комбинировать информацию о статусе защиты конечного уст-
ройства со сведениями об осуществлении доступа к сети позволяет организации значи-
тельно улучшить защиту своей вычислительной инфраструктуры.
Cisco NAC разрешает сетевой доступ соответствующим политике и доверенным око-
нечным устройствам (например, персональные компьютеры, серверы, карманные
компьютеры) и ограничивает доступ тем устройствам, которые не соответствуют поли-
тике безопасности. Решение о доступе принимается на основе информации об антиви-
русной защищенности и об уровне применения программных обновлений («заплаток»)
в операционной системе.
94
Гпава 7. Механизмы аутентификации при осуществлении подключений
Cisco NAC умножает отдачу средств, инвестированных в сетевую инфраструктуру 1
технологию защиты хостов, связывая их вместе и обеспечивая этим возможность контрол*
сетевого допуска. Например, организация может быть уверена, что применение анти
вирусных программ обеспечивается сетью Cisco — маршрутизаторами, коммутаторами
беспроводными устройствами и устройствами защиты. Таким образом. Cisco NAC допол
няет — а не заменяет — классические и широко распространенные технологии защиты
межсетевые экраны, системы обнаружения вторжений, аутентификацию пользователе!
и защиту коммуникаций.
Cisco NAC разрешает сетевой доступ соответствующие
политике и доверенным оконечным устройства*
и ограничивает доступ тем устройствам, которые
не соответствуют политике
Состав компонентов Cisco NAC приведен на рис. 7.11.
•	Доверенный агент Cisco (Cisco trust agent) — программное обеспечение, разме
щаемое на оконечных узлах (рабочие станции, серверы и т. п.). Доверенный аген
собирает информацию о защищенности от множества программных клиентов, таки>
как антивирусные клиенты, а затем передает эти сведения устройствам сетевог
доступа Cisco, которые осуществляют контроль допуска. Компания Cisco лицеи
зировала технологию доверенного агента для своих партнеров в области антиви
русов, и теперь этот агент может интегрироваться с их клиентским ПО. Доверенны
агент будет также интегрироваться и с Cisco Security Agent, чтобы контролироват
доступ, например, в зависимости от уровня применения программных обновле
ний в операционной системе оконечного устройства. Cisco Security Agent програм
ПО защиты
клиента
Cisco
Security
Agent
Маршрутизатор
коммутатор
Сервер
политик
Сервер политик
производителей
антивирусов,
антишпионов и др.
ПО
Выйолнение
проверки состояния
Cisco ф
Trust ;
Agent I
В ы полнить; де иствие:
• Разрешит^
• Запретит^
• КарантиН
• Дополнительные действия
Создание
политики
безопасности
I Антивирус
| Анти шпион
Реализация
политики
безопасности
Проверка политики
антивирусной защиты
Рис. 7.11. Компоненты Cisco NAC
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
мное решение защиты хоста от несанкционированного доступа, будет получать
доступ к информации о версии операционной системы, о программных «заплат-
ках» и текущем состоянии системы и передавать эту информацию доверенному
агенту Cisco (Cisco Trust Agent). Хостам, не имеющим необходимых программных
обновлений, может быть предложен ограниченный доступ или вообще отказано
в доступе к сети.
•	Устройства сетевого доступа — к сетевым устройствам, осуществляющим политику
контроля допуска, относятся маршрутизаторы, коммутаторы, точки беспроводного
доступа и устройства защиты. Эти устройства требуют наличия электронных удос-
товерений от оконечного узла, и передают эту информацию на серверы контроля
политики, где и принимается решения о доступе в сеть. На основе политики заказ-
чика сеть будет проводить соответствующее решение о контроле сетевого доступа —
разрешить, запретить, поместить под наблюдение, ограничить.
•	Сервер политики — оценивает защищенность конечной точки по информации, по-
лученной от устройств сетевого доступа, и определяет для них соответствующую
политику доступа. Основой системы серверов политики являются сервер аутенти-
фикации, авторизации и отчетности (AAA) RADIUS — Cisco Secure Access Control
Server (ACS). Система работает совместно с серверами приложений партнеров Cisco
NAC, обеспечивающих более широкие возможности проверки электронных удос-
товерений, такими как серверы антивирусной политики.
•	Система управления — Cisco Works VPN/Security Management Solution (VMS) управ-
ляет элементами Cisco NAC, а решение CiscoWorks Security Information Manage-
ment Solution (SIMS) предлагает инструменты мониторинга и создания отчетов.
Партнеры Cisco NAC предлагают решения для управления своим программным
обеспечением на конечных узлах.
На рис. 7.12 показаны сценарии развертывания Cisco NAC в различных сегментах сети
Рис. 7.12. Сценарии развертывания Cisco NAC
6
Гпава 7. Механизмы аутентификации при осуществлении подключений
Cisco NAC помогает гарантировать соответствие хостов в удаленных или домашних
офисах, которые подключаются к ресурсам центральной компании либо по территори-
альным сетям передачи данных, либо по защищенному каналу в Интернете. Сюда входит
проверка соответствия на главном маршрутизаторе или на маршрутизаторе филиала.
•	Защита удаленного доступа. Еще до того, как мобильный или удаленный работник
получит доступ в сеть по коммутируемой телефонной линии, по протоколу IPSec
или иному соединению, Cisco NAC гарантирует, что на компьютере работника ус-
тановлены последние версии антивирусов и программных обновлений для опе-
рационной системы.
•	Защита беспроводной сети. Cisco NAC проверяет подключенные по беспроводным
каналам хосты на предмет правильности их программных обновлений. Для выпол-
нения этой проверки используется протокол 802 1х и комбинация аутентифика-
ции пользователя и устройства.
•	Защита сетевого доступа и центра обработки данных. Cisco NAC контролирует
серверы и персональные компьютеры в офисе еще до того, как им будет предос-
тавлен доступ к сети, позволяет гарантировать их соответствие антивирусной по-
литике и политике использования программных обновлений, принятых в компа-
нии. Расширяет контроль допуска на коммутаторах Уровня 2, что позволяет
уменьшить риск заражения вирусами или «червями».
•	Соответствие внешних (партнерских) сетей. С помощью Cisco NAC можно прове-
рять не только системы, управляемые IT-подразделением предприятия, но и любую
систему, которая пытается получить доступ в сеть. На соответствие политикам
антивирусов и операционных систем могут быть проверены управляемые и не-
управляемые хосты, принадлежащие в том числе партнерам и подрядчикам. Если
на опрашиваемом хосте отсутствует доверенный агент Cisco (Cisco Trust Agent), то
используется политика доступа по умолчанию.
Контрольные вопросы
1.	Какие протоколы включены в механизм аутентификации Poini-to-Point Protocol (РРР)?
2.	Перечислите основные элементы стандарта 802.1х.
3.	Какие методы ЕАР стандарта 802.1х включены в стандартную комплектацию
Windows ХР?
4.	Опишите взаимодействие между пользователем, клиентом и сервером RADIUS
5.	Опишите метод получения ключей шифрования, используемых для РРР.
Глаа 8
АУТЕНТИФИКАЦИЯ
В ЗАЩИЩЕННЫХ СОЕДИНЕНИЯХ
Протоколы безопасности на транспортном уровне SSL и Secure Shell Protocol (SSH)
обеспечивают безопасную передачу данных между клиентом и сервером. Оба протокола
разработаны рабочей группой 1ETF по безопасности транспортного уровня (Transport
.ayer Security — TLS). Безопасный протокол передачи гипертекста S-HTTP предостав-
[яет надежный механизм Web-транзакций, однако в настоящее время наиболее распро-
транен протокол SSL. Рамочная структура SOCKS позволяет приложениям клиент/сер-
tep в доменах TCP и UDP удобно и безопасно пользоваться услугами межсетевого эк-
рана. Протокол безопасности IP (IPSec) представляет собой набор стандартов
юддержки целостности и конфиденциальности данных на сетевом уровне (в сетях IP)
(.509 — это стандарт безопасности, определяющий структуру данных цифрового серти-
фиката и описывающий вопросы обращения общих ключей. Х.509 является важнейшим
юмпонентом инфраструктуры открытых ключей (PKI)
8.1. Протоколы SSL, TLS
SSL — открытый протокол, разработанный компанией Netscape, который определяет
механизм поддержки безопасности данных на уровне между протоколами приложений
такими, как Hypertext Transfer Protocol (http), Telnet, Network News Transfer Protocol
NNTP) или File Transfer Protocol (FTP)) и протоколом TCP/IP. Он поддерживает шиф-
ювание данных, аутентификацию серверов, целостность сообщений и (в качестве оп-
1ии) аутентификацию клиентов в канале TCP/IP. SSL был представлен рабочей группе
ю безопасности консорциума W3 (W3C) для утверждения в качестве стандартного сред-
тва безопасности Web-браузеров и серверов в сети Интернет
SSL поддерживает шифрование данных, аутентификацию
серверов, целостность сообщений и (в качестве опции)
1утентификацию клиентов в канале TCP/IP.
Основная цель протокола SSL состоит в том, чтобы обеспечить защиту и надежность
•вязи между двумя подключенными друг к другу приложениями. Этот протокол состоит из
щух уровней. Нижний уровень который располагается поверх надежного транспортного
фотокола (например, TCP), называется SSL Record Protocol и используется для встраива-
ния различных протоколов высокого уровня. Один из таких встроенных протоколов —
>SL Handshake Protocol позволяет серверу и клиенту аутентифицировать друг друга и со-
ласовывать алгоритм шифрования и криптографические ключи, прежде чем протокол
филожения произведет обмен первыми битами данных. Одно из преимуществ SSL
•остоит в том, что он независим от протоколов приложений. Протокол высокого уровня
ложет располагаться поверх протокола SSL. Протокол SSL поддерживает безопасность
•вязи, обеспечивая ей следующие возможности:
18
Гпава 8. Аутентификация в защищенных соединениях
•	Защищенность. После первоначального квитирования связи применяются сре
ства шифрования и определяется секретный ключ. Для шифрования данных и
пользуются средства симметричной криптографии (например, DES, RC4 и т. д
•	Аутентификация участника сеанса связи с помощью общих ключей, т. е. среде
вами асимметричной криптографии (например, RSA, DSS и т. д.).
•	Надежность. Транспортные средства проводят проверку целостности сообщен!
с помощью шифрованного кода целостности (МАС). Для вычисления кодов МА
используются безопасные хэш-функции (например, безопасный хэш-алгорт
(SHA), MD5 и т. д.).
Основная цель протокола SSL состоит в том, чтоб
обеспечить защиту и надежность связи между двук
подключенными друг к другу приложениям^
Протокол SSL состоит из нескольких уровней На каждом уровне сообщения имек
ряд полей для указания длины, описания и содержания. SSL воспринимает данные, npej
назначенные для передачи, делит их на управляемые блоки, проводит компрессию даннь
(если это необходимо), использует код МАС, производит шифрование и передает резул]
тат. Принятые данные дешифруются, проверяются декомпрессируются и реассембл!
руются, а затем передаются клиентам более высокого уровня.
Протокол SSL принят только в рамках HTTP. Другие протоколы могут работа!
с SSL, но используют его не часто.
Протокол обеспечения безопасности на уровне передачи данных TLS (Transport Layi
Security Protocol) создан на основе SSL 3.0 компании Netscape. Идея заключалась в ton
чтобы опубликовать этот протокол как формальный RFC и придать ему до некоторо
степени некоммерческий статус. Ниже приведено общее описание TLS. Более подроС
ное описание приведено в RFC 2276 и спецификации SSL.
Протокол TLS состоит из двух уровней: TLS Record Protocol (протокол записей)
TLS Handshake Protocol (протокол установления связи). TLS Record Protocol действуе
поверх TCP и UDP и выполняет следующие функции:
•	симметричное шифрование для шифрования Ключи для такого шифрования гене
рируются отдельно для каждого соединения и при их создании используется се!
ретная информация, полученная с помощью другого протокола (такого, как TL
Handshake Protocol). TLS Record Protocol может быть использован и без шифре
вания;
•	передача сообщений: сюда входит проверка целостности переданных сообщени
с помощью кода идентификации по ключу. Для этого применяется хэширован!
(например, SHA, MD5 и др.);
•	выступает в качестве оболочки для протоколов более высокого уровня. Примеро
такого протокола может служить TLS Handshake Protocol, который позволяет се[
веру и клиенту идентифицировать друг друга, выбрать алгоритм шифрования
используемые ключи до того, как начнут передаваться данные
Протокол TLS состоит из двух уровней: TLS Record Proton
(протокол записей) и TLS Handshake Proton
(протокол установления связи
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
TLS Handshake Protocol защищает соединение, обеспечивая следующие три функции:
•	идентификация другой стороны с помощью шифрования с открытым ключом
(например, RSA, DSS и др.). Такая проверка не является обязательной, но обычно
выполняется, по крайней мере, для одной из сторон;
•	разделяемый секретный ключ становится недоступным для перехвата и не может
быть получен даже в случае, если атакующая сторона сможет поместить себя между
соединяемыми сторонами;
•	обнаружение злоумышленника при попытке изменить данные.
8.2.	Протокол SSH
Протокол Secure Shell (SSH) предназначен для защиты удаленного доступа и других
сетевых услуг в незащищенной сети. Он поддерживает безопасный удаленный вход в сеть,
безопасную передачу файлов и безопасную эстафетную передачу сообщений по протоко-
лам TCP/IP и XI1. SSH, может автоматически шифровать, аутентифицировать и сжимать
передаваемые данные. В настоящее время SSH достаточно хорошо защищен от крипто-
анализа и протокольных атак. Он хорошо работает при отсутствии глобальной системы
управления ключами и инфраструктуры сертификатов и при необходимости может под-
держивать инфраструктуры сертификатов, которые существуют в настоящий момент
(например, DNSSEC, простую инфраструктуру открытых ключей (SPK1), Х.509).
Протокол Secure Shell (SSH) поддерживает безопасный
удаленный вход в сеть, безопасную передачу файлов
и безопасную эстафетную передачу сообщений
по протоколам TCP/IP и Х11.
Протокол SSH состоит из трех основных компонентов:
•	Протокол транспортного уровня. Обеспечивает аутентификацию сервера, конфи-
денциальность и целостность данных с отличной защитой эстафетной передачи.
В качестве опции может поддерживаться компрессия данных
•	Протокол аутентификации пользователя. Позволяет серверу аутентифицировать
клиента.
•	Протокол соединения. Мультиплексирует шифрованный туннель, создавая в нем
несколько логических каналов.
Все сообщения шифруются с помощью IDEA или одного из нескольких других шиф-
ровальных средств (тройного DES с тремя ключами, DES, RC4-128 Blowfish). Обмен
ключами шифрования происходит с помощью алгоритма RSA, а данные, использованные
при этом обмене, уничтожаются каждый час (ключи нигде не сохраняются). Для зашиты
от «подслушивания» (спуфинга) сети IP используется шифрование; для защиты от DNS
и спуфинга маршрутизации — аутентификация с помощью общих ключей. Кроме того
ключи RSA используются для аутентификации центральных компьютеров.
Недостатком протоколов безопасности, действующих на уровне сессий, является их
зависимость от инструкций протокола транспортного уровня. В случае SSL это означает,
что атака на TCP может быстро прервать сессию SSL и потребовать формирования новой
сессии, в то время как TCP будет считать, что все идет нормально.
Более подробные технические детали о протоколе SSH можно получить в рабочей
группе IEFT Secure Shell (secsh).
100
Гпава 8. Аутентификация в защищенных соединениях
К преимуществам средств безопасности транспортного уровня (например, SSL или SSH)
относятся:
•	возможность действий на сквозной основе (end-to-end) с существующими стеками
TCP/IP, существующими интерфейсами прикладного программирования (API)
(WmSock, Berkeley Standard Distribution (BSD) и т. д.);
•	повышенная эффективность по сравнению с медленными каналами, поддержка
технологии Van Jacobson для компрессии заголовков, поддержка различных
средств контроля за переполнением сети, просматривающих заголовки TCP/IP;
•	отсутствие каких-либо проблем с фрагментацией, определением максимального
объема блоков, передаваемых по данному маршруту (MTU) и т. д.;
•	сочетание компрессии с шифрованием. На этом уровне такое сочетание оказыва-
ется гораздо более эффективным, чем на уровне пакетов.
8.3.	Протокол S-HTTP
S-HTTP представляет собой безопасный протокол связи, ориентированный на сооб-
щения и разработанный для использования в сочетании с HTTP. Он предназначен для
совместной работы с моделью сообщении HTTP и легкой интеграции с приложениями
HTTP. Этот протокол предоставляет клиенту и серверу одинаковые возможности (он
одинаково относится к их запросам и ответам, а также к предпочтениям обеих сторон).
При этом сохраняется модель транзакций и эксплуатационные характеристики HTTP.
Клиенты и серверы S-HTTP допускают использование нескольких стандартных фор-
матов криптографических сообщений. Клиенты, поддерживающие S-HTTP, могут уста-
навливать связь с серверами S-HTTP, и наоборот, эти серверы могут связываться с кли-
ентами S-HTTP, хотя в процессе подобных транзакций функции безопасности S-HTTP
скорее всего не будут использованы. S-HTTP не требует от клиента сертификатов от-
крытых ключей (или самих открытых ключей), потому что этот протокол поддерживает
только операции с симметричными ключами шифрования. Хотя S-HTTP может пользо-
ваться преимуществами глобальных сертификационных инфраструктур, для его работы
такие структуры не обязательны.
Протокол S-HTTP поддерживает безопасные сквозные (end-to-end) транзакции, что
выгодно отличает его от базовых механизмов аутентификации HTTP. Последние требу-
ют, чтобы клиент попытался получить доступ и получил отказ и лишь затем включают
механизм безопасности. Клиенты могут быть настроены таким образом, чтобы любая их
транзакция автоматически защищалась (обычно с помощью специальной метки в заго-
ловке сообщения). Такая настройка, например, часто используется для передачи запол-
ненных бланков. Если вы используете протокол S-HTTP, вам никогда не придется от-
правлять важные данные по сети в незащищенном виде.
Протокол S-HTTP предназначен для совместной работы
с моделью сообщений HTTP и легкой интеграции
с приложениями HTTP, поддерживает безопасные сквозные
(end-to-end) транзакции, что выгодно отличает его от базовых
механизмов аутентификации HTTP
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
S-HTTP п одддерживает высокий уровень гибкости криптографических алгоритмов,
режимов и naipa-метров. Для того чтобы клиенты и серверы смогли выбрать единый ре-
жим транзакщии (так, например, им нужно решить, будет ли запрос только шифроваться
или только по*дп исываться или и шифроваться и подписываться одновременно. Такое же
решение нуж но принять и для ответов), используется механизм согласования опций,
криптографа iec ких алгоритмов (RSA или DSA для подписи, DES или RC2 для шифро-
вания и т. д.), и ввыбора сертификатов (например, «Подписывайтесь своим сертификатом
Verisign»). S-ИТПГР поддерживает криптографию общих ключей, функцию цифровом
подписи и обеесгпечивает конфиденциальность данных.
Отметим, •чтсэ протокол S-HTTP не получил широкого распространения.
8.4.	Протокол SOCKS
SOCKS ра зршботан для того, чтобы дать возможность приложениям клиент/сервер
в доменах ТС Р i i UDP удобно и безопасно пользоваться услугами межсетевого экрана.
Он дает пользователям возможность преодолевать межсетевой экран организации и по-
лучать доступ к ресурсам, расположенным в Интернете. SOCKS служит «посредником
уровня прило жеший»: он взаимодействует с общими сетевыми средствами (например,
Telnet и браузер ^Netscape) и с помощью центрального сервера (прокси-сервера) от имени
компьютера и оль>зователя устанавливает связь с другими центральными компьютерами.
Протокол SOCKS дает пользователям возможность
преодолевать межсетевой экран организации и получать
доступ к ресурса м, расположенным в Интернете.
SOCKS был разработан много лет назад Дейвом Кобласом (Dave Koblas) из компании
SG1. и сегодня этгот код можно бесплатно получить через Интернет. С момента первого
выпуска этот код пережил несколько крупных модификаций, но каждая из них распро-
странялась бесплатно. SOCKS версии 4 решает вопрос незащищенного пересечения
межсетевых экранов приложениями клиент/сервер. основанными на протоколе TCP.
включая Telnet, FTP и распространенные информационные протоколы, например HTTP.
Wide Area Information Server (WAIS) и GOPHER. SOCKS версия 5, RFC 1928, является
дальнейшим расширением четвертой версии SOCKS. Он включает в себя UDP, расши-
ряет общую рам очную структуру, придавая ей возможность использования мощных
обобщенных схем аутентификации, и расширяет систему адресации, включая в нее имя
домена и адре са IP v.6.
В настоящее время предлагается создать механизм управления входящими и исходящими
многоадресньгми сообщениями IP, которые проходят через межсетевой экран. Это до-
стигается за счет определения расширении для существующего протокола SOCKS V.5.
что создает основу для аутентифицированного перехода межсетевого экрана одноадрес-
ным пользовательским трафиком TCP и UDP. Однако из-за того, что поддержка UDP
в текущей версии SOCKS 5 имеет проблемы с масштабируемостью и другие недостатки (и
их обязательно ггужно разрешить, прежде чем переходить к многоадресной передаче),
расширения определяются двояко: как базовые и как многоадресные расширения UDP.
Протокол SOCKS заменяет стандартные сетевые системные вызовы в приложении их
специальными версиями. Эти новые системные вызовы устанавливают связь с прокси-сер-
102
Гпава 8. Аутентификация в защищенных соединениях
вером SOCKS (который конфигурируется самим пользователем в приложении или с
темным файлом конфигурации), подключаясь к хорошо известному порту (обычно
порт 1080/ТСР). После установления связи с сервером SOCKS приложение отправл
серверу имя машины и номер порта, к которому хочет подключиться пользователь. Сер
SOCKS реально устанавливает связь с удаленным центральным компьютером, а за:
прозрачно передает данные между приложением и удаленной машиной. При этом по
зователь даже не подозревает, что в канале связи присутствует сервер SOCKS.
Трудность использования SOCKS состоит в том, что кто-то должен проводить раб-
по замене сетевых системных вызовов версиями SOCKS (этот процесс обычно назы
ется «SOCKS-ификацией» приложения). К счастью, большинство обычных сетег
приложений (Telnet, FTP, finger, whois) уже SOCKS-ифицированы, и многие произ
тители включают поддержку SOCKS в свои коммерческие приложения. Кроме тс
SOCKS 5 включает эти процедуры в свою общую библиотеку: на некоторых систем
(например, на машинах Solaris) можно автоматически SOCKS-ифицировать прилов
ние, поставив общую библиотеку SOCKS перед «shared libc» в строке поиска библио
(переменная среды LD_LIBRARY_PATH в системах Solaris).
Более подробные технические детали можно получить в рабочей группе 1ETF, ра<
тающей над проблемой аутентифицированного пересечения межсетевых экранов
8.5.	Семейство протоколов IPSec
IP Security (IPSec) — это семейство протоколов, которые обеспечивают шифрован
аутентификацию и защиту при транспортировке IP-пакетов; в его состав сейчас вхо
почти 20 предложений по стандартам и 18 RFC.
I PSec добавляет возможности шифрования и аутентификации в стек протокола TCP
на более низком уровне, чем протоколы прикладного уровня, такие как Secure Soc
Layer (SSL) и Transport Layer Security (TLS). Защита IPSec прозрачна для приложен
поскольку она осуществляется на нижнем уровне стека TCP/IP. Для защиты прило:
ний средствами IPSec необходимо, чтобы передача информации осуществлялась че
определенный порт. Если для всех соединений приложения применяют производи
порты, определить фильтр IPSec, идентифицирующий потоки сетевых данных этих п
грамм, практически невозможно.
IPSec добавляет возможности шифрования и аутентификаь
в стек протокола TCP/IP на более низком уров
чем протоколы прикладного уров
Приложения не обязательно должны быть IPSec-совместимы, так как данные от к
ента к серверу передаются открытым текстом. Протокол IPSec шифрует полезные д
ные после их отправки клиентом и дешифрует до того, как они достигнут приложе!
на сервере.
Например, протокол Telnet передает реквизиты пользователя и данные программ
крытым текстом. Ниже показан сценарий, когда и клиент, и сервер настроены на
гласование ассоциации безопасности IPSec при обмене данными по Telnet (рис. 8.1
1.	Клиент отправляет пакет серверу Пакет отправляется с произвольного порта к
ента, но всегда на ТСР-порт 23 Telnet-сервера.
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Рис. 8.1. Обмен данными по протоколу Telnet через IPSec
2.	Драйвер IPSec на компьютере клиента перехватывает пакет, когда он достигает
уровня IP, и сравнивает его со списком фильтров IPSec, настроенным на клиентском
компьютере. В нашем случае фильтр соответствует TCP 23. В результате начинается со-
гласование ассоциации (сопоставления) безопасности SA (security association) между
клиентом и сервером. SA определяет параметры IPSec-сеанса между клиентом и сервером,
а также протоколы IPSec и аутентификации, алгоритмы шифрования и проверки цело-
стности,
3.	Драйвер IPSec передает пакет протоколу Internet Security Association and Key Mana-
gement Protocol (ISAKMP) для согласования SA между клиентом и сервером. ISAKMP
используется для определения типа SA, установленного между клиентом и сервером.
4.	Клиент и сервер продолжают процесс ISAKMP, используя протокол Internet Key
Exchange (IKE) и осуществляя соединение по протоколу User Datagram Protocol (UDP) 500.
Процесс ISAKMP устанавливает необходимые SA между клиентом и сервером. SA вклю-
чает протокол и алгоритмы шифрования, применяемые для защиты обмена данными между
клиентом и сервером.
5.	Результаты SA возвращаются драйверу IPSec, поэтому он может выполнять все не-
обходимые задачи и производить любые изменения для обеспечения безопасности данных
до их передачи от клиента к серверу,
6.	Драйвер IPSec применяет к данным шифрование или алгоритм целостности или и то
и другое одновременно и отправляет данные на сетевой адаптер для передачи клиенту.
8.5.1.	Набор стандартов, используемых в IPSec
Безопасный протокол IP (IPSec) представляет собой набор стандартов, используемых для
защиты данных и для аутентификации на уровне IP. Текущие стандарты IPSec включают
независимые от алгоритмов базовые спецификации, которые являются стандартными RFC.
104
Эти RFC, перечисленные ниже, сейчас пересматриваются с целью разрешить ра
личные проблемы безопасности, которые имеются в текущих спецификациях:
•	RFC 2401 (Security Architecture for the Internet Protocol) — Архитектура защиты дт
протокола IP.
•	RFC 2402 (IP Authentication header) — аутентификационный заголовок IP.
•	RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) — Использование алп
ритма хэширования MD-5 для создания аутентификационного заголовка.
•	RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) — Использование aj
горитма хэширования SHA-1 для создания аутентификационного заголовка.
•	RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) — Использоваш
алгоритма шифрования DES.
•	RFC 2406 (IP Encapsulating Security Payload (ESP)) — Шифрование данных.
•	RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) — Обласг
применения протокола управления ключами.
•	RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP))
Управление ключами и аутентификаторами защищенных соединений.
•	RFC 2409 (The Internet Key Exchange (IKE)) — Обмен ключами.
•	RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) — нулевой алг<
ритм шифрования и его использование
•	RFC 2411 (IP Security Document Roadmap) — Дальнейшее развитие стандарта.
•	RFC 2412 (The OAKLEY Key Determination Protocol) — Проверка аутентичное!
ключа.
Для защиты данных IPSec предлагает два протокола: Authentication Headers (АН)
Encapsulating Security Payloads (ESP). В своей простейшей форме АН предоставляв
службы аутентификации и проверки целостности для передаваемых данных, a ESP
службы шифрования. АН и ESP — независимые протоколы. Их можно использовать о
дельно или в комбинации для обеспечения целостности и защиты данных от просмотр
Для защиты данных IPSec предлагав
два протокола. Authentication Headers (Al
и Encapsulating Security Payloads (ESF
8.5.2.	Протокол Authentication Headers (AH)
АН обеспечивает аутентификацию, целостность и защиту от повтора данных, передава
мых в сети. Он не помешает просмотреть данные, но исключает их изменение при переда*-
АН-пакеты используются для аутентификации компьютеров, участвующих в обме!
данными, и для обеспечения целостности передаваемых пакетов, чтобы злоумышленш
не мог изменить или воспроизвести пересылаемые данные. Протокол АН рекомендуете
использовать, когда соединения в рамках рабочей группы или проекта должны быть огр
ничены определенными компьютерами. АН гарантирует взаимную аутентификацию с<
единенных компьютеров, поэтому в обмене данными могут участвовать только ayrei
тифицированные компьютеры.
Преимущество АН в том. что он обеспечивает возможность взаимной аутентификащ
для тех протоколов, которые ее не поддерживают. Если аутентификация перемещаете
на более низкий уровень в стеке сетевого протокола, все приложения смогут поддерж!
вать IPSec.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
8.5.3.	Протокол Encapsulating Security Payloads (ESP)
ESP-пакеты позволяют шифровать данные. Кроме того, ESP предоставляет механизмы
аутентификации, целостности и защиты от повтора. Протокол ESP шифрует заголовки
TCP или UDP и данные приложений в IP-пакете. Если туннельный режим IPSec не ис-
пользуется. то исходный заголовок IP не шифруется.
При выработке решения IPSec протоколы АН и ESP можно совместно использовать
в одном SA для IPSec. Оба протокола обеспечивают целостность данных, при этом АН
защищает весь пакет от изменения, a ESP только заголовок TCP/UDP и полезные дан-
ные от проверки. Протокол ESP позволяет шифровать данные. Он необходим когда при-
ложение не распознает протокол безопасности на прикладном уровне, например SSL.
Поскольку процесс шифрования и дешифрования IPSec происходит на уровне IP/IPSec,
приложение не обязано поддерживать IPSec. Фактически приложение ничего «не знает»
о защите данных средствами IPSec (рис. 8.2).
Шифрование ESP могут применять только операционные системы и сетевые устрой-
ства, поддерживающие IPSec. Если операционная система или сетевое устройство не
поддерживают IPSec, то либо SA IPSec должно разрешить обмен открытым текстом, либо
нужно применить альтернативный процесс шифрования.
Кроме поддержки шифрования, протокол ESP обеспечивает цифровую подпись данных.
Протоколы АН и ESP различаются лишь способами защиты от изменении: АН защищает
пакет целиком, а подпись ESP не защищает IP-заголовок, применяемый для маршру-
тизации пакета в сети. При необходимости шифровать данные и обеспечить защиту всех
полей в пакетах нужно настроить SA на внедрение обоих (АН и ESP) протоколов в IPSec.
Рис. 8.2. «Прозрачная» защита данных средствами IPSec
Гпава 8 Аутентификация в защищенных соединениях
8.5.4.	Работа протоколов IPSec
Для прохождения трафика IPSec через межсетевой экран нужно разрешить прохож-
дение через него пакетов, использующих UDP 500 и идентификатор протокола 51 для АН
или 50 для ESP. Кроме того, межсетевой экран не должен транслировать сетевой адрес
(Network Address Translation, NAT). Пакеты IPSec не могут проити через NAT, поскольку
поля, измененные в результате процесса NAT, уже защищены IPSec и при их изменении
пакет станет недействительным. При прохождении пакета через службу NAT исходный
IP-адрес источника преобразуется в общий IP-адрес, а порт источника — в реальный
порт, который задан на сервере, осуществляющем преобразование.
Протокол IPSec также включает криптографические методы для управления ключами
на сетевом уровне безопасности. Протокол управления ключами Ассоциации безопас-
ности в Интернете (Internet Security Association Key Management Protocol — ISAKMP) со-
здает рамочную структуру для управления ключами в сети Интернет и предоставляет
конкретную протокольную поддержку для согласования атрибутов безопасности. Это не
создает ключей сессии, однако процедуру можно использовать с разными протоколами,
создающими такие ключи (например, с Oakley).
Протокол IPSec также включает криптографические методы
для управления ключами на сетевом уровне безопасности.
Протокол определения ключей Oakley Key Determination Protocol пользуется гибрид-
ным методом Диффи—Хелл мана, чтобы создать ключи Интернет-сессии для центральных
компьютеров и маршрутизаторов. Протокол Oakley решает важную задачу обеспечения
полной безопасности эстафетной передачи данных. Он основан на криптографических
методах, прошедших серьезное испытание практикой. Полная защита эстафетной пере-
дачи означает, что если хотя бы один ключ раскрыт, раскрыты будут только те данные,
которые шифрованы этим ключом. Что же касается данных, шифрованных последую-
щими ключами, они останутся в полной безопасности.
Протоколы ISAKMP и Oakley были совмещены в рамках гибридного протокола IKE —
Internet Key Exchange. Протокол IKE, включающий ISAKMP и Oakley, использует ра-
мочную структуру ISAKMP для поддержки подмножества режимов обмена ключами
Oakley. Новый протокол обмена ключами обеспечивает (в виде опции) полную защиту
эстафетной передачи данных, ассоциаций и согласования атрибутов, а также поддержи-
вает методы аутентификации, допускающие отказ от авторства и не допускающие такого
отказа. Этот протокол можно, например, использовать для создания виртуальных част-
ных сетей (VPN) и предоставления удаленным клиентам (использующим динамически
распределяемые адреса IP) доступ к защищенной сети.
Протоколы ISAKMP и Oakley были совмещены в рамках
гибридного протокола IKE — Internet Key Exchange.
Стандарт IPSec позволяет поддерживать на уровне IP потоки безопасных и аутентич-
ных данных между взаимодействующими устройствами, включая центральные компью-
теры, межсетевые экраны (сетевые фильтры) различных типов и маршрутизаторы. Ниже
приводится пример использования IPSec для обеспечения обмена аутентифицирован-
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Межсетевой экран
Удаленный
Неконтролируемая область
Рис. 8.3. Безопасность обмена данными между удаленным маршрутизатором и межсетевым экраном
ними конфиденциальными данными между удаленным маршрутизатором и межсетевым
экраном (рис. 8.3).
Прежде чем пройти через межсетевой экран предприятия, весь трафик, идущий от
удаленного маршрутизатора, должен быть аутентифицирован. Маршрутизатор и межсе-
тевой экран должны согласовать ассоциацию безопасности (SA), т. е. прийти к согласию
относительно политики в области безопасности. SA включает:
•	алгоритм шифрования;
•	алгоритм аутентификации;
•	общий ключ сессии;
•	срок действия ключа.
Ассоциация безопасности SA является однонаправленной, поэтому для двусторонней
связи нужно устанавливать две SA, по одной для каждого направления. Как правило, в обоих
случаях политика остается той же самой, но существует возможность и для асимметрич-
ной политики в разных направлениях. Согласование SA проводится через ISAKMP
Кроме того, SA могут определяться вручную. На рис. 8.4 показан процесс согласования
через ISAKMP, который происходит, когда на маршрутизатор поступает пакет, предназ-
наченный для межсетевого экрана предприятия.
Входя щи и пакет
Удаленный
маршрутизатор
Межсетевой экран
«Trustme»
«Wally»
Маршрутизатор инициирует обмен ISAKMP
DST = Campus

3 j Маршрутизатор и межсетевой экран
согласовывают следующие параметры:
• Алгоритм шифрования = 3DES
•	Алгоритм хэш-функции = Md5
•	Метод идентификации = DSS
Рис. 8.4. Согласование SA через ISAKMP
Гпава 8. Аутентификация в защищенных соединениях
IP HDR I	DATA
Хэш IP-заголовка и поля данных
IPHDR АН	DATA
Рис. 8.5. Создание нового аутентификационного заголовка IP
После согласования SA принимается решение о том. следует ли использовать сред
ства аутентификации, конфиденциальности и целостности данных или ограничиться
только аутентификацией. Если использоваться будут только средства аутентификации
текущий стандарт предполагает применение хэш-функции, а точнее алгоритма не ниж<
MD5 с 128-разрядными ключами. Заголовок пакета и данные пропускаются чере
\эш-функцию, и результаты этого вычисления вводятся в специальное поле заголовк;
АН, как показано на рис. 8.5.
Новый пакете аутентификационным заголовком, расположенным между заголовкоь
1Р и данными, отправляется через маршрутизатор в пункт назначения Когда этот паке1
попадает на межсетевой экран, последний проверяет его аутентичность, вычисляя хэи
с помощью хэш-функции, указанной в SA. Обе стороны должны использовать одни i
те же хэш-функции. Как показано на рис. 8.6, межсетевой экран сравнивает вычислен
ный им хэш с параметрами, указанными в соответствующем поле АН. Если эти вели
чины совпадают, аутентичность и целостность данных считаются доказанными (если па
кет передан из удаленной точки и при передаче не был искажен ни один бит).
Отметим, что вставка заголовка АН расширяет пакет и поэтому для данного пакет
может потребоваться фрагментация, которая производится после заголовка АН для ис
ходящих пакетов и перед ним для входящих пакетов.
Если помимо всего сказанного стороны пожелают использовать средства поддержк!
конфиденциальности, SA указывает, что весь трафик, поступающий из удаленной
маршрутизатора на межсетевой экран предприятия, должен аутентифицироваться i
шифроваться. В противном случае межсетевой экран его не пропустит. ESP поддержи
вает аутентификацию, целостность и конфиденциальность данных и работает в двух ре
жимах: туннельном и транспортном, как показано на рис. 8.7 и 8.8.
В туннельном режиме вся датаграмма IP, заголовок IP и данные встраиваются в за
головок ESP. В транспортном режиме шифруются только данные, а заголовок IP пере
дается в нешифрованном виде Современные стандарты требуют использования DES
режиме цепочки шифрованных блоков (СВС).
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Заголовок IP и поле данных
Заголовок IP и поле данных
Цифровая подпись
(OOBADDOG)
Цифровая подпись
(OOBADDOG)
Wally
TrustMe
IP HDR | AH
DATA
Рис. 8.6. Проверка аутентичности и целостности данных
Конфиденциальность с шифрованием заголовка IP и данных
Конфиденциальность с шифрованием данных
Рис. 8.8. Транспортный режим ESP
Гпава 8 Аутентификация в защищенных соединениях
Отметим, что вставка заголовка АН расширяет пакет и поэтому для данного пакет
может потребоваться фрагментация, которая производится после ESP для исходящи
пакетов и перед ESP для входящих пакетов.
8.5.5.	Выбор протокола защиты данных
Решение об использовании протоколов АН, ESP или их комбинации зависит от тре-
бований к защите IPSec. Включение в проект IPSec протокола АН обеспечит выполне-
ние следующих задач:
1.	Защита от изменения всего пакета целиком. Для зашиты пакета от изменении при
передаче протокол АН осуществляет цифровую подпись всего пакета, включая исходный
заголовок IP. Протокол АН используется для подписи пакета, когда требуется защитить
весь пакет от попыток изменить заголовок IP и маршрут пакета в сети.
2.	Взаимная аутентификация клиента и сервера. В случае АН IPSec требует взаимной
аутентификации компьютеров, участвующих в обмене данными. Аутентификация осу-
ществляется между компьютерами, а не между работающими на них пользователями.
3.	Ограничение соединений в рамках проекта только полномочными компьютерами. АН
требует взаимной аутентификации компьютеров, обменивающихся данными. Если компью-
теры не могут согласовать SA, соединения не будут установлены. АН обеспечивает уста-
новление соединения только между авторизованными компьютерами
Использование в проекте IPSec протокола ESP обеспечивает выполнение следующих
задач:
1.	Защита полезных данных приложения от просмотра во время передачи. Пакеты ESP
шифруют исходные полезные данные, не позволяя просмотреть содержимое пакета при
передаче по сети.
2.	Защита загоювка TCP/UDP и данных приложения от изменения во время передачи
Протокол ESP применяет к пакету данных цифровую подпись, но не обеспечивает защиту
всего пакета от изменения От изменения защищены только заголовок ESP, заголовок
TCP/UDP, данные приложения и трейлер ESP.
Если же надо шифровать данные и защитить весь пакет от изменения, следует приме-
нять АН и ESP одновременно. Для обеспечения общей защиты передаваемых данных
можно согласовать SA. Для этого требуются оба протокола.
Для обеспечения общей защиты передаваемых данных можно
согласовать SA, требующее наличия протоколов АН и ESP.
8.5.6.	Планирование режимов IPSec
I PSec можно использовать в одном из двух режимов: транспортном и туннельном
Иногда требуется обеспечить защиту IPSec на всем протяжении пути от клиента до сер-
вера назначения. Этот режим называется транспортным (рис. 8.9).
Зашита пересылаемых данных осуществляется с помощью протоколов АН, ESP или
обоих одновременно. Данные защищаются на всем пути между двумя компьютерами.
При использовании туннельного режима IPSec (рис. 8.10) защита данных осуществ-
ляется только между двумя определенными точками туннеля или шлюзами Туннельный
режим IPSec обеспечивает защиту данных, пересылаемых между шлюзами.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Рис. 8.10. Туннельный режим IPSec
От клиента к серверу данные до достижения начального шлюза пересылаются в не-
защищенном виде. Затем при передаче пакетов в сеть назначения к ним применяются
определенные в SA протоколы АН или ESP. На принимающем шлюзе происходит про-
цесс дешифрования и верификации данных. В конце процесса данные в виде открытого
текста передаются на целевой компьютер.
Обычно туннельный режим применяется, когда пакеты должны пройти через откры-
тую или незащищенную сеть. Туннельный режим подходит для локальных сетей, в ко-
торых нет необходимости защищать данные.
Пакеты туннельного режима IPSec отличаются от пакетов транспортного режима
тем, что при передаче между шлюзами к пакету добавляется новый заголовок IP. В него
вставляется АН-заголовок между новым и исходным заголовками IP. Поля, включенные
в заголовок аутентификации, не различаются
Аналогично пакет туннельного режима ESP отличается от пакета транспортного ре-
жима ESP расположением заголовка ESP. Как и в пакете туннельного режима АН, за-
головок ESP помещается между новым и старым заголовками 1Р.
Гпава 8. Аутентификация в защищенных соединениях
Поля, включенные в ESP-заголовок в туннельном и транспортном режимах, не раз-
личаются. Единственное отличие — местоположение ESP-заголовка в пакете туннель-
ного режима и защите информации исходного IP-заголовка.
Пакеты туннельного режима IPSec отличаются от пакетов
транспортного режима тем, что при передаче между
шлюзами к пакету добавляется новый заголовок IP.
8.5.7.	Аутентификация при использовании протокола IPSec
Перед согласованием SA участники IPSec-соединения должны взаимно аутентифи-
цироваться одним из трех способов:
1.	Kerberos. Стандартный механизм проверки подлинности в Windows 2000/2003
обеспечивает стойкую аутентификацию и легко настраивается, так как все компьютеры
с Windows 2000/2003 осуществляют аутентификацию с аналогичными компьютерами
в лесу, не требуя дополнительной настройки Но Kerberos не годится для аутентифика-
ции между лесами.
2.	Сертификаты. Для аутентификации участников сети на основе сертификатов в сеансе
IPSec. Для этого сертификаты должны быть выданы центром сертификации (СА), ко-
торому доверяют оба компьютера. Сертификаты обеспечивают надежную аутентифика-
цию для компьютеров в разных сетях. Компьютеры должны получить сертификаты для
аутентификации до начала согласования SA IPSec.
3.	Общие секретные ключи. Общие ключи представляют собой текстовые строки, вве-
денные на обоих компьютерах для подтверждения их подлинности. Использование об-
щих ключей возможно, когда нельзя применять Kerberos или сертификаты, или при тес-
тировании фильтров IPSec перед внедрением параметров IPSec в сети.
8.5.8.	Алгоритмы шифрования и проверки целостности IPSec
Свойства фильтров IPSec настраиваются для определения алгоритмов IPSec, приме-
няемых при согласовании безопасности. Для потоков данных, защищенных протокола-
ми АН и ESP, можно использовать разные алгоритмы.
Если требуется защита АН. в качестве алгоритма проверки целостности можно ис-
пользовать алгоритмы Message Digest v5 (MD5) или Secure Hash Algorithm vl (SHA1). Если
требуется шифрование ESP, используется алгоритм цифровой подписи MD5 или SHAT
и алгоритм шифрования Data Encryption Standard (DES) или Triple DES (3DES). Алгоритм
проверки целостности SHAI считается сильнее MD5. а алгоритм шифрования 3DES —
сильнее DES.
8.5.9.	Фильтры протокола IPSec
Для идентификации протоколов, которые необходимо защитить средствами АН или
ESP, надо определить I PSec-фильтры. Для идентификации протокола используются сле-
дующие характеристики:
•	IP-adpec источника. Может быть конкретным 1Р-адресом. IP-адресом определен-
ной подсети или любым адресом.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
•	IP-адрес назначения Может быть конкретным IP-адресом. IP-адресом определен-
ной подсети или любым адресом
•	Тип протокола. Это идентификатор протокола или используемый транспортный
протокол. Например. РРТР использует пакеты GRE, которые определяются по их
идентификатору протокола (47). С другой стороны, Telnet использует в качестве
транспортного протокола TCP, поэтому в IPSec-фильтре дтя Telnet нужно указы-
вать тип протокола как TCP.
•	Порт источника. Если используются протоколы TCP ши UDP. для защищенного
соединения можно определить порт источника В зависимости от протокола порт
источника устанавливается для конкретного или произвольного порта. Большин-
ство протоколов в качестве порта источника используют случайный порт.
•	Порт назначения. Если применяется TCP или UDP, то для получения данных слу-
жит конкретный порт на сервере Например. Telnet настраивает сервер для про-
слушивания соединении на ТСР-порте 23.
После определения защищаемых протоколов следует задать действия, предприни-
маемые в случае соответствия принимаемых или получаемых пакетов фильтру IPSec
Действия фильтра IPSec могут быть следующие:
•	Разрешить (Permit) передачу пакетов без защиты IPSec. Например, протокол
SNMP включает поддержку устройств, не совместимых с IPSec. Включение IPSec
для протокола SNMP может помешать этим устройствам управлять сетью. Для
разрешения передачи пакетов SNMP без защиты IPSec в сетях с высокой безопас-
ностью можно создать специальный фильтр IPSec для SNMP.
•	Блокировать (Block) — запрещает существование в сети протокола, соответствую-
щего IPSec-фильтру. Все пакеты, подпадающие под условия этого фильтра, от-
брасываются.
•	Согласовать безопасность (Negotiate Security) — позволяет администратору опре-
делить уровень шифрования и алгоритм хэширования для зашиты трафика, со-
ответствующего фильтру IPSec.
Если для установления виртуальной частной сети применяется протокол Layer Two
Tunneling Protocol (L2TP), определять фильтры IPSec для включения зашиты IPSec в сети
Windows 2000/2003 не нужно. Windows 2000/2003 автоматически включает защиту IPSec
для туннеля L2TP. В этом случае нет необходимости определять фильтры IPSec, так как
Windows 2000 средствами ESP автоматически защищает данные, пересылаемые по тун-
нелю L2TP.
I PSec не может защитить:
•	Широковещательные IP-адреса. Фильтры IPSec можно определять только для от-
дельных получателей пакетов. Для пакетов, предназначенных нескольким полу-
чателям, определить IPSec нельзя, так как SA должны быть установлены между
парами компьютеров
•	Групповые адреса. Как и в случае с широковещательными сообщениями нельзя
обеспечить защиту пакетов, отправляемых нескольким получателям. Групповые
адреса включают все IP-адреса класса D (224.0.0.0-237.255.255.255).
•	Протокол Resource ReSerVation Protocol (RSVP). Для запроса части пропускной
способности сети компьютер использует протокол RSVP (идентификатор прото-
кола 46). Служба IPSec может защитить протокол, для которого RSVP запраши-
вает качество обслуживания, но не сами RSVP-пакеты этого запроса.
•	Протокол Kerberos. Протокол Kerberos используется для аутентификации двух
компьютеров, участвующих в обмене данными IPSec. Защита аутентификации
Kerberos осуществляется протоколом Kerberos и не требует защиты I PSec.
Гпава 8. Аутентификация в защищенных соединениях
•	Протоко.1 Internet Key Exchange (IKE). Протокол IKE применяется дня согласова-
ния SA между двумя компьютерами, участвующими в передаче данных IPSec. Про-
цесс согласования IPSec шифровать нельзя. Согласование осуществляется с по-
мощью пакетов с открытым текстом. При этом определяется порядок защиты сле-
дующих пакетов.
Чтобы обеспечить соответствие фильтров потребностям предприятия, при их разра-
ботке нужно учитывать следующее:
•	Для одного компьютера можно назначать только одну политику IPSec. Если фильт-
рованию нужно подвергнуть несколько разных протоколов, необходимо создать
перечень фильтров, включающий все протоколы, и вставить его в список фильтров.
•	В среде Windows политики IPSec определяются не для пользователей, а для
компьютеров. Фильтры IPSec определяются только для компьютеров в сети. При
этом не имеет значения, кто из пользователей работает на компьютере.
•	Для выбора правильного фильтра нужно задать требования к протоколу. Необхо-
димо определить следующие атрибуты для каждого фильтра:
1)	IP-адрес источника;
2)	порт источника;
3)	IP-адрес назначения;
4)	порт назначения;
5)	тип протокола.
•	Идентифицировать шифрованный трафик IPSec при прохождении через межсете-
вой экран нельзя. Если к пакету был применен протокол ESP. определить, какой
протокол зашифрован в пакете, невозможно. Это может привести к тому, что через
межсетевой экран сможет пройти нежелательный трафик, если межсетевой экран
настроен на 1КЕ-пакеты (UDP-порт 500) и ESP-пакеты (идентификатор прото-
кола 50). Так как данные в пакете зашифрованы, межсетевой экран не может оп-
ределить. какой исходный протокол был защищен IPSec.
•	Если определено несколько фильтров, первым вычисляется наиболее конкретный
из них, а наименее конкретный — последним. Порядок вывода на экран при этом
не имеет значения.
•	В случае транспортного режима IPSec всегда следует применять пакетные фильт-
ры с отражением. Отражение обеспечивает шифрование ответных пакетов при их
передаче обратно источнику. В ответных пакетах информация об источнике и на-
значении будет обращена. Отражение правил обеспечивает шифрование ответов
•	При определении соединений туннельного режима IPSec для каждого направле-
ния следует создавать фильтр IPSec. Для туннельного режима IPSec нельзя ис-
пользовать отраженные пакетные фильтры, так как для заголовка трафика на каж-
дом направлении должны быть заданы разные конечные точки туннеля.
8.5.10. Преимущества протокола IPSec
К преимуществам поддержки безопасности на сетевом уровне с помощью IPSec сле-
дует отнести:
•	поддержку совершенно ^модифицированных конечных систем, хотя в этом слу-
чае шифрование нельзя назвать в полном смысле слова сквозным (end-to-end):
•	частичную поддержку виртуальных частных сетей (VPN) в незащищенных сетях:
• поддержку других транспортных протоколов а не только TCP (например UDP):
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
•	защиту заголовков транспортного уровня от перехвата и, следовательно, более на-
дежную защипу ют агализа трафика;
•	при использовании АН и средств обнаружения повторяющихся операций обес-
печивается зашита от атак типа «отказ от обслуживания», основанных на «затоп-
лении» систем и енухной информацией (например, от атак TCP SYN)
8.6. Протгоколы защищенного взаимодействия
и аутентификации для корпоративных
беспроводных локальных сетей
На сегодняшний доен ь лшеры рынка предлагают ряд технологии, которые существенно
повышают безопасноостъ корпоративных сетей WLAN, предоставляющую следующие
возможности для кли ентских устройств WLAN:
•	Поддержка сташдартаIEEE 802.11 i.
•	Поддержка сертификатов безопасности Wi-Fi Alliance — Wi-Fi Protected Access
(WPA) и Wi-Fi Protecied Access 2 (WPA2).
•	Двусторонняя ааутентгфикация и управление динамическими ключами шифрова-
ния благодаря  о»ддеркке IEEE 802.IX.
•	Шифрование дгаг ныхс помощью алгоритмов Advanced Encryption Standard (AES)
или Temporal Kley Integrity Protocol (TKIP)
•	Поддержка тигпов аутентификации 802. IX, клиентских устройств и клиентских
операционных «сггстем
•	Подавление актгивныхи пассивных сетевых атак.
•	Интеграция с ре-шенияии Network Admission Control (NAC) компании Cisco Systems.
•	Предотвращение сетеьых вторжений (Intrusion Prevention System, IPS) и слежения
за перемещением абонента — прозрачное представление сети в реальном времени.
•	Конвергенция бе опасности внутренней и внешней сетей Wi-Fi.
Главным постулатов безопасности любой сети, не только беспроводной, является уп-
равление доступом и конфиденциальностью. Одним из надежных способов управления
доступом к WLAN яв_ляется аутентификация, позволяющая предотвратить доступ не-
санкционированных псол ьзователей к передаче данных через точки доступа. Действенные
меры управления доступом к WLAN помогают определить круг разрешенных клиентских
станций и связать их только с доверенными точками доступа, исключая несанкциони-
рованные или опасные точкидоступа В настоящее время компании, использующие сети
WLAN, внедряют четьпре отдельных решения для безопасности WLAN и управления до-
ступом и конфиденциаальнос ью:
•	открытый доступ!;
•	базовая безопасность;
•	повышенная безопасность;
•	безопасность удаленного доступа.
8.6.1.	Открытый доступ
Все продукты для беспроводных локальных сетей, соответствующие спецификациям
Wi-Fi, например продукты серии Cisco Aironet, поставляются для работы в режиме откры-
того доступа с выключ енными функциями безопасности. Открытый доступ или отсут-
Гпава 8. Аутентификация в защищенных соединениях
ствие безопасности могут устраивать и удовлетворять требования общественных хот-спо-
тов, таких как кофейни, университетские городки, аэропорты или другие общественные
места, однако для предприятий этот вариант не подходит. Функции безопасности должны
быть включены на беспроводных устройствах в процессе их установки. Некоторые ком-
пании, однако, не включают функции безопасности сетей WLAN, и тем самым повы-
шают уровень риска для своих сетей.
8.6.2.	Базовая безопасность
Базовая безопасность заключается в использовании идентификаторов сети SS1D
(Service Set Identifier), открытой аутентификации, аутентификации с помощью общих и
статических WEP-ключей и аутентификации по МАС-адресу. С помощью этой комби-
нации можно настроить элементарные средства управления доступом и конфиденци-
альностью, однако каждый отдельный элемент такой защиты может быть взломан.
Идентификатор SS1D — общее имя сети для устройств в подсистеме WLAN — служит
Д1Я логического обособления данной подсистемы. Он предотвращает доступ любого кли-
ентского устройства, не имеющего SSID. Однако по умолчанию точка доступа передает
в эфир среди своих сигналов и свой SSID. Даже если отключить передачу в эфир SSID,
взломщик или хакер может обнаружить нужный SSID с помощью скрытого мониторинга
сети. Стандарт 802.11, группа спецификаций для сетей WLAN, выработанная IEEE, под-
держивает два средства аутентификации клиента: открытую аутентификацию и аутен-
тификацию с помощью открытых ключей.
Идентификатор SSID — общее имя сети для устройств
в подсистеме WLAN, служит для логического обособления
данной подсистемы
Открытая аутентификация лишь ненамного отличается от предоставления правильного
идентификатора SSID. При аутентификации с помощью открытых ключей точка доступа
посылает на клиентское устройство тестовый текстовый пакет, который клиент должен
зашифровать правильным WEP-ключом и вернуть на точку доступа. Без правильного
ключа аутентификация будет прервана и клиент не будет допущен в группу пользовате-
лей точки доступа.
Аутентификация с помощью общих ключей считается ненадежной, поскольку взлом-
щик, получивший в свое распоряжение начальное тестовое текстовое сообщение и это же
сообщение, зашифрованное WEP-ключом, может дешифровать сам WEP-ключ. При от-
крытой аутентификации, даже если клиент проходит аутентификацию и получает доступ
в групп} пользователей точки доступа, WEP-защита не позволяет клиенту передавать
данные с этой точки доступа без правильного WEP-ключа.
WEP-ключи могут состоять из 40 или 128 бит и обычно статически определяются сетевым
администратором на точке доступа и каждом клиенте, передающем данные через эту точку
тоступа. При использовании статических WEP-ключей сетевой администратор должен
потратить много времени на ввод одинаковых ключей в каждое устройство сети WLAN.
Если устройство, использующее статические WEP-ключи, потеряно или украдено,
обладатель пропавшего устройства может получить доступ к сети WLAN. Администратор
не сможет определить, что в сеть проник несанкционированный пользователь до тех пор.
пока не будет известно о пропаже, Послб этого администратор должен сменить WEP-ключ
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
на каждом устройстве, использующем тот же статический WEP-ключ, что и пропавшее
устройство. В сети крупного предприятия, включающей сотни или даже тысячи поль-
зователей, это может оказаться невыполнимым Если же статический WEP-ключ был де-
шифрован с помощью такого инструмента, как AirSnort, администратор никак не узнает
о том, что ключ был взломан несанкционированным пользователем.
Некоторые поставщики решений WLAN поддерживают аутентификацию на базе фи-
зического или МАС-адреса, клиентской сетевой карты (NIC). Точка доступа позволит
клиенту ассоциироваться с точкой доступа только в случае, если МАС-адрес клиента со-
ответствует одному из адресов в таблице аутентификации, используемой точкой доступа.
Однако аутентификация по МАС-адресу не является адекватной мерой безопасности,
поскольку МАС-адрес можно подделать, а сетевую карту — потерять или украсть.
Другая форма доступной на сегодняшний день базовой безопасности — это WPA или
WPA2 с помощью общих ключей (Pre-Shared Key, PSK). Общий ключ проверяет пользо-
вателей с помощью пароля или кода идентификации (также называемого «фраза—пароль»)
как на клиентской станции, так и на точке доступа. Клиент может получить доступ к се-
ти только в том случае, если пароль клиента соответствует паролю точки доступа. Общий
ключ также предоставляет данные для генерации ключа шифрования, который исполь-
зуется алгоритмами TKIP (Tenporal Integrity Protocol) или AES для каждого пакета пе-
редаваемых данных. Являясь более защищенным, чем статический WEP-ключ, общий
ключ также хранится на клиентской станции и может быть взломан, если клиентская
станция потеряна или украдена. Рекомендуется использовать общую фразу-пароль, вклю-
чающую разнообразные буквы, цифры и не алфавитно-цифровые символы
Выводы. Базовая безопасность сетей WLAN, основанная на комбинации SSID, откры-
той аутентификации, статических WEP-ключей, МАС-аутентификации и общих ключей
WPA/WPA2, является достаточной только для очень небольших компаний или тех, кото-
рые не доверяют жизненно важные данные своим сетям WLAN. Всем прочим организа-
циям рекомендуется вкладывать средства в надежные решения безопасности сетей WLAN
класса предприятия.
Некоторые поставщики решений WLAN поддерживают
аутентификацию на базе физического адреса или
МАС-адреса клиентской сетевой карты (NIC).
8.6.3.	Повышенная безопасность
Повышенный уровень безопасности рекомендуется для тех компаний, которым требу-
ется безопасность и защищенность класса предприятия. При этом для обеспечения без-
опасности повышенного уровня, полностью поддерживаемого WPA и WPA2 с двусторон-
ней аутентификацией 802.1х и шифрования алгоритмами TKIP и AES, целесообразно
реализовать следующие возможности:
•	802.IX для двусторонней аутентификации и динамических ключей шифрования
для каждого пользователя и каждой сессии;
•	TKIP для расширения шифрования на базе RC4, например, для хэширования клю-
чей (для каждого пакета), проверки целостности сообщения (MIC), изменений
вектора инициализации (IV) и ротации широковещательных ключей;
•	AES для шифрования данных максимальной защищенности;
•	интеграция с Cisco Self-Defending Network и NAC;
Гпава 8. Аутентификация в защищенных соединениях
9 возможности системы предотвращения сетевых вторжений (Intrusion Prevention
System, IPS) и слежения за перемещением абонента — прозрачное представление сети
в реальном времени.
Решение по обеспечению повышенного уровня безопасности, как правило, должно
предоставлять:
•	Безопасное подключение к сетям WLAN — динамические ключи шифрования
должны автоматически изменяться в соответствии с настройками для обеспе-
чения конфиденциальности передаваемых данных
— Шифрование WPA-TKIP должно расширяться такими функциями, как про-
верка целостности сообщения (MIC), хэширование ключей (для каждого пакета),
изменение вектора инициализации (IV) и ротация широковещательных ключей.
— WPA2-AES, «золотой эталон» шифрования данных.
•	Доверительные отношения и идентификацию в сетях WLAN. Надежное управление
доступом к WLAN должно обеспечивать подключение уполномоченных клиентов
только к доверенным точкам доступа и исключать неавторизованные точки доступа.
Для этого должна применяться двусторонняя аутентификация каждого пользова-
теля и каждой сессии с применением IEEE 802. IX, разнообразных типов расши-
ряемого протокола аутентификации (Extensible Authentication Protocol, ЕАР) и
сервера аутентификации RADIUS (Remote Authentication Dial-In User Service) или
сервера аутентификации, авторизации и учета AAA (Authentication. Authorization
and Accounting).
— Поддержка типов аутентификации 802. IX, клиентских устройств и клиент-
ских операционных систем.
— Поддержка записей биллинга протокола RADIUS для всех попыток аутен-
тификации.
•	Защиту от атак на сети WLAN. Обнаружение несанкционированного доступа се-
тевых атак и несанкционированных точек доступа с помощью надежных средств
предотвращения вторжений IPS, WLAN NAC и расширенных сервисов обнаруже-
ния местоположения. Необходимо использовать средства предотвращения сетевых
вторжении (IPS) класса предприятия, позволяющие непрерывно сканировать радио-
диапазон, обнаруживать несанкционированные точки доступа и прочие несанк-
ционированные события
Протокол NAC Network Admission Control был специально разработан для адекватной
защиты всех проводных и беспроводных оконечных устройств (таких как персональные
компьютеры, ноутбуки, серверы и КПК), обращающихся к сетевым ресурсам, от угроз
безопасности Использование протокола NAC позволяет организациям анализировать и
контролировать все устройства, подключающиеся к сети.
8.6.4.	Поддержка WPA и WPA2
WPA был представлен Wi-Fi Alliance в 2003 г., a WPA2 был представлен Wi-Fi Alliance
в 2004 г. Все продукты, сертифицированные Wi-Fi на соответствие требованиям WPA2
обязательно взаимодействуют с продуктами, сертифицированными Wi-Fi на соответствие
требованиям WPA. Cisco Unified Wireless Network включает поддержку сертифицирован-
ных Альянсом Wi-Fi механизмов WPA и WPA2.
WPA и WPA2 предоставляют конечным пользователям и сетевым администраторам вы-
сокий уровень уверенности в том, что их данные останутся конфиденциальными, а доступ
к их сетям будет предоставляться только санкционированным пользователям. Оба стан-
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Сравнение типов режимов WPA и WPA2
Таблица 8.1
	И7М	WPA2
Корпоративный режим (коммерче- ские, правительственные, образова- тельные структуры)	• Аутентификация: IEEE 802.1Х/ЕАР • Шифрование: TKIP/MIC	• Аутентификация: IEEE 802 IX/ЕАР • Шифрование: AES-CCMP
Персональный режим (небольшие компании, домашние и персональные системы)	• Аутентификация: PSK • Шифрование: TKIP/M1C	• Аутентификация: PSK • Шифрование: AES-CCMP
дарта обладают персональным и корпоративным режимами работы, удовлетворяющими
отдельным требованиям этих двух сегментов рынка. Корпоративный режим использует
для аутентификации IEEE 802.IX и ЕАР, а персональный режим — общие ключи (PSK).
Не рекомендуется применять персональный режим для коммерческих или государствен-
ных решений из-за использования общих PSK-ключей при аутентификации пользователей.
PSK-ключи не считаются достаточно надежной мерой для внедрения на предприятии.
WPA позволяет закрыть все известные уязвимости WEP исходного стандарта безопас-
ности IEEE 802.11. Представляет собой быстрое решение для обеспечения безопасности
сетей WLAN как для предприятий, так и для небольших компаний или домашних систем.
WPA использует алгоритм шифрования TKIP.
WPA2 — это следующее поколение безопасности Wi-Fi. Он представляет собой пред-
ложенный Wi-Fi Alliance вариант ратифицированного стандарта IEEE 802.1 li. В его состав
входит рекомендованный Национальным институтом стандартов и технологий (NIST)
алгоритм шифрования AES, использующий протокол ССМР (Counter Mode with Cipher
Block Chaining Message Authentication Code Protocol) WPA2 обеспечивает соответствие
требованиям правительственного стандарта FIPS 140-2 (табл. 8.1).
И/РД позволяет закрыть все известные уязвимости WEP
исходного стандарта безопасности IEEE 802.11, WPA2
представляет собой предложенный Wi-Fi Alliance вариант
ратифицированного стандарта IEEE 802.1П.
8.6.5.	IEEE 802.1Х-аутентификация и протокол ЕАР
(Extensible Authentication Protocol)
IEEE приняла 802. IX в качестве стандарта аутентификации для проводных и беспро-
водных сетей. 802. IX поддерживается корпоративными режимами WPA и WPA2. 802.IX
предоставляет сетям WLAN средства мошной двусторонней аутентификации между кли-
ентом и сервером аутентификации. В дополнение к этому, 802.IX предоставляет дина-
мические ключи шифрования для каждого пользователя и каждой сессии, избавляя та-
ким образом администраторов от необходимости обслуживания ненадежных статических
ключей шифрования.
Средствами 802. IX конфиденциальная информация, используемая для аутентификации,
такая, как пароли для входа, никогда не передается в открытом виде без шифрования по
беспроводным сетям. 802. IX обеспечивает надежную аутентификацию для беспроводных
локальных сетей, однако для шифрования дополнительно к 802.IX необходимы алго-
Гпава 8. Аутентификация в защищенных соединениях
мы TKIP и AES, поскольку стандартное WEP-шифрование стандарта 802 11 уязвимо
перед сетевыми атаками.
Существует несколько типов 802,1Х-аутентификации, предоставляющих различные
подходы к аутентификации, однако, опирающихся на единую структуру, и протокол ЕАР
с целью обеспечения передачи данных между клиентом и точкой доступа. К ним отно-
сятся следующие: Cisco LEAP, ЕАР-Flexible Authentication via Secure Tunneling (EAP-FAST),
ЕАР-Transport Layer Security (ЕАР-TLS), Protected Extensible Authentication Protocol
(PEAP), ЕАР-Tunneled TLS (EAP-TTLS) и ЕАР-Subscriber Identity Module (EAP-SIM)
Для выбора наиболее подходящего типа ЕАР-аутентификации для развертывания 802. IX.
рекомендуется провести анализ собственных сетей и систем безопасности. При выборе
типа ЕАР следует обращать внимание на механизм обеспечения безопасности, используе-
мый для передачи данных для аутентификации, базу данных аутентификации пользова-
телей используемые клиентами операционные системы, доступные клиентам способы
обращения, тип необходимого входа пользователей в сеть, а также наличие серверов
RADIUS или ААА.
Разница между уровнями безопасности зависит от типа управляемости ЕАР, поддер-
живаемых операционных систем, клиентских устройств, преимуществ клиентского про-
граммного обеспечения и передачи аутентификационных данных, требовании сертифи-
кации, простоты использования и поддержки устройств инфраструктурой WLAN. Кроме
того, возможно применение нескольких типов ЕАР в рамках сети — для поддержки спе-
цифического типа аутентификации, клиентского устройства или потребностей конечных
пользователей.
Для аутентификации по 802. IX может быть использован широкий ассортимент серверов
RADIUS, таких, например, как Cisco Secure Access Control Server (ACS) и AAA RADIUS-сер-
веров различных производителей, например, Interlink Networks (AAA RADIUS).
Применение одного из типов 802.1Х-аутентификации, позволяющего аутентифици-
ровать клиентскую станцию с помощью вводимых пользователем данных, а не физиче-
ских атрибутов клиентского устройства, дает возможность понизить риск, связанный
с потерей устройства или его сетевой карты WLAN. 802. IX предоставляет и другие пре-
имущества, включая снижение опасности появления угрозы «человек посередине»
(«man-in-the-middle») при аутентификации, централизованное управление шифровани-
ем ключей с ротацией ключей на базе установленной политики, а также защиту от атак,
осуществляемых методом перебора ключей (brute-force) (рис. 8.11).
Применение одного из типов 802.1Х-аутентификации,
позволяющего аутентифицировать клиентскую станцию
с помощью вводимых пользователем данных,
дает возможность понизить риск, связанный с потерей
устройства или его сетевой карты WLAN.
Другим преимуществом 802.1Х-аутентификации является централизованное управле-
ние группами пользователей сетей WLAN, включающее ротацию ключей на базе политик,
динамическое распределение ключей, динамическое назначение VLAN и запрет SSID, Эти
функции осуществляют ротацию ключей шифрования. Они также позволяют назначить
пользователям определенные VLAN-сети для гарантии того, что пользователи имеют до-
ступ только к определенным ресурсам.
После удачного проведения двусторонней аутентификации и клиент, и RADIUS-сер-
вер генерируют одинаковые ключи шифрования, используемые для шифрования всех пере-
121
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
2. Точка доступа блокирует
все пользовательские запросы
на доступ в локальную сеть
1. Клиент ассоциируется
с точкой доступа
Автономная точка Коммутатор
доступа Cisco
Aironet 1240 AG
Беспроводной клиент
с поддержкой ЕАР-Fast
RADIUS-сервер
БД пользователя
Кампусная Сеть
3 Пользователь предоставляет
данные учетной записи_______
БД пользователя
RADIUS-сервер с поддержкой
аутентификации EAP-Fast и динамической
генерацией ключей шифрования
Кампусная Сеть
4. RADIUS-сервер аутентифицирует Пользователя.
Пользователь аутенфицирует RADIUS-сервер
Автономная точка Коммутатор
доступа Cisco
Aironet 1240 AG
Беспроводной клиент
с поддержкой EAP-Fast
8. Клиент и Точка Доступа
включают шифрование
5. RADIUS-сервер передает
ключ Pair-wise Master
Key (РМК) Точке Доступа
7. Точка доступа шифрует
широковещательный ключ
и предоставляет его Клиенту
6. Точка доступа и Клиент
обмениваются сообщениями,
чтобы получить ключи шифрования
Рис. 8.11. Применение EAP-FAST одного из типов 802. IX
для обеспечения безопасности класса предприятия
даваемых данных. По защищенному каналу проводной локальной сети RADIUS-сервер
посылает этот ключ автономной точке доступа или беспроводному контроллеру локаль-
ной сети, которые сохраняют его для клиента. В результате мы имеем ключи шифрова-
ния для каждого пользователя и каждой сессии, а продолжительность сессии определя-
ется политикой на RADIUS-сервере. После окончания сессии или при переходе клиента
с одной точки доступа на другую происходит процесс повторной аутентификации, в ре-
зультате которой генерируется новый ключ сессии. Повторная аутентификация прохо-
дит незаметно для пользователя
Параметры имени/идентификатора VLAN и параметры SSID передаются на автоном-
ную точку доступа или контроллер беспроводной локальной сети вместе с ключами
шифрования и таймером повторной аутентификации. После получения автономной точ-
кой доступа или контроллером беспроводной локальной сети имени/идентификатора
VLAN, назначаемого для указанного пользователя, он указывает данного пользователя
в метке указанного имени/идентификатора VLAN. В случае, если точке доступа или
контроллеру также передается список разрешенных SSID, точка доступа или контроллер
пытаются обеспечить данного пользователя действительным SSID для доступа к сети
WLAN. Если пользователь предоставляет SSID, не указанный в списке разрешенных
SSID, точка доступа или контроллер беспроводной локальной сети удаляет ассоциацию
с пользователем из сети WLAN.
122
Гпава 8. Аутентификация в защищенных соединениях
Снижение риска атак, осуществляемых методом перебора ключей (brute-force). Тради-
ционные схемы WLAN на основе статических ключей шифрования легко поддаются
взлому сетевыми атаками, осуществляемыми методом перебора ключей. Атака представ-
ляет собой попытку взломщика получить ключ шифрования путем перебора. Для взлома
стандартной 128-битовой WEP-защиты потребуется перебрать максимум 2104 разных
ключей. Использование динамических ключей шифрования стандарта 802. IX, получаемых
каждым пользователем для каждой сессии делает атаку методом перебора ключей хоть и
теоретически возможной, но крайне сложной для проведения и практически бесполезной.
8.6.6.	WPA-шифрование, протокол целостности
временных ключей Temporal Key Integrity Protocol
TKIP представляет собой следующее поколение стандарта обеспечения безопасности
WEP. Как и WEP, TKIP использует метод шифрования, разработанный инженером Роном
Раивестом и известный как алгоритм шифрования Ron's Code 4 (RC4) Однако TKIP улуч-
шает WEP ta счет ликвидации известных уязвимостей WEP и добавления таких функций,
как хэширование ключа каждого пакета, MIC и ротация широковещательных ключей.
TKIP реализует RC4-кодирование потока 128-битовыми ключами для шифрования и
64-битовыми ключами для аутентификации. За счет шифрования данных ключом, кото-
рый может быть использован только предписанным пользователем этих данных, TKIP
позволяет гарантировать получение передаваемых данных в открытом виде только теми,
для кого они предназначены. Шифрование TKIP приводит к 280 триллионам возможных
комбинаций ключей для каждого отдельного пакета данных.
TKIP реализует ЯС4-кодирование потока 128-битовыми ключами
для шифрования и 64-битовыми ключами для аутентификации.
Например, в рамках решения Cisco Unified Wireless Network реализованы алгоритмы
Cisco TKIP и WPA TKIP для автономных точек доступа Cisco Aironet, устройств Cisco
Aironel и совместимых с Cisco клиентских устройств для работы с беспроводной локаль-
ной сетью. Несмотря на то, что Cisco TKIP и WPA TKIP не могут взаимодействовать друг
с другом, автономные точки доступа серии Cisco Aironet могут работать одновременно
в этих режимах при использовании нескольких VLAN. Системным администраторам
требуется выбрать один набор TKIP-алгоритмов для активации на клиентских устрой-
ствах предприятия, поскольку клиенты не могут поддерживать оба набора TKIP-алго-
ритмов одновременно. Cisco рекомендует по возможности использовать для клиентских
устройств и точек доступа алгоритм WPA TKIP. Контроллеры беспроводной локальной
сети Cisco и простые точки доступа Cisco Aironet поддерживают только WPA TKIP.
Хэширование ключей дзя каждого пакета с целью снижения риска атак типа «Слабый
вектор инициализации» (Weak IV). При использовании WEP-ключа для шифрования
(дешифрования) передаваемых данных каждый пакет включает вектор инициализации (IV),
представляющий собой 24-битовое поле, меняющееся с каждым пакетом. Алгоритм
обновления ключей TKIP RC4 генерирует вектор на базе основного WEP-ключа. Уязви-
мость в реализации WEP-алгоритма RC4 позволяет создавать «слабые» векторы, дающие
возможность взлома основного ключа. С помощью таких инструментов, как AirSnort
взломщик может воспользоваться данной уязвимостью путем сбора пакетов, шифрован-
ных одним ключом и подстановки слабых векторов инициализации для нахождения ос-
новного ключа.
123
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Фильтрация
между сетями
RFC 2827
DHCP/
RADIUS
OTP/PKI-сервсры
Беспроводной клиент
ЕАР и TKIP
Автономная точка доступа
с поддержкой ЕАР и TKIP
Аутентификация ЕАР
Динамическое создание
ключей
Сканирование на наличие
вирусов. Аутентификация ЕАР
TKIP (Улучшение шифрования)
Динамическая генерация ключей
Аутентификация ЕАР
TKIP (Улучшение
шифрования)
Рис. 8.12. Снижение риска атак для схемы беспроводной локальной сети с использованием
WPA-802.1X EAP/TKIP
TKIP содержит средства хэширования ключей или создания ключей для каждого пакета
для снижения риска атак с использованием слабых векторов инициализации. При вне-
дрении поддержки хэширования ключей как на точке доступа, так и на всех ассоцииро-
ванных клиентских устройствах, отправитель данных хэширует базовый ключ с помощью
вектора инициализации для создания нового ключа для каждого пакета. Обеспечивая
шифрование каждого пакета своим ключом, хэширование ключа снимает вероятность
определения WEP-ключа с помощью уязвимости векторов инициализации (рис. 8.12).
Message Integrity Check, проверка целостности сообщения для защиты от активных се-
тевых атак. Использование MIC позволяет избежать активных сетевых атак, нацеленных
на поиск ключа шифрования, применяемого для шифрования перехваченных пакетов.
При внедрении MIC как на точке доступа, так и на всех ассоциированных клиентских
устройствах отправитель пакета данных добавляет несколько байтов (для проверки це-
лостности сообщения) к пакету перед его шифрованием и отправкой. При получении
пакета получатель дешифрует его и проверяет байты MIC. Если байты MIC пакета со-
ответствуют расчетным данным (рассчитываемым из функции MIC), получатель при-
нимает пакет; в противном случае получатель уничтожает пакет С помощью MIC ста-
новится возможным отбрасывать пакеты, измененные злоумышленниками.
Ротация широковещательных ключей. TKIP позволяет сетевым администраторам
осуществлять ротацию как присвоенных конкретному устройству, так и широковещатель-
ных ключей, используемых для шифрования широковещательных и мультивешательных
сообщений. Сетевые администраторы могут конфигурировать политики ротации широ-
ковещательных ключей для точек доступа Поскольку статический широковещательный
ключ подвержен тем же атакам, что и присвоенные конкретному устройству или стати-
ческие WEP-ключи, поддерживается ротация значений ключа для широковещательных
ключей, позволяющая закрыть эту уязвимость.
Контрольные вопросы
1.	Какие возможности обеспечивает протокол SSL для безопасности связи9
2.	Что включает в себя ассоциация безопасности?
3.	Перечислите способы аутентификации при использовании протокола IPSec
4.	Какие протоколы IPSec защитить не может?
5.	Преимущества протокола IPSec?
124
Глава 9
ПРИМЕНЕНИЕ АППАРАТНЫХ СРЕДСТВ
АУТЕНТИФИКАЦИИ И ХРАНЕНИЯ
КЛЮЧЕВОЙ ИНФОРМАЦИИ
9.1.	Аппаратные средства защиты
в современных РК1-решениях
По оценкам компании IDC примерно 74% финансовых потерь связано с проблемами
так называемого «человеческого фактора». Для сравнения, потери от вирусных и хакер-
ских атак составляют соответственно 4 и 2%.
Поэтому важнейшими приоритетными задачами обеспечения информационной без-
опасности (ИБ) является снижение риска, связанного с человеческим фактором (нена-
дежность паролей, сложность их выбора и смены, ошибки администрирования и т. п.).
Таким образом, нельзя построить защищенную систему, не обеспечив надежное ре-
шение проблемы «трех А»:
•	аутентификации (ответа на вопрос «Ты кто и как ты можешь доказать, что ты —
это ты?»);
•	авторизации («Какие у тебя есть полномочия на доступ к информации и права на
работу в системе?»);
•	администрирования («Как безопасно управлять и централизованно администри-
ровать всю информационную систему?»).
Практически все ведущие продавцы, разработчики операционных систем, систем ИБ,
ERP-систем и бизнес-приложений (Microsoft, Novell. Linux, IBM, Oracle, Cisco, SAP,
Check Point и др.) поддержали PKI и включили в состав своих продуктов поддержку сов-
ременных средств двухфакторной аутентификации (смарт-карты, USB-ключи) для без-
опасного хранения закрытых ключей и удобной работы с цифровыми сертификатами,
обеспечив тем самым надежное решение проблемы «трех А».
В данной главе приводится сравнение существующих аппаратных и программных
средств защиты закрытых ключей пользователя, применяемых в современных PKI-ре-
шениях. Показывается, что использование программных контейнеров для хранения за-
крытых ключей пользователя в памяти компьютера, который сам по себе является потен-
циально небезопасным, или на отчуждаемом носителе является недостаточным для того,
чтобы обеспечить должный уровень безопасности закрытого ключа пользователя. В связи
с чем РК1-решения, предполагающие применение таких средств, заведомо уязвимы
Единственным надежным средством, обеспечивающим сохранность в тайне закры-
тых ключей на всех этапах их жизненного цикла (генерация ключевой пары (закрытый
ключ — открытый ключ), хранение, использование и уничтожение закрытого ключа),
являются специализированные устройства, построенные на основе микросхемы смарт-кар-
ты. В них выполняются все криптографические операции с закрытым ключом, а сам за-
крытый ключ никогда не покидает устройство и не может быть из него извлечен.
В настоящее время только аппаратные решения — смарт-карты и USB-ключи на ос-
нове микросхемы смарт-карты, аппаратно реализующие криптографические алгоритмы
в соответствии с национальными стандартами — в состоянии надежно защитить закры-
тый ключ пользователя даже при работе в небезопасных средах Об этом следует обяза-
тельно помнить, проектируя архитектуру PKl-решений или планируя их внедрение.
125
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
9.2.	Необходимость применения аппаратных средств
аутентификации и хранения ключевой информации
В асимметричной криптографии, как известно, применяется два типа отличных друг от
друга ключей. Один из них — открытый ключ — используется для того, чтобы выполнить
«публичные операции» (например, шифрование, проверку и подтверждение подлинности
цифровой подписи (ЭЦП)). Другой — закрытый ключ — используется для «закрытых
операций» (например, дешифрование, генерация ЭЦП). Таким образом, все, что зашиф-
ровано с помощью публичного ключа, может быть расшифровано с помощью закрытого
или секретного ключа, а подлинность ЭЦП, выработанной с помощью закрытого ключа,
может быть проверена с помощью открытого ключа. Такая система позволяет не только
избежать необходимости делиться секретной (ключевой) информацией с другими поль-
зователями, но и обеспечить такое важное свойство этой информации, как неотказу-
емость пользователя от авторства, так как только владелец закрытого ключа в состоянии
реализовать соответствующие процедуры.
Благодаря инфраструктуре открытых ключей (РК1), которая базируется на использо-
вании сертификатов определяющих владельцев закрытых ключей и их полномочия, мы
имеем возможность соотнести публичные ключи с их владельцами. Это, безусловно,
важно, так как при криптографическом преобразовании сообщения решающим фактором
является использование публичного ключа, который принадлежит легальному получате-
лю, а не какому-либо «подставному» лицу. Таким образом, технология РК1 по существу
является способом безопасного распределения публичных ключей, которая дает гаран-
тию того, что сообщение зашифровано с применением публичного ключа, принадлежа-
щего нужному нам адресату. По аналогичной схеме после получения подписанного до-
кумента мы в состоянии проверить идентичность подписывающего его лица.
Другая не менее важная составляющая асимметричной криптографии — управление
закрытыми ключами пользователя В этой главе мы обсудим, где эти ключи должны
храниться и почему. При этом будем считать решенным вопрос, как распределены пуб-
личные ключи, и каким образом мы узнаем о соответствии ключа пользователю
9.2.1.	Безопасность закрытых ключей
Основной постулат криптографии заключается в том, что закрытые ключи доступны
только их владельцам. Если злоумышленник может получить закрытый ключ какой-либо
из сторон, участвующих в информационном обмене, это значит, что он легко может рас-
шифровать все сообщения, посланные этой стороне. Кроме того, он может подписать лю-
бое сообщение от имени легального пользователя и успешно исполнить его роль в ин-
формационном обмене. Таким образом, ни о какой безопасности здесь не может быть
и речи.
Более тонкий вопрос, который возникает в этом случае, заключается в том, что не-
отказуемость, как свойство ЭЦП, можно также считать утраченным, как только поль-
зователь получит возможность утверждать, что его закрытый ключ мог быть нелегально
использован (неважно, действительно ли фактическое воровство имело место или нет).
Признание того факта, что закрытый ключ пользователя мог быть нелегально исполь-
зован, является основанием для поддержки судом заявления о том. что подписанный заказ,
финансовый документ или приказ является фальсификацией. Безусловно, наличие такой
возможности для недобросовестных пользователей носило бы разрушительный характер
для системы электронных цифровых подписей в юридическом контексте транзакции.
126
Гпава 9 Применение аппаратных средств аутентификации и хранения ключевой информации
Безопасность закрытого ключа пользователя должна быть обеспечена на каждом эта-
пе его жизненного цикла:
•	Генерация ключевой пары (открытый и закрытый ключи).
•	Хранение закрытого ключа.
•	Использование закрытого ключа (выполнение криптографических операций, тре-
бующих использования закрытого ключа пользователя, например, формирование
электронной цифровой подписи).
•	Уничтожение закрытого ключа.
Безопасность закрытого ключа должна быть обеспечена
на каждом этапе его жизненного цикла: генерация, хранение,
использование закрытого ключа, уничтожение.
Генерация ключевой пары должна выполняться в среде, исключающей как возмож-
ность влияния злоумышленника на сам процесс генерации, так и возможность получения
какой-либо информации о закрытом ключе, которая может впоследствии быть исполь-
зована при попытке его восстановления.
При хранении закрытого ключа должны быть обеспечены его конфиденциальность и
целостность — ключ должен быть надежно защищен от несанкционированного доступа,
а также модификации.
При использовании закрытого ключа важно исключить возможности его перехвата, а так-
же несанкционированного использования (помимо воли и желания владельца ключа)
И, наконец, на этапе уничтожения закрытого ключа необходимо обеспечить гаран-
тированное уничтожение информации и полностью исключить возможность его повтор-
ного использования (например, путем восстановления ранее удаленного хранилища).
9.2.2.	Подходы к обеспечению безопасности закрытых ключей
Ceiriac наиболее распространены и часто используются следующие подходы к обеспе-
чению безопасности закрытых ключей:
1.	Программные хранилища (software token) предназначены для хранения закрытых клю-
чеи на диске компьютера, чаще всего в зашифрованном виде. Примерами реализации
данного подхода являются криптопроваидер Microsoft Enhanced CSP, входящий в состав
операционной системы Microsoft Windows или браузер Mozilla/Netscape. Программные
хранилища не обеспечивают безопасность закрытых ключей пользователя. Они создают
только иллюзию защищенности.
Программные хранилища не обеспечивают безопасность
закрытых ключей пользователя. Они создают только иллюзию
защищенности
2.	Аппаратные устройства (hardware token) предназначены для хранения закрытых клю-
чей и выполнения криптографических операций, требующих использования закрытого
ключа Наиболее распространенными представителями устройств данного класса явля-
ются смарт-карты и USB-ключи eToken PRO компании Aladdin, построенные с исполь-
юванием микросхем смарт-карты.
127
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
3.	Репозитории (credentials repository) представляют собой выделенные серверы (часто
специализированное аппаратное обеспечение) для централизованного хранения закрытых
ключей нескольких пользователей. Для того, чтобы выполнить операцию с помощью
своего закрытого ключа (например, подписать электронное письмо), пользователь должен
вначале аутентифицироваться на сервере, передать данные для обработки на сервер, затем
получить результат.
В настоящее время в России наиболее распространенными средствами хранения за-
крытых ключей являются программные хранилища и аппаратные устройства в виде
смарт-карт и USB-ключей. Репозитории стоят очень дорого и не позволяют обеспечить
мобильность пользователя. В основном они используются для хранения ключей, исполь-
зуемых при аутентификации устройств, например, серверов, при организации защищен-
ного информационного обмена, а также в финансовой сфере.
Ниже мы сравним два наиболее распространенных в сфере информационной безопас-
ности подхода к хранению закрытых ключей пользователей. Один из вариантов предпо-
лагает хранение закрытых ключей с использованием программных средств, а второй —
в специальном внешнем аппаратном устройстве (смарт-карте или USB-ключе). Послед-
ний вариант обладает значительно большей эффективностью для безопасности системы
в целом.
9.2.3.	Программные хранилища и их уязвимость
Защита закрытых ключей программными средствами называется программным храни-
лищем. Такое хранилище является программной эмуляцией аппаратного электронного
ключа и выполняет практически аналогичные функции
Для того чтобы воспользоваться закрытым ключом (например, для формирования ЭЦП
документа), закрытый ключ пользователя должен быть предварительно извлечен из про-
граммного хранилища и загружен в память компьютера, после чего он может быть ис-
пользован для выполнения криптографических операций.
Отметим, что за удобство и простоту использования программных хранилищ прихо-
дится дорого расплачиваться. В частности, для обеспечения мобильности пользователя
программное хранилище должно быть продублировано на всех компьютерах пользова-
теля (рабочий компьютер, домашний компьютер, ноутбук, карманный компьютер и др.).
Это значительно увеличивает уязвимость закрытого ключа и может привести к его комп-
рометации. как будет показано ниже.
9.2.4.	Основные угрозы
Важно понимать и отдавать себе отчет в том, что 1юбые персональные компьютеры
представляют собой потенциально небезопасную среду из-за двух основных угроз:
•	Возможность физического доступа. В основе угрозы лежит тот факт, что компьютер
в большинстве случаев является физически доступным и незащищенным. И дело
даже не в краже того же ноутбука, хотя и это не исключено. Во многих компаниях
практикуется посменная работа сотрудников. При этом все они используют один
и тот же компьютер — каждый в свою смену. Соответственно никто из них не мо-
жет знать, что происходит с компьютером и кто за ним сидит в другую смену
Нередки случаи, когда, например, секретарь может покинуть свое рабочее место, оставив
пришедшего в офис посетителя предоставленным самому себе. Кто знает с какой целью
он пришел?
128
Гпава 9. Применение аппаратных средств аутентификации и хранения ключевой информации
Во всех этих случаях получить физический доступ к «бесхозному» компьютеру не со-
ставляет никакой сложности. А это значит, что потенциально злоумышленник может
получить доступ к программному хранилищу.
Фактически любой офис является небезопасной средой и представляет возможности для
проникновения злоумышленника, особенно обладающего навыками социальной инжене-
рии. Программное хранилище закрытых ключей легального пользователя — сотрудника
компании — может быть захвачено, скопировано или украдено вместе с ноутбуком или
карманным компьютером. Причем в качестве злоумышленника можно легко предста-
вить не только «случайного гостя», но и коллегу по работе или даже уборщицу!
Важно отметить, что простой блокировки компьютера недостаточно, ведь злоумыш-
ленник может просто вручную извлечь жесткий диск и прочесть хранящиеся на нем файлы.
(Конечно, можно принять контрмеры против кражи программного хранилища таким
способом, например, зашифровав содержимое жесткого диска компьютера, однако в боль-
шинстве случаев даже такой «грубый» вариант все еще остается возможным).
•	Злонамеренное программное обеспечение (malicious software). Вторую серьезную
угрозу представляет быстро растущее и по качеству, и по количеству злонамерен-
ное ПО, к которому относятся вирусы, сетевые черви, трояны и др. Стремительное
распространение вредоносных программ ежегодно наносит компаниям колоссаль-
ный ущерб.
Заражение с помощью любого типа злонамеренного ПО может иметь разрушительные
последствия для хранящегося на компьютере пользователя закрытого ключа, защищенно-
го программными средствами. Написанная специально для этих целей программа-шпи-
он (spyware) может просто считать файл программного хранилища без ведома хозяина
компьютера и послать его своему автору. Такие программы незаметно «подсаживаются»
на компьютер в ходе просмотра обычных с виду web-страниц.
Специализированные вирусы и троянские программы — реальность! Пример — ви-
рус Caligula, выпущенный в конце 90-х гг. Он был предназначен именно для похищения
закрытых ключей пользователя системы PGP, которые хранились в программном хра-
нилище.
Более того, описанная выше атака может носить массовый характер, и, таким обра-
зом, множество ключей, хранящихся на компьютерах, могут быть считаны и украдены
одним единственным «шпионом».
Специализированные вирусы и троянские программы —
реальность! Пример — вирус Caligula, выпущенный в конце
90-х гг. Он был предназначен именно для похищения
закрытых ключей пользователя системы PGP, которые
хранились в программном хранилище
Основные контрмеры и обеспечиваемая ими безопасность
Учитывая вышеупомянутые угрозы, ясно, что программные хранилища не являются
простыми, типичными файлами, сохраненными в личном каталоге пользователя Это
сделало бы доступ к содержимому программного токена чрезмерно простой задачей для
злоумышленника Программные хранилища защищены, и для этого используются сле-
дующие методики.
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
I
ДР.
«гг
ци
оп
ро
ил
МО
из(
301
ем-
pet
ва>
им
ва>
яш
лю
я в/
ТИ1
ще
кул
зак
хра
ЛИ1
/Пи
ИЗ (
ши
бое
ф0|
и р
отк
зов
исг
зов.
фИ1
воз
для
126
Шифрование данных: все содержимое программного хранилища находите?
рованном виде; используется надежный алгоритм шифрования; ключ шифро!
мируется из пароля пользователя (например, с использованием хэш-функци
Путаница: данный способ состоит в том, чтобы максимально усложнить i
граммного хранилища тому, кто несанкционированно попытается получить д
крытому ключу. По существу, программное хранилище скрывается благодаря
ке на жестком диске пользователя. Чтобы усложнить задачу хакера, использ
жество способов, имеющих эффект «путаницы». Например, один из возможн!
состоит в том, чтобы сначала зашифровать программное хранилище с закрыл
и затем «прятать» ключ в различных местах на диске пользователя.
Рассмотрим безопасность каждой из описанных выше контрмер. Мы впо
согласиться с тем, что эффект «путаницы» действительно может помочь заш
неопытных сетевых злоумышленников. Однако опытный хакер, приложив
усилия, может обойти этот способ защиты. Таким образом, всецело доверял
ние безопасности «путанице» не стоит, так как она не обеспечивает необхо;
PKI-решений уровня безопасности.
Что же касается шифрования с помощью пароля, его безопасность в зн<
степени зависит от качества используемого пароля. Важно понимать следую
• как только злоумышленник стал обладателем зашифрованного програм
нилища, он может попытаться подобрать пароль и по этому паролю •
вать нужную информацию;
• число попыток подбора пароля для программного хранилища неограь
Пробуя вводить подобранные пароли, атакующий может угадать необходим
ступа комбинацию Такое нападение называют «атакой по словарю» или «словарь
и оно в достаточной мере эффективно. Единственный способ предотвратить
состоит в применении сложного пароля, содержащего символьные, цифровые,
значения разных регистров, и к тому же состоящего из случайного набора симв
ственный пароль может выглядеть примерно так: gl UY$AM#&6430Fr' @Nk. К (
запомнить качественные пароли для большинства пользователей не представляет
ным, особенно если принять во внимание тот факт, что таких паролей может бы
ко. Таким образом, в большинстве случаев «словарные атаки» очень успешны.
9.2.5. Выводы о безопасности программных хранилиш
Основная проблема программных хранилищ состоит в том, что они зависят
ности среды, в которой они находятся, т. е. компьютера. Однако, как мы уже не
упоминали, персональные компьютеры небезопасны: как только получен (J
доступ или машина заражена вирусом, закрытый ключ пользователя может б
рометирован.
Стоит добавить, что сам факт атаки может остаться незамеченным для по.
и злоумышленник в течение долгого времени сможет расшифровывать коррес
легального пользователя и отправлять от его имени и за его подписью фаль
ванную информацию. Таким образом, важнейшее свойство ЭЦП — неотка'
не может быть достигнуто. Именно поэтому программное хранилище обесп<
носительно низкий уровень безопасности, и его использование в организащ
рующих конфиденциальной информацией, должно быть исключено
Для усиления безопасности закрытых ключей пользователя и обеспечения <
ности широко используются внешние отчуждаемые носители Следует отмет!
130
пользование внешних носителей для сохранения программного хранилища (в качест]
носителя может выступать, например, дискета, CD-диск) обеспечивает мобильност
однако несущественно повышает безопасность. Содержимое такого носителя загруж
ется на локальный компьютер всякий раз. когда пользователю необходима ключевая И1
формация (например, для формирования ЭЦП документа). Удобство и простота — ва>
ные преимущества использования портативного внешнего устройства по сравнению <
стандартным программным хранилищем. Однако эти преимущества не повышают защ]
шенность системы. Почему?
На первый взгляд, кажется, что раз закрытый ключ пользователя не сохранен на н<
утбуке или стационарном компьютере, он надежно защищен. Ведь теперь злоумышле]
ник нуждается в физическом доступе к внешнему устройству пользователя, а такое ус
ройство мобильно и его значительно проще обезопасить, чем тот же ноутбук или пе]
сональныи компьютер. Его можно хотя бы просто всегда носить с собой.
Однако можно вполне обоснованно утверждать, что достигаемое повышение защ1
шенности (по сравнению с программным хранилищем) крайне незначительно.
•	Во-первых, если внешний носитель, например, дискета, даже на короткое вреи
окажется в руках злоумышленника, он сможет считать с нее информацию. Причс
легальный пользователь — хозяин дискеты — может никогда не узнать о факте к<
пирования его данных и, следовательно, их компрометации
•	Во-вторых, загруженный с дискеты на компьютер закрытый ключ уязвим для ль
бого вредоносного программного обеспечения, имеющегося на компьютере пол
зователя.
•	В-третьих, опасность для утечки данных представляют так называемые файл
подкачки (swap-файлы). В большинстве операционных систем они используют
для временного хранения данных, которые выгружаются для ускорения работ
системы. Облегчая работу компьютеру, технология подкачки всегда несет опасное
записи на жесткий диск в открытом виде данных, которые должны оставаться з
шифрованными.
Исходя из вышеперечисленного, можно сделать вывод о том, что уровень безопасное
закрытых ключей пользователя, обеспечиваемый внешними носителями, ненамного вьп.
уровня безопасности, обеспечиваемого программными хранилищами. Усилить защиту юн
чевои информации, записанной на взятую нами в качестве примера дискету, можно с п
мощью пароля. Однако, как мы уже говорили выше, простой пароль уязвим, и, следов
тельно, уровня обеспечиваемой им защиты недостаточно. Также не стоит забывать о вирус?
которые может содержать компьютер пользователя. Парольная защита здесь бессильна
Использование программных хранилищ — это слишком большой риск для орган
зации, так как обеспечивает слишком низким уровень безопасности. При этом после
ствия вирусном атаки могут быть необратимыми. Это необходимо учитывать при п
строении системы информационной безопасности.
9.2.6.	Аппаратные устройства с криптографическими возможностями
Итак, основная проблема рассмотренной выше системы защиты состоит в том, ч
закрытый ключ импортируется в небезопасную среду локального компьютера. Реши
эту проблему можно, лишь используя отчуждаемое устройство, способное аппаратно bi
поднять криптографические операции Таким образом, внешний носитель должен бы
оснащен микропроцессором, способным зашифровать и отправить обратно сообщеш
посланное на это устройство локальным компьютером пользователя. Благодаря возмо.
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
ности выполнения криптографических операций аппаратные устройства обеспечивают
более высокий уровень защиты ключевой информации, так как закрытые ключи никогда
не экспортируются из устройства.
Благодаря возможности выполнения криптографических
операций аппаратные устройства обеспечивают более
высокий уровень защиты ключевой информации, так как
закрытые ключи никогда не экспортируются из устройства
Тот факт, что закрытый ключ никогда не экспортируется из памяти устройства, яв-
ляется фундаментальным шагом вперед к максимально безопасному хранению закрытых
ключей. Рассмотрим снова обозначенную нами парадигму угроз безопасности, но теперь
через призму аппаратного устройства с криптографическими возможностями:
1.	Злонамеренное программное обеспечение (malicious software). Предположим, что поль-
зователь подключает аппаратное устройство с криптографическими возможностями на
инфицированную вирусом машину и вводит пароль для авторизации в появившемся на
экране монитора окне. Существует вероятность того, что вирус, находящийся в компьютере,
может подменить собой пользователя и, действуя от его имени, использовать аппаратное
устройство (токен) для подписи сообщения. Однако реализация такой атаки ограничена
во времени — она осуществима только на время физического подключения токена
к компьютеру.
2.	Физический доступ (phisycal access). Вспомним еще раз о том, что в обсуждаемом
нами типе токенов закрытый ключ хранится в защищенной памяти устройства и никогда
не покидает ее. Поэтому воспользоваться им для проведения криптографических пре-
образований можно только в случае получения злоумышленником физического доступа
к устройству (кража, похищение и др.). Если злоумышленник сумеет получить токен легаль-
ного пользователя, возникнет угроза компрометации хранящейся в его памяти инфор-
мации. Безопасность в этом случае обеспечивается лишь степенью физической защиты,
обеспечиваемой самим устройством. У простейших токенов она минимальна, поэтому
сломать ее и извлечь ключевую информацию не составляет большого труда. Справед-
ливости ради, отметим, что для взлома зашиты часто необходимо разрушить сам токен или
просто украсть его, а, значит, нападение будет обнаружено легальным пользователем.
В некоторых случаях, эта цена слишком высока.
3.	В дополнение к перечисленным выше рискам и угрозам, существует потенциально
более разрушительный тип нападения на аппаратные токены — атака на побочные каналы
(side channel attack). Получив физический доступ к токену, атакующий может получить
информацию о закрытых ключах пользователя, измерив такие показатели, как время и
мощность, затраченные в ходе выполнения токеном криптографических преобразований.
Да, возможно, такой тип атаки покажется неправдоподобным, однако на деле он пред-
ставляет собой высокоэффективный способ считывания закрытого ключа, к тому же не
повреждающий само устройство.
9.2.7.	Смарт-карты и USB-ключи на основе микросхем смарт-карт
Смарт-карта представляет собой специализированную микросхему, содержащую микро-
процессор и операционную систему, управляющую работой микропроцессора.
Микросхема смарт-карты, которую использует этот класс устройств, обеспечивает
безопасное хранение и использование ключей шифрования и ЭЦП, а также надежное
132
Гпава 9. Применение аппаратных средств аутентификации и хранения ключевой информации
хранение цифровых сертификатов. Устройства, использующие технологии смарт-карт
разработаны специально для надежного противостояния различным типам атак и обес-
печивают максимально высокий уровень безопасности для хранения и использование
закрытых ключей.
Устройства, использующие технологии смарт-кар^
разработаны специально для надежного противостояны
различным типам атак и обеспечивают максимально высокий
уровень безопасности для хранения и использованы
закрытых ключей
Устройства на основе микросхем смарт-карт могут выпускаться как в виде смарт-карты
так и в виде USB-ключа, что существенно расширяет область их применения. Более того
устройства, базирующиеся на технологиях смарт-карт, можно дополнить RFID-метког
для радиочастотной идентификации, благодаря чему они могут использоваться не толь-
ко для входа в сеть, но и для контроля доступа в помещения.
Мобильность смарт-карт и USB-ключей позволяет пользователю безопасно работал
в «запрещенной среде», так как ключи шифрования и ЭЦП генерируются аппаратнс
микросхемой смарт-карты, никогда не покидают ее и не могут быть извлечены или пе-
рехвачены.
Большие возможности смарт-карт и USB-ключей на основе микросхемы смарт-карть
позволяют им работать со всеми приложениями, использующими технологии смарт-карт
что делает их незаменимым средством для проведения защищенных финансовых тран
закций, применения в приложениях, предназначенных для электронной коммерции
а также для безопасного доступа в корпоративную сеть, к защищенным информацион-
ным ресурсам, порталам и др
Реализуя принцип двухфакторной аутентификации, данный тип устройств может был
использован злоумышленником только в том случае, если он будет иметь физический до
ступ к устройству и знать его PIN-код, защищенный от подбора. Во всех остальных слу
чаях кража смарт-карты или USB-ключа на основе микросхемы смарт-карты бесполезна
Также важно отметить, что существуют международные стандарты безопасности, ко
торые разработаны специально для смарт-карт и USB-ключей. среди которых наиболее
широко применяются стандарт CWA 14169 (стандартдля изделий, реализующих электрон
ную подпись — безопасные устройства создания подписи secure signature-creation devices
SSCD) и профиль защиты для смарт-карт «Smart Card Protection Profile (SCSUG-SCPP)»
Многие производители смарт-карт и USB-ключей на основе микросхем смарт-карт длз
приложений информационной безопасности (среди них в первую очередь компании
Aladdin — SafeNet) сертифицируют свою продукцию на соответствие этим стандартам
К основным особенностям смарт-карт можно отнести следующие:
•	Смарт-карты изначально проектируются с учетом требовании обеспечения безопас
ности хранящихся и обрабатываемых на них данных. Существует ряд международ
ных открытых стандартов (например, семейство стандартов 1TSEC) в области обес
печения безопасности для смарт-карт, которыми руководствуются разработчики
•	Физически (на уровне «железа») и логически (средствами встроенной операци
оннои системы) обеспечивается защищенное хранение данных и защищенная об
работка данных внутри микросхемы смарт-карты (а не на внешних модулях па
мята).
•	Аппаратная реализация криптографических алгоритмов.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Другие типы персональных идентификаторов (Dallas Touch Memory, магнитные карты,
радио-метки, средства генерации одноразовых паролей и пр.) сильно проигрывают
смарт-картам и USB-ключам.
Преимуществами использования технологии смарт-карт в качестве средств аутенти-
фикации и хранения ключевой информации пользователей являются:
•	Архитектурное решение, специально спроектированное для использования в сис-
темах обеспечения информационной безопасности
•	Защищенность микросхем смарт-карт от различных видов атак (по анализу по-
требляемой мощности, от послойного сканирования, от изучения разрушающими
методами и пр.)
•	Для микросхем смарт-карт существуют общепринятые международные стандарты
по безопасности, которыми руководствуются разработчики микросхем смарт-карт
и операционных систем для смарт-карт, такие как стандарт CWA 14169 — стандарт
для изделии, реализующих электронную подпись — безопасные устройства созда-
ния подписи secure signature-creation devices, SSCD: профиль защиты для смарт-карт
«Smart Card Protection Profile (SCSUG-SCPP)
•	Сертификация изделий производится на соответствие международным стандартам
в независимых испытательных лабораториях, а не самим производителем на со-
ответствие собственным декларациям.
Глава 9 Применение аппаратных средств аутентификации и хранения ключевой информации
•	Аппаратная реализация криптографических функций, в том числе функций ге
рации ключевых пар (открытый/закрытый ключи), формирования ЭЦП с испс
зованием закрытого ключа.
•	Обеспечение безопасности закрытых ключей пользователя на всех этапах их д
ценного цикла (генерация, хранение, использование, уничтожение).
•	Поддержка смарт-карт включена в наиболее популярные версии операционных с
тем для компьютеров — Microsoft Windows (PC/SC), Linux и его клоны, МАС
(Open Card Framework). Это снижает объем ПО от разработчика средств аутен
нификации и хранения ключевой информации, требуемый к установке на ра(
чей станции пользователя. Упрощается процесс развертывания устройств в к<
поративной среде, их поддержки и сопровождения.
•	Простая конструкция устройства, за счет чего повышаются надежность и стабш
ность работы устройства в целом (так как используется меньшее число комг
нентов).
•	Становится возможным сертифицировать устройство аутентификации и хранен
ключевой информации в целом, а не только отдельных его компонентов. Для ус
ройств аутентификации и хранения ключевой информации, построенных на оснс
микроконтроллера, чаще всего разработчику удается сертифицировать лишь од1
из компонентов устройства, но не устройство в целом.
•	Возможность создания устройств аутентификации и хранения ключевой информ
ции пользователей в различных форм-факторах: смарт-карты и USB-ключа. Фо
мат смарт-карты наиболее востребован корпоративными заказчиками, котор]
применяют смарт-карты как единое устройство для контроля логического досту!
(доступ к информационным ресурсам) и физического доступа (контроль досту]
в помещения, визуальный контроль по фотографии, напечатанной на поверхн<
сти смарт-карты). Смарт-карты также необходимы на защищенных рабочих ста]
циях, где по требованиям безопасности недопустимо использование портов US1
Разработчик средств аутентификации и хранения ключевой информации может рас
ширить функции устройства путем написания так называемых пакетов для операционно
системы смарт-карты или Java-аплетов (если речь идет о Java-карте). Функции могут бьп
расширены разработчиком устройства, например для добавления поддержки национал!
ных алгоритмов шифрования или расширения функций устройства Хорошим примеро
является USB-ключ eToken PRO (Java) производства компании Aladdin, в котором под
держка российских криптографических алгоритмов (в соответствии с ГОСТ Р 34.10—200
и ГОСТ Р 34 11—94) реализована в виде Java-аплета, исполняемого на смарт-карте
9.3.	Типовые требования к средствам аутентификации
и хранения ключевой информации
Современные средства аутентификации и хранения ключевой информации пользова
телей должны не только обеспечивать защищенное хранение данных в памяти устрой
ства, но и аппаратно поддерживать выполнение криптографических операций в дове
ренной среде в соответствии с требованиями национальных стандартов.
Поскольку национальные требования в области информационной безопасности раз
личаются в разных странах, задача создания национального средства аутентификации
хранения ключевой информации пользователя не может быть решена только путем им
порта аналогичных средств, используемых в других странах.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Чтобы полностью отвечать требованиям потребителей на национальных рынках, пос-
тавщик средств аутентификации и хранения ключевой информации пользователей должен
обеспечить соответствие устройства как минимум следующим требованиям:
•	поддержка национальных и международных криптографических стандартов;
•	сертификация;
•	возможность использования устройства без установки пользователем дополнитель-
ного ПО на клиентской рабочей станции;
•	возможность размещения и исполнения нескольких приложений на устройстве;
•	наличие инфраструктурного решения для управления жизненным циклом устройств;
•	наличие двух форм исполнения: USB-ключ и смарт-карта;
•	встроенная поддержка в наиболее распространенные клиентские операционные
системы и приложения:
•	обратная совместимость с наиболее широко распространенными средствами аутен-
тификации и хранения ключевой информации пользователей.
9.3.1.	Поддержка национальных криптографических стандартов
Данная поддержка должна быть реализована:
•	на аппаратном уровне (реализация национальных криптографических алгоритмов
самим устройством);
•	на программном уровне (ПО промежуточного слоя — библиотека PKCStfl 1 и/или
криптопровайдер стандарта Microsoft CSP, — позволяющее разработчикам при-
кладного ПО легко встроить поддержку устройств в свои продукты).
При аппаратной реализации национальных криптографических алгоритмов разра-
ботчик устройства в первую очередь должен обеспечить поддержку национального стан-
дарта ЭЦП (генерация устройством пар открытый/закрытый ключ, их безопасное хра-
нение, использование и гарантированное уничтожение).
Также следует предусмотреть совместимость с наиболее распространенными типами
национальных средств криптографической защиты информации (СКЗИ) (в России —
КриптоПро CSP, Домен-К, Signal-COM, Верба-OW и др.) и возможность импорта клю-
чевой информации пользователей этих СКЗИ с незащищенных носителей (дискета, ре-
естр Windows) в устройство.
9.3.2.	Поддержка международных криптографических стандартов
Для участия в международном информационном обмене следует предусмотреть аппа-
ратную и программную поддержку устройством международных и межгосударственных
криптографических стандартов. Примером действующего международного стандарта яв-
ляется алгоритм RSA. В качестве межгосударственного стандарта стран СНГ выступает
алгоритм формирования и проверки ЭЦП в соответствии с ГОСТ Р 34.310—2004.
9.3.3.	Сертификация средств аутентификации
и хранения ключевой информации
В соответствии с требованиями законодательства аутентификационные данные поль-
зователей и ключевая информация должны сохраняться в тайне, а в ряде случаев они мо-
гут быть отнесены к категории конфиденциальной информации. Средства аутентифи-
136
Гпава 9 Применение аппаратных средств аутентификации и хранения ключевой информации
кации и хранения ключевой информации реализуют защищенное хранение данны
должны быть сертифицированы в системе сертификации средств защиты информац
Средства аутентификации и хранения ключевой информации также реализуют аппара
(и программно) национальные криптографические алгоритмы. Они относятся и к ка
гории СКЗИ, что потребует от разработчика наличия лицензии на деятельность в даш
области, а также выполнения предусмотренных процедур их проектирования и раз
ботки (например, положение П КЗ-2005).
Таким образом, разработчик должен иметь лицензии на соответствующие виды
ятельности и предусмотреть сертификацию создаваемых средств:
•	в системе сертификации средств зашиты информации (ФСТЭК России);
•	в Федеральной Службе Безопасности России (как СКЗИ);
•	в отраслевых системах добровольной сертификации (например, ГАЗПРОМСЕРТ
по требованию потребителя
9.3.4.	Возможность использования без установки дополнительного Г
на клиентской рабочей станции
Данное требование вытекает из сценариев использования устройства пользовате.1
в системах Интернет-банкинга, системах дистанционного банковского обслуживания (Д1
и других сферах, где очень важны как доступность услуги (сервиса) самому широкс
кругу пользователей, так и обеспечение юридической значимости транзакций (дей
вий), выполняемых пользователем в процессе работы.
Выполнение требования доступности сервиса (услуги) приводит к тому, что необхо
мо предусмотреть возможность полноценной работы пользователя с рабочих стан!
(терминалов), где у него нет прав локального администратора и поэтому нет возм<
ности проводить установку ПО. Все компоненты, необходимые для функционирова]
устройства, должны либо входить в состав наиболее популярных операционных сист
либо быть доступны для автоматического скачивания с сайтов обновлений к ОС (
пример, для ОС семейства Microsoft Windows, это сайт Windows Update).
9.3.5.	Размещение и исполнение нескольких приложений на устройс!
Устройство аутентификации и хранения ключевой информации пользователя не доле
быть одноаппликационным, а должно иметь возможность размещения и исполнения
скольких приложений на устройстве (каждое приложение — со своим набором данн!
Данное требование предполагает наличие на устройстве достаточного количества пам
для размещения приложений и их данных Оптимальный объем памяти — 72 Кбайт,
торый в большинстве случаев достаточен для размещения необходимых приложени
их данных.
9.3.6.	Инфраструктурное решение для управления
жизненным циклом устройств
Массовый характер использования средств аутентификации и хранения ключе
информации предусматривает их эмиссию большому числу пользователей. При этом
обходимо иметь единую централизованную систему управления этими устройства
которая позволяет:
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
•	вести реестр выпущенных устройств;
•	управлять их жизненным циклом (при любых масштабах эмиссии);
•	обеспечивать пользователей web-сервисами самообслуживания для самостоятельного
(и удаленного) решения задач, возникающих в процессе эксплуатации устройств:
•	вести аудит использования устройств (во внутрикорпоративной сети);
•	создавать отчеты (управленческие, для служб ИТ и И Б).
9.3.7.	Два форм-фактора исполнения: USB-ключ и смарт-карта
Форм-фактор USB-ключа является наиболее популярным для конечных (в том числе
и индивидуальных) пользователей, так как для работы с устройством аутентификации и
хранения ключевой информации не требуется устройство чтения смарт-карт (достаточно
наличие на рабочей станции порта USB). Следует отметить, что предпочтительной явля-
ется версия 2.0 интерфейса USB, поскольку она обеспечивает значительно более высо-
кую скорость передачи данных по сравнению с устаревшей версией 1.1.
Смарт-карты наиболее востребованы корпоративными заказчиками, которые при-
меняют смарт-карты как единое устройство для контроля логического доступа (доступ
к информационным ресурсам) и физического доступа (контроль доступа в помещения,
визуальный контроль по фотографии, напечатанной на поверхности смарт-карты).
Смарт-карты также необходимы на защищенных рабочих станциях, где по требованиям
безопасности нельзя использовать порты USB
Гпава 9 Применение аппаратных средств аутентификации и хранения ключевой информации
9.3.8.	Встроенная поддержка устройств в наиболее распространенных
клиентских операционных системах и приложениях
Выполнение разработчиком устройства данного требования обеспечит беспроблем-
ное использование устройства на большинстве имеющихся рабочих станций.
9	3.9. Обратная совместимость с наиболее широко распространенными
средствами аутентификации и хранения
ключевой информации пользователей
В настоящее время наиболее распространенным средством аутентификации и хра-
нения ключевой информации пользователей являются электронные ключи eToken ком-
пании Aladdin. По состоянию на начало 2008 г, компания Aladdin контролировала
70—75% российского рынка этих средств. Оставшийся сегмент рынка был распределен
между изделиями отечественных производителей — электронные ключи ruToken (ком-
пания Актив), Шипка (ОКБ САПР) и зарубежных — электронные ключи iKey (Rainbow
Technologies, ныне — SafeNet), RSA SecurlD (RSA ныне — подразделение EMC).
В процессе перехода на новые средства аутентификации и хранения ключевой ин-
формации должна быть обеспечена полная обратная совместимость с уже имеющимися
у заказчика аналогичными средствами. Так как электронные ключи eToken PRO 1анимают
доминирующее положение на российском рынке средств аутентификации и хранения
ключевой информации, а электронные ключи eToken PRO (Java) полностью обратно
совместимы с eToken PRO, то выбор именно eToken PRO (Java) в качестве платформы
для средств следующего поколения представляется наиболее целесообразным.
9.4.	Особенности корпоративного использования
персональных средств аутентификации
и хранения ключевой информации
9.4.1.	Многоуровневая ролевая модель доступа
При корпоративном внедрении крайне важна возможность реализации многоуровне-
вой ролевой модели доступа. Как правило, эта модель включает следующие уровни раз-
граничения полномочий доступа к персональным средствам аутентификации и хранения
ключевой информации:
•	Уровень пользователя Конечный пользователь использует пользовательский
PIN-код для выполнения ежедневных задач аутентификации, доступа к данным
и т. д.
•	Уровень администратора информационной безопасности (офицера ИБ). Админи-
стратор И Б устанавливает ряд параметров для применяемых в организации
средств аутентификации и хранения ключевой информации (например, требова-
ния к качеству PIN-кода), соответствующих действующей политике ИБ. Адми-
нистратор ИБ использует PIN-код администратора при необходимости разблоки-
рования персонального идентификатора и/или смены забытого PIN-кода поль-
зователя.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
•	Уровень производителя. PIN-код этого уровня используется для:
✓	полного переформатирования персонального средства аутентификации и хра-
нения ключевой информации с полным удалением всех хранящихся в памяти
устройства данных;
✓	установки параметров, соответствующих требованиям действующей политики
И Б на предприятии (например, максимально допустимое число последова-
тельных неудачных попыток ввода PIN-кода до блокирования устройства).
В данной модели каждый из субъектов действует на своем уровне в рамках делегиро-
ванных ему полномочий и установленных ограничений. Применяемые средства аутен-
тификации и хранения ключевой информации должны поддерживать все три уровня
разграничения полномочии.
9.4.2.	Интеграция с системами контроля
и управления доступом в помещения (СКУД)
Смарт-карты и USB-ключи могут выступать как единое средство доступа к различным
информационным ресурсам, а смарт-карты с нанесенной на них информацией о вла-
дельце и его фотографией — еще и как средство визуальной идентификации
Гпава 9 Применение аппаратных средств аутентификации и хранения ключевой информации
Смарт-карты и USB-ключи могут применяться как единое
средство для контроля физического доступа в помещения
и контроля логического доступа к информационным
ресурсам.
Смарт-карта и токен также могут быть дополнены бесконтактной радио-меткой
(RFID-чипом, Proximity), используемым в бесконтактных «электронных проходных».
Это позволит повысить уровень безопасности и удобства — смарт-карта или токен не
может быть оставлен подключенным к компьютеру или передан другому лицу, так как
без него нельзя покинуть помещение. Также становится возможным отслеживание пе-
ремещения сотрудников, а при интеграции с системами телефонии — перевод звонков
в те помещения, где в данный момент находится сотрудник.
9.4.3'	Централизованная система управления
При корпоративном внедрении проектов, использующих технологии PKI, необходи-
мо централизованно управлять распределением и вести учет всех средств аутентифика-
ции и хранения ключевой информации, используемых в организации. Это могут быть
смарт-карты, USB-ключи, генераторы одноразовых паролей, комбинированные устрой-
ства (например, USB-ключ с микросхемой смарт-карты и генератором одноразовых па-
ролей).
Система централизованного учета и управления необходима для поддержки исполне-
ния политики И Б организации и является эффективным средством интеграции различ-
ных средств защиты информации (СЗИ).
Централизованная система управления должна:
•	производить централизованное автоматическое тиражирование/обновление/удале-
ние пользовательских данных в памяти устройств, а также проводить их разблоки-
ровку и форматирование;
•	обеспечивать блокировку утерянных персональных средств аутентификации и хра-
нения ключевой информации, выполнять отзыв (блокировку) содержавшихся на
них аутентификационных данных и ключевой информации;
•	позволять использовать групповые политики для делегирования и отзыва прав и пол-
номочий пользователям, а таюке реализовать единую политику назначения PIN-ко-
дов персональных идентификаторов;
•	определять список приложений И Б, доступ к которым имеет владелец данного
средства аутентификации;
•	собирать статистику и вести аудит использования средств аутентификации и хра-
нения ключевой информации;
•	интегрироваться со службой каталога (например, Microsoft Active Directory или
Open LDAP);
•	осуществлять дистанционное обновление программного обеспечения на клиент-
ских рабочих местах.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
9.5.	Централизованная система управления
средствами аутентификации и хранения
ключевой информации пользователей
Все большее число организаций используют надежные аппаратные средства аутенти-
фикации и хранения ключевой информации (USB-ключи и смарт-карты, далее по тексту —
токены) Но без системы управления, используемой для централизованного учета и об-
служивания токенов, их практическое использование может оказаться сложным или даже
невозможным. Системы управления токенами, предоставляющие возможности по под-
держке и управлению их жизненным циклом, делают внедрение аппаратных средств
аутентификации и хранения ключевой информации реальностью.
Система управления токенами — это основа, объединяющая и управляющая всей инф-
раструктурой аутентификации путем организации точки централизованного админист-
рирования всех типов аппаратных средств аутентификации, инструментов самообслу-
живания пользователя, встраивания в уже существующие системы управления учетными
записями пользователей, политики и приложения безопасности в организации Система
упрощает процессы распространения токенов и управления ими, поддерживает управле-
ние возможностями повышения безопасности пользователя в течение всей его деятель-
ности в организации и повышает эффективность работы пользователя. Открытая, мощная
и гибкая система управления позволяет постоянно увеличивать число поддерживаемых ре-
шений безопасности, улучшая и расширяя возможности решений, включающих токены.
9.5.1.	Проблема управления жизненным циклом
Применение аппаратных средств аутентификации и хранения ключевой информации
пользователей ставит задачи контроля их распространения и управления их жизненным
циклом в рамках организации. Без системы управления обеспечение таких связей может
оказаться чрезвычайно сложным и длительным, что приводит к большим затратам на
внедрение и росту вероятности возникновения ошибок
Для примера возьмем сотрудника, который только поступил на работу в организацию.
Назначение и регистрация средства аутентификации. Чтобы начать работу, сотруд-
нику необходимо получить токен. Без системы управления администратор должен перед
этим вручную настроить и «привязать» токен к учетной записи пользователя, используя
различные системы для формирования и сохранения учетных записей нового сотрудника
в памяти токена. Такой процесс регистрации токенов вручную несет в себе вероятность
ошибки. Предоставление новому сотруднику неправильных учетных записей и/или прав
доступа, может привести к нарушению режима И Б.
Восстановление PIN-кода токена. Если сотрудник забыл PIN-код своего токена, то он
не сможет пройти аутентификацию, войти в сеть и выполнить свою работу. Без инстру-
мента самообслуживания для восстановления PIN-кода токена, вместо того, чтобы быстро
восстановить PIN-код самостоятельно, сотрудник должен связаться со службой поддерж-
ки пользователей. При этом тратятся время и средства компании
Замена утерянного токена. Сотрудник может потерять токен. При этом администратор
должен вручную:
•	отозвать (заблокировать) все учетные записи пользователя для доступа ко всем
информационным системам, с которыми работал пользователь;
•	сформировать новые учетные записи;
•	выдать пользователю новый токен и занести в его память новые учетные записи
142
Гпава 9. Применение аппаратных средств аутентификации и хранения ключевой информации
При этом опять возникает вероятность ошибки, так как администратор может забыть
отозвать некоторые учетные записи, с помощью которых пользователь позже сможет по-
лучить несанкционированный доступ.
При наличии в организации 100 и более токенов система
управления их жизненным циклом обязательна.
Для организации с более чем 100 сотрудниками администрирование парка устройств
аутентификации и хранения ключевой информации без системы управления может ока-
заться очень трудной задачей Грамотное решение предполагает использование автома-
тических инструментов и процедур, которые не только значительно разгружают техниче-
ский отдел, но и уменьшают вероятность ошибок и отвечают требованиям администрации
по организации, управлению и отслеживанию всего парка устройств для аутентифика-
ции и соответствующих приложений, имеющих отношение к безопасности в организации.
Система управления токенами отвечает всем этим требованиям.
Система управления предоставляет всесторонние возможности управления токенами
и связанными с ними решениями по безопасности на протяжении всего жизненного
цикла токена, от момента его выпуска для пользователя и до отзыва. Для упрощения этих
действий система управления предоставляет набор инструментов управления для адми-
нистратора и пользователей.
9.5.2.	Жизненный цикл токенов
Регистрация. Токен «связывается» с конкретным пользователем и регистрируется в сис-
теме. в соответствии с ролью пользователя в организации и корпоративными полити-
ками безопасности. В память токена записываются аутентификационные данные и клю-
чевая информация.
Использование и поддержка. Аутентификационные данные и ключевая информация
пользователя, а также настройки самого токена периодически изменяются. Например, это
может произойти из-за перевода сотрудника на другую должность, когда изменяется круг
приложений, с которыми работает пользователь, а также при регламентной смене аутен-
тификационных данных. Пользователь самостоятельно осуществляет поддержку токена
(например, смену PIN-кода). При утере или повреждении токена хранящиеся в его памяти
аутентификационные данные и ключевая информация либо аннулируются, либо восста-
навливаются, если это возможно
Отзыв. Когда сотрудник покидает организацию, назначение токена ему отменяется.
Аутентификационные данные и ключевая информация пользователя, хранящиеся в памя-
ти токена, аннулируются.
Возврат в эксплуатацию. Токен может быть выдан новому сотруднику. Перед реги-
страцией токена он должен быть приведен в исходное состояние и персонализирован
для нового пользователя.
Ниже приведен обзор главных стадий и процессов жизненного цикла токенов.
9.5.3.	Выпуск и распространение
Токены могут быть вначале зарегистрированы в системе и только потом назначены
пользователям, либо регистрироваться в системе непосредственно в момент их выпуска.
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Когда токены выдаются пользователям, система управления позволяет создавать и обнов
лять записи о физическом списке токенов во время выпуска. В идеале выпуск токено
может производиться как централизованно (например, на рабочем месте администра
тора системы), так и самими пользователями
9.5.4.	Регистрация токенов
Каждый токен должен быть назначен конкретному пользователю и подготовлен дд]
него. В процессе регистрации в память токена загружаются пользовательские данные, циф
ровые сертификаты и пароли. При этом токен защищается индивидуальным PIN-кодом
известным лишь пользователю, для которого токен предназначен Система управление
может облегчить регистрацию токена путем автоматического создания и сохранения не
обходимых реквизитов пользователя, основанных на правах доступа конкретного поль
зователя в соответствии с политикой организации. Например, в организации, исполь-
зующей инфраструктуру открытых ключей (PKI), авторизованные пользователи могу
автоматически создавать запросы на получение сертификата и генерировать ключевые
пары аппаратно на самих токенах в процессе регистрации токена.
Системы управления, включающие возможность самостоятельной регистрации поль
зователей, обеспечивают большую эффективность, уменьшая необходимость вмешатель-
ства администраторов.
Система управления облегчает процесс регистрации токенов
путем автоматического создания и последующего сохранения
аутентификационных данных и ключевой информации
каждого пользователя Система должна быть основана на
действующих правилах доступа и политике И Б организации
9.5.5.	Обработка типовых событий:
«Потеря токена» и «Повреждение токена»
Система управления обеспечивает быстрый процесс замены утерянного или повреж
денного токена. Это позволяет значительно снизить потерю производительности поль
зователя. Утерянный или поврежденный токен может быть быстро заменен на новый
в памяти которого содержатся все необходимые пользователю аутентификационные дан
ные и ключевая информация.
9.5.6.	Отзыв токена
Данная операция необходима для предотвращения несанкционированного доступ;
к информационным ресурсам с помощью токена (например, если им завладел злоумыш
ленник или принято решение об увольнении/экстренном отстранении сотрудника от ис
полнения им служебных обязанностей). Система управления токенами позволяет админи
стратору из единой точки управления аннулировать (заблокировать) все аутентификацион
ные данные и ключевую информацию, хранящиеся в памяти токена, чтобы запретить досту!
к корпоративной сети и приложениям пользователям, больше не имеющим на это права
Комплексные решения Aladdin
eToken NG-ОТР
Безопасный удаленный доступ
со всеми преимуществами
двухфакторной аутентификации
с использованием генератора
одноразовых паролей
nternet
Secret Disk
Server
Шифрование
данных на сервере
eSafe
Очистка Интернет-трафика
от вредоносного и
нежелательного контента
SafeData
Шифрование данных
в СУБД ORACLE
Secret Disk*
обеспечения
Система защиты
конфиденциальной
информации и персональных
данных
USB-ключи и смарт-карты для
строгой аутентификации,
хранения данных и цифровых
сертификатов
Решения для аутентификации
Aladdir
$ С <• Я I Т V S , I U Т I О И
Азбука строгой аутентификации
Аутентификация с помощью электронных ключей и смарт-кар
Вход в сеть и компьютер, удаленный доступ, интеграция со СКУД
Комбинированная карта
(смарт-карта + RFID)
USB ктМч
с генератором
одноразовых паролей
Генерато^!^
одноразовых паролей
Б Безопасность при работе с приложениями
ЭЦП и шифрование, управление паролями, безопасность данных
С использованием PKI
Без использования PKI
(унаследованные приложения)
Защищенный
доступ
по одноразовым
паролям
Собственные
приложения,
работающие с eToken
(комплект разработчика
eToken SDK)
Внедрение инфраструктуры управления доступом
Пользователи
и устройства
eToken TMS
Организационные
Централизованное управление
приложениями ИБ,
средствами аутентификации
учетными записями
и паролями
Вход на рабочую станцию
ш
S Сквозная аутентификация
К
Удостоверяющий Центр
Ф
Я	Шифрование данных
с
3	Удаленный доступ
Другие приложения
Аутентификация
ЭЦП, обеспечение безопасности закрытых ключей
Обеспечение конфиденциальности информации
Защита персональных данных
Защита баз данных
Обеспечение безопасной работы при использовании сети Интернет
Сертифицированные решени
для Российских заказчико!
от лидера рынка защип
приложений, данных
Web-сервисов i
документе
Оптимальный набор лучших в класса
легко подключаемых, интегрированны
средств обеспечень
информационной безопасност
Применение политик	Аутентификация и авторизация WebSSO EnterpnseSSO Federation Anti-Fraud
Определение политик	Управление ролями и учетными данными, их согласование и доставка
Хранилище учетных данных	Службы каталогов LDAP Virtual Directory	Meta Directory
E-Business Suite PeopleSoft. Siebel,
SAP Собственной Разработки.
Унаследованных Банковских Офисных
Защита
приложений
и документов
d
ф
Многоуровневый Мониторинг и
контроль доступа предупреждения
Безопасность
данных
Преобразование (Encryption)
At Rest In Motion in Backup
Безопасность операционной системы
Oracle (NASDAQ: ORCL) - крупнейший в мире производитель корпоративного программного обеспечения
За более подробной информацией о компании Oracle, обращайтесь, пожалуйста, на web-сайт www oracle con
Инфраструктура доставки приложений
Citrix Delivery Center
Citrix' NetScaler
Доставка Web
Приложении
Citrix
EdgeSight
Мониторинг
Производительности
Citrix
Access Gateway”
Безопасный Доступ к
Приложениям
Citrix
Branch Repeater
Ускорение Доставки
Приложений в Филиалы
Citrix
XenDesktop”
Доставка Рабочих
столов WindOAS
Пользователи
Citrix XenServer ’ I
Essentials’
Доставка Рабочей
Нагрузки на Сервера
Citrix ХепАрр
Server
Достав* а Прило* ений
Wind as
Приложения
Q
Подробная информация на
www.citrix.com и www.citrix.ru
Гпава 9. Применение аппаратных средств аутентификации и хранения ключевой информации
9.5.7.	Инструменты управления токенами
Системы управления токенами предоставляют различные инструменты для админи-
страторов и пользователей, облегчающие управление жизненным циююм токенов.
9.5.8.	Инструменты для администраторов
Система управления токенами — это платформа, с которой можно отслеживать и управ-
лять токенами в сочетании с корпоративным хранилищем учетных записей, правилами,
политикой и приложениями безопасности. Она может включать как программы, уста-
новленные на серверах организации, так и веб-приложения.
9.5.9.	Инструменты самообслуживания пользователя
Для операций, которые пользователь может совершать без обращения к администратору,
таких как регистрация токена или смена PIN-кода, существуют инструменты самообс-
луживания пользователя, которые предоставляют значительную экономию времени и
средств. Пользователи могут быстро совершать все действия по управлению токенами,
уменьшая потерю производительности и загруженность отдела информационных техно-
логий. Инструменты самообслуживания пользователей могут применяться как в виде ус-
тановленных на компьютеры пользователей программ, так и в виде веб-приложений для
удаленного администрирования.
Инструменты самообслуживания обеспечивают
значительную экономию средств и времени для организации.
9.6.	Типовые требования
к системе управления токенами
При выборе системы управления токенами важно помнить, что она имеет огромное
значение для организации. Потенциальная сложность решений на основе токенов делает
выбор системы управления важным стратегическим решением. В приведенном ниже
списке рассматриваются важные аспекты, которые должны быть приняты во внимание
в организации при выборе системы управления токенами.
9.6.1.	Функциональность
Система должна предоставлять администратору полный набор инструментов для управ-
ления жизненными циклами различных устройств и приложений. Она юлжна давать
организации возможность централизованно управлять всеми аспектами использования
токенов.
6 5680
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
9.6.2.	Простое и интуитивное использование
Система должна быть простои, доступной и управляться интуитивно. Кроме того, для
уменьшения участия службы поддержки пользователей и максимальной экономии важна
простота использования инструментов самообслуживания пользователя.
9.6.3.	Открытая архитектура
Открытая и основанная на стандартах архитектура делает возможным совмещение
системы управления токенами с внешними ресурсами, использующими известные и
принятые стандарты. Открытая архитектура не только позволяет всесторонне встроить
систему управления токенами в уже существующие в организации инфраструктуру инфор-
мационных технологий и системы управления идентификацией, но и оказывать хорошо
налаженную поддержку целому спектру приложений безопасности Системы управле-
ния токенами, для которых поставляются комплекты разработчика (SDK), позволяющие
встраивать их в другие приложения, предоставляют увеличенные возможности для рас-
ширения спектра поддерживаемых решений
9.6.4.	Гибкость
Система управления токенами должна быть достаточно гибкой, чтобы отвечать раз-
личным и развивающимся нуждам разных организаций. Она должна позволять органи-
зациям легко расширять набор поддерживаемых средств управления при появлении но-
вых решений на основе токенов в будущем.
9.7.	Token Management System (TMS) компании Aladdin
TMS — надежная система управления, позволяющая осуществлять в организации
распространение токенов подготовку их к работе и последующую поддержку. TMS ком-
пании Aladdin поддерживает ряд устройств, включая USB-токены, смарт-карты и устрой-
ства одноразовых паролей, а также разнообразные приложения безопасности, такие как
программы для входа в сеть, виртуальные частные сети, защищенный доступ к веб-сайтам,
приложения для аутентификации с помощью одноразового пароля, защиты электрон-
ной почты, шифрования информации и т. д.
TMS — это единственное решение, которое объединяет пользователей, устройства, ор-
ганизационные правила и приложения безопасности в единую, автоматизированную и пол-
ностью настраиваемую систему. Это дает возможность легко управлять использованием
решений с применением токенов, в частности, решений в инфраструктуре открытых ключей.
TMS компании Aladdin — это надежная платформа, которая
помогает внедрять токены и связанные с ними приложения
безопасности и управлять их жизненным циклом в масштабах
всей организации.
TMS полностью встраивается в Active Directory (AD). При внедрении TMS расши-
P «ется схема экземпляра AD. TMS хорошо сочетается с уже существующей в организации
инфраструктурой информационных технологии Система предоставляет интерфейс управ-
146
Пользователи и устройства
Организационные политики
WEB/LAN
Централизованная
персона.’! и запил
Реп< ппорни
ио. и ювателем
lj -ППО! ы
П» Iи гики
Реестр
токенов
Резервное
копирование/
восстановление
профилей
Прочее
'\ут. 1нифи* а 1 । я
DTP
Приложение безопасности
Рис. 9.1. Система управления TMS
Гпава 9. Применение аппаратных средств аутентификации и хранения ключевой информации
Служба каталога
Active Directory,
Open LDAP,
MS SQL Server
Token
Management
System
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
ления в AD, позволяющий администраторам выполнять свои функции по отношени
к токенам средствами, сходными с созданием и управлением групповыми политикам
В TMS применяется веб-интерфейс для взаимодействия пользователя с системой Пол
зователь имеет возможность самостоятельно управлять токеном через настраиваемь
веб-сайт предприятия. Это дает пользователям возможность регистрировать токены
сразу начинать их использовать, переустановить забытый PIN-код (разблокировать токе
и выполнять иные действия (рис. 9,1).
Открытая модульная архитектура TMS позволяет управлять использованием токене
с применением решений по безопасности сторонних разработчиков. Эта возможное
достигается путем применения «коннекторов» TMS — настраиваемых подключаем!
модулей, используемых на сервере. Компания Aladdin предоставляет набор для разр
ботчика коннекторов TMS, который позволяет поставщикам решении безопасности с
здавать собственные коннекторы и тем самым дополнять свои решения, используюш
eToken, средствами администрирования. В настоящее время разработаны коннекто[
для УЦ «КриптоПро УЦ» и УЦ RSA Кеоп.
9.7.1.	Назначение
•	Поэкземплярный учет и регистрация всех аппаратных и программных средств ауте
тификации и хранения ключевой информации, используемых сотрудниками.
•	Ускорение ввода в эксплуатацию электронных ключей и смарт-карт, автоматизаь
процессов выдачи eToken сотруднику, персонализация eToken, запись ключе!
информации и аутентификационных данных в память eToken
•	Управление жизненным циклом средств аутентификации и хранения ключевой i
формации: обновление аутентификационных данных и ключевой информац
предоставление/отзыв прав доступа к приложениям при изменении служебг
обязанностей/увольнении сотрудника, замена устройства при его утере/повр»
дении, вывод устройства из эксплуатации.
•	Аудит использования сотрудником выданного ему средства аутентификации и >
нения ключевой информации (фиксируются все факты использования устройс
сотрудником на компьютере предприятия, изменения хранящихся в памяти ?
ройства данных).
•	Подготовка отчетов для руководителей служб ИТ и ИБ об использовании cotj
никами средств аутентификации и хранения ключевой информации (на ось
данных аудита средствами встроенного генератора отчетов, также имеется
можность экспорта данных во внешние средства построения отчетов).
•	Техническая поддержка и сопровождение пользователей средств аутентифика
через веб-сайт технической поддержки: переустановка забытого пользоватс
PIN-кода устройства, синхронизация генератора одноразовых паролей, обраб
типовых ситуаций «пользователь забыл eToken», «пользователь потерял eTol
«пользователь повредил/сломал еТокеп».
9.7.2.	Возможности
•	Поддержка всех типов и моделей электронных ключей eToken (смарт-кг
USB-ключи комбинированные USB-ключи. программные или виртуальны
кены).
•	Интеграция со службой каталога Microsoft Active Directory
Гпава 9 Применение аппаратных средств аутентификации и хранения ключевой информации
•	Веб-сайты для самостоятельного решения пользователем проблем, возникающих
в ходе эксплуатации eToken, оказания технической поддержки пользователям
eToken специалистом сервисной службы (help desk web site), веб-сайт для адми-
нистрирования системы.
•	Открытая архитектура, позволяющая добавлять в систему поддержку новых при-
ложений и аппаратных устройств (через механизм коннекторов).
•	Масштабируемое, распределенное администрирование:
✓	администрирование систем eToken TMS, установленных в разных доменах,
с одного рабочего места администратора;
✓	ролевое администрирование, возможность делегирования полномочии.
•	Аудит использования средств аутентификации и хранения ключевой информации
сотрудниками, гибкая система построения отчетов на основе данных аудита.
•	Отказоустойчивость и масштабируемость системы, поддержка кластерных техно-
логий Microsoft Windows 2003/2008.
•	Централизованная установка клиентского ПО на рабочие станции пользователей.
•	Широкий спектр поддерживаемых клиентских ОС: Windows, Linux, Mac OS; любая
ОС при использовании одноразовых паролей.
•	Полная поддержка русского языка.
•	Виртуальный токен — уникальное программное решение, позволяющее пользо-
вателю, находящемуся вне офиса, даже в случае утери/повреждения eToken про-
должить работу с компьютером или получить безопасный доступ к ресурсам.
9.8. Практика: комплексная система
на базе единого персонального средства
аутентификации и хранения ключевой информации
На примере простой гипотетической корпоративной системы попробуем выяснить,
с какими трудностями чаще всего приходится сталкиваться при выборе единого персо-
нального средства аутентификации и хранения ключевой информации, на основе каких
принципов можно сформулировать критерии такого выбора.
Современные системы обеспечения информационной безопасности состоят, как пра-
вто, из нескольких объединенных посредством централизованного управления подсис-
тем, включающих в себя разнородные сервисы безопасности. Следовательно, и задачи
управления доступом пользователей с помощью единого персонального средства аутен-
тификации к различным подсистемам, подчас не связанным напрямую между собой, от-
нюдь не кажутся тривиальными. Тем более что еще несколько лет назад производители
систем защиты информации (СЗИ) настраивали их работу только на определенные типы
аутентификаторов.
Поэтому до сих пор для доступа к одному защищенному приложению пользователю
приходится пользоваться дискетой, к другому — смарт-картой, а к третьему — токеном или
труднозапоминаемым паролем. С точки зрения централизованного управления досту-
пом и прозрачного администрирования при наличии десятков информационных систем
более удобным является введение единого персонального идентификатора, в котором
надежно хранятся параметры доступа пользователя во все разрешенные области инфор-
мационного пространства предприятия.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
9.8.1.	Бизнес-задачи по защите корпоративной информации
Наша гипотетическая организация в той или иной степени решает такие задачи, как:
•	разграничение и контроль доступа зарегистрированных во внутренней сети поль-
зователей к рабочим станциям и корпоративным информационным ресурсам;
•	организация защиты корпоративных ресурсов, в том числе баз данных, содержащих
информацию, утечка которой критична для существования бизнеса компании;
•	предоставление безопасного доступа к порталу компании, в том числе к защи-
щенным веб-страницам;
•	защищенный обмен информацией территориально удаленных подразделений;
•	внедрение и поддержка сервиса электронной цифровой подписи (ЭЦП);
•	защищенный вход в бизнес-приложения;
•	защита корпоративной почты и документооборота;
•	организация полноценной работы удаленных пользователей;
•	физическая защита рабочих помещений (системы контроля и управления доступом);
•	оперативное и эффективное управление информационной инфраструктурой.
Данный перечень условимся считать оптимальными бизнес-требованиями комплекс-
ной защиты. При этом подзадачей организации защищенного доступа к корпоративной
сети, как уже упоминалось, будем понимать применение технологий, основанных на ис-
пользовании закрытых ключей и цифровых сертификатов стандарта Х.509.
Например, для сетей под управлением сервера Windows 2000/2003/2008 эта техноло-
гия основана на возможности запрета доступа к сети по паролю и разрешения доступа
по предъявлении пользователем сертификата из защищенной памяти персонального
идентификатора (смарт-карты или USB-ключа) и проверке его валидности (протокол
Kerberos + PKINIT).
Вопрос защиты корпоративных баз данных рассмотрим на примере СУБД Oracle, по-
скольку начиная с версии 8i данная СУБД оснащена встроенной поддержкой PKI, что
позволяет организовывать доступ к корпоративной базе по предъявлении цифрового сер-
тификата, сформированного штатными средствами Oracle.
Проблемы организации доступа к корпоративному порталу, защищенным приложе-
ниям и обеспечение работы удаленных пользователей проанализируем на примере техно-
логий, основанных на использовании цифровых сертификатов.
Для применения ЭЦП в качестве гарантии конфиденциальности (защита от НСД),
целостности (защита от внесения изменений), доступности для легальных пользователей,
аутентичности (подтверждение авторства) и неотказуемости (несмотря на внесенные из-
менения в документы и почтовые сообщения) требуется применение средств криптогра-
фической защиты информации (СКЗИ). При этом персональное средство аутентифи-
кации и хранения ключевой информации должно обеспечить надежное хранение клю-
чевых контейнеров применяемых СКЗИ.
Физическая защита рабочих помещений пользователей обеспечивается, как правило,
с помощью систем контроля и управления доступом, основанных на применении RFID-тех-
нологий (Radio Frequency Identification Device — радиочастотная идентификация).
Можно выделить основные технологии информационной зашиты, позволяющие ре-
шать типичные проблемы, составляющие вышеперечисленный оптимальный набор биз-
нес-задач:
•	аутентификация пользователей,
•	криптографическая зашита электронных документов (шифрование, ЭЦП);
•	межсетевое экранирование зашита каналов связи и VPN;
•	RFID-технологии.
Гпава 9. Применение аппаратных средств аутентификации и хранения ключевой информации
Иные технологии, не вошедшие в список, будем считать комбинацией перечисленных
выше методов (например, защиту удаленного доступа или беспроводных соединении
можно рассматривать как комбинацию технологии аутентификации и защиты сетевого
трафика).
Каждая из перечисленных технологий в той или иной степени связана с активным ис-
пользованием персональных устройств аутентификации и хранения ключевой инфор-
мации:
•	в рамках систем аутентификации данные устройства используются в качестве но-
сителей атрибутов доступа пользователей к информационным и (или) вычисли-
тельным ресурсам;
•	в рамках СКЗИ — для хранения ключевых контейнеров и выполнения криптопре-
образовании;
•	при защите каналов связи и организации VPN — для аутентификации удаленных
пользователей и сетевых устройств, выработки сеансовых ключей шифрования
трафика;
•	в рамках систем контроля и управления доступом (СКУД), основанных на исполь-
зовании RFID-технологии, персональные устройства играют центральную роль
маркеров доступа, в зависимости от состояния которых принимается решение
о допуске пользователей в те или иные помещения.
Таким образом, проблема выбора единого персонального средства аутентификации
и хранения ключевой информации может быть решена путем приобретения универсаль-
ного устройства отвечающего перечисленному оптимальному набору бизнес-задач по
защите информации, плюс возможность интеграции с установленными средствами за-
щиты и унаследованными (как правило, не поддерживающими сертификат Х.509) при-
ложениями. Рассмотрим типичные трудности, с которыми можно столкнуться при этом.
•	9.8.2. Проблемы выбора персонального устройства
Если вы хотите объединить все установленные системы защиты информации и при-
менить для доступа единое средство аутентификации и хранения ключевой информа-
ции, то неизбежно столкнетесь со следующими трудностями:
•	системы зашиты информации работают с конкретными типами идентификаторов:
•	СКЗИ настроены на использование определенных идентификаторов;
•	RFID-метки размещаются только в смарт-картах;
•	не все типы идентификаторов могут быть универсальными (применимыми к раз-
ным системам).
В частности, для того, чтобы полностью отвечать бизнес-задачам защиты информа-
ции, персональный идентификатор должен как минимум содержать процессор для вы-
полнения криптографических операций на закрытом ключе пользователя и иметь до-
статочно большой (порядка 20—40 килобайт) запас свободной энергонезависимой па-
мяти для записи цифровых сертификатов (каждый сертификат занимает в среднем от 1,5
до 2 Кбайт) и других параметров доступа к системам, которые не могут поддерживать
использование сертификатов стандарта Х.509 для аутентификации. Прежде чем рас-
смотреть существующие идентификаторы с точки зрения выполнения перечисленных
выше задач, попробуем сформулировать критерии выбора.
ЧАСТЫ. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
9.8.3.	Критерии выбора
Для выбора персонального средства аутентификации и хранения ключевой инфор-
мации предлагается применять следующие минимальные бизнес-критерии
1.	Обеспечение строгой (двухфакторной) аутентификации при доступе к корпоратив-
ной сети, информационным ресурсам, защищенным приложениям.
2.	Возможность защищенного хранения в персональном идентификаторе ключевого
контейнера, сформированного СКЗИ, закрытого ключа пользователя (в терминах PKI).
3.	Обеспечение зашиты критичной информации от несанкционированного доступа.
4.	Наличие необходимого объема свободной памяти в персональном идентификаторе
для записи ключевой информации и других параметров доступа пользователя к защи-
щенным ресурсам.
5.	Надежность идентификатора как хранилища ключевой информации (физическая
защита чипа, гарантированный срок применения, соответствие отечественным и меж-
дународным стандартам).
6.	Приемлемая средняя стоимость.
Насколько хорошо отвечают широко известные типы идентификаторов (парольная
защита, дискета, устройство iButton, USB-ключи/смарт-карты) сформулированным
критериям?
Детальный анализ показывает, что парольная защита, дискета и устройства iButton не
отвечают указанным критериям. Наиболее приемлемыми (исходя из минимальных кри-
териев) являются устройства класса USB-ключа eToken. Заметим, что функционально
eToken PRO и смарт-карта, содержащая чип, идентичны, поскольку eToken — это
смарт-карта и считыватель в одном устройстве.
Парольная защита не может использоваться для решения рассматриваемых задач за-
щиты корпоративной информации.
Несложно объяснить, почему до сих пор многие заказчики предпочитают пользо-
ваться персональными идентификаторами в виде дискеты. На этот выбор влияют три
фактора: низкая стоимость, большой объем памяти и то, что дискета в качестве носителя
поддерживается практически всеми отечественными производителями систем криптогра-
фической защиты информации. При этом не учитывается тот факт, что в случае попадания
дискеты в руки злоумышленника (этого достаточно — никакой зашиты нет) от вашего
имени (а во многих случаях и с вашей подписью) могут быть совершены действия по-
следствия которых приведут к краху бизнеса предприятия. К тому же дискета недолго-
вечна, скажем, в интенсивно используемых приложениях типа систем «клиент-банк»
в течение года приходится менять десятки дискет в расчете на одного пользователя. При
этом на каждую замену тратятся время и деньги не только пользователя, но и произво-
дителя системы.
Не представляется возможным персонифицировать пользователя «таблеток» iButton.
Характерно на этот счет высказывание одного из специалистов по защите информации:
«При использовании "таблетки" iButton в качестве персонального идентификатора вы
получаете защиту корпоративной информации на уровне домофона».
Таким образом, в качестве универсальных персональных идентификаторов можно
порекомендовать только устройства класса процессорной смарт-карты и USB-ключа
(например, смарт-карты или USB-ключи eToken компании Aladdin).
Глава 9 Применение аппаратных средств аутентификации и хранения клкэчевой инфор мации
Контрольные вопросы
1.	На каких этапах должна быть обеспечена безопасность закр ытого ключа пользов;
теля?
2.	Перечислите подходы к обеспечению безопасности закрытых ключей.
3.	Опишите жизненный цикл токенов.
4.	Перечислите функции централизованной системы управления.
5.	Перечислите основные критерии выбора персонального средства аутентификаци
и хранения ключевой информации.
Список использованной литературы
1.	A Guide to Understanding Identification and Authentication in Trusted Sy-stems, U.S. National Corr
puter Security Center.
2	Курило А. П. и др. Обеспечение информационной безопасности бизнеса. — М.: БДЦ-Прес<
2005.
3.	Документ RFC 4226, http://www.ietf.org/rfc/rfc4226.txt.
4.	cToken NG-ОТР. Краткая справочная информация. — Компания Aladdin, жсплуатационна
документация, 2006.
5.	Федеральный закон Российской Федерации от 10 января 2002 г. N 1-ФЗ -Об электронно!
цифровой подписи».
6.	Ричард Э. Смит. Аутентификация: от паролей до открытых ключей. — М.: Вильямс, 2002.
7.	Рекомендации к средствам криптографической защиты информации на взаимодействие удосто
веряющих центров, реестров сертификатов, сертификаты ключей формата Х.509 и электрон
ные документы формата CMS. — ООО «КРИПТО-ПРО», 2001.
8.	Стандарты ГОСТ 28147-89, ГОСТ Р 34.10-94 «Информационная технология. Криптографи
ческая зашита информации. Процедуры выработки и проверки электронной цифровой подписг
на базе асимметричного криптографического алгоритма*, ГОСТ Р 34.10—2001 «Информаци-
онная технология. Криптографическая зашита информации. Процессы формирования и про-
верки электронной цифровой подписи», ГОСТ Р 34.11—94 «Информационная технология
Криптографическая зашита информации. Функция хэширования».
9.	Документы RFC 4357, 4490, RFC 4491.
10.	Горбатов В. С., Полянская О. Ю. Основы технологии PKI. — М.: Горячая линия — Телеком.
2004.
11.	Рассел Ч., Кроуфорд LLL, Джеренд Дж. Microsoft Windows Server 2003. Справочник админист-
ратора. — М.: Издательство «Эком», 2006.
12.	Мак-Федрис П. Microsoft Windows ХР. Полное руководство. — М.: Вильямс, 2006
13.	[CMS] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3852, July 2004.
14.	[CPALGS] Popov, V., Kurepkin, 1., and S. Leontiev, «Additional Cryptographic Algorithms for Use with
GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms»
RFC 4357, January 2006.
15.	[CPCMS] S Leontiev, Ed., G. Chudov, Ed., «Using the GOST 28147—89, GOST R 34.11—94, GOST
R 34.10—94, and GOST R 34.10—2001 Algorithms with Cryptographic Message Syntax (CMS)»,
RFC 4490, May 2006.
16.	[CPPK1 S. Leontiev, Ed. and D. Shefanovskij, Ed., «Using the GOST R 34.10—94, GOST R 34.10—2001,
and GOST R 34 11—94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and
CRL Profile», RFC 4491, May 2006.
ЧАСТЫ ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
7.	[PKIX] Housley, R.. Polk. W., Ford. W., and D. Solo, •Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile», RFC 3280, April 2002.
8.	|SMIME] B. Ramsdell, «Secure/Multipurpose Internet Mail Extensions (S/M1ME) Version 3.1
Message Specification», RFC 3851, July 2004.
9.	Веб-сайт компании Майкрософт для технических специалистов (на русском языке)
http://technet.microsoft.com/ru-ru/default.aspx.
Ю. Майкл Уэнстром. Организация защиты сетей Cisco (Managing Cisco Network Security) Изда-
тельство «Вильямс», 2003, 768 стр. ISBN 5-8459-0387-4 1-5787-0103-1.
Я. Шиндер Д. Основы компьютерных сетей. Серия: Cisco Press, 2002 г.. 656 стр., ISBN:
5845902851, 1587130386.
2.	Дэвид В Чепмен мл., Энди Фокс Брандмауэры Cisco Secure PIX Издательство: Вильямс, 2003
г., 384, с ил. ISBN: 5-8459-0463-3, 1-5870-5035-8.
3.	Кэтрин Пакет. Создание сетей удаленного доступа Cisco. Издательство: Вильямс, 2003 г., 672,
сил., ISBN: 5-8459-0443-9, 1-5787-0091-4.
24.	Педжман Рошан. Джонатан Лиэри. Основы построения беспроводных локальных сетей стан-
дарта 802.11. Руководство Cisco. Издательство: Вильямс, 2004 г., 304, с ил., ISBN:
5-8459-0701-2, 1-5870-5077-3.
25.	Альваро Ретана, Дон Слайс, Расс Уайт. Принципы проектирования корпоративных 1Р-сетей.
Издательство: Вильямс, 2002 г., 368, с ил., ISBN: 5-8459-0248-7, 1-57870-097-3.
26.	Джим Гейер. Беспроводные сети. Первый шаг (Cisco). Издательство: Вильямс, 2005 г., 192
стр., с ил.; ISBN 5-8459-0852-3, 1-58-720111-9.
27.	Vijay Bollapragada, Mohamed Khalid. Scott Wainner. IPSec VPN Design CiscoPress, 2005, ISBN:
1-58-705111-7.
28.	Troubleshooting Virtual Private Networks (VPN). Mark Lewis. Cisco Press, 2007, ISBN:
1-58-705104-4.
ЧАСТЬ II
ПРАКТИКА
Практическая роль аутентификации в современном компьютеризированном мире
весьма велика. Пользователи компьютеров используют механизмы аутентификации для
того, чтобы быть авторизованными в своем компьютере, в корпоративной сети, для до-
ступа к различным приложениям. С точки зрения защиты информации аутентификация
является обязательной составляющей практически всех систем защиты информации,
а для защиты от несанкционированного доступа аутентификация является одним из важ-
нейших механизмов защиты наряду с шифрованием информации. С точки зрения биз-
нес-ориентированных информационных систем роль аутентификации особенно велика
для организации таких сервисов, как:
•	доступ к корпоративной сети;
•	удаленный доступ к корпоративной сети и приложениям, в том числе беспровод-
ной доступ;
•	применение ЭЦП в документообороте, а также для подписи и шифрования со-
общений;
•	доступ к системам дистанционного банковского обслуживания;
•	доступ к системам планирования ресурсов предприятия (ERP), управления вза-
имоотношениями с клиентами (CRM), управления цепочками поставок (SCM),
биллинговым системам и т.д.;
•	организация защищенных каналов взаимодействия (VPN);
•	защита данных на серверах и рабочих станциях.
Безусловно, для организации доступа к различным информационным системам требу-
ется использовать те или иные механизмы и средства аутентификации (рассмотренные
в первой части данной книги) в зависимости от уровня защищенности систем и инфор-
мационных ресурсов.
Практические решения ряда типовых задач по организации систем аутентификации
на различных платформах приводятся в следующих главах.
Глава I
ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ
ДОСТУПА К ДАННЫМ И ПРИЛОЖЕНИЯМ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ОРГАНИЗАЦИИ
НА ОСНОВЕ РЕКОМЕНДАЦИЙ
И ПРОДУКТОВ MICROSOFT.
ТИПОВЫЕ РЕШЕНИЯ
1.1.	Основные сервисы для обеспечения
надежной аутентификации и управления доступом
Корпорация Microsoft выделяет пять основных сервисов (областей), связанных с обес-
печением надежной аутентификации и управлением доступом:
•	служба каталога (Active Directory Domain Services);
•	инфраструктура PKI, шифрования, управления циклами безопасности, аутентифи-
кация с помощью сертификатов или смарткарт (Active Directory Certificate Services);
•	управление федеративными отношениями (Active Directory Federation Service);
•	управление правами доступа к информации (Active Directory Rights Management
Services);
•	управление идентификацией (Microsoft Identity Lifecycle Manager 2007).
Основой для построения системы безопасности является Служба каталога Active
Directory Domain Services. Остальные решения могут использоваться в зависимости от
потребностей организации. Первые четыре области представляют собой платформу для
создания системы надежной аутентификации и управления доступом.
1.1.1. Служба каталога
(Active Directory Domain Services)
Наиболее известная область (и технология), используемая в настоящее время —
служба каталога Active Directory Domain Services которая является основным компо-
нентом безопасности Windows (рис. 1.1).
Основные цели и задачи службы каталога:
•	обеспечение централизованного управления и хранения учетной информации;
•	управление растущим количеством пользователей, ролей и устройств;
•	упрощение внесения изменений в политики безопасности компании, например,
включение многофакторной аутентификации, шифрование данных и контроль
исполнения политик безопасности.
Преимущества при ее использовании:
•	упрощение управления учетными записями через унифицированную консоль;
•	повышение безопасности с возможностью использования различных средств без-
опасности внутри сети;
•	возможность использования службы каталога в качестве средства аудита инфор-
мации об учетных записях;
•	снижение стоимости управления сетями
157
ЧАСТЫ1. ПРАКТИКА
Рис. 1.1. Служба каталога
Рис. 1.2. Служба аутентификации с помощью сертификатов
Гпава 1 Обеспечение безопасности доступа на основе рекомендаций и продуктов Microsoft
1.1.2.	Служба аутентификации с помощью сертификатов или смарт-карт
(Active Directory Domain Services)
Основные цели и задачи этой службы (рис. 1.2):
•	переход от традиционной аутентификации на основе имени и пароля пользова-
теля к более стойкой и надежной схеме;
•	поддержка индустриальных стандартов.
Преимущества при ее использовании:
•	повышение защищенности сети с помощью средств многофакторной аутентифи-
кации и проверки подлинности цифровых сертификатов с помощью протокола
Online Certificate Status Protocol (OCSP);
•	управление цифровыми сертификатами объектов (пользователей и устройств) без
вмешательства пользователей:
•	снижение стоимости владения благодаря автоматизации регистрации, хранения и
отзыва цифровых сертификатов с помощью Active Directory.
1.1.3.	Управление федеративными отношениями
(Active Directory Federation Services)
Служба Active Directory Federation Services в Windows Server 2003 R2 (рис. 1.3) является
для администраторов основным инструментом в построении корпоративной инфраструк-
туры с возможностью защищенного обмена идентификационными данными Здесь обыч-
SINGLE LOGON
PARTNER WEB APPLICATION
CREDENTIAL FOR ALL
BUSINESS PARTNERS J
TRUST
ESTABLISHED
ACTIVE DIRECTORY
FEDERATION SERVICES
FhDERAriON SERVICES
Рис. 1.3. Служба управления федеративными отношениями
ЧАСТЫ1. ПРАКТИКА
но возникает ряд вопросов, разрешить которые позволяет именно Active Directory Federation
Services. Интегрированные системы часто выходят за пределы организации и объединяют
между собой множество различных технологий, носителей идентификационных данных,
принципов реализации защиты и моделей программирования. В рамках интегрирован-
ной системы организации требуется надежный и отвечающий современным стандартам
механизм, определяюший не только принцип предоставления клиентам и партнерам
своих услуг, но также и соблюдение политик безопасности, т. е. порядок доверия конк-
ретным пользователям и организациям, предоставления и сохранности того или иного
рода персональных данных и обработки соответствующих запросов.
Основные цели и задачи Управления федеративными отношениями:
•	защищенное взаимодействие с другими организациями;
•	надежный контроль данных и предоставление доступа доверенным источникам;
•	возможность задать политики безопасности с доверенными организациями;
•	обеспечение единого входа в систему (Single Sign-On).
Преимущества при его использовании:
•	использование Active Directory в качестве главного репозитория идентификацион-
ных данных;
•	обеспечение взаимодействия и контроль доступа к данным;
•	прозрачность взаимодействия с разделением прав и ролей;
•	максимальное использование имеющихся компенентов (служба каталога Active
Directory и системы безопасности);
•	усовершенствованная система безопасности за счет применения службы Active Di-
rectory Federation Services, токенов SAML и аутентификации по протоколу Kerberos.
1.1.4.	Служба защиты информации
(Active Directory Rights Management Services)
Основные цели и задачи данной службы (рис. I.4):
•	исключение неавторизованного доступа и компрометации конфиденциальной ин-
формации (отметим, что RMS предназначен для защиты информации вне сети/инф-
раструкгуры владельца);
•	снижение рисков, связанных с потерей конкурентноспособности организации.
Преимущества при ее использовании:
•	повышение безопасности информации с помощью постоянной защиты данных;
•	простое внедрение готового решения с возможностью интеграции с приложениями
(Microsoft Office System) почтовой системы и службой каталога Active Directory;
•	интеграция с продуктами третьих фирм с помощью использования комплекта раз-
работчика (RMS SDK).
1.1.5.	Служба управления идентификацией
(Identity Lifecycle Management)
Основные цели и задачи службы управления идентификацией (рис. 1.5):
•	простое и эффективное управление большим количеством цифровых удостовере-
ний различных форматов;
•	снижение рисков и стоимости владения при ручном управлении (provisioning и
de-provisioning) идентификаторами пользователей (user identities);
Глава 1. Обеспечение безопасности доступа на основе рекомендаций и продуктов Microsoft
Рис. 1.4. Служба защиты информации
ACTIVE DIRECTORY
e-mail system 'fdentityLifecycle HR SYSTEM
Manager 2007
Рис. 1.5. Служба управления идентификацией
ЧАСТЫ1 ПРАКТИКА
•	упрощение управления средствами аутентификации пользователей, такими как
смарт-карты и цифровые сертификаты;
•	упрощение поддержки пользователей, например, при смене паролей
Преимущества при ее использовании :
•	реализация принципа «один пользователь — одна учетная запись в системе»;
•	объединение управления всеми видами цифровых удостоверений и носителей;
•	создание единого метакаталога организации;
•	возможность автоматизации обслуживания и самообслуживания пользователей (на-
пример, при смене пароля или изменении PIN-кода смарт-карты).
1.1.6.	Аутентификация в службе каталога Active Directory
Операционная система Windows Server по существу является платформой информаци-
онной системы. Поэтому изначально в нее заложены механизмы, реализующие защиту
информации на всех уровнях:
•	пользователь;
•	рабочая станция;
•	сеть;
•	сервер;
•	доступ во внешние сети, например — Интернет.
Весь инструментарий Windows, отвечающий за безопасность, можно сгруппировать
по трем направлениям:
•	аутентификация (проверка подлинности) субъектов;
•	авторизация (контроль доступа субъектов к объектам);
•	шифрование информационных хранилищ и потоков.
Работа любого пользователя в сети Windows Server 2003 начинается с обязательной
аутентификации. По сути, аутентификация — это ответ на вопрос: «Кто ты и чем можешь
это доказать?». Процесс аутентификации начинается с того, что пользователь сообщает
системе свои регистрационные параметры, например, регистрационное имя и пароль.
Надо отметить, что регистрационное имя и пароль не являются надежным средством
аутентификации, поэтому Microsoft рекомендует использовать средства многофакторной
аутентификации пользователей.
Поскольку передавать пароль по сети небезопасно (он может быть перехвачен злоумыш-
ленником), необходимо обеспечить возможность подтверждения правильности пароля,
введенного на рабочей станции пользователя, без передачи пароля по сети в открытом
виде.
В семействе Windows Server 2003 реализованы следующие алгоритмы аутентификации:
•	Lan Manager (LM);
•	NTLM;
•	NTLM v2;
•	Kerberos v 5.
Windows Server 2003 также обеспечивает поддержку следующих протоколов:
•	Х.509 v3/Smartcard;
•	проверка подлинности Digest;
•	проверка подлинности .NET Passport;
•	аутентификация удаленного пользователя — расширенный протокол EAP-TLS;
•	аутентификация при установлении защищенного канала — протокол SSL/TLS;
•	аутентификация хостов при установлении сеанса IP Security
162
Глава 1. Обеспечение безопасности доступа на основе рекомендации и продуктов Microsoft
Использование протокола Lan Manager крайне нежелательно из-за его невысокой на-
дежности. Вместе с тем, он нередко используется в сетях Active Directory. Это мотивиру-
ется необходимостью обеспечения «совместимости» с клиентами на основе Windows 9Х.
Однако, после установки клиента Active Directory Services (ADSC) в Windows 9X появ-
ляется возможность поддержки протокола аутентификации NTLM v2, что позволяет от-
казаться от использования LM в сети. Кроме того, установка клиента ADS предоставляет
ряд других преимуществ, таких как поиск через Глобальный каталог, изменение пароля
на любом контроллере домена и пр. В Windows NT 4.0 поддержка NTLM v2 появляется
после установки пакета Service Pack 4
Таким образом, в смешанной сети, где присутствуют pre-Windows 2000 компьютеры,
для повышения безопасности аутентификации рекомендуется:
1)	установить на все компьютеры Windows 9Х клиент ADS;
2)	установить на все компьютеры с Windows NT 4 0 пакет обновлений не ниже 4-го;
3)	через групповую политику запретить использование LM и NTLM.
Дополнительную информацию см. в статье КВ239869 на веб-узле корпорации Microsoft
Наиболее защищенным является протокол аутентификации Kerberos, реализованный
в ОС Microsoft, начиная с Windows 2000. Ниже перечислены его основные преимущества
Более эффективная аутентификация на серверах. При аутентификации по протоколу
NTLM серверу приложений приходится подключаться к контроллеру домена при провер-
ке каждого клиента. С Kerberos такая необходимость отпадает — здесь аутентификация
производится за счет проверки удостоверения, представленного клиентом. Индивидуаль-
ное удостоверение клиент получает от контроллера единожды, после чего может неодно-
кратно использовать его на протяжении всего сеанса работы в сети.
Взаимная аутентификация. Протокол NTLM позволяет серверу идентифицировать
своих клиентов, однако не предусматривает верификации сервера ни клиентами, ни дру-
гими серверами. Этот протокол разрабатывался для сетей, в которых все серверы счи-
таются легитимными. В отличие от него, Kerberos такого допущения не делает, поэтому
проверяет обоих участников сетевого подключения, каждый из которых в результате может
точно узнать, с кем поддерживает связь.
Делегированная аутентификация. Когда клиент сети Windows обращается к ресурсам,
службы операционной системы прежде всего производят его идентификацию. Во многих
случаях для выполнения этой операции службе достаточно информации на локальном
компьютере. Как NTLM, так и Keiberos обеспечивают все данные необходимые для иден-
тификации пользователя на месте, однако иногда их бывает недостаточно. Некоторые
распределенные приложения требуют, чтобы при подключении к серверным службам на
других компьютерах идентификация клиента производилась локально службой самого
 -того клиента. Проблему помогает решить Kerberos, где предусмотрен специальный ме-
ханизм представительских билетов, который позволяет на месте идентифицировать кли-
ента при его подключении к другим системам. В протоколе NTLM такая возможность
отсутствует.
Упрощенное управление доверительными отношениями. Одно из важных достоинств
взаимной аутентификации по протоколу Kerberos состоит в том, что доверительные от-
ношения между доменами Windows Server 2003 по умолчанию являются двусторонними
и транзитивными. Благодаря этому в сетях с множеством доменов не придется устанав-
ливать много явных доверительных отношений. Вместо этого все домены большой сети
можно свести в дерево транзитивных отношений взаимного доверия. Удостоверение,
выданное системой безопасности для любого домена, может приниматься во всех ветвях
дерева. Если же сеть содержит несколько деревьев, то удостоверение любого из них будет
приниматься по всему «лесу».
ЧАСТЫ1 ПРАКТИКА
Совместимость. В основе своей реализации протокола Kerberos корпорация Microsoft
использовала стандартные спецификации, рекомендованные группой 1ETF. Благодаря
такому подходу удалось обеспечить аутентификацию клиентов Windows 2000/ХР во всех
сетях, которые поддерживают Kerberos 5.
Протокол Kerberos был создан в Массачусетском технологическом институте в рам-
ках проекта Athena. Однако общедоступным этот протокол стал лишь после появления
версии 4. После того как специалисты отрасли изучили новый протокол, его авторы раз-
работали и предложили пользователям очередную версию — Kerberos v5. которая и была
принята в качестве стандарта IETF (RFC 1510).
В Windows Server 2003 нашли применение расширения протокола Kerberos, упрощающие
начальную аутентификацию клиентов. Обычно для этой цели используются секретные
ключи, которыми должны заранее обменяться между собой участники сеанса, но теперь
такую процедуру можно провести с помощью открытых ключей Благодаря этому по-
явилась возможность интерактивной регистрации пользователя с помощью смарт-карт.
В основу расширений, обеспечивающих аутентификацию с открытым ключом, легла
спецификация PKINIT.
Базовая концепция Kerberos. Описывает троих участников сетевого взаимодействия:
клиент, пытающийся получить доступ к ресурсу, сервер, на котором расположен необ-
ходимый ресурс, и Центр распределения ключей (Key Distribution Center, KDC), высту-
пающий в роли посредника между клиентом и сервером.
KDC выпускает специальные билеты (tickets), которые служат как бы «документами»
в процессе аутентификации. Кроме того, в случае успешной аутентификации, в билет
помешается информация, необходимая для последующей авторизации клиента при об-
ращении к ресурсу.
Принцип работы протокола Kerberos. Для начала рассмотрим базовый принцип работы
Kerberos. Протокол Kerberos активно использует технологии аутентификации, опирающиеся
на «секреты для двоих». Основная идея довольно проста: если есть секретный ключ, извест-
ный только двоим, любой из его хранителей может легко удостовериться, что имеет дело
именно со своим напарником. Для этого ему достаточно каким-либо способом проверить,
знает ли собеседник их общий секретный ключ. Предположим, что некоторые клиент и сер-
вер (и только они) обладают копией секретного ключа Клиент формирует запрос на аутен-
тификацию к серверу, помешает в этот запрос свое имя и текущее время и зашифровывает
запрос своей копией ключа. Зашифрованная структура данных носит название аутентифи-
катор (authenticator) Получив запрос, сервер расшифровывает его своей копией ключа и
сравнивает метку времени из запроса с текущим временем на своих часах. Будем исходить
из того, что часы на всех компьютерах сети синхронизированы. Если полученная метка
времени расходится с текущим временем на сервере более чем на пять минут, аутентифи-
катор отвергается. Если же время оказывается в пределах допустимого отклонения можно
с большой долей уверенности предположить, что аутентификатор поступил именно отдан-
ного клиента. Возможна однако и такая ситуация: кто-то перехватил предыдущую попытку
клиента связаться с сервером и теперь пытается воспользоваться его аутентификатором.
Но если на сервере сохранились записи о времени аутентификаторов, поступивших от дан-
ного клиента за последние пять минут, можно найти последний и отказаться от всех других
сообщений, отправленных одновременно с ним или ранее. Иными словами, проверка вре-
менной метки позволяет существенно снизить вероятность перехвата и последующего
подбора пароля.
Убедившись, что аутентификатор удалось расшифровать и временная метка в пределах
допустимого, сервер формирует ответный пакет, помещает в него метку времени из аутенти-
фикатора клиента, зашифровывает пакет своей копией секретного ключа и отсылает клиенту.
164
Глава 1 Обеспечение безопасности доступа на основе рекомендаций и продуктов Microsoft
Клиент получает ответ сервера, расшифровывает его, а затем сравнивает полученный
результат со временем, которое было указано в исходном аутентификаторе. Если эти
данные совпадают, можно быть уверенным, что аутентификатор дошел именно до тре-
буемого сервера, и именно требуемый сервер на него ответил. Таким образом выполня-
ется взаимная аутентификация клиента и сервера.
Остается решить одну проблему: каким образом безопасно передать клиенту и сер-
веру (и только им) копии секретного ключа?
Для решения проблемы обмена ключами и был введен третий участник — посредник
между клиентом и сервером. В протоколе Kerberos он называется KDC. KDC представ-
ляет собой службу, работающую на физически защищенном сервере. Эта служба ведет
базу данных с информацией об учетных записях всех главных абонентов безопасности
(security principals) своей области (realm) (области Kerberos в сетях Windows Server 2003
соответствует домен). Вместе с информацией о каждом абоненте безопасности в базе
данных KDC сохраняется криптографический ключ, известный только этому абоненту
и службе KDC. Данный ключ, который называют долговременным, используется для
связи пользователя системы безопасности с центром распределения ключей. Долговре-
менные ключи создаются на основе пароля пользователя. В реализации Microsoft функ-
цию KDC выполняет контроллер домена (Domain Controller, DC).
Когда клиенту нужно обратиться к серверу, он прежде всего направляет запрос в центр
KDC, который в ответ направляет каждому участнику предстоящего сеанса копии уникаль-
ного сгенерированного именно для этой пары абонентов сеансового ключа (session key),
действующие в течение короткого времени. Копия сеансового ключа, пересылаемая
клиенту, шифруется с помощью долговременного ключа этого клиента, а направляемая
серверу — долговременного ключа данного сервера.
Теоретически для выполнения функций доверенного посредника центру KDC доста-
точно направить сеансовые ключи непосредственно абонентам безопасности, как показа-
но выше. Однако на практике реализовать такую схему чрезвычайно сложно. Прежде всего,
серверу пришлось бы сохранять свою копию сеансового ключа в памяти до тех пор, пока
клиент не свяжется с ним. А ведь сервер обслуживает не одного клиента, поэтому ему
нужно хранить пароли всех клиентов, которые могут потребовать его внимания. В таких
условиях управление ключами требует значительной затраты серверных ресурсов, что
ограничивает масштабность системы. Нельзя забывать и о превратностях сетевого тра-
фика. Они могут привести к тому, что запрос от клиента, уже получившего сеансовый
пароль, поступит на сервер раньше, чем сообщение KDC с этим паролем. В результате
серверу придется повременить с ответом до тех пор, пока он не получит свою копию се-
ансового пароля. Поэтому на практике применяется другая схема управления ключами,
которая делает протокол Kerberos гораздо более эффективным.
В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC на-
правляет обе копии сеансового ключа клиенту. Сообщение, предназначенное клиенту,
шифруется с помощью долговременного ключа клиента, а сеансовый ключ для сервера
вместе с информацией о клиенте вкладывается в блок данных, получивший название се-
ансового билета (session ticket). Затем сеансовый билет целиком шифруется с помощью
долговременного ключа сервера, который знают только служба KDC и данный сервер
После этого вся ответственность за обработку билета, несущего в себе зашифрованный
сеансовый ключ, возлагается на клиента, который должен доставить его на сервер.
Обратите внимание, что в данном случае функции службы KDC ограничиваются вы-
дачей билета. Ей больше не нужно следить за тем. все ли отправленные сообщения до-
ставлены соответствующим адресатам. Даже если какое-нибудь из них попадет не туда, —
ничего страшного не случится. Расшифровать клиентскую копию сеансового ключа может
ЧАСТЫ1. ПРАКТИКА
только тот, кто знает секретный долговременный ключ данного клиента, а чтобы про-
честь содержимое сеансового билета, нужен долговременный секретный ключ сервера.
Получив ответ KDC. клиент извлекает из него сеансовый билет и свою копию сеан-
сового ключа, которые помещает в безопасное хранилище (оно располагается не на ди-
ске, а в оперативной памяти).
Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение,
состоящее из билета, который по-прежнему зашифрован с помощью долговременного
ключа этого сервера, и собственного аутентификатора, зашифрованного с помощью сеан-
сового ключа. Этот билет в комбинации с аутентификатором как раз и составляет удос-
товерение, по которому сервер определяет «личность» клиента.
Сервер получив «удостоверение личности» клиента, с помощью своего секретного
ключа расшифровывает сеансовый билет и извлекает из него сеансовый ключ, который
затем использует для дешифрования аутентификатора клиента. Если все проходит нор-
мально делается заключение, что удостоверение клиента выдано доверенным посред-
ником, то есть службой KDC. Клиент может потребовать у сервера проведения взаимной
аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шиф-
рует метку времени из аутентификатора клиента и в таком виде пересылает ее клиенту
в качестве собственного аутентификатора.
Одно из достоинств сеансовых билетов состоит в том, что серверу не нужно хранить
сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений
(credentials cache) клиента, который направляет билет на сервер каждый раз, когда хочет
связаться с ним. Сервер, со своей стороны, получив от клиента билет, расшифровывает
его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может
просто стереть его из своей памяти.
Такой метод дает еще одно преимущество: у клиента исчезает необходимость обра-
щаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые
билеты можно использовать многократно. На случай же их хищения устанавливается
срок годности билета, который KDC указывает в самой структуре данных. Это время оп-
ределяется политикой Kerberos для конкретного домена. Обычно срок годности билетов
не превышает 8 ч, т. е. стандартной продолжительности одного сеанса работы в сети.
Когда пользователь отключается от нее, кэш-память удостоверений обнуляется, и все сеан-
совые билеты вместе с сеансовыми ключами уничтожаются.
Итак, в процедуре аутентификации используются:
•	индивидуальный (он же долговременный) ключ компьютера (сервера и рабочей стан-
ции), который создается при включении компьютера в домен и хранится в Active
Directory;
•	сеансовый ключ, который генерируется KDC для конкретной пары абонентов
безопасности, и используется при аутентификации.
При этом возникает вопрос: «Каким же образом клиент взаимодействует с KDC?».
Ведь очевидно, что это взаимодействие также должно быть безопасным.
Когда пользователь проходит регистрацию, клиент Kerberos, установленный на его
рабочей станции, пропускает введенный пароль через функцию хэширования В резуль-
тате формируется криптографический ключ, с помощью которого аутентификатор поль-
зователя шифруется и затем пересылается ближайшему KDC. Получив запрос от клиента,
KDC обращается в базу AD. находит в ней учетную запись нужного пользователя и из-
влекает из соответствующего ей поля долговременный ключ. Такой процесс — вычис-
ление одной копии ключа по паролю и извлечение другой его копии из базы данных —
выполняется всего лишь один раз за сеанс, когда пользователь входит в сеть впервые.
Сразу же после получения пользовательского пароля и вычисления долговременного
Глава 1 Обеспечение безопасности доступа на основе рекомендации и продуктов Microsoft
ключа клиент Kerberos рабочей станции запрашивает сеансовый билет и сеансовый ключ,
которые используются во всех последующих транзакциях с KDC на протяжении теку-
щего сеанса работы в сети.
На запрос пользователя KDC отвечает специальным сеансовым билетом для самого
себя, так называемый билет на выдачу билетов (ticket-granting ticket), или билет TGT.
Как и обычный сеансовый билет, TGT содержит копию сеансового ключа для связи
службы (в данном случае — KDC) с клиентом. В сообщение с билетом TGT также вклю-
чается копия сеансового ключа, с помощью которой клиент может связаться с KDC.
Билет TGT шифруется с помощью долговременного ключа службы KDC, а клиент-
ская копия сеансового ключа — с помощью долговременного ключа пользователя.
Получив ответ службы KDC на свои первоначальный запрос, клиент расшифровы-
вает свою копию сеансового ключа, используя для этого копию долговременного ключа
пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из
пользовательского пароля, можно удалить из памяти, поскольку он больше не понад-
обится- вся последующая связь с К DC будет шифроваться с помощью сеансового ключа.
Как и все другие сеансовые ключи, он имеет временный характер и действителен до ис-
течения срока действия билета TGT либо до выхода пользователя из системы. По этой
причине такой ключ называют сеансовым ключом регистрации (logon session key).
С точки зрения клиента билет TGT почти ничем не отличается от обычного. Перед
подключением к любой службе, клиент, прежде всего, обращается в кэш-память удос-
товерений и извлекает оттуда сеансовый билет для этой службы. Если его нет он начи-
нает искать в этой же кэш-памяти билет TGT. Найдя его. клиент извлекает оттуда же со-
ответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор,
который вместе с TGT высылает в KDC. Одновременно туда направляется ianpoc на се-
ансовый билет для требуемой службы.
По аналогии с аутентификацией на сервере аутентификация при входе в домен исполь-
зует индивидуальный (долговременный) ключ пользователя, сеансовый ключ для связи
пользователя и KDC и, наконец, долговременный ключ самого KDC, формируемый на
основе учетной записи krbtgt, имеющейся на каждом DC.
В реализации Windows Server 2003 Kerberos содержит в себе три подпротокола. Первый
из них используется службой KDC для передачи клиенту сеансового ключа регистрации
и билета TGT. Он называется Authentication Service Exchange (обмен со службой аутен-
тификации) или, сокращенно AS Exchange. Второй подпротокол под названием
Ticket-Granting Service Exchange (обмен со службой выдачи билетов) или TGS Exchange
служит для рассылки служебных сеансовых ключей и сеансовых ключей самой службы KDC.
Третий подпротокол Client/Server Exchange (клиент-серверный обмен) или CS
Exchange используется клиентом для пересылки сеансового билета доступа к службам
Такое разделение труда позволяет применять протокол Kerberos и за пределами его
«родного» домена. Клиент, получивший билет TGT из службы аутентификации одного
домена, может воспользоваться им для получения сеансовых билетов в службах выдачи
билетов других доменов. Наладить аутентификацию между доменами нетрудно, для это-
го достаточно договориться о едином междоменном ключе (Inter-Realm key). В Windows
Server 2003 такой ключ генерируется автоматически, когда между доменами устанавли-
ваются юверительные отношения. Служба выдачи билетов каждого домена регистриру-
ется в центре К DC другого домена в качестве главного абонента безопасности. В резуль-
тате служба выдачи билетов каждого домена начинает рассматривать службу выдачи би-
летов второго домена, как еще одну свою службу. Благодаря этому клиент, прошедший
аутентификацию и зарегистрировавшийся в системе, может запрашивать и получать се-
ансовые билеты для нее.
ЧАСТЫ1 ПРАКТИКА
Теперь рассмотрим, что происходит, когда пользователь с учетной записью в домене West
запрашивает доступ к серверу из домена East. Прежде всего, клиент Kerberos, установ-
ленный на рабочей станции этого пользователя, посылает запрос в службу выдачи би-
летов своего домена, в котором просит выдать сеансовый билет для доступа на нужный
сервер. Служба выдачи билетов домена West проверяет список своих абонентов безопас-
ности и убеждается, что такого сервера среди них нет. Поэтому она направляет клиенту
так называемый билет переадресации (referral ticket), который представляет собой TGT,
зашифрованный с помощью междоменного ключа, общего для служб KDC доменов West
и Company. Получив билет переадресации, клиент использует его для подготовки другого
запроса на сеансовый ключ. Однако на этот раз запрос пересылается в службу выдачи
билетов домена Company, откуда в ответном пакете приходит билет переадресации для
домена East, зашифрованный с помощью междоменного ключа, общего для служб КОС
доменов Company и East. Наконец, направляется запрос на сеансовый ключ в домен, где
находится учетная запись нужного сервера, то есть, в домен East. Его служба выдачи би-
летов пытается расшифровать билет переадресации с помощью собственной копии меж-
доменного ключа. Если попытка удается, центр KDC направляет клиенту сеансовый билет
на доступ к соответствующему серверу своего домена.
Определенную сложность для протоколов аутентификации создают многоуровневые
клиент-серверные приложения Здесь клиент может подключаться к серверу, который,
в свою очередь, должен будет подключиться к другому серверу более высокого уровня.
Для этого первому серверу понадобится билет на подключение ко второму. В идеале такой
билет должен ограничивать доступ первого сервера ко второму лишь теми функциями,
на которые клиент имеет права.
Для решения этой проблемы в протоколе Kerberos имеется специальный механизм —
так называемое делегирование аутентификации. По существу в такой ситуации клиент
поручает свою аутентификацию серверу. С этой целью он уведомляет службу KDC о том,
что данный сервер имеет право представлять клиента. Такой подход называется импер-
сонацией (concept of impersonation).
Делегирование аутентификации возможно двумя способами. Во-первых, клиент может
получить билет на подключение к серверу высшего уровня а затем передать его ближай-
шему серверу. Билеты, полученные таким способом — клиентом для ближайшего сер-
вера — называются представительскими (proxy tickets). Однако на этом пути имеется одна
серьезная трудность: чтобы получить представительский билет, клиенту нужно знать
имя сервера высшего уровня. Решить проблему помогает второй способ делегирования
аутентификации. Здесь клиент передает на ближайший к нему сервер свой билет TGT,
который тот по мере необходимости использует для запроса собственных билетов. Билеты
TGT, полученные таким образом, т. е. по удостоверению клиента, называются переда-
ваемыми (forwarded tickets). Какой из описанных способов применяется службой KDC,
зависит от политики Kerberos.
Необходимо отметить, что предложенная в Kerberos схема зависит от сложности исполь-
зуемых паролей. Повысить надежность аутентификации позволяет применение смарт-карт
и криптографии с открытым ключом. На смарт-карте хранятся личный ключ пользова-
теля и цифровой сертификат с открытым ключом Для доступа к личному ключу необ-
ходимо ввести уникальный для данной карты PIN-код (Personal Identification Number).
Повышение безопасности при использовании смарт-карт обусловлено нескольким
факторами.
Во-первых, все операции с ключами выполняются непосредственно на смарт-карте,
ключи никогда не хранятся в файловой системе компьютера и скомпрометировать их го-
раздо сложнее.
168
Глава 1. Обеспечение безопасности доступа на основе рекомендаций и продуктов Microsoft
Во-вторых, аутентификация становится двухфакторной, т. е., чтобы зарегистрировать-
ся в системе, необходимо:
1) обладать смарт-картой;
2) знать PIN-код.
В Windows Server 2003 аутентификация с помощью смарт-карт по протоколу Kerberos
реализована с помощью расширения, называемого PKINIT.
PKINIT предусматривает следующий порядок использования пары ключей пользо-
вателя. Открытый ключ служит для шифрования сеансового ключа пользователя службой
KDC, а личный — для расшифровывания этого ключа клиентом.
Регистрация начинается с того, что пользователь вставляет свою смарт-карту в специ-
альное считывающее устройство, подключенное к компьютеру, и вводит PIN-код. Windows
использует PIN-код пользователя для доступа к смарт-карте, где хранятся секретный ключ
пользователя и сертификат Х.509 v3, содержащий открытый ключ пары. В дальнейшем
все криптографические операции с использованием данной пары будут производиться
через смарт-карту.
Kerberos SSP клиентского компьютера направляет в службу KDC сообщение
KRB_AS_REQ — первоначальный запрос на аутентификацию. В поле данных предвари-
тельной аутентификации этого запроса включается сертификат открытого ключа поль-
зователя. Аутентификатор подписывается личным ключом пользователя. KDC проверя-
ет подлинность сертификата и извлекает из него открытый ключ, которым проверяет
корректность аутентификатора
1.2.	Авторизация при доступе к объекту
Итак, аутентификация однозначно идентифицирует субъект. Проще говоря, после
успешной аутентификации система понимает, кто к ней обращается. Следующий шаг —
выяснить, какими правами обладает данный субъект. Эту задачу решает механизм авто-
ризации. Главные составляющие процесса авторизации — маркер доступа (access token),
связанный с субъектом (пользователем), и дескриптор безопасности (security descriptor),
связанный с объектом, к которому пользователь пытается обратиться.
Маркер доступа представляет собой структуру данных, в которую помещается иден-
тификатор безопасности пользователя (Security Identifier, SID), SID всех групп, членом
которых он является, а также список привилегий (User Rights), которыми пользователь
обладает.
Напомним, что маркер доступа помещается в специальный раздел сеансового билета
при аутентификации. Причем при входе в домен в маркере будет содержаться инфор-
мация о членстве в локальных группах рабочей станции, в которой пользователь заре-
гистрировался DC добавит в маркер сведения о членстве в глобальных и универсальных
группах. А при обращении к конкретному компьютеру в сети маркер пополнится ин-
формацией о членстве в локальных группах этого компьютера.
Права доступа на объект перечислены в дескрипторе безопасности, связанном с этим
объектом. В Windows Server 2003 дескрипторами безопасности обладают:
•	общие папки (shared folders);
•	принтеры;
•	файлы и папки на разделах NTFS;
•	все объекты Active Directory.
ЧАСТЬ II. ПРАКТИКА
Собственно дескриптор безопасности представляет собой структуру данных, состоящую
из двух списков управления доступом: Discretionary Access Control List (DACL) и System
Access Control List (SACL). Оба списка имеют одинаковую структуру и, в свою очередь,
состоят из набора шементов Access Control Entry (АСЕ). Однако АСЕ списка DACL со-
держит назначение прав для конкретного S1D, в то время как АСЕ списка SACL ука-
зывает, какие действия конкретного S1D должны протоколироваться системой аудита.
Заметим, что DACL объекта Active Directory может содержать строки АСЕ, назначенные
отдельным атрибутам. Тем самым в Active Directory администратор может назначать пра-
ва доступа не только на уровне объекта, но и на уровне конкретного атрибута объекта.
Например, можно разрешить/запретить редактирование номера рабочего телефона для
пользователей такого-то подразделения.
В Active Directory и в файловой системе NTFS реализован механизм наследования прав
доступа. Наследование позволяет существенно упростить назначение прав доступа в ука-
занных иерархических структурах. По умолчанию, объект, создаваемый на каком-либо
уровне иерархии, например, файл File.doc, унаследует права доступа с родительского
уровня, что избавляет администратора от необходимости явно указывать права на объект.
С другой стороны, администратор всегда может на любом уровне иерархии отключить
наследование и задавать права доступа явным образом. В общем случае ACL объекта со-
стоит из унаследованных с верхнего уровня списков управления доступом плюс прав, за-
данных непосредственно для данного объекта (явные назначения). Такой механизм фор-
мирования списков позволяет эффективно делегировать полномочия в каталоге AD.
АСЕ может содержать как разрешающее так и запрещающее право доступа, например,
запрет на операцию записи Запрещающее право доступа имеет приоритет, причем не-
важно, назначен запрет непосредственно пользователю или группе, членом которой он
является.
Если при просмотре списка DACL выясняется, что пользователь не имеет доступа к объ-
екту (встретился запрещающий АСЕ, содержащий SID пользователя или одной из его
групп), то дальнейший просмотр списка прекращается.
Таким образом, для повышения эффективности Windows Server 2003 упорядочивает
элементы АСЕ следующим образом:
•	явные запреты;
•	явные разрешения;
•	унаследованные запреты;
•	унаследованные разрешения.
Сумма полномочий пользователя после просмотра списка — личных, групповых, явных,
унаследованных — образует его эффективные права
1.3.	Система аудита
Active Directory
Даже если мы уверены в том. что в нашей сети используется надежный и безопасный
протокол аутентификации, а списки управления доступом корректно настроены, мы, ко-
нечно же, хотим знать, кто и когда пытался проникнуть в нашу систему, кто и когда пы-
тался получить доступ к папке с важной конфиденциальной информацией, удалось это
злоумышленнику или нет. Ответы на эти и другие вопросы нам поможет получить сис-
тема аудита.
170
Гпава 1. Обеспечение безопасности доступа на основе рекомендации и продуктов Microsoft
При настройке аудита администратор должен указать, какие типы событий его инте-
ресуют и на каких машинах. После чего система аудита начинает отслеживать указанные
события и фиксировать их в специальном журнале аудита — Security Log. Для каждого
типа событий администратор может указать, интересуют ли его факты успешного завер-
шения события, неуспешного или и те, и другие. Начиная с Windows 2000, аудит вклю-
чается в объектах групповой (локальной) политики, причем в Windows Server 2003 аудит
определенных действий включен по умолчанию.
Параметров аудита довольно много, и у начинающих администраторов часто возни-
кает вопрос, какие конкретно опции следует включать. Строго говоря, это определяется
целым набором критериев, таких как роль, выполняемая данным компьютером (рабочая
станция, сервер приложений, контроллер домена), условия его эксплуатации (локальная
сеть, демилитаризованная зона, сеть за пределами периметра), требования политики
безопасности предприятия и т. д. Тем не менее в руководствах «Windows Server 2003
Security Guide» и «Windows XP Security Guide» даны некоторые общие рекомендации по
настройке данных систем, а в прилагаемых к ним шаблонах безопасности можно найти
примеры настроек аудита.
В систему управления можно включить все доступные параметры политики аудита.
Некоторые из них используются довольно редко. Например, «Аудит отслеживания про-
цессов» используется в основном для целей отладки и практически не применяется при
администрировании. «Аудит доступа к службе каталогов» имеет смысл включать только
на контроллерах доменов. Обратите внимание, что «Аудит доступа к службе каталогов»
и «Аудит доступа к объектам» недостаточно просто включить в данной консоли.
Поскольку задача этих политик — отслеживать действия, совершаемые с объектами
соответственно AD, NTFS и принтеры, то администратор должен еще указать:
1)	какие конкретно объекты его интересуют (папка, файл, подразделение в AD);
2)	чьи действия в отношении выбранных объектов необходимо протоколировать (на-
пример, пользователя Иванова и пр.);
3)	наконец, какие конкретно действия следует заносить в журнал (чтение файла, уда-
ление папки и пр.).
Технически эти настройки реализованы в виде списка System Access Control List
(SACL), аналогичного по структуре списку прав доступа.
Аудит доступа к объектам может быть настроен довольно тонко. При этом работает ме-
ханизм наследования, и выбранные параметры можно легко распространить на все уровни
иерархии объектов.
После настройки требуемых параметров политики аудита администратору необходимо
периодически просматривать журнал аудита и анализировать собранную информацию.
Просмотр осуществляется стандартным образом с помощью утилиты Event Viewer (про-
смотр событий). Security Log хранит только информацию, собранную системой аудита.
Естественно, что в зависимости от настроек записей в журнале может быть очень много.
Для отображения только необходимой в данный момент информации можно использо-
вать фильтры по различным критериям. Кроме того, следует еще до включения аудита
изменить размер журнала, который по умолчанию всего 512 Кбайт, и указать алгоритм
поведения системы при заполнении журнала. Для критически важных компьютеров ре-
комендуется не переписывать журнал, чтобы не терять записи, которые могут оказаться
весьма важными для анализа потенциальных или возникших проблем. Более того, в объ-
екте групповой или локальной политики существует настройка, согласно которой компью-
тер принудительно выключается, если журнал аудита переполняется и фиксировать со-
бытия становится невозможно
ЧАСТЫ1. ПРАКТИКА
Поскольку Security Log является важной составляющей системы безопасности, со-
держимое журнала хранится в зашифрованном виде. По умолчанию настройка аудита
разрешена только членам группы «Administrators», а рядовой пользователь не имеет даже
права чтения журнала аудита. Пользователь, наделенный соответствующими полномо-
чиями, может выполнять очистку и архивацию журнала аудита. При этом надо иметь в
виду, что удаление отдельных событий журнала невозможно. Система фиксирует факт
очистки журнала с указанием того, кто и когда выполнил очистку.
1.4.	Назначение и решаемые задачи
инфраструктуры открытых ключей
Система строгой двухфакторной аутентификации пользователей основана на приме-
нении методов асимметричной криптографии и использует в качестве атрибутов аутен-
тификации цифровые сертификаты открытых ключей формата Х.509, размещенные на
персональных смарт-картах или USB-ключах пользователей. Централизованное примене-
ние сертификатов открытых ключей требует наличия в составе информационной системы
организации инфраструктуры открытых ключей (Public Key Infrastructure, PKI), обеспе-
чивающей выпуск и дальнейшее сопровождение цифровых сертификатов.
К основным задачам инфраструктуры открытых ключей (PKI) относятся:
•	централизованное формирование, управление и хранение сертификатов открытых
ключей;
•	предоставление доступа прикладным информационным системам к сертификатам
открытых ключей и спискам аннулированных сертификатов (Certificate Revoca-
tion List, CRL);
•	поддержка многофакторной (двухфакторной) аутентификации пользователей в до-
мене службы каталога, при доступе к корпоративным веб-ресурсам, а также под-
держка шифрования и ЭЦП при обмене электронными сообщениями.
Дополнительно к PKI часто предъявляются следующие требования:
•	интеграция с применяемой в организации службой каталога;
•	обеспечение возможности гибкого масштабирования PKI с целью интеграции
с новыми корпоративными прикладными системами и распределения нагрузки;
•	поддержка основных промышленных стандартов PKI, используемых в приложе-
ниях со встроенными средствами работы с PKI:
—	семейство стандартов Х.509;
—	стандарты серии PKCS;
—	криптографические алгоритмы RSA, SHA-l, MD5;
—	российские государственные стандарты в области криптографической защиты ин-
формации - ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94, ГОСТ 28147-89;
—	протокол LDAP v2.
Удостоверяющий центр на Windows Server 2003 и 2008 может поддерживать следую-
щие конфигурации:
•	отдельный удостоверяющий центр либо полная интеграция с Active Directory;
•	корневой или подчиненный удостоверяющий центр.
Обычно таких возможностей оказывается достаточно для решения большинства за-
дач в организации.
172
Глава 1. Обеспечение безопасности доступа на основе рекомендаций и продуктов Microsoft
1.5.	Управление идентификацией (ILM)
Централизованная система управления идентификацией, представленная службами
каталогов, не означает, что вся информация будет содержаться в центральном месте, она
будет только управляться централизованно. В типичном решении различные данные иден-
тификации управляются различными группами организации. Например, группе трудовых
ресурсов требуется добавить новых работников, менеджерам нужно иметь возможность
устанавливать отношения с деловыми партнерами, а администраторам необходимо
иметь возможность управлять доступом к ресурсам.
Типичные проблемы:
•	необходимость работать с различными хранилищами информации о пользователях;
•	в сети имеется несколько систем с разными средствами аутентификации;
•	растет число пользователей, использующих цифровые сертификаты;
•	растет число выпущенных сертификатов.
В таких ситуациях одним из важнейших элементов управления является управление
сертификатами (Certificate Lifecycle Management — CLM) и управление идентификаци-
онной информацией в гетерогенной среде (Identity Lifecycle Management — ILM).
Появляется задача обеспечения управления цифровыми удостоверениями и обеспече-
ния единой аутентификации для поддержки принципа Single Sign-on и надежной зашиты
данных.
Решение для интеграции различных источников данных идентификации, имеющихся
в организации, — использовать продукт синхронизации каталогов, например, продукт
мета каталогов.
Метакаталоги помогают создать единое представление для отдельных данных иденти-
фикации, хранящихся в разных хранилищах. Они берут информацию о пользователе из
различных утвержденных источников, таких как приложения трудовых ресурсов и учета,
каталоги электронной почты и регистрационные базы данных веб-серверов, и заполняют
каталог, чтобы создать такое представление. Самое главное заключается в том, что мета-
каталоги синхронизируют значения данных, предоставляемые каждым из утвержденных
источников организации.
Для решения этих задач компания Microsoft выпустила продукт Identity Lifecycle
Manager 2007, состоящий из двух компонентов (фактически, независимых продуктов):
•	Certificate Lifecycle Manager (CLM);
•	Microsoft Identity Integration Server (MIIS).
CLM позволяет организовать управление большим количеством цифровых удосто-
верений и носителей различных форматов и упростить поддержку пользователей с по-
мощью портала самообслуживания.
Microsoft Identity Integration Server (MIIS) обеспечивает возможность интегрировать
данные идентификации по многим репозитариям, системам и платформам.
1.6.	Microsoft Identity Integration Server (MIIS)
MIIS поставляется с набором «коннекторов» (рис. 1.6), позволяющих клиенту интег-
•ировать информацию по идентификации из множества различных источников, являю-
шхся каталогами сетевой операционной системы, электронной почты или приложе-
ии, ба данных или форматированных текстовых файлов. MIIS также поддерживает
роизводные форматы данных Интернета, такие как XML и DSML.
ЧАСТЫ1. ПРАКТИКА
Employees
Arriving
Employees
Changing
Employees
Leaving
Administrators
Customers
I
Рис. 1.6. M11S с набором «коннекторов*
MIIS добавляет Active Directory, обеспечивая клиента широкими возможностями
взаимодействия.
Классический «метакаталог»
о Синхронизация атрибутов между множеством систем:
•	множество каталогов LDAP: AD ADAM. iPlanet, Novell:
•	множество почтовых систем: Exchange (5.5, 2000, 2003), Notes;
•	кадровые системы: SAP, PeopleSoft, Oracle HR;
•	наследуемые системы (мэйнфреймы, Unix, и т.д.): обмен файлами. XML
Управление паролями
о Задание начального пароля, задание/изменение множества паролей одновре-
менно.
о Автоматическое распространение
•	Автоматическое создание или запрет/удаление учётных записей/почтовых ящиков.
Multi-forest Active Directory
о Сайты, подсети, принтеры, синхронизация реального времени.
174
Глава 1. Обеспечение безопасности доступа на основе рекомендации и продуктов Microsoft
Сценарии электронной почты
о Создание глобального списка рассылки (Global Address List):
•	Объединение множества лесов Exchange, множества почтовых систем;
о Автоматизированное управление группами.
1.7.	Системы обеспечения
Ключевая часть решении по управлению доступом и учетными записями — способ
создания, изменения и удаления идентификационных данных. Этот жизненный цикл
управления идентификацией обычно описывается как обеспечение. Оно использует инфор-
мацию пользователя, содержащуюся в инфраструктуре каталогов организации, чтобы
ускорить выдачу и аннулирование пользовательских учетных записей и прав доступа к ин-
формационным ресурсам: электронную почту, телефонную службу, приложения, трудовые
ресурсы, бизнес-линейку, функциональные приложения, допуск в интрасеть и внеш-
нюю сеть, а также сервисы службы поддержки.
Автоматизация данных процессов может снизить затраты и серьезно увеличить произ-
водительность. Например, подсчитано, что простое действие по автоматизации сбрасыва-
ния паролей составляет 48 % обращений в службу поддержки для организаций с 10 000 поль-
зователей и более. Кроме того, автоматизация процессов может сократить время, требуе-
мое для получения пользовательских учетных записей и прав доступа, более чем с недели
до нескольких часов. Это также сильно снижает время, затрачиваемое управляющими
делами на заполнение сопутствующей документации, так же как и время, затрачиваемое
персоналом отдела финансов, отдела трудовых ресурсов и отдела ИТ на подтверждение
и выполнение запросов на доступ.
Удаление и повторное обеспечение — другие ключевые функции систем обеспечения.
Если работник покидает или меняет свою должность, система обеспечения может быстро
изменить или аннулировать учетные записи и пользовательские права доступа.
Как говорилось выше, корпорация Microsoft обеспечивает данный уровень функцио-
нальных возможностей как часть МI IS. В перспективе системы обеспечения MI1S по-
зволяют:
•	«встроенным» работникам — автоматическое создание учетных записей в связанных
системах, основанных на «триггерах» или событиях, таких, как приглашение на ра-
боту и добавление к системе трудовых ресурсов или другой официальной системе;
•	«невстроенным» работникам — автоматическое удаление или приостановка учет-
ных записей в связанных системах, когда работник удаляется из системы трудо-
вых ресурсов или другой официальной системы;
•	атрибутам идентификации «Брокер» — автоматическое создание или синхрониза-
ция данных идентификации между двумя или множеством систем.
Автоматизация деловых процедур — другая важная возможность системы обеспечения,
которая используется больше всего во время встраивания работника. При встраивании
нового работника компания может использовать MIIS для предоставления:
•	простого обеспечения — работник впускается в различные связанные системы,
которые для него открыты;
•	одношагового обеспечения автоматизации деловых процедур — за один шаг менед-
жер или другое уполномоченное лицо уведомляется по электронной почте о том.
что новый работник приглашен на работу и готов к обеспечению. Менеджер или
ЧАСТЬ II. ПРАКТИКА
уполномоченное лицо выдает свое решение (да/нет), и учетные записи работника
автоматически создаются или не создаются в зависимости от решения;
•	многошагового обеспечения автоматизации деловых процедур — сходного с обеспе-
чением автоматизации деловых процедур, исключая количество более одного ра-
ботника в процессе обеспечения, который должен авторизовать новое приглаше-
ние на работу. Многошаговая автоматизация деловых процедур возможна при ис-
пользовании BizTalk Server вместе с MIIS4;
•	комплексное обеспечение — более редкий сценарий, в котором телефон, кредит-
ная карта, пейджер или другие элементы внесистемной учетной записи работника
обеспечиваются как часть процесса встраивания. Вместе со специализированными
продуктами третьих фирм (т. е. Business Layers) MIIS может выполнять необхо-
димые сложные задачи обеспечения.
MIIS предоставляет широкий набор возможностей обеспечения «из коробки» для
удовлетворения нужд компании. Компании, для которых требуются возможности, пре-
восходящие предоставляемые Ml IS сегодня, могут выиграть от использования BizTalk Server
или продуктов от различных партнеров корпорации Microsoft.
Для MIIS 2003 имеются следующие агенты управления (коннекторы):
•	AD/Exchange 2000/Exchange 2003;
•	Active Directory Application Mode (ADAM);
•	Active Directory global address list (GAL);
•	SunOne Directory Server 5.1 (iPlanet);
•	SQL;
•	Oracle8i Database / Oracle9i Database;
•	NT4;
•	Exchange 5.5;
•	Microsoft Exchange Server 5.5 (bridgehead server);
•	Lotus Notes 4.6 и 5.0;
•	Novell eDirectory 8.62/8.7;
•	Netscape Directory Server 6.1;
•	Informix, DB2, dBase, Access, Excel, OLE DB через SQL DTS:
•	LDAP Directory Interchange Format (LDIF);
•	текстовый файл с разделителями;
•	текстовый файл с полями фиксированной ширины;
•	Directory Services Markup Language (DSML) 2.0;
•	текстовый файл, состоящий из пар «атрибут + значение».
В заключение отметим, что список коннекторов постоянно расширяется
Глава 2
ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ
ДОСТУПА К ДАННЫМ И ПРИЛОЖЕНИЯМ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ОРГАНИЗАЦИИ
НА ОСНОВЕ РЕКОМЕНДАЦИЙ И ПРОДУКТОВ
ORACLE И ALADDIN. ТИПОВЫЕ РЕШЕНИЯ
2.1.	Управление доступом в СУБД Oracle
с помощью встроенных механизмов безопасности
и криптографических средств защиты
2.1.1.	Методы аутентификации в СУБД Oracle
Аутентификация в СУБД Oracle означает проверку подлинности субъекта (пользователя,
приложения, устройства), которому требуется доступ данным, ресурсам или приложениям.
СУБД Oracle предоставляет множество способов аутентификации и позволяет использо-
вать один или несколько методов одновременно. В СУБД Oracle возможна аутентификация:
•	средствами операционной системы;
•	с помощью сетевых сервисов;
•	средствами базы данных (БД);
•	в многозвенных приложениях.
Аутентификация средствами операционной системы
Некоторые операционные системы позволяют СУБД Oracle использовать ту информа-
цию о пользователях, которой они управляют. Это создает следующие преимущества:
•	аутентификация может проходить без указания имени пользователя и пароля (на-
пример. пользователь, прошедший аутентификацию в ОС, может загрузить при-
ложение SQL*Plus, выполнив команду: SQLPLUS /);
•	при записи событий аудита средствами ОС и СУБД можно использовать одно и то же
имя пользователя;
•	сервер БД не должен хранить пароли и управлять ими (хотя необходимость хра-
нения имен пользователей сохраняется).
Однако при этом возникают проблемы в распределенных системах, использующих
различные ОС.
Аутентификация с помощью сетевых сервисов
Среди встроенных в СУБД Oracle средств защиты можно выделить опцию Oracle Advan-
ced Security (OAS) — комплекс средств зашиты данных, аутентификации и обеспечения се-
тевой безопасности, включающий поддержку защищенных протоколов передачи данных
Опция Oracle Advanced Security обеспечивает конфиденциальность информации, переда-
ваемой по сети, исключая «прослушивание» и разнообразные виды атак OAS позволяет
защищать все входящие и исходящие соединения СУБД Oracle. Для каждого соединения
создается секретный ключ, обеспечивающий безопасность сетевого трафика. OAS делает не-
возможным скрытую модификацию, добавление или удаление части передаваемых данных.
ЧАСТЫ1. ПРАКТИКА
В Oracle Advanced Security предусмотрена аутентификация службами третьих сторон:
•	Kerberos;
•	Entrust/PKI;
•	Remote Authentication Dial-In User Service (RADIUS);
•	службой LDAP-каталога
OAS позволяет организации использовать существующую инфраструктуру безопас-
ности, например Kerberos, PKI, RADIUS для сильной аутентификации в СУБД Oracle 10g.
Аутентификация службами третьих сторон
Kerberos
Kerberos — система аутентификации доверенной третьей стороной, основанная на ис-
пользовании сервером аутентификации и субъектом так называемого общего секретного
ключа. Она гарантирует безопасность коммуникаций и надежность доверенной стороны.
Kerberos обеспечивает однократную регистрацию, централизованное хранение паролей,
прозрачную аутентификацию через связи БД, а также средства усиленной безопасности
на рабочих станциях.
PKI
Аутентификация на основе цифровых сертификатов опирается на инфраструктуру
открытых ключей (РК1) — современную технологию использующую для идентифика-
ции субъектов в распределенной среде криптографию с открытыми ключами. При этом
не требуется специального сервера аутентификации. Аутентификация пользователей
(приложений) выполняется на серверах БД в рамках предприятия. СУБД Oracle распо-
лагает следующими возможностями и компонентами для аутентификации с помощью
цифровых сертификатов:
•	аутентификация и безопасная передача сеансовых ключей по SSL-протоколу;
•	набор функций OCI (Oracle Call Interface — прикладного интерфейса доступа к БД)
и PL/SQL, Java-библиотеки;
•	доверенные сертификаты (trusted certificates) для проверки подлинности сертифи-
катов, предъявляемых пользователями (приложениями);
•	контейнеры Oracle wallets, содержащие секретные ключи пользователей, их сер-
тификаты и цепочки доверенных сертификатов;
•	Oracle Wallet Manager (OWM) — компонент СУБД для управления контейнерами.
RADIUS
Служба удаленной аутентификации пользователей по коммутируемой линии (Remote
Access Dial-In User Service, RADIUS) фактически является стандартом (RFC 2138) для
централизованной аутентификации и авторизации пользователей в крупных вычисли-
тельных сетях. СУБД Oracle поддерживает протокол RADIUS, при этом становятся до-
ступны службы и устройства аутентификации третьих производителен, с которыми мо-
жет взаимодействовать сервер RADIUS (например, устройства генерации одноразовых
паролей, биометрические устройства и т. п.)
Аутентификация службой LDAP-каталога
Эффективное управление аутентификацией и учетными записями пользователей
(приложении) может быть обеспечено с помощью службы LDAP-каталога В инфраструк-
туре СУБД Oracle служба каталога представлена следующими компонентами:
Глава 2. Обеспечение безопасности доступа на основе рекомендаций и продуктов Oracle и Aladdin
•	Oracle Internet Directory (OID) — специализированное хранилище информации на
основе базы данных Oracle и тесно интегрированное с сетевыми службами и управ-
ляющими средствами Oracle. Oracle Internet Directory позволяет централизованно
хранить информацию о пользователях (создавать одну учетную запись пользователя
для многих баз данных). 01D обеспечивает интеграцию со службами каталогов других
производителей, например, MS Active Directory или iPlanet, позволяет гибко управ-
лять атрибутами безопасности и привилегиями каждого пользователя, включая тех,
кто для аутентификации применяет цифровые сертификаты Для повышения без-
опасности соединении во время аутентификации может использоваться протокол SSL.
•	Oracle Enterprise Security Manager — утилита управления приложениями, пользо-
вателями, группами, ролями и привилегиями.
Аутентификация средствами базы данных
СУБД Oracle может аутентифицировать пользователя (приложение), используя ин-
формацию, хранимую в базе данных. Если субъектом аутентификации является пользо-
ватель, то для проверки его подлинности может запрашиваться некоторая дополнитель-
Особенности способов аутентификации в СУБД Oracle 9i/10g
Таблица 2. i
Способ	Хранение ключей	Преимущества	Недостатки
Имя/пароль	БД	•	Распостраненность •	Возможность выбора любой платформы клиента/сервера •	Простота использования •	Возможность задать правила фор- мирования пароля (качество пароля)	•	Пароль либо легко подбира- ется, либо сложно запомина- ется •	Пароль доступен для комп- роментации
Kerberos	Файл	•	Шифрование ключевой инфор- мации •	Возможность временнОго огра- ничения действия ключа •	Поддержка однократной регист- рации Single Sign-On •	Поддержка смарт-карт технологии	•	Требуется дополнительная настройка сервера на прото- кол Kerberos •	Небезопасное хранение ключей •	Управление ключевой инфор- мацией не средствами Oracle
RADIUS	Файл/ Внешняя БД	•	Сильная аутентификация •	Возможность сочетать двухфак- торную аутентификацию с други- ми методами •	Возможность интеграции с лю- быми технологиями, поддержи- вающими данный протокол (То- kenCard, SecurlD, биометрические устройства) •	Возможность выбора любой платформы клиента/сервера	•	Возможность компромета- ции ключевой информации •	Недостаточная надежность UDP-протокола •	Требуется установка RADIUS-сервера •	Возможно, потребуется до- полнительное кодирование для клиента •	Не рекомендуется использо- вать карты SecurlD с версии 9i Oracle
SSL/PK1	Фаил/Реестр/ Смарт-карта	•	Двухфакторная аутентификация • Возможность централизованного управления пользователями и приложениями, а также ключевой информацией •	Возможность выбора любой платформы клиента/сервера •	Поддержка однократной регист- рации Single Sign-On	•	Возможность компромента- ции ключей при хранении в файле/реестре •	Подтверждено со стороны Oracle только использование смарт-карт NCipher •	При использовании смарт- карт других производите тс и требуется дополнительное ПО
ЧАСТЫ1. ПРАКТИКА
ная информация, например, пароль. Пользователь может изменить собственный пароль
в любое время. Информация о пользователе и пароле хранится в словаре БД, причем па-
роль криптографически защищен от несанкционированной модификации.
Программное обеспечение СУБД Oracle шифрует пароли пользователей в целях безопас-
ной передачи по сети. После прохождения процедур аутентификации и авторизации
субъекты могут выполнять свои роли и полномочия. Аутентификация администраторов
СУБД Oracle требует специальной процедуры, что обусловлено спецификой выполняе-
мых ими задач.
Аутентификация средствами БД (табл. 2.1) обеспечивает следующие возможности:
•	шифрование пароля во время соединения (с помощью симметричного алгоритма
шифрования Advanced Encryption Standard (AES), также известного, как Rijndael);
•	блокирование учетной записи (возможна остановка числа неправильных попыток
ввода пароля, а также варианта разблокировки, например, вручную администра-
тором БД. автоматически через некоторое время и т. п.);
•	управление жизненным циклом пароля;
•	хранение истории паролей (это позволяет, например отслеживать повторяющие-
ся варианты паролей);
•	управление качеством паролей (проверка пароля на соответствие некоторым тре-
бованиям по качеству — длине, используемым символам, несовпадению со слова-
рем и т. п.).
Аутентификация в многозвенных приложениях Enterprise User Security
Стандартный механизм аутентификации и авторизации в СУБД Oracle предполагает,
что каждому пользователю соответствует учетная запись. Таким образом, если пользо-
ватель работает с несколькими базами данных, то в каждой хранится его учетная запись.
В результате при большом количестве серверов баз данных происходит многократное
дублирование учетной информации, что естественно усложняет процесс администриро-
вания и увеличивает риски безопасной эксплуатации приложений.
Подобных проблем позволяет избежать подход, предлагаемый Oracle в решении
Enterprise User Security: учетные записи пользователей создаются в едином LDAP-ката-
логе — Oracle Internet Directory, а ведение ролей пользователей, которым предоставляются
необходимые привилегии, происходит в различных базах данных При этом аутентифи-
кация и авторизация пользователей СУБД Oracle выполняются на основе информации
LDAP-каталога и правил соответствия (mapping) ролей в OID и ролей в базах данных
Важной особенностью данного решения является то, что существующие приложения не
нуждаются в модификации, а их защищенность возрастает: появляется возможность
аутентифицировать пользователей в LDAP-каталоге на основе паролей, а также цифро-
вых сертификатов Х.509.
Аутентификация пользователей в Enterprise User Security выполняется по-разному для
приложений, работающих в архитектуре клиент—сервер (двухзвеннои), и для приложе-
ний, работающих в Web-архитектуре (трехзвеннои).
В двухзвенной архитектуре пользователь непосредственно подключается к базе данных,
используя свои идентификационные данные (имя/пароль или цифровой сертификат).
Сервер базы данных передает данные пользователя в Oracle Internet Directory, который
их проверяет и в случае успешной проверки организует соединение пользователя с так
называемой разделяемой схемой, к которой ему разрешен доступ. Корпоративные поль-
зователи не являются пользователями базы данных и поэтому могут не иметь собственных
схем в базе. Пользователи соединяются с базой данных и работают с требуемыми объек-
Гпава 2. Обеспечение безопасности доступа на основе рекомендаций и продуктов Oracle и Aladdin
тами в разделяемой схеме в соответствии с привилегиями, предоставленными им сервером
Oracle Internet Directory. Для получения привилегий пользователям назначается одна
или несколько корпоративных ролей, созданных в LDAP-каталоге.
Существует прямое соответствие между корпоративными ролями и ролями в базе дан-
ных. После успешной аутентификации сервер базы данных запрашивает у Oracle Internet
Directory набор всех корпоративных ролей пользователя, создает сессию и предоставляет
этой сессии роли (привилегии), закрепленные за корпоративными ролями в базе данных.
В результате пользователь, зарегистрированный в LDAP-каталоге, получает возможность
работать с базой данных с правами, описание которых хранится в OID. В этом случае
в СУБД Oracle отсутствует необходимость создавать учетные записи пользователей и
управлять ими.
В многозвенной архитектуре аутентификация пользователей происходит на сервере
приложений. Между сервером приложении и сервером базы данных устанавливаются до-
верительные отношения, и все пользователи, зарегистрированные в 01D, открывают сес-
сии от имени одного или нескольких так называемых прокси-пользователей БД. В этом
случае пользователи LDAP-каталога не могут напрямую соединяться с сервером базы
данных. Доверительные отношения между сервером приложении и сервером базы данных
означают, что всем пользователям, которые успешно прошли аутентификацию на сер-
вере приложений, используя имя/пароль или цифровые сертификаты, разрешен доступ
к объектам базы данных. Совместное использование механизмов аутентификации (одно-
кратной регистрации SSO), LDAP-каталога и Enterprise User Security обеспечивает воз-
можность создания информационных систем, удовлетворяющих самым высоким требо-
ваниям безопасности.
2.1.1.1.	Управление доступом к базе данных Oracle
с помощью механизма Enterprise User Security
Постановка задачи
На предприятии существует несколько прикладных программных систем (в архитек-
туре «клиент—сервер» и в Web-архитектуре), работающих с базами данных Oracle. С целью
снижения затрат на управление учетными записями пользователей и повышения уровня
информационной безопасности принимается решение о переносе учетных записей поль-
зователей, зарегистрированных в различных экземплярах Oracle, в единое хранилище
учетных записей и введении процедур единой регистрации и авторизации пользователей
при доступе к прикладным программным системам
Описание решения
Основой архитектуры решения служит механизм Enterprise User Security Как гово-
рилось выше (см. разд. 2.1.1), аутентификация пользователей выполняется по-разному
для приложений, работающих в архитектуре «клиент—сервер» (двухзвенной), и для при-
ложении, работающих в Web-архитектуре (трехзвеннои). Если приложения, работающие
в трехзвеннои архитектуре, уже использовали сервер приложений Oracle iAS 10g, то что-
бы перенести учетные записи всех пользователей, зарегистрированных в разных экземп-
лярах СУБД Oracle, в единое хранилище, не требуется устанавливать дополнительные
компоненты, достаточно зарегистрировать серверы баз данных Oracle в Oracle Internet
Directory и перевести данные пользователей БД в OID. В этом случае код приложений
не меняется, все действия сводятся к изменению конфигурации серверов приложении
и баз данных.
ЧАСТЫI. ПРАКТИКА
Рис. 2.1. Управление доступом с помощью механизма Enterprise User Security
Если на предприятии используются дополнительные LDAP-каталоги, например, MS
Windows Active Directory (MS AD), и требуется предоставить доступ пользователей до-
менов Windows к корпоративным приложениям, достаточно организовать синхронизацию
между каталогами (OID и MS AD) (рис. 2.1). Синхронизация осуществляется средствами
Directory Integration Platform (DIP), поставляемыми Oracle в составе сервера приложении
Oracle iAS 10g. DIP позволяет синхронизировать Oracle Internet Directory с другими
LDAP-каталогами (MS AD, SUN Java System Directory Server, OpenLDAP, Novell
eDirectory), репозиториями (Oracle Human Resource) и таблицами базы данных Oracle через
стандартный интерфейс.
DIP обеспечивает создание и управление учетными записями пользователей и их при-
вилегиями для внешних приложений, имеет механизмы внешней аутентификации, позво-
ляющие передавать функции проверки пользователей во внешние сервисы, например,
в каталог MS AD. После проведения синхронизации пользователи, зарегистрированные
в домене Windows, получают возможность автоматически без дополнительной регист-
рации подключаться к СУБД Oracle и работать с приложениями с помощью механизмов
аутентификации Kerberos и Oracle Enterprise User Security.
Механизм Enterpise User Security позволяет обеспечить единую точку входа для аутенти-
фикации пользователей, а также единую регистрацию и авторизацию пользователей для
доступа к информационным ресурсам. При этом хранение информации о пользователях
в централизованном и внешнем по отношению к базам данных LDAP-каталоге Oracle
Internet Directory позволяет снизить затраты на администрирование учетных записей поль-
зователей.
Поскольку Enterprise User Security является расширением популярных серверных про-
дуктов Oracle, его применение открывает новые возможности, не требуя дополнитель-
ных затрат на развертывание системы и обучение администраторов. Механизм Enterprise
User Security позволяет не только повысить безопасность данных и удобство управления
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
учетными записями пользователей, но и обеспечивает более гибкое управление систе-
мок безопасности предприятия в условиях изменения организационной структуры или
политики безопасности, а также при появлении новых информационных систем
2.1.1.2.	Двухфакторная аутентификация в СУБД Oracle
на основе встроенных средств безопасности Oracle Advanced Security
Постановка задача
На предприятии для доступа к прикладным программным системам, реализованным
на ба ie СУБД Oracle, и данным, которые обрабатываются и хранятся на серверах Oracle,
используется самый простой метод — аутентификация по имени пользователя и паролю.
Однако удобство и безопасность этого метода не устраивают руководство предприятия.
Требуется обеспечить сильную аутентификацию в корпоративной сети (под управлени-
ем Microsoft Windows Server 2000/2003) и защиту доступа к конфиденциальным данным
с помощью механизмов безопасности (инфраструктуры открытых ключей и организации
доступа пользователей к информации), реализованных в самой СУБД Oracle.
Описание решения
Метод аутентификации пользователей по имени и паролю заменяется на более на-
дежный. Решение базируется на применении цифровых сертификатов формата Х.509 и
протокола Secure Sockets Layer (SSL), поддерживающего строгую двухфакторную аутен-
тификацию пользователей СУБД Oracle, а также позволяющего передавать информацию
по сети между сервером БД и клиентским компьютером (рис. 2.2) в зашифрованном ви-
де. При этом используются лишь штатные настройки СУБД и клиента Oracle, предус-
мотренные опцией Oracle Advanced Security.
СУБД Oracle поддерживает аутентификацию по сертификату Х.509. Сертификаты
пользователей и секретные ключи могут храниться либо в файлах стандартного формата
PKCS#12. размещенных на отчуждаемых носителях, либо в реестре Windows на рабочих
станциях, при этом они защищаются паролем. Однако парольная защита порождает про-
блемы безопасности — ключевые контейнеры могут быть скопированы и впоследствии
t
t
Сертификаты
пользователей
На основании данных в сертификате
клиентское приложение получает
доступ к определенной
БД с определенными правами
Сервер БД	Oracle Internet
Directory
Клиент Oracle
Рис. 2.2. Архитектура предоставления доступа
ЧАСТЫ1. ПРАКТИКА
«взломаны» методом простого перебора паролей. Определенные неудобства вызывает и
привязка ключевого контейнера к конкретной рабочей станции. Хранение идентифика-
ционных данных и ключей шифрования пользователей на персональных съемных носи-
телях eToken компании Aladdin решает обе проблемы. Во-первых, сертификаты хранятся
непосредственно в смарт-карте или USB-ключе eToken, секретный ключ находится в за-
щищенной памяти и никогда ее не покидает; во-вторых, сертификаты «мобильны» — ра-
ботать с приложениями Oracle можно с любой рабочей станции и от имени любого поль-
зователя корпоративной сети. Все, что требуется для настройки на стороне клиента. —
это указать, что ключевой контейнер помещен в хранилище сертификатов (Certificate
Store) Microsoft.
В момент запроса на соединение с БД служба eToken SecurLogOn позволяет сетевым
драйверам Oracle «видеть» сертификаты, установленные на eToken. Аутентификация
проходит в два этапа:
1)	запрос на выбор сертификата (в зависимости от выбранного сертификата пользо-
ватель будет работать с определенной БД, схемой и правами) Если сертификат единст-
венный, он выбирается автоматически;
2)	запрос PIN-кода смарт-карты или USB-ключа eToken для авторизации на опера-
ции с секретным ключом.
Когда клиенту требуется предъявить свой сертификат, служба смарт-карты «подска-
зывает» ему, какой сертификат следует брать из смарт-карты. Для подтверждения подлин-
ности сервера клиенту необходим секретный ключ для расшифрования ответа сервера.
Секретный ключ находится в защищенной памяти смарт-карты, и все операции с ним
выполняет встроенный в карту криптопроцессор. Для таких операций требуется допол-
нительная авторизация, т. е. запрашивается PIN-код. Когда между клиентом и сервером
установлены доверительные отношения, сервер проверяет наличие отличительного имени
пользователя, для которого издан сертификат клиента, в LDAP-каталоге — Oracle Internet
Directory. Если он найден, дополнительно определяются экземпляр БД. схема и набор прав
для клиента. После этого сервером создает-
Oracle	Oracle
прикладное ни
Рис. 2.3. Двухуровневая модель доступа
к защищенным данным с помощью
цифровых сертификатов X 509
ся сессия пользователя с указанными пара-
метрами. Сетевой обмен между клиентом и
сервером происходит по соединению, защи-
щенному определенным криптоалгоритмом.
Такой подход позволяет на практике
реализовать двухуровневую модель орга-
низации защищенного доступа пользова-
теля к данным (СУБД) с помощью цифро-
вых сертификатов Х.509, установленных
в eToken. Легальные пользователи корпора-
тивной сети (под управлением контролле-
ра домена Windows 2000/2003) могут авто-
ризоваться в сети (рис. 2.3) только после
успешной аутентификации по смарт-карте,
включающей предъявление соответствую-
щего сертификата (первый уровень). На
втором уровне зашиты доступ авторизо-
ванных пользователей корпоративной сети
к защищенным данным СУБД возможен
только при предъявлении соответствующе-
го сертификата Oracle.
Гпава 2. Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Результатом настройки сервера БД, клиентских рабочих станций и установки серти-
фикатов пользователей на смарт-карты является надежная аутентификация, шифрован-
ный трафик между рабочими станциями и сервером, и самое главное — строгая персо-
нализация доступа в БД. Помимо повышения надежности, аутентификация с исполь-
зованием eToken дает ряд преимуществ по сравнению с традиционным (логин/пароль)
методом. Прежде всего, электронный ключ дает возможность пользователю различных
приложении не хранить «где попало» и не запоминать необходимые имена и пароли. Зная
один PIN-код и выбрав сертификат из предложенного списка, можно, имея соответст-
вующие права и привилегии, обращаться к конкретной БД, причем с любой рабочей
станции.
Администратор безопасности получает при этом дополнительные удобства в виде цент-
рализованного управления доступом и контроля работы системных администраторов.
Все эти возможности управления обеспечивает единый инструмент — служба каталогов
Oracle Internet Directory. Существующие получают в «лице» службы каталогов единую
точку входа — своего рода портал архитектуры клиент—сервер. При этом в большинстве
случаев изменений в прикладном ПО не требуется.
2.1.1.3.	Варианты усиления безопасности доступа в СУБД Oracle
с помощью сертифицированных криптографических средств защиты
Для решения задачи, описанной в предыдущем разделе, предлагаются два варианта уси-
ления безопасности на основе сертифицированных криптографических средств защиты
Базовая аутентификация/авторизация и защита канала связи
Архитектура типового решения и аутентификация представлены на рис. 2.4. В дан-
ном варианте используются следующие компоненты:
•	прикладное ПО, которое реализует интерфейс пользователя для решения биз-
нес-задач прикладной системы;
•	ПО Oracle Client, которое обеспечивает взаимодействие между клиентом и сер-
вером по сети;
Канал связи,
защищенный СКЗИ
(TLS/SSL)
Рис. 2.4. Базовая аутентификация/авторизация и защита канала связи. Общая схема решения
ЧАСТЫ1 ПРАКТИКА
•	сертифицированное средство защиты информации (СКЗИ), которое устанавли-
вает защищенное соединение между клиентом и сервером по протоколу SSL/TLS,
использует сертификаты/ключи для аутентификации на серверном компоненте;
•	eToken RTE — драйверы смарт-карт и USB-ключеи eToken и дополнительное ПО
компании Aladdin для работы с ними
Личное хранилище сертификатов и секретных ключей пользователя на рис. 2.4 обо-
значено буквой А, в качестве физического носителя используется USB-ключ или смарт-кар-
та eToken. Хранилище сертификатов и секретных ключей, используемое ПО СКЗИ на
стороне сервера, обозначено буквой Б. Как правило, оно представляет собой файл фор-
мата PKCS#12.
Аутентификация выполняется за несколько шагов:
1.	Прикладное ПО посылает запрос серверу БД на соединение
2.	Oracle Client делает попытку соединиться с сервером БД по обычному протоколу.
3.	СКЗИ перехватывает запрос от Oracle Client и перенаправляет его в защищенный
канал. Если защищенный канал еще не установлен, ПО СКЗИ выполняет аутентифи-
кацию на серверном компоненте с помощью ключа, который хранится на USB-ключе или
смарт-карте eToken. В случае успешной аутентификации создается защищенный канал
передачи данных.
4.	В процессе аутентификации eToken RTE осуществляет дополнительную авториза-
цию (запрос PIN-кода) для выполнения операций с секретным ключом
5.	Oracle Client авторизует пользователя по имени и паролю.
Дальнейшее взаимодействие между клиентом и сервером осуществляется по 1ащи-
щенному каналу прозрачно для прикладного приложения.
В качестве ПО для выпуска сертификатов могут использоваться программные про-
дукты, которые автоматизируют функции удостоверяющих центров (УЦ). Эти программные
продукты должны быть сертифицированы ФСТЭК ФСБ РФ (например, программный
комплекс «Удостоверяющий Центр «КриптоПро УЦ»).
Базовая аутентификация/авторизация по протоколу Kerberos
и защита канала связи
Второй вариант усиления безопасности на основе сертифицированных криптографи-
ческих средств зашиты отличается от первого только тем, что аутентификация выполня-
ется по протоколу Kerberos. Это дает возможность отказаться от ввода имени пользователя
и пароля в процессе авторизации в БД.
Архитектура типового решения и процесс аутентификации представлены на рис. 2.5.
В данном варианте используются следующие компоненты:
•	прикладное ПО, которое реализует интерфейс пользователя для решения биз-
нес-задач прикладной системы;
•	ПО Oracle Client, которое обеспечивает взаимодействие между клиентом и сер-
вером по сети. В данной схеме используется функциональность опции Advanced
Security Options; это расширение СУБД Oracle устанавливается на стороне сервера
баз данных:
•	сертифицированное СКЗИ, которое устанавливает защищенное соединение между
клиентом и сервером по протоколу SSL/TLS. использует сертификаты/ключи для
аутентификации на серверном компоненте;
•	eToken RTE — драйверы смарт-карт и USB-ключей eToken и дополнительное ПО
компании Aladdin для работы с ними.
Личное хранилище сертификатов и секретных ключей пользователя на рис. 2.5 обозна-
чено буквой А, в качестве физического носителя используется USB-ключ или смарт-кар-
186
Глава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Рабочая станция клиента
Kerberos DC
Рис. 2.5, Аутентификация/авторизация по протоколу Kerberos и защита канала связи.
Общая схема решения
та eToken. Хранилище сертификатов и секретных ключей, используемое ПО СКЗИ на
стороне сервера, обозначено буквой Б. Как правило, оно представляет собой файл фор-
мата PKCS#12,
В процессе аутентификации пользователя в ОС (домене) по сертификату пользова-
теля, установленному на USB-ключе или смарт-карте eToken, сервер аутентификации
возвращает на рабочую станцию клиента так называемый билет (ticket). В дальнейшем
он используется для аутентификации и авторизации в БД. Аутентификация выполняется
за несколько шагов:
1.	Прикладное ПО посылает запрос серверу БД на соединение.
2.	Oracle Client делает попытку соединиться с сервером БД по обычному протоколу.
3.	СКЗИ перехватывает запрос от Oracle Client и перенаправляет его в защищенный ка-
нал. Если защищенный канал еще не установлен, ПО СКЗИ выполняет аутентификацию
на серверном компоненте на основе информации о сертификате и ключах пользователя,
которая хранится на токене eToken В случае успешной аутентификации создается защи-
щенный канал передачи данных.
4.	В процессе аутентификации eToken RTE осуществляет дополнительную авторизацию
(запрос PIN-кода) для выполнения операций с секретным ключом.
5.	Oracle Client авторизует пользователя по билету Kerberos, полученному ранее. Даль-
нейшее взаимодействие между клиентом и сервером ведется по защищенному каналу
прозрачно для приложения.
ЧАСТЫ1. ПРАКТИКА
В качестве ПО для выпуска сертификатов могут использоваться программные про-
дукты. которые автоматизируют функции удостоверяющих центров (УЦ) Эти програм-
мные продукты должны быть сертифицированы ФСТЭК, ФСБ России (например, про-
граммный комплекс «Удостоверяющий Центр «КриптоПро УЦ»).
2.1.2.	Обеспечение безопасности доступа к данным
и приложениям информационной системы организации
на основе Oracle Application Server
2.1.2.1.	Усиленная аутентификация пользователей в неоднородной среде
приложений на основе Oracle Application Server — Oracle iAS 10g
Постановка задачи
Компании необходимо обеспечить надежную аутентификацию пользователей в слож-
ной среде распределенной обработки данных в условиях работы большого количества
приложений управления предприятием. Для аутентификации пользователей при доступе
к ресурсам Oracle E-Business Suite должны использоваться цифровые сертификаты фор-
мата Х.509.
Описание решения
Для решения поставленной задачи выбрана комплексная инфраструктура управле-
ния учетными записями пользователей, которую сервер приложений Oracle Application
Server (Oracle iAS 10g) использует для обеспечения комплексной безопасности в сложных
средах распределенной обработки данных. Oracle iAS 10g Infrastructure включает следую-
щие продукты:
•	Oracle Database 10g (Metadata Repository, MR) — сервер баз данных, в таблицах ко-
торого сохраняется вся информация, необходимая для предоставления услуг управ-
ления учетными записями; является репозиторием для других продуктов Oracle
iAS 10g Infrastructure, таких как Oracle Internet Directory;
•	Oracle Internet Directory (OID) — каталог LDAP v.3, использующий для хранения
идентификационных данных СУБД Oracle;
•	Oracle Single Sign-On Server (OSSO) — сервис, выполненный на базе Oracle HTTP
Server и контейнеров OC4J (Oracle Containers for JAVA). Предоставляет админи-
стративные и пользовательские интерфейсы по протоколу HTTP(S), в свою очередь
взаимодействует с Oracle Internet Directory для проверки аутентификационных
данных и хранения ряда конфигурационных параметров* OSSO имеет встроенные
функции поддержки цифровых сертификатов формата Х.509;
•	Delegated Administration Services (DAS) — субкомпонент OSSO, предназначенный
для делегированного администрирования идентификационных и аутентификаци-
онных данных, сохраненных в Oracle Internet Directory;
•	Directory Integration Platform (DIP) — сервис, выполненный на базе OC4J и предос-
тавляющий услуги интеграции идентификационных данных между гетерогенными
источниками. В качестве таких источников могут быть базы данных (например,
таблица FND_USERS, хранящая пользовательские данные Oracle E-Business Suite)
либо LDAP-каталоги (например, MS Active Directory). Взаимодействие DIP с ис-
точниками осуществляется с помощью профилей (коннекторов, плагинов), опре-
деляющих правила и направления миграции данных.
Гпава 2 Обеспечение безопасности доступа на основе рекомендаций и продуктов Oracle и Aladdin
Рис. 2.6. Архитектура управления учетными шписями пользователей
Слой баз данных
Архитектура управления учетными записями пользователей, реализованная на сер-
висах Oracle iAS 10g, представлена на иллюстрации (рис. 2.6).
Принцип работы Single Sign-On Oracle iAS 10g заключается в следующем: приложе-
ния Oracle (по умолчанию либо с добавленным функционалом) способны осуществлять
аутентификацию пользователя на основании заголовка Cookie, формируемого сервером
Single Sign-On после успешной аутентификации пользователя в системе однократной ре-
гистрации. В заголовке Cookie содержится зашифрованная информация об имени поль-
зователя и идентификатор успешного прохождения аутентификации.
Уровень безопасности решений на основе Oracle iAS 10g
В решениях на основе Oracle iAS 10g могут быть применены следующие методы за-
щиты аутентификационных данных:
•	сложные пароли;
•	генерация паролей по установленной парольной политике (настраивается средст-
вами Oracle Internet Directory);
•	сертификаты формата Х.509;
•	защита секретного ключа пользователя PIN-кодом.
Таким образом, Oracle iAS 10g обеспечивает максимальную защищенность аутенти-
фикационных данных.
Двухфакторная аутентификация в Oracle iAS 10g
В решениях на базе Oracle iAS 10g может быть реализован механизм двухфакторной
аутентификации на базе сертификатов Х.509. При этом в качестве первого фактора аутен-
тификации выступают сертификаты, а в качестве второго фактора — аппаратные носители
сертификатов и секретных ключей пользователей. Аппаратные носители — смарт-карты —
способны осуществлять генерацию секретного ключа пользователя и выполнять с его по-
мощью криптографические операции. Секретный ключ в данном случае не покидает фи-
зические границы аппаратного носителя. В качестве аппаратных носителей ключевой
информации могут использоваться аппаратные носители, которые способны взаимодей-
ствовать с криптопровайдером операционной системы Windows. Таким решением, напри-
мер. является USB-ключ или смарт-карта eToken PRO компании Aladdin. Взаимодейст-
вие eToken с криптопровайдером Windows осуществляется с помощью ПО eToken RTE
(Run-Time Environment).
Способы аутентификации
Сервер Single Sign-On в составе Oracle iAS 10g может использовать в качестве пользо-
вательского интерфейса протокол HTTP(S). Таким образом, возможны следующие спо-
собы аутентификации:
ЧАСТЬ II. ПРАКТИКА
•	аутентификация по имени и паролю пользователя;
•	SSL-аутентификация по протоколу HTTPS с предъявлением сертификатов Х.509
Любой из приведенных методов может быть усилен применением аппаратных носи’
телей. Пример аутентификации по имени и паролю пользователя приведен на рис. 2.7
Зарегистрироваться
Введите имя пользователя и уникальный пароль регистрации
Имя пользователя
Пароль
Забыли пароль?
Рис. 2.7. Форма аутентификации Oracle Identity Management с вводом имени пользователя и пароле
Пример SSL-аутентификации по протоколу HTTPS с использованием USB-ключе!
и предъявлением сторонами своих сертификатов иллюстрируют рис. 2.8 и 2.9. При под-
Chaos? a dejHaliertita .»!<•
г Identification
The Web site you want to view requests
identification Please choose a certificate.
Name	Issuer	, .________________
Users	DemoCA
Users	DemoCA
More Info... I View Certificate... |
_____________________________~1
OK	Cancel
Рис. 2.8. Окно выбора сертификата
190
Гпава 2. Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
кдючении к компьютеру USB-ключа (или смарт-карты) eToken, на котором (-ои) хранятся
сертификаты открытых ключей пользователя, появляется окно выбора нужного серти-
фиката (единственный сертификат выбирается автоматически).
Пользователь выбирает сертификат, но для работы с ним система просит предвари-
тельно ввести PIN-код.
ёТокеп
Рис. 2.9. Окно ввода PIN-кода
Серверное и клиентское ПО
Решение для Oracle iAS 10g не требует установки какого бы то ни было специализи-
рованного ПО на рабочие места пользователей, если выполняется парольная аутенти-
фикация пользователей. При аутентификации пользователей с помощью цифровых сер-
тификатов, установленных на электронных ключах eToken Pro, на рабочие места поль-
зователей необходимо установить клиентское ПО eToken Real-Time Environment (RTE).
Количество единиц серверного оборудования может варьироваться в зависимости от
топологии развертывания решения. Компания Oracle рекомендует разворачивать реше-
ние Oracle Identity Management в следующей конфигурации:
•	2 сервера Oracle Database 10g с установленной опцией Real Applications Clusters;
•	2 сервера для размещения компонентов Oracle Internet Directory и Directory Integra-
tion and Provisioning;
•	2 сервера для размещения компонентов Single Sign-On и Delegated Administration
Services;
•	2 устройства балансировки нагрузки.
Рекомендуемая топология приведена на рис. 2.10.
На данной иллюстрации:
•	LBR#1, LBR#2 — Load Balancer — устройства балансировки нагрузки;
•	IM1, IM2 — серверы с размещенными компонентами OSSO и DAS:
•	O1D1, 01D2 — серверы с размещенными компонентами OID и DIP.
ЧАСТЫ1 ПРАКТИКА
Рис. 2.10. Рекомендуемая топология развертывания решения Oracle Identity Management
Нижний слой представлен двумя серверами баз данных с размешенными агентами Real
Application Clusters и данными, вынесенными на сетевое хранилище (Shared Disk Storage).
Возможности авторизации
Решения на основе Oracle iAS 10g не реализуют авторизационные требования при до-
ступе к не-Огас!е-приложениям. Доступ пользователей к тем или иным данным после
пройденной аутентификации (авторизации) осуществляется собственно средствами
не-Огас!е-приложений.
Oracle Internet Directory позволяет группировать пользователей в зависимости от их
прав доступа, однако в данном случае авторизация носит бинарный характер, т. е. поль-
зователи из выделенных групп могут проходить авторизацию средствами Single Sign-On.
а другим в доступе будет отказано.
Поддерживаемые платформы
Решения на основе Oracle iAS 10g ориентированы на совместимость с решениями
Oracle, такими как Oracle E-Business Suite, Oracle Portal и др. Информационные системы
и платформы от сторонних производителей в явном виде не поддерживаются. Такие ре-
шения позволяют также обеспечить SSO по отношению к трехзвенным приложениям
других поставщиков.
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Поддерживаемые аутентификационные устройства
Так как платформа Oracle iAS 10g в первую очередь ориентирована на поддержку тон-
ких веб-клиентов, допускается использование любых аутентификационных устройств,
совместимость которых с веб-браузерами и операционной системой предусмотрена
производителем устройства.
Решение eToken SecurLogon для Oracle Application Server
Решение компании Aladdin eToken SecurLogon для Oracle Application Server предназ-
начено для аутентификации в Oracle iAS 10g с помощью смарт-карт. Поддержка устройств
eToken обеспечивается с помощью драйвера eToken Run-time Environment, который
взаимодействует с криптопровайдером операционной системы и позволяет осуществ-
лять операции с ключевой информацией, сохраненной в аппаратном носителе, через
криптопровайдер операционной системы прозрачно для пользователя. Благодаря eToken
SecurLogon пользователям не нужно запоминать имена и пароли, следить за сложностью
и качеством паролей, периодически их менять — нужно только носить с собой USB-ключ
или смарт-карту и знать PIN-код.
eToken SecurLogon для Oracle Application Server обеспечивает взаимную аутентифи-
кацию клиента и сервера приложений при доступе к приложениям и шифрование со-
гласно протоколу SSL с помощью цифровых сертификатов Х.509. Такую же связь можно
установить между сервером приложений и сервером базы данных. Благодаря этому на сер-
верах может быть введен явный запрет на соединения по открытому протоколу (не SSL).
При этом для приложений, требующих соединения с каким-либо сервером по откры-
тому протоколу (например, для администрирования сервера), в сетевых настройках дан-
ного сервера явно указываются IP-адреса, для которых действует исключение из общего
запрета.
eToken SecurLogon для Oracle Application Server можно интегрировать с Token Manage-
ment System (TMS) — системой управления жизненным циклом USB-ключей и смарт-карт
eToken SecurLogon встраивается в различные инфраструктуры открытых ключей — не
только Oracle iAS 10g, но и Microsoft Windows 2000/ХР/2003, RSA Keon и т. п., что обес-
печивает возможность централизованного выпуска сертификатов и управления правами
пользователей в рамках всей информационной инфраструктуры предприятия, а не толь-
ко подсистем на основе продуктов Oracle
Преимущества
Решение eToken SecurLogon для Oracle Application Server обеспечивает значительно
более высокую безопасность за счет:
•	отказа от передачи имен пользователей и паролей по сети в открытом виде;
•	применения двухфакторной программно-аппаратной аутентификации вместо од-
нофакторной;
•	использования защищенного шифрованием канала передачи данных;
•	взаимной аутентификации сервера и клиента;
•	эффективного применения встроенных средств и механизмов защиты Oracle
Application Server.
Способы аутентификации, применяемые в eToken SecurLogon для Oracle Application
Server на основе технологии авторизации Oracle Single Sign-On, удобнее для пользователей,
чем стандартные способы, поскольку требуют запоминания единственного PIN-кода,
* не множества имен пользователя и сложных паролей, необходимых для доступа к раз-
личным приложениям.
193
ЧАСТЬ II ПРАКТИКА
Принципы работы и архитектура eToken SecurLogon для Oracle Application Server
Процесс аутентификации иллюстрирует рис. 2.11, на котором цифрами обозначены
этапы аутентификации:
1	и 2 — взаимная аутентификация клиента и сервера приложений с помощью циф-
ровых сертификатов Х.509. Сертификат пользователя с секретным ключом установлен
в памяти eToken, а сертификат сервера приложений (HTTP-сервера) с секретным клю-
чом — в контейнере wallet (файле формата PKCS#12).
3	— после успешной аутентификации компонент Single Sign-On сервера приложений
проверяет в LDAP-каталоге (Oracle Internet Directory, O1D) наличие учетной записи поль-
зователя, для которого издан этот сертификат. Причем проверка может выполняться по
всем полям сертификата или просто по отличительному имени владельца сертификата.
4	— если учетная запись пользователя найдена, то устанавливается защищенное со-
единение по протоколу SSL и пользователь получает доступ к приложению с правами,
соответствующими его учетной записи.
Сервер приложений должен быть настроен на аутентификацию с помощью протокола
SSL. Сервер приложений выступает по отношению к серверу базы данных как обычный
клиент и имеет одно или несколько постоянных соединений с сервером базы данных.
Рис. 2.11. Процесс аутентификации с помощью eToken SecurLogon для Oracle Application Server
2.1.2.2. Встраивание сертифицированных криптографических средств
в информационные системы на платформе Oracle Application Server
Постановка задачи
Основной задачей является построение защищенной информационной системы, ис-
пользующей технологии и инфраструктуру Oracle Application Server. Данная задача делится
на три подзадачи:
194
Гпава 2 Обеспечение безопасности доступа на основе рекомендаций и продуктов Oracle и Aladdin
•	зашита канала передачи данных криптографическими методами;
•	усиленная аутентификация пользователей при доступе к приложениям информа-
ционной системы;
•	интеграция со штатными механизмами аутентификации/авторизации Oracle Appli-
cation Server.
Решение предусматривает использование программных продуктов, реализующих рос-
сийские криптоалгоритмы. Поставщики криптографических средств защиты должны
иметь лицензии ФСБ России, а само ПО — сертификаты по соответствующему классу
защищенности. Применяемые методы встраивания решения в инфраструктуру Oracle
Application Server не должны нарушать лицензионных соглашений на использование ПО
поставщика (Oracle, поставщиков ОС для сервера или клиентских рабочих станций).
Описание решения
Основными компонентами решения, представленного на рис. 2.12, являются:
•	приложения (applications), которые реализуют интерфейс пользователя и бизнес-ло-
гику информационной системы;
•	клиент (Web-браузер), который обеспечивает взаимодействие между клиентом и
сервером приложении;
•	сертифицированное СКЗИ (подключаемый модуль сервера Apache (mod_ssl), адап-
тированный для работы с российской криптографией), который устанавливает за-
щищенное соединение между клиентом и сервером по протоколу SSL/TLS, ис-
пользует сертификаты/ключи для аутентификации на серверном компоненте;
•	eToken RTE (драйверы смарт-карт и USB-ключей eToken компании Aladdin и до-
полнительное ПО для работы с ними).
В качестве физических носителей ключей и сертификатов пользователей применя-
ются USB-ключи или смарт-карты eToken. Физическое хранилище сертификатов и сек-
ретных ключей, используемое модулем СКЗИ в составе прокси-сервера, определяется
производителем СКЗИ.
В качестве ПО для выпуска сертификатов могут использоваться программные про-
дукты, которые автоматизируют функции удостоверяющих центров (УЦ). Эти программные
продукты должны быть сертифицированы ФСТЭК, ФСБ РФ (например, программный
комплекс «Удостоверяющий Центр «КриптоПро УЦ»).
Принцип функционирования
1.	Пользователь информационной системы пытается получить доступ к защищенно-
му ресурсу (приложению). Клиент посылает запрос на аутентификацию прокси-серверу.
2.	Производится стандартная аутентификация по SSL-протоколу При этом eToken
RTE осуществляет дополнительную авторизацию (запрос PIN-кода) для выполнения
операции с секретным ключом. Логику работы с сертификатами, изданными с исполь-
зованием российских криптоалгоритмов, реализует модуль СКЗИ (mod_ssl), имплемен-
тированный в сервер Apache.
3.	При успешной аутентификации создается защищенный канал передачи данных между
клиентом и прокси-сервером, а все запросы в дальнейшем перенаправляются на Oracle
HTTP Server (OHS). Необходимые для авторизации заголовки запросов устанавливаются
прокси-сервером на основании информации, полученной из сертификата, предъявлен-
ного клиентом в процессе аутентификации
4.	Затем обращение к приложению перехватывается компонентом Single Sign-On (SSO)
Oracle Application Server, который обеспечивает штатный процесс авторизации пользо-
вателя и использует вызов подключаемого модуля авторизации (Custom SSO plug-in).
195
ЧАСТЫ1. ПРАКТИКА
Канал связи,
защищенный СКЗИ
(TLS/SSL)
|	| — настраиваемые компоненты
| Z | — компоненты поставщиков СКЗИ
Рис. 2.12. Аутентификация и защита канала передачи данных с помощью eToken SecurLogon
для Oracle Application Server и средств криптографической защиты
Решение позволяет создавать информационные системы на платформе Oracle Application
Server, которые не только обладают повышенной безопасностью, но и соответствуют
требованиям лицензирующих организаций. Описанная выше схема опирается только на
документированные возможности используемого ПО и соответственно не нарушает ли-
цензионных соглашений на его применение.
196
Гпава 2. Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
2.1.2.3.	Смарт-карты и USB-ключи eToken для аутентификации и авторизации
в приложениях Oracle Business Intelligence ЕЕ
Постановка задачи
Основной задачей является построение защищенной информационной системы, ис-
пользующей технологии и инфраструктуру Oracle Application Server. Данная задача делится
на четыре подзадачи:
•	защита канала передачи данных криптографическими методами;
•	усиленная аутентификация пользователей при доступе к приложениям информа-
ционной системы;
•	безопасное хранение ключей и сертификатов;
•	интеграция со штатными механизмами аугентификации/авторизации Oracle Appli-
cation Server.
Применяемые методы встраивания решения в инфраструктуру и/или приложения
Oracle Application Server не должны нарушать лицензионных соглашений на использование
ПО поставщика (Oracle, поставщиков ОС для сервера или клиентских рабочих станций)
TLS/SSL (LAN/WAN)
Рис. 2.13. Аутентификация и авторизация в приложениях Oracle Business Intelligence ЕЕ
посредством смарт-карт и USB-ключей eToken
197
ЧАСТЫ1 ПРАКТИКА
Описание решения
Основными компонентами решения, представленного на рис. 2.13, являются:
•	приложения (applications), которые реализуют интерфейс пользователя и бизнес-ло-
гику приложений Oracle Bl ЕЕ и Oracle Bl Publisher (XML Publisher);
•	инфраструктура, которая обеспечивает хранение информации о пользователях, ро-
лях, приложениях, а также реализует механизмы авторизации и однократной ре-
гистрации (Single Sign-On);
•	клиент (Web-браузер), который реализует взаимодействие по сети между клиен-
том и сервером приложений.
В качестве физических носителей ключей и сертификатов пользователей используются
USB-ключи или смарт-карты eToken. Сертификаты и секретные ключи, используемые
компонентом Oracle HTTP Server (OHS) в составе сервера приложений и инфраструктуры,
хранятся в файле формата PKCS#12.
Принцип функционирования
1.	Пользователь информационной системы пытается получить доступ к защищенному
ресурсу (приложению), вводя соответствующий URL в адресной строке браузера. Браузер
клиента посылает запрос на http-сервер (OHS) сервера приложений.
2.	OHS выполняет стандартную SSL-аутентификацию, используя свой сертификат и
секретный ключ из файлового хранилища
3.	Пользователь предъявляет свой сертификат, хранящийся на смарт-карте или
USB-ключе eToken.
4.	При успешной аутентификации создается защищенный канал передачи данных меж-
ду браузером клиента и сервером приложений. Необходимые для процедуры авторизации
заголовки запросов устанавливаются http-сервером на основании информации, полу-
ченной из сертификата, предъявленного клиентом в процессе аутентификации.
5.	Затем обращение к приложению перехватывается компонентом Single Sign-On (SSO)
инфраструктуры Oracle Application Server, SSO обеспечивает штатный процесс автори-
зации пользователя и использует вызов подключаемого модуля авторизации по цифро-
вому сертификату.
6.	При успешной авторизации пользователь получает доступ к выбранному приложению.
7.	Если сессия пользователя не прерывалась (браузер не был закрыт), то последующие
обращения к другим приложениям Oracle Business Intelligence или иным, развернутым на
Oracle Application Server, не потребуют повторных процедур аутентификации и авторизации.
В качестве ПО для выпуска сертификатов могут использоваться программные про-
дукты для автоматизации функций удостоверяющих центров (УЦ) от разных производи-
телей. Все используемые технологии, компоненты и настройки на стороне сервера при-
ложений и инфраструктуры предоставляются в составе соответствующих компонентов
Oracle и описаны в штатной документации.
2.1.3.	Обеспечение безопасности доступа
к бизнес-приложениям Oracle E-Business Suite
Постановка задачи
В компании, работающей в сфере информационных технологий (крупный систем-
ный интегратор), необходимо реализовать внутренний проект по созданию корпоративной
системы управления на базе комплекса бизнес-приложении Oracle E-Business Suite. Обладая
198
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
широким функционалом (от управления финансами и производством до отношений с пос-
тавщиками и клиентами), данный комплекс консолидирует в среде бизнес-приложений
обширную конфиденциальную информацию о деятельности компании.
Основными целями проекта по обеспечению защищенного доступа к ресурсам про-
граммного комплекса являются:
•	предоставление безопасного доступа с удаленных рабочих станций к корпоратив-
ным информационным ресурсам Oracle E-Business Suite;
•	обеспечение как локальных, так и удаленных пользователей возможностями ра-
боты по единому защищенному протоколу;
•	развертывание системы надежной двухфакторной аутентификации сотрудников
компании в сети с помощью аппаратного ключа eToken и PIN-кода;
•	построение инфраструктуры для защищенного документооборота на основе ЭЦП
и корпоративного Удостоверяющего центра.
Для более полного понимания специфики решения задачи обеспечения защищенного
доступа к Oracle E-Business Suite необходимо кратко описать архитектуру данного програм-
много комплекса.
Архитектура Oracle E-Business Suite
Oracle E-Business Suite использует трехуровневую модель приложений (представлена на
рис. 2.14):
•	уровень клиента (Desktop Tier);
•	уровень приложений (Application Tier);
•	уровень базы данных (Database Tier).
Архитектура Oracle E-Business Suite позволяет выполнять распределенные вычисле-
ния и легко масштабируется на уровнях приложений и базы данных, что означает воз-
можность установки нескольких экземпляров служб на уровне приложений, располо-
женных на разных компьютерах, объединенных в сеть
Concurrent Processing
Server
Reports Server
Admin Server
Discoverer Server
Приложения
Database Server
БД
ЧАСТЫ1 ПРАКТИКА
Уровень клиента
Уровень клиента представлен Интернет-браузером, а также Java-машиной, функци-
онирующей как добавочный компонент (add-on) браузера; он обеспечивает визуальный
интерфейс пользователя (рис. 2.15).
Рис. 2.15. Взаимодействие клиента и приложений
Компоненты уровня клиента и уровня приложений могут взаимодействовать как
в рамках локальной (LAN), так и глобальной сети (WAN).
Пользователь в браузере вводит адрес (URL), являющийся адресом веб-сервера эк-
земпляра Oracle E-Business Suite. Работа с Oracle E-Business Suite начинается с аутенти-
фикации и авторизации пользователя, т. е. с ввода имени и пароля (рис. 2.16).
При успешной аутентификации/авторизации браузер переадресуется на стартовую
страницу, соответствующую введенному имени пользователя. Затем данное имя (учетная
запись) используется для различных целей, в том числе аудита и ограничения доступа.
CDRACZLG Пакет приложений электронного бизнеса
Вход______________________________________________ _
Имя пользователя
Пароль
С Вход )
Русский • English
(С) Корпорация Oracle, 2004 Все права зашуш^ны
Рис. 2.16. Форма авторизации доступа к Oracle E-Business Suite с вводом имени пользователя и пароля
200
Гпава 2. Обеспечение безопасности доступа на основе рекомендаций и продуктов Oracle и Aladdin
ORACLE E-Business Suite
Diagnostics Home Logout preferences K0d
Logged In As JAL EE
Favorites
v Edit Favomes)
J Advanced Workhst
3 Saien Orders
J Verify Ooen Transactions
J Expenses Home
 Submit Requests
Navigator
Q Customer Relationship
Mgmt
. Edit Navigator J
Procurement Cards
View Transection History
Enterprises
Diagnostics I Home | Logout I Preferences I Help
Copyright 2000-2005 Огкш СогрогМюп Al rghts reserved
About this Page
Рис. 2.17. Пример стартовой страницы пользователя
веб-сервер также посылает некоторый набор данных, идентифицирующий сессию
(authentication cookie), которая существует до момента закрытия браузера или до завер-
шения работы с Oracle E-Business Suite.
На стартовой странице (рис. 2.17) в виде ссылок перечислены приложения, к кото-
рым разрешен доступ пользователю. При навигации по ссылкам каждое из приложений,
входящих в состав Oracle E-Business Suite, проверяет наличие authentication cookie для
данной сессии. Если такая информация недоступна, то аутентификация/авторизация
повторяется. Таким образом обеспечивается единая точка доступа ко всему набору при-
ложений.
Презентационный уровень выполняемых в окне браузера приложений обеспечивает
виртуальная машина Java и апплет клиента (Client Applet) Апплеты клиента содержат все
необходимые визуальные и прикладные компоненты, реализующие клиентскую часть
(Front End) Oracle E-Business Suite и представлены в виде набора jar-архивов. Виртуальная
машина Java кэширует нужные jar-файлы на рабочей станции клиента, при необходи-
мости обновляет их и выполняет апплеты клиента в окне браузера. В качестве вирту-
альной машины Java на рабочей станции клиента архитектура Oracle E-Business Suite
предусматривает возможность использования одного из трех компонентов:
•	Oracle Jinitiator;
•	Sun Java RunTime Environment (JRE);
•	Microsoft Java Virtual Machine (JVM).
Уровень приложений
Уровнень приложений представлен набором сервисов (Services), которые реализуют
бизнес-логику компонентов Oracle E-Business Suite, а также обеспечивают управление
компонентами и формирование страниц для отображения на уровне клиента. Основны-
ми компонентами уровня приложений являются веб-сервер и сервер форм. Приложе-
ния, выполняемые на данном уровне, могут быть разделены на два класса:
•	приложения на основе HTML (HTML-based или Self Service Applications);
•	приложения на основе Oracle Forms (Forms-based Applications).
ЧАСТЫI. ПРАКТИКА
Web-сервер
Web-сервер обрабатывает запросы от браузера клиента и формирует HTML-страни-
цы для отсылки результата. Web-сервер содержит следующие компоненты (рис. 2.18 с
•	проел ушиватель (Web-listener);
•	сервер сервлетов (Java servlet engine);
•	серверные страницы Java (Java Server Pages).
По возможности Web-сервер обслуживает запросы самостоятельно, при необходимости
передавая запросы в сервер сервлетов, например, для извлечения информации из базы
данных.
Непосредственно Web-сервером выполняются HTML-приложения, которые имеют
следующие особенности:
•	не используют Oracle Forms;
•	разработаны на чистом HTML и Java Script;
•	динамически формируют HTML-страницы, исполняя Java-код;
•	для формирования страниц используют репозиторий БД.
Сервер форм
Сервер форм Oracle Forms Server обслуживает формы Oracle E-Business Suite и обеспе-
чивает графический интерфейс пользователя. Сервер форм взаимодействует с БД, из-
влекая нужную информацию, формирует и отображает окна на уровне клиента, иници-
ирует изменения в БД (рис. 2.19). Дополнительно сервер форм кэширует необходимые
данные (например большие списки) на уровне клиента.
Сервер форм может взаимодействовать с браузером клиента по протоколам HTTP.
HTTPS и Socket (TCP/IP), а с сервером БД — по протоколу Oracle Net*8.
Forms Listener Servlet
Для работы сервера форм в локальной сети, как правило, используется режим Socket
Такой режим является наиболее производительным, однако, не позволяет получить до-
ступ к Oracle E-Business Suite через глобальную сеть, для этого используется специальная
202
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Клиент
Приложения
БД
Рис. 2.19. Взаимодействие сервера форм с базой данных и браузером клиента
архитектура Forms Listener Servlet. Она дает возможность взаимодействовать процессам
времени исполнения сервера форм с клиентом через Web-сервер и использовать НТТР-
или HTTPS-протоколы. Помимо возможности работы по глобальной сети такая архи-
тектура позволяет восстанавливать прерванные соединения, использовать меньшее ко-
личество портов и обеспечивает более высокий уровень безопасности при передаче данных
в Интернете. Однако в рамках такой архитектуры возрастает сетевой трафик (в среднем
на 40%). Это приводит к увеличению времени отклика для клиента LAN на 8—10 %, а для
клиента WAN — до 30%.
Уровень базы данных
Уровень базы данных также представлен набором сервисов и обеспечивает хранение
и манипулирование данными Oracle E-Business Suite.
Схема безопасности Oracle E-Business Suite
Стандартная система безопасности Oracle E-Business Suite базируется на четырех ком-
понентах — аутентификации, авторизации, аудите и безопасности сети Аутентификация
осуществляется по имени пользователя и паролю. Возможности имеющейся специальной
системы настройки политики управления паролями и их качеством, как правило, персо-
налом не используются, и все недостатки, присущие аутентификации по паролям, сохра-
няются. Короткие и простые пароли легко подбираются; длинные и сложные тяжело за-
помнить, и поэтому их часто записывают, что является грубым нарушением политики
безопасности; слишком редкая смена пароля пользователями существенно снижает все
усилия специалистов по информационной безопасности.
Система авторизации обеспечивает управление правами и привилегиями, назначенны-
ми определенной учетной записью, а система аудита позволяет протоколировать и обра-
батывать информацию о транзакциях, выполненных от имени определенного пользова-
теля по учетной записи. Oracle E-Business Suite поддерживает работу всех своих компо-
нентов по протоколу HTTPS, что обеспечивает защиту каналов передачи данных.
Помимо своевременного обновления повышения качества паролей и регулярного
аудита для защиты приложении при доступе к ним через Интернет рекомендуется исполь-
зовать протокол HTTPS. После выполнения ряда процедур (как автоматизированных.
203
ЧАСТЫ1 ПРАКТИКА
так и выполняемых вручную) все компоненты Oracle смогут работать через защищенные
каналы связи. Однако, если на веб-сервере, обрабатывающем запросы от браузера кли-
ента и формирующем HTML-страницы, установить обязательную проверку подлинности
сертификата клиента, работа на сервере форм становится невозможной.
Это происходит из-за того, что Oracle Jinitiator (встроенный в браузер компонент), ис-
пользуемый на уровне клиента, не поддерживает аутентификацию клиента по SSL-про-
токолу. поскольку не умеет извлекать сертификат клиента из хранилища браузера. Эта про-
блема может быть решена заменой на клиентской рабочей станции компонента Jinitiator
от Oracle на подключаемый модуль Java Plug-In от Sun, при этом требуются дополнительные
настройки на стороне сервера и клиента. Еще один недостаток такого решения — на-
личие дополнительного хранилища сертификатов и ключей, «понятных» Java-клиенту.
Сертификаты и ключи, установленные в браузере (т. е. в локальном хранилище сер-
тификатов Microsoft), порождают как минимум две проблемы. Во-первых, они не могут
считаться в достаточной мере защищенными, поскольку эта информация доступна для
записи пользователя компьютера, на котором установлен браузер, и для администратора
системы, следовательно, ею могут воспользоваться несанкционированно. Во-вторых,
остается проблема удаленного доступа с произвольного компьютера, поскольку учетной
записью можно воспользоваться через Интернет с удаленного компьютера.
Вариант с хранением ключевой информации на незащищенных носителях (дискеты,
флэш-память и т. п.) неприемлем как с точки зрения безопасности, так и по соображе-
ниям надежности и удобства использования: удаленному пользователю, например, нужно
установить ключевой контейнер с носителя на компьютер, а по завершении сеанса не забыть
его удалить. Разумным выходом является хранение ключей и сертификатов на отчуждае-
мом защищенном носителе — USB-ключе или смарт-карте eToken компании Aladdin.
Описание решения
Авторизованный доступ пользователей к данным бизнес-приложении Oracle E-Business
Suite осуществляется с помощью цифровых сертификатов, защищенного SSL-протокола
взаимодействия пользователя и комплекса бизнес-приложений Oracle E-Business Suite
на базе специализированных аппаратно-программных продуктов Aladdin.
Продукт eToken SecurLogon for Oracle E-Business Suite
Возможности
Программно-аппаратный продукт eToken SecurLogon для Oracle E-Business Suite ком-
пании Aladdin обеспечивает взаимную аутентификацию клиента и сервера Oracle E-Busi-
ness Suite на основе цифровых сертификатов Х.509 при доступе к серверу и шифрование
согласно протоколу SSL. Благодаря этому на сервере может быть введен явный запрет на
соединения по открытому протоколу (не SSL). При этом для приложений, требующих
соединения с сервером Oracle E-Business Suite по открытому протоколу (например, для
администрирования), в сетевых настройках сервера явно указываются IP-адреса, для ко-
торых действует исключение из общего запрета.
В продукте предусмотрена возможность интеграции с Oracle Application Server Single
Sign-On. Такая интеграция обеспечивает однократную регистрацию пользователя при до-
ступе к различным ресурсам и централизованное управление правами пользователей
приложении. Продукт позволяет использовать один и тот же eToken для доступа в поме-
щения (по встроенной в карту радиометке) и в различные системы приложения (не толь-
ко входящие в пакет приложений Oracle для электронного бизнеса).
204
Глава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Продукт можно интегрировать с Token Management System (TMS) — системой управ-
ления жизненным циклом eToken в масштабах предприятия С помощью TMS можно
организовать централизованную подготовку eToken к работе, удаленное обслуживание (в том
числе разблокирование PIN-кода), отзыв полномочии и т. д.
Продукт встраивается в различные инфраструктуры открытых ключей — не только
Oracle Identity Management, но и Microsoft Windows 2000/ХР/2003, RSA Keon и т. п. Это
обеспечивает возможность централизованного издания сертификатов и управления пра-
вами пользователей в рамках всей информационной инфраструктуры предприятия, а не
только подсистем Oracle.
Принципы работы продукта
Аутентификация и авторизация пользователей выполняется следующим образом.
Пользователь вводит в окне браузера адрес защищенного Web-сервера Oracle E-Business
Suite (используется протокол HTTPS). Для аутентификации пользователя на Web-сер-
вере применяются секретный ключ и сертификат открытого кл юча, установленный в па-
мяти eToken. В процессе аутентификации у пользователя запрашивается PIN-код
eToken. При успешной аутентификации между клиентом и сервером устанавливается
защищенное соединение, и пользователь попадает на стартовую страницу Oracle
E-Business Suite.
Аутентификация пользователя на сервере форм, осуществляется с помощью eToken
Web Sign On. Затем пользователь выбирает приложение, в котором он будет работать
После этого на рабочей станции клиента активизируется Java-клиент, который также ус-
танавливает с сервером защищенное соединение и загружает (при необходимости) нуж-
ные библиотеки с сервера.
Преимущества продукта
Продукт eToken SecurLogon обладает следующими преимуществами:
•	не требует установки какого-либо дополнительного программного обеспечения
на сервере, достаточно выполнения описанных настроек;
•	поддерживает все серверные платформы, на которые может быть установлен пакет
приложений Oracle для электронного бизнеса;
•	предусматривает безопасное хранение секретных ключей и соответствующих сер-
тификатов открытого ключа в энергонезависимой памяти ключа eToken;
•	способы аутентификации, применяемые в продукте, удобны для пользователей,
так как не требуют запоминания множества имен пользователя и сложных паро-
лей, необходимых для доступа к разным приложениям.
Переход на аутентификацию по цифровым сертификатам
Вариант перехода на аутентификацию по цифровым сертификатам предполагает ис-
пользование клонированных сервисов уровня приложений, работающих с той же базой
данных, что и исходные сервисы, — Web- и Forms-серверами и др. Но в отличие от исходных
сервисов, клонированные изначально настроены на использование HTTPS-протокола и
обязательную двустороннюю аутентификацию с клиентом. Клон уровня приложений
располагается в защищенном сегменте сети и доступен как для пользователей глобаль-
ной сети (например, через прокси-сервер), так и для пользователей локальной сети
Такая схема (рис. 2.20) предоставляет следующие преимущества:
•	возможность постепенного перевода пользователей с прежней системы аутенти-
фикации на новую систему;
ЧАСТЫ1 ПРАКТИКА
Рис. 2.20. Схема использования клонированных сервисов уровня приложений
•	безопасное хранение ключевой информации;
•	возможность безопасной работы в глобальной сети;
•	возможность проверки подлинности клиентов, снижение рисков атак, например,
путем подбора пароля.
На начальной стадии выполнения проекта необходимо развернуть следующие програм-
мные продукты: Oracle Internet Directory (OID), представляюшиий собой реализацию
LDAP-каталога, и корпоративный удостоверяющий центр (УЦ) на базе Microsoft СА. ко-
торый, помимо генерации цифровых сертификатов обеспечивает организацию юриди-
чески значимого документооборота с применением ЭЦП в качестве аналога собствен-
норучной подписи.
Двухфакторная аутентификация при доступе к СУБД позволяет на порядок повысить
уровень информационной безопасности, проводить постоянный аудит всех действий в сис-
теме, а также полностью исключить перехват идентификационной информации пользо-
вателя потенциальным злоумышленником. Зашита данных на рабочих станциях пользо-
вателей может быть реализована с помощью продукта Secret Disk компании Aladdin.
Он обеспечивает защиту конфиденциальной информации, хранящейся и обрабатываемой
на персональных компьютерах под управлением ОС Microsoft Windows.
206
Гпава 2. Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Одним из преимуществ предложенного решения является организация удаленного
доступа к бизнес-приложениям Oracle E-Business Suite с помощью защищенного SSL-про-
токола, обеспечивающего надежную защиту передаваемой информации. Соединение
осуществляется в два этапа. Сначала в ходе двусторонней аутентификации сервера и
пользователя происходит установление SSL-сессии и подтверждение подлинности обеих
сторон. На втором этапе обеспечивается защита обмена данными с помощью шифро-
вания канала, в результате чего достигается конфиденциальность и целостность пере-
даваемой информации
Предлагаемое типовое проектное решение позволяет существенно повысить уровень
защищенности информации без внесения каких-либо изменений в систему В результате
компания получает возможность предоставлять пользователям безопасный доступ с уда-
ленных рабочих станций к корпоративным информационным ресурсам на базе Oracle
E-Business Suite. Доверенное информационное пространство можно расширить в случае
роста потребностей компании, обеспечив при этом необходимый уровень информаци-
онной безопасности. Это решение необходимо, прежде всего, компаниям, располагаю-
щим развитой сетью удаленных филиалов или мобильных рабочих мест.
2.1.4. Управление доступом и учетными данными пользователей
на основе программных продуктов
Oracle Identity и Access Management Suite
Технологии Oracle для управления учетными данными пользователей,
их правами и доступом
Приступая к реализации технологии управления учетными данными (реквизитами),
правами и доступом пользователей, корпорация Oracle рассматривала три ключевых кри-
терия. которые определяют современный подход к созданию корпоративных служб управ-
ления каталогами и учетными данными: полноту решения, интегрируемость, открытость
и поддержку неоднородных сред.
Полнота решения. Современные требования к решениям по управлению учетными
данными диктуют необходимость охвата полного спектра функциональных возможностей
управления идентификацией — от первоначальной подготовки к работе до долгосроч-
ного управления, от высокой безопасности доступа к развернутым в масштабах органи-
зации приложениям и информационным ресурсам до авторизации и аутентификации
доступа с тонкой детализацией параметров доступа, определяемой политикой инфор-
мационной безопасности организации.
Интегрируемость. Заказчики предпочитают работать с крупными производителями
программного обеспечения, которые в состоянии тесно интегрировать технологии управ-
ления учетными данными и бизнес-приложения. Именно здесь достигается наибольший
экономический эффект. Недостаточно просто предоставить инструменты для управле-
ния учетными данными и управления доступом. Заказчикам требуется, чтобы эти ин-
струменты были полностью интегрированы в деловую активность организации. Техно-
логии Oracle позволяют выполнять это критически важное требование и обеспечивают
интеграцию с такими бизнес-приложениями. как Oracle E-Business Suite, mySAP Business
Suite, PeopleSoft, JD Edwards, Siebel
Открытость и поддержка неоднородных сред. Ключевое требование сегодняшнего дня
состоит в том, что заказчикам необходимы решения, способные качественно работать
в неоднородной ИТ-инфраструкгуре. В ходе проектов по централизации ведения учет-
ЧАСТЫ1 ПРАКТИКА
ных записей крупные организации часто встречаются с проблемой интеграции систем
управления учетными данными с существующим ПО. Продукты Oracle специально раз-
работаны так, чтобы упростить интеграцию. Существует библиотека заранее сконфигу-
рированных коннекторов (адаптеров), которые обеспечивают доступ к большому коли-
честву тиражируемых бизнес-приложений, использующихся в крупных организациях.
Дополнительно каждый коннектор (адаптер) может быть переконфигурирован или до-
работан с помощью инструмента Oracle Adapter Factory. Запатентованная технология
Oracle Adapter Factory позволяет быстро и без программирования выполнять интеграцию
не только с тиражируемыми бизнес-приложениями, но и с приложениями, разработан-
ными внутри организации.
Программные средства управления учетными данными пользователей,
их правами и доступом Oracle Identity & Access Management Suite
В семейство программных продуктов компании Oracle под общим названием Oracle
Fusion Middleware включено инфраструктурное программное обеспечение класса middleware
(ПО промежуточного слоя) с широким спектром функциональных возможностей, в том
числе — интегрированный набор средств управления учетными данными и управления
доступом пользователей к корпоративным приложениям и информационным ресурсам.
Данный интегрированный набор носит название Oracle Identity & Access Management
Suite (Oracle IAMS). полный состав его компонентов представлен в табл. 2.2.
Кратко рассмотрим технологии хранения, доставки и управления учетными данными
пользователей и их доступом к информационным ресурсам организации, а также про-
граммные продукты, входящие в состав Oracle Identity & Access Management Suite.
LDAP-каталог Oracle
Ядром службы управления LDAP-каталогами является программный продукт Oracle
Internet Directory (OID).
Таблица 2.2
Функциональность и компоненты Oracle IAMS
Функциональность	Название компонента
Управление Web-доступом	Oracle Access Manager
Аудит и обеспечение соответствия законодательству	Oracle Identity Manager & Oracle Access Manager
Однократная регистрация в федеративных (партнерских) сетях	Oracle Identity Federation
Согласование идентификационных данных и их доставка во внешние хранилища	Oracle Identity Manager
Коннекторы (доставка ID-данных)	Oracle Identity Manager Connectors
Реализация LDAP-каталога	Oracle Inemet Directory
Виртуальный LDAP-каталог	Oracle Virtual Directory
Однократная регистрация на серверах приложении Oracle	Oracle SSO & Oracle Access Manager
Сервис делегирования прав администрирования	Delegated Administration Service
Платформа интеграции LDAP-каталогов	Directory Integration Platform
208
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Oracle Internet Directory — это реализация протокола LDAP версии 3, объединяющая
стандартные подходы к организации служб каталогов и опирающаяся на надежность и
масштабность СУБД Oracle. Служба каталогов Oracle представляет собой приложение на
основе СУБД Oracle, тесно интегрированное с сетевыми службами и управляющими
средствами Oracle. Используя 01D и применяя методы централизованной авторизации,
можно хранить в едином хранилище данные о сервисах, предоставляемых продуктах,
а также о пользователях и их правах в едином хранилище. 01D опирается на СУБД Oracle
и активно использует его возможности по обработке больших объемов данных и под-
держке одновременной работы с базой данных большого числа пользователей. Емкость
одного сервера каталогов оценивается в полмиллиарда записей.
СУБД Oracle — основа службы каталогов — спроектирована так, что системные опе-
рации, такие, как резервное копирование, добавление файлов данных, установка допол-
нительных приложений, могут проходить без остановки СУБД и не требуют отключения
пользователей. Восстановление после системных сбоев происходит автоматически. Для
обеспечения защиты от отказа аппаратных средств в архитектуру серверов LDAP заложена
возможность развертывания распределенной системы, состоящей из нескольких отдельных
серверов, обменивающихся информацией о происходящих изменениях и добавлениях.
Во время простоя одного сервера LDAP другие берут на себя задачи обслуживания поль-
зователей. После восстановления сервера, претерпевшего сбой, происходит полная синхро-
низация данных. Серверы OID пользуются проверенными на практике механизмами
репликации данных Oracle Advanced Replication.
01D обеспечивает три уровня авторизации пользователей: анонимный доступ, доступ
по паролю и авторизацию, основанную на сертификатах безопасности, распространяемых
в рамках инфраструктуры SSL v3. Разграничение прав доступа осуществляется админи-
стратором. Он может гибко контролировать доступность элементов хранения каталога,
предоставляя права и управляя доступом пользователей как к записям и их атрибутам,
так и к целым ветвям дерева каталогов.
Управление Web-доступом
Технология разработана в целях обеспечения централизованного управления доступом
корпоративных пользователей к информационным ресурсам организации с высокой сте-
пенью детализации прав и привилегий доступа, применяется для разнородных прикладных
сред, а также интеграции с такими компонентами ИТ-инфраструкгуры, как корпоративный
информационный портал, программное обеспечение для организации коллективной ра-
боты с корпоративной информацией и бизнес-приложениями, например ERP, CRM. SCM.
Oracle Access Manager предоставляет комплексный набор сервисов по централизован-
ному управлению доступом пользователей к различным информационным ресурсам
предприятия, в том числе Web-ресурсам и приложениям. В программном продукте пол-
ностью реализована концепция защищенного доступа к ресурсам предприятия (аутен-
тификация, авторизация и аудит). Развитые средства авторизации и аудита действии
пользователей и администраторов системы позволяют существенно повысить уровень
безопасности работы с информационными ресурсами.
Oracle Access Manager может работать с широким набором LDAP-каталогов серверов
приложений. Web-серверов, серверов порталов и бизнес-приложении, поставляемых ве-
дущими производителями ПО.
Централизованное управление учетными записями пользователей, политиками до-
ступа и аудита существенно снижает риски несанкционированного доступа к ресурсам,
особенно для организаций с большим количеством сотрудников и различных информа-
ционных ресурсов.
ЧАСТЫ1. ПРАКТИКА
Управлять учетными записями пользователей позволяют:
•	развитые средства проектирования полей учетных записей пользователя, опреде-
ления групп пользователей и организационной структуры предприятия, а также
удобный интерфейс для создания учетных записей, групп, оргструктуры;
•	широкий набор различных типов групп пользователей: статический, динамический,
вложенный, гибридный, на основе подписки. Особенно интересны динамические
группы, позволяющие определять группу на основе, например, условий назначения
атрибутов учетных записей Использование групп существенно упрощает адми-
нистрирование политик доступа;
•	средства автоматизации определения и исполнения потоков работ, состоящих как
из шагов взаимодействия с различного рода администраторами/менеджерами, так
и шагов по получению/передаче данных. Используются для реализации бизнес-про-
цессов утверждения при регистрации пользователей, регистрации их в группах,
для передачи идентификационных данных во внешние системы и др.:
•	средства самообслуживания которые дают возможность конечным пользовате-
лям самостоятельно создавать свои учетные записи, а также изменять в них дан-
ные (например, свои пароли) в рамках предоставленных им полномочий. В случае
необходимости с изменением поля учетной записи может быть связан поток ра-
бот, который, может, например, запросить разрешение на конкретную операцию
у руководителя данного сотрудника. Средства самообслуживания существенно
снижают расходы организации на администрирование пользователей и их прав
доступа;
•	делегированное администрирование пользователей и политик доступа, которое обес-
печивает создание многоуровневых иерархии администраторов, каждого со свои-
ми полномочиями, а также распределение нагрузки, и легко адаптируется к биз-
нес-структуре организации.
Особенностями управления доступом пользователей являются:
•	поддержка аутентификации пользователей на основе имен и паролей, цифровых
сертификатов, смарт-карт (в том числе — eToken), биометрии и др.;
•	возможность взаимодействия с внешними системами с целью расширенной аутен-
тификации и/или авторизации на основе имен и паролей, цифровых сертифика-
тов, смарт-карт, биометрии и др.;
•	поддержка авторизации пользователей и групп на основе политик авторизации
(развитый аппарат для определения сложных политик доступа);
•	наличие средств тестирования политик доступа и графического интерфейса для
определения защищаемых информационных ресурсов и политик доступа;
•	авторизация доступа к группе приложений на основе однократной аутентифика-
ции (Single Sign-On. SSO, федеративный SSO).
Oracle Access Manager позволяет осуществлять аудит действии, выполняемых сред-
ствами управления учетными данными и доступом пользователей, на основе политик
аудита, при этом возможна запись данных аудита в базу данных, что повышает надежность
и защищенность этих данных. Продукт поставляется с набором предопределенных отче
тов, например, по неуспешным авторизациям (по пользователям или ресурсам), по созда-
нию, активации, деактивации пользователей, по изменению данных в учетных записях-
Распространение и согласование учетных данных
Данная технология служит для автоматизации сложного и рутинного процесса реги-
страции и управления большим количеством учетных записей пользователей в неодно-
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
родной ИТ-инфраструктуре, когда имеется большое число различных LDAP-каталогов,
разнородных приложении и обшекорпоративных сервисов (таких, например, как элек-
тронная почта). Доставка учетных данных осуществляется с помощью программного
продукта Oracle Identity Manager, характерными особенностями которого являются:
•	полный технологический цикл авторизации доступа, гарантирующий, что доступ
к нужным ресурсам осуществляется быстро, непротиворечиво и в полном соот-
ветствии с корпоративными политиками доступа;
•	прямое подключение (за счет использования коннекторов) к приложениям управ-
ления кадрами (Human Resources Management Systems — HRMS) и их данным, что
позволяет предоставлять сотрудникам организации санкционированный руковод-
ством доступ ко всем корпоративным приложениям и информационным ресур-
сам, которые им необходимы для выполнения должностных обязанностей;
•	широкий спектр средств подключения (коннекторов) к операционным системам,
базам данных. LDAP-каталогам, средствам обеспечения коллективной работы,
приложениям и устройствам, что избавляет от рутинных работ по разработке до-
полнительных коннекторов.
Виртуальные каталоги
Программный продукт Oracle Virtual Directory позволяет отказаться от принципа фи-
зического хранения учетных данных в едином LDAP-каталоге. В качестве альтернативы
Oracle Virtual Directory предоставляет возможность создавать представления, которые
объединяют атрибуты идентификации данного объекта, взятые из других физически от-
деленных друг от друга хранилищ учетных данных, включая и LDAP-каталоги. Таким
образом, создается виртуальный каталог, синдицирующий в режиме реального времени
данные из различных хранилищ учетных данных и предоставляющий эти «взгляды»
(views) обшекорпоративным сервисам и приложениям Особенно удобно использование
виртуальных LDAP-каталогов при построении корпоративных порталов
Однократная регистрация в федеративных (партнерских) сетях
По мере того как все больше организации переносят свои бизнес-процессы в ИТ-инф-
раструктуру, появляется насущная потребность в расширении границ бизнес-процессов
до дочерних структур и бизнес-приложений партнеров. Системы, которые помимо собст-
венной ИТ-инфраструктуры, затрагивают также и ИТ-инфраструктуры партнерских ор-
ганизаций, носят название федеративных. Интеграция на федеративных началах (феде-
рирование учетных данных) позволяет организациям работать независимо, но объеди-
няться для достижения деловых целей.
Очевидно, что в федеративных системах для обеспечения доступа внешних пользо-
вателей к корпоративным приложениям и информационным ресурсам необходим жесткий
учет регистрационных записей пользователей с целью защиты от несанкционированного
доступа к корпоративным ресурсам. Работу с учетными данными в федеративных сис-
темах обеспечивает программный продукт Oracle Identity Federation, использующий для
доступа к другим системам управления учетными данными пользователей многопрото-
кольный шлюз, поддерживающий все стандарты федерирования, включая SAML,
Liberty, WS-Federation.
В итоге успешно аутентифицированные в партнерской сети пользователи могут под-
ключаться к ресурсам другой сети без повторной аутентификации.
ЧАСТЫ1. ПРАКТИКА
2.1.4.1.	Создание единой системы управления доступом, учетными данными
и однократной регистрацией пользователей крупного предприятия
на основе продуктов Oracle Identity Manager и Oracle Single Sign-On
Постановка задачи
Автоматизированная система управления (АСУ) крупного предприятия представляет
собой информационно-технологическую систему, которая характеризуется:
•	высокой степенью сложности,
•	широким спектром прикладных задач, решаемых подсистемами, и
•	разнообразием парка оборудования и базового программного обеспечения.
Структура АСУ предприятия, ее состав и взаимосвязи между подсистемами определя-
ются функциональной структурой корпоративной системы управления предприятия.
ИТ-инфраструктура предприятия состоит из множества разнородных автоматизированных
систем, предназначенных для решения разных задач, обладающих различными функ-
циональными возможностями и имеющих сложные связи между собой. Каждая из них
использует собственные механизмы аутентификации и управления жизненным циклом
учетных записей пользователей. Все идентификационные данные распределены по ин-
формационным системам, каждая система имеет собственное хранилище учетных запи-
сей, которыми управляют администраторы различных приложений. Подобный подход
существенно усложняет процедуру управления доступом и учетными данными в рамках
информационной системы всего предприятия, не позволяет централизованно управлять
учетными записями и требует значительных затрат на администрирование приложений.
В качестве первоначального источника учетных записей пользователей на предприятии
используется LDAP-каталог Microsoft Active Directory (MS AD). Кроме него существуют
другие типы хранилищ учетных данных, которые используются различными приложе-
ниями (Lotus Notes, Oracle Financial Analyzer, Oracle E-Business Suite).
Для большинства приложений Oracle учетные данные хранятся в так называемой инф-
раструктуре сервера приложений, которая состоит из LDAP-каталога — Oracle Internet
Directory (OID). системы однократной регистрации Web-приложений Oracle Single
Sign-On (OSSO) и сервисов синхронизации учетных данных между O1D и другими хра-
нилищами Directory Integration Platform (DIP). Для работы с приложениями, работаю-
щими в архитектуре «клиент—сервер», пользователи регистрируются в базах данных Or-
acle как пользователи СУБД с соответствующими правами.
Цели и задачи решения
Важнейшими задачами проектирования системы управления доступом, учетными дан-
ными и однократной регистрации пользователей крупного предприятия являются:
•	создание иерархии хранения учетных данных пользователей — работников пред-
приятия;
•	организация единого хранилища учетных записей;
•	управление учетными данными и обеспечение их целостности и непротиворечивости;
•	сокращение трудозатрат ИТ-специалистов и пользователей АСУ при управлении
учетными данными;
•	построение системы однократной регистрации, обеспечивающей подключение со-
трудников со своих рабочих мест к информационным ресурсам предприятия без
дополнительного предъявления учетных данных;
•	синхронизация учетных данных в целевых системах в рамках всей информацион-
ной инфраструктуры предприятия.
Гпава 2. Обеспечение безопасности доступа на основе рекомендаций и продуктов Oracle и Aladdin
В целях развития АСУ предприятия предусматривается совершенствование систем,
автоматизирующих отдельные бизнес-процессы, более полная интеграция всех автомати-
зированных систем в единую АСУ предприятия, а таюке создание на предприятии еди-
ной системы управления доступом и учетными данными в рамках ИТ-инфраструктуры,
которая объединяет:
•	LDAP-каталог Microsoft AD;
•	приложения Lotus Notes;
•	информационную систему на основе БД Oracle;
•	финансово-аналитическую систему Oracle Financial Analyzer;
•	LDAP-каталог Oracle Internet Directory;
•	комплекс бизнес-приложений Oracle E-Business Suite.
Кроме того, в ИТ-инфраструктуре крупного предприятия предусматриваются механиз-
мы защиты от несанкционированного доступа к корпоративным приложениям и инфор-
мационным ресурсам. Дополнительными требованиями к общему решению являются
надежная аутентификация пользователей, а также консолидация средств контроля доступа
для реализации полномасштабной политики информационной безопасности в рамках
всех подсистем предприятия.
Описание решения
Система управления доступом, учетными данными и однократной регистрацией
пользователей крупного предприятия строится на основе программных продуктов Oracle
Identity Manager и Oracle Enterprise Single Sign-On Suite (ESSO). Особенность ESSO
в гом, что этот программный комплекс для прозрачного подключения пользователей
к приложениям путем подстановки за них учетных данных работает и на рабочих стан-
циях пользователей.
На первом этапе создается единое хранилище учетных данных (репозиторий), объ-
единяющее учетные данные всех пользователей предприятия. Репозиторий управляется
с помощью Oracle Identity Manager (OIM) и механизмов согласования с информацион-
ными ресурсами. Учетные данные пользователей из различных источников (в нашем слу-
чае это MS AD. OID и Oracle DB) собираются в репозитории OIM, где создаются гло-
бальные учетные записи. Доверенным источником для таких записей может выступать
LDAP-каталог MS AD. Далее глобальным учетным записям ставятся в соответствие
учетные данные, которые необходимы для работы в прикладных системах
Для построения системы управления учетными данными сначала обследуются выбран-
ные прикладные системы (Microsoft Active Directory, Oracle E-Business Suite, приложения,
хранящие учетные данные в БД Oracle) с целью получения информации, необходимой
для проектирования архитектуры системы. На основании данных, полученных на этапе
обследования, разрабатывается общая архитектура системы и упорядочиваются группы
пользователей в рамках каждой из прикладных систем. Затем прикладная часть ПО
Oracle Identity Manager устанавливается на сервер управления. Для интеграции с выбран-
ными прикладными системами осуществляется необходимая доработка и установка адап-
теров. позволяющих организовать информационный обмен учетными данными в при-
кладных системах. После этого определяются требования по управлению учетными дан-
ными и выполняется настройка политик управления этими данными.
После завершения работ по созданию единого корпоративного хранилища учетных
данных пользователей и регистрации в LDAP-каталоге (MS AD) всех пользователей, кото-
рым разрешен доступ к корпоративным приложениям, к LDAP-каталогу подключается
администратор Oracle Enterprise Single Sign-On Suite. Он создает и публикует в LDAP-ка-
талоге шаблоны, обеспечивающие автоматический вход зарегистрированных пользовате-
ЧАСТЫ1. ПРАКТИКА
лей в приложения. Клиентская часть ESSO позволяет автоматически выгружать эти шаб-
лоны на рабочие станции, опознавать окна и формы приложений для ввода атрибутов
аутентификации и подставлять в эти формы данные пользователей.
Для организации сквозного управляемого процесса от заведения учетной записи
пользователя в MS AD до его прозрачного подключения к разрешенным корпоративным
приложениям требуется интеграция системы однократной регистрации ESSO с системой
распространения учетных данных пользователей (Oracle Identity Manager). Без такой ин-
теграции администраторы прикладных систем сами должны создавать учетные записи
пользователей в приложениях и каким-то образом сообщать им их учетные имена и па-
роли. Для интеграции выполняется установка адаптера 01М для ESSO, который позво-
ляет безопасно помещать в контейнер пользователя на LDAP-каталоге его учетные дан-
ные для подключения к целевым системам.
Итак, на первом этапе с помощью программных продуктов Oracle Identity Manager и
Oracle ESSO строится единая система управления учетными данными, к которой подключа-
ются Microsoft AD, Lotus Notes и одна информационная система, построенная на БД Oracle.
На втором этапе происходит увеличение количества пользователей системы, и су-
ществующая архитектура системы управления учетными данными расширяется за счет
программных комплексов 01D, OEBS, OFA.
Функциональная архитектура решения и потоки данных между информационными
системами представлены на рис. 2.21.
Для распространения однократно введенных учетных данных сотрудников в инфра-
структуру предприятия вводятся Oracle Identity Manager и коннекторы к различным ин-
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
формационным системам предприятия. Развертывание Oracle Enterprise SSO позволяет
осуществлять прозрачное подключение пользователей при доступе к различным инфор-
мационным системам предприятия на основе учетных данных приложений, которые
клиентская часть ESSO извлекает из контейнера пользователя в MS AD.
Управление учетными записями и правами на информационные системы
01М обладает функциональностью управления жизненным циклом учетных данных
пользователей информационной системы. Для создания, изменения учетной записи,
а также назначения, исключения прав на информационную систему предприятия либо
администратор, либо сам пользователь инициирует запрос на выполнение потока работ
в Web-интерфейсе 01М. Запрос проходит процесс согласования с уполномоченными лица-
ми и после успешного утверждения OIM через соответствующие коннекторы осуществ-
ляет необходимые действия в конечных информационных системах и репозитории.
Применение Oracle Enterprise SSO
Для передачи на рабочие станции шаблонов и учетных данных ESSO может исполь-
зовать LDAP-каталоги, базы данных и файловые хранилища. В данной архитектуре в ка-
честве репозитория ESSO (и точки синхронизации с клиентами) используется MS AD.
На рабочие места администраторов устанавливается ESSO Management Console, с по-
мощью которого администраторы настраивают пользовательские шаблоны для ESSO
Logon Manager, а также управляют в целом функциональностью ESSO.
На рабочие места пользователей устанавливаются ESSO Logon Manager, который в
автоматическом режиме скачивает из MS AD и применяет изменения, сделанные адми-
нистратором ESSO. Logon Manager без вмешательства пользователей распознает окно
запроса ввода имени и пароля (а также окно смены пароля) и автоматически вводит туда
соответствующие учетные данные для информационной системы. Детали работы модуля
и события подключения пользователя к приложениям аудируются.
Опциональный модуль ESSO Password Reset позволяет пользователям, забывшим
свой пароль к MS AD, сменить его на контроллере домена после успешного ответа на
несколько контрольных вопросов.
Oracle ESSO Provisioning Gateway позволяет заполнять пользовательский контейнер
репозитория ESSO теми же данными из 01М, которые получают конечные информа-
ционные системы. Пользователь может не знать свой пароль и учетное имя в информа-
ционной системе, но при этом иметь доступ к информационной системе через ESSO
Logon Manager.
Применение ESSO позволяет предоставлять доступ к информационным системам
предприятия на основе единственной аутентификации на Microsoft Windows. Опци-
онально ее можно заменить на более сильную аутентификацию с использованием, на-
пример, ключей или смарт-карт eToken компании Aladdin. Смена пароля или учетного
имени в приложениях происходит без участия и ведома пользователя. Парольная поли-
тика ведется в OIM, пароли распространяются в информационные системы через соот-
ветствующие коннекторы.
В OIM предусмотрена возможность создания исторических отчетов о предоставлен-
ных пользователям правах доступа к прикладным системам
Интеграция Oracle Identity Manager и Oracle ESSO в информационную систему пред-
приятия позволяет создать единую систему управления учетными данными пользовате-
лей и их правами в корпоративной информационной системе, развернуть систему од-
нократной регистрации, обеспечивать ведение общей политики паролей в информаци-
онной системе, а также аудит учетных данных и прав на ресурсы предприятия
ЧАСТЬ II ПРАКТИКА
2.1.4.2.	Организация единого доступа пользователей компании-оператора
мобильной связи к сервисам, предоставляемым через web,
на основе продуктов Oracle Virtual Directory и Oracle Access Manager
Постановка задачи
Компания — оператор мобильной связи предлагает своим клиентам различные Wap-cep-
висы и услуги, предоставляемые через Web, например, сервис самообслуживания (конт-
роль счетов, смена тарифов), сервис загрузки контента, поисковый сервис и т. д. Для
обслуживания пользователей (абонентов) в компании используется несколько Web-при-
ложений, при этом часть их них принадлежит партнерам компании. Большинство при-
ложений имеет собственную инфраструктуру:
•	различные технологии формирования интерфейса пользователя (php, .NET);
•	разные серверы приложений (MS IIS, Apache, SunJavaWS, J Boss);
•	разные серверы баз данных (Oracle, MS SQL, MySQL, SunJavaDS).
Каждое приложение имеет собственных внутренних пользователей, для каждого из
которых создается учетная запись. Если пользователь работает с несколькими приложе-
ниями, то для него создается несколько учетных записей. Учетные записи абонентов хра-
нятся в базах данных приложений, т. е. каждое приложение располагает собственным,
уникальным репозиторием пользователей (рис. 2.22). Все приложения оснащены инст-
рументами управления учетными записями и правами доступа пользователей. Работа
каждого приложения контролируется администраторами.
Цели и задачи решения
В связи с диверсификацией бизнеса, территориальным расширением и развитием де-
ловых отношений с партнерскими организациями, предоставляющими услуги клиентам
оператора мобильной связи, компании необходимо обеспечить качество, гибкость и
Рис. 2.22. Первоначальная организация доступ» пользователей к сервисам, предоставляемым через Web
216
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
надежность сервисов и предложить своим абонентам и партнерам ряд дополнительных
услуг для повышения безопасности и удобства работы с Web-приложениями.
Для организации единого доступа пользователей к сервисам, предоставляемым ком-
панией через Web, необходимо создать единую базу учетных данных пользователей, ми-
нимально изменяя приложения и среду, в которой работают пользователи, и обеспечить
плавный переход от существующих разрозненных систем аутентификации к системе од-
нократной регистрации пользователей при работе со всеми Web-приложениями, консо-
лидированными на портале (Web Single Sign On — WSSO).
Описание решения
Предлагается построить систему WSSO на базе программных продуктов Oracle Virtual
Directory (OVD) и Oracle Access Manager (OAM), используя промышленное решение компа-
нии Oracle по консолидации учетных данных, расположенных в хранилищах различных
типов, без их синхронизации. Oracle Access Manager может работать с широким набором
LDAP-каталогов, серверов приложений, Web-серверов, серверов порталов и прикладных
приложений, поставляемых ведущими производителями программного обеспечения. Oracle
Access Manager предоставляет набор сервисов централизованного управления учетными
данными пользователей и их доступом к различным информационным ресурсам компании,
в том числе Web-ресурсам и приложениям. Oracle Access Manager обладает удобными сред-
ствами работы с различными группами пользователей, имеет встроенный механизм workflow
для управления аутентификацией, авторизацией и созданием групп, развитые средства
определения политик аутентификации, авторизации и аудита. Oracle Access Manager по-
зволяет обеспечить однократную регистрацию пользователей (SSO) при работе с при-
ложениями в архитектуре клиент—сервер
Задача построения единого пространства для поиска учетных данных решается с по-
мощью Oracle Virtual Directory (OVD), который обеспечивает представление существую-
щих учетных данных пользователей в унифицированном виде (в форматах LDAP или XML)
без синхронизации или перемещения данных из исходных мест хранения (баз данных и
других источников).
Oracle Virtual Directory состоит из интерфейса LDAP, Web-шлюза, механизма Virtual
Directory и адаптеров (рис. 2.23). Гибкий базовый механизм позволяет системным ад-
министраторам задавать сложные правила преобразования данных из формата хранения
в исходном репозитории в форматы, необходимые различным клиентским приложениям.
Если адаптер настроен для доступа к одному или нескольким источникам информации,
запросы к различным частям иерархического дерева единого каталога автоматически пе-
ренаправляются серверам содержащим достоверную информацию. Каждый источник
Рис. 2.23. Oracle Virtual Directory
ЧАСТЫ1 ПРАКТИКА
можно настроить таким образом, чтобы поддерживался необходимый уровень его до-
ступности и безопасности.
Внутри виртуального каталога в дереве данных о каталоге (Directory Information Tree —
DIT) для каждого приложения создается своя ветвь пользователей, в результате возникает
единое пространство для поиска пользователей. Именно на основе виртуального каталога
Рис. 2.24. Приведение всех ID-данных к одному формату и определение атрибутов для аутентификации
Рис. 2.25. Внешняя аутентификация пользователей приложениями по контексту http- заголовков
Гпава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Ресурсы, защищенные
Oracle Access Manager
Apach
веб сервер
Процесс аутентификации и авторизации
пользователей в Oracle Access Manager.
Oracle Virtual Directory
Oracle
Virtual
Directory
Oracle
Access
Server
IIS & ASP
Apps
Коннекторы
Oracle Virtual Directory
К каждому источнику
учетных записей
LDAP каталог
для хранения политик
доступа к приложениям
Firewall*-----►
DMZ *---------► Firewall
Базы данных приложений
с учетными записями пользователей
Рис. 2.26. Архитектура решения
в дальнейшем строится система проверки доступа пользователей к Web-приложениям
Схема реализации системы WSSO показана на рис. 2.24 и 2.25.
На первом этапе выполняется подключение Oracle Virtual Directory к различным храни-
лищам идентификационных данных с помощью стандартных адаптеров (см. рис. 2.24). Затем
происходит связывание учетных данных, которые описывают одного и того же пользова-
теля в разных системах, и формирование общего списка аутентификационных атрибутов.
На втором этапе устанавливается режим внешней аутентификации Web-приложений
и с помощью специализированного шлюза Oracle Access Manager всем приложениям пе-
редается общий список аутентификационных атрибутов в http-заголовке сессии клиента
(см. рис. 2.25). В результате обеспечивается однократная регистрация пользователей:
пройдя аутентификацию в одном из Web-приложений, пользователи получают доступ ко
всем приложениям.
Oracle Access Manager использует представление, полученное в Oracle Virtual Directory,
в качестве основного источника информации о пользователях и их правах доступа Каждое
Web-приложение защищается шлюзом (модулем, входящим в составе ОАМ). Все обращения
пользователей к приложениям контролируются этими шлюзами где с помощью сервера
Access Server выполняются аутентификация, авторизация и аудит действий пользователей.
Процесс аутентификации и авторизации пользователей в системе представлен на рис. 2.26.
Ниже приведен алгоритм работы совместной работы приложений, Oracle Virtual Directory
и Oracle Access Manager:
1.	Пользователь запрашивает необходимое ему Web-приложение.
2.	Запрос перенаправляется к Oracle Access Manager, который выполняет аутентифи-
кацию и авторизацию пользователя в Oracle Virtual Directory, а соответственно и в источ-
никах учетной информации (например, в таблицах БД Oracle или MySQL)
3.	Доступ к Web-приложению разрешается в случае успешной аутентификации и авто-
ризации пользователя.
4.	В ответ на шпрос пользователя возвращается контент приложения и текстовый файл
SSO cookie, который необходим для идентификации пользователя при работе с другими
приложениями (WSSO).
ЧАСТЫ1. ПРАКТИКА
Решение технических проблем
Аутентификация в обход стандартных механизмов
Решение Oracle предусматривает, что Web-серверы переводятся в режим внешней
аутентификации, т. е. приложения считывают учетные записи из http-заголовков, а не
проверяют правильность пары «имя—пароль» в своем хранилище. Эта работа возлага-
ется на виртуальный каталог.
Аутентификация особых типов клиентов
В мобильной связи возможна аутентификация устройств по MSISDN при доступе
абонента через сеть компании — оператора мобильной связи. В этом случае решение
можно дополнить хранилищем атрибутов на RADIUS-сервере.
Для доступа к системе делегированных администраторов из филиалов и партнерских
организаций решение Oracle может быть дополнено системами сильной аутентифика-
циии с использованием жетонов/смарт-карт.
Первичная авторизация клиентов
После аутентификации пользователя одним из описанных ранее способов может
быть сделан запрос в биллинговую систему для получения его статуса. В зависимости от
результата (например, пользователь заблокирован) могут быть введены ограничения на
доступ к определенным сервисам
Отказоустойчивость системы
Для обеспечения работы системы в целом необходимо обеспечить отказоустойчи-
вость модулей «сервер доступа» и «виртуальный каталог» Архитектура Oracle Access
Manager позволяет осуществлять баллансировку нагрузки между несколькими серверами
доступа, каждый из которых может обращаться к нескольким каталогам.
Мониторинг системы
Поскольку модули системы могут быть расположены далеко друг от друга, необхо-
димо, по крайней мере, контролировать их доступность. Для этого можно использовать
встроенные агенты SNMP-мониторинга Oracle Access Manager. В случае необходимости
контролировать производительность различных компонентов системы и отслеживать
уровни сервиса решение может быть дополнено подключаемым модулем для Oracle
Enterprise Manager, который называется Identity Management Pack.
2.1.4.3.	Создание единой службы управления доступом и учетными данными
пользователей в государственной организации федерального уровня
Постановка задачи
Автоматизированная система управления (АСУ) крупной государственной организа-
ции федерального уровня представляет собой распределенную по территории Россий-
ской Федерации информационно-технологическую систему, которая характеризуется
высокой степенью сложности, широким спектром решаемых подсистемами прикладных
задач и разнообразием парка оборудования и базового программного обеспечения.
Клиентами информационных ресурсов организации федерального уровня являются
пользователи, подключающиеся через специализированное клиентское ПО в удаленных
отделениях организации. Информационные ресурсы, к которым они получают доступ. —
специализированное серверное ПО, работающее с данными, хранящимися в базе данных
Oracle DB. Для обеспечения масштабности и отказоустойчивости системы на региональном
Гпава 2. Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
уровне установлены серверы промежуточного слоя, которые являются точками контакта
для клиентов, где необходимо осуществлять аутентификацию и авторизацию клиентов.
Аутентификация и авторизация выполняются на основе цифровых сертификатов, вы-
даваемых головным Удостоверяющим Центром. Авторизованные клиенты получают до-
ступ к информационным ресурсам и в зависимости от предоставленных им прав могут
читать или изменять хранящуюся в базе данных информацию. Подключение клиентов
проходит в защищенном режиме с помощью шифрования.
Цели и задачи решения
Централизованная система управления доступом является одной из ключевых служб,
штатная работа которой позволяет решить широкий спектр задач обеспечения информа-
ционной безопасности организации. Необходимость предоставлять авторизованным поль-
зователям право изменять данные организации федерального уровня и в то же время
обеспечивать защиту от несанкционированного доступа — наиболее очевидные из них.
Учитывая ценность конфиденциальных данных организации, решение должно предус-
матривать механизмы, позволяющие быстро реагировать на изменяющиеся требования
со стороны пользователей и владельцев информации.
Права пользователей на доступ к ресурсам наиболее удобно определять в LDAP-ка-
талогах, предоставляющих универсальный способ хранения и обработки регистрационных
данных пользователей информационных систем, учетных данных субъектов информаци-
онно-вычислительных процессов, компонентов инфраструктуры и т. д. Наличие LDAP-ка-
талогов позволяет целиком вынести за рамки приложений все. что касается обработки
учетных данных, и предоставлять эту обработку приложениям по стандартизованному
LDAP-протоколу как общедоступный сервис. Следующие задачи — аутентификация поль-
зователей, анализ их запросов на доступ к ресурсам и собственно предоставление доступа
к ресурсам — требуют обращений к LDAP-каталогам и формируют дополнительные тре-
бования к общему решению по управлению доступом.
Необходимо также иметь в виду, что в ряде подсистем идентификационные данные
пользователей могут храниться не в LDAP-каталогах, а непосредственно в базах данных,
с которыми работают корпоративные приложения, или в доменах Microsoft Windows NT.
Все эти хранилища учетных данных нужно интегрировать. Однако простое хранение
идентификационных данных пользователей в LDAP-каталогах и их использование в ло-
кальных приложениях не являются комплексным решением, необходима единая служба
управления LDAP-каталогами и идентификационными данными пользователей
Должны быть предусмотрены механизмы интеграции со средствами сильной аутенти-
фикации, территориальная распределенность и достаточное количество точек аутентифика-
ции, наличие интерфейсов администрирования (в том числе — делегированного) и само-
обслуживания. проверка политик (например, диапазонов IP-адресов), поддержка федера-
тивного доступа с установлением доверительных отношений между хранилищами учетных
данных нескольких организаций, аудит действий пользователей организации и т. п.
Основными целями создания единой службы управления доступом АСУ организации
федерального уровня являются:
•	консолидация средств контроля доступа, аутентификации и аудита для реализации
полномасштабной политики информационной безопасности в рамках всех под-
систем организации, организация единой точки входа для тех подсистем, где это
необходимо;
•	автоматизация процессов регистрации учетных записей клиентов АСУ организа-
ции, назначения им прав пользования ресурсами АСУ организации, выдачи и ан-
нулирования сертификатов;
ЧАСТЬ II. ПРАКТИКА
•	максимально возможная централизация решения с учетом специфики территориаль-
ной распределенности организации и необходимости обеспечивать точки доступа для
представителей других государственных структур по всей Российской Федерации-
•	повторное использование компонентов решения для обеспечения федеративного
доступа.
Важнейшими задачами являются создание надежной, гибкой и открытой для контроля
соответствующими органами инфраструктуры управления доступом, обеспечивающей
бесперебойное функционирование АСУ организации федерального уровня и ее развитие
в перспективе.
Описание решения
Концепция защищенного доступа к информации (авторизации, аутентификации и
аудита) может быть в полной мере реализована только в системе, где обеспечены единство
и унификация средств управления отдельными компонентами информационной инф-
раструктуры. При проектировании подобных систем необходимо применять модульный
принцип, позволяющий интегрировать и повторно использовать при необходимости от-
дельные компоненты. Решение задачи создания единой службы управления доступом —
это, прежде всего, построение правильной архитектуры, позволяющей логически выде-
лить и сгруппировать специализированные модули. Типовая архитектура развертывания
единой службы управления доступом, обычно бывает представлена пятью уровнями:
•	службы каталогов;
•	репозитория (хранилища) политик;
•	принятия решений (слоем приложений):
•	применения политик;
•	интеграции (слоем программных интерфейсов).
Для объединения существующих подсистем в рамках АСУ организации федерального
уровня используется интегрированный набор средств управления учетными данными Oracle
Identity & Access Management Suite, компоненты которого функционально соответствуют
всем пяти уровням. Создание единой службы управления доступом АСУ организации
федерального уровня осуществляется на базе программных продуктов Oracle Access Manager
и Oracle Identity Federation. В случае необходимости синхронизации учетных данных эти
продукты могут быть дополнены Oracle Identity Manager.
На рис. 2.27 представлена схема возможной интеграции служб управления доступом
и учетными данными при наличии нескольких хранилищ учетных данных.
Управление Web-доступом		Службы аутентификации		Единый вход
				
		Службы федеративного доступа		
Управление учетными записями		Доставка идентификационных данных		Управление паролями
Службы синхрони «алии идентификационных .а иных				
		Службы каталогов		
Рис. 2.27. Схема интеграции служб управления доступом и учетными данными
Гпава 2. Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Рис. 2.28. Схема взаимодействия компонентов единой службы управления доступом
Рис. 2.28 иллюстрирует схему взаимодействия компонентов единой службы управле-
ния доступом. Подобная схема позволяет обеспечивать гибкость при централизованном
управлении доступом территориально распределенных клиентов к информационным
ресурсам организации.
Архитектурное решение
Архитектурное решение, которое может быть внедрено в ИТ-инфраструктуре крупной
организации федерального уровня при создании полномасштабной службы управления
доступом, представлено в виде схемы на рис. 2.29.
Пилотный проект
Предлагаемое решение целесообразно внедрять в рамках пилотного проекта на стенде,
воспроизводящем топологию работы АСУ: «клиент — сервер промежуточного слоя —
сервер приложений — база данных». На этапе пилотного проекта необходимо продемон-
стрировать жизнеспособность решения и оценить ресурсы, необходимые для полно-
масштабного внедрения
В первую очередь надо обеспечить интеграцию специализированного приложения для
доступа удаленных клиентов к информационным ресурсам организации федерального
уровня и программного продукта Oracle Access Manager. Эта интеграция позволит пере-
ложить решение многих проблем обеспечения безопасности с прикладной системы на
централизованную систему управления доступом.
Интеграцию целесообразно осуществлять с использованием интерфейсов, на которых
написано приложение, а для подключения к Oracle Access Server использовать AccessGates
(блок «1» на рис. 2.29). AccessGates являются теми самыми шлюзами, которые перехваты-
вают запросы клиентов к ресурсам и проводят их авторизацию. После этого можно развер-
нуть основную инфраструктуру (Oracle Access Server, Oracle Identity Server и Oracle Access
Manager — блок «2» на рис. 2.29) и связать ее со службой каталогов (блок «3» на рис. 2.29).
3
О
О
s £
o
О
5
Z
o
g
o
*
5
о
LDAPS
Службы каталогов
LDAP - каталоги
хранилище политик
LDAPS
LDAPS
LDAPS
-LDAP!
LDAPS-
<-LDAP!
LDAPS
2
Oracle Access
Manager
Web -интерфейс
управления
политиками
ТСР/1Р(обновление политик)
Oracle Access
Server
Ядро
аутентификации /
авторизации/зудита
TCP/IP(Cache Updates)
Oracle Identity
Server
Сервис
администрирования
идентификационных
данных
Oracle Federation
Server
Сервис
федерирования
идентификационных
данных
Реляционные
базы данных
(Oracle DB,SQL
Server , IBM DB2)
ODBC
TCP/IP
SSL
TCP/IP:
H SSL ~
TCP/IP
(API
доступа)
SOAP/HTTP
Web Gate
Точка применения
политик
Custom Access
Gate
Точка применения
политик
Oracle
Federation
Proxy
Интерфейс
сервисов
федерирования
HTTP
Java , С/
C++, Net
SAML
Liberty
Хранилище политик Слои принятия решения Слой применения политик Интеграция/интерфейс
Рис. 2.29. Модульная схема развертывания единой службы управления доступом
ЧАСТЬ II. ПРАКТИКА
Глава 2 Обеспечение безопасности доступа на основе рекомендации и продуктов Oracle и Aladdin
Первый >man проекта — создание службы управления доступом в одном регионе
На этом этапе на передним план выступают вопросы оптимизации; в частности —
обеспечения отказоустойчивости системы и минимизации расходов. Схема развертывания
предполагает установку точек доступа AccessGates во всех региональных центрах, а серве-
ров Access Server — в самых крупных из них. Точки доступа AccessGates настраиваются на
последовательный опрос списка из ближайших серверов Access Server и при отсутствии
у какого-нибудь сервера Access Server соединения с другими компонентами Oracle Identity &
Access Management Suite или co службой каталогов переключаются на следующий.
Также на этом этапе оценивается, стоит ли использовать стандартную службу ката-
логов (Oracle Internet Directory или MS Active Directory) или перенести их представление
на базе Oracle Virtual Directory на уровень крупных региональных центров (см. блок «3»
на рис. 2.29).
Еще одна задача на этом этапе — настройка аудита; точнее — выбор наиболее актуальных
типов отчетов, предоставляемых Oracle Access Manager, и создание собственных типов
отчетов.
Второй этап проекта — построение службы управления доступом во всех регионах
В связи с ожидаемым резким ростом числа пользователей системы на этом этапе особое
внимание следует уделить административным задачам, которые неизбежно возникнут
в процессе внедрения. Совместное применение регламентов и инструментов управления
действиями пользователей, которые предоставляет Oracle Access Manager, позволяет ре-
шить эти задачи.
На этом этапе можно внедрить дополнительные средства — средства самообслужи-
вания, которые позволят запускать потоки работ для автоматизированного создания
учетных записей и сертификатов пользователей и предоставления им прав на ресурсы.
При этом возможны варианты с оповещением владельцев ресурсов или делегированных
администраторов. Кроме того, необходимо настроить систему мониторинга, отслеживаю-
щую состояние территориально распределенных компонентов Oracle Access Manager.
Использование поставляемого файла спецификации MIB позволяет дистанционно по-
лучить детальную информацию и быстро локализовать неисправности.
Третий этап проекта — обеспечение федеративного доступа
При построении системы доступа других государственных организаций к ресурсам
организации федерального уровня логично повторно использовать готовую инфраструк-
туру, созданную на предыдущих этапах. Oracle Identity Federation позволяет использо-
вать на стороне поставщика услуг (которые будет оказывать организация федерального
уровня в виде Web-доступа к своим данным) Oracle Access Manager. Решение обеспечи-
вает безопасную передачу результата успешной аутентификации пользователей на сто-
роне потребителя услуг и его прозрачное подключение к партнерским Web-сервисам
с заранее предопределенными правами.
Также ранее созданная инфрастуктура Oracle Access Manager позволит пользователям
АСУ организации федерального уровня через Oracle Identity Federation в будущем полу-
чать доступ к Web-сервисам других государственных организации. Для этого они могут
использовать те же сертификаты, но точками доступа будут не требующие разработки
AccessGates. а готовые WebGates (см блок «5» на рис. 2.29).
Предложенное архитектурное решение может служить стандартом при построении
систем управления доступом для организаций федерального масштаба.
225
Глава 3
ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ
ДОСТУПА К ДАННЫМ И ПРИЛОЖЕНИЯМ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ОРГАНИЗАЦИИ
НА ОСНОВЕ ПРОДУКТОВ
КОМПАНИИ CITRIX SYSTEMS
3.1.	Описание продуктов компании Citrix Systems
Развитие информационных технологий привело к тому, что теперь обыкновенные поль-
зователи могут получить доступ к своим данным и приложениям, находясь вне офиса. И для
получения доступа нет необходимости обладать какими-либо «тайными знаниями», эта
возможность сегодня встраивается в современные операционные системы Естественно,
рассматривая возможность предоставления сотрудникам такого доступа, необходимо осо-
бенно тщательно проработать вопросы обеспечения безопасности этого доступа. С одной
стороны, консолидация данных и приложений в Дата-центре повышает безопасность, так
как нам достаточно обеспечить их защиту (физическую, электронную и др.) всего лишь
в одном или очень небольшом количестве мест. Дата-центр — Центр Обработки Данных
(ЦОД) — это специализированная площадка, на которой организация размешает сервер-
ное и телекоммуникационное оборудование. Данная площадка (здание) обеспечивает все
необходимые требования по электропитанию, охлаждению, физической безопасности.
К данной площадке подводятся используемые организацией каналы связи. Крупные ор-
ганизации обычно располагают своим собственным ЦОД, средние и мелкие могут арен-
довать такие помещения у специализированных организаций (обычно провайдеров).
Но, с другой стороны, пользователи которые получают доступ к этим данным и системам
часто находятся не в «мирном» офисе, подключенном к Дата-центру своими защищенными
каналами, оснащенные системами обнаружения и предотвращения атак, антивирусны-
ми средствами и межсетевыми экранами, а используют любое доступное им устройство
(ноутбук, Интернет-киоск, смартфон) и доступные каналы связи, где никто не гарантирует
отсутствие лиц, которые могут быть заинтересованы в незаконном получении доступа
к ценной информации. Задача архитектора таких систем, с одной стороны, обеспечить
максимальную защищенность а с другой стороны, не усложнить пользователю работу
настолько, что последний просто откажется использовать данную возможность.
Компания Citrix Systems разработала систему продуктов, которые обеспечивают вы
полнение приведенных выше требований.
Рассмотрим сначала продукты компании Citrix Systems в целом, а затем более подробно
остановимся на некоторых из них. Чтобы нам было проще описывать всю систему, об-
ратимся к рис. 3.1.
С левой стороны мы видим пользователей информационных систем, а справа распо-
лагается Дата-центр, где установлены корпоративные приложения
Итак, начнем с Дата-центра
Citrix XenServer — программный продукт, предназначенный для виртуализации опе-
рационных систем. Виртуализация — технология или набор технологии, позволяющий
сделать вычислительные ресурсы автономными и независимыми от окружающих ком-
понентов. Особенностью данного продукта является использование гипервизора Хеп. под
226
Гпава 3. Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
Citrix
r i роизводител ьности
По ib зо вате л и
 WAN Scaler™
Ускорение доставки
приложений
в филиалы
Citrix
Xen Desktop™
Доставка ПК
Windows
Citrix ХепАрргм
Доставка Windows-
приложений
Приложения
Рис. 3.1. Инфраструктура доставки приложении компании Citrix Systems
держивающего паравиртуализацию. Гипервизор — микроОС, которая предоставляет сер-
вис виртуальных машин операционным системам, установленным поверх нее, обеспечи-
вая изоляцию гостевых ОС друг от друга, защиту, безопасность и эмуляцию определенных
компонентов в случае необходимости, а также разделение и управление ресурсов
хост-машины. Паравиртуализация — метод виртуализации, при котором операционная
система виртуальной машины «знает» о том. что она работает в виртуальной среде Это
достигается за счет модификации виртуализированной операционной системы.
В поставку данного ПО в зависимости от редакции может входить Citrix Provisioning
Server for Data Center.
Citrix Provisioning Server — программное обеспечение, позволяющее осуществлять
потоковую доставку операционных систем (серверных или клиентских) по сети, в том чис-
ле на компьютеры, не имеющие жестких дисков. Здесь необходимо отметить, что в дан-
ном случае вся вычислительная работа выполняется на том устройстве, куда происхо-
дила потоковая доставка.
Citrix NetScaler — аппаратный комплекс, обеспечивающий доставку Web-приложений
конечному пользователю. В этот комплекс заложены механизмы, обеспечивающие: муль-
типлексирование запросов, сжатие информации и ее кеширование, перенаправление за-
просов. балансировку нагрузки, анализ трафика как в направлении Web-сервера, так и
в обратном, защита трафика и логики приложений с помощью межсетевого экрана при-
ложений
Citrix ХепАрр — программное обеспечение, отвечающее за доставку пользователям
приложении Windows. Пользователь получает на используемое устройство, на котором
запущен клиент Citrix Application, изменения экрана, а на сервер, в свою очередь, пере-
даются коды нажатых на клавиатуре клавиш и изменения позиций курсора. Приложение
в данном случае выполняется на стороне сервера и использует его вычислительные ре-
сурсы. Таким образом, мы получаем независимость от операционной системы и аппа-
ратного обеспечения на стороне клиента, так как основная функция клиента — только
отображение информации.
Citrix XenDesktop — система доставки персональных компьютеров из Дата-центра на
устройство пользователя. Под доставкой персонального компьютера понимается достав-
ка графического интерфейса клиентской операционной системы. При этом персональный
компьютер, находящийся в Дата-центре, может представлять собой виртуальную машину
или аппаратный комплекс, например блейд-ПК. Блеид-ПК — разновидность персональ-
ного компьютера, представляющего собой модуль, содержащий в себе процессор, память.
227
ЧАСТЬ II. ПРАКТИКА
материнскую плату и устанавливаемый в специализированное шасси. Жесткий диск ц
видео подсистема могут быть опциональными. Все операции ввода-вывода осуществля-
ются через шасси, которое также содержит в себе модули управления. Доступ пользо-
вателей к таким ПК осуществляется только по сети.
Необходимо отметить, что в этом продукте используются технологии, заложенные в Citrix
ХепАрр. и в зависимости от редакции могут быть доступны дополнительные компоненты.
Редакция ПО — это разновидность ПО от одного производителя, имеющая одинаковый
базовый функционал и отличающаяся друг от друга дополнительным функционалом или
дополнительными продуктами, поставляющимися в рамках той или иной редакции
Citrix Access Gateway — аппаратный комплекс, обеспечивающий безопасный доступ
пользователей к своим данным и приложениям. Предоставляет SSL-VPN-доступ, основным
отличием от других решений является наличие технологии SmartAccess. Данная техно-
логия позволяет контролировать доступ, основываясь не только на аутентификации, но
также и на параметрах устройства, с которого осуществляется доступ.
Все перечисленные компоненты устанавливаются в Дата-центре, а сейчас мы перейдем
к тем программным и аппаратным комплексам, которые могут также быть установлены
и на стороне клиента, на его устройстве доступа или находиться в его удаленном офисе.
Citrix WANScaler — программно-аппаратный комплекс, обеспечивающий оптимиза-
цию использования WAN-каналов. Ускорение работы достигается за счет использования
технологий: сжатия, битового кеширования, оптимизации работы некоторых протоко-
лов, присвоения приоритета различным видам трафика. Это решение — симметричное,
т. е. для своей работы требует установки двух аппаратных комплексов, по одному с каждой
стороны WAN-канала или установки аппаратной части с одной стороны, и программной
части с другой стороны.
Citrix EdgSight — группа программных продуктов, осуществляющих мониторинг про-
изводительности клиентских систем или терминальных сессий. Также существует специ-
альная версия EdgeSight for LoadTesting для проведения нагрузочного тестирования.
На данной схеме указаны не все продукты, поэтому еще хочется отметить программу
Citrix Password Manager — решение Single Sign-On в масштабе всего предприятия. Данный
продукт осуществляет управление паролями для Web, Windows или Хост-приложений,
а также подстановку учетных записей для этих приложений в соответствующие диало-
говые окна.
В данной книге мы будем рассматривать только программное обеспечение для до-
ставки Windows-приложений — Citrix ХепАрр.
3.2.	Компоненты систем,
построенных с использованием ХепАрр
Прежде чем начать обсуждение процесса аутентификации и авторизации в системах,
построенных с использованием ХепАрр. необходимо остановиться на компонентах, из
которых эти системы строятся.
Существует несколько версий и редакций программного обеспечения Citrix Systems,
с помощью которого строятся системы удаленного доступа.
1.	Citrix Access Essentials 2.0 — версия для малого бизнеса, с ограничением в макси-
мальное количеС1ВО пользователей — 75.
2.	Citrix Presentation Server 4.0 for UNIX — версия для заказчиков, использующих
IBM AIX, HP-UNIX или Solaris. Эту версию в данной книге мы не рассматриваем.
228
Глава 3. Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
3.	Citrix XenApp Server 4.5 — версия, работающая под ОС Microsoft Windows Server 2003
(В середине 2008 г. планируется выпуск новой версии, которая будет работать, используя
новую версию ОС Microsoft Windows 2008, представленную в феврале 2008 г.).
Версия Citrix XenApp Server 4.5 существует в трех редакциях — Advanced, Enterprise
и Platinum. Для процессов аутентификации и авторизации они не различаются, так же
как не различаются Citrix Presentation Server и Citrix Access Essentials
Итак, в системе присутствуют следующие компоненты
1.	Citrix Secure Gateway — предназначен для обеспечения шифрования SSL/TLS между
безопасным сервером-шлюзом и клиентским ПО с поддержкой SSL, а также для шиф-
рования данных http-трафика, передаваемого между веб-сервером и веб-браузером.
2.	Citrix Web Interface — веб-сервер, предназначенный для представления приложений
и данных пользователю информационной системы в виде веб-страницы. Возможна ин-
теграция с портальными решениями, такими как IBM WebSphere и Microsoft SharePoint.
Портал — веб-сайт (чаще внутренний) организации, тесно интегрированный с корпоратив-
ными информационными системами. Обычно имеют модульную структуру, а также возмож-
ность персональной настройки для конкретного пользователя или группы пользователей.
3.	Citrix License Server — обрабатывает запросы на установление соединения с фермой
серверов XenApp Server и предоставляет необходимую для работы пользователя лицен-
зию. Ферма — в терминологии Citrix Systems группа серверов XenApp.
4.	Secure Ticket Authority (STA) — XML Web служба, которая обменивается инфор-
мацией с сервером XenApp с помощью случайно сгенерированных билетов. Использу-
ется для контроля доступа к серверу Citrix Secure Gateway.
5.	Citrix XenApp Server — предоставляет пользователю возможность выполнения
«опубликованных» на сервере или группе серверов приложений.
6.	Citrix XenApp Client — программное обеспечение, предназначенное для подклю-
чения и использования ресурсов Citrix XenApp Server.
На приведенной ниже схеме (рис. 3.2) можно увидеть одну из возможных конфигу-
рации использования Citrix XenApp Server.
Для проверки подлинности и прав доступа пользователей программное обеспечение
Citrix Systems активно использует возможности служб каталога, совместно с которыми
Citrix XenApp
STA
XML Service
License
Server
Контроллер
домена
Рис. 3.2. Примерная схема подключения пользователя к Citrix XenApp
229
ЧАСТЫ1 ПРАКТИКА
это ПО работает. Служба каталогов — иерархическая служба, содержащая в себе инфор-
мацию об объектах организации и их свойствах. Так, Citrix ХепАрр поддерживает работу
при использовании в организации как службы каталога Active Directory компании
Microsoft, так и Novell Directory Services (NDS).
Аутентификация
Аутентификация в среде Citrix ХепАрр осуществляется с помощью следующих меха-
низмов:
•	пароли;
•	смарт-карты;
•	токены;
•	биометрические решения
Некоторые из этих решений могут потребовать дополнительные программно-аппа-
ратные комплексы, которые приобретаются у других поставщиков.
Вышеперечисленные механизмы для своей работы используют один из следующих
протоколов аутентификации:
•	Windows NT IAN Manager (NTLM);
•	Kerberos
Каждый из рассматриваемых механизмов обладает как достоинствами, так и недос-
татками. Для выбора механизма аутентификации при внедрении решения необходимо
учитывать множество факторов, таких, например, как цена решения, возможность под-
ключения дополнительного оборудования к клиентским устройствам, необходимость
обучения пользователей и т. д. Заметим также, что смарт-карты, токены и средства био-
метрии предоставляются сторонними поставщиками и должны иметь явную поддержку
от Citrix Systems или поставщика решения для функционирования в среде Citrix. Некото-
рые из этих решений могут потребовать дополнительных аппаратных или программных
компонентов или не поддерживаться в среде Citrix Поэтому перед выбором решения не-
обходимо учитывать эти факторы и проконсультироваться с поставщиком решения.
Протоколы аутентификации WINDOWS NT LAN Manager (NTLM)
NTLM (Windows NT LAN Manager — протокол типа отклик—отзыв) — сетевой протокол
аутентификации. Он встроен в Windows и является методом аутентификации по умол-
чанию между хост-машинами Windows в сети. Этот протокол позволяет пользователям
аутентифицироваться на удаленных машинах. NTLM может быть использован для аутен-
тификации напрямую между двумя узлами в сети или с помощью контроллера домена
как доверенного источника.
Оригинальный протокол NTLM работал поверх протокола Server Message Block (SMB).
ПО Citrix использующее NTLM для аутентификации применяет более новый стандарт, ко-
торый туннелирует аутентификацию NTLM с использованием протокола Hypertext
Transfer Protocol (HTTP).
Аутентификация Kerberos
Citrix ХепАрр расширяет использование протокола Kerberos. После того, как пользо-
ватель входит в систему на клиентском устройстве, он может подключиться к Citrix ХепАрр
без необходимости проходить снова аутентификацию. Пароль пользователя не пере-
дается на Citrix ХепАрр, вместо этого происходит обмен токенами аутентификации со-
гласно Generic Security Services API (GSSAP1) стандартизованного в Internet RFC 1509
230
Гпава 3 Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
)тот аутентификационный обмен происходит внутри виртуальных каналов протокола
Citrix ICA и не требует никаких дополнительных протоколов или портов. Также нужно
отметить, что этот аутентификационный обмен не зависит от метода входа в систему, и
поэтому может быть использован совместно с паролями, смарт-картами или биометри-
ческими методами. Для использования аутентификации Kerberos в Citrix ХепАрр клиент
и сервер должны быть правильно сконфигурированы При необходимости Групповые
Политики Службы Каталога Microsoft могут быть также использованы для выборочного
отключения аутентификации Kerberos для определенных пользователей или серверов.
Безопасные коммуникации
Коммуникации между продуктами Citrix должны быть аутентифицированы и иметь
защиту целостности. Одним из вариантов обеспечения безопасности коммуникаций яв-
ляется использование технологий шифрования, таких как SSL, Transport Layer Security
( TLS) или IPSec. В ряде решений эти технологии безопасных коммуникаций усиливают
безопасность продуктов Citrix. В других решениях безопасные коммуникации являются
обязательной составляющей для функционирования продуктов Citrix.
SSL/TLS
SSL и TLS — стандартные протоколы для обеспечения безопасных коммуникации.
Эти протоколы используют сертификаты для аутентификации вовлеченных в процесс
передачи участников и договариваются о ключах сессии, которые будут использованы
дзя шифрования трафика между участниками. SSL/TLS также использует клиентские
сертификаты для взаимной аутентифкации SSL/TLS может инкапсулировать и шифровать
трафик других протоколов, таких, например, как HTTP, и защищать их от разглашения
и фальсификации.
HTTPS
Использование безопасного HTTP (HTTPS) показывает, что SSL/TLS используется
для шифрования трафика HTTP.
IPSec
IPSec — протокол для шифрования и/или аутентификации IP-пакетов. IPSec имеет
два режима: туннельный и транспортный С точки зрения продуктов Citrix интерес пред-
ставляет транспортный режим, который обеспечивает сквозную безопасность для всего
IP-трафика, пересылаемого между двумя узлами. Так же как и SSL/TLS, IPsec требует
наличия на каждом узле ключа шифрования, который используется для установления и
шифрования туннеля. IPSec рекомендуется использовать, когда недоступны все осталь-
ные протоколы безопасной коммуникации
Рекомендации по использованию Citrix ХепАрр в среде Microsoft Active Directory
Ниже мы приведем некоторые рекомендации по использованию Citrix ХепАрр в среде
Microsoft Active Directory.
Компания Citrix рекомендует следующие конфигурации фермы серверов, использую-
щей Active Directory:
•	все серверы должны находиться в одном домене;
•	у домена фермы серверов нет доверительных отношений с доменами, не исполь-
зующими Active Directory;
•	ферма серверов находится в одном лесу Active Directory.
ЧАСТЫ1 ПРАКТИКА
Заметим, что это рекомендации, а не требования Тем не менее, наличие нескольких до-
менов или доверительных отношений с доменами, не использующими Active Directory,
может повлиять на все аспекты, касающиеся аутентификации пользователя, что включает:
•	проверку подлинности для администратора Citrix;
•	доступ пользователей к опубликованным приложениям, опубликованное прило-
жение (приложение, установленное на сервере Citrix XenApp и предоставленное
пользователю для удаленной работы);
•	назначение пользователей сетевым принтерам.
Использование лесов Active Directory
При использовании Windows Active Directory компания Citrix рекомендует, чтобы все
серверы в ферме серверов относились к одному пространству Active Directory. Если в фер-
ме имеются серверы, относящиеся более чем к одному лесу, пользователи не смогут за-
регистрироваться, введя полное имя пользователя (UPN).
При регистрации в системе с помощью UPN используется формат «имя пользовате-
ля»@идентификатор UPN (Например: ivanov__aa@company.ru). В системе с Active Directory
регистрация с помощью главного имени пользователя (UPN) не требует указания доме-
на, поскольку Active Directory может полностью определить расположение регистрации
с UPN в каталоге. Тем не менее, если в ферме имеется несколько лесов, может возник-
нуть проблема, поскольку один и тот же идентификатор UPN может существовать в двух
доменах в разных лесах.
Реализация модели безопасности Active Directory
В Active Directory имеются следующие типы групп безопасности , к которым могут при-
надлежать пользователи:
•	Локальные доменные группы. В модели Active Directory локальные доменные группы
могут включать группы из других доменов, однако доменной локальной группе мо-
гут быть присвоены ресурсы только из того домена, в котором она присутствует.
•	Универсальные группы. Они могут содержать группы из других доменов и сохраня-
ются в глобальном каталоге Active Directory. Универсальные группы могут исполь-
зоваться для присвоения полномочий на использование ресурсов в любом домене.
•	Глобальные доменные группы. Глобальные группы включают группы в одном доме-
не и им могут присваиваться ресурсы в любом домене. Компания Citrix рекомен-
дует использовать доменные глобальные группы для обеспечения доступа поль-
зователей к опубликованным приложениям и сетевым принтерам. Глобальные до-
менные группы эквивалентны глобальным группам, не относящимся к доменам
Active Directory. Эти группы безопасности можно использовать при назначении
пользователей для опубликованных приложений и сетевых принтеров.
Для получения дополнительных сведений о доменах, установлении доверительных
отношений между доменами для настройки учетных записей пользователя в доменах или
Active Directory, см. документацию по Windows.
Сценарии разрешений для пользователей при использовании Active Directory
При использовании Active Directory на решения по конфигурированию фермы сер-
веров и управлению разрешениями пользователей могут повлиять следующие условия:
•	Если для определения разрешений пользователям на запуск опубликованного
приложения используются универсальные группы, то все серверы, на которых за-
232
Гпава 3 Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
пущено приложение (если для распределения нагрузки используется Load Manager
(Диспетчер нагрузки)), должны находиться в домене Active Directory.
•	Если для определения разрешений пользователям на запуск опубликованного при-
ложения используются локальные группы, то все серверы, между которыми рас-
пределена нагрузка по данному приложению, должны находиться в одном домене.
Кроме того, локальные доменные группы, которым разрешается использовать
приложение, должны принадлежать первичному домену, общему для всех серверов,
между которыми распределяется эта нагрузка. Если пользователь является членом
локальной доменной группы, то группа принадлежит маркеру безопасности поль-
зователя только тогда, когда пользователь входит в систему в том же домене, что
и локальная доменная группа. Доверительная маршрутизация не гарантирует того,
что запрос пользователя на вход в систему отправляется на сервер в том же домене,
в котором находится локальная доменная группа.
Связывание клиентов и серверов
В ферме серверов основные процессы соединения клиентов и серверов — это пере-
числение приложения, рабочего стола и сеанса 1СА (рис. 3.3).
Клиент
Перечисление
ICA
Citrix ХепАрр
Рис. 3.3. Схема перечисления приложении
На рис. 3.3 показан клиент, осуществляющий перечисление приложений с сервера.
Для запуска приложения клиент инициирует сеанс 1СА с сервером.
Перечисление
Перечисление — это процесс, при котором клиент передает данные, чтобы обнаружить
серверы в сети и получает информацию по опубликованным приложениям фермы сер-
веров.
В процессе перечисления клиенты общаются с Citrix XML Service или обозревателем
1СА в зависимости от протокола просмотра, выбранного на клиенте.
Перечисление производится в случае, когда:
•	Web Interface или клиентское ПО Program Neighborhood посылает запрос с целью
обнаружения приложения на сервере. При использовании Load Manager (диспетчер
нагрузки) компонента Citrix ХепАрр для Windows, Advanced Edition и Enterprise
Edition, клиент получает адрес сервера с минимальной загруженностью
•	Пользователи Program Neighborhood выводят список Набора приложении в Мас-
тере «Найти новый набор приложений».
•	Пользователи Program Neighborhood выводят список серверов или опубликованных
приложении в Мастере «Добавить новое ICA-подключение» для создания поль-
зовательского 1СА-подключения.
10-5680
233
ЧАСТЫ1 ПРАКТИКА
Сеансы ICA
Сеанс ICA — это канал связи клиента и сервера, создаваемый пользователем для запуска
приложения. В рамках сеанса 1СА сервер передает экран с окном приложения на кли-
ентское устройство доступа, а устройство посылает приложению, запущенному на сер-
вере, коды нажимаемых пользователем клавиш, операций мыши и локальные данные.
Порт по умолчанию для входящего трафика сеансов ICA на серверах — 1494
Если включается функция надежного сеанса, то трафик ICA туннелируется с помощью
общего шлюзового протокола, использующего по умолчанию TCP порт 2598. Как и в слу-
чае ICA-трафика, для входящих данных во время сеансов с ХепАрр используется вы-
бранный порт, а динамически назначаемый порт используется для исходящего трафика.
Порты 1494 и 2598 должны быть открыты только для внутреннего входящего трафика.
Исходящий порт на серверах, используемых для сеансов ICA, назначается динами-
чески в момент создания сеанса.
Кроме компьютеров, на которых запущен Citrix ХепАрр, в создании сеанса ICA могут
участвовать и другие компоненты, например, компьютеры, на которых запущен Web
Interface, прокси-серверы и веб-обозреватели. В любом случае основной канал связи для
сеанса ICA располагается между клиентом и сервером.
Конфигурирование перечисления
Пользователь подключается к серверам и приложениям из набора приложений или
пользовательских ICA-подключений на клиенте. Перечисление — это процесс, позво-
ляющий найти серверы и опубликованные приложения в ответ на запросы клиента.
•	Когда пользователь запускает приложение из набора приложений, Citrix ХепАрр
обнаруживает сервер, на котором находится данное приложение и, таким образом,
клиент может подключиться к серверу и запустить приложение.
•	Когда пользователь создает пользовательское подключение, то функция «пере-
числение» позволяет получить список опубликованных приложений или серверов
в ферме. Пользователь выбирает приложение или сервер, для которого будет созда-
ваться пользовательское подключение.
Безопасность сеансов, создаваемых клиентами, подключающимися через Интернет,
должна обеспечиваться при помощи Secure Gateway или Access Gateway.
3.2.1.	Настройка доступа пользователей к опубликованным ресурсам
Перед публикацией ресурсов необходимо проверить, как настройки учетных записей
пользователей могут повлиять на их доступ к ресурсам Ресурсы публикуются для опре-
деленных пользователей и групп пользователей. Мастер публикации приложений по-
зволяет настроить два типа доступа к приложениям: анонимный доступ и доступ для яв-
ных (настроенных) учетных записей.
Анонимные пользователи
Во время установки Citrix ХепАрр программа создает специальную группу анонимных
пользователей. По умолчанию анонимным пользователям предоставляются гостевые
разрешения. Публикация приложений для группы анонимных пользователей позволяет
полностью исключить необходимость проверки подлинности при доступе к этим прило-
жениям Когда пользователь запускает приложение, настроенное для анонимных поль
234
Гпава 3 Обеспечение безопасности доступа на основе продуктов компании СцГ1х systems
зователей, сервер не требует указания явного имени пользователя и пароля для входа на
сервер и запуска приложения. Анонимным пользователям предоставлякггся минимальные
права на сеансы, включающие следующие ограничения:
•	десятиминутный интервал ожидания при отсутствии действии Пользователя-
•	выход из системы при разрыве соединения или истечении интьрвала ожидания;
•	пользователь не может изменить пароль (пароль не требуется)
По окончании сеанса анонимного пользователя пользовательские СцедсНия не сохра-
няются. Сервер не сохраняет настройки рабочего стола, принадлежа!цие пользователю
файлы и другие ресурсы, созданные или настроенные для клиента.
Примечание. Учетные записи анонимных пользователей, которые Citrix XenApp со-
здает во время установки, не требуют дополнительной настройки. Если нужно изменить
их свойства, можно сделать это с помощью стандартных средств управления учетными
записями пользователей Windows.
Явные пользователи (Explicit Users)
Явный пользователь — это любой пользователь, не входящий в группу 1НОнимных поль-
зователей. У явных пользователей есть учетные записи, создаваемые, настраиваемые и
обслуживаемые с помощью стандартных средств управления учетным^ зэписями.
Существуют ограничения для явных пользователей, входящих в си;теМу фермы сер-
веров для запуска приложений: администраторы могут указать тип профцдя, параметры
и другие настройки для этих пользователей.
Управление пользовательским доступом
Пользователи получают доступ к опубликованным ресурсам с помо^ью ICA-подклю-
чений и сеансов. Подключения — это порты сетевого протокола, настроенные на ожи-
дание подключения на компьютере под управлением Citrix XenApp. £огда клиент со-
единяется с сервером через подключение, он устанавливает сеанс. Ceai __ это активный
канал, который работает на сервере, пока пользователь не выйдет из чИСТемы.
В этой главе описывается управление доступом пользователей к ресу>ам фермы серве-
ров путем настройки входов в систему, конфигурации подключений, а тзкже монито-
ринга, оптимизации и управления сеансами.
Настройка входов пользователей в систему
По умолчанию, когда вход в систему разрешен, Citrix XenApp не оцан1лчивает поль-
зовательский доступ к опубликованным приложениям. Следовательо пользователи
могут запускать несколько подключений и подключаться к любым опубвкованным при-
ложениям, на использование которых они имеют право. Вы можете коьро шровать спо-
собность пользователей подключаться к серверу, разрешая и запрета вход в систему.
По умолчанию после установки Citrix XenApp входы активны
Управление видом пользовательского входа
Во время подключения к серверу пользователи видят все сведения подключении и
состоянии входа в последовательности экранов, начиная с момента, они дважды
Щелкают по значкам приложений на клиентском устройстве до провс, ки подлинности
и запуска опубликованного приложения в сеансе.
ЧАСТЬ II. ПРАКТИКА
Citrix ХепАрр контролирует вид входа, пропуская окна состояния, созданные операци-
онной системой Windows сервера, во время подключения пользователя. Для этого про-
грамма установки Citrix ХепАрр использует следующие локальные групповые политики
Windows для сервера, на который вы устанавливаете продукт:
•	Административные шаблоны -> Система Удалить сообщения о состоянии за-
грузки/завершения работы/входа/выхода;
•	Административные шаблоны Система -> Подробные или обычные сообщения
о состоянии.
Однако групповые политики, настроенные в Active Directory, имеют приоритет над
эквивалентными локальными групповыми политиками, настроенными для отдельных
серверов. Поэтому если вы установите Citrix ХепАрр на серверы, входящие в домен Active
Directory, и настроите групповые политики Active Directory, эти политики могут поме-
шать Citrix ХепАрр скрыть экраны состояния, сгенерированные операционной системой
Windows на отдельных серверах. В этом случае пользователи увидят экраны состояния,
созданные ОС Windows во время подключения к этому серверу. Для обеспечения оптималь-
ной производительности не настраивайте такие групповые политики в Active Directory.
Предоставление пользователям функции Workspace Control
Функция Workspace Control позволяет пользователям быстро отключаться от всех ра-
ботающих приложений и переподключаться к ним, или выходить из всех работающих
приложений. Workspace Control позволяет пользователям перемешаться между клиентски-
ми устройствами и получать доступ ко всем своим открытым приложениям после входа.
Например, Workspace Control может помочь работникам, нуждающимся в быстром пе-
реходе между рабочими станциями и доступе к одному набору приложений при каждом
входе в Citrix ХепАрр. Если вы разрешите этот режим в Workspace Control, работники
смогут отключаться от нескольких приложений на одном клиентском устройстве, а за-
тем подключаться к ним, чтобы открыть приложения на другом клиентском устройстве.
Для пользователей, подключающихся через Web Interface или Program Neighborhood Agent
можно настраивать (или разрешить пользователям настраивать) следующие операции:
•	Вход. По умолчанию Workspace Control позволяет пользователям переподключать-
ся ко всем работающим приложениям во время входа без необходимости в повтор-
ном открытии отдельных приложений. С помощью Workspace Control пользователи
могут открывать автономные приложения и приложения, активные на другом
клиентском устройстве. После отключения от приложения оно продолжит работу
на сервере. Если в организации есть пользователи, которые часто меняют рабочее
место и которым необходимо, чтобы некоторые приложения работали на одном
клиентском устройстве, когда они переподключаются к поднабору приложений
на другом устройстве, можно настроить режим переподключения на открытие
только тех приложений, от которых пользователь отключился ранее.
•	Переподключение. После входа на ферму серверов пользователи могут переподклю-
читься ко всем приложениям в любое время, нажав кнопку «Переподключить»
По умолчанию переподключение открывает отключенные приложения и все актив-
ные приложения, работающие на другом клиентском устройстве. Переподключе-
ние можно настроить на открытие только тех приложений, от которых пользова-
тель отключился ранее.
•	Выход из системы. Для пользователей, которые открывают приложения через Web
Interface, можно настроить команду «Выход» на выход только из Web Interface и
всех активных сеансов или на выход только из Web Interface.
236
Гпава 3 Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
•	Отключение. Пользователи могут отключиться от всех работающих приложении
без необходимости в отключении всех приложений в отдельности По умолчанию
функция Workspace Control включена в ферме серверов и доступна только для
пользователей, которые получают доступ к приложениям через Web Interface или
Program Neighborhood Agent.
Когда пользователь переходит на новое клиентское устройство, пользовательские по-
литики, назначение клиентских дисков и конфигурация принтеров изменяются соот-
ветственно Политики и назначения применяются в соответствии с клиентским устрой-
ством, с которого подключается пользовательский сеанс. Например, медицинский ра-
ботник завершает сеанс на клиентском устройстве в пункте первой помощи больницы,
а затем выполняет вход на рабочую станцию в рентгеновской лаборатории больницы, при
этом политики, назначения принтеров и назначения клиентских устройств для сеанса
рентгеновской лаборатории применяются, как только пользователь выполняет вход на
клиентское устройство лаборатории.
Дополнительные сведения о включении и настройке Workspace Control для пользо-
вателей см. в документе Citrix Web Interface Administrator's Guide
Настройка пользовательских подключений
Citrix ХепАрр позволяет запускать приложения, опубликованные на сервере, обес-
печивая подключение различных платформ через клиентское ПО Citrix ХепАрр.
Если подключение обрывается, сеанс, который его использует, останется активным,
пока его состояние не будет изменено функцией автоматического переподключения, па-
раметрами ICA Keep-Alive или администратором Citrix.
Несколько клиентов могут создавать сеансы, используя одно подключение к серверу.
Citrix ХепАрр связывает идентификатор пользователя и подключение с каждым сеансом.
Защита ферм серверов
Здесь мы дадим общие указания по планированию безопасных сред Citrix.
Защита доступа к серверам
Первый и важный этап обеспечения безопасности фермы серверов — защита доступа
к серверам и их консолям управления.
Защита Консоли ХепАрр Console
Консоль ХепАрр может подключаться ко всем серверам фермы. Запускайте консоль
только в средах, в которых перехват пакетов невозможен. Убедитесь, что доступ к консоли
имеют только администраторы. Можно настроить права NTFS так. чтобы пользователи
без прав администратора не могли выполнять операцию Execute для исполняемого фай-
ла консоли (Ctxload.exe).
Использование разделов NTFS. Чтобы обеспечить необходимый уровень контроля
доступа для всех файлов, установленных Citrix ХепАрр Server, устанавливайте ХепАрр
Server только на разделы, отформатированные в NTFS.
Установка и настройка службы SNMP. По умолчанию служба SNMP не устанавлива-
ется на компьютеры под управлением Windows Server 2003. При установке службы необ-
ходимо задать параметр community string. Может потребоваться создание «белого списка»
Для ограничения доступа к службе SNMP с удаленных IP-адресов. Служба Windows SNMP
ЧАСТЫ1 ПРАКТИКА
по умолчанию поддерживает несколько привилегий на чтение и запись, однако необ-
ходимо также дать службе SNMP права на чтение и создание для задач администриро-
вания, таких как выход или отключение через Network Manager. При использовании
Network Manager или другого управляющего ПО на основе SNMP только для мониторинга
сервера (без удаленного управления), Citrix рекомендует настроить права только на чтение.
Если консоль SNMP не используется, не устанавливайте компоненты SNMP на сервер.
Для предотвращения несанкционированного доступа можно задать общие и выделенные
консоли управления SNMP. Настройте агенты SNMP на прием ловушек только от из-
вестных консолей SNMP.
Настройка доверенного сервера. Эта функция определяет и обеспечивает отношения
доверия в клиентских подключениях. Отношения доверия помогают повысить уверенность
администраторов и пользователей клиентских машин в целостности данных на клиентских
устройствах, а также предотвратить злонамеренное использование клиентских подклю-
чений. Когда эта функция включена, клиенты могут задавать требования к доверию и
определять, доверяют ли они тому или иному серверному подключению. Дополнитель-
ные сведения об этой функции см. в документе Clients for Windows Administrator's Guide.
Защита хранилища данных
Один из самых важных аспектов обеспечения безопасности фермы серверов — защита
хранилища данных. Она подразумевает не только защиту данных в БД хранилища, но и
ограничение доступа к этим данным. Как правило:
•	пользователи, которые имеют доступ к серверам фермы, не нуждаются в доступе
к хранилищу данных и предоставлять его не следует;
•	если подключение к хранилищу данных является прямым (т. е. без промежуточных
серверов), все серверы фермы используют одно имя пользователя и пароль для до-
ступа к хранилищу данных. Выберите пароль, который трудно подобрать. Храните
имя пользователя и пароль в безопасном месте и давайте его администраторам
только для установки Citrix XenApp.
Предупреждение. Входящий Интернет-трафик SNMP можно заблокировать, закрыв
порты 161 и 162 для протокола UDP в межсетевом экране.
Более конкретные рекомендации Citrix по обеспечению безопасности хранилища
данных зависят от БД, используемой для хранилища данных. В следующих разделах рас-
сматриваются рекомендуемые меры безопасности для каждой базы данных, поддержи-
ваемой Citrix XenApp.
Для повышенной безопасности можно изменить права учетной записи на db-reader
и db_writer после первоначальной установки базы данных с правами db_owener Измене-
ние прав учетной записи с db_owener может вызвать проблемы установки новых пакетов
обновления или версий Citrix XenApp.
Microsoft Access. Для хранилища данных Access именем пользователя по умолчанию бу-
дет «Citrix», пароль — «Citrix». Если пользователи имеют сетевой доступ к хранилищу данных,
измените пароль с помощью команды dsmaint config и храните его в безопасном месте.
Microsoft SQL Server. Учетная запись, используемая для доступа к хранилищу данных
Microsoft SQL Server, имеет роли public и db_owner на сервере и в базе данных. Учетная
запись системного администратора для доступа к хранилищу данных не требуется. Нс
используйте эту учетную запись, так как это может стать причиной дополнительных ри-
сков для безопасности.
Если Microsoft SQL Server использует смешанный режим безопасности (т. е. можно
использовать проверку подлинности как Microsoft SQL Server, так и Windows), возможно
238
Гпава 3. Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
потребуется создание учетной записи Microsoft SQL Server только для доступа к хранилищу
данных. Так как эта учетная запись будет иметь доступ только к хранилищу данных, ри-
ски безопасности для домена Windows в случае раскрытия пароля будут устранены
Предупреждение. Если учетная запись для прямого доступа изменится, служба Citrix
IMA Service не запустится на всех серверах, использующих эту учетную запись. Для того,
чтобы изменить пароль Citrix IMA Service необходимо ввести команду dsmaint config на
всех серверах, где это необходимо.
Предупреждение. Для сред с высоким уровнем безопасности Citrix рекомендует ис-
пользовать только проверку подлинности Windows.
Microsoft SQL Server 2005 Express Edition. Проверка подлинности Windows поддер-
живается для баз данных Microsoft SQL Server 2005 Express Edition. По соображениям
безопасности проверка подлинности Microsoft SQL Server не поддерживается. Дополни-
тельные сведения см. в документации Microsoft. Как правило, используется имя поль-
зователя и пароль учетной записи локального администратора. Если пользователи имеют
доступ к серверу хранилища данных, измените пароль с помощью команды dsmaint
config и храните его в безопасном месте.
Oracle. Если хранилище данных размещено в БД Oracle, дайте учетной записи, исполь-
зуемой для подключения к ферме серверов только права «connect» и «resource». Права
учетной записи уровня системного администратора (system или sys) для доступа к хра-
нилищу данных не требуются.
IBM DB2. Если хранилище данных размещено в БД IBM DB2, дайте учетной записи,
используемой для подключения к ферме серверов следующие права:
•	Connect database (подключение базы данных);
•	Create tables (создание таблиц);
•	Register functions to execute to database manager’s process (регистрация функций для
выполнения процесса диспетчера базы данных);
•	Create schemas implicitly (неявное создание схем).
Права учетной записи уровня системного администратора (DB2Admin) для доступа
к хранилищу данных не требуются.
Защита сетевой передачи данных
Сетевая передача данных между клиентом и сервером представляет риски безопасности
в любой корпоративном среде. В следующих разделах рассматриваются компоненты без-
опасности, которые можно использовать для защиты сетевой передачи данных в ферме
серверов. В зависимости от требований к безопасности в проект развертывания Citrix
ХепАрр можно включить следующие компоненты для защиты сетевой передачи данных:
•	шифрование средствами протокола ICA:
•	Citrix SSL Relay;
•	служба Secure Gateway;
•	Secure Ticket Authority (служба STA)
•	Межсетевые экраны
Использование средств шифрования протокола ICA
Протокол 1СА предлагает встроенное шифрование на стороне клиента и сервера, до-
бавляя дополнительный уровень зашиты от раскрытия данных сеанса. Используйте шиф-
рование ICA (Citrix SecurelCA) для шифрования данных, передаваемых между сервером
под управлением Citrix ХепАрр Server и клиентом. Шифрование ICA помогает предотв-
ратить перехват данных. В отличие от шифрования SSL/TLS. шифрование ICA, если ис-
ЧАСТЫ1. ПРАКТИКА
пользуется отдельно, не обеспечивает проверку подлинности сервера. Поэтому, теоре-
тически, данные можно перехватить во время передачи по сетям общего пользования и
перенаправить на поддельный сервер. Кроме того, шифрование 1СА не включает проверку
целостности данных. Шифрование ICA — только один из аспектов комплексной стра-
тегии безопасности.
Уровень шифрования ICA для опубликованного приложения можно задать на странице
Properties (свойства) приложения или с помощью политик Citrix. Кроме того, необхо-
димо включить шифрование 1СА на стороне клиента. См. документацию по клиенту, ко-
торый планируется развернуть.
В целом шифрование ICA нужно использовать если:
•	необходима безопасная внутренняя связь в рамках LAN или WAN; или есть по-
требность в безопасном внутреннем доступе в Интранет;
•	необходима безопасная связь с устройствами под управлением ОС Microsoft DOS
или Win 16;
•	клиентское ПО работает на старых устройствах, которые невозможно модерни-
зировать;
•	риск «атаки изнутри» невысок.
Использование Secure Gateway
Для обеспечения шифрования SSL/TLS между безопасным шлюзовым сервером Ин-
тернета и клиентом с поддержкой SSL в сочетании с шифрованием данных HTTP, пере-
даваемых между веб-обозревателем и веб-сервером, используется Secure Gateway. Secure
Gateway упрощает передачу данных через межсетевые экраны и улучшает безопасность,
обеспечивая единую точку входа и безопасный доступ к фермам серверов.
Secure Gateway следует использовать, если требуется:
•	скрыть внутренние IP-адреса;
•	обезопасить общий доступ к серверам фермы;
•	двухфакторная аутентификация (в сочетании с Web Interface);
Использование Secure Gateway позволяет добиться следующих преимуществ:
•	безопасный доступ к Интернету;
•	устранение необходимости в публикации адресов каждого сервера Citrix ХепАрр;
•	упрощение управления серверными сертификатами;
•	единая точка шифрования и доступа к серверам.
Для создания шлюза, изолированного от компьютеров под управлением Citrix ХепАрр
используется Secure Gateway. Организация шлюза упрощает передачу данных через меж-
сетевой экран, так как входящий и исходящий трафики ICA проходят через широко ис-
пользуемый порт. Secure Gateway обеспечивает повышенную масштабируемость. Однако,
поскольку данные ICA шифруются только между клиентом и шлюзом, может потребо-
ваться защита трафика между шлюзом и серверами Citrix ХепАрр, включая серверы, на
которых работает служба Citrix XML Service. Дополнительные сведения о настройке
Secure Gateway см. в документе Secure Gateway Administrator’s Guide.
Использование службы Secure Ticket Authority
Служба Secure Ticket Authority (STA) выполняет выдачу билетов сеансов по запросам
на подключение к ресурсам, опубликованным на сервере Citrix ХепАрр На билетах сеанса
основываются процедуры проверки подлинности и авторизации для доступа к опубли-
кованным ресурсам. Служба STA устанавливается одновременно с установкой ХепАрр-
240
Гпава 3 Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
Если Citrix XenApp устанавливается на сервер со старой версией службы STA, она об-
новляется до текущей версии. Служба STA встроена в службу Citrix XML Service.
Настройка межсетевых экранов
В дополнение к обеспечению физической безопасности серверов, большинство орга-
низаций устанавливают средства сетевой защиты, такие как межсетевые экраны, для
изоляции Citrix XenApp и веб-обозревателей от Интернета и сетей общего доступа Для
развертывания Citrix XenApp во внутренних сетях обеспечьте безопасность данных, пе-
редаваемых между клиентом и сервером, с помощью протоколов SSL/TLS и других мер
безопасности.
Дополнительные сведения о настройке межсетевых экранов в серверной ферме см.
в документе Advanced Concepts Guide for Citrix Presentation Server (Руководство no исполь-
зованию дополнительных решений для Citrix Presentation Server).
Настройка TCP-портов
В таблице ниже перечислены порты TCP/IP, которые используются серверами, кли-
ентами Citrix XenApp, службой IMA Service и другими службами фермы. Эти сведения
могут помочь в настройке межсетевых экранов и устранении конфликтов портов с дру-
гим программным обеспечением.
Таблица используемых TCP портов
Таблица 3.1
Передача данных	Порт по умолчанию
Citrix XML Service Access Management Citrix SSL Relay Сеансы ICA (от клиентов к серверам) Клиент—сервер (направленный UDP) Сервер—сервер Консоль XenApp—сервер Надежность сеанса «Session Reliability» Сервер—сервер Microsoft SQL или Oracle Консоль License Management Сервер—сервер лицензий	80 135 443 1494 1604 2512 2513 2598 139. 1433 или 443 для MS-SQL 8082 27000
3.2.2.	Настройка проверки подлинности пользователя
Обеспечение безопасности серверов подразумевает гарантии того, что доступ к сер-
верам и ресурсам могут получить только пользователи, подлинность которых проверена
Настройка аутентификация для Workspace Control
Если пользователи выполняют вход, используя смарт-карты или сквозную аутенти-
фикацию, необходимо установить отношения доверия между сервером Web Interface и
всеми серверами фермы, к которым Web Interface обращается для доступа к опублико-
ванным приложениям Без отношении доверия команды Disconnect, Reconnect и Log Off
ЧАСТЫ1. ПРАКТИКА
(«Workspace Control») пользователей, выполнивших вход с помощью смарт-карты или
сквозной аутентификации, работать не будут.
Если при входе пользователи вводят учетные данные в Web Interface или Program
Neighborhood Agent, отношения доверия не требуются.
Если вы настраиваете сервер доверять запросам, отправленным в адрес службы Citrix
XML Service, необходимо рассмотреть следующие факторы:
•	отношения доверия нужны, только если вы планируете внедрить Workspace Control
и пользователи выполняют вход, используя смарт-карты или сквозную аутенти-
фикацию;
•	включайте отношения доверия только на серверах, к которым Web Interface под-
ключается напрямую. Эти серверы перечислены в консоли Web Interface;
•	устанавливая отношения доверия, вы передаете аутентификацию пользователей
серверу Web Interface. Чтобы избежать рисков для безопасности, используйте SSL
Relay, IPSec, межсетевые экраны или любые другие технологии, позволяющие га-
рантировать, что со службой Citrix XML Service смогут взаимодействовать только
доверенные серверы. Установка отношений доверия без IPSec, межсетевых экра-
нов и других технологий защиты позволит любому сетевому устройству отключать
и завершать клиентские сеансы;
•	настройте SSL Relay, IPSec, межсетевые экраны и другие технологии для зашиты
среды и ограничения доступа к службе Citrix XML Service таким образом, что ее
смогут использовать только серверы Web Interface. Например, если служба Citrix
XML Service делит порт с I IS, можно использовать функцию ограничения IP-ад-
реса в IIS для ограничения доступа к службе Citrix XML Service.
Настройка входа Kerberos
Клиенты Citrix ХепАрр для Windows предлагают расширенную безопасность для сквоз-
ной аутентификации. В этом случае применяется аутентификация Kerberos, а не отправ-
ка паролей через сеть. Kerberos — стандартный протокол аутентификации, встроенный
в операционные системы Windows. Вход Kerberos предлагает заказчикам с высокими тре-
бованиями к безопасности удобство сквозной аутентификации в сочетании с симметрич-
ной криптографией и целостностью данных, обеспечиваемой стандартными решениями
по сетевой безопасности.
Системные требования. Вход Kerberos требует Presentation Server 3.0 или выше и кли-
ентское ПО Citrix Presentation Server для Windows версии 8.x или выше Kerberos работает
только между клиентами и серверами, которые принадлежат одному домену или доверен-
ным доменам Windows. Кроме того, серверы должны быть доверенными для делегирования.
Эту возможность можно включить в средстве управления «Пользователи и компьютеры*
Active Directory.
Вход Kerberos недоступен, если в конфигурации терминальных служб заданы сле-
дующие функции:
•	использовать обычную аутентификацию Windows;
•	всегда использовать следующие сведения или всегда запрашивать пароль:
—	если подключения проходят через Secure Gateway;
—	если сервер Citrix ХепАрр требует входа по смарт-карте
Kerberos требует, чтобы для фермы серверов было включено разрешение DNS-адре-
сов средствами службы Citrix XML Service, или для Active Directory было включено об'
ратное разрешение DNS.
Гпава 3. Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
Использование смарт-карты с Citrix ХепАрр
В среде Citrix ХепАрр можно использовать смарт-карты:
•	аутентификации пользователей в сетях и компьютерах;
•	защищенной передачи данных по сети;
•	цифровой подписи содержимого.
Если вы используете смарт-карты для аутентификации в сети, пользователям также бу-
дет доступна аутентификация для доступа к приложениям и содержимому, опубликован-
ному на серверах. При этом функциональность смарт-карты сохраняется и внутри этих
приложений. Например, опубликованное приложение Microsoft Outlook может требовать
вставки смарт-карты в устройство для чтения клиентского устройства для входа на сервер.
После аутентификации пользователей для доступа к приложению они смогут добавлять циф-
ровую подпись к сообщениям электронной почты с помощью сертификатов смарт-карты.
Компания Citrix тестировала смарт-карты, соответствующие стандарту ISO 7816 для
карт с электрическими контактами (также известных как контактные карты), которые взаи-
модействуют с компьютерными системами через устройства для чтения смарт-карт. Устрой-
ство чтения подключается к компьютеру через последовательный порт, USB или PCMCIA.
Citrix поддерживает криптографические смарт-карты PC/SC, используемые для крип-
тографических операций, таких как цифровые подписи и шифрование. Криптографи-
ческие карты обеспечивают безопасное хранение закрытых ключей, которые, в частности,
могут использоваться в системах на основе инфраструктуры PKI (Public Key Infrastruc-
ture). В таких картах криптографические функции выполняются в самой смарт-карте. Это
означает, что закрытые ключи и цифровые сертификаты никогда не покидают карту.
Кроме того, Citrix поддерживает двухфакторную аутентификацию для повышенной
безопасности. Помимо простого предъявления смарт-карты (один фактор) для выполнения
операции требуется PIN-код (второй фактор), известный только пользователю Это позво-
ляет гарантировать, что лицо, использующее смарт-карту, является ее законным владельцем.
Смарт-карты можно также использовать в Web Interface для Citrix ХепАрр. Дополни-
тельные сведения о настройке Web Interface для поддержки см. в документе Web Interface
Administrator's Guide (Руководство администратора Web Interface).
Требования к смарт-картам
Ниже приводятся основные инструкции по использованию смарт-карт с Citrix ХепАрр
Для сервера необходимы следующие компоненты:
•	программное обеспечение PC/SC;
•	программное обеспечение Cryptographic Service Provider (CSP).
Предупреждение. Citrix Presentation Server не поддерживает функциональные специ-
фикации стандарта PKCS компании RSA Security Inc по персональным криптографи-
чески маркерам.
Компоненты, которые необходимо установить на устройстве с поддерживаемым кли-
ентским ПО Citrix ХепАрр:
•	программное обеспечение PC/SC:
•	драйверы устройства для чтения смарт-карт;
•	устройство для чтения смарт-карт.
Операционные системы клиента и сервера могут включать PC/SC, CSP и драйверы
устройства для чтения смарт-карт. Сведения о том, поддерживаются ли эти компоненты
или их необходимо заменить специализированным программным обеспечением, можно
получить у поставщика смарт-карт.
ЧАСТЫ1. ПРАКТИКА
Если вы используете сквозную аутентификации для передачи учетных записей от кли-
ентского устройства Windows 2000 или Windows ХР серверному сеансу смарт-карты, необ-
ходимо установить ПО CSP на клиентское устройство.
Смарт-карты можно использовать в качестве средства аутентификации для доступа
к опубликованному приложению, а также для использования внутри приложений, поддер-
живающих функциональность смарт-карт При установке Citrix XenApp по умолчанию
поддерживается только первое.
Настройка политик Windows для смарт-карт
Microsoft Windows поддерживает два параметра политик безопасности для интерактив-
ного входа в серверный сеанс. Клиентские сеансы Citrix XenApp могут использовать сле-
дующие политики:
•	для входа в интерактивный сеанс необходима смарт-карта. Это — пользователь-
ская политика, которая требует вставки смарт-карты для аутентификации;
•	политика удаления смарт-карты. Это — компьютерная политика, которая вклю-
чает три параметра, определяющие режим работы клиентского устройства при из-
влечении смарт-карты из устройства чтения:
о нет (без эффекта);
о	блокировка рабочей станции (отключение всех пользовательских сеансов);
о принудительный выход (выход из всех пользовательских сеансов).
Настройка клиента
Смарт-карты поддерживаются следующими клиентами:
•	клиент Citrix Presentation Server для Windows;
•	клиент для Linux;
•	клиент для терминалов Windows.
Список использованной литературы
1.	Рэнд Моримото, Майкл Ноэл, Омар Драуби, Росс Мистри. Крис Амарис «Microsoft Windows
Server 2008. Полное руководство». М.: Вильямс, 2008.
2.	Джонатан Хассел «Администрирование Windows Server 2003» — «Русская редакция», •Питер»,
2006.
3.	Курт Хадсон «Официальный учебный курс Microsoft. Планирование, внедрение и поддержка
инфраструктуры Microsoft Windows Server 2003 Active Directory 70-294. Практические занятия». —
M.: «ЭКОМ Паблишерз», 2007.
4	Windows Server 2008. Официальный сайт. http://www.microsoft.com/Rus/windows-server/de-
fault.mspx
5.	Пошаговые руководства для установки, настройки и использования систем Windows Server 200©.
http://www.microsoft.com/rus/windows-server/tutorials/default.mspx
6.	Windows Server TechCenter, http://technet.microsofl.com/ru-ru/windowsserver/default.aspx
7.	Воронин А. Безопасный доступ к Oracle E-Business Suite ОС Week, № 13/2006,
http://www. aladdin.ru/catalog/etoken_products/suite/public_detail.php?ID=7648
8.	Демченко К., Додохов А., Сабанов А. Русская версия «индийской защиты», или Зашита дан-
ных в СУБД Oracle, журнал Byte, № 8, 2004, http://www.bytemag.ru ?1D=6O2973
9.	Додохов А., Сабанов А. О дополнительных возможностях зашиты данных в среде Огас1е9ь
BYTE, № 5/2005, http://www.aladdin.ru/catalog/etoken_products/oracle/public_detail.php?ID=7264
10.	Краткий обзор Oracle E-Business Suite, http://www.oracle.com/global/ru/pdfs/brochure_ebs.pdf
244
Гпава 3 Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
11.	Сабанов А Безопасность баз данных. Что, от кого и как надо защищать Connect № 4/2006,
hup://www.aladdin.ru/catalog/etoken_products/oracle/public_detail.php?lD=7640
12.	Сабанов А. О роли аутентификации при обеспечении защищенного удаленного доступа.
Connect № 5, 2007. Технические подробности eToken SecurLogon для Oracle Application Server
www.aladdin.ru/catalog/etoken_products/oas/tech_details.php
13.	Технические подробности eToken SecurLogon для Oracle E-Business Suite,
www.aladdin.ru/catalog/etoken_products/suite/tech_details.php
14.	eToken SecurLogon для Oracle Application Serverwwu.aladdin.ru/catalog/etoken_products/oas/
15.	eToken SecurLogon для Oracle E-Business Suite, wwu.aladdin.ru/catalog/etoken_products/suite/
16.	Oracle Advanced Security Administrator’s Guide Release 2 (9.2)
17.	Oracle Database 10g — Каталог программных продуктов http://www.oracle.com/global/ru/pdfs/
index.html
18.	Oracle Database 10g Release 2 (10.2) Documentation hup://www.oracle.com/technology/documen-
tation/database 10gr2.html
19	Oracle E-Business Suite. Каталог, http://download.oracle.com/otndocs/ebs/oracle-ebs-catalogue-fuli.pdf
20.	Oracle Fusion Middleware. Каталог продуктов, http://www.oracle.com/global/ru/pdfs/mdex.html
21.	Citrix Product Development Team. Access Security for IT Administrators, McGraw Hill Osborne, 2007.
22.	Fabian Kienle. Citrix MetaFrame Secure Access Manager, MITP, 2004
23.	Meta Frame Presentation Server Security Standards and Deployment Scenarios, Citrix Systems. 2004.
24.	Citrix Advanced Concepts Guide, Vol. 3, Security, Citrix Systems, 2007.
25.	Web interface Administrator’s Guide, Citrix Systems, 2006.
26.	Secure Gateway for Windows Administrator’s Guide, Citrix Systems, 2007.
27.	eToken Integration Guide. eToken and Citrix MetaFrame Presentation Server version 4.0, Aladdin
Knowledge Systems. 2006.
28.	eToken OTP Authentication 2.0 for Citrix WI Administrator’s Guide. Aladdin Knowledge Systems, 2007.
Источники
I.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectorycertificateservi-
ces.mspx» (Службы сертификации Active Directory AD CS)
2.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectorydomainservi-
ces.mspx (Службы доменов Active Directory AD DS)
3.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectoryfederationservi-
ces.mspx (Службы федерации Active Directory AD FS)
4.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectorylightweightdirecto-
ryservices.mspx (Службы Active Directory облегченного доступа к каталогам AD LDS)
5.	http://technet2.microsoft.eom/windowsserver2008/en/servermanager/activedirectoryrightsmanagement-
scrvices.mspx (Службы управления правами Active Directory AD RMS)
6.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/applicationserver.mspx (Сервер
приложений)
7.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/dhcpserver.mspx (DHCP-сервер)
8.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/dnsserver mspx (DNS-сервер)
9.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/faxserver.mspx (Факс-сервер)
10.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/fileservicesmspx (Файловые
службы)
11.	hitp://go.microsoft.com/fwlink/?LinkId=101268 (Нурег-V)
12.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/networkpolicyandaccessservic-
es.mspx (Службы сетевой политики и доступа)
13.	http://technct2.microso;i.com/windowsserver2008/en/servermanager/printscrviccs.msp\ (Службы
печати)
14.	http://technet2 microsoft.com/windowsserver2008/en/scrvermanager/streamingmcdiascrvices.mspx
(Службы потокового мультимедиа)
ЧАСТЫ1. ПРАКТИКА
15.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/terminalservices.mspx (Службы
терминалов)
16.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/uddiservices.mspx (Службы UDD1)
17.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/webserver.mspx (Веб-сервер)
18.	http://technet2.microsoft.com/windowsserver2008/en/servermanager/windowsdeploymentservices.mspx
(Службы развертывания Windows)
19.	http://download-uk.oracle.com/docs/cd/B28196_01/idmanage 1014/bl5988/toc.htm (Oracle Identity
Management 10.1.4/ Single Sign-On Administration Guide)
20.	http://download-uk.oracle.com/docs/cd/B31017_01/web.1013/b28948/toc.htm (Oracle Application Ser-
ver 10.1.3.1 / Oracle HTTP Server Administration Guide)
21.	http://download-uk.oracle.com/docs/cd/B31017_01/web. 1013/b28957/toc.htm (Oracle Application Ser-
ver 10.1.3.1 / Oracle Containers for J2EE (0C4J) Security Guide)
22.	http://download-uk.oracle.com/docs/cd/B40078_02/doc/bi.1013/b31765.pdf (Oracle BI Suite Enter-
prise Edition 10.1.3.2 / Infrastructure Installation and Configuration Guide)
23.	http://download-uk.oracle.com/docs/cd/B40078_02/doc/bi.1013/b40017/toc.htm (Oracle Bl Suite
Enterprise Edition 10.1.3.2 / Publisher User Guide)
24.	http://download-uk.oracle.com/docs/cd/B40078_02/doc/bi.1013/b31766.pdf (Oracle BI Suite Enter-
prise Edition 10.1.3.2 / Presentation Services Administrator Guide)
25.	http://download-uk.oracle.eom/docs/cd/B40078_02/doc/bi.1013/b40058.pdf (Oracle BI Suite Enter-
prise Edition 10.1.3.2 / Deployment Guide)
26.	http://download-uk.oracle.com/docs/cd/B40078_02/doc/bi.1013/b32481/toc.htm (Oracle Bl Suite
Enterprise Edition 10.1.3.2 / Deploying Oracle Business Intelligence Publisher in J2EE Application
Servers)
27.	http://technet2.microsoft.com/windowsserver/en/library/32aacfe8-83af-4676-a45c-75483545a9781033.
mspx?mfr=true Windows Server 2003 TechCenter, Security
28.	http://technet2.microsoft.com/WindowsServer/en/library/a92d8eb9-f53d-4e86-ac9b-29fd6146977bl033.
mspx?mfr=true Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infra-
structure
29.	http://technet2.microsoft.com/windowsserver/en/library/2cb5c8c9-cadc-44a9-bf39-856127f4c8271033
mspx?mfr=true How Terminal Services Works
30.	http://www.aladdin.com/etoken/windows-logon.aspx eToken Network Logon and Smart Card Logon
for Windows
31.	http://www.aladdin.com/etoken/otp.aspx eToken One-Time Password (OTP)
32.	http://www.aladdin.ru/catalog/etoken/tech_details/ eToken Aladdin Технические Подробности
33.	http://www.citrix.com/English/SS/supportSecond.asp?slID=162512&ntref=hp_nav_US Citrix Security
and Compliance Information
34.	http://support.ciirix.com/article/CTX113743 Web Interface Administrator’s Guide
35.	http://support.citrix.com/article/CTX111066 Configuring Web Interface 4.x to Use Smart Cards
36.	http://support.citrix.com/article/CTX105749 Citrix Presentation Server Security Standards and De-
ployment Scenarios
37.	http://support.citrix.com/article/CTX112223 Citrix Presentation Server 4.5 Administrator's Guide
38.	http://support.citrix.com/article/CTX112429 Secure Gateway for Windows Administrator's Guide
39.	http://support.citrix.com/article/CTX113599 Citrix SmartAuditor for Presentation Server 4.5
40.	http://support.citrix.com/article/CTX113935 Citrix Password Manager Administrator's Guide
41.	http://support.citrix.com/article/CTXl 12190 Clients for Windows Administrator's Guide-10.x EN
42.	http://www.ieif.org/rfc.html Request for Comments Repository
43.	http://wwu .ietf.org/rfc/rfc 15O9.txt?number= 1509 Internet EFC 1509
ЧАСТЬ III
ЛАБОРАТОРНЫЕ РАБОТЫ
Лабораторная работа № 1
ПОДГОТОВКА СТЕНДА,
УСТАНОВКА И НАСТРОЙКА ПО,
ПОДГОТОВКА ЭЛЕКТРОННЫХ КЛЮЧЕЙ eToken
Цель работы
Подготовить стенд для выполнения работ по теме «Обеспечение безопасности досту-
па к данным информационной системы организации с помощью продуктов Microsoft
и Aladdin. Типовые решения» Подготовить к работе электронные ключи eToken.
Общие сведения о ключах eToken
Смарт-карты и USB-ключи
Смарт-карты, как и Memory-карты, представляют собой пластиковые карты с встро-
енной микросхемой. Однако смарт-карта — достаточно сложное устройство, которое со-
держит микропроцессор и операционную систему, контролирующую устройство и до-
ступ к объектам в его памяти. Кроме того, смарт-карты, как правило, обладают возмож-
ностью проводить криптографические вычисления
Несмотря на название — устройство для чтения смарт-карт — большинство оконеч-
ных устройств или устройств сопряжения (1FD) способны как считывать, так и записы-
вать. если позволяют возможности смарт-карты и права доступа. Устройства для чтения
смарт-карт могут подключаться к компьютеру с помощью:
•	последовательного порта;
•	слота PCMCIA;
•	порта USB.
Устройства чтения смарт-карт могут быть интегрированы в клавиатуру.
Некоторые производители выпускают другие аппаратные устройства, в которых
смарт-карта объединена с ее устройством чтения. По характеристикам памяти и вычис-
лительным возможностям они аналогичны смарт-картам. Наиболее распространены ап-
паратные ключи, использующие порт USB. USB-ключи привлекательны для некоторых
организаций, поскольку USB становится стандартом, находящим все большее распро-
странение в новых компьютерах: организации не нужно приобретать для пользователей
какие бы то ни было считыватели.
Для получения доступа к цифровым сертификатам пользователя на этапе аутенти-
фикации в систему и для хранения закрытых ключей пользователей для связки Kerberos +
+ PKINIT в ОС Windows 2000/2003 используются смарт-карты. Служба управления ре-
сурсами смарт-карт интегрирована в операционную систему, и для настройки аутенти-
фикации по сертификатам достаточно активизировать данную службу, установив драйве-
ры считывателей смарт-карт. При нахождении в домене графический интерфейс О
Windows 2000/2003 (GINA) заменяется вариантом с поддержкой работы со смарт-картами.
На смарт-карту записывается цифровой сертификат и связанный с ним закрыты
ключ, выписанные на доменном центре сертификации с использованием политик, пред-
усматривающих возможность его использования для интерактивной аутентификаций
пользователя в системе.
248
Лабораторная работа № 1
При подключении смарт-карты к рабочей станции для аутентификации пользователя
хранящийся на ней сертификат используется для запроса TGT, а операция с закрытым
ключом, возможная после ввода PIN-кода, используется для подписи этого запроса.
Модели eToken
Ключ eToken — персональное средство аутентификации и хранения данных, аппа-
ратно поддерживающее работу с цифровыми сертификатами и электронными цифро-
выми подписями (ЭЦП). eToken выпускается в форм-факторах USB-ключа или
смарт-карты.
(JSB-ключ eToken подключается к компьютеру через порт USB (Universal Serial Bus)
и не требует наличия устройства чтения смарт-карт.
eToken обладает защищенной энергонезависимой памятью и используется в качестве
хранилища секретных данных (ключей шифрования, имен пользователя, паролей, учет-
ных записей, сертификатов и пр.).
В лабораторных работах будет использоваться электронный ключ eToken PRO
в форм-факторе USB-ключа.
eToken PRO
eToken PRO имеет микросхему смарт-карты Infineon SLE66C, аппаратно реализую-
щую алгоритмы RSA, DES, TripleDES, SHA-1. eToken PRO снабжен встроенным гене-
ратором ключевых пар алгоритма RSA. При этом закрытые ключи никогда не покидают
микросхему смарт-карты. Микросхемы семейства Infineon SLE66C работают под управ-
лением операционной системы Siemens CardOS и обеспечивают высокий уровень без-
опасности (сертификат ITS ЕС LE4).
Кроме PIN-кода пользователя в eToken PRO предусмотрен пароль администратора.
С его помощью, например, можно сменить забытый PIN-код. Пароль администратора
также можно менять.
eToken PRO можно форматировать с помощью утилиты eToken Properties, входящей
в состав набора драйверов eToken Run Time Environment 3.65. При форматировании:
•	из памяти eToken PRO удаляется вся информация;
•	устанавливается PIN-код;
•	возможно задание пароля администратора:
•	возможно задание ключа форматирования для предотвращения несанкциониро-
ванного переформатирования.
249
ЧАСТЫ11 ЛАБОРАТОРНЫЕ РАБОТЫ
Описание работы
Для изучения возможностей продуктов Microsoft Windows Server 2003 и электронных
ключей eToken для обеспечения безопасности доступа к данным информационной сис-
темы работа делится на три части:
•	установка и настройка стенда;
•	установка и настройка программного обеспечения для работы с ключами eToken;
•	подготовка ключей eToken.
Установка и настройка стенда
Данная часть работы предназначена для настройки стенда (хоста и виртуальных ма-
шин) и подготовки их к выполнению основной части лабораторной работы. Для выпол-
нения данной части работы необходимо:
•	подготовить и настроить рабочую станцию (хостовый компьютер);
•	настроить виртуальную машину VM SRV;
•	настроить виртуальную машину VM WS;
•	настроить виртуальную сеть;
•	проверить работу стенда;
•	проанализировать полученный результат.
Установка и настройка программного обеспечения
для работы с ключами eToken
Данная часть работы предназначена для настройки программного обеспечения, не-
обходимого для работы с электронными ключами eToken Для работы с электронными
ключами eToken необходимо установить и настроить программное обеспечение eToken
RTE.
Для выполнения данной части работы необходимо:
•	установить eToken RTE;
•	установить eToken RTE Russian User Interface;
•	проверить работу утилиты «Свойства eToken»;
•	проанализировать полученный результат.
Подготовка ключей eToken
Данная часть работы предназначена для подготовки электронных ключей eToken.
Для использования ключей eToken для аутентификации в среде ОС Windows необходимо
настроить параметры качества PIN-кодов отформатировать ключи и задать PIN-коды
администратора и пользователя.
Для выполнения данной части работы необходимо:
•	установить расширенный режим работы утилиты «Свойства eToken»;
•	отформатировать eToken;
•	настроить параметры ключей eToken;
•	проверить параметры ключей eToken;
•	проанализировать полученный результат
Лабораторная работа N° 1
Задание
1.	Изучить теоретические вопросы, изложенные в начале лабораторной работы
2.	Подготовить стенд.
3.	Установить и настроить программное обеспечение, необходимое для работы с клю-
чами eToken.
4.	Подготовить к работе ключи eToken
5.	Оформить отчет по лабораторной работе.
6.	Ответить на контрольные вопросы.
Порядок выполнения работы
Описание стенда
Для обеспечения проверки возможности настройки режимов работы встроенных
(штатных) средств обеспечения безопасности Windows Server 2003 и Windows ХР, по-
строенных на основе технологий смарт-карт и основных концепциях построения
PKI-систем, на базе Windows Server 2003 СА, ключей и смарт-карт eToken используется
стенд.
В состав тестового стенда входят две виртуальные машины, построенные на основе
VMware 6.0:
1. На базе ОС Windows Server 2003 Enterprise Edition R2 Rus.
2. На базе ОС Windows XP Pro Rus.
Для проведения лабораторной работы используется исходное состояние стенда, по-
строенного на виртуальных машинах VMware 6.0.
Стенд для проведения лабораторных работ представляет собой рабочую станцию,
на которой имитируется работа локальной сети предприятия. Он состоит из рабочей
станции и созданных на ней двух виртуальных машин, работающих под управлением
VMware 6.0. Для удобства дальнейшего изложения материала введены следующие обо-
значения:
•	хост (host) — рабочая станция слушателя;
•	VM SRV — виртуальная машина с операционной системой Windows Server 2003
сервер предприятия;
•	VM WS — виртуальная машина с операционной системой Windows ХР. рабочая
станция предприятия
Для нормального функционирования стенда рекомендуется следующая минимальная
конфигурация рабочей станции:
•	центральный процессор — Pentium 111 1 ГГц;
•	оперативная память — 1 Гб;
•	объем свободного места на жестком диске — 20 Гб;
•	наличие порта USB версии 2.0.
Кроме того, для настройки и последующей работы стенда потребуется следующее
программное обеспечение:
•	операционная система Windows ХР Professional;
•	VMware версии 6.0 или выше;
•	CD-ROM с дистрибутивом (либо образ диска) Windows 2003 Server;
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
•	Microsoft Exchange 2003;
•	CD-ROM с дистрибутивом (либо образ диска) Windows ХР Professional;
•	Microsoft Windows Russian User Interface Pack (для Windows Server 2003 и Windows
XP Professional);
•	eToken RTE 3.65;
•	eToken RTE RUI 3.65.
Установка и настройка стенда
Настройка хоста
Настройка хоста сводится к установке параметров сетевых подключений. Для
установки параметров сетевых подключений выполните на хосте следующие дейст-
вия:
Остановите все виртуальные машины на хосте
Из меню Edit (Редактирование) программы VMware выберите пункт Virtual Network
Settings (Настройки виртуальной сети).
Выберите вкладку NAT и остановите NAT для сети VMNet8, для чего нажмите Stop
Service (Остановить сервис) и затем Применить
Лабораторная работа № 1
лнительно в списке VMNet host выберите пункт Disable (Отключить).
рите вкладку Host virtual Network Mapping
ire адрес для VNNetl.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Задайте адрес для VMNet8
Если на хосте установлен сетевой адаптер и он использует те же параметры сети, что
и виртуальные адаптеры VMware, то на время работы со стендом либо отключите его от
сети, либо в свойствах данного сетевого адаптера выберите пункт Отключить (Disable).
Если же параметры сети сетевого адаптера и виртуальных адаптеров VMware на рЯ"
бочей станции не пересекаются, ничего делать не надо.
На время выполнения практических работ отключите клиента Firewall на хосте
Лабораторная работа № 1
Настройка виртуальной машины VM SRV
Машина VM SRV представляет собой контроллер домена northwind.ru. Полное имя
компьютера — server.northwind.ru.
Характеристики виртуальной машины VM SR V
Ниже приведены минимальные характеристики виртуальной машины:
•	оперативная память — 384 Мб;
•	суммарный объем жесткого диска — 3 Гб;
•	сетевая плата — 2 шт.;
•	устройство CD-ROM (IDE);
•	контроллер USB.
Для нормальной работы виртуальной машины рекомендуется увеличить (по возмож-
ности) объем оперативной памяти, например, до 512 Мб При определении размера опе-
ративной памяти обращайте внимание на минимальные, рекомендуемые и максимально
возможные (исходя из характеристик хоста) значения.
Memory
Specify the amount of memory allocated to this virtual
machine. The memory size must be a multiple of 4 MB.
Memory for this virtual machine:
384
4 А Л A	1792
ZS G uest 0 S recommended minimum:	128M В
Д Recommended memory:	384MB
A Maximum recommended memory:	796MB
(Memory swapping may occur beyond this size)
Настройка сетевых параметров
Для настройки сетевых параметров виртуальной машины VM SRV выполните сле-
дующие шаги:
Откроите файл виртуальной машины в VMware.
В секции Commands (Команды) нажмите Edit virtual machine settings (Редактирование
настроек виртуальной машины).
Для сетевой карты Ethernet в секции Network Connection (Сетевое соединение) уста-
новите значение Custom: Specific virtual network (Другое: Особенная виртуальная сеть) и
в выпадающем списке выберите значение VMNetl (Host-only)
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Аналогично для сетевой карты N1C2 установите значение VMNet8 (Host only).
Нажмите OK.
Загрузите операционную систему на VM SRV
Откройте Пуск -> Настройка —> Панель управления -> Сетевые подключения (Start ->
Settings -> Control Panel -> Network connections).
Переименуйте сетевые подключения на LAN (соответствует адаптеру Ethernet) И
Internet (соответствует адаптеру Ethernet 2)
Лабораторная работа № 1
Вызовите свойства подключения LAN и установите параметры протокола TCP/IP:
Вызовите свойства подключения Internet и установите параметры протокола TCP/IP:
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Настройка виртуальной машины VM WS
Характеристики виртуальной машины VM WS
Ниже приведены минимальные характеристики виртуальной машины:
•	оперативная память — 192 Мб;
•	суммарный объем жесткого диска — 2 Гб;
•	сетевая плата — 1 шт.;
•	устройство CD-ROM (IDE);
•	контроллер USB.
Для нормальной работы виртуальной машины рекомендуется увеличить (по возмож-
ности) объем оперативной памяти, например, до 256 Мб. При определении размера опе-
ративной памяти обращайте внимание на минимальные, рекомендуемые и максимально
возможные (исходя из характеристик хоста) значения.
Настройка сетевых параметров
Для настройки сетевых параметров виртуальной машины VM WS выполните следую-
щие шаги:
Откройте файл виртуальной машины в VMware.
В секции Commands (Команды) нажмите Edit virtual machine settings (Редактирование
настроек виртуальной машины).
Для сетевой карты Ethernet в секции Network Connection (Сетевое соединение) уста-
новите значение Custom: Specific virtual network (Другое: Особенная виртуальная сеть)
и в выпадающем списке выберите значение VMNetl (Host-only).
Загрузите операционную систему на VM WS.
Откроите Пуск -> Настройка -> Панель управления -> Сетевые подключения (Start
Settings -> Control Panel -> Network connections).
258
Лабораторная работа Ns 1
Вызовите свойства подключения LAN и установите параметры протокола TCP/IP:
Настройка виртуальной сети
Присоедините виртуальную машину VM WS к домену VM SRV. Кроме того, в моде-
лируемой сети предприятия создайте несколько пользователей.
Присоединение VM JVS к домену VM SR V
Для присоединения VM WS к домену VM SRV:
•	Загрузите операционные системы виртуальных машин VM SRV и VM WS.
•	Перейдите к свойствам Мой компьютер (Му Computer) системы VM WS.
•	Перевдите на вкладку Имя компьютера (Computer Name) и нажмите Изменить
(Change).
•	Введите имя домена northwind.ru и нажмите ОК.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Укажите имя и пароль учетной записи администратора на системе VM
мите ОК.
После появления окна с подтверждением того, что компьютер присоеди
ну, нажмите ОК. Для того чтобы внесенные изменения вступили в силу, Vl\
буется перезагрузить
После этого вы можете зарегистрироваться на VM WS с помощью учетно
кального администратора либо с помощью учетной записи доменного адм*
Далее, если не будет указано обратное, для входа ВСЕГДА будет использовг
ныи пользователь.
Виод в Windows
Windows
i9es2«»	• - professional
[ ОК 11 Отмена ~| | Завершение работы... 11 Параметры «
260
Лабораторная работа Ns 1
Создание нового пользователя
Для того чтобы создать пользователя выполните следующие шаги %
Запустите на VM SRV Пуск -> Программы -> Администрирование Actjve pjr
Пользователи и компьютеры (Start -> Programs -> Administrative Tools дс^	™ ~
Users and Computers).
В директории Users (Пользователи) создайте нового пользователе
Active D< ectory Us«*rs and Computer*
-JBJx
Консоль Действие 0ид Qkho ^правка
о »|s.m > ю, > g Eii^l(§|	te
Active Dvectory - пользователи и кс
v ____| Сохраненные запросы
- V northwind.ru
я _J Butin
|£ J Computers
Ш <•! Doman Contrders
£ _J ForeignSecurityPnncipals
Users 19 шт.
Делегирование управления...
Найти...
г^Я_________________
С Admostrator
fjcert Pubfchers
fBlMCP Adnmstrst ms
Д DHCP Users
fSDnsAdmins
teProrv
| Тип
Пользователь
Группа безопа.
Группа безопа.
Группа безопа.
Группа безопа
Группа безопа.
Г руппа безопа.
| Описание	'----
fcjt-in account for ”--
Members of this gro V|'
r*embe5 v ho ha-”'
M«mb**s лЬо have ^ir
DNS Admnstrators *** ”
DNS dents who are 7^*
Designated cdnvms* ‘
Создан
1.ид
Новое о»$но отсюда
Обновить
Экспортировать список...
Свойства
^правка
Создание нового объекта...
kJ workstations and *W5,
M domain controlei
kJ domam guests
kJ domain users
:««gnMed edvmsi
Members n this gn> *ors*
 hdl-in account for • •’*
Vyoupfor theHefc "
br-vs in this дгоц J 5<J'
Группа безопа. . Designated adnvnist * “
Пользователь This is a vendor's *
Группа безопа... Members of this gro 
1 ha..
Компьютер
Контакт
Группа
InetOrgPerson
Пс»донич очереди MSMQ
Принтер_______________
Пользователь
Общая папка
________|_388945а0
»। |6?TetnetGents
Задайте ему имя для входа в сеть и нажмите Далее (Next)
Новый объект - Пользователь
Создать в northwindru/Usefs
Имя
Фамилия
Полное имя-
ИНИЦ|1<=»ЛЬ! I
mth.
|Воронцое
| Алексей В оронцов
Имя входа пользователя
avofontsoY
|@northvwnd.ru
Имя ьходj пзльзсАателя (сред-Window. 2000j
|NORTHWIND\
avofontsov
Назад I Далее >
fcj задач. 1
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Задайте пароль для пользователя. Отключите опцию Требовать смену пароля при сле-
дующем входе в систему (User must change password at next logon).
Нажмите Далее (Next) для создания почтового ящика с параметрами по умолчанию.
262
Лабораторная работа Ns 1
Нажмите Готово (Finish).
Для выполнения дальнейших лабораторных работ необходимо по приведенному вы-
ше сценарию создать двух пользователей. Один пользователь будет администратором
Для этого нужно создать пользователя, используя следующие данные:
•	имя: «Admin»;
•	фамилия: «Инициалы вашего имени и фамилии»;
•	имя для входа в сеть: «Абпнп_»Инициалы вашего имени и фамилии».
Второго пользователя нужно создать, используя следующие данные:
•	имя: «User»;
•	фамилия: «Инициалы вашего имени и фамилии»;
•	имя для входа в сеть: «и5ег_»Инициалы вашего имени и фамилии».
Предоставление пользователю прав администратора
Для выполнения практических работ потребуется предоставить созданному пользо-
вателю «Admin »Инициалы вашего имени и фамилии» права администратора. Чтобы это
сделать, выполните следующую последовательность действий:
Запустите на VM SRV Пуск -> Программы -> Администрирование -> Active Directory —
пользователи и компьютеры (Start -> Programs -> Administrative Tools -> Active Directory —
users and computers).
В папке Users выберите группу Администраторы домена (Domain Admins) и правой
клавишей мыши откройте свойства данной группы
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
На вкладке Члены групп (Members) нажмите Добавить (Add).
Лабораторная работа № 1
Введите имя пользователя, которому вы предоставляете права администратора («Admin_»
Инициалы вашего имени и фамилии»), затем нажмите Проверить имена (Check Names).
Если имя пользователя введено верно, нажмите ОК.
После того как пользователь оказался в списке членов данной группы, нажмите ОК.
Свойства: Dorna n Admins
Члены груеты | Ч групп | Управляется |
У лены группы
Имя	Папка Active Drectory___________________
С Admrwttiata__________northwrxjruAJtert_______________________
n<thwndru/Usef<
Добавить I	Уд.адигь
OK | Отмена | Применить
Закройте программу «Active Directory — пользователи и компьютеры».
И 5680
265
ЧАСТЬ Ш ЛАБОРАТОРНЫЕ РАБОТЫ
Установка и настройка программного обеспечения
для работы с ключами eToken
eToken Run Time Environment (eToken RTE) — это среда функционирования уст-
ройств eToken, включающая все необходимые драйверы и утилиту «Свойства еТокеп»
(eToken Properties). С помощью утилиты «Свойства еТокеп» вы можете:
•	осуществлять настройки параметров eToken и его драйверов;
•	просматривать общую информацию относительно еТокеп;
•	импортировать, просматривать и удалять сертификаты и ключевые контейнеры RSA;
•	форматировать eToken;
•	настраивать критерии качества PIN-кодов.
По умолчанию в eToken Run Time Environment 3.65 предусмотрен интерфейс на анг-
лийском языке. При установке пакета eToken Run Time Environment 3.65 Russian User
Interface (eToken RTE 3.65 RU1) язык интерфейса eToken RTE 3.65 изменяется на рус-
ский.
Согласно требованиям для проведения данной части работы необходимо выполнить
следующие действия:
Убедитесь, что на вашем компьютере присутствуют и находятся в рабочем состоянии
порты USB.
Запустите файл RTE_3.65.msi. На экране появится окно приветствия программы ус-
тановки RTE.
В окне приветствия программы установки eToken Run Time Environment нажмите
Next (Далее).
В окне еТокеп Run Time Environment 3.65 Setup/End-User License Agreement озна
комьтесь с Лицензионным соглашением (на английском языке). Если вы согласны с его
условиями, выберите I accept the license agreement (Я принимаю условия лицензионного
266
Лабораторная работа N° 1
соглашения) и нажмите Next (Далее) для того, чтобы продолжить установку. Если вы не
согласны с условиями лицензионного соглашения, нажмите Cancel (Отмена), а в по-
явившемся окне — Yes (Да), чтобы выйти из программы установки.
iT еToken Run lime Environment 3 65 Setup
X
End-User License Agreement
Please read the fcVovsng Seen* в agreer-er* 1 c irefu ly
elblen RTF
Your Key to «Security ' 
ALADDIN KNOWLEDGE SYSTEMS LTD.
eTOKEN ENTERPRISE END USER LICENSE AGREEMENT
IMPORTANT INFORMATION - PLEASE READ THIS AGREEMENT
CAREFULLY BEFORE OPENING THE PACKAGE AND/OR USING
THE CONTENTS THEREOF AND/OR BEFORE DOWNLOADING OR
INSTALLING THE SOFTWARE PROGRAM ALL ORDERS FOR AND
USE OF THE eTOKEN ENTERPRISE PRODUCTS (including without
limitation, libraries, utilities, diskettes, CD-ROM, eToken“* keys and the
accompanying technical documentation) (hereinafter “Product^) SUPPLIED v
QI accept the hcense agreement
ОI do not accept the license agreement
[ < Back | Next > j [ Cancel ]
Отсоедините все eToken от компьютера и в окне eToken Run Time Environment 3.65
Setup/Ready to Install the Application нажмите Next (Далее).
I Г eToken Run Time Environment 3.65 Setup
Ready to Install the Application
Click Next to begr mstalation.
eToicen RTP
Your Key to «Security । *
Please click Next to begin uistataooiL
[ < Back | Next >	] [ Cancel
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
Подождите некоторое время, пока программа завершит установку. После завершения
установки появится окно с сообщением eToken Run Time Environment 3.65 has been sue
cessfiilly installed. Нажмите Finish (Готово).
Для удобства дальнейшей работы необходимо установить русификацию драйвера
eToken RTE. Для того чтобы установить eToken RUI, выполните следующее:
Запустите программу установки eToken RUI (RTE_3.65.RUI.msi). На экране появится
окно приветствия программы установки.
В окне приветствия программы установки eToken RUI нажмите Далее.
IJ еТокеп RTL 3.65 Russian 1к%г Interface - IrntadlSMeld Wizard
еТокегг
Your K«y to «Security
RTE
Вас приветствует программа Installshield
Wizard для eToken RTE 3.65 Russian User
Interface
Программа InstallShield(R) Wizard выполнит установку
eToken RTE 3.65 Russian User Interface на компьютер. Для
продолжения нажмите кнопку "Далее".
П'^ЕДУГРЕЖДЕНИЕ: Даннаящ:о’рамма«ащкщ',назаконами
об авторских правах и международными соглашение*..
Ма>ад Далее >	| [ Отмена ]
Лабораторная работа No 1
В окне eToken RTE 3.65 Russian User 1п(егТасе\Готова к установке программы наж-
мите Установить.
Дождитесь завершения установки. После завершения установки eToken RUI в окне
eToken RTE 3.65 Russian User Interface/Программа InstallShield Wizard завершена наж-
мите Готово.
ЧАСТЫП ЛАБОРАТОРНЫЕ РАБОТЫ
Подготовка ключей eToken
Для того чтобы иметь доступ к полным возможностям утилиты «Свойства eToken»,
выполните следующие действия:
Нажмите Пуск -» Выполнить (Start Run) В появившемся окне в строку ввода Открыть
(Open) введите regedit для запуска программы редактора реестра
В окне редактора реестра выберите ветвь \HKEY_LOCAL_MASHINE\SOFTWARE\
Aladdin\eToken\eTProperties.
Укажите в области Система счшсления (Base) значение Шестнадцатеричное
(Hexadecimal) Присвойте параметру Advanced значение f.
Лабораторная работа Ns 1
Закройте окно редактора реестра.
Для того чтобы виртуальная машина могла использовать устройства USB (в частнос-
ти eToken), подсоединенное к компьютеру, на котором эта машина запушена:
Выберите в VMware окно виртуальной машины, в которой вы хотите использовать
eToken. Из меню программы VMware выберите VM/Removable Device/USB
Portl/Anonymous USB Device (...)
При появлении следующего окна нажмите ОК.
Windows ХР Professional
A USB device is about to be unplugged from the host and connected to this virtual machine
It will first be stopped to enable safe removal With some devices the host may display the
message "The device can now safely be removed"
□ Never show this hint again
OK I [ Cancel |
В будущем, чтобы исключить появление данного окна, установите флажок Never
show this hint again (Никогда больше не предупреждать об этом).
После завершения обработки нового оборудования на ключе загорится световой ин-
дикатор.
Для того чтобы убедиться в том, что подключенный eToken готов к работе, выполните
следующую последовательность действий:
В Windows XP/Server 2003 запустите Пуск Настройка -> Панель управления -►
Администрирование -► Управление компьютером (Start —> Settings —> Control Panel —>
administrative Tools -> Computer management).
Убедитесь в том, что в дереве консоли присутствует узел Smart card readers, а в нем —
один или более Aladdin IFD Handler, а также USB Token в разделе USB controllers.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Для дальнейшего выполнения работы необходимо отформатировать ключи eToken,
используемые для выполнения лабораторной работы Для того чтобы отформатировать
eToken PRO, выполните следующее:
Нажмите Пуск -> Программы (Все программы) -> eToken Properties (Start -> Programs
(All Programs) eToken Properties) В окне утилиты «Свойства eToken» выберите
eToken для форматирования.
Лабораторная работа № 1
Нажмите кнопку Форматирование.
Для изменения параметров форматирования, принятых по умолчанию, нажмите Па-
раметры. Появится окно Параметры форматирования eToken.
Для форматирования eToken с созданием Aladdin File System (файловой системы
Aladdin) оставьте пункт Инициализировать eToken отмеченным.
В секции Назначение PIN-кода оставьте значения полей PIN-код и Подтверждение
по умолчанию (1234567890).
ЧАСТЬ Ш ЛАБОРАТОРНЫЕ РАБОТЫ
Задайте пароль администратора Для этого установите флажок Задать пароль од»
нистратора и введите пароль (1234567890) в поля Пароль и Подтверждение.
Выберите вкладку Настройки.
274
Лабораторная работа Ns 1
В поле Цвет eToken выберите соответствующий цвет значка eToken.
В разделе Счетчики неудачных попыток ввода задайте количество неправильных по-
пыток ввода PIN-кода и пароля администратора равным 15
Выберите вкладку Ключ форматирования
Проверьте, что в разделе Текущий ключ форматирования отмечен пункт Ключ фор-
матирования по умолчанию, а в разделе Новый ключ форматирования не отмечен пара-
метр Назначить ключу форматирования значение.
Внимание! Назначение ключа форматирования может иметь необратимые
последствия.
Нажмите ОК.
В окне Форматирование eToken нажмите Запустить.
ЧАСТЫ11 ЛАБОРАТОРНЫЕ РАБОТЫ
Для начала форматирования в окне Свойства eToken с предупреждением о потере
данных при форматировании нажмите ОК
Процесс форматирования будет отображаться в окне Форматирование eToken. Дож-
дитесь завершения процесса форматирования.
По окончании форматирования появится сообщение об успешном завершении фор-
матирования. Нажмите ОК.
Закройте утилиту «Свойства eToken».
Для дальнейшего выполнения лабораторной работы необходимо настроить парамет-
ры работы ключей eToken. Для этого выполните следующее:
Нажмите Пуск -> Программы (Все программы) -> eToken -> eToken Properties (Start ->
Programs (All Programs) -> eToken/eToken Properties).
Примечание, В процессе работы с программой, для внесения изменений в пара-
метры eToken, необходимо будет ввести его PIN-код. После его ввода вы можете вно-
сить необходимые изменения в различных окнах программы, пока вы не выйдите из про-
граммы.
После запуска программы в окне Свойства eToken отображается общая информация
относительно выбранного eToken:
цвет и имя eToken, в строке Имя считывателя — устройство чтения (физическое или
виртуальное), в строке Модель — модель eToken.
276
Лабораторная работа № 1
Для дальнейшего выполнения лабораторной работы необходимо сменить пользова-
тельские PIN-коды (заданные по умолчанию) на используемые в лабораторной работе
ключи eToken. Используйте простые пароли, например 123456 или 654321. Для этого вы-
полните следующее:
Для смены PIN-кода нажмите Сменить PIN-код,..
В окне Свойства eToken введите текущий PIN-код в поле Текущий PIN-код (по умол-
чанию 1234567890), а новый PIN-код — в поля Новый PIN-код и Подтверждение:
—	в окне справа отображается качество задаваемого вами нового PIN-кода, оно должно
быть в «зеленой зоне», в противном случае заданное вами значение не будет принято:
—	если вы нажмете кнопку Показать рекомендации, вы увидите текущие требования
по качеству пароля, которым он должен соответствовать.
Нажмите ОК (Кнопка ОК неактивна до тех пор. пока не введена удовлетворительная
информация в поля Новый PIN-код и Подтверждение).
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
В случае успешной смены PIN-кода на экране появится окно с сообщением PIN-код
успешно изменен При появлении этого окна нажмите ОК.
Свойства eToken

PIN-код успешно изменён.
Для дальнейшего выполнения лабораторной работы необходимо переименовать ис-
пользуемые ключи eToken,
Для смены PIN-кода нажмите Переименовать..., При необходимости введите теку-
щий PIN-код.
Внесите изменения в поле Имя eToken (обычно в имени eToken используется имя его
владельца и/или назначение).
Примечание. Не рекомендуется использовать в имени eToken русские буквы.
Задайте имя для первого eToken в формате: «Admin»_»Bania фамилия».
Задайте имя для второго eToken в формате: «User»_»Bama фамилия».
Для настройки требований, накладываемых на предприятии на качество PIN-кодов
eToken и паролей администратора, служит пункт Качество паролей из состава утилиты
«Свойства eToken*.
Информация о качестве PIN-кодов и паролей хранится в файле etpass.ini. располо-
женном в системной папке %systemroot%\system32 (по умолчанию —
C:\WINDOWS\System32). Программа позволяет создавать и редактировать конфигура-
ционные файлы для их последующего распространения среди пользователей eToken.
Требования к качеству PIN-кода и пароля администратора общие Поэтому для крат-
кости при описании задания критериев качества будем использовать термин пароль. Тре-
бования задаются путем задания критериев качества пароля.
Для запуска настройки параметров качества паролей eToken запустите утилиту
«Свойства eToken», нажав Пуск -> Программы (Все программы) -> eToken -> eToken
Лабораторная работа No 1
Properties (Start —> Programs (AU Programs) -> eToken -> eToken Properties) и выберите
на вкладке Компьютер пункт Качество паролей.
В открывшемся окне Настройка параметров качества паролей eToken можно просмат-
ривать и изменять значения параметров, влияющих на качество паролей, а таюке выяв-
лять качество текущих паролей.
Для того чтобы проверить соответствие пароля выбранным критериям, введите па-
роль в строку Проверка качества введенного пароля.
Под строкой Проверка качества введенного пароля в процентах условно отображается
качество введенного пароля согласно критериям файла etpass.ini. В нижнем поле окна
выводится информация о причинах несоответствия введенного пароля этим критериям.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
На хосте создайте свои настройки качества паролей eToken, используя утилиту
«Свойства еТокеп».
С помощью программы Notepad (Блокнот) откройте файл c:\windows\system32\etpass.ini
и внесите дополнительные изменения, усиливающие качество паролей.
Установите единые установки критериев качества паролей на все машины. Для этого
скопируйте файл etpass.ini на VM WS и VM SRV в директорию c:\windows\system32\.
Для того чтобы убедиться в применении заданных критериев качества паролей
(PIN-кода) eToken, необходимо в утилите «Свойства еТокеп» изменить пароль и попы-
таться задать пароль, не удовлетворяющий заданным критериям качества.
Результат тестирования критериев качества паролей можно считать положительным,
если не удается изменить пароль пользователя на пароль, заведомо этим критериям не
удовлетворяющий.
Содержание отчета
Отчет оформляется один на бригаду из одного-двух исполнителей.
В отчете с титульным листом установленной формы (Приложение А) необходимо
представить следующие сведения:
1.	Наименование и цели работы.
2.	Краткую характеристику учебного стенда (по составу доступных пользователю
функций управления и индикаций, распределению ресурсов, функций, вариантов
набора преобразований)
3.	Функциональную схему учебного стенда с пояснениями и комментариями.
4.	Заданные критерии качества паролей eToken, установленные в ходе выполнения ра-
боты.
5.	Подготовиться для устных ответов на контрольные вопросы
Контрольные вопросы
1.	Как подготовить к работе учебный стенд?
2.	Как ввести в действие учебный стенд?
3.	Каковы признаки готовности учебного стенда?
4.	Каким образом можно инициализировать eToken?
5.	Каким образом можно задать сложность пароля для eToken?
6.	Каким образом можно распространить критерии качества пароля eToken на другие
компьютеры?
Лабораторная работа № 1
Приложение А
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
ПОДГОТОВКА СТЕНДА, УСТАНОВКА И НАСТРОЙКА ПО,
ПОДГОТОВКА ЭЛЕКТРОННЫХ КЛЮЧЕЙ eToken
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
Выполнили:
Студенты гр._______________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
Лабораторная работа № 2
УСТАНОВКА И НАСТРОЙКА ЦЕНТРА
СЕРТИФИКАЦИИ, ИСПОЛЬЗОВАНИЕ КЛЮЧЕЙ
ETOKEN В ДОМЕНЕ WINDOWS SERVER 2003
Цель работы
Для выполнения работ по теме «Обеспечение безопасности доступа к данным ин-
формационной системы организации с помощью продуктов Microsoft и Aladdin. Типо-
вые решения» установить и настроить Центр сертификации Windows Server 2003 СА
и научиться использовать электронные ключи eToken для аутентификации пользовате-
лей в домене Windows Server 2003.
Общие сведения об аутентификации пользователей
в домене Windows Server2003 с помощью цифровых сертификатов
и ключей eToken
Инфраструктура открытых ключей (PKI)
Основой построения инфраструктуры открытых ключей (PKI) на базе Windows Server
2003 является Центр сертификации (Certification Authority, СА) — один из компонентов
сервера Windows Server 2003. Центр сертификации получает и обрабатывает запросы на
издание цифровых сертификатов (Х.509), идентифицирует и подтверждает такие запросы,
издает сертификаты, используя шаблоны сертификатов, обновляет и аннулирует серти-
фикаты, публикует сертификаты, создает и обрабатывает Списки аннулированных сер-
тификатов (Certificate revocation lists, CRLs), а также сохраняет в журнале все операции
с сертификатами.
Центр сертификации (СА) также выполняет операции по хранению и восстановле-
нию закрытых ключей.
СА интегрирован со службой каталогов (Active Directory, AD) и использует AD для
получения информации о пользователях и для хранения ключевых контейнеров.
При использовании электронных ключей eToken СА позволяет копировать цифро-
вые сертификаты и закрытые ключи в защищенную память eToken
Описание работы
Для изучения возможностей Microsoft Windows Server 2003 СА и электронных ключей
eToken для обеспечения аутентификации пользователей в домене Windows Server 2003
и безопасности доступа к данным информационной системы работа делится на две части.
•	установка и настройка Центра сертификации (СА), подготовка его консоли, из-
дание сертификатов;
•	использование ключей eToken для регистрации в домене, для запуска приложений
от имени другого пользователя и для подключения сетевых дисков с использова-
нием прав доступа другого пользователя
282
Лабораторная работа № 2
Установка и настройка Центра сертификации (СА),
подготовка консоли Центра сертификации, издание сертификатов
Данная часть работы предназначена для установки и настройки Центра сертифика-
ции, подготовки к работе консоли Центра сертификации и издания сертификатов, ко-
торые будут использоваться при выполнении основной части лабораторной работы. Для
выполнения данной части работы необходимо:
Установить Центр сертификации на виртуальную машину VM SRV
Настроить Центр сертификации:
•	Создать шаблон сертификата.
•	Включить шаблоны сертификатов.
Настроить консоль Центра сертификации:
•	Установить пакет Windows Server 2003 Administration Tools.
•	Подготовить консоль Центра сертификации.
•	Подготовить консоль управления доменными политиками.
•	Установить групповую политику для автоматической выдачи сертификатов
Издать сертификаты:
•	Настроить станцию выписки сертификатов.
•	Добавить Центр сертификации в список доверенных узлов.
•	Подготовить консоль управления сертификатами.
•	Получить сертификат агента получения заявок.
•	Издать сертификаты с помощью агента получения заявок.
•	Издать сертификаты без помощи агента получения заявок.
•	Скопировать сертификаты с закрытыми ключами на eToken.
•	Проверить работу стенда.
•	Проанализировать полученный результат.
Использование ключей eToken для регистрации в домене,
для запуска приложений от имени другого пользователя
и для подключения сетевых дисков с использованием прав доступа
другого пользователя
Данная часть работы предназначена для обучения использованию ключей eToken при
выполнении основных операций по безопасному доступу к информационным ресурсам
домена Windows Server 2003 — регистрация пользователя в домене, запуск приложений
и подключение сетевых дисков от имени другого пользователя с использованием элек-
тронных ключей eToken. Для выполнения данной части работы необходимо:
•	Выполнить регистрацию в домене с помощью eToken
•	Установить для пользователя требование использования смарт-карты при инте-
рактивном подсоединении к компьютеру.
•	Установить групповую политику требования использования смарт-карты при ин-
терактивном подсоединении к компьютеру.
•	Установить блокирование компьютера и принудительный выход пользователя
при отключении eToken.
Выполнить запуск приложений от имени другого пользователя:
•	С использованием графического интерфейса.
•	С использованием командной строки.
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
Выполнить подключение сетевых дисков с использованием прав доступа другого
пользователя:
•	С использованием графического интерфейса
•	С использованием командной строки.
Проанализировать полученный результат.
Задание
1.	Изучить теоретические вопросы, изложенные в начале данной лабораторной работы.
2.	Установить и настроить Центр сертификации.
3.	Выписать сертификаты, скопировать их в ключи eToken.
4.	Выполнить регистрацию пользователя в домене с использованием eToken.
5.	Выполнить запуск приложений от имени другого пользователя с использованием
eToken.
6.	Выполнить подключение сетевых дисков с использованием прав доступа другого
пользователя с использованием eToken
7.	Оформить отчет по лабораторной работе.
8.	Ответить на контрольные вопросы.
Порядок выполнения работы
Установка Центра сертификации
Для установки Центра сертификации на контроллер домена выполните следующие шаги
Зарегистрируйтесь на компьютере VM SRV под именем пользователя с правами адми-
нистратора.
Выполните Пуск -» Настройка —> Панель управления —> Установка и удаление про-
грамм (Start -> Control Panel * Add or Remove Programs).
Нажмите Установка компонентов Windows (Add/Remove Windows Components).
Выберите пункт Certificate Services и нажмите Далее (Next).
[мастер компонентов Windows
Компоненты Windowi
бы монете добавить или удалить компоненты\VrxJows
Чтобы добавить или удаытъ компонент установите или снимите Флажок
Затенена,*! флажок означает частичную установку компонента. выяснеть его
состав позволяет кнопка Состав
Компоненты:
|< ^jAccwicmiandUtAtw.	4 5 МБ
flotation Server	_____________________24 6 МБ —
а с -Certteate Service___________________________________________4 МБ
[ gEmad Serves»	U МБ
ф”1 .бвРлв	22 Л MR ZJ
Описан* InstA a cert^cabon authority (СА) to issue сегЫюаг' for use vrfh
pubic key security programs
Гребуется на диске	2 9 МБ	£остаь |
Свободно на д иске	1252,6 МБ	------------
284
Лабораторная работа Ns 2
Появится предупреждающее сообщение о том, что после установки Центра серти-
фикации на сервер нельзя будет изменить имя сервера (имя его домена) Если имя сер-
вера уже установлено и меняться не будет, нажмите Да (Yes).
После установки службы сертификатов изменять имя компьютера и
принадлежность к домену будет нельзя так как имя комгъютера пр»вязамо к
данным о ЦС, хранящимся в Active Dvectory. Измене! не имени компьютера или
принадлежности к домену может сделать недействительными сертификаты,
выданные в ЦС. Прежде чем устанавливать службу сертификатов, убедитесь,
что имя компьютера и принадлежность к домену заданы правильно
Продолжить?
В окне Мастер компонентов Windows (Windows Components Wizard) нажмите Далее (Next).
Выберите пункт Корневом ЦС предприятия (Enterprise root СА) и нажмите Далее (Next).
Мастер компонентов Window*
Тип ЦС
Выберите	тит устанавчеа»<у о UC.
J ЦС предприятия
Г Подчиненный ЦС гредгриятия
С Изолированный корневой ЦС
С Изолированным подчиненюяй ЦС
Описание типа ЦС
Наиболее доеереньый ЦС на предприялас Он должен быть установлен
ранее всех других ЦС.
F V1 <зеленные параметры создания пары ключей и сертификата ЦС
<Назад | Далее? ~| Отмена | Справка |
Задайте Общее имя для этого ЦС (Common name). Для задания имени ЦС исполь-
зуйте инициалы имени и фамилии + Root. Затем нажмите Далее (Next)
[мастер компонентов Windows
Сведения о центре сертификации
Введите сведения об этом центре сертификации
Общее имя для этого ЦС
|DS Root
£уФФк.с р сличающегося 1меты_________________________
DC-northwncLDC-fu
Просмотр различающегося w.
CN-DS Root DC-northwndDC-<u
Срок действия	Истекает
I R 2	21.08.20111Б15
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Нажмите Далее (Next).
БД сертификатов.
Журнал м * сертификатов
|с W/INDOWSMyrtcm'CSCrtLoo	Ofisop
Г” £оф»мп> ьгэаения о конФктоащы в общей папке
*та<пг>к
<Назад. | Далее» | Отмена | Справка |
Появится предупреждение, что служба IIS будет временно остановлена Нажм
Да (Yes).
Для продолжения потребуется дистрибутив Windows 2003 Server. При работе с
SRV необходимо будет подключить образ данного диска к этой виртуальной мапв
Для этого вам понадобится ISO-образ данного диска (либо установочный CD-ROM
Из меню программы VMware, в которой у вас запущена VM SRV, выберите VM
Settings После этого появится окно Virtual Machine Control Panel. На закладке Hardv
выберите CD-ROM, укажите путь к образу диска, установите опцию Device statu
Connected Нажмите OK.
286
Лабораторная работа Ns 2
Примечание, Система установки автоматически обнаружит появление
CD-ROM и скопирует необходимые ей файлы. Также возможно выполнение опции
автозапуск (autorun) для данного CD-ROM, вызывающее приглашение инсталлятора
Windows 2003 Server (Welcome to Microsoft Windows Server 2003). При появлении дан-
ного приглашения закройте его.
После окончания установки нажмите Готово (Finish) Закройте программу
Add/Remove Programs
Перезагрузите сервер, либо выполните следующие команды из командной строки
(используйте Пуск -> Выполнить -> cmd (Start Run cmd)):
—	certutil —pulse;
—	gpupdate /force;
—	certutil -pulse.
Настройка Центра сертификации
Для удобства работы и максимально эффективного применения возможностей
Windows Server 2003 при настройке Центра сертификации будут созданы шаблоны сер-
тификатов, которые используются при издании сертификатов пользователей:
•	Aladdin Smartcard User — предназначается для входа в сеть со смарт-картой (Smart
Card Logon), аутентификации клиента (Client Authentication) и защищенной элек-
тронной почты (Secure Mail);
•	Aladdin Smartcard Logon — предназначается для входа в сеть со смарт-картой
(Smart Card Logon) и аутентификации клиента (Client Authentication);
•	Aladdin Exchange User — предназначается для защищенной электронной почты
(Secure Mail).
Создание и последующее использование шаблона делает удобным процесс выпуска
сертификатов и минимизирует возможные ошибки агентов подачи заявок.
На компьютере, с которого осуществляется создание данных шаблонов, должен быть
установлен eToken RTE. Это необходимо для того, чтобы был доступен поставщик крип-
тографических средств (CSP) eToken Base Cryptographic Provider. Именно этот CSP будет
использоваться при издании сертификатов
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
Создание шаблона сертификата
Для того чтобы создать шаблон сертификата Aladdin Smartcard User, выполните еле
дующее:
Запустите консоль Центра сертификации Пуск -> Программы -> Администрирование -
Центр сертификации (Start -> Programs -> Administrative Tools -> Certification Authority)
Выберите Центр сертификации, который вы хотите настроить.
Щелкните правой кнопкой мыши на Шаблоны сертификатов (Certificate Templates
и выберите Управление (Manage)
В окне certtmpl — [Certificate Templates] выберите шаблон Пользователь со смарт-карто
(Smartcard user), щелкните правой кнопкой мыши и выберите Скопировать табло
(Duplicate Template).
288
Лабораторная работа N? 2
В окне Свойства нового шаблона (Properties of New Template) на закладке Общие
(General) в поле Отображаемое имя шаблона (Template display name) введите Aladdin
Smartcard User.
Свойства нового н блонт
Jjxl
Tрайсммн аммчи | Вьпцдмшыа шаблоны | Prwpw | Безопасность |
Общие | Обработка запроса | Имя субъекта |
Отображаемое имя шаблона
|Alad4 т Smartc srd U
Минимально поддерживаемые НС
Wixfowu Server 2СОЗ ErterprueEdncn
После применен и»**мк сделанные на этой вкладке
изменить имя шаблона будет невозможно
И“яш*г era.
puadtkrSmartcardUser
Периса действия	Период обновления
I ^|лет jd | Б |недель 3
|7 Одуб ковать сертификат в Active Drectory
Г Hfi использовать автоматическую перезаявку если такой
сертификат уже существует в Active D«ecto»y
ОК | Отмена | Применить
Откройте закладку Обработка запроса (Request Handling). Назначьте параметру Ми-
нимальный размер ключа (Minimum key size) значение 1024 Нажмите Поставщики
(CSPs).
Свойства нового ш биона
Т * Г выд-м | гt--смеетешаблоны | Расширения| Безопасность|
Общие	Обработка запроса | Имя субъекта
Цель	| Подпись и шифрование
Г" Лавировать закрытый ключ субъекта
I? Включить симметричные алгоритмы, разрешение субъектом
Г” . ляг - • -нн еили < ен • есести; .--.аты не , > • .я
Минимальный размер ключа. 11024
П Е^зреиаль экспортировать закрытый ключ
При подаче заявки для субъекта и использовании закрытого ключа
его сертификата следует
<• Подавать заявку для субъекта не требуя ввода данных
С Запрашивать пользовате/м во время подачи мивки
Запрашивать пользователя и требовать ответа при
использовании закрытого ключа
Для настрсйки списка поставшиков служб	7
кр кгп-л ^Фиы (Г-Pj нажмите чкепку	1	• I
’Посгавщикй"
OK I Отмена I Применить
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Выделить CSP (CSP Selection) выберите Запросы должны использовать один
из следующих CSP (Requests must use one of the following CSPs).
В списке Поставщики служб криптографии (CSPs) выберите eToken Base
Cryptographic Provider и нажмите OK.
Примечание. Этот CSP присутствует в списке, только если на компьютере,
с которого осуществляется настройка создаваемого шаблона, установлен eToken RTE.
В окне Свойства нового шаблона (Properties of New Template) откройте вкладку Тре-
бования выдачи (Issuance Requirements).
CboncTBd нового ммбяона
Обшив | Обработка запроса |	Имя субъекта
Требования | Вытесняемые шаблоны | Расширения | Безопасность
Т ребоваггь для подачи заявок
Г” Одобрения диспетчера сертификатов ЦС
Р Указанного числа авторизован»*» подписей. |~
Если требовать более одной подписи автоподача заявок не
будет разрешена
В подписи требуется указать рп по/ыгжи
| Политика прямее еения	]
родилка	____________________________________
[Агент запроса сертификата	-
Политики; д
I	л,-. I
Требсвать для г- горной подачи заявок	•
Р Тех аеуслое»Л. что и для подале заявок
Г Подтвердить садествуоший сертификат
ОК 11 Отмена ~~| Применить
Поставьте флажок Указанного числа авторизованных подписей (This number of
authorized signatures) и убедитесь, что этот параметр принимает значение 1.
Убедитесь, что параметр В подписи требуется указать тип политики (Policy type
required in signature) принимает значение Политика применения (Application Policy)
Из списка Политика применения (Application Policy) выберите Агент запроса серти-
фиката (Certificate Request Agent).
290
Лабораторная работа № 2
В окне Свойства нового шаблона (Properties of New Template) нажмите OK.
Убедитесь в том, что шаблон Aladdin Smartcard User появился в списке Шаблоны сер-
тификатов (Certificate Templates).
Закройте окно certtmpl — [Certificate Templates].
Для выполнения лабораторной работы создайте шаблоны сертификатов в соответст-
вии с указанными ниже параметрами, остальные параметры оставьте без изменений:
Имя шаблона	Параметры шаблона			
	Базовый шаблон	Обработка запроса		Требования выдачи
		Минимальный размер ключа	CSP	
Aladdin Smartcard User Цель:	Пользователь со смарткартой (Smartcard User)	1024	eToken Base Cryptographic Provider	Указанное число авто- ризованных подписей: 1 Тип политики:политика применения Политика применения: агент запроса сертифи- ката
Aladdin Smartcard Logon	Вход со смарткартой (Smartcard Logon)		eToken Base Cryptographic Provider	
Aladdin Exchange Sign & Encrypt Цель: подпись и шифрование	Пользователь Exchange (Exchange User)		Microsoft Enhanced Cryptographic Provider	—
Включение шаблонов сертификатов
После того как шаблон сертификата создан, его необходимо включить. Для включе-
ния шаблона сертификата, выполните следующее:
Запустите консоль Центра сертификации Пуск Программы Администрирование -»
Центр сертификации (Start -» Programs -> Administrative Tools —> Certification Authority).
Выберите Центр сертификации, который вы хотите настроить.
В череве консоли щелкните правой кнопкой мыши Шаблоны сертификатов
(Certificate Templates) и выберите Создать (New). Щелкните Выдаваемый шаблон серти-
фиката (Certificate Template to Issue).
ЧАСТЫП ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Включение шаблонов сертификатов (Enable Certificate Templates) выберите
шаблон Aladdin Smartcard User и нажмите OK
 Включе>ые шаблонов сертификат**
Выберите один wv несколько шаблонов сертифксалгое для
использования на этом центре сертификации (UQ
Имя
। Назначение"
Aladdr Stnattcatd Uset
Q3 -ЕР шифрование
03 IPSEC
®'PSEC [автономный запрос)
jJ RAS и IAS-сервер
03 Агент восстановления ключ
Агент запроса сертификата*
IKE-посредн* IP-беэоласяо
IKE-посреди* IP Ав «опасно
Проверка подлинности клие
Агент восстановления ключ,

Отмена |
Для выполнения лабораторной роботы включите созданные шаблоны сертификатов
Aladdin Smartcard User, Aladdin Smartcard Logon, Aladdin Exchange Sign & Encrypt и шаб-
лон сертификата агента подачи заявок (Enrollment Agent).
Установка пакета Windows Server 2003 Administration Tools
Настроить Центр сертификации вы можете как на самом сервере, так и с любого
компьютера, входящего в домен. Компьютер, с которого осуществляется настройка
Центра сертификации, должен работать под управлением операционной системы
Windows Server 2003 или Windows ХР Professional. В последнем случае на компьютере
должен быть установлен пакет Windows Server 2003 Administration Tools. Для того чтобы
установить этот пакет, выполните следующее:
1.	Подключите диск с дистрибутивом Windows Server 2003 к виртуальной машине VM
WS. Для этого вам необходим образ данного диска.
2.	Из меню программы VMware выберите VM -> Settings После этого появится окно
Virtual Machine Control Panel. На закладке Hardware выберите CD-ROM, укажите путь
к образу диска, установите опцию Device status — Connected. Нажмите OK.
292
Лабораторная работа Ns 2
Примечание. Система автоматически обнаружит появление компакт-диска,
запустится опция autorun для данного CD-ROM, появится приглашение инсталля-
тора Windows 2003 Server. Закройте его.
3.	Из директории <CD-ROM>\I386 запустите файл adminpak.msi. В окне приветствия
мастера установки Windows Server Administration Tools Pack нажмите Next (Далее).
4.	Нажмите Finish для завершения установки.
293
ЧАСТЫМ ЛАБОРАТОРНЫЕ РАБОТЫ
Подготовка консоли Центра сертификации
Для подготовки консоли управления Центром сертификации выполните следующие шаги-
Зарегистрируйтесь на компьютере под именем доменного администратора.
Запустите программу Пуск -> Выполнить -> mmc (Start -> Run -> mmc).
Запуск программы
Введите имя программы, папки, документа или
ресурса Интернета, и Windows откроет их.
Открыть: mmc
OK j [ Отмена ] | Обу)р..~
В меню Консоль (Console) выберите Добавить или удалить оснастку (Add/Remove snap-in).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите Добавить (Add).
Лабораторная работа № 2
В окне Добавить изолированную оснастку (Add Standalone snap-in) выберите
Certification Authority и нажмите Добавить (Add)
В окне Certification Authority выберите Another computer и введите имя сервера, на ко-
тором установлен СА.
Нажмите Готово/Finish.
В окне Добавить изолированную оснастку (Add Standalone snap-in) нажмите Закрыть
21ose).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите ОК
Сохраните настройки консоли на рабочем столе (Консоль ЦС).
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Подготовка консоли управления доменными групповыми политиками
Если на вашем компьютере нет готовой консоли для управления доменными
повыми политиками, подготовьте ее, выполнив следующие шаги:
Зарегистрируйтесь на компьютере под именем доменного администратора
Запустите программу Пуск -> Выполнить -> mmc (Start -> Run -> mmc).
В меню Консоль (Console) выберите Добавить или удалить оснастку (Add/Remove
snap-in).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите Добавить (Add)
В окне Добавить изолированную оснастку (Add Standalone snap-in) выберите Редактоп
объектов групповой политики (Group Policy Object Editor) и нажмите Добавить (Add)
KONCOl

»орень
Изолированная оснастка
Используется для добавления или удаления и олировакюй оснастки
Оснастки
Описание
Делить
| Расширения |
В появившемся окне выберите с помощью кнопки Обзор (Browse) выберите Default
Domain Policy (Политика домена по умолчанию)
296
Лабораторная работа № 2
Нажмите Готово (Finish).
В окне Добавить изолированную оснастку (Add Standalone snap-in) нажмите
Закрыть (Close).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите ОК.
Сохраните настройки консоли на рабочем столе (Domain policy)
Установка групповой политики
для автоматической выдачи сертификатов
Для того чтобы пользователи могли переиздавать сергифлкаты автоматически
(reenrollment), кроме настроек Центра сертификации отредактируйте соответствующий
объект групповой политики.
Зарегистрируйтесь на компьютере под именем доменного администратора.
Запустите созданную ранее консоль Domain Policy
Отредактируйте объект групповой политики Конфигурация пользователя Конфи-
гурация Windows -> Параметры безопасности -> Политики открытого ключа —> Параметры
автоматической подачи заявок (User Configuration -> Windows Setting -> Security Settings ->
Public Key Policies Autoenrollment Settings):
—	выберите Подавать заявки на сертификаты автоматически (Enroll certificates
automatically);
—	установите флажок Обновлять сертификаты с истекшим сроком действия, обнов-
лять отозванные и устанавливать сертификаты в состоянии ожидания (Renew expired
certificates, update pending certificates, and remove revoked certificates);
—	установите флажок Обновлять сертификаты hi основе шаблонов сертификатов
(Update certificates that use certificates templates).
Примечание. Данный объект можно использовать как < доменных политиках,
так и в политиках, применяемых к отдельным подрс <деленuim.
Чтобы обновленная политика начала действовать немедленно, выполните на контр-
оллере домена команду gpupdate /force.
I?5680
297
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Издание сертификатов
Для издания сертификатов пользователей необходимо настроить станцию выписки
сертификатов и получить сертификат агента получения заявок. Выписывать сертифика-
ты можно как с помощью агента получения заявок, так и без него.
Кроме того, необходимо произвести настройку хоста для выписки сертификатов на
устройство eToken Необходимость настройки хоста вызвана особенностями работы
VMware с портами USB. Для настройки хоста требуется внести изменения в реестр
Windows, чтобы это сделать выполните следующие шаги:
Создайте в программе Notepad («Блокнот») или любом другом текстовом файле файл
данных реестра (Registration Entries, *.reg), например vm_usb_correct,reg.
Введите следующий текст:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmusb\Parameters]
@=””
"Powerstate0n0pen”=dword:00000000
”PowerStateOnClose"=dword:00000000"
"Enable Remote Wakeup”=dword:00000001
" MinPowerState U sed"=dword:00000003
"MinPowerStateUnused"=dword:00000003
"AbortPi pesOnPowerDown"=dword:00000001
"SuppressPnPRemoveDlg"=dword:00000001
"RequestTimeout"=dword:00002710
"ShortTransferOk’—dword:00000001
"MaxIsoPackets"=dword:00000040
"UnconfigureOnClose’— dword:00000001
" Reset DeviceOnClose"=dword:00000000
Сохраните файл и запустите его. На предложение внести данные в реестр ответьте
Да (Yes).
После успешного внесения данных в реестр нажмите ОК.
Примечание. Если не внести указанные изменения в реестр Windows. то выписать
сертификат можно будет только на смарт-карту eToken. На USB-ключ eToken вы-
писать сертификат будет невозможно — при попытке это сделать будет выведено
окно с сообщением о неизвестной ошибке.
Настройка станции выписки сертификатов
Добавление Центра сертификации в список доверенных узлов
Для выписки сертификатов с использованием приложения Internet Explorer необхо-
димо предварительно настроить его параметры безопасности. Для этого:
Запустите приложение Internet Explorer Откройте пункт меню Сервис -> Свойства обоз-
ревателя (Tools -> Internet Options). Откройте вкладку Безопасность (Security)
Выберите зону Надежные узлы (Trusted sites) и нажмите кнопку Узлы (Sites).
Введите адрес Центра сертификации (http://server.northwind.ru/censrv) и нажмите До-
бавить (Add). Нажмите ОК.
298
Лабораторная работа Ns 2
Выберите зону Надежные узлы (Trusted sites) и нажмите кнопку Другой (Custom level).
3 аДаиГ.ЬЬлй - мисгомЛ! Internet ixpx~rr<
Обшив
Содержание Подкяочения
Интеонет Mi ттм гя
интрасеть
П -рамкы
Дополнительно
КонФидетшиальность
•Л
Q Переход Links
Эта эона содержит доверенные
вашему компьютеру или данным
^роьень б. з с таоности д 'я этой зоны
Друтй
Пользовательская настройка
юю-жч "Другой"
• Для возврата> .	(
кнопку "По у>юлча»мо".
IK
ОК
Надежные
»злы
I

В поле На уровень: установите значение Низкий и нажмите ок.
299
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Подготовка консоли управления сертификатами
Зарегистрируйтесь на компьютере VM WS под именем доменного администратора.
Запустите программу Пуск > Выполнить > mmc (Start > Run > mmc).
В меню Консоль (Console) выберите Добавить или удалить оснастку (Add/Remove snap-in).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите Добавить (Add).
В окне Добавить изолированную оснастку (Add Standalone snap-in) выберите Серти-
фикаты (Certificates) и нажмите Добавить (Add).
Изолированная оснастка Расширения
Консоль
Оснастки
Описание
Добавить
< Корень к»
? X
н м ту
Выберите моей учетной записи пользователя (Му user account)
Нажмите Готово (Finish).
300
Лабораторная работа N° 2
В окне Добавить изолированную оснастку (Add Standalone snap-in) нажмите Закрыть
(Close).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите ОК.
Сохраните настройки консоли на рабочем столе (Консоль Сертификатов).
Получение сертификата агента получения заявок
Запустите «Консоль сертификатов».
В дереве консоли разверните Сертификаты — текущий пользователь (Certificates —
Current User).
Щелкните правой кнопкой мыши на папку Личные (Personal), выберите Все задачи
(All tasks) и щелкните на пункт меню Запросить новый сертификат (Request New
Certificate).
На первой странице мастера запроса сертификатов нажмите Далее (Next).
мастер запроса сертификата
Г*
Вас приветствует мастер запроса
сертификате©
Этот мастер помогает создать запрос на сертификат в
центре сертификации (ЦС) вашего домена
Се этиф. кат. гыда центр. 1ртифгкаим
ярл» тся педте *ржден>* ч t жиги о. иисти и
содержит информацию, необходимую для защиты
дажых или установления зашищежь сетевых
г„дмлючемий
Закрытый ключ является секретной половиной
пары ключей, связанных с сертификатом Он
испо/ъзуется для создания цифровой подгыси иш
для расшифровывания даниях, зашифрованкях
гтчгытым» гючон
Для продолжены нажючте киоску "Далее".
< Назад | Далее > ] [ Отмена"""]
301
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
На странице Мастер запроса серти фи ката/Типы сертификатов (Certificates Request
Wizard/Се rtificate Types) в списке Типы сертификатов (Certificate types) выберите тип
Агент подачи заявок (Enrollment Agent).
Примечание. Для обеспечения защиты от несанкционированного издания сертифи-
катов на сертификат агента подачи к&вок устанавливаете* пароль. Ды /того уста-
новите опции Дополнительно (Advanced! и только после этого нажмите Далее (Next).
В следующем окне установите опцию Включить усиленную защиту закрытого ключа
(Enable strong private key protection) и нажмите Далее (Next).
Мастер запроса сертификата
X
Поставщик службы криптографии
п зстаьщгк ел-/vf ы ктиптогрзфии ।С5Р) создает пар ы иь отк;t ж го и закр tin го
ключей для шифрования и расшифровки сообщений.
Поставщики службы кр.птт зфи
Microsoft Base Cryptographic Provider vl .0
Moosoft Base DSS Cryptographic Provider
Microsoft Enhanced Cryptographк Provider vl .0
Длина ключа:
«1024	v
। юттить этот • люч к ar «• спортир- , что позволит г ** со ранять
ар ме^ую копию ключа и умещать • о
Q Включить усиленную защиту закрытого ключа. В этой случае при каждом
использовании приложением закрытого ключа будет выдаваться запрос.
[ < Назад |( Далее > | [ Отмена ]
302
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
нения, нажмите Назад (Back). Для того чтобы сформировать запрос на выдачу серти-
фиката, нажмите Готово (Finish).
Мастер »апроса сертификата
Заверивн/ в р< «6 оты нас т< ра
запроса сертификатов
Работа мастера уелейно завершена
Имя учетной записи	AdmHstratcr
Ли ь л-пьюте,э	'fT
Центр сертификации	DS Root
Шаблон сертификата	Агент подачи заявок
ZfP	Enha~*eJO
ЬНемальиый размер клоча 1024
Экспортируемый ключ	Нет
Сильная защита ключа	Да
[ < Назад |[ Готово | | Отмена
Если вы активизировали защиту закрытого ключа сертификата агента подачи заявок,
появится окно Создание нового ключа подписи RSA (Creating a new RSA signature key).
Нажмите на кнопку Уровень безопасности... (Set Security Level).
Создание нового ключа подписи RSa
Приложение создает защищенный элемент
Ззкрытс:5<г-жлС»ур*оА
Установлен средк* уровень безопасности
| ОК | | Отмена | [ Состав |
Выберите опцию Высокий (High) и нажмите Далее (Next)
304
Лабораторная работа Ns 2
Введите пароль, который необходимо будет вводить при использовании данного сер-
тификата. Нажмите Готово (Finish).
Появится окно Создание нового ключа подписи RSA (Creating a neu RSA signature
key)c информацией о том, что установлен высокий уровень безопасности. Нажмите ОК
При успешном завершении процесса издания сертификата на экране появится окно
с сообщением: Запрос на сертификат выдан успешно (The certificate request was successful)
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Издание сертификатов с помощью агента получения зая^вок
Для дальнейшего выполнения лабораторной работы вьпмпишите сертификаты для
пользователя «Адгшп_»Инициалы вашего имени и фамилии*,» с помощью агента полу-
чения заявок, используя шаблоны:
—	Aladdin Smartcard User;
—	Aladdin Smartcard Logon.
Для того чтобы подать заявку на сертификат пользователя, ч получить сертификат и за-
писать его в память eToken, следуйте приведенной ниже инстструкции:
Подсоедините eToken, на который вы хотите поместить , сертификат. Используйте
программу «eToken Properties», чтобы убедиться, что вы подсоединили нужный ключ
Запустите Microsoft Internet Explorer
На домашней странице веб-узла службы сертификации НИрг^/Дер^.northwind.ru/certsrv
нажмите на гиперссылку Request a certificate (Запросить серл^ификат).
На странице Request a Certificate (Запросить сертификат) нажмите на гиперссылку
advanced certificate request (расширенный запрос сертификата
ДПА
Лабораторная работа № 2
Нажмите Request a certificate for a smart card on behalf of another user by using the smart
card certificate enrollment station (Запросить сертификат смарт-карты пользователя, ис-
пользуя сертификат агента подачи заявок).
)
При открытии следующей страницы подтвердите, что вы не возражаете против ус
тановки на вашу машину ActiveX компонентов. Нажмите Yes (Да).
Введите пароль к сертификату агента подачи заявок и нажмите ОЬ
307
ЧАСТЬ ///. ЛАБОРАТОРНЫЕ РАБОТЫ
На странице Smart Card Certificate Enrollment Station в списке Certificate Template
(Шаблон сертификата) выберите шаблон Aladdin Smartcard User. В поле Administrator
Signing Certificate выберите ваш сертификат агента подачи заявок (если вы выберете его
еще раз, от вас снова потребуется ввести его пароль). Нажмите Select User (Выбрать
пользователя) для выбора пользователя, которому вы собираетесь выписать сертификат.
Введите имя пользователя, для которого вы хотите издать сертификат. Нажмите
кнопку Проверить имена, чтобы убедиться, что вы правильно набрали имя
308
Лабораторная работа Ns 2
Выберите вашего пользователя и нажмите ОК.
После выбора пользователя на странице Smart Card Certificate Enrollment Station по-
явится кнопка Enroll (Записать).
Убедитесь в том, что в списке Certification Authority (Центр Сертификации) выбран
верный Центр сертификации.
Если все поля заполнены верно, нажмите Enroll (Записать)
В процессе издания сертификата у вас будет запрашиваться PIN-код вашего eToken,
введите его.
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
В случае успешного издания сертификата и записи его в память eToken на стра-
нице Smart Card Certificate Enrollment Station в разделе Status (Состояние) появится
сообщение:
The smart card is ready... Press «View Certificate» to make sure the certificate contains the
correct personal information about the user. (Смарт-карта готова. Нажмите «Просмотр сер-
тификата» для того чтобы убедиться, что сертификат содержит правильную информа-
цию о пользователе)
310
Лабораторная работа N? 2
Издание сертификатов без помощи агента получения заявок
Для дальнейшего выполнения лабораторной работы выпишите сертификат для поль-
зователя «User_»Инициалы вашего имени и фамилии» без помощи агента получения
заявок, используя шаблон Aladdin Exchange Sign & Encrypt.
Для того чтобы подать заявку на сертификат пользователя, получить сертификат и за-
писать его в память eToken, следуйте приведенной ниже инструкции:
Запустите Microsoft Internet Explorer
На домашней странице веб-узла службы сертификации http://server.northwind.ru/certsrv
нажмите Request a certificate (Запросить сертификат).
На странице Request a Certificate (Запрос сертификата) нажмите advanced certificate
request (расширенный запрос сертификата).
Нажмите Create and submit a request to this СА (Создать и представить на рассмотре-
ние запрос к ЦС).
В разделе Certificate Template (Шаблон Сертификата) выберите шаблон Aladdin
Exchange Sign & Encrypt В поле Name (Имя) укажите имя пользователя, для которого
вы выписываете сертификат, а в поле E-mail укажите его E-mail адрес.
В разделе Key Options (Настройки Ключа) все параметры оставьте без изменений:
Key Options,
© Create n«* key set О Use existing key set
CSP Microsoft Enhanced Cryptographic Provider vl 0 *
Key Usage Exchange
Key Size , 1024	| „j"	<<*’T"T'on	Z236 «5 61821225)
©Automatic key container name	О User specified key container name
0Mark keys as exportable
□ Export keys to file
□	Enable strong private key protection
□	Store certificate in the local computer certificate store
Shves	i ert4 Jein tAe Ага/currr-rfez star
instead of m the user's certificate store Does not
install the root CA's certificate Уои must be an
afmimstretor to generate or use a key in the local
machr* stere
ЧАСТЫП ЛАБОРАТОРНЫЕ РАБОТЫ
В ра ид еле Additional Options (Дополнительные настройки) в поле Friendly Name (Ото-
бражаем ое имя) укажите назначение сертификата (например, Exchange avorontsov — сер-
тификат пользователя avorontsov для использования с программой Exchange) и нажмите
Submit ( Подтвердить).
Additional Options:
R-quest Format ©CMC OPKCS10
Hash Algorithm: SHA-1 v
Only used to sign request
□ Save request to a file
Attributes.
Friendly Name: [Exchange avorontsov|
| Submit > |
На странице Potential Scripting Violation (Возможное нарушение выполнения сцена-
рия) нажтмите Да (Yes).
В случ. ie успешного издания сертификата появится окно с сообщением The certificate
you requested was issued to you (Запрашиваемый вами сертификат был для вас выписан).
Нажмите Jnstall this certificate (Установить этот сертификат).
312
Лабораторная работа № 2
На странице Potential Scripting Violation (Возможное нарушение выполнения сцена-
рия) нажмите Да (Yes).
В случае успешной записи сертификата в локальное хранилище данного компьютера
появится окно Certificate Installed (Сертификат установлен).
Копирование сертификата с закрытым ключом на eToken
Для дальнейшего выполнения лабораторной работы произведите импорт сертифи-
ката для шифрования и цифровой подписи электронной почты пользователя «User_»
Инициалы вашего имени и фамилии» на eToken «User «Ваша фамилия». При импорте
не удаляйте оригинальный сертификат с закрытым ключом, он необходим для после-
дующего выполнения лабораторной работы.
Для того чтобы скопировать сертификат с закрытым ключом на eToken, следуйте
приведенной ниже инструкции:
Подсоедините eToken, на который вы хотите поместить сертификат. Используйте
программу eToken Properties (Свойства eToken), чтобы убедится, что вы подсоединили
необходимый ключ.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Запустите утилиту «Свойства еТокеп». Нажмите Пуск -> Программы -> еТокеп >
eToken Properties (Start —> Programs -> еТокеп -> еТокеп Properties).
В окне утилиты «Свойства еТокеп» выберите нужное устройство еТокеп. Перейдите
в расширенным режим, нажав кнопку Дополнительно. Введите Р1 N-код eToken и наж-
мите ОК.
Выберите вкладку Сертификаты и ключи и нажмите кнопку Импортировать сертификат.
314
Лабораторная работа Ns 2
Выберите Хранилище личных сертификатов в качестве источника сертификата Наж-
мите ОК.
Примечание. Утилита Свойства eToken позволяет также импортировать сер-
тификаты, хранящиеся в файлах #PKCS12 (pfx).
В окне Импорт сертификата выберите сертификат, который вы хотите импортировать
на eToken, и нажмите Записать.
Примечание. Рекомендуется удалять оригинальный сертификат с ключом после
его импорта на eToken.
В случае успешного импорта сертификата появится сообщение Импорт осуществлен
успешно. Нажмите ОК.
Свойства eToken
Импорт осуществлён успешно.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Регистрация в домене с помощью eToken
Для того чтобы зарегистрироваться в домене с помощью eToken, выполните следующее:
После появления окна Операционная система Windows подключите eToken
One рацио иная система Windows
Windows
Ж Professional
Вставьте карту или нажмите клавиши Ctrl-Alt-Delete
для начала работы.
Нажатие этого сочетания клавиш обеспечивает
безопасность ввода пароля. Нажмите кнопку	F------
"Справка" для получения дополнительных сведений.	»3
В окне Вход в Windows (Log on to Windows) в поле PIN-код (PIN) введите PIN-код.
Вход в Windows
t Windows
l «rw лк-.	Professional
Mr VT .	МсямоЖ
PIN-код:	| ••••••••••••••
Г~1с использованием удаленного доступа
| OK j [ Отмена ] [ Завершение работы.?") [ параметры « ]
Нажмите ОК.
Установка для пользователя требования использования смарт-карты
при интерактивном подсоединении к компьютеру
Для того чтобы разрешить регистрацию на компьютере только с использованием
смарт-карт, выполните следующее:
Откройте Active Directory — пользователи и компьютеры (Active Directory — users and
computers).
В дереве консоли откройте директорию Users.
Дважды щелкните по учетной записи пользователя в списке, которому вы хотите ус-
тановить данное требование.
В окне учетной записи пользователя откроите вкладку Учетная запись (Account).
В списке Параметры учетной записи (Account options) установите флажок Для инте-
рактивного входа в сеть нужна смарт-карта (Smart card is required for interactive logon).
316
Лабораторная работа No 2
Uxj
- групп	|	Входящие звонки	|
Сергее л п—«ля мрами емХЪьмм. | Гр—t I Ср—ы I
Удалв*мовулрмле»«« | Профиль служб терминалов | СОМ*
Exchange General	| E-tnai *»• -	| Exchange Featues
0*>1ие| Мх* Учетная запись | Профи» | Ть—«— | Орг—*—
Цмл в» ха пользователя:_____
|as?toniwv	|@northwrxiw	-
Им I зхооа поа вателя (пред’угкЬг LDOO
|NO4THW1NO\	[>г
fepoa клрда | Вчщна. |
Г
Параметры учетной записи
Г"Отклонить w запись	-±J
Р Для лггеракпеного е«м в сеть иуаме смарт-карта	.
Г Учетная запись доверена для де легфоеагыя	—J
Г* Учетная эагысь важна и не может быт* делегирована	»|
Срок действия учетной записи
Цеограгычвн
Г Истекает |	- ч-2006 г	3
L
ОК | Отмена | Пргцегыть | Cnp
Нажмите ОК
Чтобы внесенные изменения начали действовать немедленно, выполните на контр-
оллере домена команду gpupdate /force.
Установка групповой политики требования использования смарт-карты
при интерактивном подсоединении к компьютеру
Для того чтобы установить требование использования смарт-карт при интерактивном
подсоединении к компьютеру на все компьютеры, которые входят в домен, выполните
следующие действия:
Запустите программу Политика безопасности домена (Domain Security Policy), нажав
Пуск -> Программы -> Администрирование (Start -> Programs -> Administrative Tools).
Перейдите в папку Параметры безопасности -> Локальные политики -> Параметры
безопасности (Security Settings Local Policies Security options). Установите параметр
Interactive logon: Require smart card в соответствии с рисунком.
Установите флажок Определить следующий параметр политики (Define this policy setting)
Выберите Включен (Enabled).
Крнанъ Действие (ид Отрвека
 1>
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Если вы хотите, чтобы обновленная политика начала действовать немедленно, вве-
дите на контроллере домена команду gpupdate /force.
Примечание.Этот объект групповой политики отсутствует в списке Параметры
безопасности Локальные политики -> Параметры безопасности (Security Settings ->
-> Local Policies -> Security Options) при настройке с рабочей станции. Данный объект
можно использовать как в доменных политиках, так и в политиках, применяемых
к отдельным подразделениям.
Блокирование компьютера и принудительный выход пользователя
при отключении смарт-карты
Для того чтобы настроить опцию, управляющую действиями компьютера при отклю-
чении от него смарт-карты, выполните следующее.
Запустите программу Политика безопасности домена (Domain Security Policy), нажав
Пуск -> Программы -> Администрирование (Start -> Programs -> Administrative Tools).
Перейдите в папку Параметры безопасности -> Локальные политики —> Параметры
безопасности (Security Settings -> Local Policies Security options). Установите параметр
Interactive logon: Smart card removal behavior:
=- для блокирования компьютера установите значение Lock Workstation;
— для принудительного выхода пользователя из системы установите параметр Force
Logoff.
Если вы хотите, чтобы обновленная политика начала действовать немедленно, вве-
дите на контроллере домена команду gpupdate /force.
Примечание 1. Данный объект можно использовать как в доменных политиках,
так и в политиках, применяемых к отдельным подразделениям.
Примечание 2. Принудительное блокирование или выход пользователя при извле-
чении смарт-карт отключается для удобства дальнейшего проведения практических
работ.
318
Лабораторная работа № 2
Запуск приложений от имени другого пользователя
Использование графического интерфейса
Для того чтобы запустить приложение от имени другого пользователя с использова-
нием графического интерфейса, выполните следующее:
Подсоедините eToken с сертификатом пользователя, от имени которого вы хотите за-
пустить приложение.
Щелкните правой кнопкой мыши по значку программы, которую вы хотите запустить
(например, «Локальная политика безопасности») и выберите Запуск от имени (Run as).
В окне Запуск от имени другого пользователя (Run As) выберите Учетная запись ука-
занного пользователя (The following user). Из списка Пользователь (User name) выберите
сертификат пользователя под которым вы хотите запустить приложение.
Запуск от имени другог о пользователи
J Ss Чью учетную запись следует использовать для запуска
” этой программы7
С Учетную запись текущего пользователя (NORTHWIND\Admimtstrat
Р Зап т.*т< 'Г, про-ргм<' с ог. ан.«ч^нны-дост г ом
Эт т параметр лоте сияет пр-дотврат- ть и -оль' вани
-дминистрати «ь пр»* <легийпр гртмами. пыт .им -i
т- -дить ко- ь~ .тер. При выбор* этого параметр-•
Пр ; аММЫ К» ТОРЫМ И ОДР-’ < Д< »«V Г пр ^1* и • г- - •
р< ' ТЬ ИСК ' чТ‘«О.
(• Учетную запись указанного пользователя:
Пользователь:
Пароль:
С NORTHWIND\Admostrator JJ
fl NORTHWIND\Admin»stratot
|~ It .СЙ 6uL L-rlU L J R - J
Вставьте смарт-карту...
В поле PIN-koa(PIN) введите PIN-код eToken, на котором находится данный серти-
фикат. Нажмите ОК
Запуск от имени другого пользователи
” Чью учетную запись следует использовать для запуска
этой программы7
С учетную запись текущего пользователя (NORTHWIND\Administrat
P ап ти’ьз’ прогр м-. с г^ранич-нным д< - ом
Этот парам-т. по”	пр-дот-ратить испольгт
дм ми тра’ивнь. п вилепипр амм---- пытающимся
П- -ДИТЬ •х ’МПЬЮТ-	ПрИЕ -  п -7“-
пр .......... ' • и'- .* оди •» данны- п: г-’Л'гим м т
. V Т"ТЬ н-к рр- чТКО
(• Учетную запись указанного пользователя:
Сцарт -карта:
PIN-код:
Алексей Воронцов DSRoot^l х..|
OK I Отмена
ЧАСТЬ ///. ЛАБОРАТОРНЫЕ РАБОТЫ
Использование командной строки
Для того чтобы запустить приложение от имени другого пользователя, при исполь-
зовании интерфейса командной строки, выполните следующее:
Подключите eToken с сертификатом пользователя, под которым вы хотите запустить
приложение.
В командной строке введите runas /sm <имя приложения> (например, chkdsk.exe):
C:\Documents and Settings\user_ds>runas /sm chkdsk
Windows начнет перебор виртуальных и физических устройств чтения смарт-карт. Ес-
ли операционная система найдет несколько eToken с сертификатами, предназначенны-
ми для входа в сеть с использованием смарт-карты (Smart Card Logon), будет выведен
список соответствующих устройств с указанием имен пользователя
Примечание.
— Для каждого устройства, в котором Windows не обнаружит eToken, будет вы-
ведено сообщение об ошибке Нет карты в устройстве чтения N (No card on reader
N), где N — порядковый номер устройства.
— Для каждого устройства, в котором Windows обнаружит eToken без сертифика-
та, предназначенного для входа в сеть по смарт-карте (Smart Card Logon), будет вы-
ведено сообщение Ошибка при чтении смарт-карты в устройстве чтения N (Error
reading smart card on reader N).
При использовании интерфейса командной строки, выполните следующее:
Запустите команду >runas /sm chkdsk
Чтение смарт-карт...
Укажите сертификат, который следует использовать. Выберите его из следующего списка:
Устройство чтения 1: avorontsov@northwind.ru
Устройство чтения 3: Administrator@northwind ru
Из списка устройств чтения смарт-карт выберите номер устройства, в котором хра-
нится сертификат пользователя, от имени которого вы хотите запустить приложение
(например, 3 — от имени пользователя Administrator@nonhwind.ru).
Выберите номер устройства чтения для использования ’Пользователь со смарт-картой’
Введите номер устройства:
3
Введите PIN-код соответствующего eToken. Если вы предоставили сертификат поль-
зователя, который обладает правами для запуска данной программы, то эта программа
запустится в новом окне.
Используется карта в устройстве 3. Введите PIN-код:
Попытка запуска chkdsk от имени пользователя «Administrator — DS Root» ...
320
Лабораторная работа № 2
Подключение сетевых дисков
с использованием прав доступа другого пользователя
Использование графического интерфейса
Для того чтобы подключить сетевой диск, используя права другого пользователя, с
использованием графического интерфейса, выполните следующее:
Подключите eToken с сертификатом пользователя, обладающего необходимыми пра-
вами доступа, которые вы хотите использовать для подсоединения сетевого диска.
Запустите «Проводник» (нажмите на Пуск (Start) правой кнопкой мыши). Из меню
Сервис (Tools) выберите Подключить сетевой диск... (Map Network Drive...).
Введите в поле Диск () имя диска (например, Z:), которое вы хотите назначить под-
ключаемому ресурсу, а в поле Папка () полное имя ресурса, который вы хотите подсо-
единить (например — <<\\server\c$>>) и нажмите Готово
Если имеющихся прав у текущего пользователя недостаточно для доступа к данному
ресурсу, появится окно, предлагающее предоставить регистрационные данные другого
пользователя, обладающего необходимыми правами.
321
ЧАСТЬ III ЛАБОРАТОРНЫЕ РАБОТЫ
Из списка Пользователь (User name) выберите сертификат пользователя, обладаю-
щего необходимыми правами доступа.
Подключение к servvr.northwind.ru ? X
Подключение к server
Пользователь:
Пароль:
В поле PIN-код (PIN) введите PIN-код eToken, на котором находится данный сер-
тификат, и нажмите ОК.
Подключение к server.northwind.ru
Годелсчзюк к ж ver
Смарт-карта:	[бй Administrator - D5 Root v
PIN-код:	•••••••>••••••
Co -*«1ть паро м
| OK j [ Отмена ]
Примечание* Данный диск отключается для обеспечения условий проведения сле-
дующего практического задания.
Использование командной строки
Для того чтобы подключить сетевой диск, используя права другого пользователя,
с помощью интерфейса командной строки, выполните следующее:
Подключите eToken с сертификатом пользователя, обладающего необходимыми пра-
вами доступа, которые вы хотите использовать для подсоединения сетевого диска.
В командной строке введите net use <имя диска> <имя ресурса> /sm (например, имя
диска — Z:, а имя ресурса — \\са\с$):
C:\Documents and Settings\avorontsov>net use Z: \\server\c$ /sm
322
Лабораторная работа № 2
Windows начнет перебор виртуальных и физических устройств чтения смарт-карт. Ес-
ли операционная система найдет несколько eToken с сертификатами, предназначенны-
ми для входа в сеть по смарт-карте (Smart Card Logon), будет выведен список соответ-
ствующих устройств с указанием имен пользователя.
Примечание.
— Для каждого устройства, в котором Windows не обнаружит eToken, будет вы-
ведено сообщение об ошибке Нет карты в устройстве чтения N (No card on reader N),
где N — порядковый номер устройства.
— Для каждого устройства, в котором Windows обнаружит eToken без сертифика-
та, предназначенного для входа в сеть по смарт-карте (Smart Card Logon), будет вы-
ведено сообщение Ошибка при чтении смарт-карты в устройстве чтения N (Error
reading smart card on reader N).
При использовании интерфейса командной строки, выполните следующее:
Запустите команду >net use Z: \\server\c$ /sm
Чтение смарт-карт...
Укажите сертификат, который следует использовать. Выберите его из следующего
списка:
Устройство чтения 1: avorontsov@northwind ru;
Устройство чтения 3: Administrator@northwind.ru.
Из списка устройств чтения смарт-карт выберите номер устройства, в котором хра-
нится сертификат пользователя, от имени которого вы хотите запустить приложение
(например, 3 — от имени пользователя Administrator@northwind.ru).
Выберите номер устройства чтения для использования «Пользователь со смарт-картой»:
Введите номер устройства:
3
Введите PIN-код соответствующего eToken. Если вы предоставили сертификат поль-
зователя, обладающего необходимыми правами доступа, то запрошенный ресурс будет
подключен.
Используется карта в устройстве 3. Введите PIN-код:
Диск Z: сейчас подключен к \\server\c$.
Операция выполнена успешно.
C:\Documents and Settings\avorontsov>
Примечание. Данный диск отключается для удобства проведения практических
работ.
323
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
Содержание отчета
Отчет оформляется один на бригаду из одного-двух исполнителей.
В отчете с титульным листом установленной формы (Приложение А) необходимо
представить следующие сведения:
1.	Наименование и цели работы.
2.	Краткую характеристику учебного стенда (по составу доступных пользователю
функций управления и индикаций, распределению ресурсов, функций, вариантов
набора преобразований).
3.	Функциональную схему учебного стенда с пояснениями и комментариями.
4.	Выполненные настройки Центра сертификации, шаблоны сертификатов, создан-
ные в ходе выполнения лабораторной работы.
5.	Подготовиться для устных ответов по контрольным вопросам.
Контрольные вопросы
1.	Какие дополнительные средства (утилиты) необходимо установить для того, чтобы
подготовить к работе Центр сертификации?
2.	Какие поля можно задавать в шаблоне сертификата?
3.	Как издать сертификаты без помощи агента получения заявок?
4.	Каким образом можно скопировать сертификат в память ключа eToken?
5.	Как можно выполнить запуск приложений от имени другого пользователя с исполь-
зованием командной строки?
Лабораторная работа N° 2
Приложение А
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
УСТАНОВКА И НАСТРОЙКА ЦЕНТРА СЕРТИФИКАЦИИ,
ИСПОЛЬЗОВАНИЕ КЛЮЧЕЙ eToken
В ДОМЕНЕ WINDOWS SERVER 2003
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
Выполнили:
Студенты гр.____________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
325
Лабораторная работа № 3
ИСПОЛЬЗОВАНИЕ eToken
ДЛЯ БЕЗОПАСНОГО ДОСТУПА
К ИНФОРМАЦИОННЫМ РЕСУРСАМ,
ДЛЯ ШИФРОВАНИЯ И ДЛЯ ЭЦП
Цель работы
Изучить возможности использования ключей eToken для безопасного доступа к ин-
формационным ресурсам организации, для шифрования информации и для ЭЦП в при-
ложениях MS Office.
Общие сведения о безопасном доступе
к информационным ресурсам организации
Удаленный доступ к рабочему столу (RDP)
В Windows ХР существует возможность выполнять аутентификацию пользователей
по ключу eToken при входе в систему терминального клиента. Аутентификация произ-
водится с помощью цифрового сертификата Х.509, хранящегося в памяти ключа, точно
так же, как если бы пользователь физически находился за данной рабочей станцией.
В предыдущих лабораторных работах по теме «Обеспечение безопасности доступа к дан-
ным информационной системы организации с использованием продуктов Microsoft и
Aladdin. Типовые решения» такие сертификаты уже использовались при регистрации
пользователя в домене Windows Server 2003, при запуске приложений и для доступа к се-
тевым дискам от имени другого пользователя.
Помимо аутентификации при терминальном подключении все приложения, рабо-
тающие со смарт-картами, к которым пользователь обращается в течение сеанса, могут
использовать ключ eToken.
Для того чтобы пользователи имели доступ к рабочему столу, необходимо предоста-
вить им такую возможность средствами ОС Windows Программа «Подключение к уда-
ленному рабочему столу» позволяет с легкостью подключаться к серверу терминалов или
другому компьютеру, работающему под управлением Windows При необходимости име-
ется возможность указать параметры каждого подключения и сохранить их в файле для
последующего использования.
По умолчанию удаленный доступ к рабочему столу предоставляется администрато-
рам. Чтобы обычные пользователи могли также подключаться к рабочему столу, необ-
ходимо предоставить им соответствующие права Кроме того, можно предоставить поль-
зователю право удаленно подключаться к контроллеру домена.
Виртуальные частные сети (VPN)
При развертывании РК1 в основу использования виртуальной частной сети (Virtual
Private Network, VPN) положен протокол расширенной аутентификации (Extensible
Authentication Protocol, ЕАР). Подключаться к сети через VPN-соединения могут только
те пользователи, учетные записи которых настроены для таких подключений. ВозмоЖ-
326
Лабораторная работа Ns 3
ность подключения пользователей к корпоративным серверам через VPN-соединения
задается настройками сервера- Кроме сервера и учетной записи пользователя необходи-
мо также соответствующим о»бразом настроить рабочую станцию — установить серти-
фикат ЦС, а также создать и настроить VPN-соединение.
Общие сведения о протока^ ЕАР
Для проверки подлинности подключений виртуальных частных сетей (VPN), под-
держивающих протокол PPI Р или L2TP, применяются методы проверки на уровне
пользователей, основанные на протоколе РРР. К этим методам относятся протоколы:
—	Password Authentication Protocol (РАР);
—	Challenge Handshake Authentication Protocol (CHAP);
—	Shiva Password Authentication Protocol (SPAP);
—	Microsoft Challenge Authentication Protocol (MS-CHAP);
—	Extensible Authentication Protocol (EAP).
Благодаря новым возможностям, предлагаемым протоколами ЕАР и IPSec (internet
Protocol security), виртуальные частные сети обеспечивают повышенную безопасность
для удаленных пользователей
Протокол ЕАР является расширением протокола Point-to-Point Protocol (PPP). На нем
основаны несколько методов проверки подлинности, предусматривающих обмен учет-
ными записями и прочими снедениями произвольного объема. Протокол ЕАР был раз-
работан с учетом растущей потребности в средствах проверки подлинности, использую-
щих более широкий круг устройств системы безопасности; он предлагает стандартную ар-
хитектуру для поддержки дополнительных методов проверки подлинности в рамках РРР.
С помощью ЕАР можно реализовать поддержку нескольких алгоритмов проверки
подлинности — так называемых типов ЕАР, к числу которых относятся:
—	генераторы кода доступа:
—	одноразовые пароли;
—	средства проверки подлинности на основе открытых ключей с помощью
смарт-карт, сертификатов и ДР-
Сочетание протокола со строгими типами является ключевым компонентом техно-
логии безопасных подключений виртуальных частных сетей (VPN). Например, строгие
типы ЕАР, основанные на сертификатах, обеспечивают более надежную защиту от по-
пыток «грубого» взлома системы или подбора пароля, чем другие протоколы проверки
подлинности, использующие пароли, такие как CHAP и MS-CHAP.
Операционная система Windows ХР включает поддержку двух типов ЕАР:
—	EAP-MD5 CHAP (аналог протокола проверки подлинности CHAP);
—	EAP-TLS (применяется для проверки подлинности на основе сертификатов поль-
зователей).
EAP-TLS — это метод взаимной проверки подлинности, при котором и клиент, и
сервер должны предоставлять доказательства своей подлинности. В ходе сеанса
EAP-TLS клиент удаленного доступа отправляет свой сертификат пользователя, а сервер
удаленного доступа — свой сертификат компьютера. Если хотя бы один из этих серти-
фикатов не будет передан или окажется недействительным, подключение разрывается.
Защищенное подключение к Web-cepeepy (HTTPS)
Для исключения несанкционированного доступа к веб-северу используется защи-
щенный протокол HTTPS. Рекомендуется создать новый защищенный веб-сервер и для
исключения несанкционированного доступа к такому серверу рекомендуется макси-
мально ограничить возможности аутентификации пользователя, исключив анонимную
327
ЧАСТЫ11 ЛАБОРАТОРНЫЕ РАБОТЫ
аутентификацию, а также другие стандартные способы аутентификации. При работе с
общими настройками сервера способы аутентификации ограничиваются на уровне сер-
вера целиком, и эти изменения применяются ко всем сайтам данного сервера.
Ограничив способы идентификации на уровне сервера, можно приступать к настрой-
ке сайтов (правильное задание DNS-имени для нового сервера и настройки доступа по
протоколу HTTPS).
Следует отметить, что после настройки веб-сервера доступ ко всем его сайтам по про-
токолу HTTP станет невозможным.
Важно отметить, что в целях безопасности развертывать Центр сертификации на
веб-сервере не рекомендуется.
Шифрование и использование ЭЦП
Microsoft Office 2003 использует технологию Microsoft Authenticode, позволяющую
снабжать электронные документы (файлы) электронной цифровой подписью (ЭЦП).
Электронная цифровая подпись представляет собой зашифрованную с помощью за-
крытого ключа автора контрольную сумму электронного документа. Для вычисления
контрольной суммы используется известный автору и адресату алгоритм (хэш-функция).
Для того, чтобы проверить электронную цифровую подпись, используется открытый
ключ автора документа. Открытый ключ автора содержится в сертификате ключа подписи
и распространяется вместе с ним. Такой механизм позволяет, с одной стороны, проверить
целостность электронного документа, а с другой — удостоверить его авторство.
Для проверки электронной цифровой подписи пользователь должен иметь действую-
щий сертификат (формата Х.509) отправителя. Поэтому при отправке подписанного со-
общения адресату передается его электронная цифровая подпись, а также, как правило
сертификат ключа подписи автора.
При успешной проверке электронной цифровой подписи адресат подтверждает, что
документ был получен от владельца сертификата ключа подписи (автора) и документ не
был изменен.
Microsoft Office 2003 позволяет создавать ЭЦП в документах, создаваемых с помощью
приложений: Word 2003, Excel 2003, Power Point 2003.
Описание работы
Для изучения возможностей использования ключей eToken для безопасного доступа
к информационным ресурсам организации, для шифрования информации и для ЭЦП
в приложениях MS Office работа делится на четыре части:
•	удаленный доступ к рабочему столу с использованием eToken (RDP):
•	настройка виртуальной частной сети (VPN);
•	создание защищенного веб-сервера и настройка доступа по HTTPS;
•	использование шифрования и ЭЦП в приложениях MS Office.
Удаленный доступ к рабочему столу с использованием e Token
Данная часть работы предназначена для настройки сервера и рабочей станции и под-
готовки их к проверке удаленного подключения с помощью eToken. Для выполнения
данной части работы необходимо:
•	Настроить возможность удаленного доступа к компьютеру.
•	Настроить рабочую станцию
328
Лабораторная работа № 3
•	Настроить контроллер домена.
•	Настроить подключение к удаленному компьютеру с помощью eToken.
•	Предоставить обычным пользователям возможность удаленного доступа к компью-
теру.
•	Предоставить пользователям права Log on through Terminal Services на контрол-
лере домена.
•	Проверить удаленный доступ к рабочему столу сервера с рабочей станции.
•	Проанализировать полученный результат.
Настройка виртуальной частной сети
Данная часть работы предназначена для настройки сервера маршрутизации с исполь-
зованием протокола ЕАР, а также для настройки учетной записи пользователя для ис-
пользования VPN-соединений на примере организации удаленного доступа пользовате-
лей к рабочему столу (RDP).
Для выполнения данной части работы необходимо:
•	Настроить сервер маршрутизации и удаленного доступа.
•	Настроить учетную запись пользователя для использования VPN-соединений
•	Установить сертификат Центра сертификации на рабочую станцию
•	Создать VPN-соединение на рабочей станции.
•	Настроить параметры VPN-соединения на рабочей станции.
•	Установить VPN-соединение.
•	Проверить сведения об установленном VPN-соединении
•	Проанализировать полученный результат.
Создание защищенного веб-сервера
и настройка доступа по HTTPS
Данная часть работы предназначена для создания дополнительного защищенного
веб-сервера, настройке подключения к защищенному веб-серверу с использованием
протокола HTTPS и проверке доступа к защищенному веб-сайту, созданному на защи-
щенном веб-сервере.
Для выполнения данной части работы необходимо:
•	Создать дополнительный защищенный веб-сервер.
•	Настроить подключение к новому веб-серверу по протоколу HTTPS
•	Создать DNS-имя для нового веб-сервера
•	Настроить рабочую станцию.
•	Настроить сетевые подключения на хосте.
•	Настроить файл hosts на хосте.
•	Проверить доступ к веб-сайту по HTTPS.
•	Проанализировать полученный результат.
Использование шифрования и ЭЦП в приложениях MS Office
Данная часть работы предназначена для настройки использования электронной циф-
ровой подписи (ЭЦП) в приложениях MS Word 2003 и MS Outlook 2003, а также для за-
щиты электронных сообщений при использовании технологии Outlook Web Access.
13-5680	37Q
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Для выполнения данной части работы необходимо:
•	Создать ЭЦП в MS Word 2003.
•	Проверить работу с ЭЦП в MS Word 2003
•	Настроить MS Outlook 2003 для шифрования и ЭЦП сообщений.
•	Настроить MS Outlook 2003 для нового пользователя.
•	Настроить параметры MS Outlook 2003 для шифрования и ЭЦП сообщении.
•	Настроить Outlook Web Access для шифрования и ЭЦП сообщений.
•	Проверить использование MS Outlook 2003 для защиты сообщений электронной
почты.
•	Создать сообщения с ЭЦП.
•	Создать зашифрованное сообщение.
•	Открыть зашифрованные сообщения.
•	Проверить ЭЦП в сообщении.
•	Проанализировать полученный результат.
Задание
1.	Изучить теоретические вопросы, изложенные в начале данной лабораторной ра-
боты.
2.	Настроить стенд, рабочую станцию и контроллер домена
3.	Установить и настроить защищенный веб-сервер
4.	Настроить и проверить удаленный доступ к рабочему столу с использованием
eToken.
5.	Настроить и проверить работу виртуальной частной сети с использованием eToken.
6.	Создать защищенный веб-сервер и настроить доступ по протоколу HTTPS.
7.	Настроить и проверить использование шифрования и ЭЦП в MS Word 2003 и в MS
Outlook 2003.
8.	Оформить отчет по лабораторной работе.
9.	Ответить на контрольные вопросы.
Порядок выполнения работы
Настройка возможности
удаленного доступа к компьютеру
Настройка рабочей станции
Для того чтобы администраторам предоставить возможность удаленного доступа
к компьютеру, выполните следующие действия:
Подсоединитесь к компьютеру VM WS пользователем с правами администратора.
Запустите Пуск -> Панель управления -> Система (Start -> Control Panel -» System).
В окне Свойства системы (System Properties) откройте вкладку Удаленные сеансы
(Remote). Установите флажок Разрешить удаленный доступ к этому компьютеру (Allow
users to connect remotely to this computer). Нажмите OK.
330
Лабораторная работа Ns 3
Предоставьте администраторам, зарегистрированным при выполнении предыдущих
лабораторных работ, возможность удаленного доступа к VM SRV.
На VM SRV закройте все программы и выйдите из системы.
Настройка контроллера домена
Подсоединитесь к компьютеру VM WS пользователем с правами администратора.
Запустите Пуск —> Панель управления —> Система (Start -> Control Panel -> System).
В окне Свойства системы (System Properties) откройте вкладку Удаленное использо-
вание (Remote). Установите флажок Разрешить удаленный доступ к этому компьютеру
(Allow users to connect remotely to this computer). Нажмите OK.
Л1	~	JQxj
О «шие | Имя ммлыот » | Оборудована 1 Дополнительно |
Автоматическое обновим*	Удаленное использование
j Укажите как этот компьютер можно будет использовать с
? < другого места
Удаленный помощник-------------------------------------
Г Ра решить дтпраеку приглашения удаленному помощник*
Подрсбчь обадь^ом
П I
Дистанционное управпение работе* столом —-------------
Р (азрешить . алемьид -нг кэт »». к-е»
Полное имя компьютера:
•ervernortfwmd.ru
Псжфобнееобуд^11М±Р.<'аШс1?Л
Выбрать удалемъи погьзователем
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
При появлении окна Удаленные сеансы (Remote Sessions) нажмите ОК
Удаленные сеансы
Некоторые локальные учетные записи не имеют паролей.
Учетные записи, используемые для удаленных подключении, должны иметь
пароль.
При использованье общего доступа к подключению Интернета или
персонального
брандмауэра необходимо открыть соответствующий порт и разрешить
удаленные подключения.
Дополнительные сведения содержатся в центре справки и поддержки
Р ОК
Настройка подключения к удаленному компьютеру
с использованием eToken
Для того чтобы настроить удаленное подключение к удаленному компьютеру, вы-
полните следующие действия:
Запустите Подключение к удаленному рабочему столу (Remote Desktop Connection),
нажав Пуск -> Все программы -> Стандартные -> Связь (Start -> Programs -> Accessories ->
Communications).
В окне Подключение к удаленному рабочему столу (Remote Desktop Connection) в поле
Компьютер (Computer) введите IP-адрес или DNS имя компьютера, к которому вы на-
страиваете подключение.
Нажмите Параметры (Options).
Откройте вкладку Локальные ресурсы (Local Resources). Установите флажок
смарт-карты (Smart cards).
332
Лабораторная работа № 3
Перейдите на закладку Общие (General) Введите IP-адрес машины, для которой
создается подключение (для сервера VW SRV задайте 1Р-адрес 192.168.1.145). Нажмите
Сохранить как (Save As), сохраните настроенное подключение на рабочем столе хоста
(например, под именем CA.rdp).
Общие | Экран | Локальные ресурсы | Программы | Дополнительно |
Параметры входа
Введите имя комтгыотер»и и ть Ssxre г и из сгв%жа.
Компостер |l9216812	*
Пользователь I Mwmaakx””
Пароль	J
Домек	|
Г" Сохранить пароль
Параметры подключения
v > Сохранение текущих параметров или открытие
______| существующего подключения
Сохранить как | Открыть
| Подклкуыть | Отмена | Справка | Параметры «
Подключите eToken с сертификатом пользователя «Admin»_» Инициалы вашего име-
ни и фамилии».
Для подключения к удаленному рабочему столу нажмите Подключить (Connect).
Если на удаленном компьютере открыт сеанс пользователя, то для подключения
к удаленному рабочему столу необходимо его завершить. Для этого в окне предупреж-
дения нажмите Да (Yes).
ЧАСТЬ ///. ЛАБОРАТОРНЫЕ РАБОТЫ
Попытайтесь подсоединиться к удаленному рабочему столу, используя созданное вами
RDP-подключение (дважды щелкните мышкой на файл CA.rdp).
Примечание. В окне Вход в Windows (Log on to Windows) в поле PIN-код (PIN)
введите PIN-код.
После установления удаленного подсоединения к рабочему столу сервера СА завер-
шите его (Пуск -> Завершение работы (Start -> Log Off))
Подключите eToken с сертификатом пользователя «User>_» Инициалы вашего имени
и фамилии». Попытайтесь подсоединиться к удаленному рабочему столу, используя со-
зданное вами RDP-подключение.
Предоставление обычным пользователям
возможности удаленного доступа к компьютеру
Для того чтобы обычным пользователям предоставить возможность удаленного доступа
к компьютеру, выполните следующие действия:
Подсоединитесь к компьютеру пользователем с правами администратора.
Откройте Пуск -» Панель управления -> Система (Start -> Control Panel -> System).
В окне Свойства системы (System Properties) откройте вкладку Удаленное использо-
вание (Remote).
Установите флажок Разрешить удаленный доступ к этому компьютеру (Allow users to
connect remotely to this computer). Для того, чтобы к компьютеру могли подключаться
пользователи, не имеющие полномочий локального администратора, нажмите Выбрать
удаленных пользователей (Select remote Users).
334
Лабораторная работа Ns 3
В окне Пользователи удаленного рабочего стола (Remote Desktop Users), используя
клавишу Добавить (Add), добавьте пользователя, которому вы хотите предоставить уда-
ленный доступ к данному компьютеру. Нажмите ОК.
Примечание. При предоставлении удаленного доступа к компьютеру пользова-
тель автоматически добавляется в локальную группу Remote Desktop Users. Если уда-
ленный доступ предоставляется к контролеру домена, то пользователь добавляется
в доменную группу Remote Desktop Users.
Закройте окно Свойства системы (System Properties), нажав ОК
Предоставление пользователю права
Log on through Terminal Services на контроллере домена
Для того чтобы предоставить пользователям право Log on through Terminal Services на
контролере домена, выполните следующее:
Запустите программу Политика безопасности контроллера домена (Domain Controller
Security Policy), нажав Пуск -> Программы -> Администрирование (Start -> Programs
Administrative Tools).
Перейдите в папку Настройки безопасности -> Локальные политики -> назначение
прав пользователя (Security Settings -> Local Policies —> User Rights Assignment). Отредак-
тируйте значение параметра Разрешать вход в систему через службу терминалов fpht
(Allow log on through Terminal Services), добавьте в список группу Пользователи удален-
ного рабочего стола (Remote Desktop Users) и нажмите ОК.
335
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
 ГН jut D«w. _n Coni rol - be - г* у Sett 
Консоль Действи» Вид Справка
« -» SJft ?	t®_
J Конфигурация Windows
£) Сценарм (мпуос/эаваршение >
В 9 Параметры безопасности
♦ М Полпикм учетных з«*сай
В JI Показные ломтики
• И Помтикаауе»»та
S J Назнамеме тм 'ыыоы’ни
Парметрыбежхзасноггы
*	Журнал событий
Ш J г руппы с (Гранича»е*ы доступой
-	3 Сметенные < у«вь.
R _> Реестр
-	Л Файловая система
•	X Полипки беспроводной сетти (IEEE
•	_1Помтики открытого ключа
-	_J Политжи ограниченного исгсльэов
Е £ Политжи безопасности IP н« "Служ
-JPJXJ
•1Ш
Помтика
^Изменение систем
"Й Лока/ым! вход в
.&Й настройка квот па
шй Обход перекрести
^Овладею* файл»
£д]Омцетеоре»м • ч
ЛЙОтказ в доступе к
£Й* Хгкаэ во входе в к
лЙЭткаэатх во входе
щй Отклонить покали
ЗЙ Отладка протрем
^Принудительное у.
еЙГ^юфимроваже э.
£*)Гфофи1»фоеание о
ЗЙРабота в режме <м
^Р ч •* «ть ев* в <
^Разрешение доеер*
ЗЙСьаронизация де
£д| Создание глобагы
^Создание журнале
»д)и датеенаркгрм
ЗЙ Создание постом
«^Создам* г '
Р Опрейодгъ следующие параметры положи
Добавил» пользователя или групу | Ыддмть
i ^ДанмяР параметр не совмеспм с системами Wndowa 2000
'г Seivr е Pat* 1 или более рангами Применяйте объекты
грдомзойло/мгищ. содержащие дагашй параметр только к
ОК | Отмена I Приичип
«Я ' оеличега» приоритета диспетчировагмя	AAnrestrators
!«д| правчеме аудитом и журналом безопасности	NOTH.'МДЕxchange Enterprise Server Т
Lil________________________________________________________________I 2J
Чтобы внесенные изменения начали действовать немедленно, выполните на контр-
оллере домена команду gpupdate /force.
Подключите eToken с сертификатом пользователя «и8ег»_»Инициалы вашего имени
и фамилии». Попытайтесь подсоединиться к удаленному рабочему столу, используя со-
зданное вами RDP-подключение.
Примечание. Для пиъго чтобы пользователи могли удаленно подсоединиться
к компьютеру, они (должны обладать правом Log on through Terminal Services на дан-
ном компьютере. По умо.гчанию обычные пользователи (не входящие в доменную груп-
пу Administrator) не обладают данным правом на контроллере домена.
Результат выполнения данной части лабораторной работы можно считать положи-
тельным, если все попытки удаленного подключения к рабочему столу прошли успешно.
Настройка сервера маршрутизации
и удаленного доступа
В этой части лабораторной работы необходимо настроить ЦС, чтобы он выполнял
функции сервера маршрутизации и удаленного доступа через VPN-соединение. Для того
чтобы настроить сервер, выполните следующие действия:
На виртуальной машине VMSRV откройте административную консоль Маршрутиза-
ция и удаленный доступ (Routing and Remote Access), нажав Пуск > Программы > \дми-
нистрирование (Start > Programs > Administrative Tools).
В дереве консоли выберите сервер, щелкните правой кнопкой мыши и выберите На-
строить и включить маршрутизацию и удаленный доступ (Configure and Enable Routing and
Remote Access), чтобы запустить мастер установки сервера маршрутизации и удаленного
доступа.
336
Лабораторная работа № 3
В окне приветствия мастера нажмите Далее (Next).
< {Назад I} Далее > Отмена
В окне Конфигурация (Configuration) выберите опцию Удаленный доступ (VPN или
модем) (Remote access (dial-up or VPN)) и нажмите Далее (Next)
ЧАСТЬ III ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Удаленный доступ (Remote Access) установите флажок Доступ к виртуальной
частной сети (VPN) (VPN) и нажмите Далее (Next).
Мастер настройки сервера маршрутизации и удаленного доступа
Удаленный доступ
Данный сервер можно настроить на поддержку подключений удаленного
доступа и подключений VPN
Р Лост.п к ^гртуальнои частной сети PN |
Удаленные VPN-серверы могут получать удалек»^е клиентские
подключения через Интернет
Г" Удаленный доступ
Серверы удаленного доступа могут получать уда.че»^** клиентские
гадк ггочегия по модему
< Назад I Далее > | Отмена
В окне Соединение по VPN (VPN Connection) выберите сетевой интерфейс Internet,
к которому будут подключаться удаленные компьютеры для установления VPN-соеди-
нений. Установите флажок Безопасность с использованием фильтров статических пакетов
338
Лабораторная работа № 3
(Enable security on the selected interface by setting up static packet filters) и нажмите Далее
(Next).
Примечание. Если флажок Безопасность с использованием фильтров статиче-
ских пакетов (Enable security on the selected interface by setting up static packet filters)
установлен, то устанавливается статический фильтр пакетов, который позволяет
подключаться через выбранный интерфейс только с использованием VPN-соединений.
В окне Назначение IP-адресов (IP Address Assignment) выберите способ назначения
удаленным компьютерам IP-адресов IP-адреса подключаемым удаленным компьютерам
должны назначаться из диапазона 192.168.1.201—192.168.1.205. Выберите опцию Из за-
данного диапазона адресов (From a specified range of addresses) и нажмите Далее (Next).
Примечание.
—	Автоматически (Automatically) — для динамического предоставления IP-adpecoe
DHCP сервером;
—	Из заданного диапазона адресов (From a specified range of addresses) — для того
чтобы задать один или несколько диапазонов адресов вручную.
В окне Назначение диапазонов IP-адресов (Address Range Assignment) нажмите Создать
(New), чтобы ввести диапазон IP-адресов.
Можно доз in диапаэотчя адресов которые этот зврвер будет
испотэовать при нмыачеиии адресо» уд•вн*н к/ыентам
Введите диапазоны адресов из стоического пуло, которые вы могите
использовать Сервер будет на наметь адреса из очередного диапазонд пока
он не будет исчерпан, и только затем перейдет к спадуошему
Диапазоны ддр-сое
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Новый диапазон адресов (New Address Range) в поле Начальный IP-адрес (Start
IP address) введите первый адрес диапазона (192.168.1.201), а в поле Конечный IP-адрес
(End IP address) — последний (192.168.1.205). Нажмите ОК.
Новый диапазон адресов
Вгедите начальна IP адрес и либо конеч ь и IP-адрес /ибо «ело
адресов в непрерывном диапазоне.
Началыеяй1Р адрес.	1192 168 001 201
Ьоне^1Р-®рес	1192 168 001 205
Количество ддресов-	|	~
0К | Отмена |
Примечание. Общее число адресов должно быть не менее чем на 1 больше необ-
ходимого числа VPN-подключений к данному серверу.
В окне Назначение диапазонов IP-адресов (Address Range Assignment) нажмите Далее
(Next).
Мастер настройки сервера маршрутизации и уда энного доступа
Назначение диапазонов 1Р-адресое
Можно указать диапазоны адресов, которые этот сервер будет
использовать при назначении адресов удаленным клиентам
Введите диапазоны адресов из статического пула, которые вы хотите
использовать Сервер будет назначать адреса из очередного диапазона пока
он не будет исчерпан, и только затем перейдет к следующему.
Диапазоны здресоЕ
с	по	Число
1921681 201	1921681 205	5
Создать... I - енить.. I Удалить
< Назад
Отмена
В окне Управление несколькими серверами удаленного доступа (Managing Multiple
Remote Access Servers) выберите опцию Нет, не использовать маршрутизацию и удален-
ный доступ для проверки подлинности запросов на подключение (No, use Routing and
Remote Access to authenticate connection requests) и нажмите Далее (Next).
340
Лабораторная работа № 3
Мастер настройки сервера маршрутизации и удаленного доступа
Uправление несколькими серверами удаленного доступа
Запросы на подключения могут быть проверены локально или
переадресованы на удаленный сервер доступа совместимый с
_ RADIUS-службой______________________________
*, 'отя мйрц^чпк лхия и удап^ннь^ доступ -югут сь полнпрсоер-чу подги.- ихГУ
запросов на подключение, большие сети с множеством серверов удаленного
доступа чхто игпогьсиют RADIUS сервер для централизованно!Р проверки
подлинности
Можно переадресовать запросы проверки подлинности RADIUS-серверу при
его использовании в данной сети.
Настроить д анный сервер для работы с RADIUS-сервером?
(* Hej использовать маршрутизацию и удаленный доступ для проверки
^подлинности запросов на подключение
Г Дз, настроить данный сервер для работы с RADIUS-сервером
< Назад I Далее >
Отмена
Для завершения работы мастера нажмите Готово (Finish).
Мастер настройки сервера маршрутизации и удаленного доступа
Завершение работы мастера настройки
сервера маршрутизации и удаленного
доступа
Успешно завершена работа мастера сервера
маршрутизации и удаленного доступа
Сводка.
Клиенты VPN подключаются к следующему общему
интерфейсу Internet
Клиентам VPN для адресации назначается
следующая сеть LAN.
Чтобы клиенты могли подключаться, необходимо
добавить учетные записи пользователей на локальном
компьютере или через Active.Direct^
об учетных записях см в справ* е о ма; шрутизации и,
удаленном доступа.
Для закрытия мастера нажмите кнопку Тотово"
< Назад
Готово
Отмена
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Маршрутизация и удаленный доступ (Routing and Remote Access) нажмите OK.
Примечание. Для применения заданных параметров операционной системе
Windows Server 2003 потребуется некоторое время.
В дереве консоли выберите сервер, щелкните правой кнопкой мыши и нажмите
Свойства (Properties).
В окне свойств сервера откройте вкладку Общие (General). Установите опцию Марш-
рутизатор (Router) и выберите Только локальной сети (Local area network (LAN) routing
only), а также опцию Сервер удаленного доступа (Remote access server).
342
Лабораторная работа Ns 3
Откройте вкладку Безопасность (Security). Нажмите Методы проверки подлинности
(Authentication Methods).
В окне Методы проверки подлинности (Authentication Methods) снимите все флажки,
кроме Протокол расширенной проверки подлинности (ЕАР) (Extensible Authentication
Protocol).
Нажмите Методы ЕАР (ЕАР Methods) В окне Методы ЕАР (ЕАР Methods) убедитесь
в том, что в списке Методы (Methods) присутствует строка Smart Card or other certificate.
Нажмите OK.
ЧАСТЬШ ЛАБОРАТОРНЫЕ РАБОТЫ
Методы ЕАР
Протокол расширенной проверки лоалинности (ЕАР) расширяет
методы проверки, доступные для подключении протокола РРР.
Методы ЕАР настраиваются через политику удаленного доступа. На
этом сервере установлены следующие метеаы ЕАР
Методы
Примечание. Из протоколов, которые вы можете выбрать в окне Методы про-
верки подлинности (Authentication Methods), только ЕАР поддерживает проверку
подлинности с использованием смарт-карт. Для того чтобы пользователи могли при
обращении к серверу идентифицировать себя только с помощью eToken, из всех про-
токолов оставляется только ЕАР.
В окне Методы проверки подлинности (Authentication Methods) нажмите ОК.
На остальных закладках оставьте параметры по умолчанию В окне свойств сервера
нажмите ОК.
При появлении окна с сообщением о необходимости перезагрузки маршрутизатора
нажмите Да (Yes).
М ршрутизация и удаленный доступ
Проведенные изменения конфигурации требуют перезагрузки маршрутизатора
ПрОДОПЖИТЬ'
Закроите административную консоль Маршрутизация и удаленный доступ (Routing
and Remote Access).
Настройка учетной записи пользователя
для возможности использования VPN-соединений
Для выполнения дальнейшей части лабораторной работы необходимо предоставить
пользователю <^тт»_»Инициалы вашего имени и фамилии» возможность подключаться
с использованием VPN-соединений. Для того чтобы предоставить пользователю возмож-
ность подключаться с использованием VPN-соединении, выполните следующие действия:
Запустите программу Active Directory — Пользователи и компьютеры (Users and
Computers).
344
Лабораторная работа N§ 3
Выберите пользователя, которому вы хотите предоставить возможность подсоединяться
через VPN-соединения, и, используя правую кнопку мыши, перейдите к его свойствам
В окне свойств учетной записи откройте вкладку Входящие звонки (Dial-In). В раз-
деле Разрешение на удаленный доступ (VPN-модем) (Remote Access Permission (Dial-in or
VPN)) установите опцию Разрешить доступ (Allow access) и нажмите OK.
Свойства: Алексей Воронцов
Удаленное управление | ric ? * ль служб* | М*
Общие | Адрес | Учетная запись | Профиль | Телефоны | Организация
Exchange General	|	Е-тай Addresses	| Exchange Features
ч |.»• - а  -ля вред . мщений | Среда | Сеансы
Член групп	Входящие звонхи
Разрешение на удаленный доступ (VPN или модем)
(• Р *•( •’.-*<ТЬ дост«1
Г* Запретить доступ
Г* ?пр t • Н ' П •» 41 уд • ’•НН  туп
Г* Г).- терять»
Ответный вызов сервера
Ответный вызов не выполняется
Устанавливается вызывающим (только для RAS)
Г4 Всегда по этому номеру
Г £татич • i-i IP ад по * • ат «я J .
Г ль -атьсгат •- кр м	-	--------------------
Определите маршруты, работающие	।
с входящим подключением	ем.ш |
Отмена | Пр1 г| Спр
Примечание. Эта вкладка отсутствует при настройке с рабочей станции
345
ЧАСТЫП ЛАБОРАТОРНЫЕ РАБОТЫ
Настройка рабочей станции
Для того чтобы подготовить рабочую станцию для использования VPN-соединений
необходимо установить на ней сертификат Центра сертификации.
Установка сертификата Центра сертификации на рабочую станцию
Для того чтобы установить сертификат Центра сертификации на рабочую станцию,
выполните следующие действия:
Скопируйте сертификат ЦС на рабочий стол станции.
Примечание. Сертификат Центра сертификации находится в корне диска С:
сервера, на котором установлен Центр сертификации.
На рабочем столе хоста выполните щелчок правой кнопкой мыши на сертификате
ЦС и выберите команду Установить сертификат (Install Certificate).
В окне приветствия мастера импорта сертификатов нажмите Далее (Next).
Мястер импорта сертификатов
Вас приветствует мастер
импорта сертификатов
Этот мастер помогает копировать сертификаты,
списки досерия и омски отзыва сертификатов с
локального диска в хранив ище сертификатов
Сертификат, выдажыи центром сертификации,
является подтверждением вашей личности и
содержит информацию, необходимую для защиты
данных или установления защищенны» сетевых
подключении Хранилище сертификатов - это
область системы предназначенная для хранегмя
сертификатов.
Д'|я г? одолжения нткните кнепку "Дале е'
с Назад [ Далее > | | Отмена |
Нажмите Далее (Next).
346
Лабораторная работа № 3
Нажмите Готово (Finish).
При появлении сообщения с предложением добавить сертификат в корневое храни-
лище нажмите Да (Yes).
После окончания процесса импорта появится окно с сообщением «Импорт успешно
выполнен». Нажмите ОК.
Создание VPN-соединения на рабочей станции
Для того чтобы на рабочей станции настроить VPN-соединение к серверу ЦС, вы-
полните следующие действия:
На рабочей станции откройте Панель управления (Control Panel).
Если вы используете вид панели управления по категориям, выберите Сеть и Под-
ключения к Интернету (Network and Internet Connections).
Выберите Сетевые подключения (Network Connections).
’• Сетевые подключения
Файл Правка Вид Избранное Сервис Дополнительно Справка
Назад ”	у Поиск Папки
A Alес С Сетевые подключения
Имя	Тип
ЛВС или высокоскоростной Интернет
X Local Area Connection	ЛВСиливысокоосорос...
-Д-LAN	ЛВСиливысокоосорос..
.Ь VMware Network Adapter VMnetl	PFt. или высокоскор»зс
X VMware Network Adapter VMnetB	ЛВСиливысокоосорос...
X1394Connection	ЛВСиливысокоосорос ..
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Нажмите Создание нового подключения (Create a new connection), чтобы запустить
мастер новых подключений.
В первом окне мастера новых подключений нажмите Далее (Next).
В окне Тип сетевого подключения (New Connection Туре) выберите Подключить к сети
на рабочем месте (Connect to the network at my workplace) и нажмите Далее (Next).
О Подключить к Интернету
Подключить к Интернету для просмотра веб-узлов и чтения электронной
почты
Q Подключить к сети на рабочем месте
Подключить к рабочей сети (используя удаленный доступ или VPNL чтобы
можно было работать из дома удаленного офиса или другого места
О Установить прямое подключение к другому компьютеру
Под! лэчлть нзгря^ус к другому компьютеру с по: юцыи пдглодивате.'ънсгс
параллельного или инфракрасного порта или настроить данный компьютер
позволив другим компьютерам подключаться к нему
[ < Наэод ~]| Далее > j [ Отмена ]
В окне Сетевое подключение (Network Connection) выберите Подключение к вирту-
альной частной сети (Virtual private network connection) и нажмите Далее (Next).
348
Лабораторная работа № 3
В окне Имя подключения (Connection Name) введите имя создаваемого подключения
Создать подключение
О Подключение удаленного доступа
Подключаться, используя модем и обычную телефонную линию,
либо телефонную линию ISDN
О Подключение к виртуальной частной сети
Подключение к сети с использованием подключения к виртуальной
частной сети (Virtual Private Network - VPN) через Интернет
[ < Назад ]| Далее > | [ Отмена ]
(VM SRV Internal LAN) и нажмите Далее (Next).
В окне Публичная сеть (Public Network) выберите Не набирать номер для предвари-
тельного подключения (Do not dial the initial connection) и нажмите Далее (Next).
349
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Выбор VPN-сервера (VPN Server Selection) введите IP-адрес сервера (в соот-
ветствии с настройками сервера — 192.168.73.145) и нажмите Далее (Next).
Введите имя узла или IP-адрес компьютера, к которому осуществляется
подключение
Имя компьютера или IP-адрес [например, microsoIt com или 157.54.0.1 Г
192.168 73.145
[ < Назад ][ Далее > j [ Отмена ]
В окне Смарт-карты (Smart Cards) выберите Использовать мою смарт-карту (Use тУ
smart card) и нажмите Далее (Next)
350
Лабораторная работа No 3
Вы можете настроить это подключение для использования смарт-карты для
входа в удаленную сеть. Укажите, следует ли использовать смарт-карту для
этого подключения
0 Использовать мою смарт-карту
О Не использовать мою смарт-карту
[ < Назад ][ Далее > | [ Отмена ]
В окне Доступность подключения (Connection Availability) выберите только для меня
(Му use only) и нажмите Далее (Next).
Для завершения работы мастера нажмите Готово (Finish)
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Примечание. По завершении работы мастера настройки система автоматиче-
ски запустит данное соединение. Нажмите Отмена (Cancel) для того, чтобы про-
извести настройку параметров данного VPN-соединения.
Настройка параметров VPN-соединения на рабочей станции
Созданное подключение в данный момент не позволяет подключиться к серверу, по-
скольку не определены параметры входа в сеть. Для того чтобы на рабочей станции на-
строить параметры VPN-соединения, выполните следующие действия:
На рабочей станции откройте Панель управления (Control Panel).
Если вы используете вид панели управления по категориям, выберите Сеть и Под-
ключения к Интернету (Network and Internet Connections).
Выберите Сетевые подключения (Network Connections).
Щелкните по значку VPN-соединения правой кнопкой мыши и выберите Свойства
(Properties).
352
Лабораторная работа № 3
В окне свойств соединения откройте вкладку Безопасность (Security) Выберите оп-
цию Дополнительные (выборочные параметры) Advanced (Custom settings) и нажмите Па-
раметры (Settings).
В окне Дополнительные параметры безопасности (Advanced security settings) установите
значение поля Шифрование данных — обязательное (отключиться если нет шифрования)
(Require encryption (disconnect if server declines)). В области Безопасный вход (Logon Security)
выберите Протокол расширенной проверки подлинности (ЕАР) (Use Extensible Authentication
Protocol (ЕАР)) и выберите Смарт-карта или иной сертификат (шифрование включено)
(Smart Card or other Certificate (encryption enabled)). Нажмите Свойства (Properties).
353
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Свойства смарт-карты или другого сертификата (Smart Card or other Certificate
Properties) в области При подключении (When connecting) выберите использовать мою
смарт-карту (Use my smart card). Установите флажок Проверка сертификата сервера
(Validate server Certificate) Установите флажок Подключение к серверам (Connect to these
servers) и введите DNS-имя VPN-сервера (server.northwind.ru). В списке Доверенные кор-
невые центры сертификации (Trusted Root Certification Authorities) установите флажок,
соответствующий центру сертификации, присутствующему в пути сертификации серти-
фиката VPN-сервера (DS Root). Нажмите ОК.
В окне Дополнительные параметры безопасности (Advanced security settings) нажмите OK.
В окне свойств соединения нажмите ОК.
Установка VPN-соединения
Для того чтобы получить доступ к корпоративным ресурсам с помощью VPN-под-
ключения, выполните следующее.
Откройте Панель управления (Control Panel).
Если вы используете вид панели управления по категориям, выберите Сеть и под-
ключения к Интернету (Network and Internet Connections).
Выберите Сетевые подключения (Network Connections).
Убедитесь в том, что ваш eToken подключен к компьютеру. На USB-ключе eToken
должен гореть световой индикатор. Для установки VPN-соединения к компьютеру дол-
жен быть подключен только один eToken, содержащий сертификат, предназначенный
для входа в сеть по смарт-карте (Smart Card Logon).
В разделе Виртуальная частная сеть (VPN) (Virtual Private Network) дважды щелкните
по значку соответствующего подключения.
Введите PIN-код.
354
Лабораторная работа № 3
Примечание. Данный адаптер включается для обеспечения условий проведения
следующего практического задания.
На хосте создайте и настройте VPN-соединение. Выполните следующие действия:
Зайдите в сетевые свойства, выберите адаптер «...VMnetl», вызовите контекстное ме-
ню и выберите пункт Отключить (Disable);
Перейдите в командную строку (используйте Пуск -> Выполнить -> cmd (Start Run ->
cmd);
В командной строке запустите команду ping 192.168.1.145 и ping 192.168.1.2;
Используя созданное вами соединение, подсоединитесь по VPN к VM SRV, исполь-
зуя сертификат пользователя «Ас1тт»_»Инициалы вашего имени и фамилии»;
В командной строке запустите команду ping 192.168.1.145 и ping 192.168.1.2;
Запустите на хосте «Проводник» и выберите в меню Сервис (Tools) пункт Подключить
сетевой диск... (Map Network Drive). Попытайтесь подсоединиться к папке \\са\с$
(используйте входное имя и пароль доменного администратора);
Отключитесь от VPN;
На хосте зайдите в сетевые свойства, выберите адаптер ...VMnetl и через правую
кнопку мыши задайте для него параметр Включить (Enable).
Сведения об установленном VPN-соединении
Для того чтобы получить сведения о параметрах установленного VPN-соединения,
выполните следующее:
Щелкните правой кнопкой мыши по значку установленного соединения и выберите
Состояние (Status).
RU
Корзина
> @ 10:43
В окне состояния соединения откройте вкладку Сведения (Details).
355
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Создание дополнительного веб-сервера
Для создания дополнительного сервера, работающего по тому же порту, что и основ-
ной, но с другим DNS именем, выполните следующие действия:
Откроите программу System Manager, нажав Пуск —> Программы -> Microsoft Exchange
(Start -> Programs -> Microsoft Exchange).
Выдел иге раздел HTTP, открыв Northwind (Exchange) -> Servers -> SERVER -> Protocols
Нажмите правую клавишу мыши и выберите Создать HTTP Virtual Server (New
HTTP Virtual Server).
356
Лабораторная работа № 3
В окне Свойства (Properties) задайте имя для веб-сервера (например — OWA) и наж-
е кнопку Advanced.
Свойства
JjjcJ
General | Access |
 С1 Нате	|~
IP address;	|(AI Unassigned)	Advanced |
Г Lr,A г. nnbei of cor rectum
Т rne-out (secs)	|900
Exchange Path-------------------------------------------------
<• Майонез for
C Pybbcfoider
|northwind ru (defadt)	|
Г" fnabie Forms Based Authentication for Outlook Web Access
To configure venous other setbngs on this HTTP vrtual server use the
Internet Information Services (IIS) snap-n
OK ~| Отмена | П 	| Справка
В открывшемся окне выберите существующую запись и нажмите кнопку Modify
Advanced
Configure multiple identities for this virtual server.
Identities:
IPAddress_ | TCP Port | SSL Port Host name
j AH Unassi^ned 0
Add... | Modtfy...
OK | Cancel | help
В открывшемся окне в поле Host name введите DNS-имя веб-сервера (например —
а.northwind.ru) и нажмите ОК.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Свойства (Properties) нажмите ОК
Закройте все окна, нажав ОК. Закройте программу System Manager
Настройка подключения к новому веб-серверу по HTTPS
Для настройки подключения к новому веб-серверу по HTTPS выполните следующие
действия:
Запустите программу Диспетчер служб IIS (Internet Information Services (IIS))
Manager, нажав Пуск -> Программы -> Администрирование (Start -> Programs -> Admini-
stration Tools).
В дереве консоли разверните узел данного сервера, щелкните правой кнопкой мыши
Internet Information Services -> Server (локальный компьютер) -» Веб-узлы (Internet Infor-
mation Services SERVER (local computer) -> Web Sites) и выберите Свойства (Properties).
В окне Свойства: Веб-узлы (Web Sites Properties) перейдите на вкладку Безопасность
каталога (Directory Security) Установите флажок Сопоставление службы каталогов
Windows (Enable the Windows directory service mapper). Нажмите OK.
358
Лабораторная работа Ns 3
Появится окно Изменение наследования (Inheritance Overrides). Нажмите Select All.
а потом нажмите ОК.
Изменение наследования
Следующие дочерние узлы также определили значение свойства
"UNCPassword", перезаписав только что заданное вами значение. Выберите
узлы которые должны применять новое значение.
Дочерние узлы.
Detail# Web Site/Exadmin
Default Web Site/Exchange
Default Web Site/Microsoft-Server ActiveSyn*
Default Web Site/OMA
Default Web Site/Public
OWa/
||,£ьцел»львсе j
OK
Отмена
Справка |
В окне Диспетчер служб IIS (Internet Information Services (IIS) Manager) Выберите но-
вый веб-сайт (OWA) и перейдите к редактированию его свойств.
359
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Свойства: OWA (OWA Properties) откройте вкладку Веб-узел (Web Site).
Назначьте веб-сайту порт SSL (например, 443).
360
Лабораторная работа № 3
Откройте вкладку Безопасность каталога (Directory Security). В секции Управление до-
ступом и проверка подлинности (Authentication and access control) нажмите Изменить (Edit).
В окне Методы проверки подлинности (Authentication methods) снимите все флажки
и нажмите ОК.
14 5680
361
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Примечание, Это делается для того, чтобы исключить все способы аутентифи-
кации для доступа к сайту, кроме SSL.
В Диспетчер IIS (IIS Manager) окне нажмите Да (Yes).
В разделе Безопасные подключения (Secure Communications) нажмите Сертификат
(Server Certificate), чтобы запустить мастер сертификатов.
На первой странице мастера сертификатов веб-сервера нажмите Далее (Next).
362
Лабораторная работа N° 3
На странице Сертификат сервера (Server Certificate) выберите Создание нового сер-
тификата (Create a new certificate) и нажмите Далее (Next).
Выберите способ назначения сертификата для данного веб-узла
<• Создание новогосертиФикатй
С Назначение существующего сертификата
С И мпдрт сертификата из файла архива диспетчера ключей
С Импорт сертификата из файла .pfx
С Копирование или перемещение сертификата с удаленного узла на этот узел
< Назад I Далее > I Отмена
363
ЧАСТЬ III. ЛАБОРА ТОРНЫЕ РАБОТЫ
На странице Отложенный или немедленный запрос (Delayed or Immediate Request) вы-
берите Немедленно отправить запрос в локальную службу сертификации (Send the request
immediately to an online certification authority) и нажмите Далее (Next).
На странице Настройка имени и безопасности (Name and Security Settings) введите имя
для сертификата WEB-сервера (например — owa.northwind.ru) и длину криптографиче-
ского ключа (например — 1024) Установите флажок Выбор поставщика шифрования
(CSP) для данного сертификата (Select cryptographic service provider (CSP) for this
certificate) для выбора поставщика криптографических средств (CSP) для запрашивае-
мого сертификата. Нажмите Далее (Next).
Мастер сертификатов IIS
Настройка имени и безопасности
Для нового сертификата необходимо задать имя и длину в битах.
Введите имя сертификата. Это имя должно быть легким для запоминания и
ссылок.
Имя:
|owa northwind ru
Длина ключа определяет стойкость шифра Чем больше длина тем выше
безопасность Но при этом снижается быстродействие.
Длина (бит):	|Ю24	3
Р Выбор поставщика шифрования (CSP) для данного сертификата
< Назад I Далее > I Отмена
364
Лабораторная работа № 3
В списке поставщиков выберите Microsoft RSA SChannel Cryptographic Provider
и нажмите Далее (Next).
Мастер сертификатов IIS
Доступные поставщики
Ниже перечислены поставщики шифрования подходящи* для
вашего оертифи- ата
Выберите поставщика
Microsoft DH SChannel Cr i to j at hie Provider
ignnel Cryptographic Provide1
< Назад I Далее > I Отмена
На странице Сведения об организации (Organization Information) введите название ва-
шей организации — Northwind и подразделения — EDU и нажмите Далее (Next).
Мастер сертификатов IIS
Сведения об организации
Сертификат должен содержать сведения о вашей организации,
отличающие его от сертификатов других организаций
Введите название своей организации и подразделения Обычно это реальные
названия
Для получения дополнительных сведений посетите веб-узел службы сертификации
Организация
[North wind
Подразделение-
JeduF
< Назад I Далее >
Отмена
365
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
На странице Полное имя узла (Your Site’s Common Name) введите полное доменное
имя вашего сайта — owa.northwind.ru и нажмите Далее (Next).
На странице Сведения о местоположении (Geographical Information) введите страну,
регион и населенный пункт. Нажмите Далее (Next).
На странице Порт SSL (SSL Port) убедитесь в том, что указан верный номер порта
SSL, используемый WEB-сервером.
366
Лабораторная работа № 3
На странице Выбор службы сертификации (Choose a Certification Authority) выберите
Центр сертификации. Нажмите Далее (Next)
Мастер сертификатов IIS
Выбор службы сертификации
Запросы сертификата отправляются в службу сертификации
доступную в локальной сети
Выберите службу сертификации для обработки запроса
Службы СвртИфИКацИИ
[server г iorthwind ru\DS Root
Отмена
Примечание. Этотп Центр сертификации должен совпадать или находиться
в доверительных отношениях со всеми центрами сертификации, выдающими сер-
тификаты пользователям, которые должны будут получать доступ к защищенному
сайту.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
На странице Отправка запроса сертификата (Certificate Request Submission) проверьте
введенную информацию. Если вам необходимо внести какие-либо изменения, нажмите
Назад (Back). Для формирования запроса на сертификат нажмите Далее (Next).
Мастер сертификатов IIS
Отправка запроса сертификата
Отправка указанного запроса сертификата.
Чтобы отправить запрос нажмите кнопку "Далее".
Служба сертификации:
server northwndru
DS Root
Псромэтрь • запроса.
Получтгел: ссртифг атэ
Понятное имя
Страна
Область
Город
Организация
Подразделение
owa.northwind.ru
owancrthvrdrii
RU
SPB
St Petersburg
Northwind
EDU
Отмена
Если сертификат веб-сайта установлен, в последнем окне мастера сертификата
WEB-сервера будет присутствовать сообщение «А certificate is now installed on this server».
Нажмите Готово (Finish).
В разделе Безопасные подключения (Secure communications) нажмите Изменить (Edit).
368
Лабораторная работа № 3
В окне Безопасные подключения (Secure communications) установите флажки Требуется
безопасный канал (SSL) (Require secure channel (SSL)) и Требуется 128-разрвдное шифро-
вание (Require 128-bit encryption). Выберите Требовать сертификаты клиентов (Require
client certificates), установите флажок Разрешить сопоставление сертификатов клиентов
(Enable client certificate mapping). Для того чтобы при авторизации посетителей сайта могли
использоваться сертификаты, выданные различными центрами сертификации, служат
списки доверенных сертификатов. Для того чтобы составить новый список, установите
флажок Включить список доверенных сертификатов (Enable certificate trust list). Нажмите
Создать (New), чтобы запустить мастер составления списков доверенных сертификатов.
369
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В первом окне мастера списков доверия сертификатов нажмите Далее (Next)
Мастер списков доверия
сертификатов
Этот мастер помогает создать список: доверия
сертифкатоо юм изиокить существуют^ список
доверия
Слисок доверия сертификатов (СП.) является
подлисанньи стеком сертификатов корневого ЦС,
которые быт ©пределе»ы адтнистраторои как
мслуж>«ающини доверия
Для продо*»»*» мажттв киоску "Далее*
В окне Сертификаты в списке доверия (Certificates in the CTL) нажмите Добавить из
хранилища (Add from Store).
В окне Выбор сертификата (Select Certificate) выберите сертификат Центра сертифи-
кации (DS Root) и нажмите ОК. В окне Сертификаты в списке доверия (Certificates in the
CTL) нажмите Далее (Next).
Выбор сертификата
_?jxj
Выборите сертифмсаты для ислотэомния
ЕЗ*ceoft Roo... Mcrosoft .. <Все>
Mcrosof. . 09.05.2...
<Bce> Mcrosof . 31.12.2...
Hf><cp - Matlock... 20.02.2...
Зашище... GTECyb... 03.04.2...
0MterosoftRoo ... Mcrosoft...
Qtetux k Exp . NetLockE..
E3gTE CyberTru... GTE Cyber...
E3veriSign Trust... ver&gnTr...
OK | Отмена | Просмотр сертификата
370
Лабораторная работа № 3
В окне Имя и описание (Name and Description) введите название списка сертификатов
(например — Northwind IIS CTL). Нажмите Далее (Next).
Проверьте параметры списка сертификатов- если вам необходимо внести какие-либо
изменения, нажмите Назад (Back). Для завершения работы мастера составления списка
нажмите Готово (Finish).
Мастер списков доверия сертш| шматов
Завершение мастера списка
доверия сертификатов
Работа мастера успешно завершена
Выбраны следующие параметры:
Цель	Проверка подлинности клиента
1.3.6.1.4.1.311.30.1
Идентификатор :5AQ€tO?A-DE96-4F9cВ739-Т>₽В;
Срок действия <мет>
Понятное имя	NorthwrxJ IIS CTL
Описание	Данный список доверенных серп
При успешном завершении работы мастера на экране появится окно с сообщением
«Мастер списка доверия сертификатов успешно завершил работу.» («The Certificate Trust
List wizard succeeded.»). Нажмите OK
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Безопасные подключения (Secure Communications) нажмите ОК.
В окне свойств сайта нажмите ОК
В окне Изменение наследования (Inheritance Overrides) нажмите Выделить все (Select АП)
для того, чтобы сделанные настройки были применены ко всем сайтам данного сервера,
и нажмите ОК.
В дереве консоли Диспетчер служб IIS (Internet Information Services (IIS) Manager)
щелкните правой кнопкой мыши по имени сервера — SERVER (локальный компьютер)
(SERVER (Local computer)). В контекстном меню выберите Все задачи > Перезапуск IIS
(АП Tasks > Restart IIS).
372
Лабораторная работа N° 3
В окне Остановка, запуск или перезагрузка (Start/Stop/Restart) выберите пункт Пере-
запуск служб Интернета на SERVER (Restart Internet Services on SERVER) и нажмите OK.
Остановка, запуск или перезагрузка
Какая операция должна быть выполнена в IIS?
езап ск сл ♦ б Инте нета на SERVER
Останоыа и псзторкьЙ допуск ьсех слуигб К 1теркет< ।
Все текущие сеансы связи будут потеряны, а все узлы
Интернета будут недоступны, пока службы Интернета
не будут запущены вновь.
Выберите этот параметр, если нужно установить файлы
или компоненты которые недоступны при работе служб
Интернета.
OK J
Отмена I Справка
Создание DNS-имени для нового веб-сервера
Чтобы создать DNS-имя для нового веб-сервера выполните следующие шагиз
Запустите на сервере программу DNS (DNS Manager), нажав Пуск -> Программы ->
Администрирование (Start -> Programs -> Administrative Tools).
Выделите папку SERVER Зоны прямого просмотра northwind.ru (SERVER -> Forward
Lookup Zones -> northwind.ru) и через правую клавишу мыши выберите Создать псевдо-
ним (CNAME) (New Alias (CNAME)).
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Новая запись ресурса (New Resource Record) в поле Псевдоним (Alias name)
введите DNS-имя нового веб-сайта (например — owa) относительно домена
northwind.ru, а в поле Полное доменное имя (Fully qualified domain name) ведите его пол-
ное DNS-имя. Нажмите ОК.
Настройка рабочей станции
Настройка сетевых подключений на хосте
Действия выполняются на хосте.
На хосте зайдите в сетевые свойства и измените параметры для подключения
«...VMnetl» в соответствии с рисунком.
Отсоедините сетевой кабель от адаптера LAN на хосте (если он использует сеть
192.168.1.0).
374
Лабораторная работа № 3
Настройка файла hosts на хосте
Отредактируйте на хосте файл hosts (данный файл находится в папке
C:\Windows\system32\drivers\etc) Для этого выполните следующие действия:
Откройте файл, выполнив двойной щелчок мыши В появившемся окне Выбор про-
граммы (Select program) выберите программу «Блокнот» («Notepad») и нажмите ОК.
В окне программы введите:
192.168.L145ca.aladdin.edu
192.168.1.145owa.aladdin.edu
Сохраните файл и закройте программу «Блокнот» («Notepad»).
Доступ к веб-сайту по протоколу HTTPS
Для получения доступа к веб-сайту по HTTPS выполните следующие действия:
Запустите Microsoft Internet Explorer.
Попытайтесь подсоединиться к веб-сайту owa.northwind.ru (http://owa.northwind.ru) и
server.aladdin.edu (http://server.northwind.ru), используя протокол http.
Убедитесь в том, что ваш eToken с сертификатом, дающим право на доступ к сайту,
подключен к компьютеру. На USB-ключе eToken должен гореть световой индикатор.
Введите адрес защищенного сайта, начинающийся с https: (https://owa.northwind.ru).
В появившемся окне нажмите ОК.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Выбор цифрового сертификата (Select certificate) выберите сертификат поль-
зователя «Admin»_»Инициалы вашего имени и фамилии». Используйте Просмотр серти-
фиката (View certificate) для того, чтобы убедиться, что выбран правильный сертификат.
В окне Сертификат (Certificate) в поле указан пользователь, кому выдан данный сер-
тификат. Нажмите ОК.
В окне Выбор сертификата (Select Certificate) нажмите ОК
В появившемся окне введите PIN-код eToken.
376
Лабораторная работа Ns 3
Результат тестирования доступа к защищенному веб-сайту можно считать положи-
тельным, если не удается подключиться к сайту по протоколу HTTP, и удается подклю-
читься к сайту по протоколу HTTPS с использованием сертификата пользователя, хра-
нящемся в ключе eToken.
Электронная цифровая подпись в Word 2003
Создание ЭЦП в Word 2003
Для создания ЭЦП в Word 2003 выполните следующие действия:
Убедитесь в том, что необходимый eToken подключен к компьютеру. На USB-ключе
eToken должен гореть световой индикатор. Для установки VPN-соединения к компьютеру
должен быть подключен eToken, содержащий сертификат, позволяющий создавать ЭЦП
Запустите программу Microsoft Office Word 2003, нажав Пуск -> Программы -> Microsoft
Office (Start -> Programs -> Microsoft Office).
Создайте новый или откроите ранее созданный документ
Из меню Сервис перейдите в раздел Параметры.
377
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Параметры перейдите на вкладку Безопасность В секции Параметры совмест-
ного использования для данного документа нажмите Цифровые подписи...
В окне Цифровая подпись нажмите Добавить...
378
Лабораторная работа № 3
В появившемся окне нажмите Да.
Microsoft Office Word
ISCI
Перед добавлением цифровой подписи документ необходимо сохранить в
формате документа Word.
Сохранить документ?
L	. 1 н-т
В окне Выбор сертификата выберите сертификат, позволяющий создавать ЭЦП (на-
пример — User DS). Нажмите ОК.
Выбор сертификата	? X
Выберите сертификат.
ОК | [ Отмена ] [ Просмотр сертификата ]
В появившемся окне введите PIN-код eToken.
379
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Цифровая подпись установите опцию Присоединять сертификаты к добавляе-
мым подписям и нажмите ОК.
В окне Параметры нажмите ОК.
Закройте документ.
Проверка ЭЦП в Word 2003
Для проверки ЭЦП в Word выполните следующие действия:
Откройте документ, содержащий ЭЦП. Для проверки подписи дважды щелкните
указателем мыши на знак ЭЦП в правом нижнем углу экрана данного документа
51 Данный документ подписан с использованием ЭЦП.doc Microsoft Word
! Файл Правка Вид Вставка Форват Сервис Даблина Окно ^правка	В* дит	* к
-J	-1г -
||J	1 • 1 * 1 • 2 ’ • • 3 • ‘ • 4 • ' ’ 5 • । • 6 • • • 7 • । • 8 • I • 3 • I -10 - । 11- • -12- I -13 - I -14- I -15- • - И -л.
Данный документ подписан с использованием ЭЦП.|
 г» ЦБ] з и <
Стр. 1 Разд 1 1/1 На 2см Ст 1 Klptfi 47.
р;г -ши  Ро
Откроется окно Цифрок&я подпись. В ж«ем будет показан сертификат, с помощью ко-
торого подписан данный документ, а также информация о данном сертификате (кем
. данный сертификат издан и т.п.)
380
Лабораторная работа No 3
Примечание. Для того чтобы система могла проверить сертификат, с помощью
которого создано ЭЦП документа, Центр сертификации, издавший данный серти-
фикат, должен присутствовать в списке доверенных центров сертификации на дан-
ном компьютере.
Настройка Outlook 2003для шифрования и ЭЦП сообщений
Настройка Outlook 2003 для нового пользователя
Для того чтобы новый пользователь мог использовать Outlook 2003, необходимо вы-
полнить следующие действия:
Зарегистрируйтесь на компьютере под пользователем, для которого вы хотите на-
строить Outlook (например — «User»_»Инициалы вашего имени и фамилии»)
Запустите Microsoft Office Outlook 2003. нажав Пуск -> Программы Microsoft Office
(Start -> Programs -> Microsoft Office).
В окне Настройка Outlook 2003 нажмите Далее.
В окне Настройка учетной записи выберите опцию Да и нажмите Далее.
В окне Учетные записи электронной почты выберите опцию Microsoft Exchange Server
и нажмите Далее.
В окне Учетные записи электронной почты в поле Microsoft Exchange Server введите
имя сервера (например — server), отключите опцию Использовать режим кэширования
Exchange и в поле Имя пользователя введите входное имя пользователя. Нажмите Про-
верить имя для того, чтобы проверить введенную информацию.
382
Лабораторная работа N° 3
После того, как система уточнит информацию, в окне Учетные записи электронной
почты нажмите Далее.
383
В окне Учетные записи электронной почты нажмите Готово.
В появившемся окне нажмите ОК.
Настройка параметров Outlook 2003 для шифрования и ЭЦП сообщений
Для того чтобы настроить параметры Outlook 2003 для возможности шифрования и
ЭЦП сообщений, необходимо выполнить следующие действия:
Зарегистрируйтесь на компьютере под пользователем, для которого вы хотите на-
строить параметры Outlook (например — «и8ег»_»Инициалы вашего имени и фами-
лии»).
Запустите приложение Microsoft Office Outlook 2003, нажав Пуск Программы Micro-
soft Office (Start -> Programs -> Microsoft Office).
Из меню Сервис перейдЛе в раздел Параметры.
384
В окне Параметры перейдите на вкладку Безопасность. В секции Шифрованная элек-
тронная почта нажмите Параметры.
385
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Изменения настройки безопасности в секции Сертификаты и алгоритмы наж-
мите Выбрать...
В окне Выбор сертификата выберите сертификат пользователя, с помощью которого
вы будете создавать ЭЦП для сообщений (например — сертификат пользователя
«User» » Инициалы вашего имени и фамилии», предназначенный для Защиты сообще-
ний электронной почты) и нажмите ОК.
В окне Изменения настройки безопасности нажмите ОК.
В окне Параметры нажмите Опубликовать в глобальном списке адресов.
В появившемся окне нажмите ОК.
386
Лабораторная работа № 3
В появившемся окне введите PIN-код и нажмите ОК.
В окне Параметры нажмите ОК.
Настройка Outlook Web Access для шифрования и ЭЦП сообщений
Для того чтобы настроить параметры Outlook Web Access для шифрования и ЭЦП со-
общений, необходимо выполнить следующие действия:
Запустите Microsoft Internet Explorer.
Убедитесь в том, что ваш eToken с сертификатом, дающим право на доступ к сайту,
подключен к компьютеру. На USB-ключе eToken должен гореть световой индикатор.
Войдите на сайт Outlook Web Access (https://owa.northwind.ru), используя eToken с сер-
тификатом пользователя, для которого вы хотите настроить параметры Outlook Web Access
В открывшемся окне выберите раздел Параметры.
3 Microsoft Outlook Web Access - Microsoft Internet Explorer
Файл Правка Вид Избранное Сервис Справка
j Назад ’	, Поиск Избранное v ‘ Медиа в
Адрес: [jb] https://owa.northwind.ru	v Переход Links
387
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В окне Параметры в разделе Безопасность электронной почты нажмите кнопку Загрузить
G OutlookWebAbCtbs ® Пар^етры
__| Папки
Administrator
, Входящие
jfi Дневник
tii Задачи
Заметки
^Исходящие
3Календарь
Вй Контакты
Л Нежелательная
О *1 А Сохранить и закрыть Закрыть -Справка
। юмема1 ь сииищения как ирит ьнные через	секунд
0 Помечать сообщения как прочтенные при выборе другого сообщения
О Не помечать автоматически элементы как прочтенные
Выход
Параметры проверки орфографии
Пропускать слова из ПРОПИСНЫХ букв
Пропускать слова с цифрами
Всегда проверять орфографию перед отправкой
Выберите язык словаря для проверки орфографии
(Выберите язык)	*
□
□
□
Входящие
Календарь
Контакты
Задачи
Общие па
Пра» л
Безопасность электронной почты
j * Установка последней версии эленен'а управления S/MIME
l i................. -.—-----------------------------
I Загрузить
е | Параметры
Обеспечение конфиденциальности данных и защита от нежелательной почты
Примечание. Если управление S/MIME уже установлено на компьютер, кнопка
Загрузить отсутствует, вместо нее появляется кнопка Переустановить.
В появившемся окне нажмите Да.
В появившемся окне нажмите Да.
388
Лабораторная работа № 3
В окне Параметры в панели управления нажмите Закрыть.
Для удаления управления S/MIME из Outlook Web Access выполните следующие шаги:
В Панели Управления (Control Panel) выберите Установка и удаление программ (Add
or Remove Programs).
В списке установленных программ выберите Microsoft Exchange Outlook Web Access
S/MIME и нажмите Изменить/Удалить (Change/Remove).
Использование Outlook 2003
для защиты сообщений электронной почты
Создание сообщений с ЭЦП
Для того чтобы в Outlook 2003 создать сообщение с ЭЦП, необходимо выполнить сле-
дующие действия:
Зарегистрируйтесь на компьютере под пользователем, от имени которого вы хотите
создать сообщение.
Запустите приложение Microsoft Office Outlook 2003, нажав Пуск -> Все программы ->
Microsoft Office (Start —> Programs —> Microsoft Office).
На Панели управления нажмите Создать —> сообщение.
В поле Кому... укажите получателя письма (например — admin_ds) и на панели уп-
равления установите опцию Подписать. При необходимости укажите тему и введите сам
тест сообщения. На Панели управления нажмите Отправить.
389
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В появившемся окне введите PIN-код eToken и нажмите ОК.
Создание зашифрованного сообщения
Для того чтобы в Outlook 2003 создать зашифрованное сообщение, необходимо вы-
полнить следующие действия:
Зарегистрируйтесь на компьютере под пользователем, от имени которого вы хотите
создать сообщение.
Запустите приложение Microsoft Office Outlook 2003, нажав Пуск -> Программы -> Micro-
soft Office (Start -> Programs -> Microsoft Office).
На Панели управления нажмите Создать (сообщение).
В поле Кому... укажите получателя письма (например — admin_ds) и на панели уп-
равления установите опцию Зашифровать сообщение. При необходимости укажите тему
и введите сам тест сообщения. На Панели управления нажмите Отправить.
Проверка ЭЦП в сообщении
Для того чтобы в Outlook 2003 произвести проверку ЭЦП в сообщении, необходимо
выполнить следующие действия:
Зарегистрируйтесь на компьютере под пользователем, на имя которого пришло со-
общение с ЭЦП.
Запустите приложение Microsoft Office Outlook 2003. нажав Пуск -» Программы -> Micro-
soft Office (Start Programs > Microsoft Office).
390
Лабораторная работа № 3
В почтовом ящике данного пользователя выберите папку Входящие.
Дважды щелкните мышью на сообщение, содержащее ЭЦП.
В окне с сообщением нажмите на значок подписи (справа внизу в заголовке
письма).
В окне Цифровая подпись представлены результаты проверки ЭЦП (например, в дан-
ном примере подпись является действительной и достоверной). Для получения допол-
нительной информации о сертификате, с помощью которого создана данная ЭЦП, наж-
мите Сведения.
Цифровая подпись; правильная
От:
я
Test Sign
Алексей Воронцов
Цифровая подпись сообщения является действительной и
доверенной.
Для просмотра сведений о сертификате, применяемом в
цифровой подписи сообщения, нажмите кнопку "Сведения'’.
Сведения...
П Предупреждать об ошибках в подписанных сообщениях до открытия.
| Закрыть
В окне Свойства безопасности сообщения представлена более подробная информация
о сертификате, использованном для создания ЭЦП данного сообщения.
391
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Открытие зашифрованного сообщения
Для того чтобы в Outlook 2003 открыть зашифрованное сообщение, необходимо вы-
полнить следующие действия:
Зарегистрируйтесь на компьютере под пользователем, на имя которого пришло за-
шифрованное сообщение.
Запустите приложение Microsoft Office Outlook 2003, нажав Пуск -> Программы -> Micro-
soft Office (Start -> Programs -> Microsoft Office).
В почтовом ящике данного пользователя выберите папку Входящие.
Дважды щелкните мышью на зашифрованное сообщение.
В появившемся окне введите PIN-код eToken и нажмите ОК.
392
Лабораторная работа № 3
В окне с сообщением нажмите на значок зашифрованного сообщения (справа внизу
в заголовке письма).
В окне Свойства безопасности сообщения представлена информация о параметрах,
использованных при шифровании данного сообщения.
15-5680
393
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Использование Outlook Web Access
для защиты сообщений электронной почты
Создание сообщений с ЭЦП
Для того чтобы в Outlook Web Access создать сообщение с ЭЦП, необходимо выпол-
нить следующие действия:
Запустите Microsoft Internet Explorer.
Убедитесь в том, что ваш еТокеп с сертификатом, дающим право на доступ к сайту,
подключен к компьютеру. На USB-ключе eToken должен гореть световой индикатор.
Войдите на сайт Outlook Web Access (например, https://owa.northwind.ru), используя
eToken с сертификатом пользователя, от имени которого вы хотите создать сообщение.
На Панели управления нажмите Создать (сообщение).
В поле Кому... укажите получателя письма и на панели управления установите опцию
Подписать. При необходимости укажите тему и введите сам тест сообщения. На Панели
управления нажмите Отправить.
Создание шифрованных сообщений
Для того чтобы в Outlook Web Access создать зашифрованное сообщение, необходимо
выполнить следующие действия:
Запустите Microsoft Internet Explorer.
Убедитесь в том, что ваш eToken с сертификатом, дающим право на доступ к сайту,
подключен к компьютеру. На USB-ключе eToken должен гореть световой индикатор.
Войдите на сайт Outlook Web Access (например, https://owa.northwind.ru), используя
eToken с сертификатом пользователя, от имени которого вы хотите создать сообщение.
На Панели управления нажмите Создать (сообщение).
В поле Кому... укажите получателя письма и на панели управления установите опцию
Зашифровать сообщение. При необходимости укажите тему и введите сам тест сообще-
ния. На Панели управления нажмите Отправить.
394
Лабораторная работа Ns 3
Проверка ЭЦП в сообщениях
Для того чтобы в Outlook Web Access произвести проверку ЭЦП в сообщении, необ-
ходимо выполнить следующие действия:
Запустите Microsoft Internet Explorer.
Убедитесь в том, что ваш eToken с сертификатом, дающим право на доступ к сайту,
подключен к компьютеру. На USB-ключе eToken должен гореть световой индикатор.
Войдите на сайт Outlook Web Access (например, https://owa.northwind.ru), используя
eToken с сертификатом пользователя, на имя которого пришло сообщение с ЭЦП.
В почтовом ящике данного пользователя выберите папку Входящие.
Дважды щелкните мышью на сообщение, содержащее ЭЦП.
В окне с сообщением нажмите на значок подписи (справа внизу в заголовке письма).
В окне Цифровая подпись представлены результаты проверки ЭЦП (например,
в данном примере цифровая подпись этого сообщения действительна и является до-
веренной).	г
395
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Открытие шифрованных сообщений
Для того чтобы в Outlook 2003 открыть зашифрованное сообщение, необходимо вы-
полнить следующие действия:
Запустите Microsoft Internet Explorer.
Убедитесь в том, что ваш eToken с сертификатом, дающим право на доступ к сайту,
подключен к компьютеру. На USB-ключе eToken должен гореть световой индикатор.
Войдите на сайт Outlook Web Access (например, https://owa.northwind.ru), используя
eToken с сертификатом пользователя, на имя которого пришло зашифрованное сообщение.
В почтовом ящике данного пользователя выберите папку Входящие.
Дважды щелкните мышью на зашифрованное сообщение.
В окне будет представлено само сообщение (расшифрованное), а справа внизу в за-
головке письма будет стоять значок зашифрованного сообщения.
396
Лабораторная работа № 3
Содержание отчета
Отчет оформляется один на бригаду из одного-двух исполнителей.
В отчете с титульным листом установленной формы (см. Приложение А) необходимо
поедставить следующие сведения:
1	Наименование и цели работы.
2	Краткую характеристику учебного стенда (по составу доступных пользователю
функций управления и индикаций, распределению ресурсов, функций, вариантов
набора преобразований).
3	функциональную схему учебного стенда с пояснениями и комментариями.
4	Описание настроек сервера и рабочей станции для удаленного доступа к рабочему
столу.
5	. Описание настроек виртуальной частной сети.
6	. Настройки созданного нового защищенного веб-сервера для доступа к нему по про-
токолу HTTPS.
7	. Настройки MS Word 2003 и MS Outlook 2003 для применения ЭЦП.
8	. Подготовиться для устных ответов по контрольным вопросам.
Контрольные вопросы
1.	Как настроить учебный стенд для работы виртуальной частной сети?
2.	Как использовать ЭЦП в MS Word 2003?
3.	Как создать защищенный веб-сервер?
4.	Каким образом можно настроить MS Outlook 2003 для шифрования сообщений9
5.	В чем заключаются отличия протоколов РРР и ЕАР?
Приложение А
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
ИСПОЛЬЗОВАНИЕ eToken ДЛЯ БЕЗОПАСНОГО ДОСТУПА
К ИНФОРМАЦИОННЫМ РЕСУРСАМ
ДЛЯ ШИФРОВАНИЯ И ДЛЯ ЭЦП
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
Выполнили:
Студенты гр._______________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
398
Лабораторная работа № 4
СОПРОВОЖДЕНИЕ ФУНКЦИОНИРОВАНИЯ
ЦЕНТРА СЕРТИФИКАЦИИ,
ПОВЫШЕНИЕ ЗАЩИЩЕННОСТИ СИСТЕМ
НА ОСНОВЕ WINDOWS SERVER 2003
Цель работы
Изучить практические вопросы по сопровождению функционирования Центра сер-
тификации и рассмотреть практические советы по повышению защищенности систем на
основе Windows Server 2003.
Общие сведения по сопровождению функционирования
Центра сертификации и повышению безопасности систем
на основе Windows Server 2003
Архивирование и восстановление ЦС
В данной лабораторной работе будут рассмотрены практические вопросы по сопро-
вождению функционирования Центра сертификации, которое, помимо изученных ра-
нее операций настройки и выпуска сертификатов, включает архивирование и восста-
новление состояния системы (компьютера, на котором установлен ЦС), архивирование
и восстановление собственно самого ЦС, а также такие операции, как архивирование
сертификатов, аннулирование и удаление сертификатов.
Первая часть работы посвящена вопросам архивирования сертификатов. Кроме того,
специалистами компании Microsoft рекомендовано регулярное архивирование данных
на компьютере, выполняющем функции Центра сертификации В процессе сопровож-
дения функционирования Центра сертификации также может потребоваться архивиро-
вание данных и самого Центра сертификации.
В процессе выполнения работы слушатели познакомятся с рекомендациями спе-
циалистов компании Microsoft по сопровождению функционирования Центра серти-
фикации.
Обеспечение безопасности клиентов нижнего уровня
Степень безопасности всякой системы определяется степенью безопасности ее са-
мого слабого звена. Именно поэтому необходимо постоянно выявлять такие звенья и по-
ышать уровень их защищенности.
того^611646™6 безопасности клиентов нижнего уровня — задача не из легких. Кроме
, она относится к разряду задач, которыми часто пренебрегают при внедрении новой
Но Рационной системы. Хотя настройку защиты Windows 9х и Windows NT вряд ли мож-
с б азвать увлекательной работой, однако глубокое понимание всех проблем, связанных
WindowaCH°CTbI° ЭТИХ си^тем’ поможет лучше подготовиться к настройке доменов
Име^Се Методы и средства, которые используются для защиты клиентов нижнего уровня.
т аналоги в системах Windows 2000/ХР: оснастке Group Policy соответствует редак-
399
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
тор системной политики System Policy Editor, Security Configuration Manager — Security
Configuration and Analysis, SMB-подпись — IPSec. Это не означает, что данные инстру-
менты и методы защиты идентичны — они просто призваны решать сходные проблемы
и нередко позволяют получить примерно одинаковые результаты.
Для обеспечения защиты клиентов нижнего уровня нужно выполнить следующие
действия:
•	установить клиент AD;
•	включить обязательный режим аутентификации NTLMv2;
•	при необходимости включить режим подписи SMB;
•	использовать Security Configuration Manager и System Policy Editor для дополни-
тельной защиты клиентов;
•	тщательно тестировать все новые безопасные конфигурации.
Тематика второй части лабораторной работы посвящена настройкам, позволяющим
в той или иной степени повысить безопасность систем на основе Windows Server 2003.
Рекомендации по сопровождению функционирования Центра сертификации (ЦС)
Специалисты компании Microsoft рекомендуют при работе с развернутой инфраст-
руктурой открытых ключей (PKI) на базе Microsoft Windows Server 2003 СА придержи-
ваться следующих правил:
•	Держать корневой ЦС отключенным от сети и хранить его в физически защи-
щенном месте, например в сейфе. В данной лабораторной работе Центр серти-
фикации и контроллер домена находятся на одном компьютере, исходя из удоб-
ства изложения материала. В действительности же лучше создать Центр сертифи-
кации независимо от контроллера домена.
•	Не создавать в больших организациях, интенсивно использующих структуру PKI
и соответствующие приложения, более четырех уровней иерархии ЦС. При не-
обходимости лучше расширять иерархию, создавая на соответствующих уровнях
дополнительные, специализирующиеся на определенных типах сертификатов
ЦС, а также оптимизировать распределение ЦС по предприятию.
•	Возобновлять сертификаты ЦС задолго до истечения их срока действия.
•	Обеспечивать регулярное и своевременное обновление публикуемого CRL, чтобы
учесть и потребности в своевременном извещении об отозванных сертификатах,
и необходимость выполнения репликации изменений. Иными словами, нужно
следить, чтобы CRL не устаревал еще до того, как он будет реплицирован на всех
доменах всеми контроллерами доменов.
•	Защищать резервную копию секретного ключа ЦС и базы данных и хранить их в
надежном месте.
•	Своевременно обновлять программное обеспечение с помощью сервисных паке-
тов и модулей обновления.
•	Заблаговременно отрабатывать и проверять план действий в нештатных ситуациях.
Описание работы
Для изучения практических вопросов по сопровождению функционирования Центра
сертификации и повышению безопасности систем на основе Windows Server 2003 работа
делится на две части:
•	сопровождение функционирования Центра сертификации;
•	повышение безопасности клиентов нижнего уровня.
400
Лабораторная работа № 4
Обслуживание Центра сертификации
и иная часть работы предназначена для ознакомления с практическими советами по
овождению функционирования Центра сертификации. Для выполнения данной
пясти работы необходимо:
4 Научиться проводить архивирование сертификата вместе с закрытым ключом
Выполнить резервное копирование и восстановление состояния системы.
•	Научиться проводить отзыв и удаление сертификата.
•	Провести архивирование и восстановление Центра сертификации
•	Научиться переиздавать сертификат корневого Центра сертификации.
•	Научиться корректно удалять Центр сертификации.
•	Изучить практические рекомендации по работе с центром сертификации.
Проанализировать полученные результаты.
Повышение безопасности клиентов нижнего уровня
Данная часть работы предназначена для ознакомления с практическими советами и
рекомендациями по повышению уровня безопасности клиентов нижнего уровня в сис-
темах, построенных на основе Windows Server 2003. Для выполнения данной части ра-
боты необходимо:
•	Изучить отказ от аутентификации LM, NTLM v.l:
—	провести установку алгоритма аутентификации NTLM v.2 на клиенте;
—	запретить алгоритмы аутентификации LM и NTLM v. I на контроллере домена.
•	Настроить запрет создания и хранения значений хэш-функций LM на контрол-
лере домена.
•	Настроить парольную политику домена.
•	Изучить возможность усиления безопасности на уровне сетевого трафика:
—	выполнить отключение протокола NetBIOS;
—	выполнить включение SMB-подписи.
• Проанализировать полученный результат.
Задание
1. Изучить теоретические вопросы, изложенные в начале данной лабораторной ра-
боты.
2.
3.
4.
5.
6.
7.
8.
9.
Ю.
11.
12.
ровести архивирование сертификата вместе с закрытым ключом.
ыполнить резервное копирование и восстановление состояния системы.
ереиздать сертификат корневого Центра сертификации.
орректно удалить Центр сертификации.
зучить практические рекомендации по работе с центром сертификации.
ыполнить отказ от аутентификации LM, NTLM v.l.
встроить запрет создания и хранения значений хэш-функций LM на контроллере
Домена.
Выполнить отключение протокола NetBIOS.
^ыполнить включение SMB-подписи.
формить отчет по лабораторной работе.
тветить на контрольные вопросы.
401
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Порядок выполнения работы
Сопровождение функционирования Центра сертификации
Архивирование сертификата вместе с закрытым ключом
Для того чтобы заархивировать сертификат вместе с закрытым ключом, следуйте
приведенной ниже инструкции:
Запустите Консоль Сертификатов
В дереве консоли разверните Сертификаты — текущий пользователь Личные -> Сер-
тификаты (Certificates — Current User Personal -> Certificates).
Выберите сертификат и щелкните по нему правой кнопкой мыши, выберите Все задачи
(All tasks)n щелкните Экспорт (Export).
Консоль Действие Вид Избранное Окно Справка
> w ।	s’(g. [§
Сертификаты
На первой странице мастера запроса сертификатов нажмите Далее (Next).
остер экспорта сертификате
Ki
Вас приветствует мастер
экспорта сертификатов
Этот мастер помогает копировать сертификаты,
списки доверия и списки отзыва сертификатов из
хранилища сертификатов на локальный диск.
Сертификат, выданный центром сертификации,
является подтверждением вашей личности и
содержит информацию, необходимую для защиты
данных или /становления защищенных сетевых
подключений. Хранилище сертификатов - это
область системы, предназначенная для хранения
сертификатов.
Для продолжения нажмите кнопку "Далее"
< На ад | Далее > '] [ Отмена ]
На странице Экспортирование закрытого ключа (Export Private Key) выберите опцию
Да. экспортировать закрытый ключ (Yes, export the private key) и нажмите Далее (Next)
402
Лабораторная работа № 4
На странице Формат экспортируемого файла (Export File Format) нажмите Далее (Next)
На странице Пароль (Password) введите пароль и нажмите Далее (Next).
403
ЧАСТЫ11 ЛАБОРАТОРНЫЕ РАБОТЫ
На странице Имя файла экспорта (File to Export) введите имя файла, куда будет по-
мещен сертификат с закрытым ключом, и нажмите Далее (Next).
На странице Завершение работы мастера экспорта сертификатов (Completing the
Certificate Export Wizard) нажмите Готово (Finish).
В случае успешного экспорта сертификата с закрытым ключом появится экран с со
общением Экспорт успешно выполнен (The export was successful). Нажмите OK.
404
Лабораторная работа № 4
Резервное копирование состояния системы
Создание резервной копии
Для того чтобы создать резервную копию состояния системы (System State), необхо-
димо выполнить следующие действия:
Выберите на сервере Пуск -> Программы -> Стандартные Служебные Архивация
данных (Start -> Programs Accessories System Tools Backup).
На первой странице Мастер архивации или восстановления (Backup or Restore Wizard)
нажмите Далее (Next).
На странице Архивация или восстановление (Backup or Restore) выберите опцию Ар-
хивация файлов и параметров (Back up files and settings) и нажмите Далее (Next).
Мастер архивации или восстановлен <
Архивация и восстановление
Вы можете архивировать Файлы и параметры или восстановить их из
архива
*1
ВыберитерДну из следующих возможностей.
Архивация Файлов и параметров
С Восстановление Файлов и параметров
< Назад I Далее > | Отмена
На странице Что следует архивировать (What to Back Up) выберите опцию Предос-
тавить возможность выбора объектов для архивации (Let me choose what to back up) и наж-
мите Next (Далее).
405
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Мастер архивации или восстановлен -«
Выберите объекты которые следует архивировать
Г £сюинфсрмежо на данном ис -пыотере
Полная архивация данных и создание диска автоматического
восстановления системы который может быть использован для
восстановления системы в случае ее аварийного отказа
Р |1редоставить возможность выбора объектов для архиваций
< Назад | Далее > | Отмена
На странице Элементы для архивации (Items to Back Up) установите флажок System
State, предварительно открыв Рабочий Стол Мой Компьютер (Desktop -> Му
Computer). Нажмите Далее (Next).
Мастер архивации или восстановления
Элементы для архивации
Можно архивировать любую совокупность дисков, папок или Файлов
Дважды щелкните на носителе для просмотра содержимого У становиге
Флажки для всех дисков папок или Файлов которые требуется архивироеать
Что следует архивировать:
ЩГ * э * S-абочий стол
Я О 51 Мой компьютер
3- □	Диск 3,5 (А:)
S □	system (С:)
Й □	install (D:)
. Й □ £ NRMEFPPJEN (Е:)
System State
S- □ _ J Мои документы
£-Q \ Сетевое окружение
Имя	| Комментарий
Q «^Active Directory
П Boot Files
Q ^Certificate Server
1 ЙГСОМ> Class Regis...
□ ЙГ Registry
... £sysvol
< Назад I Далее > I Отмена
На странице Имя, тип и расположение архивации (Backup Type, Destination, and
Name) выберите директорию и имя файла, где будет храниться резервная копия состоя-
ния системы (например — c:\backup\SystemState). Нажмите Далее (Next).
406
Лабораторная работа № 4
В „-РТ-/П-Г- u -^.уя
| Файл	*|
Выберите расположение для данного архива
| C:\backupK	3	fi^op [
Введите имя для данноео архива
jSyslemState
< Назад |~ Далее > | Отмена |
На странице Завершение мастера архивации и восстановления (Completing the Backup
or Restore Wizard) нажмите Готово (Finish).
(Cl^°CJie окончания РезеРВН0Г0 копирования в появившемся окне нажмите Закрыть
407
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Восстановление из резервной копии
Для того чтобы восстановить состояние системы из резервной копии необходимо вы-
полнить следующие действия:
Если Центр сертификации установлен на контролере домена, то перезагрузите сервер и
загрузите его в режиме Directory Services Restore Mode (Windows domain controllers only) (для
этого в процессе загрузки нажмите F8, чтобы попасть в меню Windows Advanced Options).
Windows Advanced Options Menu
Please select an option:
Safe Mode
Safe Mode with Net working
Safe Mo de with Co мма n d P г омр•
Enable Boot ogging
Enable UGA Mode
Last Known Good Configuiat ion (pour Most recent settings that woiked)
Directory* Services Restore Mode (Windows dомаin controllers uni
Dehti gg ing Mode
Start Windows НогмаПу
Reboot
Return to OS Choices Menu
Use the up and down arrow keys to номе the highlight to your choice.
Для запуска на сервере программы Архивация данных (Backup) выполните двойной
щелчок мышью на файле, в котором у вас хранится резервная копия System State (на-
пример — c:\backup\SystemState).
На первой странице Мастер архивации и восстановления (Backup or Restore Wizard)
нажмите Далее (Next).
Отмена |
На странице Архивация и восстановление (Backup or Restore) выберите опцию Вос-
становление файлов и параметров (Restore files and settings) и нажмите Next (Далее).
408
Лабораторная работа № 4
Мастер арх -вации или восстановлен*
Архивация м восстановление
Вы можете архивировать файлы и параметры или восстановить их из
архива
Выберите одну из следующих Возможностей:
С дрхиващя Файлов г пар и этрэв
<• ^Восстановление Файлов и параметров
< Назад | Далее» ~| Отмена |
На странице Что следует восстанавливать (What to Restore) установите флажок System
State (File/SystemState.bkf) и нажмите Next (Далее).
[Мастер архивации или восстановлен* 
Что следует восстановить
Можно восстанавливать любую совокупность дисков, папок или Файлов
Раскройте содержимое носителя и установите Флажки для
всех объектов которые вы хотите восстановить.
Обзор..
Что следует восстановить
Я О eJ Файл	Метка одентиФикаиии архива | Расположение н
Й	@ SystemState bkf со® Q Q;SystemState bkf создан . I C:\backup4Syster
ЕЭ.35 System State
<Назад [~Далее» ~|
На странице Завершение мастера архивации и восстановления (Completing the Backup
or Restore Wizard) нажмите Готово (Finish).
409
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Восстановление из резервной копии
Для того чтобы восстановить состояние системы из резервной копии необходимо вы-
полнить следующие действия:
Если Центр сертификации установлен на контролере домена, то перезагрузите сервер и
загрузите его в режиме Directory Services Restore Mode (Windows domain controllers only) (ддя
этого в процессе загрузки нажмите F8, чтобы попасть в меню Windows Advanced Options).
Uindows Advanced Options Menu
Please select an option:
Safe Mode
Safe Mode with HetHarking
Safe Mode with Соммаnd ProMpt
Enable Boot Logging
Enable UGA Mode
Last Кнонп Good Configurat ion (you г Most recent settings that normed)
Debugging Mode
Start UindoMs Nornally
Reboot
Return to OS Choices Menu
Use the up and donn arrow keys to Move the highlight to your choice
Для запуска на сервере программы Архивация данных (Backup) выполните двойной
щелчок мышью на файле, в котором у вас хранится резервная копия System State (на-
пример — c:\backup\SystemState).
На первой странице Мастер архивации и восстановления (Backup or Restore Wizard)
нажмите Далее (Next)
На странице Архивация и восстановление (Backup or Restore) выберите опцию Вос-
становление файлов и параметров (Restore files and settings) и нажмите Next (Далее).
408
Лабораторная работа № 4
Архивация м восстановление
Вы можете архивировать файлы и параметры и/м восстановить их из
архиве
Выберите одну из следующих возможностей:
С Архивация файлов и параметров
(* Восстановление Файлов и параметров
1 Назад | Далее» | Отмена
На странице Что следует восстанавливать (What to Restore) установите флажок System
State (File/SystemState.bkf) и нажмите Next (Далее).
Мастер архивации или восстановлен* »
Что следует восстановить
Можно восстанавливать любую совокупность дисков папок или Файлов
Раскройте содержимое носителя и установите Флажки для
। “ всех объектов которые вы хотите восстановить.
Обзор |
Что следует восстановить	: ----------------»
Я ОвВ Файл	Метка едентификации архиве | Расположением
Й Q Q SystemState bkf соз£ Г" 0:SystemStatebkf создан _  С Abackup\Syster
Q System Stale
-Назад J" Далее» Отмена |
На странице Завершение мастера архивации и восстановления (Completing the Backup
or Restore Wizard) нажмите Готово (Finish).
409
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
В появившемся окне нажмите ОК.
После окончания восстановления данных в окне Ход архивации (Restore Progress)
нажмите Закрыть (Close).
Ход восстановления
Восстановление: действие завершено	| Закрыть |
Для получения сведений щелкните ’'Отчет”	- QT4eT- |
Устройство: (System State
Метка:	|Sy$temState.bkf сотлан 8/21/2006 в 11:44 А
Состояние:	(завершено
Прошло:	Осталось:
Время- |	4 мин 56 сек. |
Обработано:	Ожидалось:
Файлов- |	2 384 |	2384
Байт:	|	440,534,707 |	417,054,555
В появившемся окне нажмите Да (Yes) для перезагрузки VM SRV в обычном режиме.
Отзыв и удаление сертификата
Для того чтобы отозвать сертификат, необходимо выполнить следующие действия:
Запустите консоль Центра сертификации Certification Authority (Пуск -> Программы ->
Администрирование (Start Programs -» Administrative Tools)).
Выберите Центр сертификации, сертификаты которого вы хотите отозвать, и выбе-
рите папку Выданные сертификаты (Issued Certificates).
Щелкните правой кнопкой мыши по сертификату, который вы хотите отозвать, и вы-
берите Все задачи -> Отзыв сертификата(А11 Tasks -> Revoke Certificate).
В окне Отзыв сертификатов (Certificate Revocation) выберите причину отзыва серти
фиката (например — Сертификат заменен (Superseded)) и нажмите Да (Yes).
410
Лабораторная работа № 4
Tjjcj
Вы действительно хотите отозвать выделенные
сертификаты?
Можете также указать причину отзыва.
Отзыв сертификатов
Код причины:
Не определен
Не определен
Компрометация ключа
Компрометация ЦС
И зменениепринадлежности
Нет
Сертификат, заменен..
Прекращение работы
Приостановка действия
Для того чтобы удалить сертификат из списка опубликованных сертификатов для
учетной записи пользователя, необходимо выполнить следующие действия:
Запустите программу Active Directory — пользователи и компьютеры (Active Directory —
users and computers), нажав Пуск -> Программы -> Администрирование (Start -> Programs ->
Administrative Tools). Включите опцию Дополнительные функции (Advanced Features) из
меню Вид (View).
> Active Directory Users and Computers
Консоль Действие Вид Окно Справка
Active Directory - пользе
IЙ Сохраненные запрс
й W"
Й Q Builtin
3 Cj Computers
3- szJ Domain Controlle
S LJ ForeignSecurityP
Й- (□ Users
Добавить или удалить столбцы...
Крупные
Мелкие
Список
• Таблица
писание
efault container for upgr...
Пользователи, группы и компьютеры как контейнеры
efault container for dom...
efault container for secu...
efault container For upgr...
Дополнительные функции
Параметры фильтра...
Настроить...
Включить или отключить дополнительные возможности и объекты

^*1
Пис^^ В диРектоРию Users. Щелкните правой кнопкой мыши по учетной за-
(Ргпгч Пользователя, у которого вы хотите удалить сертификат. Выберите Свойства
V Auperties).
Рите^из^1™ На 3аКЛадку Онублпкованные сертификаты (Published Certificates), выбе-
списка сертификат, который вы хотите удалить, и нажмите Удалить (Remove)
411
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Свойства: Алексей Воронцов
jJjd
J— ^опасность | Среда | Сеансы | Удаленное управление
Профиль । луж*1 терминалов | С0М+ | Exchange General
Е-тай Addresses | C -. harigeFerftjfe* | Exchange advanced
Общие | Адрес | Учетная запись | Профиль] Телефоны] Организация
Опубликованные сертификаты | Член групп | Входяш.ие звонки | Объект
Список сертификатов Х509 учетной записи пользователя
Кому выдан	Ktr в щан . На , ач	| Срок
sMSSESSSEGEEB® Root вход с° смарт картой 21 ое
Просмотр сертификата...
Добавить из хранилища I	Добавить из файла
Удалить	I Копировать в файл
OK I ' Отмена I Применит» I п авна
В появившемся окне нажмите Да (Yes).
Архивация и восстановление Центра сертификации
Для архивации Центра сертификации:
Используя «Проводник», создайте новую директорию C:\Backup_CA, куда будет по-
мещен архив Центра сертификации.
На виртуальной машине VM SRV запустите Центр Сертификации (Certification Authority).
Выделите DS Root и выберите Все задачи -> Архивация ЦС (All Tasks -> Back up СА).
412
Лабораторная работа № 4
в окне приветствия
мастера архивации Центра сертификации нажмите Далее (Next)
Мастер архивации центра сертификации
Мастер архивации центра
сертификации
Этот мастер помогает заархивировать такие важные
данные, как закрытые ключи, сертификаты центров
сертификации (ЦС), параметры настройки журналы
выданных сертификатов, очереди запросов
сертификатов
Для продолжения нажмите кнопку "Далее**
[ Г Далее > j
Отмена |
Установите опции Закрытый ключ и сертификат ЦС (Private key and СА certificate)
и Certificate database and certificate database log (База данных сертификатов и ее журнал),
укажите в поле Архивировать в следующее место (Back up to this location) директорию
C:\Backup_CA.
[Мастер архивации центра сертификации

Элементы для архивации
Можно архивировать отдельные компоненты данных центра сертификации
Выберите элементы, которые следует архивировать;
Р Закрытый ключ и сертификат ЦС
Р База данных сертификатов и ее журнал
Г” В • ь добавочную архивацию
Архивировать в следующее место:
|C:\Backup_CA
Замечание; архивная папка должна быть пустой.
Обзор... 1|
< Назад I Далее > I Отмена
Задайте пароль, который будет использоваться для защиты архива
413
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Мастер архивации центра сертификации
Выберите пароль
Для шифрования и расшифровки сообщений требуются как открытый так
и закрытый ключ Следует указать пароль для закрытого ключа.
Для доступа к Файлу закрытого ключа и сертификата ЦС требуется ввести
пароль.
Пароль:
2d
Подтверждение
Чтобы обеспечить безопасность закрытого ключа, храните пароль в секрете
< Назад Далее > ~| Отмена j
Примечание: Данный пароль очень важен, поскольку в системе не предусмотрено
альтернативного восстановления на случай утери пароля.
Нажмите Готово (Finish).
< Назад
Готово
Отмена
Чтобы воспользоваться созданной архивной копией Центра сертификации выпол-
ните следующие шаги:
На виртуальной машине VM SRV запустите Центр Сертификации (Certification
Authority).
414
Лабораторная работа № 4
Выделите DS Root и выберите Все задачи -> Восстановление ЦС (АП Tasks -> Restore СА)
После появления сообщения об остановке службы сертификации нажмите ОК.
Мастер восстановления центра сертификации
На время выполнения этой операции необходимо остановить службы сертификации.
Хотите остановить службы сертификации сейчас?
В окне приветствия мастера восстановления Центра сертификации нажмите Далее
(Next).
< Назад I; Далее > 1 Отмена
415
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Установите опции Закрытый ключ и сертификат ЦС (Private key and СА certificate) и
Certificate database and certificate database log (База данных сертификатов и ее журнал)
укажите в поле Восстанавливать из следующего места (Restore from this location) дирек-
торию C:\Backup_CA. Затем нажмите Далее (Next).
Мастер восстановления центра сертификации
Восстанавливаемые элементы
Можно восстановить отдельные компоненты архивного Файла,
Выберите элементы которые следует восстановить:
17 Закрытый ключ и сертификат ЦС
Р База данных сертификатов и ее журнал
Восстанавливать из следующего места:
|CABackup_CA	Дбзор...
Замечание: для добавочного восстановления сначала выберите Файл полного
архива и выполните восстановление После этого запускайте мастер снова
указывая последовательно Файлы добавочных архивов
< Назад j Далее >I Отмена |
Введите пароль к архивной копии Центра сертификации и нажмите Далее (Next).
Мастер восстановления центра сертификации
Укажите пароль
Для шифрования и расшифровки сообщений требуются как открытый, так
и закрытый ключ. Следует указать пароль для закрытого ключа.
XJ
Для доступа к Файлу закрытого ключа и сертификата ЦС требуется ввести
пароль.
Пароль:
IхххххххххххххЛ
Чтобы обеспечить безопасность закрытого ключа, храните пароль в секрете
*
< Назад I Далее > I Отмена
Нажмите Готово (Finish).
416
Лабораторная работа № 4
При появлении сообщения с предложением запустить службу сертификации нажми-
те Да (Yes).
Мастер восстановления центра серт фикаци-
Операция восстановления завершена. Хотите запустить службы сертификации?
Если имеются дополнительные файлы добавочной архивации для
восстановления, нажмите кнопку "Нет" и вновь запустите мастер, пока все файлы
не будут восстановлены.
Нет |
Переиздание сертификата корневого Центра сертификации
Если время действия сертификата корневого Центра сертификации заканчивается
и/или вы хотите изменить ключевую пару, вам следует переиздать данный сертификат,
овый сертификат будет иметь серийный номер, отличный от серийного номера преж-
него сертификата. Для того чтобы переиздать сертификат корневого Центра сертифи-
кации, выполните на сервере следующие действия:
В дереве консоли выделите Центр сертификации, щелкните правой кнопкой мыши,
ВЫ ерите Все задачи > Обновить сертификат ЦС (All tasks > Renew СА Certificate).
ели Центр сертификации запущен, потребуется его остановка. В этом случае на эк-
ие появится окно с предложением остановить Центр сертификации. Нажмите Да (Yes).
g
На время выполнения этой операции необходимо остановить службы сертификации.
Хотите остановить службы сертификации сейчас?
..Да”" "1| йет |
Установить  ертификат ЦС
417
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
На экране появится окно Переиздать новый сертификат ЦС (Renew СА Certificate) с
предложением изменить ключевую пару. Выберите Да (Yes), если вы хотите сменить
ключевую пару, в противном случае выберите Нет (No).
Нажмите ОК.
Центр сертификации получит новый сертификат, после чего его необходимо будет
снова запустить.
Примечание: Вместо этой последовательности действий вы можете выполнить
на сервере команду certutil —renewcert [reusekeys], где [reusekeys] — необязательный
ключ, указывающий на то, что вы не хотите менять ключевую пару. Без этого па-
раметра новому сертификату будет соответствовать закрытый ключ, отличный
от закрытого ключа старого сертификата.
Корректное удаление Центра сертификации
Для того чтобы удалить Центр сертификации, выполните на сервере следующую по-
следовательность действий:
Создайте защищенную паролем резервную копию Центра сертификации с помощью
консоли или команды certutil — backup <путь>, где <путь> — путь к папке, в которую
вы хотите сохранить архив.
Отклоните все запросы на получение сертификата Подайте команду на внеочередное
выполнение процедур автоматической выдачи сертификатов (certutil -pulse).
Служба каталогов Active Directory должна растиражировать информацию об откло-
ненных запросах на получение сертификата, а групповые политики — довести эту ин-
формацию до пользователей. Для того чтобы применить политики немедленно, выпол-
ните команду gpupdate /force.
Если Центр сертификации является промежуточным, отзовите его сертификат в
центре сертификации, выдавшем данный сертификат В качестве причины отзыва ука-
жите Прекращение работы (Cease of Operation).
418
Лабораторная работа № 4
Центр сертификации является корневым:
^отзовите все выданные им сертификаты с указанием причины Прекращение рабо-
?rease of Operation);
ты алите сертификат данного Центра сертификации из всех созданных вручную
объектов групповой политики.
° л бликуйте в соответствующем центре сертификации список отзыва сертификатов
Ol*L с помощью консоли, либо с помощью команды certutil — crl.
ВрУудалите системный компонент Certificate Services с помощью мастера компонентов
windows (Windows Components Wizard).
Для того чтобы удалить из Active Directory оставшуюся информацию об удаленном
центре сертификации, выполните команду certutil -dsdel «<имя>«, где <имя> — имя
удаленного Центра сертификации.
У Удалите лишние сертификаты из хранилищ, выполнив следующие команды:
— certutil — delstore са "<имя>";
— certutil — delstore my "<имя>";
— certutil — delstore root "<имя>";
— certutil — delstore trust "<имя>";
— certutil — delstore —enterprise ntauth "<имя>”;
— certutil — delstore -enterprise root "<имя>";
— certutil — delstore -user my "<имя>".
Подайте команду на внеочередное выполнение процедур автоматической выдачи
сертификатов (certutil -pulse).
Перезагрузите сервер.
Отказ от аутентификации LM, NTLM v. 1
В операционных системах Windows Server 2003 и Windows ХР по умолчанию для
аутентификации при регистрации в сети используется протокол Kerberos. Вместе с тем,
предусмотрены также возможности аутентификации по менее надежным протоколам
LAN Manager (LM), NT LAN Manager (NT LM) и NT LM v.2. Эти протоколы в качестве
ключевой основы используют имя и пароль пользователя.
Полностью ограничить множество доступных методов аутентификации одним лишь
протоколом Kerberos нельзя. Одной из причин этого является то обстоятельство, что
Kerberos не поддерживается операционными системами-предшественниками.
Поскольку стойкость используемых криптографических алгоритмов возрастает в ря-
ду LM > NT LM > NT LM v.2, рекомендуется в качестве альтернативного протоколу
Kerberos метода аутентификации использовать только протокол NT LM v.2.
Установка алгоритма аутентификации NTLM v.2 на клиенте
Для того чтобы на клиенте задать алгоритм аутентификации NTLM v.2, необходимо
выполнить следующие действия:
^Откройте на рабочей* станции Пуск -> Панель управления -» Администрирование
art -> Control Panel -> Administrative Tools), запустите программу Локальные политики
езопасности (Local Security Policy).
ереидите в папку Параметры безопасности (Secure Settings) Установите значение
-йраметра Network security: LAN Manager authentication level равным Send NTLMv2
esponse only\refiise LM & NTLM.
419
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Запрет алгоритма аутентификации LM и NTLM v. 1
на контроллере домена
Для того чтобы на контроллере домена запретить использование алгоритмов LM и
NTLM v.l для аутентификации, необходимо выполнить следующие действия:
Откройте на контролере домена Пуск -» Программы -> Администрирование (Start ->
Programs Administrative Tools), выберите программу Политика безопасности контрол-
лера домена (Domain Controller Security Policy).
Перейдите в папку Параметры безопасности -> Локальные политики -> Параметры
безопасности (Security Settings Local Police —> Security Options). Установите значение
параметра Network security: LAN Manager authentication level равным Send NTLMv2
response only\refiise LM & NTLM.
420
Лабораторная работа № 4
Запрет создания и хранения хэшей LM на контроллере домена
того чтобы на контроллере домена запретить создание и хранение хэшей LM, не-
^Jo выполнить следующие действия:
обх°д	контролере домена Пуск > Программы > Администрирование (Start >
Откр > Administrative Tools), выберите программу Политика безопасности контрол-
РГ°£Гдомена (Domain Controller Security Policy).
ЛеРп ейдите в папку Параметры безопасности > Локальные политики > Параметры без-
1 еРсти (Security Settings > Local Police > Security Options). Найдите параметр Network
онасн	store LAM Manager hash value on next password change. Активизируйте
security- 17 J
данный параметр.
Примечание. Установка данной опции не приводит к удалению уже существую-
щих LM хэшей паролей. С этого момента не будет больше вычисляться и храниться
М хэш паролей для новых пользователей или новых паролей для старых пользователей.
Перезагрузите сервер и рабочую станцию, чтобы активизировать внесенные изменения.
Настройка парольной политики домена
в гетерогенной cpeie полный отказ от использования паролей может распростра-
Те Ься ТОЛЬКО на интерактивный вход в систему пользователей, работающих на компью-
xQjni П°Д ^правлением Windows 2000, Windows ХР и Windows Server 2003. Пароль необ-
зап ЯД*1 других ва₽иантов аутентификации и является неотъемлемым атрибутом учетной
Men Пользователя. Поэтому безопасность сетевой инфраструктуры в значительной
е зависит от стойкости паролей.
421
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Для того чтобы на контроллере домена настроить парольную политику домена, не-
обходимо выполнить следующие действия:
Откройте на контролере домена Пуск -> Программы -> Администрирование (Start -> Pro-
grams -> Administrative Tools), выберите программу Политика безопасности контроллера
домена (Domain Controller Security Policy).
Перейдите в папку Политики учетных записей > Политика паролей (Account Polices
Password Policy). Установите параметры в соответствии с рисунком.
Перезагрузите сервер или выполните команду gpupdate /force.
Возможности усиления безопасности
на уровне сетевого трафика
Отключение протокола NetBIOS
Протокол NetBIOS и имена NetBIOS использовались в качестве основных в опе-
рационных системах, предшествовавших Windows 2000. Операционные системы
Windows Server 2003 и Windows ХР поддерживают NetBIOS через TCP/IP для совмес-
тимости с устаревшим программным обеспечением. Если вы не используете програм-
мы, обращающиеся к ресурсам по именам NetBIOS, отключите NetBIOS через
TCP/IP.
Для того чтобы на рабочей машине отключить протокол NetBIOS, необходимо вы-
полнить следующие дейЛъия:
Зарегистрируйтесь на рабочей станции под именем пользователя с правами админи-
стратора.
Перейдите к свойствам Сетевое окружение (Му Network Place).
Выберите адаптер LAN (Local Area Network) и перейдите к его свойствам.
Выберите пункт Internet ProtocoI(TCP/IP) и нажмите Properties (Свойства).
422
Лабораторная работа № 4
_Х- LAN - свойства

Общие | Проверка подлинности | Дополнительно |
Подключение через:
I Я0 VMware Accelerated AMD PCNet Adapter
| Настроить... |
Отмеченные компоненты используются этим подключением:
Е File and Printer Sharing for Microsoft Networks
E VReliable Multicast Protocol
Internet Protocol (TCP;IF|
Свойства
Удалил- |
Установить... |
Описание
Протокол ТCP/IP  стандартный протокол глобальных
сетей, обеспечивающий связь между раз личными
взаимодействующими сетями.
Р П ри подключении вывести значок в области уведомлений
Отмена
В появившемся окне нажмите Дополнительно (Advanced).
423
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Выберите вкладку WINS и в разделе Свойства NetBIOS (NetBIOS Settings) выберите
значение Отключить NetBIOS через TCP/IP (Disable NetBIOS over TCP/IP) и нажмите
ОК. Закройте все окна.
Дополнительные параметры TCP/IP
Использование просмотра LMHOSTS влияет на все подключения,
использующие TCP/IP.
Р Включить просмотр LMHO5T	Импорт LMHOSTS.,.
Параметры NetBIOS
С По умолчанию:
Использовать параметры NetBIOS, полученные с
DHCP-сервера. Если используется статический IP-адрес
или DHCP-сервер не указывает параметры NetBIOS, то
включить NetBIOS через TCP/IP.
Г Включить NetBIOS через TCP/IP
Отключить NetBIOS через ТСР/1Й
OK I Отмена
I___________
Включение SMB-nodnucu
Протокол SMB (Server Message Block) используется для осуществления доступа к
файлам, папкам и устройствам. Для того чтобы злоумышленник не мог обратиться к ре-
сурсам от имени доверенного пользователя или службы рекомендуется использовать
электронные подписи пакетов SMB.
Для того чтобы на контроллере домена включить SMB-подпись, необходимо выпол-
нить следующие действия:
Откройте на контролере домена Пуск -> Программы Администрирование (Start
Programs -> Administrative Tools), выберите программу Политика безопасности контрол-
лера домена (Domain Controller Security Policy).
Перейдите в папку Параметры безопасности -> Локальные политики -> Параметры
безопасности (Security Settings -э- Local Police -> Security Options). Установите параметры
в соответствии с рисунком:
— Microsoft network client: Digitally sign communications (always): Включен (Enabled).
424
Лабораторная работа № 4
— Microsoft network sever: Digitally sign communications (always): Включен (Enabled).
Перезагрузите сервер и рабочую станцию или выполните команду gpupdate /force (на
сервере и на рабочей станции).
Содержание отчета
Отчет оформляется одинына бригаду из одного-двух испд, необходимо
В отчете с титульным листом установленной формы (см. Приложение А)
представить следующие сведения:
1-Наименование и цели работы.	rncTaBV доступных пользователю
2.	Краткую характеристику учебного стенда £ ресурсов функций, вариантов
Функций управления и индикаций, распределению ресурсов, Фу кц
набора преобразований).
16-5680
425
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
3.	Функциональную схему учебного стенда с пояснениями и комментариями.
4.	Описание настроек протокола аутентификации на сервере и на рабочей станции.
5.	Описание действий по архивации и восстановлению Центра сертификации.
6.	Подготовиться для устных ответов по контрольным вопросам.
Контрольные вопросы
1.	Как проводить процедуры резервного копирования и восстановления Центра сер-
тификации?
2.	Как настроить использование протокола аутентификации NT LM v.2?
3.	Как усилить безопасность на уровне сетевого трафика?
4.	Какие есть рекомендации по работе с центром сертификации и РК1-службой?
Лабораторная работа № 4
Приложение А
Титульный лист
(образец)
ГоУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
СОПРОВОЖДЕНИЕ ФУНКЦИОНИРОВАНИЯ
ЦЕНТРА СЕРТИФИКАЦИИ,
ПОВЫШЕНИЕ ЗАЩИЩЕННОСТИ СИСТЕМ
НА ОСНОВЕ WINDOWS SERVER 2003
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
Выполнили:
Студенты гр.________________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
427
Лабораторная работа № 5
ДОСТУП В СУБД ORACLE С АУТЕНТИФИКАЦИЕЙ
ПО ИМЕНИ ПОЛЬЗОВАТЕЛЯ И ПАРОЛЮ
В LDAP-КАТАЛОГЕ
Цель работы
Изучение системы централизованного управления пользователями, ролями, базами
данных и приложениями, построенной на основе LDAP-каталога Oracle Internet
Directory. Применение методик настройки сервера БД Oracle и клиентских рабочих
станций для аутентификации и авторизации пользователей службами LDAP-каталога.
Получение навыков работы с программным обеспечением конфигурации сервера баз
данных Oracle и доступу к СУБД Oracle с помощью аутентификации и авторизации по
имени пользователя и паролю в LDAP-каталоге.
Примечание. Установленное на предоставляемом стенде программное обеспе-
чение является собственностью корпорации Oracle. Данное программное обеспе-
чение может быть свободно загружено с сайта производителя
http://www.oracle.com/technology/software/products/oracle9i/index.html. Перед ис-
пользованием его в составе данного стенда или при самостоятельной установке,
пожалуйста, ознакомьтесь с лицензионным соглашением по адресу
h ftp ://www. oracle, сот/technology/software/pop up - license/stan dard - license, h tm l. Про -
граммное обеспечение для функционирования стенда является собственностью
компании VMWare Inc. Программное обеспечение VMWare может быть загруже-
но для ознакомительных целей с сайта производителя по адресу
http://www.vmware.com/download/ws/eval.html. Правила использования продуктов
VMWare, Inc. изложены в http://www.vmware.com/help/legal.html.
Общие сведения
Информационные системы организаций, построенные на основе СУБД Oracle, как
правило, состоят из значительного количества приложений, которые используют одну
или несколько баз данных (или, иначе говоря, экземпляров баз данных). При большом
числе пользователей приложений встает вопрос об эффективном управлении пользова-
телями, их ролями в информационной системе организации, собственно приложениями
и базами данных. Одновременно появляется необходимость получения доступа к раз-
личным базам данных (а^гтентификация) от имени одной и той же учетной записи. Цент-
рализованное управление аутентификацией и учетными записями пользователей (при-
ложений) в СУБД Oracle обеспечивает специальная служба каталога — Oracle Internet
Directory (O1D).
OID предоставляет возможность использования двух типов аутентификации:
1. Однократный пароль пользователя.
2. Сертификат пользователя (в данной лабораторной работе не рассматривается).
428
Лабораторная работа № 5
Однократный пароль пользователя
возможность аутентификации во многих базах данных с предъявлением един-
Дает имени и пароля пользователя. Данная возможность реализуется в опции
СТВеЬцНГ)Гас1е Advanced Security. Учетные записи пользователей и пароли хранятся в OID
СУБД г помощью криптографических методов и контрольных списков доступа
“АХ” с™.го1 Lists - ACL).
Объекты хранения OID
Ниже перечислены основные типы объектов каталога, относящихся к управлению
аутентификацией:
•	Пользователи масштаба организации (далее, пользователи);
•	Роли пользователей масштаба организации (далее, роли);
•	Домены;
•	Базы данных;
•	Соответствия пользователь—схема;
•	Административные группы.
Пользователи
Определяются, хранятся и управляются службами каталога. Каждый пользователь
уникально идентифицируется в рамках информационной системы организации Поль-
зователи определяются в любом поддереве LDAP-каталога OID. Объекты, описанные
ниже, могут определяться только в поддереве каталога со специальным именем
«CN=OracleContext».
Роли
Пользователям могут назначаться роли, которые определяют набор прав доступа к той
или иной базе данных. Роли также хранятся и управляются в LDAP-каталоге OID Роли мо-
гут содержать так называемые «глобальные роли», каждая из которых определяется в соот-
ветствующей базе данных. Глобальная роль содержит привилегии, которые располагаются
в базе данных, но управляются службой каталога. Таким образом, роль — есть контейнер
Для глобальных ролей. Роль может быть назначена одному или многим пользователям.
Замечание. База данных получает глобальные роли пользователя после его
регистрации (аутентификации и авторизации). Поэтому измене-
ния в наборе глобальных ролей для пользователя вступают в силу
только после следующего события регистрации в базе данных.
Домены
ля Д°Мен пРедставляет собой группу ролей и баз данных. Доменом, например, может яв-
мена Я ПОдразделение организации или небольшая организация в целом. Поддерево до-
составляют ТрИ тица объектов: роли, соответствия схем баз данных и группы ад-
министраторов данного домена.
Базы данных
ДаннРеДСТаВЛЯЮТ собой наб°Р информации об определенном экземпляре сервера базы
мента^О1^6 Данные объекты каталога создаются с помощью программного инстру-
racle Enterprise Security Manager в процессе регистрации базы данных
429
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Соответствие пользователь—схема
Соответствие схемы определяет связь между полным или частичным отличительным
именем (DN — Distinguished Name) пользователя в каталоге и схемой в базе данных. Со-
ответствие может быть задано на уровне базы данных или для всех баз данных домена. Со-
ответствия также создаются и управляются с помощью Oracle Enterprise Security
Manager.
Административные группы
Каталог Oracle (рис. 1) содержит административные группы, относящиеся к безопас-
ности при управлении каталогом. Каждая группа содержит контрольные списки доступа
(ACL), ограничивающие права на саму эту группу. Пользователь, изначально установив-
ший OID, автоматически становится членом всех административных групп (пользова-
тель cn^orcladmiri). В дальнейшем он может быть исключен из какой-либо группы, чтобы
ограничить его права в управлении каким-либо доменом.
Административные группы, создаваемые в OID по умолчанию, перечислены в табл.1.
Таблица 1
Административные группы
Наименование	Описание
OracleDBCreators	Члены данной группы (cn=OracleDBCreators,cn=OracleContext...) могут создавать но- вые базы данных, что подразумевает их регистрацию в каталоге с помощью Oracle Enterprise Security Manager. Они имеют права create и modify к объектам и атрибутам баз данных. Они также мо- гут модифицировать домен по умолчанию. Члены группы OracleContextAdmins могут добавлять пользовате- лей в эту группу с помощью Oracle Enterprise Security Manager. В Oracle Enterprise Security Manager данная группа обозначается как Database Registration Admins.
Oracle ContextAdmins	Члены группы OracleContextAdmins могут модифицировать лю- бую группу. В Oracle Enterprise Security Manager данная группа обозначается как Full Context Management.
OracleDBSecurityAdmins	Члены группы OracleDBSecurityAdmins (cn=OracleDBSecurityAdmins,cn=OracleContext...) имеют все привилегии на поддерево каталога OracleDBSecurity. Они имеют доступ ко всем доменам организации и ответственны за: •Управление группой OracleDBSecurityAdmins •	Создание новых доменов •	Перемещение баз данных между доменами В Oracle Enterprise Security Manager данная группа обозначается как Database Security Management.
Oracle UserSecurityAdmins •	Члены группы OracleUserSecurityAdmins (cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext...) отвечают за безопасность для пользователей Oracle Например, они могут модифицировать пароль пользователя. В Oracle Enterprise Security Manager данная группа обозначается как Directory User Management.
OraclePasswordAccessibleDomains	Членами этой группы являются домены, содержащие базы данных, для которых разрешен однократный пароль пользователя.
430
Лабораторная работа № 5
Рис. 1. Схема каталога OID
Пример схемы каталога приведен на рис. 1.
При установке OID в нем создаются некоторые объекты схемы, относящиеся к управ-
лению базами данных, ролями и пользователями. Суперпользователь (администратор OID)
с отличительным именем «cn=orcladmin» добавляется во все созданные административные
группы. Далее, в схему могут добавляться дополнительные домены, группы и пользователи.
Процесс настройки и дальнейшей аутентификации пользователя
с однократным паролем (рис. 2)
1. Администратор БД настраивает сетевую конфигурацию экземпляра базы данных
Для взаимодействия со службой каталога OID. Это может быть сделано вручную (редак-
тирование файла конфигурации) или с помощью служебной утилиты Net Configuration
sistant. Настройка заключается в указании имени компьютера (IP-адреса), на котором
Функционирует O1D, номеров портов, назначенных OID, а также имени контекста
гас е (корневого элемента каталога). В задачи администратора БД входит также созда-
ние общих схем и глобальных ролей.
2. Пользователь, являющийся членом группы Oracle D В Creators, регистрирует эк-
ctvT Р баЗЫ даныЬ1Х в каталоге OID. Регистрация экземпляра базы данных делает до-
Ня ЫМ получение информации о пользователях, ролях, соответствиях схем и т.д., хра-
*базаИСЯ В Каталоге OID, для данного экземпляра. Процесс регистрации создает объект
Данных» в выбранном контексте Oracle и вносит в каталог необходимую инфор-
ст 5 однозначно определяющую указанный экземпляр. Завершением процесса реги-
Ниал ИИ Является внесение отличительного имени (DN) базы данных в параметры ини-
изации сервера. Взаимодействие сервера базы данных и службы каталога OID про-
431
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Oracle
Enterprise
Security
Manager
Рис. 2. Настройка аутентификации
с помощью однократного пароля
исходит по защищенному протоколу (SSL)
и только после успешной взаимной аутен-
тификации также по SSL-протоколу. Для
осуществления SSL-аутентификации эк-
земпляр сервера БД использует ключевой
контейнер (т.н. wallet), содержащий откры-
тый и закрытый ключи, а также сертификат
базы данных. Аналогичный ключевой кон-
тейнер имеет и служба каталога OID. Для
регистрации используется служебная утили-
та Enterprise Security Manager.
1.	Администратор БД или администратор
безопасности с помощью утилиты Enterprise
Security Manager создает в каталоге OID (ес-
ли это необходимо) домены, роли и пользова-
телей.
2.	Пользователь инициирует соединение
с базой данных, используя имя и пароль.
3.	База данных проводит процесс аутен-
тификации и авторизации пользователя,
включающий следующие шаги:
• поиск отличительного имени (DN) по
предъявленному имени и извлечение
правила проверки предъявленного
пароля;
•	проверка пароля с помощью извлеченного правила и поиск (локально в базе дан-
ных) схемы, явно назначенной данному пользователю;
•	поиск общей схемы в каталоге OID, если локально схему найти не удалось;
•	извлечение ролей пользователя и соответственное назначение глобальных ролей
для установленной сессии пользователя.
Методические указания
Подготовка стенда
Минимальные аппаратные требования к хост-машине
Процессор PIV-1400 и выше, 1024М RAM — и более, 12 Gb дискового пространства.
OS Windows 2000/ХР, клиентское ПО VMWare (6.0.0 и выше).
Установка виртуальной машины (рис. 3)
1.	Распаковатьшархив с образом виртуальной машины на жесткий диск хост-машины
(например, в каталог D:\VM\SERVER). Архив с образом виртуальной машины находят-
ся на демонстрационном диске в каталоге \VM\SERVER.
2	Архив содержит файлы:
EDU-Oracle-Server-DataDisk-fOOLvmdk
EDU-Oracle-Server-DataDisk-f002.vmdk
ED U - Oracle- Server- DataDisk-f003. vmdk
432
Лабораторная работа № 5
Рис. 3. Виртуальная машина стенда
EDU-Oracle-Server-DataDisk.vmdk
EDU-Oracle-Server.flp
W2003S-EE-Oracle-EDU.vmdk
3.	Для размещения файлов конфигурации виртуальной машины создать каталог
D:\VM\SERVER\CFG.	.	.
4.	Запустить клиент VMWare. Из меню консоли VMWare выбрать File —> New... —>	а
Machine
5.	В открывшемся окне мастера выбрать «Next»
6.	В открывшемся окне «Select the Appropriate Configuration» выбрать «Custom», далее —
«Next»
7.	В открывшими окне «Select a Virtual Machine Format» выбрать «New — Workstation 6»,
далее - «Next»
8-	В открывшемся окне «Select a Guest Operating System» выбрать «Microsoft Windows»
в панели «Guest Operating System», а в списке выбора «Version» — «Windows 2003 Server
Enterprise Edition», далее — «Next»
9.	В открывшемся окне «Name the Virtual Machine» ввести имя (например,
«EDU-Oracle
-Server») в поле ввода «Virtual Machine Name», а в поле ввода «Location»
имя каталога конфигурации (в нашем случае - «D:\VM\SERVER\CFG»), далее - «Next»
433
ЧАСТЫП ЛАБОРАТОРНЫЕ РАБОТЫ
10.	В открывшемся окне выбрать нужное число виртуальных процессоров (рекомен-
дуется 1, по умолчанию), далее — «Next»
11.	В открывшемся окне «Memory for the Virtual Machine» в поле ввода «Memory for
the Virtual Machine» ввести размер оперативной памяти не менее 512М, далее — «Next»
12.	В открывшемся окне «Network Туре» выбрать «Use Host-only networking’, далее —
«Next»
13.	В открывшемся окне «Select I/O Adapter Types» выбрать «BusLogic», далее —
«Next»
14.	В открывшемся окне «Select a Disk» выбрать «Use an existing Virtual Disk», далее —
«Next»
15.	В открывшемся окне «Select an existing Disk’ ввести полный путь к образу диска
сервера («D:\VM\SERVER\W2003S-EE-Oracle-EDU.vmdk»), далее — «Finish».
Консоль VMWare отобразит созданную виртуальную машину.
16.	Из левой верхней панели консоли «Commands» выбрать «Edit virtual machine
settings». В открывшемся окне «Virtual machine settings» на вкладке «Hardware» нажать
«Add...»
17.	В открывшемся окне «Add hardware wizard» в списке оборудования («Hardware
types») выбрать «Hard disk» и нажать «Next»
18.	В открывшемся окне «Select a Disk» выбрать «Use an existing Virtual Disk», далее —
«Next»
19.	В открывшемся окне «Select an existing Disk» ввести полный путь к образу допол-
нительного диска сервера («D:\VM\SERVER\ EDU-Oracle-Server-DataDisk.vmdk»), да-
лее — «Finish».
Описание стенда (табл. 2—6)
Таблица 2
Установленное ПО
Параметр	Описание
«Гостевая» операционная система	• Windows 2003 Server Enterprise Edition SP1
ПО Oracle	•	Oracle Database Server 9i (9.2.0.8) Enterprise Edition •	Oracle Internet Directory (9.2.0.8)
Таблица 2.1
Службы, запускаемые на стенде
Служба	Описание
OracleServiceORCL	Экземпляр базы данных. Запускается от имени учетной записи пользователя ОС «oracle» при старте системы.
OracleOraHome92TNSListener	Сетевая служба экземпляра БД. Запускается от имени учетной записи пользователя ОС «oracle» при старте системы.
OracleDirectoryService_ORCL	Служба каталога Oracle Internet Directory (OID). Запускается от имени учетной записи пользователя ОС «oracle» вручную.
434
Лабораторная работа № 5
Учетные записи и пароли пользователей
Таблица 3
	’ Пользователь	Пароль	Описание
Administrator^			Welcome 1	Администратор ОС.
Oracle	Welcome 1	Пользователь ОС, администратор БД Oracle, входит в группы «Administrators» и «ORA_DBA».
Sys		Welcome 1	Пользователь БД, администратор Oracle.
				 System		Welcome 1	Пользователь БД, суперпользователь Oracle.
orcladmin (cn=orcladmin)	welcome	Пользователь OID, администратор OID
Таблица 4
Параметры сервера БД и службы каталога OID
Параметр	Значение	Описание
ORACLE_HOME	E:\Ora92	Директория установки сервера Oracle.
ORACLESID/SERVICE	ORCL	Имя экземпляра БД/Имя службы
HOSTNAME	EDU	Имя машины, где установлен экземпляр БД Oracle
Oracle port	1521	Порт для обслуживания обычных соединений
Oracle SSL port	2484	Порт для обслуживания SSL-соединений
OID host	EDU	Имя машины, где установлена служба OID
OID port	4054	Порт OID для обслуживания обычных соединений
OID SSL port	4057	Порт OID для обслуживания SSL соединений
Сетевые алиасы (описатели соединений в ORACLE_HOME\network\admin\tnsnames.ora)		
—	ORCL	Для соединения с БД по обычному протоколу
-—			ORCLSSL	Для соединения с БД по SSL-протоколу
Таблица 5
Другие параметры стенда
Параметр	Описание
Ключевые контейнеры (wallets)	Используются для установления защищенного соединения и взаимной аутен- тификации между экземпляром БД и службой каталога OID Размещаются в ката- логах «E:\Wallets\DB», «E:\WaIIets\OID» для базы данных и O1D соответственно. Пароль к ключевым контейнерам «Welcomel» — для обоих контейнеров
435
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Таблица 6
Сетевые настройки операционной системы стенда
Параметр	Значение
IP адрес/маска подсети	192.168.12.1/255.255.255.0
Имя компьютера/имя рабочей группы	EDU/EDUCATION
Задание
Настроить доступ для пользователей «user», «user2» для работы с экземпляром базы
данных Oracle «ORCL» в одной общей схеме «SHAREDSCHEMA». При успешной уста-
новке сеанса пользователи должны получить роль «GLOBALROLE», назначаемую служ-
бой каталога O1D. Для учетных записей пользователей в каталоге использовать контекст
Oracle, созданный по умолчанию («edu»\ Использовать домен по умолчанию
(«Oracle Default Domain»). База поиска пользователей также задается по умолчанию
(«cn=users, dc=edu, dc=com») (рис. 4).
Здесь:
1	— контекст Oracle;
2	— домен для регистрации базы данных и ролей’,
3	— зарегистрированный экземпляр базы данных;
4	— соответствие роли и глобальной роли базы данных;
5	— соответствие пользователей и общей схемы базы данных;
6	— база поиска пользователей.
^4gBedu
Oracle Contexts
йь^-edu —---------
6-0 Databases
ШEnterprise Domains
OracleDefaultDomain
Enterprise Roles
EnterpriseUserRole
sers
k# userl-—-----------
user2 -----------“
6KJ Users, by Search Base
users — p/gj
^-4 Root Context
Служба каталога OID
Экземпляр БД (ORCL)
Рис. 4. Схема объектов каталога и базы данных
436
Лабораторная работа № 5
Подготовка к работе
Создание точки отката
Эта процедура необязательная, но рекомендуется ее выполнить для возможности
ведения виртуальной машины в исходное состояние.
ПрИ. Выбрать меню окна консоли VMWare (рис. 3) «VM Snapshot ->Take Snapshot...».
В открывшемся окне мастера «Take Snapshot» задать имя точки отката и опци-
ональное описание, нажать «ОК».
Запуск виртуальной машины
и подготовка к работе сервера базы данных Oracle
•	В окне консоли VMWare ( см. рис. 3) в панели «Commands» выбрать «Start this vir-
tual machine».
•	После завершения загрузки операционной системы Windows 2003 Server нажать
комбинацию клавиш Ctrl + Alt + 1ns и зарегистрироваться в системе как пользо-
ватель «oracle» с паролем «Welcome 1».
•	Подождать, пока стартует экземпляр Oracle.
•	С рабочего стола из папки «bats» запустить «start_oid.bat» для старта службы Oracle
Internet Directory (OID).
•	Подождать, пока служба OID перейдет в состояние «Started».
Порядок выполнения работы
Сетевые настройки
На данном этапе производится настройка сетевых служб экземпляра базы данных для
получения возможности связи со службой каталога OID. Данная процедура выполняется
с помощью служебной утилиты Net Configuration Assistant.
1.	Запустить Net Configuration Assistant. Start -> All Programs... -> Oracle-OraHome92 ->
Configuration and Migration Tools -> Net Configuration Assistant. В открывшемся окне мас-
тера выбрать «Directory Usage Configuration», далее — кнопка «Следующий» (рис. 5).
2.	В открывшемся окне мастера выбрать «Select the directory server you want to use. The
irectory server must be already configured for Oracle usage» («Выберите сервер каталога,
который вы хотите использовать. Сервер каталога должен быть настроен на использо-
вание сервером Oracle» ), далее — кнопка «Следующий» (рис. 6).
3.	В открывшемся окне выбрать тип каталога — «Oracle Internet Directory».), далее —
кнопка «Следующий» (рис. 7).
4.	В открывшемся окне в поле ввода «Но81паше»задать имя сервера, где установлена
^лужба OID, в полях ввбда «Port» и «SSL Port» — номера портов службы OID для обыч-
? $$^-соединений соответственно. Вводимые значения должны соответствовать на-
Ройкам ( см. табл. 4), далее — кнопка «Следующий» (рис. 8).
Лсп=о В открывшемся окне в списке выбора контекста выбрать контекст
яв Urac*eC°ntext, dc=edu,dc=com». Не следует выбирать «cn=OracleContext», который
Man еТСЯ Корневым контекстом Oracle и предназначен для хранения служебной инфор-
Ии- Далее — кнопка «Следующий» (рис. 9).
437
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 5. Окно мастера Net Configuration Assistant. Выбор действия
Рис. 6. Окно мастера Net Configuration Assistant. Выбор варианта настройки
438
Лабораторная работа № 5
Configuration Assistant: Directory Usage Configuration, Direct u»ry Typ
Oracle e	———
X]
Отмена
Cn... \	Назад
What type of directory do you have?
DirectoiyTyp^ Oracle Internet Directory
Следующий j
Рис. 7. Окно мастера Net Configuration Assistant. Выбор типа каталога
| Oracle Net Configuration Assistant: Directory Usage Configuration, Direct < у tjw afyoft
2S1
Where is your directory service located?
Hostname- (edu|
Port:	[4054
SSL Port: [4057
Отмена । Cn.. I	Назад
Следующий S> J
Рис. 8. Окно мастера Net Configuration Assistant. Сетевая конфшурация
439
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 9. Окно мастера Net Configuration Assistant. Выбор контекста.
Рис. 10. Окно мастера Net Configuration Assistant. Завершение настройки
440
Лабораторная работа № 5
& В открывшемся окне мастера убедиться, что контекст выбран верно, далее — кнопка
г недуюпхий» (рис. Ю).
оТКрЫВШемся окне мастера нажать кнопку «Готово». Работа Net Configuration
a cistant будет завершена.
^7 Следует проверить содержимое файла конфигурации OID ORACLE_HOME\
ork\^DMlN\ldap.ora. Для рассмотренного варианта настройки его содержимое дол-
”12Гбыть следующим:
*#LDAP-ORA Network Configuration File: E:\ora92\network\admin\ldap.ora
^Generated by Oracle configuration tools.
DEFAULT ADMINCONTEXT = «dc=edu,dc=com»
DIRECTORY_SERVERS= (EDU:4054:4057)
directory_server_type = OID
Указанные настройки могут быть произведены непосредственно перед редактирова-
нием файла конфигурации ORACLEHOME\network\ADMIN\ldap.ora.
Создание общих схем
и глобальных ролей
Данный этап предполагает создание общей схемы, в которой будут работать пользо-
ватели, успешно прошедшие аутентификацию и авторизацию в OID. Общая схема может
быть получена двумя путями:
•	создана;
•	преобразована из обычной схемы.
Оба способа реализуются с помощью SQL-команд CREATE USER или ALTER USER
соответственно. Необходимо также создать одну или несколько глобальных ролей, кото-
рые будут использоваться для установки соответствия ролей базы данных и ролей ката-
лога OID. Глобальные роли создаются с помощью SQL команды CREATE ROLE. Все ко-
манды должны выполняться от имени пользователя, имеющего требуемые привилегии.
* Oracle SQL*Plus
Файл Правка. Поиск Параметры Справка
SQL*Plus: Release 9.2.0.8.0 - Production on Втн Map 18 17:30:18 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Присоединен к:
0racle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the OLAP and Oracle Data Mining options
JSeruer Release 9.2.0.8.0 - Production
SQL> |
Рис. 11. Окно SQL-консоли. Соединение с БД от имени SYS
441
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ

Файл Правка. Поиск Параметры Справка
SQL*Plus: Release 9.2.0.8.0 - Production on Втн Map 18 17:30:18 2008
Copyright (с) 1982, 2002, Oracle Corporation. All rights reserved.
Присоединен к:
0racle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the OLAP and Oracle Data Mining options
□Server Release 9.2.0.8.0 - Production
SQL> create user sharedscheroa identified globally as '*;
Пользователь создан.
SQL> |
Рис. 12. Окно SQL-консоли. Создание общей схемы
•=O*J
Файл Правка. Поиск Параметры Справка
With the OLAP and Oracle Data Mining options
□Server Release 9.2.0.8.0 - Production
SQL> create user sharedscheroa identified globally as ’*;
Пользователь создан.
SQL> grant CONNECT,RESOURCE to sharedscheroa;
Привилегии предоставлены.
SQL> |
Jjj
Рис. 13. Окно SQL-консоли. Назначение ролей общей схеме
442
Лабораторная работа № 5
rnracleSQl/r-m*
-=1012<1
пеза-а. Поиск Параметры Справка
Пользователь создан.
SQL> grant CONNECT,RESOURCE to sharedschema;
Привилегии предоставлены.
SQL> create role globalrole identified globally;
роль создана.
SQL> |
Рис. 14. Окно SQL-консоли. Создание глобальной роли
1.	Запустить SQL-консоль. Start -» Run... , в поле «Open» указать sqlplusw «/as sysdba».
Откроется окно SQL-консоли, соединенное с экземпляром базы данных от имени поль-
зователя «SYS» (рис. 11).
2.	Для создания новой общей схемы выполнить SQL-команду:
CREATE USER <имя схемы> IDENTIFIED GLOBALLY AS"p
Для преобразования имеющейся схемы в общую выполнить SQL-команду:
ALTER USER <имя-обычной-схемы> IDENTIFIED GLOBALLY AS "p **>
Например, для создания новой общей схемы с именем «SHAREDSCHEMA» следует
выполнить:
SQL>create user sharedschema identified globally as ‘ ’ (рис. 12).
3.	Назначение ролей «CONNECT» и «RESOURCE» в созданной общей схеме для воз-
можности работы (соединение со схемой, создание в ней объектов и т.д.) производится
С помощью SQL-команды GRANT В рассматриваемом примере:
QL> grant CONNECT, RESOURCE to sharedschema (рис. 13).
n ~ Создание глобальной роли БД производится с помощью SQL-команды CREATE
Е <имя~роли> IDENTIFIED GLOBALLY. В рассматриваемом примере создать роль
именем «GLOBALROLE». *
SQL> create role globalrole identified globally (рис. 14).
*\ .1 _
*L ДВе одинарные кавычки
Утерян еДУеТ Иметь в виду’ что при преобразовании существующий пароль обычной схемы будет
443
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 15. Enterprise Security Manager. Окно регистрации
Рис. 16. Окно консоли Enterprise Security Manager. Объекты схемы
444
Лабораторная работа № 5
Регистрация базы данных
регистрации используется служебная утилита Enterprise Security Manager. В дан-
^имере следует зарегистрировать экземпляр базы данных с именем «ORCL» в до-
н°м ™gracieDefauitDoniain» (домен, создаваемый по умолчанию) в контексте Oracle
^H^edUfdc-com».
Запустить Enterprise Security Manager. Start -> All Programs... -> Oracle-OraHome92 ->
rated Management Tools -> Enterprise Security Manager В открывшемся окне регист-
Inte^n выбрать «Password Authentication», ввести требуемые поля (см. табл. 3 и 4) и на-
жать кнопку «ОК» (рис. 15).
Обший вид консоли Enterprise Security Manager приведен на рис. 16.
д — Дерево объектов контекстов Oracle.
В — Панель свойств выделенного объекта дерева.
С — Меню.
1	— Хост-машина, на которой установлен каталог 01D.
2	— Контекст Oracle «edu» (создан при установке OID).
3	— Домен «OracleDefaultDomain» (пока не содержит ролей).
4	— База поиска пользователей (пользователи должны располагаться ниже в данном под-
дереве). При создании пользователей в других поддеревьях, отличительные имена
этих поддеревьев должны быть перечислены в данном списке.
5	— Закладка доступных в данном контексте доменов. Вначале пустая.
6	— Версия контекста. По умолчанию версия совместима с Oracle 8i.
7	— Список пользователей, входящих во все базы поиска (4).
2.	Добавить домен, в котором будет зарегистрирована база данных
(«OracleDefaultDomain»), в список доступных доменов контекста «dc=edu,dc=com». Для
этого выбрать закладку «Accessible Domains» в панели свойств контекста «edu» (п. 5 рис. 15).
Рис. 17. Окно консоли Enterprise Security Manager. Список доступных доменов
445
ЧАСТЫ11. ЛАБОРАТОРНЫЕ РАБОТЫ
X]
; Register Database
( OK Cancel Help
Рис. 18. Окно консоли Enterprise Security Manager. Диалог регистрации базы данных
Далее — кнопка «Add». В открывшемся окне со списком имеющихся доменов выбрать
«OracleDefaultDomain» и нажать «ОК». В списке доступных доменов должен присутст-
вовать «OracleDefaultDomain», далее — кнопка «Apply» (рис. 17). Нажатие кнопки
«Apply» — обязательно.
3.	Выбрать в меню (п. С на рис. 16) «Operations» -> «Register Database...». В открывшемся
окне заполнить требуемые значения в соответствии с табл. 4*\ В качестве значения кон-
Register Database...
Your database registration is notyet complete To participate
in Enterprise User Security the database requires the
rdbrns__sen/er_dn parameter to be set The Database
Administrator must perform the following SQL operation and
restart the database.
Рис. 19. Окно консоли Enterprise Security Manager. Сообщение о регистрации базы данных
446
Лабораторная работа № 5
а («Oracle Context») выбрать «edu», опционально можно отметить пункт выбора «Store
^M^Connect String» (сохранить строку связи в каталоге), далее — кнопка «ОК» (рис. 18).
™ случае успешной регистрации базы данных в каталоге Enterprise Security Manager
б азит сообщение о завершающем этапе регистрации (см. п. 3.4). Нажать кнопку
°ОК*> (рис. 19)- При этом значение Л-451 «Oracle SID» вводится строго в верхнем регистре.
* 4 Для завершения регистрации следует установить параметр инициализации
gpBMS SERVER_DN» (отличительное имя базы данных в каталоге OID) для экземп-
ляра базы данных «ORCL».
Внимание! В связи с тем, что служба каталога OID использует изменяемую ба-
зу данных (текущая конфигурация), перед дальнейшими операциями
следует остановить сервер OID. Для этого выполнить командный
файл «C:\Documents and Settings\oracle\Desklop\ bats\ptop_oid.bat».
Далее:
•	Запустить SQL-консоль, аналогично п. 2.1.
•	Выполнить последовательно S QL-команды:
о alter system set RDBMS_SERVER_DN=«cn=ORCL,cn=OracleContext, dc=edu,dc=com»
scope=spfile;
о shutdown immediate;
о startup.
Первая из указанных SQL-команда отображается в сообщении Enterprise Security
Manager (рис. 18 п. 1). Значение параметра RDBMSSERVERDN регистрозависимо и
должно в точности соответствовать указанному в сообщении. Следует обратить внима-
ние на синтаксис команды: при ее выполнении нужно применять одиночные кавычки
для значения параметра, а не двойные, как указано в сообщении.
Чтобы убедиться в правильности установки, выполнить команду «show parameter
rdbms server dn» (рис. 20).
5.	Запустить сервер OID с помощью выполнения командного файла «C:\Documents
and Settings\oracle\Desktop\bats\stop_oid.bat».
t Oracle SQL*Plus
jojxj
Файл Правка Поиск Параметры Справка
SQL> alter system set RDBMS SERUER DM-	\
2 *сп-orcl,cn=oraciecontext,dc=edu,dc=com‘ / установка параметра
3 scope=spfile;	.z
Система изменена.
SQL> shutdown inmediate ---------останов экземпляра ORCL
База данных закрыта.
База данных размонтирована.
Экземпляр ORACLE завершен.
sql> startup---------------------запуск экземпляра ORCL
Экземпляр ORACLE запушен.
Total System Global Area 378609496	bytes
Fixed size	454488	bytes
triable Size	343932928	bytes
Database Buffers	33554432	bytes
Redo Buffers	667648	bytes
База данных смонтирована.
База данных открыта.	КОНтрОЛЬ установки
SQL> show parameter r5bms_seruer_dn -***' Параметра
NfiME	TYPE	UALUE
Ldbms_seruer_dn	string	cn=0RCL,cn=OracleContext,dc=ed
u.dc-com
SQL> |
Рис. 20. Окно SQL-консоли. Завершение регистрации базы данных
447
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 21. Окно Enterprise Security Manager. Проверка регистрации базы данных
6.	Проверка регистрации базы данных в каталоге:
6.1.	Запустить утилиту Enterprise Security Manager. Зарегистрированный экземпляр
базы данных должен отображаться в свойствах домена «OracleDefaultDomain» (закладка
«Databases»), при этом его отличительное имя (п. 2 рис. 20) должно в точности совпадать
с параметром инициализации «RDBMSSERVERDN» (см.п.3.4).
6.2.	Следует убедиться (и в случае необходимости изменить), что значение списка
выбора «User Authentication» (п. 1 рис. 21) установлено в «Oracle Wallet (SSL) and Pas-
sword» (разрешен вход пользователей по предъявлению имени и однократного пароля).
7.	Следует повторно проверить содержимое файла конфигурации OID ORACLE-
HOME\network\ADMIN\ldap,ora (аналогично п. 1.8).
Создание ролей и установление соответствия с глобальными ролями
На данном шаге в каталоге создаются роли и каждой из них ставится в соответствие
ранее созданные глобальные роли базы данных (см. п. 2). Пользователи, которым будет
назначена созданная роль, после аутентификации и авторизации в каталоге O1D, получат
набор привилегий, определяемых соответствующей глобальной ролью (в данном при-
мере это привилегии CONNECT и RESOURCE (см. п. 2)).
1. В окне консоли Enterprise Security Manager выбрать пункт меню «Operations» ->
«Create Enterprise Role...» (п. С рис. 15). В открывшемся окне выбрать контекст «edu»,
домен «OracleDefaultDomain» и ввести имя роли, например «EnterpriseUserRole». Далее —
кнопка «ОК» (рис. 22).
2. В окне консоли Enterprise Security Manager выбрать созданную роль в дереве объ-
ектов, в панели свойств роли выбрать закладку «Database Global Roles», нажать кнопку
«Add...», В открывшемся окне выбрать «ORCL» (ранее зарегистрированный экземпляр
базы данных). В открывшемся окне ввести значения для регистрации в базе данных.
В качестве пользователя («Username») выбирается SYSTEM (см. табл. 3), далее — кнопка
«ОК» (рис. 23).
448
Лабораторная работа № 5
В открывшемся окне в нижней панели выбрать ранее созданную в п.2 глобальную
роль «GLOBALROLE», далее — кнопка «ОК» (рис. 24).
После закрытия окна выбора ( см. рис. 23) следует нажать кнопку «Apply».
*; Database Authentication Required
xj
Orao i Emtwrise Manager
Copyright ©1998, 2002, Oracle Corporation. All rights reserved.
Рис. 23. Окно Enterprise Security Manager. Регистрация в базе данных.
449
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 24. Окно Enterprise Security Manager. Выбор глобальной роли
Создание пользователей
Пользователи, как было указано выше, могут создаваться в поддеревьях каталога, кото-
рые перечислены в базе поиска пользователей (п. 4 рис. 16). В данном примере будут созданы
два пользователя с именами «userl» и «user2» с базой поиска «cn=Users,dc=edu,dc=com».
Обоим пользователям будет назначена роль «EnterpriseUserRole» и они оба будут работать
с базой «ORCL» в общей схеме «sharedschema».
1. В окне консоли Enterprise Security Manager выбрать пункт меню «Operations» ->
«Create Enterprise User...» (п. С рис. 16). В открывшемся окне выбрать контекст запол-
нить требуемые поля (закладка «User Naming», рис. 25):
• База поиска (Base) — «cn=Users,dc=edu,dc=com».
• Имя (First Name) — «userl».
•	Фамилия (Surname) — «и» (опционально).
•	Идентификатор (User ID) — «userl» (может и не соответствовать имени).
•	Суффикс (User ID Suffix) — пустой по умолчанию (опционально).
•	Email (Email Address) — по умолчанию (опционально).
• Общее имя (Common Name) — «userl».
2. Далее — выбрать закладку «Password». Выбрать пункт «Enter manually» (задать па-
роль вручную), ввести в поле пароля («New Password») и в поле подтверждения («Verify
Password») значение пароля, в данном примере — «Welcomel» (рис. 26).
450
Лабораторная работа № 5
Рис. 25. Окно Enterprise Security Manager. Создание пользователя
3. Далее — выбрать закладку «Enterprise Roles». Выбрать имя контекста «edu» из спи-
ска выбора «Oracle Context» и нажать кнопку «Add...». Из предложенного списка ролей
выбрать «Enterprise UserRole» и нажать кнопку «ОК». Далее — «ОК» (рис. 27).
Дополнительные настройки и соответствия пользователь—общая схема
Установка соответствия пользователь — общая схема возможно как для каждого поль-
зователя индивидуально, так и для группы пользователей, находящихся ниже выбран-
ного поддерева каталога. В настоящем примере соответствие будет назначено для каж-
дого из созданных пользователей индивидуально.
1- Для возможности аутентификации пользователей, входящих в базы поиска, следует:
1 • 1. В консоли Enterprise Security Manager в дереве объектов выделить «users» в под-
дереве «User’s by search base».
1-2. В панели свойств выбрать закладку «Allow Database Access», отметить пункт вы-
°ра «Allows Logon to Authorized Enterprise Domain» и нажать кнопку «Apply» (рис. 28).
• Для установки соответствия следует:
•1. В консоли Enterprise Security Manager в дереве объектов выделить «ORCL» в под-
реве «Databases». В панели свойств выбрать закладку ’Database Schema Mapping' и на-
ать кнопку «Add...».
451
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 26. Окно Enterprise Security Manager. Задание пароля
Рис. 27. Окно Enterprise Security Manager. Задание роли
452
Лабораторная работа № 5
Рис. 28. Окно Enterprise Security Manager. Установка возможности аутентификации
Add Database Schema Mappings
cn=OracleContext
cn=OracleSchemaVersion
^H^dc=com
^4 dc=EDU
cn=Calendar Server
6>^cn=Groups
S>4 cn=OracleContext
y-^-cn=Users
!+>5cn=orcladmin
cn=user1
cn=user2
Directory Entry cn=user1,cn=Users, dc=edu,dc=com
r Subtree Level Entry Level-------2
Schema SHAREDSCHEMA
OK~| Cancel • Help j
Рис. 29. Окно Enterprise Security Manager. Установка соответствия общей схеме
453
ЧАСТЬ III ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 30. Окно Enterprise Security Manager. Соответствие пользователей общей схеме
2.2.	В открывшемся окне в панели дерева объектов (п. 1 рис. 29) выбрать пользователя
«userl» («dc=com» -> «dc=edu» «cn=Users»). Отличительное имя пользователя отобра-
зится в строке ввода «Directory Entry».
2.3.	Переключатель (п. 2 рис. 29) установить в «Entry Level».
2.4.	В строке ввода указать имя ранее созданной общей схемы — «SHAREDSCHEME»
(см. п. 2).
2.5.	Нажать кнопку «ОК» и повторить те же действия для пользователя «user2».
2.6.	Нажать кнопку «Apply» (рис. 30).
Тестирование полученной конфигурации
Тестирование полученной конфигурации сводится к проверке собственно возмож-
ности успешной аутентификации пользователей в базе данных, а также проверка ис-
пользования общей схемы разными пользователями. Проверка производится с помощью
SQL-консоли (утилита Oracle SQL*Plus).
•	Запустить SQL-консоль. Start Run... , в поле «Open» указать «sqlplusw/nolog».
Откроется окно SQL-консоли, не соединенное с экземпляром базы данных.
•	Ввести команду соединения с базой данных от имени пользователя «userl».
•	SQL> connect userl/Welcomel@orcl.
•	Должно отобразиться сообщение об успешной аутентификации/авторизации.
•	Ввести SQL-команду для определения рабочей схемы.
•	SQL> select sys_context(«userenv», «session user») from dual.
•	Должно отобразиться имя общей схемы.
•	Ввести SQL-коман;^ для определения имени пользователя.
•	SQL> select sys_context(«userenv», «extemal_name») from dual.
•	Должно отобразиться отличительное имя пользователя «userl» из каталога OID.
•	Ввести SQL-команду для определения ролей для текущего сеанса.
•	SQL> select role from session_roles.
454
Лабораторная работа № 5
+ Oracle SQL*Plus
файл Правка. Поиск Параметры Спрлвка
<Л1> connect user1/Welcome1@orcl
SUL/ win	__-------- Успешная аутентификация
Соединено. \--- —»
SQL> select sys_context(’userenu*,*session_user') From dual;
SVS CONTEXT!‘USERENU*,‘SESSIONJJSER‘)
SHAREDSCHEMA^------Текущая схема сеанса
SQL> select sys_context(’userenu','external_name') From dual;
SYS—CONTEXT!*USERENU’,'EXTERNAL-NAME1)
cn=user1 ,cn=Users, dc=edu ,dc=com Отличительное имя пользователя
SQL> select * From session_roles;
ROLE <-----
Список ролей
CONNECT Z_____.
RESOURCE
Роли, назначенные общей схеме
GLOBALROLE 4—____
Глобальная роль, назначенная
через службу каталога OID
Рис. 31. Окно SQL-консоли. Сеанс пользователя user!
♦ Oracle SQL*Plus
Файл Правка. Поиск Параметры Справ а
SQL> connect userZ/WelcomelBorcl
Соединено. <	-------- ‘ Успешная аутентификация
SQL> select sys_context('userenu*,‘session—user *) From dual;
SYS—CONTEXT('USERENU*,‘SESSION—USER *)
SHAREDSCHEMA^------Текущая схема сеанса
SQL> select syS-Context(‘userenu*,* external-name*) From dual;
SYS-CONTEXT(* USERENU *,‘EXTERNAL-NAME‘)
cn=user 2 ,cn=Users, dc=edu ,dc=com Отличительное имя пользователя
SQL> select * From session-roles;
ROLE <
Список ролей
jjQlxJ
CONNECT /______________________
RESOURCE
Роли, назначенные общей схеме
GLOBALROLE
ж1
лобальная роль, назначенная
через службу каталога OID
Рис. 32. Окно SQL-консоли. Сеанс пользователя user2
455
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Должен отобразиться список ролей, назначенных текущему сеансу. В списке должна
присутствовать глобальная роль «GLOBALROLE».
Аналогичную проверку следует провести для пользователя «user2». Результат должен
быть точно таким же, за исключением значения для отличительного имени пользователя
(рис. 31 и 32).
Варианты заданий
Вариант 1, Организовать доступ для пользователя «userl» для работы с экземпляром ба-
зы данных Oracle «ORCL» в общей схеме «SHAREDSCHEMA». При успешной установке се-
анса пользователь должен получить роль «GLOBALROLE» и «EDUROLE», назначаемые
службой каталога O1D. Для учетной записи пользователя в каталоге использовать контекст
Oracle, созданный по умолчанию («edu»). Для регистрации базы данных и создания ролей ис-
пользовать домен по умолчанию («OracleDefaultDomain»). База поиска пользователей зада-
ется новым поддеревом, созданным в произвольной точке дерева каталога в контексте «edu».
Вариант 2. Организовать доступ для пользователя «userl» для работы с экземпляром
базы данных Oracle «ORCL» в общей схеме «SHAREDSCHEMA». При успешной уста-
новке сеанса пользователь должен получить роль «GLOBALROLE», назначаемую служ-
бой каталога 01D. Для учетной записи пользователя в каталоге использовать контекст
Oracle, созданный по умолчанию ^edu). Для регистрации базы данных и создания ролей
создать новый домен. База поиска пользователей задается новым поддеревом, созданным
в произвольной точке дерева каталога в контексте «edu».
Отчет представляется с титульным листом установленной формы, приведенной в конце
лабораторной работы № 1.
Контрольные вопросы
1.	Каковы основные компоненты для построения системы аутентификации по одно-
кратному паролю?
2.	Назовите основное назначение службы каталога Oracle Internet Directory (OID).
3.	Какие методы предлагает система для аутентификации пользователей масштаба
предприятия?
4.	Какие объекты каталога отвечают за аутентификацию по однократному паролю?
5.	Что такое роль масштаба предприятия?
6.	Что такое административные группы?
7.	Какую связь описывает соответствие пользователь—схема?
8.	Каким образом может быть задано соответствие пользователь—схема?
9.	Что такое общая схема? В чем ее отличие от обычной схемы?
10.	Что такое глобальная роль базы данных?
11.	В чем состоят этапы процесса аутентификации по однократному паролю?
12.	Для чего необходима процедура регистрации базы данных в каталоге OID?
13.	В какой ветке каталога 01D могут быть зарегистрированы пользователи?
14.	Какой командой SQL создается общая схема?
15.	Какими привилегиями должна обладать общая схема?
16.	Какие операции выполняются с помощью утилиты Oracle Enterprise Security Manager?
17.	В чем отличие в выСЯэре уровня «Subtree» или «Entry» при задании соответствия
пользователь—схема?
18.	В чем преимущество аутентификации по однократному паролю по сравнению с тра-
диционной аутентификацией средствами базы данных?
456
Лабораторная работа № 5
Приложение А
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
ДОСТУП В СУБД ORACLE С АУТЕНТИФИКАЦИЕЙ
ПО ИМЕНИ ПОЛЬЗОВАТЕЛЯ И ПАРОЛЮ
В LDAP-КАТАЛОГЕ
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
П-5680
Выполнили:
Студенты гр. _______________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
457
Лабораторная работа № 6
ДОСТУП В СУБД ORACLE С АУТЕНТИФИКАЦИЕЙ
НА ОСНОВЕ СЕРТИФИКАТОВ
Цель работы
Изучение системы централизованного управления пользователями, ролями, базами
данных и приложениями, построенной на основе LDAP-каталога Oracle Internet
Directory. Применение методик настройки сервера БД Oracle и клиентских рабочих
станций для аутентификации по цифровым сертификатам, установленным в хранилище
файловой системы, а также на смарт-картах или USB-ключах. Получение навыков ра-
боты со служебными утилитами для конфигурации сервера баз данных Oracle для дос-
тупа в СУБД Oracle по протоколу SSL. Получение общих сведений об инфраструктуре
открытых ключей и смарт-карт-технологии.
Примечание. Установленное на предоставляемом стенде программное обеспе-
чение является собственностью корпорации Oracle. Данное программное обеспече-
ние может быть свободно загружено с сайта производителя http ://yvww.oracle.
com/technology/softyvare/products/oracle9i/index.html. Перед использованием его в со-
ставе данного стенда или при самостоятельной установке, пожалуйста, озна-
комьтесь с лицензионным соглашением по адресу http://yvyvyv.oracle.com/technology/
softyvare/popup-license/standard-license.html. Программное обеспечение для функци-
онирования стенда является собственностью компании VMWare, Inc. Программное
обеспечение VMWare может быть загружено для ознакомительных целей с сайта
производителя по адресу http://yvyvyv.vmyvare.com/doyvnload/yvs/eval.html. Правила ис-
пользования продуктов VMWare, Inc. изложены в http://yvyvyv.vmyvare.com/help/
legal.html.
Общие сведения
Информационные системы организаций, построенные с использованием СУБД
Oracle, как правило, состоят из значительного количества приложений, которые исполь-
зуют одну или несколько баз данных (или, иначе говоря, экземпляров баз данных). При
большом числе пользователей приложений встает вопрос об эффективном управлении
пользователями, их ролями в информационной системе организации, собственно при-
ложениями и базами данных. Одновременно появляется необходимость получения до-
ступа к различным базам данных (аутентификация) от имени одной и той же учетной за-
писи. Централизованное управление аутентификацией и учетными записями пользова-
телей (приложений) в СУБД Oracle обеспечивает специальная служба каталога — Oracle
Internet Directory (OID).
OID предоставляет возможность использования двух типов аутентификации:
1. Однократный пароль пользователя (в данной лабораторной работе не рассматри-
вается).
2. Сертификат пользователя.
Аутентификация в базе данных по сертификатам пользователя базируется на исполь-
зовании протокола SSL, который помимо сильной аутентификации обеспечивает защи-
ту канала передачи данных криптографическими методами.
458
Лабораторная работа № 6
Сертификат пользователя
возможность аутентификации во многих базах данных с предъявлением един-
ДаеТ цифрового сертификата пользователя. Данная возможность реализуется в оп-
ствен^	0racje Advanced Security. Учетные записи пользователей и сертификаты фор-
ЦИИ Х 509 хранятся в OID и защищены с помощью контрольных списков доступа
МаТа Control Lists — ACL). Схема работы и общая структура объектов каталога OID
описана в лабораторной работе № 5.
Хранилища ключей и сертификатов пользователя
Механизм взаимной аутентификации по SSL-протоколу между клиентом и сервером
едусматривает использование пары открытый—закрытый ключ. Открытый ключ яв-
ляется составной частью сертификата пользователя и может открыто храниться и пере-
даваться по незащищенным каналам связи. Закрытый ключ содержит очень важную
в плане безопасности информацию, которая должна быть надежно защищена от комп-
рометации. Таким образом, выбор способа хранения ключей напрямую влияет на уро-
вень защищенности информационной системы. Основным хранилищем сертификатов
и ключей пользователя, с которыми может работать ПО Oracle, является ключевой кон-
тейнер (wallet), который физически может существовать как:
•	файл операционной системы;
•	компонент хранилища сертификатов Microsoft.
Использование файла для хранения ключевого контейнера — наиболее простой спо-
соб, но он обеспечивает наименьшую степень защиты ключевой информации. Защита
от несанкционированного использования обеспечивается парольной защитой. При этом
установлены минимальные требования к качеству пароля. В версии СУБД Oracle 10g
возможно хранение сертификата пользователя (открытый ключ) в файле (с парольной
защитой), а закрытого ключа — на смарт-карте, защищенной PIN-кодом. Такой способ
хранения значительно более надежен. ПО клиента Oracle может работать с ключевым
контейнером в виде файла, только если он имеет имя ewallet.sso. Такой файл не требует
пароля, но при этом доступен только для пользователя операционной системы, от имени
которого и был создан данный файл.
Использование хранилища сертификатов Microsoft также предполагает привязку
ключевого контейнера к учетной записи пользователя операционной системы. Физиче-
ски в этом случае ключевая информация хранится в базе реестра ОС Windows и зашиф-
рована на ключе конкретного пользователя. После успешной аутентификации пользо-
вателя на рабочей станции ключевая информация расшифровывается и становися до-
ступной для дальнейшего использования, в том числе и для ПО Oracle.
Оба рассмотренных типа хранилищ имеют существенный недостаток — привязку
летной записи операционной системы. Это прежде всего снижает общую защищен-
ность информационной системы, так как отсутствует дополнительное ограничение до-
ступа «пользователь ОС — пользователь ИС». Существуют и трудности в администри-
чевиТ™ КЛИеНта ^гас^е ~ необходимо поддерживать в актуальном состоянии все клю-
контейнеры на рабочей станции для всех учетных записей, а также предусмотреть
ветствующие каждому пользователю сетевые настройки ПО клиента Oracle.
ном Ка3анные недостатки отсутствуют в хранилище ключевой информации, расположе-
вол П°ЛНОСТЬЮ на аппаратном носителе — смарт-карте или USB-ключе eToken (произ-
’ еЛЬ Akiddin Knowledge Systems). Для использования такого хранилища требуется
олнительное ПО (SecurLogon for Oracle от Aladdin Software Solution R. D.). Сетевые
459
ЧАСТЫП ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 1. Механизм расширения штатных
возможностей Oracle Advanced Security
Oracle
Enterprise
Security
Manager
Рис. 2. Настройка аутентификации
с использованием цифрового сертификата
настройки в данном случае не отличаются
от настроек с использованием хранилища
Microsoft, но в процессе аутентификации
ключи и сертификаты выбираются из фи-
зического хранилища — смарт-карты или
USB-ключа. Такую возможность обеспечи-
вает SecurLogOn for Oracle, расширяющий
возможности штатного механизма поиска
ключей и сертификатов (рис. 1).
Процесс настройки и дальнейшей
аутентификации пользователя
с цифровым сертификатом,
установленным на смарт-карте (рис. 2)
Администратор БД настраивает сетевую
конфигурацию экземпляра базы данных для
взаимодействия со службой каталога OID.
Это может быть сделано вручную (редакти-
рование файла конфигурации) или с по-
мощью служебной утилиты Net
Configuration Assistant. Настройка заключа-
ется в указании имени компьютера (IP-ад-
реса), на котором функционирует OID, но-
меров портов, назначенных OID, а также
имени контекста Oracle (корневого элемен-
та каталога). В задачи администратора БД
входит также создание общих схем и гло-
бальных ролей.
Пользователь, являющийся членом груп-
пы OracIeDBCreators, регистрирует экземп-
ляр базы данных в каталоге OID. Регистра-
ция экземпляра базы данных делает доступ-
ным получение информации о
пользователях, ролях, соответствиях схем
и т.д., хранящейся в каталоге OID, для дан-
ного экземпляра. Процесс регистрации создает объект «база данных» в выбранном кон-
тексте Oracle и вносит в каталог необходимую информацию, однозначно определяющую
указанный экземпляр Завершением процесса регистрации является внесение отличи-
тельного имени (DN) базы данных в параметры инициализации сервера. Взаимодейст-
вие сервера базы данных и службы каталога OID происходит по защищенному прото-
колу (SSL) и только после успешной взаимной аутентификации также по SSL-протоко-
лу. Для осуществления SSL-аутентификации экземпляр сервера БД использует
ключевой контейнер (т.н. wallet), содержащий открытый и закрытый ключи, а также сер-
тификат базы данных. Аналогичный ключевой контейнер имеет и служба каталога OID.
Для регистрации используется служебная утилита Enterprise Security Manager.
Администратор БД или администратор безопасности с помощью утилиты
Enterprise Security Manager создает в каталоге OID (если это необходимо) домены, роли
и пользователей
460
Лабораторная работа № 6
зователь инициирует соединение с базой данных, используя файл, смарт-карту
пчВ-ключ с установленным на них личным ключом и сертификатом.
Г1ЛИБаза данных проводит процесс аутентификации и авторизации пользователя, вклю-
аюший следующие шаги:
4 аутентификацию пользователя по SSL- протоколу;
’ поиск учетной записи по отличительному имени (DN), извлекаемому из поля
*	Subject предъявленного сертификата;
е поиск общей схемы в каталоге O1D;
’ извлечение ролей пользователя и соответственное назначение глобальных ролей
для установленного сеанса пользователя.
Методические указания
Общие рекомендации
Настоящая лабораторная работа выполняется только при успешном выполнении ла-
бораторной работы № 5 (Доступ в СУБД Oracle аутентификацией по имени пользователя
и паролю в LDAP-каталоге). Стенд, подготовленный и настроенный в рамках выполне-
ния лабораторной работы № 5, должен быть запущен в соответствии с инструкциями
раздела «Подготовка к работе».
Подготовка клиентского стенда
для выполнения работы
Минимальные аппаратные требования к хост-машине
•	Процессор P1V-1400 и выше, 1024М RAM — и более, 12 Gb дискового простран-
ства.
•	OS Windows 2000/ХР, клиентское ПО VMWare (6.0.0 и выше).
Установка виртуальной машины
1. Распаковать архив с образом виртуальной машины на жесткий диск хост-машины
(например, в каталог D:\VM\CLIENT). Архив с образом виртуальной машины находятся
на демонстрационном диске в каталоге \VM\CLIENT. Архив содержит файл
winXP_SP2_Oracle 10_client_edu. vmdk.
2. Для размещения файлов конфигурации виртуальной машины создать каталог
D:\VM\CL1ENT\CFG.
v._?’ 3апУстить клиент VMWare. Из меню консоли VMWare выбрать File->New... —>
Virtual Machine.
4. В
5. В
«Next».
открывшемся окне мастера выбрать «Next».
открывшемся окне «Select the Appropriate Configuration» выбрать «Custom», далее —
6. В открывшемся окне «Select a Virtual Machine Format» выбрать «New — Workstation
Далее - «Next». *
B ’ В открывшемся окне «Select a Guest Operating System» выбрать «Microsoft Windows»
Р^Нели «Guest Operating System», а в списке выбора «Version» — «Windows XP
Sessional», далее - «Next».
461
ЧАСТЬ Ш. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 3. Виртуальная машина стенда
8.	В открывшемся окне «Name the Virtual Machine» ввести имя (например,
«EDU-Oracle-CIient») в поле ввода «Virtual Machine Name», а в поле ввода «Location» —
имя каталога конфигурации (в нашем случае — «D:\VM\CLIENT\CFG»), далее — «Next».
9.	В открывшемся окне выбрать нужное число виртуальных процессоров (рекомен-
дуется 1, по умолчанию), далее — «Next».
10.	В открывшемся окне «Memory for the Virtual Machine» в поле ввода «Memory for
the Virtual Machine» ввести размер оперативной памяти не менее 348М, далее — «Next».
11.	В открывшемся окне «Network Туре» выбрать «Use host-only networking», далее —
«Next».
12.	В открывшемся окне «Select I/O Adapter Types» выбрать «BusLogic», далее —
«Next».
13.	В открывшемся окне «Select a Disk» выбрать «Use an existing Virtual Disk», далее —
«Next».
14.	В открывшемся окне «Select an existing Disk» ввести полный путь к образу диска
сервера («D:\VM\CLlENT\winXP_SP2_OraclelO_client_edu.vnidk»), далее — «Finish».
Консоль VMWare отобразит созданную виртуальную машину (рис. 3).
462
Лабораторная работа № 6
Описание стенда (табл. 1—6)
Таблица 1
Установленное ПО
	Параметр	Описание
«Гостевая» операционная система		Windows ХР Professional SP2
_		 ПО Oracle	Oracle Client Runtime 10g (10.2.0.1)
			Таблица 2
Службы, запускаемые на стенде (автоматически)
Служба	Описание
Aladdin SecurLogon for ORACLE	Служба поддержки аутентификации в Oracle по смарт-картам или USB-ключам eToken
eToken Notification Service	Служба оповещений eToken RTE
Таблица 3
Учетные записи и пароли пользователей
Пользователь	Пароль	Описание
Administrator	Welcome 1	Администратор ОС
oracle	Welcome 1	Пользователь ОС
Таблица 4
Параметры сервера БД и службы каталога OID
Параметр	Значение	Описание
ORACLE_HOME	С: \oracle \oralO	Директория установки ПО Oracle
Сетевые алиасы (описатели соединений в ORACLE_HOME\network\admin\tnsnames.ord)		
	EDU	Для соединения с БД по обычному протоколу
	EDULSSL	Для соединения с БД по SSL протоколу
Таблица 5
Другие параметры стенда
Параметр	Описание
Ключевые контейнеры (wallets)	Используются для установления защищенного соединения и взаимной аутен- тификации клиента и базы данных (только для тестов) Размещается в каталоге «C:\oracle\Wallets\orcladmin». Пароль к ключевому контейнеру «Welcomel».
Таблица 6
Сетевые настройки операционной системы стенда
		 Парамещр	Значение
J^ypcc/маска подсети	192.168.12.200/255.255.255.0
	Я К0МПЬ1°тера/имя рабочей группы	EDU-CLIENT/EDUCAT1ON
463
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Задание
Для пользователя «userl», созданного в ходе выполнения лабораторной работы № 5,
заменить тип идентификации учетной записи на цифровой сертификат. Создать клю-
чевой контейнер с помощью утилиты Oracle Wallet Manager, импортировать в него сер-
тификат пользователя и сертификат удостоверяющего центра. Полученный ключевой
контейнер установить на смарт-карту или USB-ключ eToken. Произвести настройку се-
тевых служб Oracle Client на аутентификацию по SSL-протоколу (рис. 4).
Здесь:
1	— контекст Oracle;
2	— домен для регистрации базы данных и ролей',
3	— зарегистрированный экземпляр базы данных;
4	— соответствие роли и глобальной роли базы данных;
5	— соответствие пользователей и общей схемы базы данных;
6	— база поиска пользователей.
Подготовка к работе
Создание точки отката
Эта процедура необязательная, но рекомендуется для возможности приведения вир-
туальной машины в исходное состояние:
1.	Выбрать меню окна консоли VMWare ( см. рис. 3) «VM —> Snapshot -> Take
Snapshot...».
2.	В открывшемся окне мастера «Take Snapshot» задать имя точки отката и опци-
ональное описание, нажать «ОК».
^44. edu
Au Oracle Contexts
A<sedu------------“CO
Databases
l0ORCL ..........................
Enterprise Domains
Afl OracleDefaultDomain
AO Enterprise Roles
АУ EnterpriseUserRole
AO Users
userl--'”-'--------------
ф user? ------------
AOUsers, by Search Base
users-—
A* Root Context
Служба каталога OID
Экземпляр БД (ORCL)
Рис. 4. Схема объектов каталога и базы данных (аналогично лабораторной работе № 5).
464
Лабораторная работа № 6
Запуск виртуальной машины
и сеанса пользователя
। В окне консоли VMWare (рис. 3) в панели «Commands» выбрать «Start this virtual
^2 После завершения загрузки операционной системы Windows ХР Professional нажать
’ „опию клавиш Ctrl + Alt + Ins и зарегистрироваться в системе как пользователь
SSe“ паролем. Welcome!..
Порядок выполнения работы
Настройки сетевых дескрипторов
На данном этапе производится настройка сетевых дескрипторов клиента Oracle для
связи с базой данных. Настраиваются два дескриптора: для обычного и SSL-протоколов
Параметры сетевых служб сервера приведены в табл. 4 лабораторной работы № 1. Про-
цедура настройки выполняется с помощью служебной утилиты Net Configuration
Assistant.
1.	Запустить Net Configuration Assistant. Start -> All Programs... -> Oracle-Gradient 10g
Configuration and Migration Tools -> Net Configuration Assistant. В открывшемся окне мас-
тера выбрать «Local Net Service Name Configuration», далее — кнопка «Следующий» (рис. 5).
2.	В открывшемся окне мастера выбрать «Add» («Добавить» ) из предлагаемых вари-
антов выбора, далее — кнопка «Следующий» (рис. 6).
Oracle Net Configuration Assistant: Welcome
Welcome to the Oracle Net Configuration Assistant.
This tool will take you through the common
configuration steps, listed below.
Choose the configuration you would like to do:
r Listener configuration
r Naming Methods configuration
Name configuration
Directory Usage Configuration
Отмена;	c’n.. J	Назад Следующий
Рис. 5. Окно мастера Net Configuration Assistant. Выбор действия
465
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Oracle Net Configuration Assistant: Net Service Name Contiouratioo
To access an Oracle database, or other service, across the network
you use a net service name. The Oracle Net Configuration Assistant
allows you to work with net service names resolved using local
naming.
Select what you want to do
* Add
r Reconfigure
r Delete
r Re e
r Test
Отмена j Cn j
Назад
Следующий
Рис. 6. Окно мастера Net Configuration Assistant. Выбор добавления сетевого дескриптора
3.	В открывшемся окне задать в поле ввода «Service Name» имя экземпляра базы дан-
ных — « ORCL».), далее — кнопка «Следующий» (рис. 7).
Рис. 7. Окно мастера Net Configuration Assistant. Задание имени экземпляра базы данных
466
Лабораторная работа № 6
Oracle Met Configuration Assistant: Met Service Name Configuration, Select Protocol
To communicate with the database across a network, a network
protocol is used Select the protocol used for the database you
want to access.
TCP
Itcps
IPC
NMP
Отмена
Назад Следующий S
Рис. 8. Окно мастера Net Configuration Assistant. Задание протокола
4.	В открывшемся окне выбрать «ТСР» из списка протоколов. Далее — кнопка «Сле-
дующий» (рис. 8).
5.	В открывшемся окне в поле ввода «Host паше» ввести имя сервера, где установлен сервер
базы данных Oracle — «EDU», из вариантов выбора порта указать «Use the standard port number of
1521» («Использовать стандартный номер порта 1521»). Далее — кнопка «Следующий» (рис. 9).
Oracle Net Configuration Assistant: Net Service Name Configuration, TCP/IP Protoco'
To communicate with the database using the TCP/IP protocol, the
database computer's host name is required Enter the host name
for the computer where the database is located.
Host name:	|EDU[
A TCP/IP port number is also required In most cases the standard
port number should be used
,e Use the standard port number of 1521
r Use another port number |l 521
Отмена
Назад
Следующий
Рис- 9. Окно
мастера Net Configuration Assistant. Задание параметров сервера базы данных
467
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 10. Окно мастера Net Configuration Assistant. Тест соединения
6.	В открывшемся окне мастера выбрать «No, do not test» («Нет, не тестировать»), так
как тестирование соединения с базой данных будет сделано позднее. Далее — кнопка
«Следующий» (рис. 10).
7.	В открывшемся окне мастера в поле ввода «Net service Name» задать имя дескрип-
тора, например, «EDU». Далее, кнопка «Следующий» (рис. 11).
Oracle Net Configuration Assistant: Net Service Name Configuration. Net
Рис. 11. Окно мастера Net Configuration Assistant. Имя дескриптора
Назад I Следующий &
Отмена J Cn...
Enter a name for this net service name.
The Oracle Net Configuration Assistant has
defaulted the net service name to be the same as
the service name you entered earlier.
Net Service Name: |edu
468
Лабораторная работа № 6
Oracle Net Configuration Assistant: Net Service Name Configuration, Another Net Service Na»v^ /
-азад | Следующий > )
Рис. 12. Окно мастера Net Configuration Assistant. Конфигурация следующего дескриптора
Отмена
8.	В открывшемся окне мастера на запрос о конфигурации другого дескриптора вы-
брать «Yes» («Да»). Далее, кнопка «Следующий» (рис. 12).
9.	Повторить шаги 3—7 для создания нового дескриптора для SSL протокола.
9.1.	Имя экземпляра базы данных — аналогично п.1.3.
9.2.	Выбор протокола. Аналогично п.1.4, но выбрать протокол «TCPS» (TCP over SSL).
9.3.	Выбор имени сервера и порта для SSL — аналогично п. 1.5.
9.4.	Пропустить тестирование соединения, аналогично п. 1.6.
9.5.	Аналогично п. 1.7. задать имя дескриптора, например, «EDUSSL».
9.6.	На запрос о конфигурации следующего дескриптора выбрать «NO' («Нет»).
9.7.	В открывшемся окне мастера нажать кнопку «Следующий» и, далее, кнопку «Го-
тово». Работа Net Configuration Assistant будет завершена.
10.	Следует открыть созданный файл конфигурации ORACLE_HOME\network\
ADMIN\tnsnames.ora в текстовом редакторе и внести следующие исправления {выделено
по тексту). Для рассмотренного варианта настройки сервера его содержимое должно
быть следующим:
---начало файла tnsnames.ora--
#	tnsnames.ora Network Configuration File: c:\oracle\oralO\network\admin\tnsnames.ora
#	Generated by Oracle configuration tools.
EDUSSL =
(DESCRIPTION =
(ADDRESSLIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = EDU)(PORT = 2484))
(CONN ECT DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
(SID = ORCL)
(SECURITY=
469
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
(AUTHENTICATION_SERVICE = TCPS)
(SSLSERVERCERT_DN=«cn=ORCL,cn=OracleContext,dc=edu,dc=com»)
)
)
EDU =
(DESCRIPTION =
(ADDRESS_L1ST =
(ADDRESS = (PROTOCOL = TCP)(HOST = EDU)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ORCL)
)
)
--конец файла tnsnames.ora--
Сетевая конфигурация клиента
На данном этапе производится настройка сетевой конфигурации клиента Oracle.
Процедура настройки выполняется с помощью служебной утилиты Net Manager.
1.	Запустить Net Manager. Start All Programs... Oracle-OraClientlOg ->
Configuration and Migration Tools -> Net Manager. В открывшемся окне мастера устано-
вить параметр конфигурации в «Naming» (п. 1 рис. 13), затем выбрать в левой панели
объект «Profile». В правой панели в закладке 'Methods’ с помощью кнопок «<» и «>» ос-
тавить в списке «Selected methods» («Выбранные методы») «TNSNAMES». Данный выбор
будет означать, что поиск параметров соединения с базой данных ПО клиента Oracle
производится только в файле tnsnames.ora, созданном выше (рис. 13).
2.	Установить параметр конфигурации в «Oracle Advanced Security» (п.1 рис. 14), вы-
брать закладку «SSL’. Переключатель типа конфигурации «Configure SSL for» (п.З рис. 14)
Рис. 13. Окно Net Manager, объект «Profile». Настройка «Naming»
470
Лабораторная работа № 6
Рис. 14. Окно Net Manager, объект «Profile». Настройка «Oracle Advanced Security»
установить в «Client». В списке выбора «Credential Configuration» (п. 2 рис. 14) выбрать
«Microsoft Certificate». Установить значение в списках выбора пп.4, 5, 6 в значения, ука-
занные на рис. 14.
3.	В меню Net Manager выбрать File Save Network Configuration. Затем, File -> Exit
Работа мастера будет завершена.
4.	Следует проверить созданный файл конфигурации ORACLE_HOME\network\4DMIN\
sqlnet.ora. Для рассмотренного варианта настройки сервера его содержимое должно быть
следующим:
начало файла sqlnet.ora-
# sqlnet.ora Network Configuration File: c:\oracle\oralO\NETWORK\ADMIN\sqlnet.ora
# Generated by Oracle configuration tools.
SQLNET.AUTHENT1CATION_SERV1CES= (BEQ, TCPS)
SSLVERSION = 3.0
SSL__CLIENT_AUTHENTICATION = TRUE
SSL SERVER DN MATCH = Yes
WALLET_ LOCATION =
(SOURCE =
(METHOD = MCS)
конец файла sqlnet.ora--
471
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Создание ключевого контейнера (wallet) для пользователя «userl» и его установка
на смарт-карту или USB-ключ eToken
Для создания wallet используется служебная утилита Wallet Manager. Данный этап
подразумевает следующие процедуры:
•	генерация ключевой пары (закрытый — открытый ключ);
•	генерация запроса на сертификат для пользователя userl (cn=userl, cn=Users,
dc=edu, dc=com);
•	получение сертификата из удостоверяющего центра;
•	импорт сертификатов пользователя и УЦ в wallet;
•	импорт wallet в физическое хранилище сертификатов и ключей.
1.	Запустить Wallet Manager. Start -> All Programs... Oracle-OraClientlOg -> Integrated
Management Tools -> Wallet Manager. В открывшемся окне выбрать меню Wallet ->
New...., в открывшемся диалоге заполнить поля ввода «Wallet Password» (пароль ключе-
вого контейнера), в данном примере — «Welcome 1» и «Confirm Password» (подтверждение
введенного пароля). Следует обратить внимание на требования по качеству пароля. Па-
роль должен быть длиной не менее 8 символов, содержать как буквы, так и цифры и спе-
циальные символы. В списке «Wallet type» (тип контейнера) следует выбрать «Standard».
Далее, нажать кнопку «ОК» (рис. 15). Будет создан «пустой» контейнер, содержащий
лишь сгенерированную пару открытый/закрытый ключ.
2.	В открывшемся окне диалога с подтверждением создания Wallet и запросом подтверж-
дения на создание запроса на сертификат пользователя следует выбрать «Да» (рис. 16).
Рис. 15. Wallet Manager. Пароль для ключевого контейнера
472
Лабораторная работа № 6
Рис. 16. Wallet Manager. Создание запроса на сертификат пользователя
3	В открывшемся окне диалога в списке «Key Size» (длина открытого ключа (бит))
выбрать 1024 и, не заполняя остальные поля, нажать кнопку «Advanced» (рис. 17.1). В от-
крывшемся окне диалога ввести в поле ввода ’DN’ ввести отличительное имя пользователя
«userl», т.е. его полное имя в каталоге OID (см. рис. 4 и лабораторную работу № 5) —
«сп-userl, cn=users, dc=edu, dc=com». Регистр символов не учитывается. Далее — кнопка
«ОК» (рис. 17.2). В открывшемся окне сообщения о создании запроса на сертификат
пользователя нажать «ОК» (рис. 17.3).
Create Certificate Request
Please enter the following information to create an identity
Common Name:
Organizational Unit:
Organization:
Locality/City:
State/Provmce:
Country:	United States	Key Size: 1024
DN	C=US	Advanced^
OK Cancel I
Рис. 17.1. Wallet Manager. Запрос параметров сертификата пользователя
Рис. 17.2. Wallet Manager. Запрос отличительного имени пользователя
473
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Oracle Wallet Manager
A certificate request has been created
Please submit it to a Certificate Authority You can use
"ЕхроЛ Certificate Request to export it into a file
CSD
Рис. 17.3. Wallet Manager. Сообщение об успешном создании запроса
-1О|х|
©•^Wallet
у Oracle Wallet Manager
e- aeration r -6'
Certificate Request
5
Рис. 18. Wallet Manager. Запрос на сертификат пользователя создан
< Classi Public Primary Certification
“3 Class 2 Public Primary Certification
Class 3 Public Primary Certification
-Пд'Secure Server Certification Autnonty
GTE CyberTrust Root
-Гц GTE CyberTrust Global Root
Entrust.net Secure Server Certification
"ц Entrust net Certification Authority (204
, Entrust.net Secure Server Certification
Requested Identity;
Key Size;
Key Type:
Certificate Request.
CN=user1. CN=users DC=edu. DC=com
1024
RSA
-----BEGIN ЛЕН CERTIFICATE REQUEST-
NIIBiTCB8uIBADBKNRHwEQyTCZIaiZ₽yl.GQBGRYDY29t«RKwEQYKC
DAYDVQQDEwVlc2VyczEQMAwGAlUEAxMFdXNlcjEwgZ8wDQYJKoZIL
APD37uFCFHgzC0CHa6K6i/V5XKc46zRC¥e066L0d++N/K7B8/JQyl
Fc0hz/RQdYVoaQzRwMlU8iqYKydYF2uw3Lfli4YdFINqyvUR3bcyVE
£ElgsIGV3Hbbpda7kN8zAgMBAAGgADANBgkqhkiG9®0BAQQFAAQB£
□nPdp8wbRZU6xV+0oDbgEDi5E¥13y7YbRqEBRy9DA9mrupwakuyUi
tBci3QknIdwfZ01Ug0WX3okuB68Pq76aAep9gnW5Ivd06uHgek81F
-----END NEW CERTIFICATE REQUEST------
3
?
4.	После создания запроса на сертификат окно Wallet Manager будет следующий вид
(рис. 18):
1.	Объект запроса на сертификат пользователя (статус сертификата — «Requested» (за-
прошен)).
2.	Список сертификатов доверенных удостоверяющих центров, добавляемый автомати-
чески.
3.	Имя пользователя, для которого сформирован запрос.
4.	Параметры открытого ключа.
5.	Содержимое запроса на сертификат в ,Ь64-кодировке.
5.	Сертификаты доверенных удостоверяющих центров, которые были добавлены ав-
томатически, следует удалить для уменьшения суммарного размера ключевого контей-
474
Лабораторная работа № 6
Это важно, если в дальнейшем ключевой контейнер предполагается импортиро-
вана аппаратный носитель. Для удаления сертификатов следует воспользоваться кон-
ваТЬтНым меню удаляемого доверенного сертификата, либо из меню «Operations» ->
TpKmove Trusted Certificate» (рис. 19.1 и 19.2). В окне подтверждения на удаление дове-
иного сертификата следует выбрать «Да».
Ре & После удаления всех доверенных сертификатов следует добавить в список серти-
ат истового удостоверяющего центра (УЦ). Файл с сертификатом тестового УЦ —
Q\oracle\wallets\CA-EDU.cer. Импорт сертификата производится из меню Wallet
^Oracle Wallet Manage»
Vyalivt Oterafkns НоГр
&Qwallet
ЙСегШа1е:[Р?ерие81ес1]
Trusted Certificates
Class 1 Public Primary Certificati
Certificate
t—on и.- ГЧ-	Export Trusted Certificate..
-‘•ftClass 2 Public Primary Certificati»
tl Л x. Remove Trusted Certificate.
Class 3 Public Primary Certificati»^
Secure Server Certification Authority
GTE CyberTrust Root
GTE CyberTrust Global Root
Version
Serial Number
Рис. 19.1. Wallet Manager. Удаление доверенного сертификата
j*?1 Oracle Wallet Manager
Wallet Operations не
Export Wallet-
Export User Certificate..
Export Certificate Request.
Remove Certificate Request-
Remove User Certificate.
Remove Trusted Certificate.
Export Trusted Certificate
Export All Trusted Certificates...
у Add Certificate Request.
Й Import User Certificate-
Import Trusted Certificate..
fication Au
fication Auj
tuthority
^rtification
ority(204E|
vilification
Рис. 19.2. Wallet Manager. Удаление доверенного сертификата
475
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Manager («Operations» —> «Import Trusted Certificate...») или из контекстного меню спи-
ска доверенных сертификатов («Import Trusted Certificate...») (рис. 20.1). В открывшемся
окне диалога выбора источника для импорта выбрать «Select a file that contains the
certificate» и нажать «ОК» (рис. 20.2). В открывшемся диалоге выбора файла выбрать
файл с сертификатом и нажать «Открыть». Сертификат с именем «For Education Purpose
only» должен появиться в списке доверенных сертификатов (рис. 20.3).
7. Далее следует сохранить содержимое запроса на сертификат в файле для после-
дующей отправки в тестовый УЦ. Экспорт запроса производится из меню Wallet Manager
(«Operations’ -> «Export Certificate Request...») или из контекстного меню для запроса
(«Export Certificate Request...) (рис. 21.1). В открывшемся диалоге выбора места сохра-
нения, позиционироваться на предварительно созданную директорию (например,
C:\oracle\wallets\userl), выбрать имя файла (например, userl-req.csr) и нажать «Сохра-
нить» (рис. 21.2).
Oracle Wallet Manager
Add Certificate Request
Export Wallet..
’ Import User Certificate...
Import Trusted Certificate...
Remove Certificate Request.
Remove User Certificate...
Remove Trusted Certificate...
Export User Certificate...
Export Certificate Reguest...
Export Trusted Certificate..
Export All Trusted Certificates...
vyallet Operations Це®
Рис. 20.1. Wallet Manager. Импорт доверенного сертификата
^Import Trusted Certificate
Choose one of the following ways to add the certificate into your wallet
r Paste the certificate
Select a file that contains the certificate
Cancel
Рис. 20.2. Wallet Manager. Импорт доверенного сертификата
476
Лабораторная работа № 6
Рис. 20.3. Wallet Manager. Импорт доверенного сертификата
f Oracle Wallet Manager
lOMtei Oeerations titip
Add Certificate Request...
Import User Certificate.
Import Trusted Certificate...
Remove Certificate Request..
Remove User Certificate...
Remove Trusted Certificate..
Export User Certificate..
Export Certificate Request..
Export Trusted Certificate.
Export All Trusted Certificates...
Export Wallet...
Рис. 21.1. Wallet Manager. Сохранение запроса на сертификат
8. Сохранить созданный Wallet с помощью меню «Wallet» «Save as...». В открыв-
шемся окне диалога выбора директории для сохранения позиционироваться, например,
На Директорию C:\oracle\wallets\userl и нажать «ОК» (рис. 22).
Получение сертификата пользователя, подписанного доверенным УЦ
1.	Запустить web-браузер (например, Microsoft Internet Explorer). В адресной строке
, СТИ URL web-страницы тестового УЦ, который развернут на сервере EDU —
P-//edu/certsrv/» (рис. 23). На открывшейся домашней странице тестового УЦ вы-
ссылку «Request a certificate» (запрос сертификата). На открывшейся странице вы-
477
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
брать ссылку «or submit an «advanced certificate request» (послать запрос на сертификат).
На открывшейся странице выбрать ссылку «Submit a certificate request by using
a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using
a base-64-encoded PKCS #7 file» (послать запрос на сертификат в base-64 кодировке
Рис. 21.2. Wallet Manager. Сохранение запроса на сертификат
Рис. 22. Wallet Manager. Сохранение Wallet
478
Лабораторная работа № 6
гМС или PKCS# 10 файл) или послать запрос на обновление сертификата в base-64 коди-
ке (PKCS#7 файл)) На открывшейся странице выбрать ссылку «Browse for file to insert»,
запрос системы безопасности о разрешении выполнения ActiveX-скрипта ответить «Да»,
и поле ввода «Full path пате» ввести полное имя файла с запросом на сертификат (см. п. 3.7)
& бо воспользоваться кнопкой «Обзор...» для поиска файла, далее — кнопка «Read!»
л с 23.1). Поле ввода текста «Saved request» должно заполниться содержимым запроса, да-
кнопка «Submit». На открывшейся странице выбрать пункт «Base 64 encoded» и пе-
йти по ссылке «Download Certificate» (рис. 23.2). В открывшемся окне системы безопас-
ности выбрать «Сохранить». На запрос директории и имени файла указать
*C-\oracle\wailets\userb> и «userl-cer.cer» соответственно. Закрыть окно браузера.
j Microsoft Certificate Services - Microsoft Internet Explorer
Файл Правка Вид Избранное Сервис Справка
Назад •	? |	, Поиск Избранное Z’*	-	, <
Адрес: |	http ://edu/certsrv/certrqxt. asp	“Я Q Переход LirMcs ’
I	--------------.--------------------------— 4--------------------. . .4.™.. — - w	--—— .
Microsoft Certificate Services Fo-Ed i *n*	И tnv
________________________________________________________--------* -^9- ___— О - - ~	------4_________
Submit a Certificate Request or Renewal Request
To submit a saved request to the CA, paste a base-64-encoded CMC or PKCS #10
certificate request or PKCS #7 renewal request generated by an external source (such as a
Web server) in the Saved Request box
Saved Request:
Base-64-encoded
certificate request
(CMC or
PKCS #10 or
PKCS #7).
Browse for a file to insert
Full path name’ |CAoracle\wallets\user1\user1-re । csr|
Read! | Cancel |
Обзор.. |
Рис. 23.1. Тестовый удостоверяющий центр. Издание сертификата пользователя
Рис. 23.2. Тестовый удостоверяющий центр. Издание сертификата пользователя
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
2.	В окне утилиты Wallet Manager выполнить импорт полученного сертификата в
ключевой контейнер. Для этого выбрать пункт меню «Operations» -> «Import User
Certificate...», либо аналогичный пункт контекстного меню объекта «Certificate» (рис.
24.1). На запрос о способе ввода сертификата выбрать «Select a file that contains the
ertificate» (выбрать файл, содержащий сертификат) и нажать «ОК» (рис. 24.2). В диалоге
выбора файла выбрать сохраненный сертификат (userl-сег.сег) и нажать «Открыть».
Сертификат будет импортирован в Wallet, и окно Wallet Manager будет соответствовать
рис. 24.3. Статус сертификата (п. 1) изменился на «Ready» (готов). В списке доверенных
сертификатов (п. 2) только один сертификат тестового УЦ. Поле «Subject» сертификата
(п. 3) точно соответствует отличительному имени пользователя «userl» в каталоге OID.
На закладке перечислены остальные свойства сертификата (п. 4).
3.	Сохранить ключевой контейнер с помощью команды меню «Wallet» -> «Save». Так-
же в данном меню необходимо отметить пункт выбора «Auto Login» (рис. 25). Далее, за-
вершить работу Wallet Manager — «Wallet» ->«Exit».
После завершения работы Wallet Manager, директория C:\oracle\wallets\userl должна
содержать следующие файлы:
•	ewallet.pl2 — ключевой контейнер, готовый к использованию для аутентифика-
ции клиента;
t Oracle Wallet Manager
pallet Operations j-ieip
Certificate Request.
Import User Certificate...
Import Trusted Certificate.
9
?
Remove Certificate Request
Remove User Certificate..
Remove Trusted Certificate...
Export User Certificate
Export Certificate Request..

Export Trusted Certificate...
Export All Trusted Certificates...
Export Wallet..
Q
Рис. 24.1. Wallet Manager. Импорт сертификата пользователя
{p Import Certificate
Choose one of the following ways to add the certificate into your wallet
Paste the certificate
® Select a file that contains the certificate
Cancel
Рис. 24.2. Wallet Manager. Импорт сертификата пользователя
480
Лабораторная работа Ns 6
Рис. 24.3. Wallet Manager. Готовый ключевой контейнер
Рис. 25. Wallet Manager. Сохранение ключевого контейнера. Завершение работы
•	cwallet.sso — копия ewallet.pl2, используемая для открытия контейнера без предъ-
явления пароля. Действительна только для пользователя, создавшего данный
файл (т.е. для пользователя «oracle»);
•	userl-req.csr — запрос на сертификат пользователя «userl»;
•	userl-cer.cer — подписанный сертификат пользователя «userl».
4.	Для аутентификации с использованием смарт-карты или USB-ключа eToken сле-
дует импортировать созданный ключевой контейнер на аппаратный носитель. Для этого
необходимо скопировать файл ключевого контейнера в файл с расширением .pfx (на-
481
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
пример, в файл ewallet.pfx, расположенный в директории, в которой был сохранен
ewallet.pl2). Далее, в проводнике windows выделить файл ewallet.pfx, и из контекстного
меню выбрать пункт «Install PFX» (рис. 26.1).
5.	В открывшемся окне мастера импорта нажать кнопку «Далее».
6.	В следующем окне выбора импортируемого файла проверить полный путь к файлу
«ewallet.pfx» и нажать кнопку «Далее» (рис. 26.2).
Адрес: ! ) C:\orade\wallets\userl
Задачи для файлов и папок
Переименовать файл
Переместить файл
Копировать файл
> Опубликовать файл в вебе
э Отправить этот файл по
электронной почте
Удалить файл
Другие места
wallets
□ Мои документы
Общие документы
Ц cwallet.sso
3|ewallet.pl2
^userl-cer.cer
S3] userl-req. csr
PFX
Открыть С ПОМОЩЬЮ.. Л
Отправить	►
Вырезать
Копировать
Создать ярлык
Удалить
Переименовать
Свойства
Рис. 26.1. Импорт ключевого контейнера. Запуск мастера.
1астер импорта сертификатов

м
Импортируемый файл
Укажите импортируемый файл.
Имя файла:
C :\oracle\wallets\user 1 \ewallet .ptx |
Обзор... |
Замечание: нижеуказанные фор:«ты файлов могут содержать в одном файле более
одного сертификата;
Файл обмана личной информацией - PKCS #12 (.PFX,.P12)
Стандарт Cryptographic Message Syntax - сертификаты PKCS #7 (.p7b)
< Назад | Далее >
Рис. 26.2. Импорт ключевого контейнера. Выбор файла
482
Лабораторная работа № 6
Настер импорта сертификатов
Пароль
Для обеспечения безопасности закрытый ключ защищен паролем.
Введите пароль для закрытого ключа.
Пароль:
Г Включить усиленную защиту закрытого ключа. В этом случае при
каждом использовании приложением закрытого ключа будет выдаваться
запрос.
Р Пометить этот ключ как экспортируемый, что позволит вам сохранять
архивную копию ключа и перемещать его.
< Назад I Далее > I Отмена
Рис. 26.3. Импорт ключевого контейнера. Пароль для ключевого контейнера
7.	В открывшемся окне мастера ввести пароль ключевого контейнера (в данном при-
мере — «Welcome 1»), отметить пункт выбора «Пометить этот ключ как экспортируе-
мый...» и нажать кнопку «Далее» (рис. 26.3).
Замечание. Хотя закрытый ключ при импорте на смарт-карту помечается как
экспортируемый, он остается недоступным для копирования со смарт-карты или
перемещения на другой носитель.
8.	Вставить смарт-карту eToken в устройство для считывания или подключить
USB-ключ в USB-порт компьютера. Консоль виртуальной машины должна распознать
подключенное оборудование и отобразить иконку подключения. В меню консоли вир-
туальной машины «VM» -> «Removable Devices» «USB Devices» должен быть отобра-
жен отмеченный пункт «Aladdin Knowledge USB device (Port 1)» (рис. 26.4). Если данный
пункт не отмечен, то отметить его.
9.	В окне выбора хранилища сертификатов мастера выбрать пункт «Поместить все
сертификаты в следующее хранилище» и нажать кнопку «Обзор...». В окне выбора хра-
нилища отметить пункт «Показать физические хранилища», в панели дерева хранилищ
вьтделить «Личные» -> «еТокеп» и нажать кнопку «ОК», затем кнопку «Далее» (рис. 26.5).
Ю- В окне завершения работы мастера нажать кнопку «Готово» (рис. 26.6)
11.	В открывшемся окне запроса PIN-кода смарт-карты или USB-ключа eToken ввес-
валидный PIN-код и нажать кнопку «ОК» (рис. 26.7). PIN-код для смарт-карты или
483
ЧАСТЬ III ЛАБОРАТОРНЫЕ РАБОТЫ
JSB-ключа eToken задается при инициализации (форматировании) данного устройства
дминистратором, по умолчанию задается «1234567890».
EDU-Oracle-Client - VMware Workstation АСЕ Edition
& j! ®
j File Edit
фн*м
Файл
Мои I
докумен-J
Removable Devices
Windows Нф
» hlAR
* Ethernet
Подключено устройство
USB-ключ еТокеп
^JHaa
Адрес: |
Мой I
компьют!
Snapshot
Replay
Clone...
Clone to ACE Master.
Install VMware Tools...
Upgrade й? Chang v-.- .lr
.Connect?.-: Users
Зад#------'---------------
Send Ctrl+Ak+Del
( Grab Input
Ctrl f-G
USB Devices >
v Aladdin Knowledge USB Device (Port 1)
Western Digital Removable Disk
пки
Capture Screen.
Caoture Movie .
Егести системы в которых пр.-изео тся
]. ооГ”©i.JSL
1
|| **~! Мастер импорта сер...
' a 12:35
чБ ijjjO ’
USB-устроиство подключено--"""^
Рис. 26.4. Импорт ключевого контейнера. Подключение смарт-карты или USB-ключа
Мастер 4«w»/T .
XI
Хранилище сертификатов
Хранилища сертификатов - это области системы в которых производится
хранение сертификатов.
Выбор хранилища может быть произведен Windows автоматически, или же
можно указать размещение сертификата вручную.
• Автоматически выбрать хранилище на основе типа сертификата
<♦ Поместить все сертификаты в следующее хранилище
X
Выбор хранилищ. cepiифика т ч
_ШЙ.
Выберите хранилище сертификатов,
Обзор..,
R-C1 Личные
_J Реестр
Доверенные корневые центры сертиЗ
S О Доверительные отношения в предпри
+	1 Пппмржутлчныр ленты гептигЬикапис
Отмена
Р Показать физические хранилища
| ОК | Отмена |
Рис. 26.5. Импорт ключевого контейнера. Выбор хранилища.
е >
о л
Лабораторная работа № 6
12
В окне сообщения об успешном импорте ключевого контейнера нажать «ОК».
Мастер импорта сертификатов
Завершение работы мастера
импорта сертификатов
Работа мастера импорта сертификатов успешно
завершена.
Были указаны следующие параметры:
Хранилище сертификатов, выбранное пользователей
Содержание
Имя файла
< Назад Готово Отмена
Рис. 26.6. Импорт ключевого контейнера. Завершение работы мастера
eToken Certificate Store
eToken
Enter eToken password
eIokfin:	|eToken [AKS ifdh 0]
Password <	| ********|
More »
Cancel
Рис. 26.7. Импорт ключевого контейнера. Ввод PIN-кода
485
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Тестирование SSL-аутентификации
с использованием файла ключевого контейнера
Использование файла ключевого контейнера для аутентификации является штатным
механизмом, используемым в Oracle. Возможность соединения с базой данных следует
проверить с помощью утилиты SQL* Plus. Для установления соединения нужно исполь-
зовать сетевой дескриптор с именем «EDUSSL», настроенный в п. 1. Перед тестиро-
ванием требуется коррекция файла сетевой настройки клиента Oracle
(ORACLE_HOME\network\ADMIN\iqlnet.ora\ в нем следует указать корректный тип по-
иска wallet — файл.
1.	В текстовом редакторе открыть c:\oracle\oralO\network\ADMIN^qlnet.ora. Изме-
нить фрагмент настройки
WALLET_LOCATION =
(SOURCE =
(METHOD = MCS)
)
на
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = c:\oracle\wallets\userl)
)
)
Сделанные изменения следует сохранить.
2.	Провести тест соединения с базой данных по SSL-протоколу:
•	Запустить SQL-консоль. Start -> Run... , в поле «Open» указать «sqlplusw /nolog».
Откроется окно SQL-консоли, не соединенное с экземпляром базы данных.
•	Ввести команду соединения с базой данных с использованием ключевого контей-
нера пользователя «userl», т. е. без указания имени пользователя и пароля:
SQL> connect /@edussl
Должно отобразиться сообщение об успешной аутентификации/авторизации.
•	Ввести SQL-команду для определения рабочей схемы:
SQL> select sys_context(«userenv»,«session_user») from dual;
Должно отобразиться имя общей схемы.
•	Ввести SQL-команду для определения имени пользователя:
SQL> select sys_context(«userenv»,«external—name») from dual;
Должно отобразиться отличительное имя пользователя «userl» из каталога OID.
•	Ввести SQL-команду для определения ролей для текущего сеанса:
SQL> select role from session_roles;
Корректные результаты тестирования приведены на рис. 27.
486
Лабораторная работа № 6
Рис. 27. Окно SQL-консоли. Результат теста
Тестирование SSL аутентификации
с использованием смарт-карты или USB-ключа eToken
Использование смарт-карты или USB-ключа eToken для аутентификации требует
установки дополнительного ПО на стороне клиента Oracle. Возможность соединения
с базой данных проверяется также с помощью утилиты SQL*Plus. Для установления
соединения нужно использовать сетевой дескриптор с именем «EDUSSL», настроен-
ный в п.1. Перед тестированием требуется коррекция файла сетевой настройки кли-
ента Oracle (ORACLE—HOME\network\ADMIN\sqlnet.ordY в нем следует указать кор-
ректный тип поиска wallet — хранилище Microsoft, которое расширено для возмож-
ности чтения ключей и сертификатов с физического хранилища — смарт-карты или
USB-ключа eToken.
1-	В текстовом редакторе открыть c:\oracle\oralO\netyvork\ADMIN\sqlnet.ora. Изме-
нить фрагмент настройки
WALLETLOCATION =
(SOURCE =
(METHOD = FILE)
(METHODDATA =
(ЫREC TOR Y = c: \oracle \wallets \userl)
487
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
)
)
на
WALLET_LOCATION =
(SOURCE =
(METHOD = MCS) # MS С — Microsoft Certificate Store
)
Сделанные изменения следует сохранить.
2.	Провести тест соединения с базой данных по SSL-протоколу:
•	Запустить SQL-консоль. Start -> Run... , в поле «Open» указать «sqlplusw/nolog».
Откроется окно SQL-консоли, не соединенное с экземпляром базы данных.
•	Вставить смарт-карту eToken в устройство для считывания или подключить
USB-ключ в USB-порт компьютера. На данной смарт-карте должен быть уста-
новлен ключевой контейнер пользователя «userl» (см. п. 3.12).
•	Ввести команду соединения с базой данных с использованием ключевого контей-
нера пользователя «userl», т.е. без указания имени пользователя и пароля:
SQL> connect/@edussl
•	На запрос PIN-кода следует ввести корректной PIN-код смарт-карты (USB-ключа)
eToken (см. рис. 26.7). Должно отобразиться сообщение об успешной аутентифи-
кации/авторизации.
•	Ввести SQL-команду для определения рабочей схемы:
SQL> select sys_context(«userenv», «session_user») from dual;
Должно отобразиться имя общей схемы.
•	Ввести SQL-команду для определения имени пользователя:
SQL> select sys_context(«userenv», «extemal_name») from dual;
Должно отобразиться отличительное имя пользователя «userl» из каталога OID.
•	Ввести SQL-команду для определения ролей для текущего сеанса:
SQL> select role from session roles.
Корректные результаты тестирования должны полностью соответствовать результа-
там п. 4 (рис. 26).
Варианты заданий
Вариант 1. Организовать доступ для пользователя «userl» для работы с экземпляром
базы данных Oracle «ORCL» в общей схеме «SHAREDSCHEMA» по протоколу SSL для
нового пользователя ОС Windows «oracleuser», имеющего привилегии обычного пользо-
вателя ОС. В качестве хранилища ключей и сертификатов использовать файл (обычный
wallet).
Вариант 2. Организовать доступ для пользователя «user2» для работы с экземпляром
базы данных Oracle «ORCL» в общей схеме «SHAREDSCHEMA» по протоколу SSL. В ка-
честве хранилища ключей и сертификатов использовать USB-ключ eToken.
Отчет представляется с титульным листом установленной формы, приведенной
в конце лабораторной работы № 1.
488
Лабораторная работа Ns 6
Контрольные вопросы
1	Каковы основные компоненты для построения системы аутентификации с исполь-
зованием PKI?
2	Основное назначение службы каталога Oracle Internet Directory (OID).
3	Какие методы предлагает система для аутентификации пользователей масштаба
предприятия?
4	Какие объекты хранятся в ключевом контейнере (wallet)?
5	В чем состоят этапы процесса аутентификации по сертификату пользователя?
6	Для чего необходима процедура регистрации базы данных в каталоге OID?
7	. Какова роль УЦ в организации PKI аутентификации?
8	. Что такое доверенный сертификат?
9	. Какими недостатками обладает хранение ключевой информации в файлах ОС?
10	. Преимущества в плане безопасности при РК1-аутентификации.
11	. Преимущества использования смарт-карт или USB-ключей при хранении ключе-
вого материала.
12	. Назовите общие шаги по изданию сертификата для пользователя.
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Приложение А
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
ДОСТУП В СУБД ORACLE С АУТЕНТИФИКАЦИЕЙ
НА ОСНОВЕ СЕРТИФИКАТОВ
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
Выполнили:
Студенты гр.________________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
490
Лабораторная работа № 7
РЕЖИМЫ РАБОТЫ ПРОТОКОЛА IPSec
НА МОДУЛЕ NME-RVPN ПРИ ИСПОЛЬЗОВАНИИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ CSP VPN GATE
ДЛЯ АУТЕНТИФИКАЦИИ И ЗАЩИТЫ ДАННЫХ
Цель работы
Изучить возможности настройки режимов работы протокола IPSec на модуле
NME-RVPN при использовании программного обеспечения CSP VPN Gate. Изучить
возможности управления модулем NME-RVPN при использовании программного обес-
печения CSP VPN Gate.
Общие сведения о протоколе IPSec
Криптотуннель предназначен для обеспечения криптографической защиты канала
связи между отдельными сетями с установкой средств защиты в открытую сеть. Для ус-
тановки криптотуннеля используется протокол IPSec.
IPSec(IP Security) — определенный IETF стандарт, который обеспечивает механизм
защиты передачи данных пользователей в IP-сетях и гарантирует конфиденциальность,
целостность и достоверность сетевых коммуникаций в незащищенных сетях, таких как
Интернет. IPSec представляет собой набор протоколов и алгоритмов для защиты данных
на сетевом уровне. Наиболее распространенными вариантами применения IPSec явля-
ются организация IPSec VPN-туннеля между сайтами и для удаленного доступа
(Site-to-Site VPN и Remote Access VPN). Site-to-site VPN устанавливается между двумя
сетевыми объектами, где каждый объект представляет собой защищенную сеть. Remote
access VPN обеспечивает централизованное управление удаленными пользователями,
предполагая, однако, что удаленная среда не является защищенной.
IPSec использует три основных протокола для создания защищенной среды:
•	Internet Key Exchange (IKE) — обеспечивает условия для обмена параметрами без-
опасности и устанавливает ключи для аутентификации;
•	Encapsulating Security Protocol (ESP) — обеспечивает шифрование, аутентифика-
цию и защиту данных;
•	Authentication Header (АН) — обеспечивает условия для аутентификации и защи-
ты данных.
Протоколы защиты передаваемого потока данных могут работать как в транспорт-
ном, так и в туннельном режиме. При работе в транспортном режиме IPSec обрабатывает
только информацию транспортного уровня — данный режим рассчитан на работу между
пользователями. В туннельном режиме с целыми IP-пакетами. IPSec в режиме тунне-
рования в основном используется на шлюзах безопасности для конфиденциальной и
тами°ВеРН°й доставки информации между двумя территориально удаленными сегмен-
жим Л°КаЛЬНОЙ сети* Шлюзы безопасности также могут использовать транспортный ре-
тро ° только в том случае, когда они выступают в роли хоста.
одн еС обеспечивает аутентификацию, целостность и шифрование путем добавления
ого или двух специальных заголовков в 1Р-дейтаграмме.
Рам Р°токол АН обеспечивает аутентификацию и проверку целостности в 1Р-дейтаг-
мы. Аутентификация означает, что роследня действительно была послана истин-
491
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
ным отправителем, а целостность — не была изменена в процессе передачи данных
по сети.
Протокол ESP обеспечивает шифрование содержимого дейтаграммы, а также аутен-
тификацию и проверку целостности. АН и ESP используются между двумя хостами, ко-
торые могут быть конечными станциями или шлюзами.
Существует несколько режимов защиты данных IPSec:
•	ESP с проверкой целостности;
•	ESP без проверки целостности;
•	ESP+AH (шифрование плюс проверка целостности);
•	АН (проверка целостности).
Протокол управляет ключами и используется совместно с IPSec, предоставляя до-
полнительные возможности, гибкость и упрощение конфигурации для стандартов IPSec.
Работа 1КЕ состоит из двух фаз:
—	установка ассоциаций безопасности (security associations (SA)) между двумя кли-
ентами;
—	установка связи между двумя SA и генерация ключевой пары для IPSec.
При этом используются два метода IKE аутентификации:
—	с помощью предопределенного ключа (Pre-Share IKE Authentication);
—	с помощью цифровых сертификатов (Digital Certificates IKE Authentication).
Для того чтобы оценить возможность установки IPSec-криптотуннеля между марш-
рутизаторами при использования модуля NME-RVPN, требуется проверить:
—	метод аутентификации 1КЕ, основанный на использовании предопределенного ключа;
—	метод аутентификации IKE основанный на цифровых сертификатах;
—	методы шифрования IPSec.
Защита трафика CSP VPN Gate осуществляется в рамках международных стандартов
IKE/IPsec:
•	Security Architecture for the Internet Protocol — RFC2401.
•	IP Authentication Header (AH) — RFC2402.
•	IP Encapsulating Security Payload (ESP) — RFC2406.
•	Internet Security Association and Key Management Protocol (ISAKMP) RFC2408.
•	The Internet Key Exchange (IKE) — RFC2409.
•	The Internet IP Security Domain of Interpretation for ISAKMP (DOI) — RFC2407.
Модуль NME-RVPN при использовании программного обеспечения CSP VPN Gate
обеспечивает:
•	защиту трафика на уровне аутентификации/шифрования сетевых пакетов по про-
токолам IPsec АН и/или IPsec ESP;
•	пакетную фильтрацию трафика с использованием информации в полях заголов-
ков сетевого и транспортного уровней:
—	на сетевом уровне — по IP v4 адресам и/или полю «протокол» IP заголовка;
—	на транспортном уровне — по направлению установления TCP соединений
и составу сервисов (сервисных протоколов);
•	загрузку политики из внешнего файла;
•	различные наборы правил обработки трафика на различных интерфейсах;
•	получение сертификатов открытых ключей по протоколу LDAP;
•	событийное протоколирование, которое может быть интегрировано с событий-
ным протоколированием маршрутизатора;
•	реализацию заданной дисциплины взаимодействия (аутентификацию и/или за-
щиту трафика) для каждого защищенного соединения, доступ в заданном защи-
492
Лабораторная работа № 7
шейном режиме только для зарегистрированных, в том числе и для мобильных
партнеров по взаимодействию;
регулируемую криптографическую стойкость защиты трафика;
маскировку топологии защищаемого сегмента сети (туннелирование трафика)
П одукт NME-RVPN с CSP VPN Gate использует криптографическую библиотеку
КЗИ «Крипто-КОМ 3.1», разработанную компанией «Сигнал-КОМ», благодаря чему
продукте реализованы следующие алгоритмы криптографической защиты:
в рост 28147—89 — шифрование/дешифрование данных;
ГОСТ Р 34.11—94 НМАС — целостность данных;
ГОСТ Р 34.11—94 — функция хэширования;
ГОСТ Р 34.10—94, ГОСТ Р 34.10—2001 — формирование и проверка электрон-
но-цифровой подписи (ЭЦП);
генерацию случайных чисел.
Описание работы
Для изучения возможностей IPSEC-криптотуннеля между маршрутизаторами при
использовании модуля NME-RVPN работа делится на три части:
•	метод аутентификации IKE, основанный на использовании предопределенного
ключа;
•	метод аутентификации 1КЕ, основанный на цифровых сертификатах;
•	методы шифрования IPSec.
Оборудование и программное обеспечение для выполнения работ
№	Наименование	Краткое описание	Производитель, ссылка
1	Модуль NME-RVPN	Программно-аппаратное ре- шение (предмет исследования для лабораторной работы)	www.s-terra.com
2	Cisco 2821 С2800 Software (C2800NM-1PVOICE-M), Version 12.4(9.9)PI5	Маршрутизатор Cisco	www.cisco.com
3	Cisco 7206 C7200 Software (C7200-JS-M), Version 12.3(18)	Маршрутизатор Cisco	www.cisco.com
4	Catalyst 3560; C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(25)SEE	Коммутатор Cisco	www.cisco.com
5	Рабочие станции с сетевой кар- той 10/100/1000 BaseTX	Рабочие станции (как конеч- ные сетевые устройства)	
6	IP-телефоны Cisco	IP-телефоны Cisco (любые мо- дели), например, 7941 или 7961	www.cisco.com
7	Кабельное оборудование (UTP кабель САТ5)	Кабельное оборудование (провода для соединения)	
8 V	Программа Iperf v 17 (для генерации трафика)	ПО	http://dast.nlanr.net/projects/ Iperf/i perfdocs_l .7.0.php
	Программа Wireshark 0.99 (для анализа пакетов)	ПО	http://wireshark.org/docs/ wsughtml
493
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Изучение работы криптотуннеля
с использованием предопределенного ключа
Данная часть работы предназначена для изучения и тестирования создания IPSec
VPN туннеля с использованием предопределенного ключа (Pre-Shared Keys). Предопре-
деленный ключ позволяет клиентам организации использовать индивидуальные распре-
деленные секретные данные для аутентификации зашифрованных туннелей до шлюза,
используя IKE. Обмен ключами по алгоритму Диффи—Хельмана объединяет открытый
и закрытый ключи для создания секретных данных, которые можно использовать для
аутентификации участников IPSec-туннеля. Секретные данные могут быть распростра-
нены между двумя и более участниками, при этом обмен обычно осуществляется по за-
щищенному внеполосному каналу. Однако, если используется предопределенный ключ
и один из участников не сконфигурирован с помощью того же ключа, IKE SA не может
быть установлен. IKE SA — это предварительное условие для установки IPSec SA. Не-
обходимо сконфигурировать предопределенный ключ на всех участниках.
Преимущество использования предопределенного ключа состоит в том, что эту техно-
логию можно использовать в небольших сетях с числом клиентов не превышающим десяти.
Для выполнения данной части работы необходимо:
•	Как минимум два маршрутизатора с установленным на каждом модулем
NME-RVPN, две рабочие станции клиентов с установленным сетевым адаптером,
•	Создать предустановленный ключ для каждого из маршрутизаторов.
•	Провести необходимое количество тестов для получения достоверного результата.
•	Проанализировать полученный результат.
Изучение работы криптотуннеля
с использованием сертификатов
Аутентификация с применением технологии PKI (Public Key Infrastructure (Инфра-
структура открытых ключей, сертификаты Х.509) позволяет клиентам организации ис-
пользовать цифровые сертификаты для аутентификации защищенных туннелей. Меж-
дународный стандарт Х.509 определяет формат цифрового сертификата. Сертификаты
Х.509 базируются на методе шифрования с открытым ключом. Каждый сертификат на-
ряду с другой информацией (сроком действия, именем владельца и т.п.) содержит от-
крытый ключ. Сертификаты подписываются Certificate Authority (СА), что позволяет
подтвердить подлинность сертификата, информации, содержащейся в сертификате и,
в конечном итоге, удаленного хоста. Подлинность СА проверяется в соответствии с его
свидетельством, которое является общедоступным.
Преимуществом использования цифровых сертификатов является тот факт, что, каж-
дый VPN-клиент и каждый маршрутизатор владеют собственным сертификатом и аутен-
тификация происходит при участии СА. Сеть становится масштабируемой и обеспечивает
более безопасную аутентификацию с помощью цифровых сертификатов по сравнению
с предопределенными ключами. Появляется возможность настроить неограниченное число
VPN-клиентов без дополнительной модификации конфигураций шлюза по умолчанию.
Для выполнения данной части работы необходимо:
•	Как минимум два маршрутизатора с установленным на каждом модулем
NME-RVPN, две рабочие станции клиентов с установленным сетевым адаптером.
•	В настройках модуля прописать метод аутентификации с использованием серти-
фикатов
•	Провести необходимое количество тестов для получения достоверного результата.
•	Проанализировать полученный результат.
494
Лабораторная работа № 7
Изучение работы криптотуннеля
в различных режимах работы IPSec
TPSec устанавливает четыре основных признака безопасного соединения по IP и на-
1 ой передачи данных: конфиденциальность данных (Confidentiality), их целостность
дежно идентификацию другой стороны и данных (Authentication) и неотказуемость
(Integ ’jation). В зависимости от требований безопасности можно создать комбина-
П°ю из различных алгоритмов шифрования и хэширования, и таким образом модуль
NME-RVPN может быть настроен с определенным уровнем гибкости.
При разработке проекта организации Site-to-Site VPN становятся критичными сле-
дующие факторы.
•	уровень безопасности, требуемый для VPN;
•	требования к производительности, которые могут оказывать влияние на выбор
механизма безопасности, когда необходимо найти баланс между безопасностью и
функциональностью.
IPSec предлагает два режима передачи: транспортный и туннельный. При транспорт-
ном режиме — реальный IP-заголовок (следовательно, и IP-адрес) остается без измене-
ний, а заголовок IPSec вставляется между заголовком IP и остальными заголовками или
соответственно данными. При таком способе передачи изменения затрагивают только
транспортный уровень пакета IP, а собственно данные могут быть аутентифицированы
и/или зашифрованы.
Транспортный режим может использоваться при организации VPN-туннелей между
хостами, в остальных случаях требуется туннельный режим, при котором изменяется весь
пакет IP. Защита распространяется на заголовок IP и данные, причем вместо исходного со-
здается новый заголовок IP с другими IP-адресами, при этом размер пакета увеличивается
на 20 байт. Туннельный режим может использоваться в следующих случаях:
—	между сетевыми устройствами (наиболее используемая конфигурация). Сетевое
устройство (маршрутизатор или брандмауэр) обеспечивают функциональность
IPSec-шлюза. Таким образом, конечным пользователям нет необходимости устанавли-
вать какое-либо программное обеспечение и 1076 для работы IPSec;
—	между сетевым устройством и хостом. Организация удаленного доступа по VPN,
когда ПК используется для доступа в корпоративную сеть. Для защиты данных IPSec ис-
пользует несколько режимов:
•	ESP с проверкой целостности;
•	ESP без проверки целостности;
•	ESP+AH (шифрование + проверка целостности);
•	АН (проверка целостности).
Предпочтительнее использовать совокупность протоколов ESP и АН, при этом дан-
ные зашифровываются и происходит проверка их целостности. При этом защищается
весь пакет вместе с IP-заголовком, что позволяет отражать атакаи типа
man-in-the-middle (человек посредине). Однако в этом режиме происходит значительное
к еличение пакета данных. Если учесть, что ESP добавляет в транспортном режиме
и	пакета данных дополнительно 37 байт, а в туннельном режиме — 57 байт,
~~ 24 и 44 соответственно, то размер пакета данных может увеличиться на 81 байт
и ольше (при использовании AES).
п ким образом, чаще всего используется только протокол ESP, поскольку при ис-
кета °Вании только протокола АН добавляется дополнительная нагрузка к заголовку па-
в процессе аутентификации, но при этом не обеспечивается защита данных путем
их ШиФрования.
495
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Для выполнения данной проверки необходимо:
•	Как минимум два маршрутизатора с установленным на каждом модулем
NME-RVPN, две рабочие станции клиентов с установленным сетевым адап-
тером.
•	В настройках модуля прописать используемый вариант набора преобразований.
•	Провести необходимое число испытаний для получения достоверного результата.
•	Проанализировать полученный результат
Задание
1	Изучить теоретические вопросы, изложенные в начале лабораторной работы.
2.	Подготовить модельный стенд.
3.	Изучить возможности настройки и управления программным обеспечением CSP
VPN Gate на модуле NME-RVPN.
4.	Оформить отчет по лабораторной работе.
5.	Ответить на контрольные вопросы.
Разработка стенда
Для обеспечения проверки всех выбранных параметров функциональности модуля
NME-RVPN необходимо провести анализ режимов работы и разработать базовую кон-
фигурацию стенда (рис. 1), которая позволяет проводить проверку требуемых характе-
ристик путем перекоммутации используемого оборудования и добавления дополнитель-
ных периферийных устройств (IP-телефонов, анализаторов сети и т.д.). Это позволяет
сократить время и затраты на специальное оборудование при проведении лабораторной
работы.
При построении данного стенда с учетом составленных требований, документации
по готовым решениям и рекомендации для построения защищенных сетей компании
Cisco Systems, выбрано следующее оборудование и программное обеспечение:
•	модули NME-RVPN;
•	Cisco 2821 С2800 Software (C2800NM-IPVOICE-M), Version 12.4(9.9)PI5;
•	Cisco 7206 C7200 Software (C7200-JS-M), Version 12.3(18);
•	Catalyst 3560;	C3560 Software (C3560-ADVIPSERVICESK9-M), Version
12.2(25)SEE;
•	рабочие станции с сетевой картой 10/100/1000 BaseTX;
•	IP-телефоны Cisco 7941 или 7961;
•	кабельное оборудование (UTP кабель САТ5);
•	программа Iperf v 1.7 (для генерации трафика);
•	программа Wireshark 0.99 (для анализа пакетов).
Для проверки базовой функциональности исходный стенд можно модифицировать
путем перекоммутации и настройки оборудования в соответствии с проводимыми ра-
ботами (рис. 2).
496
L0
5.5.5.1/32 iAnn/94 G 0/10
172.16.0.0/24 VLAN sol
"7“  ’	G 0/9
^3 VLAN 50
Bg 0/0
G 0/1
2.2.2.2/24
G 0/5 j
VLAN 399
172.18.0.1/24
SP 1/0
20^0.20.1/30
L0
5.5.5.2/32
L0
5.5.5.4/32
G 0/11
VLAN 501
G 0/12 r a/
VLAN 501 G 0/
.4
G 0/15
2.2.2.99/24
RVPN
Рабочая станция
N 502 G 0/0
172.17.0.0/30
2G 0/12
VLAN 502
SP .1/0
10.10.10.1/30
FA
10.10.10.2/30
Gi 0/3
V LAN 399
1.1.1.10/24
Gi 0/6
VLAN 499
Gi 0/8
VLAN 499
Gi 0/7
VLAN 399
Рис. 1. Конфигурация стенда для проведения лабораторной работы
172.16.0.2/24
G 0/15

VLAN 502
' SP 1/10
10.10.10.30/30
SP 0/0
10.10.10.40f
G 0/0
FA
I RVPN Л0.10.10.31/30
FA
0.10.41/30
G 0/11
Станция для
мониторинга
Вариант с обеспечением
отказоустойчивости
1.1.1.100/24
Кабельные соединения
оборудования
Лабораторная работа № 7
Ноутбук
Рис. 2. Конфигурация стенда для проверки базовой функциональности
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Лабораторная работа № 7
Порядок выполнения работы
ния лабораторной работы по изучению функциональности модуля
Для	использоваться конфигурация стенда, приведенная на рис. 2.
MN1E-RVPN будет исп
Изучение организации криптотуннеля
с использованием предопределенного ключа
С гласно требованиям для проведения данной части работы необходимо выполнить
^^Уи^полмоват^маршрутизаторы Cisco 2821#12 и Cisco 2821#30 с установленным на
КаЯ2°Соеданить ма^шр^ изэторы, как показано на рис. 2.
3	Клиентские рабочие станции (3 и 5) необходимо подключить к внешнему интер-
фейсу модуля.
4	Настроить оба модуля для возможности организации irbee-туннелей в соответст-
вии с требованиями. Конфигурация маршрутизаторов Cisco 2821 и модулей NME-RVPM
представлена в приложении А (табл. 1, 2).
5.	На компьютерах 3 и 5 в локальных сетях в качестве шлюза по умолчанию необхо-
димо прописать IP-адрес интерфейса FaO/1 модуля NME-RVPN. Таким образом, весь
трафик будет проходить через данный модуль.
6.	Создать предустановленный ключ для каждого из маршрутизаторов. Если в поли-
тике IKE для аутентификации сторон используется предустановленный ключ, то его
можно создать с помощью графического Webbased-интерфейса управления модулем
в разделе Pre-Shared Keys.
Поскольку для каждого партнера согласовывается отдельный предустановленный
ключ, в данном разделе создаются и редактируются предустановленные ключи для раз-
ных партнеров. При аутентификации сторон с помощью предустановленных ключей для
удаленного хоста в качестве идентификатора используется либо имя хоста, либо IP-адрес
7	В настройках модуля прописать метод аутентификации с помощью предустанов-
ленных ключей. Для указания метода аутентификации, используемого в рамках прото-
кола IKE применяется команда authentication. Ниже приведен пример назначения ме-
тода аутентификации на предопределенных ключах в качестве метода аутентификации,
используемого в рамках протокола IKE. Остальные параметры устанавливаются по
умолчанию:
router(config)#crypto isakmp policy 10
router(config- isakmp) #authe ntication pre -share
router(config-isakmp)#exit
8.	Установить защищенное соединение между клиентами.
9.	Для того чтобы убедиться в возможности организации криптотуннеля с использо-
ванием предопределенных ключей при верных настройках оборудования, достаточно
провести тестирование модуля в заданной конфигурации один раз.
Ю. Результат тестирования, согласно спецификации IPSec, можно считать положи-
тельным, если обе стороны могут обмениваться защищенными данными. Результаты
проведенных тестов можно оценить с помощью ICMP-запроса (выполнить команду
Ping) на IP-адрес устройства, находящегося в защищаемой маршрутизатором сети. При-
зер Положительного результата при установке VPN-туннеля.
Команда ping выполняется на рабочей станции с адресом . . .99
499
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
C:\>ping 1.1.1.100
Pinging 1.1.1.100 with 32 bytes of data:
Negotiating IP Security.
Reply from 1.1.1.100: bytes=32 time=30ms TTL=58
Reply from 1.1.1.100: bytes=32 time=32ms TTL=58
Reply from 1.1.1.100: bytes=32 time=35ms TTL=58
Ping statistics for 1.1.1.100:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
C:\>
В случае неудачного результата тестирования — IPSec VPN-туннель не установлен —
обмен данными не возможен (при уточненных настройках оборудования), можно сде-
лать вывод, что модуль NME-RVPN нельзя использовать для организации криптотун-
неля между маршрутизаторами с применением предопределенных ключей.
Пример отрицательного результата:
C:\>ping 1.1.1.100
Pinging 1.1.1.100 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 1.1.1.100:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>
Изучение работы криптотуннеля
с использованием сертификатов
Для проведения данной части работы необходимо выполнить следующие действия.
1.	Использовать маршрутизаторы Cisco 2821 #12 и Cisco 2821#30 с установленным на
каждом модулем NME-RVPN. Конфигурации маршрутизаторов Cisco 2821 представле-
ны в приложении А (табл. 3).
2.	Соединить маршрутизаторы так, как показано на учебном стенде.
3.	Клиентские рабочие станции (3 и 5) необходимо подключить к внешнему интер-
фейсу модуля.
4.	Настроить оба модуля для возможности организации IPSec туннелей в соответст-
вии с требованиями. Конфигурация модулей NMERVPM представлена в приложении А
(табл. 2).
5.	На компьютерах 3 и 5 в локальных сетях в качестве шлюза по умолчанию необхо-
димо прописать IP-адрес интерфейса Fa0/l модуля NME-RVPN. Таким образом, весь
трафик будет проходить через данный модуль.
6.	Выбрать метод получения сертификата: с использованием центра сертификатов
или использовать сертификаты, полученные заранее. Для проведения тестирования
можно использовать Центр сертификации (использующий стандарты ГОСТ 28147—89,
ГОСТ Р 34.10—94, ГОСТ Р 34.11—94, ГОСТ Р 50739—95) или использовать сертификаты,
полученные заранее. Если предполагается использовать предоставленные заранее сер-
тификаты, то их необходимо импортировать в модуль NME-RVPN СА-сертификаты
можно ввести в 16-ричном виде с помощью интерфейса командной строки (Command
Line Interface (CLI)).
500
Лабораторная работа № 7
Для регистрации локального сертификата в модуле используется утилита командной
строки cert_mgr import.
Пример работы команды приведен ниже.
n-30 /opt/VPNagent/bin# ,/cert_mgr import -f nm2/nm2.pem -kc nml
ГОК C=RU,O=s-terra,OU=qa,CN=nm2
7	Для указания метода аутентификации, используемого в рамках протокола IKE,
меняется команда authentication. Ниже приведен пример назначения метода аутен-
ПРфикации на сертификатах в качестве метода аутентификации, используемого в рамках
Т отокола IKE. Остальные параметры устанавливаются по умолчанию:
ПР router(config)#crypto isakmp policy 10
router(config-isakmp)#authentication certificate
router(config-isakmp)#exit
8	Установить защищенное соединение между клиентами
9	Для того чтобы убедиться в возможности организации криптотуннеля с
использованием цифровых сертификатов при верных настройках
оборудования, достаточно провести тестирование модуля в заданной
конфигурации один раз.
10	. Результат тестирования, согласно спецификации IPSec, можно считать положи-
тельным, если обе стороны могут обмениваться защищенными данными. Оценка ре-
зультатов проводится так же, как в предыдущем пункте.
Проверка различных режимов работы IPSec
Для проведения данной части работы IPSec с использованием всех указанных режи-
мов необходимо выполнить следующие действия.
1.	Использовать маршрутизаторы Cisco 2821# 12 и Cisco 2821 #30 с установленным на
каждом модулем NME-RVPN. Конфигурации маршрутизаторов Cisco 2821 представле-
ны в приложении А (табл. 3).
2.	Соединить маршрутизаторы как показано на учебном стенде
3.	Клиентские рабочие станции (3 и 5) необходимо подключить к внешнему интер-
фейсу модуля.
4.	Настроить оба модуля для возможности организации IPSec туннелей в соответст-
вии с требованиями.
5.	На рабочих станциях клиентов прописать IP адрес из той подсети, в которой ус-
тановлена рабочая станция и в качестве шлюза по умолчанию — IP адрес внешнего ин-
терфейса модуля.
6.	Сформировать набор преобразований.
Для формирования набора преобразований используется команда crypto ipsec
transform-set.
Набор преобразований — это приемлемая комбинация протоколов защиты, крип-
тографически алгоритмов и других параметров, применяемых в защищаемом
ес-трафике. В процессе согласования параметров IPSec SA партнеры соглашаются на
использование конкретного набора преобразований для защиты конкретного потока
иных. Можно сконфигурировать несколько наборов преобразований и затем назна-
чить один (или несколько конкретной записи криптографической карты. Этот набор
реобразований используется при согласовании параметров IPSec SA для защиты потока
ННЫх’ определенного в списке доступа записи криптографической карты. Набор пре-
Разований определяет использование протоколов IPSec: ESP и АН, и указывает на
501
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
криптографические алгоритмы, которые следует использовать с этими протоколами.
Данные протоколы могут использоваться как отдельно, так и одновременно.
Для создания набора преобразований следует описать от одного до трех преобразо-
ваний. Каждое из преобразований должно содержать описание используемых протоколов
(АН, ESP) и криптографических алгоритмов В данной работе будут рассматриваться за-
падные криптоалгоритмы, это связано с ограничением программного обеспечения модуля.
7.	В настройках модуля прописать используемый вариант набора преобразований.
Рекомендуемые настройки модуля NME-RVPN для проведения тестирования режимов
работы IPSec и описание возможных комбинаций преобразований приведены в прило-
жении А (табл. 4).
8.	Установить защищенное соединение между клиентами (выполнить команду ping
на клиентских машинах).
9.	Для того чтобы убедиться в возможности организации криптотуннеля с использо-
ванием всех указанных режимов при верных настройках оборудования, достаточно про-
вести тестирование каждого из режимов работы IPSec один раз.
10.	Результат тестирования согласно спецификации IPSec можно считать положи-
тельным, если обе стороны могут обмениваться защищенными данными.
Оценка результатов проводится так же, как в предыдущем пункте.
Содержание отчета
Отчет оформляется один на бригаду из одного-двух исполнителей.
В отчете с титульным листом установленной формы (см. Приложение В) необходимо
представить следующие сведения:
1.	Наименование и цели работы.
2.	Краткую характеристику учебного стенда (по составу доступных пользователю
функций управления и индикаций, распределению ресурсов, функций, вариантов
набора преобразований).
3.	Функциональную схему учебного стенда с пояснениями и комментариями.
4.	Измеренные значения, полученные в ходе выполнения работы.
5.	Подготовиться для устных ответов по контрольным вопросам.
Контрольные вопросы
1.	Как подготовить к работе учебный стенд?
2.	Как ввести в действие учебный стенд?
3.	Назовите признаки готовности учебного стенда.
4.	Назовие способы получения сертификата.
5.	Что означает защищенное соединение?
6.	Какие методы аутентификации IKE вы знаете7 На чем эти методы могут быть ос-
нованы?
7.	Как определить, что IPSec VPN-туннель не установлен и обмен данными не воз-
можен? Что для этого необходимо сделать?
8.	Какие режимы защиты данных использует IPSec? Чем они различаются?
9.	Какие два режима передачи предлагает IPSec? В чем их различие?
10.	Какой из вариантов использования совокупности протоколов является наиболее за-
щищенным?
502
Лабораторная работа № 7
Приложение А
Конфигурация оборудования для изучения
организации IPSEC VPN-туннеля между
маршрутизаторами
Конфигурации маршрутизаторов Cisco 2821# 12 и Cisco2821#30 для изучения орга-
низации туннеля с использованием предопределенных ключей представлены в табл. 1,
конфигурации модулей NME-RVPN на маршрутизаторах Cisco 2821 # 12 и Cisco2821#30 —
в табл. 2.
Таблица 1
Конфигурации маршрутизаторов Cisco 2821
282112	282130
2821_12#sh run version 12 4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption i hostname 2821_ 12 ! boot-start-marker boot system flash c2800nm-ipvoicemz. 124-9.9.PI5 boot-end-marker i j ip cef interface LoopbackO i ipaddress 5.5.5.1 255.255.255.255 ! interface GigabitEthemetO/O ipaddress 172.16.0.3 255.255.255.0 ip virtual-reassembly duplex full speed auto j interface GigabitEthemetO/1 ^address 2.2.2.1 255.255.255.0 ip nbar protocol-discovery ip virtual-reassembly shutdown duplex full sPeed auto i in^Ce SPecia|-Services-Engine 1/0 P address 20.20.20.1 255.255.255.252 J10 keepalive JU^teO.O.O.O O.O.Q Q	2821_30#sh run version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-enciyption I hostname 2821 30 I boot-start-marker boot system flash:c2800nm-ipvoicemz. 124-9.9.PI5 boot-end-marker i i ip cef i interface LoopbackO ip address 5.5.5.3 255.255.255.255 i interface GigabitEthernet0/0 ip address 172.17.0.2 255.255.255.252 duplex auto speed auto interface GigabitEthemetO/1 i ipaddress 1.1.1.1 255.255.255.0 shutdown duplex auto speed auto I interface Special-Services-Engine 1 /0 ip address 10.10.10.1 255.255.255.252 no keepalive i ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0 ip route 1.1.1.0 255.255.255.0 10.10.10.2
503
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Окончание табл. 1
2821_12	2821 30
213.24.233.129 ip route 0.0.0.0 0.0.0.0 GigabitEthemetO/O ip route 2.2.2.0 255.255.255.0 20.20.20.2 ip route 172.17.0.0 255.255.255.252 GigabitEthemet0/0	ip route 2.2.2.0 255.255.255.0 GigabitEthemet0/0 ip route 172.16.0.0 255.255.255.0 GigabitEthemetO/O
Таблица 2
Настройка модулей NME-RVPN
Cisco 2821X12 RVPN	Cisco2821#30 RVPN
rvpn-12#sh run I	RVPN-30#sh run i
crypto ipsec df-bit copy crypto isakmp identity address username cscons password csphostname rvpn-12 enable password csp i	crypto ipsec df-bit copy crypto isakmp identity address username cscons password csphostname RVPN-30 enable password csp ।
crypto isakmp policy 1 hash md5 encryption des authentication pre-share group 1 i	crypto isakmp policy 1 hash md5 encryption des authentication pre-share group 1 I
crypto isakmp key cisco 123 address 10.10.10.2 i	crypto isakmp key cisco 123 address 20.20.20.2 i
crypto ipsec transform-set ts esp-des esp-md5-hmac mode tunnel i	crypto ipsec transform-set ts esp-des esp-md5-hmac mode tunnel
ip access-list extended Ians permit ip 2.2.2.0 0.0.0.255 1.1.1.0 0.0.0.255 I	ip access-list extended Ians permit ip 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255 i
crypto map cm 1 ipsec-isakmp match address Ians set transform-set ts set pfs group 1 set peer 10.10.10.2 !	crypto map cm 1 ipsec-isakmp match address Ians set transform-set ts set pfs group 1 set peer 20.20.20.2 !
i interface FastEthemetO/O ip address 20.20.20.2 255.255.255.252 crypto map cm interface FastEthemetO/1 ip address 2.2.2.10 255.255.255.0 !	I interface FastEthemet0/0 ip address 10.10.10.2 255.255.255.252 crypto map cm interface FastEthemetO/1 ip address 1.1.1.10 255.255.255.0 i
ip route 0.0.0.0 0.0.0.0 20.20.20.1 1	ip route 0.0.0.0 0.0.0.0 10.10.10.1 1
504
Лабораторная работа № 7
Настройки маршрутизатора Cisco 2821 для изучения организации криптотуннеля с
использованием аутентификации Х.509 представлены в табл. 3.
Таблица 3
Настройка Cisco 2821
Cisco 2821# 12	Cisco2821#30
nml#sh run crypto ipsec df-bit copy crypto isakmp identity dn username cscons password csp hostname nml enable password csp i	nm2#sh run crypto ipsec df-bit copy crypto isakmp identity dn username cscons password csp hostname nm2 enable password csp i
crypto isakmp policy 1 hash md5 encryption des authentication rsa-sig group 1	crypto isakmp policy 1 hash md5 encryption des authentication rsa-sig group 1 i
crypto ipsec transform-set ts esp-des esp-md5-hmac mode tunnel i	crypto ipsec transform-set ts esp-des csp-md5-hmac mode tunnel i
ip access-list extended Ians permit ip 2.2.2.0 0.0.0.255 1.1.1.0 0.0.0.255 i	ip access-list extended Ians permit ip 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255 !
crypto map cm 1 ipsec-isakmp match address Ians set transform-set ts set pfs group 1 set peer 10.10.10.2 i	crypto map cm 1 ipsec-isakmp match address Ians set transform-set ts set pfs group 1 set peer 20.20.20.2 i
interface FastEthemetO/O ip address 20.20.20.2 255.255.255.252 crypto map cm interface FastEthemetO/1 ip address 2.2.2.10 255.255.255.0 snmp-server community public i	interface FastEthemet0/0 ip address 10.10.10.2 255.255.255.252 crypto map cm interface FastEthemetO/1 ip address 1.1.1.10 255.255.255.0 snmp-server community public i
crypto ca trustpoint sterra_ technological_trustpoint crl optional crypto CA certificate chain sterra_ technological_trustpoint certificate 0101010101010101 308201893082012CA0030201020208010101010 1010101300E060A2B06010401AD590103020500 3032310B30090603550406130252553110300E0	crypto ca trustpoint sterra_ technological_trustpoint crl optional crypto CA certificate chain sterra_ technologicaltrustpoint certificate 0101010101010101 308201893082012CA0030201020208010101010 1010101300E060A2B06010401AD590103020500 3032310B30090603550406130252553110300E0
505
ЧАСТЬ III ЛАБОРАТОРНЫЕ РАБОТЫ
Окончание табл. 3
Cisco 2821#12	Cisco2821#30
60355040A1307732D74657272613111300F0603 55040313084E6F746172794341301E170D30343 13032393137303035325A170D30393130323931 37303035325A3032310B3009060355040613025 2553110300E060355040A1307732D7465727261 3111300F060355040313084E6F7461727943413 05E3016060A2B06010401AD5901060206082A86 48CE3D030107034400044104D1BC76EDE6128E8 32D5D029F4E741E35FC2E99D23E086C10DC6772 8ABAB5E666ED9881AB73F1543F1A6C7049FD8CE 381E97BE2294A499F976F1CD559C8B7CA35A323 3021300F0603551D130101FF040530030101FF3 00E0603551D0F0101FF040403020106300E060A 2B06010401AD590103020500034700304402204 1991DE0A1В1C176B097A8825A9FDEFB6D57982B AA995C1DA11164E0F443E542022036E923625D7 8A172525FADD52E18A09E296141EB24688C97F2 9CB405578DDED8 quit i ip route 0.0.0.0 0.0.0.0 20.20.20.1 1 end nml#	60355040A1307732D74657272613111300F0603 55040313084E6F746172794341301E170D30343 13032393137303035325A170D30393130323931 37303035325A3032310B3009060355040613025 2553110300E060355040A1307732D7465727261 3111300F060355040313084E6F7461727943413 05E3016060A2B06010401AD5901060206082A86 48CE3D030107034400044104D1BC76EDE6128E8 32D5D029F4E741E35FC2E99D23E086C10DC6772 8ABAB5E666ED9881AB73F1543F1A6C7049FD8CE 381E97BE2294A499F976F1CD559C8B7CA35A323 3021300F0603551D130101FF040530030101FF3 00E0603551D0F0101FF040403020106300E060A 2 B06010401AD590103020500034700304402204 1991DE0A1В1C176B097A8825A9FDEFB6D57982B AA995C1DA11164E0F443E542022036E923625D7 8A172525FADD52E18A09E296141EB24688C97F2 9CB405578DDED8 quit i ip route 0.0.0.0 0.0.0.0 10.10.10.1 1 end nm2
Импорт сертификатов в модуль NME-RVPN
Пример импорта сертификатов в модуль NME-RVPN приведен ниже. В данном примере
сертификаты загружаются с FTP-сервера, вход выполняется под учетной записью —root:
rvpn-30:/opt/VPNagent/bin# mkdir nm2
rvpn-30:/opt/VPNagent/bin# mkdir nm2/keys
rvpn-30:/opt/VPNagent/bin# ftpget -u ftp -p sgena@ 172.16.0.1 rand.opq
/nm2/rand.opq
rvpn-30:/opt/VPNagent/bin# ftpget -u ftp -p sgena@ 172.16.0.1 nm2.pem
/nm2/nm2.pem
rvpn-30:/opt/VPNagent/bin# ftpget -u ftp -p sgena@ 172.16.0.1 mk.db3
/nm2/mk.db3
rvpn-30:/opt/VPNagent/bin# ftpget -u ftp -p sgena@ 172.16.0.1 kek.opq
/nm2/kek.opq
rvpn-30:/opt/VPNagent/bin# ftpget -u ftp -p sgena@ 172.16.0.1 masks.db3
/nm2/masks.db3
rvpn-30:/opt/VPNagent/bin# ftpget -u ftp -p sgena@ 172.16.0.1 request.pem
/nm2/request.pem
rvpn-30:/opt/VPNagent/bin# ftpget -u ftp -p sgena@ 172.16.0.1
keys/00000001 .key /nm2/keys/00000001 .key
506
Лабораторная работа № 7
Рекомендуемые настройки модуля NME-RVPN
для изучения режимов работы IPSec
Набор режимов работы протоколов ESP и АН можно задать командой конфигурации
crypto ipsec transform-set. Допустимые комбинации преобразований представлены в
табл. 4.
Допустимые комбинации преобразований
Тип преобразования	Имя	Описание
АН Transform (один из списка)	ah-md5-hmac ah-sha-hmac	Протокол АН с алгоритмом аутентификации ГОСТ Р 34.11-94 НМАС Протокол АН с алгоритмом аутентификации SHA
ESP Encryption Transform (один из списка)	esp-des esp-3des esp-aes-128 esp-aes-192 esp-aes-256	Протокол ESP с алгоритмом ГОСТ 28147-89 Протокол ESP с 168-битным алгоритмом 3DES Протокол ESP с 128-битным алгоритмом AES Протокол ESP с 192-битным алгоритмом AES Протокол ESP с 256-битным алгоритмом AES
ESP Authentication Transform (один из списка)	esp-md5-hmac esp-sha-hmac	Протокол ESP с алгоритмом аутентификации MD5 ГОСТ Р 34.11-94 НМАС Протокол ESP с алгоритмом аутентификации SHA
Пример заданной конфигурации:
RVPN-30(config)#crypto ipsec transform-set
<cr>
ah-md5-hmac //режим АН
ah-sha-hmac //режим АН
esp-aes //режим ESP с шифрованием
esp-des //режим ESP с шифрованием
esp-3des //режим ESP с шифрованием
esp-md5-hmac //режим ESP с проверкой целостности
esp-sha-hmac //режим ESP с проверкой целостности
Пример настроек модуля для выбора режима шифрования:
router(config)#crypto ipsec transform-set ts ah-md5-hmac
esp-des esp-md5-hmac
//использовать режим АН+ESP с проверкой целостности
router(config)#crypto ipsec transform-set ts ah-sha-hmac
// использовать режим АН
router(config)#crypto ipsec transform-set ts ah-md5-hmac esp-des
//использовать режим AH+ESP
router(config)#crypto ipsec transform-set ts esp-md5-hmac esp-3des
//использовать режим ESP с проверкой целостности
router(cfg-crypto-trans)#mode tunnel
//изменения режима, используемого набором преобразований
router(cfg-crypro-trans)# exit
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Приложение В
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
РЕЖИМЫ РАБОТЫ ПРОТОКОЛА IPSec
НА МОДУЛЕ MME-RVPN ПРИ ИСПОЛЬЗОВАНИИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ CSP VPN GATE
ДЛЯ АУТЕНТИФИКАЦИИ И ЗАЩИТЫ ДАННЫХ
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
Выполнили:
Студенты гр.________________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
505
Лабораторная работа № 8
НАСТРОЙКА WEB INTERFACE 4.Х
ДЛЯ ИСПОЛЬЗОВАНИЯ СМАРТ-КАРТ
Цель работы
Изучение возможности использования двухфакторной аутентификации в продуктах
Citnx Systems. Получение навыков работ по настройке Web Interface Citrix XenApp Server
для использования смарт-карт.
Общие сведения
При аутентификации с помощью смарт-карт, IIS аутентифицирует пользователя
и затем перечисляет приложения, используя список идентификаторов безопасности
групп (SID), вместо явного использования имени пользователя и пароля. Аутентифи-
цируя пользователя, MS Internet Information Server полагается на отображение клиент-
ского сертификата.
Пользователю необходимо иметь устройство для считывания смарт-карт
и смарт-карту, содержащую пользовательский сертификат и закрытый ключ Для полу-
чения доступа к своему закрытому ключу, хранящемуся на смарт-карте, пользователь
должен ввести PIN-код, обычно представляющий собой 4 цифры. Любой Web-сайт или
виртуальный каталог, обслуживаемый Internet Information Server, может быть настроен
для приема или требования клиентского сертификата.
Существует два метода аутентификации с помощью смарт-карт: смарт-карта и сквоз-
ная аутентификация со смарт-картой. Если выбрана сквозная аутентификация со
смарт-картой, то для переключения аутентификации клиентского сертификата на IIS
используются динамические скрипты, расположенные в каталоге аутентификации сер-
вера Web Interface (Citrix\MetaFrame\auth\certificate.aspx).
После того как клиентский сертификат проверен и послан IIS, Web-сервер взаи-
модействует с контролером домена Active Directory для отображения сертификатов
в доменные пользовательские учетные записи. Как описано в Web Interface
Administrator’s Guide, этот шаг требует, чтобы в диалоговом окне «Основные Свойства»
WWW-службы в Internet Services Manage была задействована служба Windows directory
service mapper.
После успешного отображения учетной записи контроллер домена возвращает токен
идентификации пользователя и IIS получает доступ к скриптам доступа от имени поль-
зователя.
При использовании стандартной аутентификации по смарт-картам (не сквозная),
доступ к Web Interface URL требует от пользователя выбора сертификата, который
будет использован со смарт-картой, а также введения пользователем PIN-кода.
509
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Методические указания
Подготовка стенда для выполнения работы
Минимальные аппаратные требования к хост-машине
Процессор DualCore 2,6 Ghz Intel или AMD и выше, минимальный объем ОЗУ —
2 Гб, рекомендуется 4 Гб, и 30—35 Gb свободного дискового пространства, сетевая карта
и подключение к сети Интернет.
Citrix XenServer (http://citrix.postclickmarketing.com/try_express) или MS Windows 2008
Hyper-V или OS Windows 2000/XP/2003 с клиентским ПО MS Virtual Server 2005 R2 SP1
(http://www.microsoft.com/downloads/details.aspx?FamilyId=BC49C7C8-4840-4E67-8DC4-
lE6E218ACCE4&displaylang=en) и утилитой управления MS VMRCplus (http://www.
microsoft.com/downloads/details.aspx?FamilyID=80ADC08C-BFC6-4C3A-B4Fl-772F550A
E791&displaylang=en) .
Установка виртуального окружения для MS Virtual Server 2005 R2 SP1
1.	Распаковать архив с образами виртуальных машин на жесткий диск хост-машины
(например, в каталог C:\EVA\). Архив с образами виртуальных машин можно скачать с
сайта http://citrix.com/tryxenapp. На сайте необходимо выбрать «Platinum Edition EVA».
2.	Архив содержит файлы:
ctxscpsplt.vhd
ctxs_cps_plt.vmc
ctxs_dc.vhd
ctxs_dc.vmc
ctxs_sql.vhd
ctxs_sql.vhd
3.	Для размещения файлов рекомендуется создать соответствующие подкаталоги вну-
три каталога C:\EVA\, например \DC\, \CPS\ и \SQL\ (рис. 1).
4.	Перемещаем файлы по соответствующим подкаталогам: ctxs_cps_plt.* в каталог
CPS, ctxs dc.* в каталог DC и ctxs sqL* в каталог SQL.
5.	Запустить клиент VMRCplus. В панели инструментов нажать кнопку «Connect»
(рис. 2).
• EVA
Foe Edit View Favorites Tools Help
у Back ’	* Search Folders | ^Folder Sync
\>»ess
Name
_jCPS
__jDC
SQl
Size Type	Date Modified
File Folder	24.09.2008 22:53
Fie Folder	24.09.2008 22:53
He Folder	24.09.2008 22:51
Рис. 1 Предлагаемая структура каталога для виртуального стенда
510
Лабораторная работа № 8
г Virtual Machine Manager - Virtual Machine Remote Control Client Plus
View	Tools Help
 localhost	? ’° Connect
Connected Hosts
Virtual Machine Name	Status CPU RAM Notes
Рис. 2 Подключение утилиты VMRCpIus к Virtual Server
Jjj Create Ctrl+N	^.Disconnect jj Event Viewer	Virtual Disks Virtual Networks |
5	Add	Ins
j	Remove	Del
>1	Deek:	Shift" el	Status CPU RAM Notes
Рис. 3. Добавление существующей виртуальной машины
6.	Затем в меню, выбираем пункт «Virtual Machine» -> «Add» (рис. 3) и в открывшемся
окне переходим в каталог, где расположен файл конфигурации виртуальной машины.
7.	Нажимаем кнопку «Open» (рис. 4).
8.	Повторяем операции 6 и 7 для оставшихся машин виртуальной среды.
9.	В зависимости от объема установленной на машине-хосте памяти изменяем объем
ОЗУ в виртуальной машине. Для этого устанавливаем курсор на виртуальную машину,
чьи параметры мы будем редактировать, нажимаем правую кнопку мыши и выбираем
пункт — «Settings» (рис. 5).
10.	В открывшемся окне редактируем параметр «Memory», а также, если мы хотим
иметь возможность отменить результаты нашей работы, включаем параметр «Enable
undo disks».
11.	Нажимаем кнопку «Apply» и затем «ОК» (рис. 6).
12.	Повторяем операции 9-11 для остальных виртуальных машин (рис. 7).
511
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 4. Открытие файла конфигурации виртуальной машины
В Virtual Machin. Manager - Virtual Machine Remote Control Client Plus
Virtual Machine View Virtual Server Tools
• localhost	*	Disconnect	И Event Viewer	Virtual Qisks Virtue
Crrned<id HojSs
l” localhost
Virtual Machine Name
 “ r
dxs de  Turn On	Ctrl+U
H Pause/Resume
Status CPU RAM I Notes
256
512
Тш
’^Я	Save State	Ctri+S
1Й	ShutDo^n	Ctri+Q
• ’	Turn Off	Shift+F4
R Reset	Shift 4F 5
4	VM Console	Ctrl+G
.w Manage Disk States	►
	Create Snapshot
: I Restore Snapshot	►
‘	Settings	Ctrl+C
Notes	Ctri+E
i=fj	Properties	Ctrl4P
Рис. 5 Редактирование настроек виртуальной машины
512
Лабораторная работа № 8
Рис. 6 Установка параметров виртуальной машины
513
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
CTXS-CPS
192.168.100.3
Windows Server 2003
Виртуализация приложений
Хаб Приложений
Сервер лицензий Citrix
Клиенты и агенты Citrix
Web Сайты для служб Citrix
CTXS-DC
192.168.100.1
Windows Server 2003
Контроллер домена
Служба сертификатов
Два сетевых интерфейса
Служба маршрутизации
DHCP
К физическому
адаптеру
Описание стенда
CTXS-SQL
192.168.100.2
Streaming profiler
SmartAuditor
Мониторинг Производительности
Приложений (EdgeSight)
Служба Single Sign-On
и хранилище учетных данных
Рис. 7 Схема стенда виртуальных машин
Описание стенда (табл. 1 и 2)
Таблица 1
Установленное ПО и аппаратные характеристики виртуальных машин
Параметр	Описание
CTXS-DC	
«Гостевая» операционная система	• Windows 2003 Server Enterprise Edition SP2
Объем оперативной памяти	•	512 Мб (по умолчанию) •	Можно уменьшить до 256 Мбайт в случае ограниченного объема опера- тивной памяти на хост машине
Сетевые карты	•	1 — для внутренней сети •	1 — привязана к физическому адаптеру, для подключения извне
Роль	•	Контроллер домена WWC.COM •	Сервер сертификатов •	Маршрутизация во внешнюю сеть •	DNS сервер Почтовый сервер (POP3, SMTP) •	Файл-сервер •	Сервер приложений
CTXS-SQL	
«Гостевая» операционная система	• Windows 2003 Server Enterprise Edition SP2
514
Лабораторная работа № 8
Окончание табл. 1
Параметр	Описание
Дополнительное ПО	•	MS SQL Server 2005 Enterprise Edition •	Citrix EdgeSight •	Citrix SmartAuditor •	Citrix Password Manager
Объем оперативной памяти	•	1024 Мбайт (по умолчанию) •	Можно уменьшить до 512 Мбайт в случае ограниченного объема опе- ративной памяти на хост машине
Сетевые карты	• 1 — для внутренней сети
Роль	•	Сервер баз данных для продуктов Citrix •	Хранилище учётных данных для использования Citrix Password Manager •	Компьютер для подготовки потоково-доставляемого ПО (Профайлер) •	Консоль мониторинга производительности •	Сервер и консоль для видеологирования терминальных сессий (SmartAuditor) •	Файл-сервер •	Сервер приложений
CTXS-CPS	
«Гостевая» операционная система	• Windows 2003 Server Enterprise Edition SP2
Дополнительное ПО	•	Citrix ХепАрр 4.5 c Feature Pack 1 и Hotfix Rollup Pack 2 •	Агенты Citrix Password Manager, Citrix EdgeSight, Citrix SmartAuditor
Объем оперативной памяти	1024 Мбайт (по умолчанию) • Можно уменьшить до 512 Мбайт в случае ограниченного объема опе- ративной памяти на хост машине
Сетевые карты	• 1 — для внутренней сети
Роль	•	Сервер приложений •	Файл-сервер •	Терминальный сервер •	Сервер лицензий Citrix •	Web-сервер для доступа к опубликованным приложениям
Таблица 2
Учетные записи и пароли пользователей
Пользователь	Пароль	Описание
Administrator	Evaluation 1	Администратор домена WWC.COM и Citrix ХепАрр
Ctxsuserl	Evaluation!	Пользователь домена WWC имеет доступ ко всем опубликованным приложениям, кроме консолей администрирования, и не имеет воз- можности запуска приложений с использованием технологии пото- ковой доставки
Ctxsuser2	Evaluation 1	То же
Ctxsuser3	Evaluation!		55	
Ctxsuser4	Evaluation 1	Пользователь домена WWC имеет доступ ко всем опубликованным приложениям, кроме консолей администрирования, и может запус- кать приложения с использованием технологии потоковой доставки
Ctxsuser5	Evaluation 1	То же
Ctxsuser6	Evaluation 1		55	
515
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Задание
Организовать доступ для пользователей, использующих смарт-карты, в двух вариан-
тах — стандартная аутентификация по смарт-картам и сквозная аутентификация
Подготовка к работе
Запуск виртуальных машин и подготовка
к работе виртуального окружения
До начала использования виртуальных машин необходимо обновить версию «VM
Additions» (оптимизированные драйверы для гостевых машин).
•	Запускаем каждую машину нашего виртуального стенда. Для этого устанавливаем
курсор на запись соответствующую машине, которую мы хотим включить и нажав
правую клавишу мыши из появившегося контекстного меню выбираем Turn On.
•	Для подключения к консоли виртуальной машины, опять нажимаем правую
кнопку мыши, предварительно выбрав нужную включенную виртуальную маши-
ну из контекстного меню выбираем VM Console.
•	Используя учетную запись «Administrator» входим в систему, нажав комбинацию
клавиш Right + Alt + Del.
•	В окне «Console Manager» выбираем пункт меню Media -> Install Current VM Ad-
ditions (рис. 8).
•	В гостевой операционной системе начнется установка дополнений.
Рис. 8 Установка дополнений для гостевой машины
5L6
Лабораторная работа № 8
Рис. 9 Завершение установки дополнений гостевой операционной системы
•	После завершения процесса установки инсталлятор предложит перезагрузить сис-
тему (рис. 9).
•	После перезагрузки поле Additions: изменит цвет с красного на черный, что будет
указывать на последнюю доступную версию дополнений гостевой операционной
системы.
•	Установив дополнения гостевой системы, необходимо сохранить изменения в об-
разе виртуальной машины, для чего в окне «Console Manager» необходимо вы-
брать меню Control -> Undo Options -> Shut Down Guest OS and Commit Undo
Disks.
517
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Установка лицензий Citrix для XenApp Platinum
При загрузке набора виртуальных машин с сайта Citrix Systems вы проходите реги-
страцию, и через некоторое время на указанный во время регистрации адрес электрон-
ной почты вы получите файлы временных лицензий (cps_eva_eval_license.lic и
cps_eva_eval_license_cag.lic).
Эти файлы необходимо поместить в виртуальную машину CTXS-CPS в каталог
C:\Program Files\Citrix\Licensing\My Files\. Чтобы проверить, что лицензии установи-
лись на машине CTXS-CPS можно запустить Консоль Лицензирования. Для этого за-
пускаем Internet Explorer и в строке адреса набираем http://ctxs-cps/lmc/index.jsp. При
появлении окна аутентификации необходимо ввести учетные данные пользователя
Administrator (рис. 10).
В открывшейся консоли выбираем View Current Usage Data. Мы должны увидеть, что
в системе установлены временные лицензии Citrix XenApp (рис. 11).
На виртуальной машине CTXS-CPS также находится разделяемый файловый ресурс
«Eval Resources», внутри которого располагаются клиентское ПО Citrix Systems.
На данный ресурс необходимо установить правильные права доступа.
Рис. 10 Консоль управления лицензиями Citrix
518
Лабораторная работа № 8
Current Usage - ctxs-cps - Citrix License Management Console - CTXS-CPS\Ackntnistr<itor - Windows Internet f -U., r r
UJ * 14^ http://ctxs-cps/1mc/current_us<.ge/currentUsaqe.isp	Я *т л [TiveSeaidT^
He £cSt Wew Favorites Tools tfetp
и/ '0 Current Usage - ctxs-cps - Citrix License Management... |	|	- £2 ' Ш -
License Management Console
Help К
CwiviM Lka je
Historical Usage
Configuration
I User Administration
License Server ctxs-cps
Query Time: 1:29:01 AM EEST Sep 26, 2008
Refresh ПЗ	Complete License Inventory E3
CLwJuU	|MjJ»I_________ jly^e ]Installed [in Use
|Citrix Access Gateway, Advanced Edition	Concurrent User	Evaluation |99	0
Citrix Access Gateway Enterprise Edition	Concurrent User	Evaluation 99	0
Citrix Access Gateway, Standard Edition Concurrent User {Evaluation 99	(0	99
Citnx Start-up License	Server 	System 5.000 2Ej 4 998
Citnx ХепАрр (Presentation Server) Advanced	’Concurrent User	(Evaluation	[99	0	[99
Citnx ХепАрр (Presentation Server) Enterprise	Concurrent User	Evaluation	99	0	99
|Citnx ХепАрр (Presentation Server) Platinum	[Concurrent User	Evaluation	£9	[i	|98
Citrix ХепАрр {Presentation Server Standard	Concurrent User	Evaluation	99	0	99
Refresh 03	Complete License inventory S
Рис. 11 Временные лицензии для виртуального стенда
Открываем «Му computer» -> «Local disk С» -> «Eval Resources» -> далее на каталоге
«Clients» нажимаем правую кнопку мыши и выбираем «Sharing and Security», затем пе-
реходим на вкладку «Security».
На данной вкладке нужно нажать кнопку «Add» и в открывшемся окне выбрать груп-
пу пользователей «Domain Users» (рис. 12).
Этой группе пользователей необходимы права «Read&Execute», «List Folder
Contents» и «Read». После присвоения необходимых прав, нажимаем кнопку «Apply»
и «ОК» (рис. 13).
После установки лицензий и присвоения прав доступа на каталог «C:\Eval
Resources\Clients\», необходимо сохранить изменения в образе виртуальной машины,
для чего в окне «Console Manager» необходимо выбрать меню Control -> Undo Options
Shut Down Guest OS and Commit Undo Disks.
Для выполнения следующей лабораторной работы нам необходимы все три вирту-
альные машины. Необходимо отметить, что для корректной работы необходимо соблю-
дать правильную последовательность загрузки системы. Первым должен загружаться
компьютер CTXS-DC, после завершения его загрузки, запускается компьютер
CTXS-SQL и последним включается CTXS-CPS.
В качестве клиентской машины для проверки работоспособности решения можно
использовать: хост-машину, дополнительную виртуальную машину с Windows ХР или
Windows Vista, которые можно загрузить с сайта компании Microsoft —
http://www.microsoft.com/downloads/details.aspx?FamilyID=21EABB90-958F-4B64-B5Fl-
73D0A413C8EF&displaylang=en, а также компьютер CTXS-SQL.
519
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
locatrost/ctxsjOc | locak^ttascpsjA	focafriost?ctxs_sql
Рис. 12 Настройка прав
доступа для каталога
Clients
Рис. 13 Присвоение прав
доступа группе «Domain
Users».
localhost?'ctxs_dc | localhost/ctxs_cps_pft	localhost,'ctxs_sql
520
Лабораторная работа № 8
Порядок выполнения работы
Вариант 1. Сквозная аутентификация со смарт-картой
Для включения аутентификации с помощью смарт-карты надо выполнить следую-
щие действия:
1.	После включения виртуальных машин осуществляем вход в систему на компьютер
CTXS-SQL, используя учетную запись Administrator. Нажимаем «Start» «Run» и в от-
крывшемся окне набираем \\ctxs-cps\Eval Resources\Clients. Из списка возможных под-
каталогов открываем «Citrix ICA Windows Clients». В открывшейся папке выбираем файл
«ICA32PKG.MSI» и копируем этот файл на локальный компьютер в каталог
«C:\Clients\».
2.	Запускаем файл «ica32pkg.msi» на исполнение. Во время установки Клиентского
ПО для Win32 на запрос «Would you like to enable and automatically use your local user name
and password for Citrix sessions from this client?» необходимо ответить YES (рис. 14).
3.	Отредактируйте файл Appsrv.ini, расположенный в «C:\Program Files\Citrix\ICA
Client» (рис. 15). В секции [WFClient], добавьте следующие строки:
EnableSSOnThruICAFile=On
SSOnUserSetting=On
Рис. 14 Установка клиента ICA
19-5680
521
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
CJ Console Manager - Virtual Machine Renwtv Control Client Plus
Media Control Display Settings Special Help

| localhost/ctxs_sql localhost ctxs_dc	localhost/ctxs_cps_plt
C:\Program Files\Cii rtx\TCA Client
Recycle BH
File Edit View Favorites Tools Help
I Search Folders
Security
Configurati.
Address | C:\Program Files\Citrix\ICA Client
Name ж	|	Size | Type
. У ache
^□Configuration ge Edit Format View Help
C appsrv.ini - Notepad
Citrix Eval
Resources
^resource
2jacrdlg.dll
adpcm.dll
jppsrv.ini
@| appsrv.src
Я audcvtN.dll
SSLProxyHost=*:443
SSLNOCACertS=0
SSLCiphers=ALL
pnqui ck LaunchEnabled=Yes
pnquick Launchvi s1 ble=yes
customconnect 1 ons I conoff *=off
/ X
Citrix Progra
Neighborho.-
CgpCore.dll
jjconcentr.dll
confmgr.dll
EnablessonThr uicafI1e=on
ssonusersetti ng=on

Рис. 15 Настройка клиентской машины
4.	Выполните вход на сервер CTXS-CPS под учетной записью пользователя
Administrator. Убедитесь, что задействована служба Windows Directory Service Mapper.
По умолчанию она выключена в IIS. Для включения этой службы, необходимо запустить
ММС оснастку Internet Information Services (IIS) Manager, для этого, выполните: «Start»
«All Programs» -> «Administrative Tools» «Internet Information Services (IIS) Manager».
В открывшейся оснастке, перейдите к узлу «Web Sites» и установив на нем курсор, наж-
мите правую кнопку мыши и в выпашем меню выберите раздел «Properties». Перейдите
на вкладку «Directory Security» и включаем службу Windows Directory Service Mapper.
Для завершения этого этапа, нажимаем кнопку «Apply» и «ОК» (рис. 16).
5.	Теперь необходимо установить следующие параметры для Виртуального Каталога
11S 6.0:
•	Require secure channel (SSL);
•	Ignore client certificate;
•	Enable client certificates.
Для этого в открытой оснастке Internet Information Services (IIS) Manager раскрываем
узел Web Sites, устанавливаем курсор на Default Web Site, нажимаем правую кнопку мы-
ши и в выпавшем меню выбираем пункт «Properties». Далее переходим на закладку
-522
Лабораторная работа № 8
Рис. 16. Включение службы Windows directory service mapper
«Directory Security» и в секции «Secure Communications» нажимаем кнопку «Edit»
В открывшемся окне устанавливаем параметры, в соответствии со снимком экрана
(рис. 17).
После установки параметров и нажатия кнопки ОК, мы возвращаемся на предыду-
щий экран, где мы должны сделать следующие операции:
1)	нажимаем кнопку Apply;
2)	нажимаем кнопку Select All;
3)	для завершения настройки нажимаем ОК (рис. 18).
6. Теперь необходимо выполнить работы по настройке Citrix XenApp.
Для включения аутентификации по смарткартам, откройте консоль управления
Access Management Console, для этого выполните: «Start» «АН Programs» «Citrix» ->
«Management Consoles» «Access Management Console» (рис. 19).
В открывшейся консоли раскрываем узел «Citrix Resources» -» «Configuration Tools» ->
«Web Interface» -» «Web Access Site» и в средней части экрана в разделе Common Tasks
выбираем Configure authentication methods» и в открывшемся окне включаем
Pass-through with smart card (рис. 20).
На этом шаге вариант № 1 лабораторной работы закончен. Пользователи получили
возможность использовать сквозную аутентификацию по смарт-картам.
523
ЧАСТЫН ЛАБОРАТОРНЫЕ РАБОТЫ
Г । л	। - Virtual M hirt^Rc	F.ntPkfo
Media Control Display Settings Special Meip
________________
localhost'ctxs_dc	locaSiost ctxsjsc? | localhost/ctxs_cps_pft
Г Internet Inform .4ion si r
ииа|ДГ.И|Ггг1^»—1т » -	.
rl File Action yiew Window
о !__!? M? !=>
Internet Information Services
Й ф CTX5-CP5 (local computer)
IS _J Application Pools
FJ J Web Sites______________
l+l U Default Web Site 
E fQ Wirosoft SharePoi
i+f Web Service Extensior
Web Site ] Performance | ISAPI Filters | Home Directory ] Documei
Directory Security | HTTP Headers | Custom Errors | ASP.NET ] Server Extensions«
Authentication and < access control
Enable anonymous access and edit the
authentication methods for this resource.
IP address and domem name restrictions
jQi Grant or deny access to this resource using
уУ IP addresses or Internet domain names.
Рис. 17. Установка
параметров Secure
Communications для
метакаталога Default
Web Sites
Рис. 18. Завершение
настройки метакаталога
Default Web Sites
-524
Лабораторная работа № 8
$ CD/DVO: No Meaia	Floppy: No Media
Рис. 19. Запуск консоли управления
Metfa Con.--» Oispley
Г II 1 М > о « J	_ (
fccatKaizctx»_sql (ocdhost/cbcs_dc | с calnost ±cs_cpe_pK
’ < • ftrtx Ac«ss Mahagfcftwt Cuusole
file Action ytew He*p
Ф -• © ЕВ | $ ®
Citrix Access Management Console
* Alerts
J Search Results
, S My views
Report Center
Licensing
Fi ' * Gtnx Resources
- r Configuration Tools
A Web interface
Common Tasks
Change rfisplay
Web Access Site	Cl
S Information
Я Configure Authentication Methods - Web Access Site
n Hotfix Management
Ijj И Access Gatewa'
Й 0 Presentation Server
| wwc
I—A, Administrators
Й Applications
Й J . Servers
» CTXS-CPS
Manage server farms_____________
| Configure authentication methods ]
Customce appearance for user
Manage secure cient access	i
Manage application types and
cbent deployment
Edit client-side proxy
Manage session preferences
Speciy how useis authenticate when loggng on to the Web Interface.
Avriabte methods-
IQ Smart card
IО Anonymous
Eroperties...
Other Tasks
Manage workspace control
Manaoe access method
OK | Cancel |

Рис. 20. Включение сквозной аутентификации по смарт-картам
525
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
localhost ctxs_dc | localhost ctxs_cps_plt
Г Internet	Web we frropriHe*
Efe Action
- |
Internet Info
В ф CTX5-CP*
B i Арр»
EJ _J Web
j Web
Web Site I Performance j ISAPI Fitters j Home Director*,' | Documents |
Directory Security | HTTPHeakr | GjsiomD | ASP.Ntl | Server Extensions 2002 |
Authentication and access control
Enable anonymous access and edit the
authentication methods for this resource.
Edit.
~IP address and domain name restrict!
® Grant or deny access to this resource using
IP addresses or Internet domain names
Edit...
Secue communications
Secure Communications
I** fteauire secure channel (SSL);
F Require 128-brt encryption
Client certificates
<2 Ignore cfent certificates
Рис. 21. Установка
параметров Secure
Communications
для метакаталога
Default Web Sites
P Enable cfent certificate mapping
Cfent certificates can be mapped to Windows user
accounts. This allows access control to resources using
cfent certificates.
Рис. 22. Завершение
настройки метакаталога
Default Web Sites
-526
Лабораторная работа Ns 8
Вариант 2. Несквозная аутентификация со смарт-картой
Второй вариант лабораторной работы до шага 5 аналогичен варианту 1.
5.	Для настройки стандартной аутентификации по смарт-картам (не сквозная аутен-
тификация по смарт-картам) должны быть установлены следующие параметры вирту-
ального каталога MetaFrame:
•	Require secure channel (SSL);
•	Accept client certificate;
•	Enable client certificates.
Для этого в открытой оснастке Internet Information Services (IIS) Manager раскрываем
узел Web Sites, устанавливаем курсор на Default Web Site, нажимаем правую кнопку мы-
ши и в выпавшем меню выбираем пункт «Properties». Далее переходим на закладку
«Directory Security» и в секции «Secure Communications» нажимаем кнопку «Edit». В от-
крывшемся окне устанавливаем параметры, в соответствии со снимком экрана (рис. 21).
После установки параметров и нажатия кнопки ОК мы возвращаемся на предыдущий
экран, где мы должны сделать следующие операции:
1)	нажимаем кнопку Apply;
2)	нажимаем кнопку Select All;
3)	для завершения настройки нажимаем ОК (рис. 22).
Пункт 6, выполняется аналогично Варианту № 1.
После выполнения пункта 6, вариант 2 Лабораторной работы закончен.
Примечание: При использовании стандартной аутентификации по смарт-кар-
там доступ к Web Interface URL будет приводить к запросу пользователя о необхо-
димости выбора используемого сертификата, а также ввода PIN-кода.
Дополнительная информация
При использовании аутентификации по смарт-картам необходимо, чтобы сервер Web
Interface мог получить обновление списка отозванных сертификатов (CRL). Если это
требование не выполняется, то пользователь получит сообщение об ошибке при доступе
к сайту Web Interface:
«HTTP 403.13 Forbidden: Client certificate revoked».
Для обходного решения этой проблемы необходимо загружать CRL с точки распро-
странения сертификатов на ежедневной/еженедельной основе. Для получения дополни-
тельной информации обратитесь на сайт компании Microsoft:
http://support.microsoft.com/kb/884115/en-us.
Известные ограничения:
•	Необходимо, чтобы сервер Web Interface был членом домена Active Directory
и имел возможность взаимодействовать с контролером домена.
•	Аутентификация по смарт-картам невозможна при использовании Secure Gateway
в качестве обратного прокси, прерывающего SSL для Web Inteface Пользователи
должны иметь прямое соединение с SSL портом IIS.
•	Недоступно для Web Interface для UNIX.
•	Недоступно для доменов NT 4.
Отчет представляется с тиутульным листом установленной формы.
527
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Контрольные вопросы
1.	Объясните различие между стандартной аутентификацией по смарт-картам и сквоз-
ной аутентификацией по смарт-карте.
2.	Какие ограничения применяются при настройке аутентификации по смарт-картам?
3.	Возможно ли использование USB-ключей eToken вместо смарт-карты?
4.	Какой метод аутентификации должен использоваться для доступа к приложениям,
требующим различные сертификаты пользователя?
5.	Для чего необходимо вводить PIN-код?
6.	Пользователь, жалуется системному администратору на то, что система постоянно
требует от него ввода PIN-кода при запуске опубликованного приложения. Как ад-
министратор может исправить ситуацию?
7.	Где хранится открытый ключ? Где хранится закрытый ключ пользователя?
8.	При доступе к Web Interface пользователь получает ошибку доступа и сообщение о
том, что сертификат пользователя отозван. Администратор проверил сертификат
пользователя и убедился, что он действует. Что должен еще проверить админист-
ратор?
9.	Администратор рабочей группы настраивает доступ к Web Interface с использова-
нием смарт-карт. Система не аутентифицирует пользователей, в чем причина?
10.	Пользователь обращается к Web Interface для доступа к опубликованным приложе-
ниям и не получает доступа. Администратор обнаружил в журнале системы ошибку
HTTP 403.13 Forbidden. Администратор проверил успешность соединения между
сервером Web Interface и точкой распространения сертификатов. Чем еще может
быть вызвана проблема отказа в доступе к ресурсам?
11.	Какие еще возможны варианты двухфакторной аутентификации при доступе к
Citrix Web Interface.
12.	Какой шаблон сертификатов должен быть использован для того, чтобы пользова-
тель мог получить доступ к системе, используя смарт-карту?
13.	Кроме сертификата пользователя, какие еще сертификаты могут быть использова-
ны при доступе к Citrix Web Interface? Чем они различаются?
Лабораторная работа Ns 8
Приложение А
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
НАСТРОЙКА WEB INTERFACE 4.Х
ДЛЯ ИСПОЛЬЗОВАНИЯ СМАРТ-КАРТ
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
Выполнили:
Студенты гр.________________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
529
Лабораторная работа № 9
НАСТРОЙКА SECURE GATEWAY
ДЛЯ БЕЗОПАСНОГО ПОДКЛЮЧЕНИЯ
К ОПУБЛИКОВАННЫМ ПРИЛОЖЕНИЯМ
ИЗ НЕДОВЕРЕННЫХ СРЕД ПЕРЕДАЧИ ДАННЫХ
Цель работы
Изучение возможности использования дополнительного компонента Secure Gateway
для безопасного подключения к ферме Citrix XenApp. Получение навыков работ по ус-
тановке и настройке Citrix Secure Gateway. Проверка того, что при подключении и ра-
боте с опубликованными приложениями используется только один порт.
Общие сведения
Secure Gateway помогает обеспечить безопасный доступ к компьютерам с ПО Citrix
XenApp. Этот шлюз прозрачно осуществляет шифрование и аутентификацию соедине-
ний всех пользователей для защиты данных от подделки и кражи.
В настоящее время увеличивается число предприятий, которые активно используют
глобальные каналы связи для подключения к своим филиалам, организации доступа для
мобильных сотрудников и партнеров. Однако высокая стоимость организации и обслу-
живания выделенных каналов приводит к тому, что используются экономически эффек-
тивные открытые сети передачи данных, такие как Интернет. Но любая организация по-
лагающаяся на Интернет для обеспечения соединения своих подразделений, должна
быть готова к решению с серьезных проблем обеспечения безопасности. Несмотря на
энтузиазм, связанный с возможностью получения доступа в любое время, из любого
места, используя любое устройство, корпорация должна быть уверена, что конфиден-
циальные данные, передаваемые по открытым сетям, будут защищены от чужих глаз.
Secure Gateway облегчает прохождение межсетевых экранов и представляет собой
безопасный Интернет-шлюз между Citrix XenApp и клиентскими устройствами. Все дан-
ные, передаваемые через Интернет между удаленной рабочей станцией и Secure Gateway,
шифруются с помощью протоколов Secure Sockets Layer (SSL) или Transport Layer
Security (TLS).
Сервер c Secure Gateway рекомендуется устанавливать в демилитаризованной зоне
(DMZ) для формирования защищенного периметра вокруг компонентов Citrix в корпо-
ративной сети. Secure Gateway аутентифицирует пользователей, подключающихся через
Интернет и формирует безопасный канал обмена данными между клиентским устрой-
ством и Citrix XenApp.
Secure Gateway — это приложение, выполняющееся как сервис на сервере размещен-
ном в DMZ. Этот сервер представляет собой единую точку доступа к защищенной кор-
поративной сети. Таким образом, Secure Gateway выступает в роли посредника для всех
соединений, запрашивающих подключение к корпоративной сети из Интернета.
Для повышения безопасности можно построить решение из двух демилитаризован-
ных зон: во внешней будет располагаться Citrix Secure Gateway, а во внутренней — Citrix
Secure Gateway Proxy. Secure Gateway Proxy выступает в роли изолирующего элемента
530
j lauufja i ирная раоота /vp у
трафика, направленного от Secure Gateway к серверам, расположенным в за-
данной зоне сети и для трафика, идущего в обратном направлении.
В корпоративной сети может быть установлено один или несколько серверов с Citrix
Арр. Такая группа серверов, называемая фермой, используется для размещений
бликованных ресурсов, к которым пользователи получают доступ по сети.
Secure Gateway взаимодействует со следующими компонентами Citrix ХепАрр для
ведения процедур аутентификации и входа:
Citrix Web Interface. Обеспечивает доступ пользователей, использующих Интер-
-браузер к опубликованным ресурсам на ферме серверов Citrix ХепАрр. Web Interface
этает совместно с Secure Gateway для предоставления интерфейса входа в систему и
собствует аутентификации и авторизации запросов на подключение к ферме серверов.
Secure Ticket Authority (STA). Задачей STA является выдача сессионных билетов в от-
на запрос на подключение к опубликованным ресурсам на Citrix ХепАрр. Эти билеты
яются основой процессов аутентификации и авторизации для доступа к опублико-
ным ресурсам. Во время установки Citrix ХепАрр 4.5 служба STA устанавливается ав-
атически. В отличие от предыдущих версий, здесь нет необходимости выделять от-
ьный сервер для установки STA.
Служба Citrix XML. Когда Secure Gateway обеспечивает безопасный доступ к опуб-
ованным на ферме серверов ресурсам, служба Citrix XML отвечает за информацию
)ступности и расположении опубликованных ресурсов. Для своей работы вместо про-
ола UDP используется протокол TCP, что позволяет осуществлять соединения через
ьшинство межсетевых экранов. По умолчанию порт службы Citrix XML — 80.
Citrix ХепАрр Web Plugin. Клиентское ПО для подключения к Citrix Web Interface/
ix Secure Gateway.
Методические указания
Для проведения работ мы будем использовать набор виртуальных машин, описанный
1бораторной работе № 8.
Помимо 3 машин из лабораторной работы № 8, нам потребуется дополнительная
туальная машина под управлением клиентской ОС. Такую виртуальную машину
кно установить самостоятельно или загрузить VHD-файл с установленной Windows
или Windows Vista с сайта компании Microsoft — http://www.microsoft.com/downloads/
iils.aspx?FamilyID=21EABB90-958F-4B64-B5Fl-73D0A413C8EF&displaylang=en.
эед началом использования этой виртуальной машины необходимо обновить вер-
э «VM Additions» (оптимизированные драйверы для гостевых машин), так как это
гсано в лабораторной работе № 8. Этой машине необходимо задать параметры из
л. 1 и 2.
Также нам понадобится дополнительное программное обеспечение:
— Свободно распространяемая утилита TCPView, предназначенная для контроля
►то в и адресов подключения. Загрузить ее необходимо с сайта компании Microsoft
)://technet.microsoft.com/en-us/sysinternals/bb897437.aspx
— Компонент Citrix Secure Gateway 3.1, обеспечивающий безопасное подключение к
бликованным приложениям. Этот компонент можно загрузить с сайта компании Citrix
)s://www.citrix.com/English/ss/downloads/details.asp?downloadId= 1681216&productld= 186
ure Gateway 3.1 (требуется регистрация).
В результате всех вносимых изменений наш стенд должен соответствовать рис. 1.
531
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
CTXS-CPS
192.168.100.3
Windows Server 2003
Citrix ХепАрр
Сервер лицензий Citrix
Клиенты и агенты Citrix
Citrix Web Interface
TEST
192.168.100.10
Windows XP
ПК не включенный в домен.
Утилита TCPView
CTXS-DC
192.168.100.1
Windows Server 2003
Контроллер домена
Служба сертификатов
Два сетевых интерфейса
Служба маршрутизации
DHCP
К физическому
адаптеру
Виртуальная
внутренняя сеть
CTXS-SQL
192.168.100.2
Windows Server 2003
Secure Gateway
Дополнительные
компоненты Citrix
Описание стенда
Рис. 1. Схема стенда виртуальных машин
Описание стенда
Таблица 1
Установленное ПО и аппаратные характеристики виртуальных машин
Параметр	Описание
CTXS-DC	
«Гостевая» операционная система	• Windows 2003 Server Enterprise Edition SP2
Объем оперативной памяти	•	512 Мбайт (по умолчанию) •	Можно уменьшить до 256 Мбайт в случае ограниченного объема оперативной памяти на хост-машине
Сетевые карты	•	1 — для внутренней сети •	1 — привязанна к физическому адаптеру, для подключения извне
Роль	•	Контроллер домена WWC.COM •	Сервер сертификатов •	Маршрутизация во внешнюю сеть •	DNS-сервер •	Почтовый сервер (POP3, SMTP) •	Файл-сервер •	Сервер приложений
532
Лабораторная работа № 9
Окончание табл. 1
Параметр	Описание
CTXS-SQL	
«Гостевая» операционная система	• Windows 2003 Server Enterprise Edition SP2
Дополнительное ПО	•	Citrix Secure Gateway 3.1 •	MS SQL Server 2005 Enterprise Edition •	Citrix Edge Sight •	Citrix SmartAuditor •	Citrix Password Manager
Объем оперативной памяти	•	1024 Мбайт (по умолчанию) •	Можно уменьшить до 512 Мбайт в случае ограниченного объема оперативной памяти на хост машине
Сетевые карты	• 1 — для внутренней сети
Роль	•	Сервер Secure Gateway •	Сервер баз данных для продуктов Citrix •	Хранилище учётных записей для использования Citrix Password Manager •	Компьютер для подготовки потоково-доставляемого ПО (Профайлер) •	Консоль мониторинга производительности •	Сервер и консоль для видеологирования терминальных сессий (SmartAuditor) •	Файл-сервер •	Сервер приложений
CTXS-CPS	
«Гостевая» операционная система	• Windows 2003 Server Enterprise Edition SP2
Дополнительное ПО	•	Citrix XenApp 4.5 c Feature Pack 1 и Hotfix Rollup Pack 2 •	Агенты Citrix Password Manager, Citrix EdgeSight, Citrix SmartAuditor
Объем оперативной памяти	•	1024 Мбайт (по умолчанию) •	Можно уменьшить до 512 Мбайт в случае ограниченного объема оперативной памяти на хост машине
Сетевые карты	• 1 — для внутренней сети
Роль	•	Сервер приложений •	Файл-сервер •	Терминальный сервер •	Сервер лицензий Citrix •	Web сервер для доступа к опубликованным приложениям
TEST	
«Гостевая» операционная система	• Windows ХР Professional Edition SP2
Дополнительное ПО	•	Утилита TCPView •	Клиенты для подключения к Citrix XenApp
Объем оперативной памяти	• 128 Мбайт
Сетевые карты	• 1 — для внутренней сети
Роль	• Клиентский компьютер, не входящий в состав домена WWC
533
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Таблица 2
Используемые учетные записи и пароли пользователей
Пользователь	Пароль	Описание
WWC\Administrator	Evaluation 1	Администратор домена WWC.COM и Citrix ХепАрр
TEST\Test_user	—	Тестовая учётная запись на компьютере TEST
Задание
Организовать доступ для пользователей, получающих доступ к опубликованным при-
ложениям, извне с помощью механизма безопасного подключения.
Подготовка к работе
Для приведения виртуального стенда к рабочему виду после первой лабораторной ра-
боты необходимо запустить каждую машину (CTXS-DC, CTXS-CPS и CTXS-SQL) на-
шего виртуального стенда. Для этого устанавливаем курсор на запись, соответствующую
машине, которую мы хотим включить и, нажав правую клавишу мыши, из появившегося
контекстного меню выбираем Turn On.
Для подключения к консоли виртуальной машины опять нажимаем правую кнопку
мыши, предварительно выбрав нужную включенную виртуальную машину, из контек-
стного меню выбираем VM Console.
После загрузки машины и подключения к виртуальной консоли, нам для каждой вир-
туальной машины, необходимо выполнить сброс Undo-диска (рис. 2).
Когда вы завершите возврат стенда в первоначальное состояние, снова включаем все
четыре виртуальные машины в следующем порядке — CTXS-DC, CTXS-SQL,
CTXS-CPS, TEST. Рекомендуется включать следующую машину после окончания за-
грузки предыдущей.
В виртуальную машину под управлением Windows ХР нам необходимо установить до-
полнительное ПО — утилиту TCPView. С сайта компании Microsoft загружаем утилиту
в виде архивного файла. Переносим этот файл на компьютер TEST, распаковываем его
в подходящий каталог.
Г Console Manager - Virtual Machine Remote Control Client Plus
Media Control | [>splay gettings Special H?j?
= H 11 Pause	b IСЛ jrl | & Cl El_______________________________
localhost Undo Options > | save State and Keep Undo Disks
__ g Reset	1 save State and Commit Undo Disks
<	j JEIl TurnCft . irtjal Ma ±me and Keep Undo Disis
 I	Turn Oft . irKa! Machine and Commit Undo Disks
b 11	Ife Turn -ft b*adnne and Discai d Undo Disks
Рис. 2 Сброс Undo-диска и возврат к первоначальному состоянию виртуального стенда
.534
Лабораторная работа № 9
Порядок выполнения работы
Вначале необходимо проверить, какие порты используются при стандартном под-
ключении через Web Interface. Для этого выполняем вход с учетной записью test_user на
виртуальную машину TEST, где у нас установлена утилита TCPView.
Устанавливаем клиентское ПО Citrix с сервера CTXS-CPS.
1. Нажимаем «Start» -> «Run» и в открывшемся окне набираем \\ctxs-cps\Eval
Resources\Clients. При запросе учетных данных вводим логин и пароль пользователя
Administrator. Из списка возможных подкаталогов открываем «Citrix ICA Windows
Clients» В открывшейся папке выбираем файл «ICA32PKG.MSI» и копируем этот файл
на локальный компьютер в каталог «C:\Clients\».
2. Запускаем файл «ica32pkg.msi» на исполнение. Установка проходит с параметрами
по умолчанию.
Запускаем Интернет Обозреватель, осуществляем подключение к Citrix ХепАрр и за-
пускаем любое опубликованное приложение, например Notepad.
Затем запускаем утилиту TCPView и с ее помощью контролируем порт по которому
произошло подключение к серверу CTXS-CPS (рис. 3).
Так как у нас включена опция Session Reliability, то мы видим, что используется порт
2598. Если мы отключим эту опцию, то подключение будет происходить по порту 1494.
Таким образом, при подключении к опубликованным приложениям нам придется
открывать в межсетевых экранах дополнительные порты. Первоначальное обращение к
серверу Web Interface проходит по 80 или 443 порту, но для дальнейшей работы с при-
ложением задействуются дополнительные порты.
Установка и настройка Citrix Secure Gateway.
Используя доменную учетную запись Administrator, выполняем вход на компьютер
CTXS-SQL, на который мы будем устанавливать Citrix Secure Gateway.
localhost ctxs_dc localhost ctxs_sql । localhost/test localhost/ctxs_cps_plt
5 Пл<Гфг м  I lr
>ra Вид Избранное Се
iktariwte: www.by*im«rnAls сип
Cptiort	Help
Файл
Адре<. http://ctxs-cps/Citrix/Web/site/def:
j---------------------i----------------
CITRIX Web Ii
Process
Z3 alg.exe:1916
ZJ svchost.exe:792
ZJ System 4
Z3 System-4
Z3 [System Process]: 0
Protocol Local Address
TCP
TCP
TCP
TCP
TCP
test: 1026
test:epmap
test:microsoft-ds
te$t:netbios-ssn
test: 1065
Верхний уровень • Вверх
Microsoft
Outlook
Express
Remote...
test:O
test:O
test:O
te$t:O
sergeykh:netbios- TIME_WAIT
State
LISTENING
LISTENING
LISTENING
LISTENING
Приложения ф
lEXPLUHE.EKE:!...
Isass exe:568
*<ica3i cxe:14 CP
-st:10
ctxs .» £25**.
ESTABLISHED
UDP
testisakmp
Document - WordPad
Microsof
WordPac
File Edit View Insert Format Help
v] | 10	|Western
Arial

1

2
3
Выход I
Рис. 3. Контроль используемого при работе с опубликованными приложениями порта
535
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 4. Начальный экран установки Citrix Secure Gateway 3.1
С сайта компании Citrix, по вышеприведенной ссылке мы загружаем Citrix Secure
Gateway 3.1. Запускаем процедуру установки (рис. 4):
На этом этапе нажимаем кнопку Next и переходим к следующему экрану с лицен-
зионным соглашением (рис. 5).
Рис. 5. Экран лицензионного соглашения
536
Лабораторная работа № 9
Рис. 6. Выбор варианта установки
Для продолжения дальнейшей установки вам необходимо согласиться с лицензион-
ным соглашением и нажать кнопку Next (рис. 6).
Так как на нашем стенде виртуальных машин мы устанавливаем Secure Gateway в ло-
кальной сети, то нам для продолжения работы необходимо выбрать режим установки —
Secure Gateway (рис. 7).
Рис. 7. Выбор каталога для установки Secure Gateway
537
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 8. Выбор учетной записи, под которой будет работать Secure Gateway
Соглашаемся с каталогом по умолчанию и нажимаем кнопку Next для перехода к сле-
дующему экрану (рис. 8).
На этом экране предлагается выбрать учетную запись под которой будет выполняться
Citrix Secure Gateway. Согласно рекомендациям по построению безопасных систем ре-
комендуется выбрать не привилегированную учетную запись, такую как NETWORK
SERVICE (рис. 9).
Secure Gateway 3.1 Setup
Ready to Install the Secure Gateway.
Click Next to begin the installation.
JCJXll
CiTRJX
Verify that the information shown below is correct
Installation type : New
Installation option : Gateway
Location • CAProgram FilesXCitrixXSecure GatewayX
Components : Secure Gateway
Service account NT AUTHORITYXNETWORK SERVICE
< Back	|Г	"" Cancel |
Рис. 9. Экран проверки значений, необходимых для установки
538
Лабораторная работа № 9
Рис. 10. Завершение процесса установки Citrix Secure Gateway
На открывшемся экране, прежде чем приступить к процедуре установки, система
предлагает проверить введенные параметры, чтобы при необходимости их можно было
скорректировать. Если вся информация верна, нажимаем кнопку Next (рис. 10).
После завершения процесса установки система предложит осуществить настройку
сервиса до запуска Secure Gateway (рис. 11).
После нажатия на кнопку ОК, запустится мастер, первым экраном которого будет
информационное сообщение о назначении данного конфигуратора. Нажав на кнопку
Next, вы перейдете к следующему экрану (рис. 12).
На открывшемся экране Вам будет предложено выбрать один из двух режимов на-
стройки. Для полной настройки службы выбираем режим Advanced и нажимаем кнопку
Next (рис. 13).
Выбираем имеющийся на сервере сертификат для Полного имени сервера (FQDN) —
ctxs-sql.wwc.com. Именно по этому имени в дальнейшем мы будем подключаться к сер-
jj? Launch Secure Gateway i onfiguration Wizard
i J j The Secure Gateway must be configured before it can be started.
Click OK to launch the Secure Gateway Configuration wizard.

CTXS-SQL
Рис. 11. Экран начального запуска настройки службы Citrix Secure Gateway
539
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 12. Выбор режима настройки
веру Secure Gateway. На следующем экране необходимо выбрать протокол безопасности
(рис. 14).
На этом экране выбираем протоколы SSLv3 и TLSvl, из пакетов шифрования выби-
раем оба пакета (All). Для варианта GOV, будут доступны алгоритмы шифрования, сов-
Рис. 13. Выбор сертификата сервера
540
Лабораторная работа № 9
Рис. 14. Выбор протокола безопасности и пакетов шифрования
местимые со стандартом FIPS-140, а для СОМ будет доступно коммерческое шифрова-
ние (RSA с RC4 128 MD5 или RSA с RC4 128 SHA) (рис. 15).
В открывшемся окне необходимо указать, какой интерфейс будет использоваться для
работы Secure Gateway. Также необходимо указать, на каком порту будет отвечать на за-
1. Установка интерфейса и порта обслуживаемого сервисом Secure Gateway
541
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Рис. 16. Настройка ограничений на исходящий трафик
просы этот сервис. Так как на компьютере CTXS-SQL порт 443 уже обслуживает другое
приложение на Internet Information Service, мы указываем другой порт, например, 8443.
В открывшемся экране можно настроить ограничения на исходящий трафик. В дан-
ной лабораторной работе этот функционал не используется, поэтому выбираем «No
outbound traffic restrictions» (рис. 16).
В открывшемся окне добавляем сервер STA (рис. 17). Для этого нажимаем кнопку
Add и во вновь открывшемся окна заполняем поле FQDN. Служба STA располагается
на сервере Citrix ХепАрр, соответственно в данное поле мы вводим
CTXS-CPS.WWC.COM. Здесь также можно настроить шифрование трафика между
STA-службой и сервером Secure Gateway. Так как оба сервера располагаются в рамках
локальной сети, мы не включаем шифрование. Нажимаем нопку ОК и затем Next.
На двух следующих экранах соглашаемся со значениями по умолчанию и попадаем
на экран настройки соединения с Web Interface (рис. 18).
Так как мы хотим, чтобы пользователь для доступа к опубликованным приложениям
указывал адрес Secure Gateway, то мы указываем режим доступа Indirect. В связи с тем,
что сервис Web Interface располагается на другом по отношению к сервису Secure
Gateway физическом сервере, то очищаем чекбокс Installed on this computer.
В поле FQDNyKa3biBaeM полное DNS имя сервера — CTXS-CPS.WWC.COM.
542
Лабораторная работа № 9
secure G»t vm ,v ।	.1
|Secure Gateway Configuration wizard
Details of the server running the Secure Ticket Authority
(STA)
Click Add to enter the details of the server(s) running the
Configuring multiple STAs provide failover
Secure Ticket Authority (STA) details
P Use default
Protocol settings
r— Secure traffic between the STA and the
Secure Gateway
TCP port: [go
EQDN | ctxs-cps.wwc.com
| /Scripts/CtxSTA.dll
ID:	|
ervers running the STA---------
dentifier	FQDN
Add... I Modif ... | DePe
< Back
Рис. 17. Настройка
соединения
с STA-сервером
Cancel
Рис. 18. Настройки
соединения с сервером
Web Interface

543
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
На последнем экране настройки необходимо указать глубину легирования событий
на сервере Secure Gateway. Соглашаемся с принятым по умолчанию уровнем и на сле-
дующем экране соглашаемся с запуском настроенной службы Secure gateway (рис. 19).
Прежде чем перейти к настройке службы Web Interface на сервере CTXS-CPS, необ-
ходимо проверить работоспособность нашей конфигурации.
Для этого запускаем утилиту Secure Gateway Diagnostics (рис. 20).
loesfrx5«/ctx3_dc J'>catnM/ctxj_»ql focabosMest iocahost ch» _rps.pl
Rec deb.
1 My Computer
Window* Explore»
SmartAudRor Server
'	. Activate UWcws
r Secure Gatewa*	’**xk>ws Catalog
Windows Qpdate
Termnal Server --j Accessories
Q AdmimstrativeTnefc
Q» Control Panel
4 j Admewdbve Tools
Printers and Faxes
TXS-SQL
tree Ecit'cn Service- Pack 2 Яийс
_______________________________Access Gateway
SQL Server Mar ~Microsoft SQL Server 2005	►	Management Consoles
‘X'Studo ГЗ Microsoft Visual Studio 2005 a	Password Manager
SQL Server Cor
Manager 4? Internet Epforer
(jJ Outfock Express
k Remote Assistance
Д Streaming Proffer
jQlpgOft EJshrfDown
jgj Secwe Gateway Ccnfiguratton Wttard
Secure Gateway «agrwstfcs
Рис. 20. Запуск утилиты диагностики
544
Лабораторная работа № 9
Рис. 21. Результаты работы утилиты диагностики Secure Gateway
Если наша конфигурация настроена правильно, то в результате работы мы должны
увидеть следующее (рис. 21).
После подтверждения, что Secure Gateway на сервере CTXS-SQL настроен коррект-
но, используя доменную учетную запись Administrator, переключаемся в консоли вир-
туальных машин на сервер CTXS-CPS, где установлен сервис Web Interface.
Запускаем утилиту администрирования — Access Management Console и в этой кон-
соли раскрываем узел Web Interface ? Web Access Site (рис. 22).
В средней части экрана находим элемент «Manage secure client access» и, нажав левой
клавишей мыши, выбираем пункт «Edit Gateway Settings» (рис. 23).
В открывшемся окне производим следующие операции:
1.	В поле Address (FQDN) вводим полное DNS-имя сервера, на котором установлена
служба Secure Gateway — CTXS-SQL.WWC.COM.
2.	Указываем порт, по которому будет отвечать эта служба — 8443.
3.	Нажимаем кнопку Add.
E
He Action View Help
tocdhost/d»_dc iocdhost/cbesql {locabost/ctxs_cps_p« tocdhoatlesl
Citnx Access Management Console
” Alerts (1)
J Search Results
, My Views
Repat Center
Licensing
В Citrix Resources
- » Configuration Tods
В Web Interface
Web Access Site
E Information
[	1 Warning
Common Tasks
http://ctxs-cps.wwc.ca
this item
Display settings
Web Access Site
Access Platform
Local file
ASP
ЙИ,
Vkh
tiamez
Type:
Configuration Source:
Technology:
Version:
URL:
Change tfcplay
Manage server farms
Configure authentication
methods
Customize appearance fa user
Manage ow ra rliant access »
Manage application types
and client deployment ’
Edt tent-side proxy
Manage session preferences
Edit DMZ settings
Edit Gateway settings
' i Citrix Access Management Console

©El
J J
My Views Search
Web Access Site
Я А» Agent Service Site
* - Hotfix Management
В И Access Gateway
r L J WV,Z~_AAC
В В Presentation Server
E И WWC
Administrators
ffl App'.ations
Рис. 22. Изменение настроек Web Interface
545
tocdho*/ctu_dc locahMt/cto.ttf | locahost-ctxs.cps j* xahoMAetf
Alerts (i)
Home
Web
Access
Site
My Views
Report Car* -
Э '□ Citrix Resources
P 4 Configuration Tools
В Web interface
Ы AACWebSte
. -eb Access ste
£ L Agent Service Site
I LB Hotfix Management
В Access Gateway
If any _ienr devices access th. «ie imough Jhp Access GaW-ay or Secure Gateway,
specify the Gateway server detail* btf™
’ Address (EQDNI	|ctx$- >1 wwc com
” ]ЭТ3 |
F Enel Tetron гйаЫЙ)
n Presentation Server
S QWWC
Administrators
v 1 Appkabons
Secure Ticxet authorities
Secure Ticket A - , URLs
Brt
4 *j Monitoring Corfigwabon
ЕЭ 40 Password Manager
fflv User Configurations
ffi L Application Defntrons
ffi Password Pofcies
К . Identity Verification
P Ure for toad balancing
fiypaw fated server* far:
There retung* are wih appacobte to remote вррасасюгг
|~ ~ OK Caned |
Рис. 23. Настройка параметров соединения с сервисом Secure Gateway
4. И в открывшемся окне вводим имя сервера, на котором запущена служба STA —
:txs-cps.wwc.com.
После нажатия кнопки ОК остается изменить настройки Citrix XenApp с точки зре-
[ия DMZ. Для этого в средней части экрана, опять находим элемент «Manage secure
lient access» и после нажатия левой клавиши мыши выбираем пункт «Edit DMZ Settings»
рис. 24).
b^ahMtzctxsjfc 4caho</ctx»_»d J boahcrt/ct»_cp» j*	tocahoatlest
He fiction W bdP
4= *♦ ft] ГЗ ®
ГХ Ctrix A: ess “anx:mcnt Creolj
J Alerts
5 Search Results
5 M, Views
5 Report Center
licensing
P * Ctrix Reset»cas
Rtf Configuration Tools
Й u I Web Interface
AACWebSte
WdiAccassSte
& Agent Service Ste
Hotfix Management
В u AC »SS Gatovs'
• □ WWC_AAC
0 Presentation Server
ЧЦ WWC
Administrators
AppCatoni
E 5 Se ers
f)| CTXS-CPS
& • Zones
В Morttomg Configuration
tf> Password Manager
S- User Configurations
3 . ' AppkationDefWbons
S i] Password Pueues
S 'ts Identity Verification
Рис. 24. Изменение настроек DMZ
46
Лабораторная работа № 9
Action
jgl Citrix Ассем Management Console
В Secure client access
ReUr
Otnx»-
J Sea^h Results
*4 My Views
£ Report Center
Common Tasks
Charge rfcpiay
Mm
Рис. 25. Изменение маршрута по умолчанию
E 1V Gtrtx Resources
* Configuration Tools
Web Interface
U AACWebSce
2 Web Access Site
к Agent Service Site
Д Hotfix Management
a (- wwc
jn Administrators
HJ 4 Appicabons
- Servers
• Zones
S Г Morttoring Configuration
|0 Password Manager
iS User tnfigurabons
«- . Appk.aton Definitions
- u Password Poboes
. Identity Verification
My views Search
Web Access Site
CITRIX
ins wraow оводs a> me снеге secure access secongs currency conrrgurea ror me oojecr sereccea in me
amend the date by ckkrrg on the inks wthri ths wndowcr selecting one of the tasks tn th* taskpene.
Speely delate of the DMZ setting» m the tobte below These settings alow IP
addesi, made and access method* to be defined W
Cfent address table (apply entries in order snowO
Ckert IP address ( Mark. I Access method
D-.s
Spedfy the type of route to use# the ctert address does ref
rr etch one c* fl л <d<tiir*1y defned tuiet
NATta«w«l using
as«rnsi« Mdrass
NAT fnw>l using
transferor, map
Nontraruj*iingnt.wd
> NAT hrewil using
b«naM«M**s
NATfiwwNlusIng
tmthCrtr map
3₽*cifi*d btfow
В открывшемся окне необходимо установить курсор на строку «Default»«Direct» и на-
жать кнопкук «Edit» (рис. 25).
Во вновь открытом oioie в выпадающем меню необходимо выбрать значение
«Gateway Direct» и нажать кнопку ОК.
locaihost ctxs_dc localhost/ctxs_sql localhost/ctxs_cps_plt | Io VesT
3 Регистрация в Web Interface - Microsoft Internet Explorer
Файл Правка Вид Избранное Сервис Справка
фнамд » Q	z Поиск избранное
Адрес <1 https://ctxs-sql.wwc. com:8443/Citrix/Web/authflogin.aspx
CITRIX
Web Interface
Добро пожаловать
Зарегистрируйтесь в систег
Для регистрации в системе be
Если вам не известны необход
системному администратору.
Центр сообщений
В Центре сообщений отображг
Рис. 26. Подключение к Citrix Web Interface
547
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
ncaihos! ctxs_dc locafriost/ctcs_sql locdhost ctajcpsjA ] locahostAest
Фаич
жа Вид
ch u . f .left lot* r 6t E>plo<  ••
правка
J Назад
Поиск Игранное X*
Дд₽* . https://ctxs-sql.vw«.com:8443/Citrix/Wd)/ste/default.aspx
ClTRIX Web Interface
Help
Приложения
Process
Z ' 3 System 4
Верхний уровень * Вверх
lJ svehost exe808
Z3 System 4
Protocol Local Addfess Remote Add
TCP
TCP
TCP
Ewtica32 exe:144
testmicrosoft-ds	lest 0
testepmap	test 0
test netbios-ssn	test.0
fl
Microsoft Outlook
Microsoft Word
13 svckdst.exe:^8 UOr
E3 lsass.exe:460 UDP
в IEXPLORE.EXE:! UDP
1е#10б5
7esfntp
test isakmp
fest: 1041
v State
LISTENING
LISTENING
LISTENING
. IISTFNIMG
ESTABLISH
-a2<J
г ле
сля
3H<
Дл=
1М0Г
dHKi
4ИН1
priai
U Document - WordPad
He gjft View Insert Format Help
PJglHl gl&j #| J Ms! si
3 »И и|g>l fa *!! e|।
Рис. 27. Контроль адреса сервера и порта подключения
мог
lauii
npe
5 к ' ' v v **> । ft

U-1
Q A
©
• Л


На этом настройка сервера Web Interface завершена.
Теперь необходимо проверить, как работает наше решение. Для этого, используя
учетную запись test user на компьютере TEST, запускаем Интернет Обозреватель и в
строке адреса набираем https://ctxs-sql.wwc.com:8433/Citrix/Web/auth/login.aspx. Обрати-
те внимание на то, что нам необходимо в явном виде указать порт 8433, так как он от-
личается от значения по умолчанию — 443 (рис. 26).
Используя учетные записи пользователя Administrator домена WWC, подключаемся
к опубликованным приложениям и запускаем приложение WordPad. Для контроля ад-
реса и порта подключения запускаем утилиту TCPView (рис. 27).
Как видно, соединение установлено с сервером CTXS-SQL, на котором запущена
служба Secure Gateway по порту 8443. Это означает, что мы настроили доступ к Citrix
ХепАрр, используя безопасный доступ и можем открыть на межсетевом экране всего
один порт для осуществления такого доступа. В нашем случае это порт 8443.
Контрольные вопросы
1.	Объясните различие между стандартным подключением к серверу Web Interface с
использованием SSL и подключением через Citrix Secure Gateway.
2.	Какие ограничения применяются при настройке Secure Gateway в режиме Direct?
3.	Какие протоколы могут быть использованы для подключения к Secure Gateway?
4.	Как можно защитить соединение между сервером Secure Gateway и сервером Web
Interface?
548
Лабораторная работа № 9
5.	Вы устанавливаете Secure Gateway на сервер, где располагается Web-приложение,
доступ к которому осуществляется по 443 порту. Можно ли установить Secure
Gateway на этот компьютер?
6.	Какие существуют схемы установки Secure Gateway?
7.	Вы планируете предоставить вашим пользователям доступ к приложениям через
Интернет В вашей сети установлен только один межсетевой экран, отделяющий
сеть Интернет от локальной сети Вы осуществляете настройку Citrix Secure Gateway
и вам необходимо сообщить сетевому администратору, какие порты необходимо от-
крыть на внешнем межсетевом экране для осуществления доступа и аутентифика-
ции пользователя. Назовите эти порты.
8.	При установке Secure Gateway на сервер sg.company.ru система сообщила, что не мо-
жет быть установлена с использованием порта 443. Администратор для работы вы-
брал другой порт. Пользователь, подключаясь к серверу Secure Gateway, в Интер-
нет-обозревателе набрал адрес https://sg.company.ru и не получил на экран страницу
авторизации. Почему? Какой адрес должен ввести пользователь информационной
системы?
9.	Объясните назначение службы STA.
10.	Для безопасности корпоративной сети требуется использовать две демилитаризо-
ванные зоны. Каким образом следует расположить серверы для предоставления до-
ступа к опубликованным приложениям через Secure Gateway?
11.	При установке и настройке сервера, использующего службу Secure Gateway, адми-
нистратор сделал этот сервер членом домена. Допустимо ли это? Если нет, то по-
чему?
12.	Secure Gateway может использовать протокол SSL или протокол TLS. В чем состоит
различие между этими двумя протоколами?
13.	В организации используется свой центр выдачи сертификатов. Для сервера Secure
Gateway выдан сертификат на имя сервера sg. При подключении через Интернет,
пользователь сообщает, что у него появляется предупреждение о неверном серти-
фикате. Администратор, подключаясь из локальной сети, с такой ошибкой не стал-
кивается. Как можно решить эту проблему?
14.	Администратор выписал сертификат для сервера Secure Gateway с именем
sg-001.company.ru. При настройке Secure Gateway система приняла этот сертификат.
Компания предоставила доступ к своей информационной системе компани-
ям-партнерам. Партнер подключаясь через Интернет, получает предупреждение о
невозможности проверки сертификата. Почему? Как можно исправить ситуацию?
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Приложение А
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет
систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности
электронно-вычислительных систем (КИБЭВС)
НАСТРОЙКА SECURE GATEWAY
ДЛЯ БЕЗОПАСНОГО ПОДКЛЮЧЕНИЯ
К ОПУБЛИКОВАННЫМ ПРИЛОЖЕНИЯМ
ИЗ НЕДОВЕРЕННЫХ СРЕД ПЕРЕДАЧИ ДАННЫХ
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины
«Безопасность вычислительных сетей»
Выполнили:
Студенты гр.________________________________
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
550
Аутентификация
Теория и практика обеспечения безопасного доступа
к информационным ресурсам
Учебное пособие для вузов
Афанасьев Алексей Алексеевич, Веденьев Леонид Тимофеевич,
Воронцов Алексей Андреевич, Газизова Эльвира Рафаиловна,
Додохов Александр Леонидович, Крячков Антон Викторович,
Полянская Ольга Юрьевна, Сабанов Алексей Геннадьевич,
Скида Максим Александрович, Халяпин Сергей Николаевич
Шелупанов Александр Александрович
Под редакцией
доктора техн, наук, профессора А. А. Полупанова;
генерального директора ЗАО «Аладдин Р. Д.» С. Л. Груздева',
кандидата физ.-мат. наук, старшего научного сотрудника,
руководителя аналитического отдела ЗАО «Аладдин Р. Д.» |7О. С. Нахаева\
Авторский коллектив выражает благодарность за помощь
в подготовке проекта компаниям
Aladdin, Cisco, Citrix, Microsoft, Oracle, Крипто-Про
Aladdin	dnqx-
Microsoft ORACLE
^КРИПТО
Вышли в свет и имеются в продаже:
Горбатов В. С., Полянская О. Ю. Основы техноло-
гии PKL — М.: Горячая линия—Телеком, 2004. —
248 с.: ил., ISBN 5-93517-154-6.
Рассматриваются основы технологии инфраструктур от-
крытых ключей. Даются базовые определения. Анализируются
основные подходы к реализации инфраструктур открытых клю-
чей, описываются архитектура, структуры данных, компоненты
и сервисы PKI. Предлагается классификация стандартов и спе-
цификаций в области инфраструктур открытых ключей. Рассмат-
риваются проблемные ситуации и риски, политика PKI, правовые
аспекты использования технологии PKI. Описываются програм-
мные продукты ведущих мировых и российских компаний-про-
изводителей программного обеспечения для поддержки PKI.
Для студентов и аспирантов высших учебных заведений,
слушателей курсов повышения квалификации, а также для ши-
рокого круга читателей, интересующихся современными про-
блемами информационной безопасности.
Запечников С. В., Милославская Н. Г., Тол-
стой А. И. Основы построения виртуальных частных
сетей. Учебное пособие для вузов. — М.: Горячая ли-
ния-Телеком, 2003. - 249 с., ISBN 5-93517-139-2.
Изложены основы построения виртуальных частных сетей
(VPN). Даны основные определения. Рассмотрена технология
туннелирования в сетях. Подробно анализируются стандарт-
ные протоколы построения VPN и управление криптографичес-
кими ключами в VPN. Выделяются особенности различных ва-
риантов и схем создания VPN. В качестве примеров реализа-
ции VPN приведена информация о различных продуктах
российских предприятий.
Для студентов высших учебных заведений, обучающихся по
специальностям «Компьютерная безопасность» и «Комплексное
обеспечение информационной безопасности автоматизирован-
ных систем», и слушателей курсов повышения квалификации.
Запечников С. В. Криптографические протоколы
и их применение в финансовой и коммерческой
деятельности: Учебное пособие для вузов. —
М.: Горячая линия—Телеком, 2007. — 320 с., ISBN
5-93517-318-2.
В систематизированном виде изложены основы те-
ории криптографических протоколов и практики их приме-
нения в финансовой и коммерческой деятельности. Наряду
с рассмотрением современных методов синтеза и анализа
основных классов криптографических протоколов, основное
внимание уделяется специальным их применениям: защи-
щенным каналам передачи информации, системам электрон-
ных платежей, защищенному электронному документообороту.
Рассматриваются проблемы криптографической защиты
многосторонних транзакций и коммерческих сделок, крип-
тографических методов обеспечения государственно-право-
вых отношений, осуществляемых с использованием техни-
ческих средств компьютерных систем.
Для студентов высших учебных заведений, обучаю-
щихся по специальностям 090102 - «Компьютерная бе-
зопасность» и 090105 - «Комплексное обеспечение ин-
формационной безопасности автоматизированных сис-
тем», аспирантов, слушателей курсов повышения
квалификации, специалистов в области информацион-
ной безопасности.
Информационная безопасность открытых систем:
Учебник для вузов. В 2-х томах. Том 1 — Угрозы,
уязвимости, атаки и подходы к защите / С. В. За-
печников, Н. Г. Милославская, А. И. Толстой,
Д. В. Ушаков. — М.: Горячая линия—Телеком,
2006. - 536 с.: ил., ISBN 5-93517-291-1.
В учебнике рассматриваются основы информационной
безопасности открытых систем на примере интранет. Вводятся
основные определения и понятия. Описываются современные
угрозы, уязвимости базовых составляющих интранет и удален-
ные сетевые атаки на них. Подробно рассматриваются концеп-
туальные подходы к обеспечению информационной безопас-
ности в открытых системах и вопросы разработки политики бе-
зопасности. Анализируются этапы создания комплексной
системы обеспечения информационной безопасности для ин-
транет и сервисы безопасности.
Для студентов высших учебных заведений и слушателей
курсов повышения квалификации.
Рябко Б. Я., Фионов А. Н. Криптографические ме-
тоды защиты информации: Учебное пособие для ву-
зов. — М.: Горячая линия— Телеком, 2005. —
229 с.: ил., ISBN 5-93517-265-8.
Изложены основные подходы и методы современ-
ной криптографии для решения задач, возникающих при обра-
ботке, хранении и передаче информации. Основное внимание
уделено новым направлениям криптографии, связанным
с обеспечением конфиденциальности взаимодействий пользо-
вателей компьютеров и компьютерных сетей. Рассмотрены ос-
новные шифры с открытыми ключами, методы цифровой подписи,
основные криптографические протоколы, блоковые и потоковые
шифры, криптографические хеш-функции, а также редко встре-
чающиеся в литературе вопросы о конструкции доказуемо невс-
крываемых криптосистем и криптографии на эллиптических кри-
вых. Изложение теоретического материала ведется достаточно
строго, но с использованием элементарного математического
аппарата. Подробно описаны алгоритмы, лежащие в основе
криптографических отечественных и международных стандар-
тов. Приведены задачи и упражнения, необходимые при про-
ведении практических занятий и лабораторных работ.
Для студентов, обучающихся по направлению «Теле-
коммуникации», может быть полезна специалистам.
Хорев П. Б. Криптографические интерфейсы и их
использование. — М.: Горячая линия-Телеком,
2007. - 278 с.: ил., ISBN 978-5-93517-331-9.
Рассмотрены основы использования криптографических
интер-фейсов в приложениях операционной системы Windows,
создаваемых на языках программирования Object Pascal
и C++, а также в приложениях для сети Интернет, создаваемых
на языках сценариев JavaScript и VBScript. Изложение матери-
ала сопровождается примерами создания и хранения криптог-
рафических ключей, шифрования и расшифрования файлов
и сообщений, их хеширования, вычисления и проверки элект-
ронной цифровой подписи, работы с сертификатами открытых
ключей и их хранилищами.
Дляразработчиков программных средств защиты инфор-
мации, специалистов, интересующихся современными мето-
дами и средствами криптографической защиты информации
в компьютерных системах, студентов и аспирантов.
Справки по телефону: (495) 737-39-27, WWW.TECHBOOK.Rll

Аутентификация
Теория и практика
обеспечения безопасного доступа
к информационным ресурсам
Книга посвящена одному из аспектов проблемы управления
доступом к информации в компьютерных системах - аутентифи-
кации.
Фактически защита информации начинается с аутентификации
пользователей. Каждый пользователь современных компьютер-
ных систем сталкивается с процедурами аутентификации не-
однократно в течение рабочего дня. Книга описывает достоин-
ства и недостатки практически всех существующих и используе-
мых на настоящий момент способов аутентификации и ориенти-
рована на широкий круг читателей.
Книга адресована студентам вузов и аспирантам, обучающимся
по специальностям, связанным с защитой информации, ИТ-
специалистам и специалистам по информационной безопасно-
сти; специалистам, получающим второе высшее образование в
области защиты информации, и слушателям курсов переподго-
товки.
Aladdin •J.l'co ciTRIX
SECURITY SOLUTIONS	VIWVV.	•
Microsoft ORACL-E фРГУпРО
Сайт издательства:
www.techbook.ru