Аутентификация. Теория и практика-2012

Аутентификация
Теория и практика
обеспечения безопасного доступа
к информационным ресурсам
Рекомендовано Учебно-методическим объединением

по образованию в области информационной безопасности
и одобрено ФСТЭК России
в качестве учебного пособия для студентов высших
учебных заведений, обучающихся по специальностям
«Компьютерная безопасность»,
«Комплексное обеспечение информационной
безопасности автоматизированных систем»
Под редакцией
А. А. Шелупанова, С. Л. Груздева, Ю. С. Нахаева
Москва
Горячая линия - Телеком
2012
УДК 004.732.056(075.8)
ББК 32.973.2-018.2я73
А93
А в т о р ы : А. А. Афанасьев, Л. Т. Веденьев, А. А. Воронцов, Э. Р. Газизова, А. Л.
Додохов, А. В. Крячков, О. Ю. Полянская, А. Г. Сабанов, М. А. Скида, С. Н.
Халяпин, А. А. Шелупанов
А93 Аутентификация. Теория и практика обеспечения безопасного доступа к

информационным ресурсам. Учебное пособие для вузов / А. А. Афанасьев,
Л. Т. Веденьев, А. А. Воронцов и др.; Под ред. А. А. Шелупанова, С. Л.
Груздева, Ю. С. Нахаева. - 2-е изд., стереотип. - М.: Горячая линия-Телеком,
2012. - 550 с.: ил.
ISBN 978-5-9912-0257-2.
Книга посвящена одному из аспектов проблемы управления доступом к
информации в компьютерных системах - аутентификации.
Фактически защита информации начинается с аутентификации пользователей.
Каждый пользователь современных компьютерных систем сталкивается с
процедурами аутентификации неоднократно в течение рабочего дня. Книга
описывает достоинства и недостатки практически всех существующих и ис-
пользуемых на настоящий момент способов аутентификации и ориентирована на
широкий круг читателей.
Книга адресована студентам вузов и аспирантам, обучающимся по специ-
альностям, связанным с защитой информации, ИТ-специалистам и специалистам по
информационной безопасности; специалистам, получающим второе высшее
образование в области защиты информации, и слушателям курсов переподготовки.
ББК 32.973.2-018.2я73
Адрес издательства в Интернет www.techbook.ru
Учебное издание Аутентификация

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

2-е издание, стереотипное
Редактор И. Н. Андреева
Компьютерная верстка Н. В. Дмитриева
Обложка художника В. Г. Ситникова
Подписано в печать 14.03.12. Формат 70x100/16. Усл. печ. л. 45,75. Тираж 100 экз. (1-й завод 50 экз.)
ООО «Научно-техническое издательство «Горячая линия-Телеком»
ISBN 978-5-9912-0257-2 © ЗАО «Аладдин Р.Д.», 2009, 2012

© Издательство «Горячая линия-Телеком», 2012
ОГЛАВЛЕНИЕ
ПРЕДИСЛОВИЕ................................................................................................................................ 7
ЧАСТЬ I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ.........................................................................................9
Глава 1. ОБЩИЕ СВЕДЕНИЯ.................................................................................................. 10
1.1. Основные понятия и определения...................................................................................... 10
1.2. Роль и задачи аутентификации. Место аутентификации
в структуре основных направлений защиты информации........................................ 10
1.3. Факторы аутентификации................................................................................................... 13
Контрольные вопросы......................................................................................................... 15
Глава 2. ПАPОЛЬНАЯ АУТЕНТИФИКАЦИЯ....................................................................... 16
2.1. Аутентификация с помощью запоминаемого пароля....................................................... 16
2.2. Методы парольной аутентификации.................................................................................. 16
2.3. Парольные политики........................................................................................................... 19
2.4. Недостатки методов аутентификации с запоминаемым паролем.................................... 19
Глава 3. АУТЕНТИФИКАЦИЯ С ПОМОЩЬЮ
БИОМЕТPИЧЕСКИХ ХАPАКТЕPИСТИК............................................................................ 23
3.1. Биометрические характеристики.......................................................................................23
3.2. Как работают биометрические системы............................................................................ 24
3.3. Аутентификация и биометрическое распознавание......................................................... 26
3.4. Реализация биометрических систем.................................................................................. 27
3.5. Недостатки аутентификации с помощью биометрических характеристик.
Возможные атаки.......................................................................................................... 28
Глава 4. АУТЕНТИФИКАЦИЯ С ПОМОЩЬЮ
ОДНОPАЗОВЫХ ПАPОЛЕЙ...................................................................................................30
4.1. Аппаратно-программные OTP-токены..............................................................................32
4.2. Как работают OTP-токены..................................................................................................32
4.3. Методы аутентификации с помощью OTP-токенов..........................................................32
4.4. Сравнение методов OTP-аутентификации.........................................................................36
4.5. Системы одноразовых паролей.......................................................................................... 37
4.6. Недостатки методов аутентификации с помощью OTP.
Возможные атаки......................................................................................................... 41
Глава 5. КPИПТОГPАФИЯ С ОТБЫТЫМ КЛЮЧОМ........................................................... 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
Глава 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 PAP................................................................................................................77
7.2. Протокол PPP CHAP............................................................................................................78
7.3. Протокол PPP EAP...............................................................................................................79
7.4. Протокол TACACS+............................................................................................................81
7.5. Протокол RADIUS...............................................................................................................84
7.6. Стандарт IEEE 802.1x и протокол EAPOL.........................................................................86
7.7. Протокол EAP-TLS с использованием российской криптографии..................................89
7.8. Стандарт IEEE 802.1x в операционных системах Microsoft............................................93
7.9. Cisco NAC.............................................................................................................................94
Глава 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. ПРИМЕНЕНИЕ АППАРАТНЫХ СРЕДСТВ АУТЕНТИФИКАЦИИ И
ХPАНЕНИЯ КЛЮЧЕВОЙ ИНФОPМАЦИИ................................................................. 125
9.1. Аппаратные средства защиты в современных PKI-решениях.......................................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
Список использованной литеpатуpы............................................................................................ 153
ЧАСТЬ II. БАНТИКА.....................................................................................................................155

Введение................................................................................................................................... 156
Глава 1. ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ ДОСТУПА К ДАННЫМ И
ПРИЛОЖЕНИЯМ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОРГАНИЗАЦИИ НА ОСНОВЕ
РЕКОМЕНДАЦИЙ И ПРОДУКТОВ MICROSOFT.
ТИПОВЫЕ РЕШЕНИЯ...........................................................................................................157
1.1. Основные сервисы для обеспечения надежной аутентификации
и управления доступом.............................................................................................. 157
1.2. Авторизация при доступе к объекту................................................................................ 169
1.3. Система аудита Active Directory.......................................................................................170
1.4. Назначение и решаемые задачи инфраструктуры открытых ключей...........................172
1.5. Управление идентификацией (ILM).................................................................................173
1.6. Microsoft Identity Integration Server (MIIS)...................................................................... 173
1.7. Системы обеспечения ......................................................................................................175
РЕКОМЕНДАЦИЙ И ПРОДУКТОВ ORACLE И ALADDIN. ТИПОВЫЕ РЕШЕНИЯ....177
2.1. Управление доступом в СУБД Oracle с помощью встроенных механизмов
безопасности и криптографических средств защиты..............................................177
5
ПРОДУКТОВ КОМПАНИИ CITRIX SYSTEMS...........................................................226
3.1. Описание продуктов компании Citrix Systems................................................................226
3.2. Компоненты систем, постpоенных с использованием XenApp.....................................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.m/book/
Согласно замыслу авторов, книга, которую Вы держите в руках, призвана открыть перед
читателем суть и возможности технологии аутентификации, как базового элемента любой
системы информационной безопасности современных компаний.
7
Специалистам, уже знакомым с данными технологиями, книга поможет систематизировать
и расширить свои знания в части прикладного применения средств аутентификации и
интеграции их с другими продуктами и решениями для защиты информации.
Развивать рынок аутентификации, способствовать повышению уровня и качества проектов
в области ИТ-безопасности, а, главное, содействовать формированию четкого понимания
ценности информации в современном мире — основная цель данной книги.
Мы искренне благодарим всех, кто поддерживал и продолжает поддерживать этот проект,
помогает в его продвижении, а также распространении книги.
Особую благодарность выражаем Федеральной службе безопасности России (ФСБ Рос-
сии), Федеральной службе по техническому и экспортному контролю России (ФСТЭК
России), Совету Безопасности Российской Федерации и Учебно-методическому объединению
по образованию в области информационной безопасности за проявленный интерес, полезные
замечания и конструктивную критику.
Отдельно хочется отметить вклад в работу при подготовке рукописи данной книги
безвременно ушедшего из жизни руководителя аналитического отдела компании Aladdin,
кандидата физико-математических наук Нахаева Ю.С.
Мы не планируем останавливаться на достигнутом результате и рассматриваем идею
выпуска второго расширенного издания данной книги. Приглашаем к сотрудничеству всех
заинтересованных специалистов, компании, ВУЗы.
Замечания, предложения и пожелания просьба направлять по адресу:
634050, Томск, пр-т Ленина, д.40

Институт системной интеграции и безопасности ТУСУР, Шелупанову А. А.
saa@udcs.ru
тел. 8 (3822) 413 426
129226 Москва, ул. Докукина, д. 16 корп. 1

ЗАО «Аладдин Р.Д.», генеральному директору Груздеву С. Л.
pr@aladdin.ru
тел. 8 (495) 223 0001
С уважением,
А. А. ШЕЛУПАНОВ,
Директор Института системной интеграции
и безопасности ТУСУР, доктор технических
наук, профессор
С. Л. ГРУЗДЕВ, Генеральный директор
компании Aladdin
ЧАСТЬ I
ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
Глава 1
ОБЩИЕ СВЕДЕНИЯ ОБ АУТЕНТИФИКАЦИИ
1.1. Основные понятия и определения

Процесс регистрации пользователя в любой системе состоит из трех взаимосвязанных
последовательно выполняемых процедур: идентификации, аутентификации и авторизации.
Идентификация — процедура распознавания субъекта по его идентификатору. В процессе
регистрации субъект предъявляет свой идентификатор системе, которая проверяет его наличие
в своей базе данных. Субъекты с известными системе идентификаторами считаются
легальными (законными), остальные относятся к нелегальным.
Аутентификация — процедура проверки подлинности субъекта, которая позволяет
достоверно убедиться в том, что субъект, предъявивший свой идентификатор, на самом деле
является именно тем субъектом, идентификатор которого он использует. Для этого он должен
подтвердить факт обладания некоторой информацией, которая может быть доступна только
ему одному (пароль, ключ и т. п.).
Авторизация — процедура предоставления субъекту определенных прав доступа к ресур-
сам системы после прохождения им процедуры аутентификации. Для каждого субъекта в
системе определяется набор прав, которые он может использовать при обращении к ее
ресурсам.
Для того чтобы обеспечить управление и контроль над данными процедурами, до-
полнительно используются процессы администрирования и аудита.
Администрирование — процесс управления доступом субъектов к ресурсам системы.
Данный процесс включает:
• создание идентификатора субъекта (учетной записи пользователя) в системе;
• управление данными субъекта, используемыми для его аутентификации (смена пароля,
издание сертификата и т. п.);
• управление правами доступа субъекта к ресурсам системы.
Аудит — процесс контроля (мониторинга) доступа субъектов к ресурсам системы,
включающий протоколирование действий субъектов при их доступе к ресурсам системы в
целях обнаружения несанкционированных действий.
Таким образом, в общем случае речь идет о пяти основных процедурах предоставления
доступа к информации. При этом возможен различный подход к расстановке приоритетов при
выполнении этих процедур.
1.2. Роль и задачи аутентификации.

Место аутентификации в структуре
основных направлений защиты информации
Независимо от типа системы аутентификации в ней всегда присутствуют пять элементов.
Первый элемент — конкретный человек или процесс, который должен проходить
аутентификацию, — субъект доступа.
Второй элемент — опознавательный знак, идентификатор, который выделяет этого
человека или этот процесс среди других.
Третий элемент — отличительная характеристика (аутентификатор), подтверждающая
принадлежность идентификатора субъекту доступа.
10
Глава 1. Общие сведения об аутентификации
Четвертый элемент — владелец системы (администратор), который несет ответственность

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

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

Физическое лицо — это человек, которому разрешено пользоваться компьютером. Обычно в
системе физическому лицу назначается символическое имя или идентификационный код
пользователя, который мы будем называть именем пользователя. Например, если пользователь
является авторизованным пользователем системы, то администратор присваивает ему имя
пользователя «Пользователь». Отличительной характеристикой пользователя будет его
секретный пароль, например, «qwerty». Данная процедура знакома, так как в процессе
регистрации компьютер выдает запрос на ввод имени пользователя и пароля. Процесс
включает в себя процедуру аутентификации, т.е. сравнение пароля, введенного с клавиатуры, с
паролем, установленным либо самим пользователем, либо администратором системы.
Процедура завершается успешно, если оба пароля совпадают. В этом случае механизм
управления доступом разрешает пользователю продолжать работу на компьютере, и система
использует имя пользователя каждый раз, когда ей требуется решение службы управления
доступом к защищенному ресурсу.
Рассматривая проблемы защиты компьютеров, следует всегда проводить различие между
тем, что мы хотим сделать, и тем, что мы в действительности делаем.
Первый вопрос «чего мы хотим» обычно озвучивают в виде целей защиты. Например,
целью шайки сорока разбойников была защита добычи от воровства. В этом они полагались на
механизм защиты — дверь пещеры. В вычислительной системе целью владельца системы
является предоставление доступа только авторизованным (законным) пользователям.
На практике же всегда существует зазор между тем, что мы хотим, и что происходит на
самом деле. Так, замок позволяет войти каждому, у кого есть экземпляр нужного ключа,
однако посторонние смогут войти тоже, если мы не предотвратим попадание к ним ключа.
Это может оказаться трудным делом, особенно если те, кого мы стремимся не впустить с
помощью замка, действительно хотят попасть внутрь. Более того, мы не всегда можем
позволить себе поставить замки на все на свете. Часто имеется один большой замок на
входной двери, и нам приходится доверять тем, кого мы впустили внутрь.
В компьютерных системах аутентификация и управление доступом обычно реализуются
как две разные функции. Хотя иногда имеет смысл проводить различие между задвижкой,
удерживающей дверь закрытой, и замком, который управляет задвижкой, задвижка и замок
часто встроены в один механизм. В компьютерных системах процесс аутентификации
подтверждает подлинность имени пользователя, а управление доступом осуществляется путем
сравнения имени пользователя с правилами доступа, связанными с конкретным файлом или
другим ресурсом. Если правила разрешают доступ пользователю с этим именем, то он
получает возможность использовать ресурс.
11
ЧАСТЬ I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
В компьютерных системах аутентификация и управление

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

«наименьшей привилегии», в соответствии с которым люди
имеют ровно столько разрешений и привилегий, сколько им
требуется, но на практике мера доверия пользователям
обычно расширяется.
Управление доступом может быть очень сложным даже в отсутствие попытки добиться
выполнения принципа наименьших привилегий. Современные вычислительные системы
обеспечивают широкий диапазон подходов и механизмов управления доступом. Механизмы
управления доступом даже в таких относительно простых системах, как Unix или Windows,
позволяют пользователям и администраторам устанавливать весьма сложные наборы правил
получения и лишения прав на использование различных ресурсов компьютера. Однако многие
организации придерживаются относительно простого подхода, связывая управление доступом
и аутентификацию, так что прошедшие аутентификацию пользователи имеют всего лишь
небольшое количество ограничений доступа.
Хотя проблема аутентификации пользователей сама по себе является серьезной проблемой
для компьютерных систем, пользователи не являются единственными субъектами, которые
подлежат аутентификации.
В настоящее время необходимо аутентифицировать и

системы, действующие без вмешательства человека.
12
Фактор Классификация типов факторов
аутентификации Примеры факторов аутентификации
аутентификации NCSC-TG-0171
На основе знания • Пароль или парольная фраза

чего-либо Type 1:
Authentication by Knowledge • PIN-код (Personal Identification
(1-й) Number)
На основе обладания Type 2:
чем-либо Authentication by Ownership • Физический ключ
(2-й) • Карта с магнитной полосой
• OTP-токен, генерирующий од-
норазовый пароль
Type 3:
Authentication by Characteristic • Отпечаток пальца
На основе биометрических
характеристик (3-й) • Рисунок сетчатки глаза
• Голос
1
NCSC-TG-017 — документ «A Guide to Understanding Identification and Authentication in Trusted
Systems», опубликованный U.S. National Computer Security Center. Руководство содержит комплект
рекомендуемых инструкций по процедурам идентификации и аутентификации.
13
Выделяют три фактора аутентификации, используемые в

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

определенные помещения доступ предоставляется только ограниченному числу лиц.
Например, в серверную комнату может войти только администратор или в комнату фи-
нансового отдела компании могут иметь доступ только его сотрудники. Если при этом
установить для компьютеров, находящихся в этих помещениях, строго определенные IP-
адреса, то тогда появляется возможность более качественно выполнять аутентификацию при
доступе сотрудников к ресурсам компьютерной сети. Им предоставляется доступ к
определенным действиям или данным только в том случае, если они это делают в строго
определенном помещении и соответственно с определенных компьютеров, имеющих
определенные IP-адреса. В этом случае иногда говорят об использовании «четвертого» типа
фактора аутентификации — на основе места проведения процедуры. Данный фактор не
считается дополнительным, так как его нельзя использовать отдельно от других факторов для
аутентификации субъекта. Например, нельзя обеспечить, чтобы только определенный
сотрудник работал на строго определенном рабочем месте (компьютере).
В последнее время наметились тенденции интеграции логических средств аутентифи-
кации и средств контроля и управления доступом (СКУД). Смарт-карты, используемые для
аутентификации пользователя при доступе к ресурсам компьютерной системы, интегрируются
с RFID (радиочастотной идентификацией). В этом случае появляется возможность
дополнительно использовать их для аутентификации человека при его доступе в различные
помещения. По-прежнему в этом случае речь будет идти об использовании аутентификации
«на основе обладания чем-либо». Это расширяет возможности использования смарт-карты,
дает дополнительные удобства для пользователя, но не повышает качество аутентификации.
1.3.1. Многофакторная аутентификация
Аутентификация может быть реализована с помощью одного из трех факторов аутен-

тификации. Например, в процессе аутентификации у пользователя может быть запрошен
пароль, либо потребуется представить отпечаток пальца.
Аутентификация, в процессе которой используется только один фактор аутентификации,
называется однофакторной.
Аутентификация, в процессе которой используется несколько факторов аутентификации,
называется многофакторной.
Например, в процессе аутентификации пользователь должен использовать смарт-карту и
дополнительно пароль (или PIN-код). Также используются понятия двухфакторной и
трехфакторной аутентификации при использовании комбинации двух и трех факторов
аутентификации соответственно.
В документе NCSC-TG-017 вводятся термины для различных видов многофакторной
аутентификации: типа 12, типа 23 и типа 123. Аутентификация типа 12 (произносится как
«аутентификация типа один два»), например использует два фактора аутентификации: первый
(на основе знания чего-либо) и второй (на основе обладания чем-либо).
14
Глава 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).
16
Глава 2. Парольная аутентификация
Рис. 2.1. Аутентификация на основе открытого пароля
Пример аутентификации пользователя на основе открытого пароля:

1. Пользователь вводит свои имя пользователя «Пользователь» и пароль «qwerty» на ра-
бочей станции.
2. Имя пользователя и пароль передаются по сети в открытом виде.
3. Сервер аутентификации находит учетную запись пользователя в базе данных аутен-
тификации и сравнивает введенные данные с ее содержимым.
В случае совпадения аутентификация признается успешной.
Простым методом парольной аутентификации является

аутентификация на основе открытого пароля
2.2.2. Аутентификация на основе хэшированного пароля

В большинстве используемого в настоящее время программного обеспечения приме-
няются пароли не в чистом виде, а их хэш-значения, получаемые с помощью вычисления
криптографической хэш-функции.
Однонаправленные хэш-функции (далее — хэш-функции) — это функции, которые при-
нимают на входе строку переменной длины и преобразуют ее в выходную строку фиксиро-
ванной (обычно меньшей) длины, называемую значением хэш-функции (хэш-значением).
Пример прохождения пользователем процедуры аутентификации на основе хэширо-
ванного пароля (рис. 2.2.):
1. Пользователь вводит свои имя «Пользователь», и пароль «qwerty» на рабочей станции.
2. Рабочая станция вычисляет хэш-значение N4a#@JD от введенного пароля. Имя
пользователя и хэш-значение передаются по сети серверу аутентификации.
3. Сервер аутентификаци сравнивает результат вычисления хэш-значения (N4a#@JD) от
введенного пользователем пароля с хэш-значением, хранящимся в учетной записи
пользователя (N4a#@JD).
4. В случае совпадения аутентификация признается успешной.
Основным свойством однонаправленных хэш-функций является невозможность вос-
становления исходной информации при обладании полученным из нее хэш-значением.
Восстановить открытое значение пароля из файла паролей, где он хранится в виде хэш-
значения, практически невозможно.
17
Описание атаки Защита от данной атаки
Кража парольного файла

Злоумышленник может прочитать Хэширование пароля
пароли пользователя из парольного Каждая организация, разрабатывающая парольную аутентификацию,
файла или резервной копии должна снабжать свои приложения этой защитой.
19
Продолжение таблицы 2.1
Атака со словарем
Злоумышленник, перебирая
пароли, производит в файле Безопасность файла
паролей или его копии поиск,
используя слова из большого Доступ на чтение к файлу паролей должен быть предоставлен лишь
заранее подготовленного им небольшому числу доверенных пользователей.
словаря. Злоумышленник вы- Хэшированные с шумами (помехами) пароли
числяет хэш-значение для каждого Генерирование хэш-значения различным способом для каждого
пробного пароля с помощью того пользователя намного усложняет атаку со словарем: злоумышленник
же алгоритма, что и программа должен при подборе пароля каждого пользователя еще и подбирать
аутентификации. способ хэширования пароля. Это достигается в системах с помощью
использования меняющегося значения, называемого шумом.
Правила формата пароля
Такие правила могут требовать, чтобы пароль содержал как минимум
одну цифру, как минимум один «специальный» символ, комбинации
заглавных и строчных букв, и т.д.
Подбор пароля
Исходя из знаний личных данных
пользователя, злоумышленник Правила формата пароля
пытается войти в систему с
помощью имени пользователя и Как для «атаки со словарем» выше.
одного или нескольких паролей, Изменение пароля, установленного по умолчанию
которые он мог бы использовать Пароль, установленный по умолчанию, должен изменяться сразу
(в том числе пароля, ус- после первого использования. По возможности следует вовсе
тановленного по умолчанию). исключить практику использования общеизвестных паролей.
Автоматическое блокирование
После нескольких безуспешных попыток входа система или бло-
кирует учетную запись пользователя на некоторое время, или вовсе
аннулирует ее.
Социотехника
На пользователей: Политика нераскрытия паролей

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

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

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

Расположенный рядом зло- Неотображение пароля
умышленник или видеокамера В большинстве систем пароли либо не отображаются на экране, либо
следит за тем, как пользователь отображаются незначащими символами. В некоторых системах
вводит свой пароль. отображается количество таких символов, отличное от введенного.
Вопреки этой технологии, злоумышленник может видеть, на какие
непосредственно клавиши нажимает пользователь. Также
применяются технологии, которые дают пользователю строго
ограниченное время для ввода пароля, тем самым заставляя его
вводить пароль максимально быстро. Таким образом, уменьшается
вероятность его подсматривания, а также усложняется его подбор
злоумышленником.
Троянский конь
Злоумышленник скрытно уста- Особый режим интерактивного взаимодействия для механизма
навливает программное обеспе- аутентификации
чение, имитирующее обычный В некоторых системах механизм аутентификации вызывается
механизм аутентификации, но специально выделенным для этого сочетанием клавиш, недоступным
собирающее имена пользователей для других программ. В ОС Microsoft Windows в качестве такого
и пароли при попытках сочетания клавиш используется [Ctrl]—[Alt]—[Delete]. Антивирусное
пользователей войти в систему. программное обеспечение
Организация может обнаруживать программы типа «троянский конь»
с помощью антивирусного программного обеспечения. Средства
обеспечения контроля целостности файлов В организации может
использоваться система обнаружения вторжений (intrusion detection
system) для определения модификации важных файлов, например,
программы регистрации.
Злоумышленник скрыто уста- Безопасность рабочих помещений

навливает в компьютер пользо- Служба безопасности компании должна предоставлять доступ в
вателя аппаратное средство, со- помещения, в которых располагаются компоненты информационной
бирающее информацию, которую системы предприятия, только тем, кому он разрешен. Безопасность
вводит пользователь при входе в рабочих мест
систему, например, Keykeriki для Служба безопасности компании должна обеспечить возможность
контроля компонентов информационной системы предприятия для
Аппаратный сниффер клавиатуры
беспроводных клавиатур, защиты от возможности установки в них незаконных аппаратных
KeyCarbon, KeyDevil или средств. Контроль над соответствующими компонентами
KeyGhost для проводных информационной системы предприятия возлагается на сотрудников
клавиатур. компании, службу ИТ или службу безопасности компании.
Трассировка памяти
Злоумышленник использует Защита памяти
программу для копирования Некоторые ОС используют аппаратную защиту буферов клавиатуры
пароля пользователя из буфера от возможности ее трассировки.
клавиатуры.
Для предотвращения использо- Безопасность файлов
вания компьютеров не по на- Доступ на чтение к журналам должен быть предоставлен лишь
значению некоторые организации узкому кругу доверенных пользователей (администраторов) с по-
используют программное мощью собственной или резидентной службы контроля доступа.
обеспечение, следящее за на-
жатием клавиш. Злоумышленник
может для получения паролей
просматривать журналы
Отслеживание нажатия клавиш программными средствами
соответствующей программы.
21
Вим Ван Эк описал метод, ко- Неотображение пароля
торым злоумышленник может Как для «подглядывания из-за плеча» выше.
перехватывать информацию с
монитора путем регистрации его Безопасность излучений
излучения. Вин Швартау высказал Модернизация устройств для уменьшения излучения с помощью
идею приемников Ван Эка, использования современных микрокомпонент, специально раз-
регистрирующих не только работанных с учетом необходимости уменьшения излучения.
видеосигналы. Проектирование помещений и планирование расположения
оборудования в нем с учетом предотвращения возможности утечки
Регистрация излучения (перехват Ван Эка
информации или паразитное
через фрикинг Ванизлучение
Эка) оборудования.
Анализ сетевого трафика

Шифрование
Злоумышленник анализирует Весь сетевой трафик или только пароли могут шифроваться для
сетевой трафик, передаваемый от передачи по сети (использование протокола SSL или VPN-соеди-
клиента к серверу, для нений).
восстановления из него имен Одноразовые пароли
пользователей и их паролей. Использование методов аутентификации, в которых «пароли»
пользователей изменяются каждый раз при входе в систему.
Атака на «золотой пароль»

Шифрование
Злоумышленник ищет пароли Как для «анализа сетевого трафика» (см. выше). Одноразовые пароли
пользователя, применяемые им в Как для «анализа сетевого трафика» (см. выше).
различных системах — домашняя
почта, игровые серверы и т. п.
Есть большая вероятность того,
что пользователь применяет один
и тот же пароль во всех системах.
Злоумышленнк записывает Использование надежных протоколов аутентификации Надежные

последовательность передаваемых протоколы аутентификации предполагают использование при обмене
и получаемых субъектом доступа данными с субьъектом доступа криптографически защищенных
в процессе аутентификации меток времени. Одноразовые пароли
данных. Позднее он осуществляет Как для «анализа сетевого трафика» (см. выше).
попытку аутентификации,
передавая и получая записанные
данные в той же
последовательности.
Атака методом воспроизведения
1. Назовите методы парольной аутентификации.
2. Приведите пример аутентификации пользователя на основе открытого пароля.
3. Что такое однонаправленные хэш-функции?
4. Что такое PIN-код?
5. Назовите области и условия использования PIN-кода.
6. Для чего необходимы парольные политики?
7. Приведите примеры атак на системы, в которых используется аутентификация на основе
пароля.
22
Глава 3
АУТЕНТИФИКАЦИЯ С ПОМОЩЬЮ
БИОМЕТРИЧЕСКИХ ХАРАКТЕРИСТИК
Издавна люди узнавали друг друга по чертам лица, по голосу и другим приметам, харак-
терным только для определенного человека. Даже сейчас лицо является основным признаком,
по которому производят удостоверение личности человека, когда проверяют его паспорт,
водительские права, пропуск для доступа в организацию — все они содержат фотографию
человека, предъявляющего данные документы.
Современные технологии способны обеспечить удостоверение личности человека,
используя характерные только ему одному характеристики. Данные технологии основаны на
использовании знаний биометрики (или биометрии). Данная дисциплина занимается
статистическим анализом биологических наблюдений и явлений.
Биометрическая характеристика — это измеримая физиологическая или поведенческая
черта живого человека, которую можно использовать для установления личности или
проверки декларируемых личных данных.
Поскольку биометрический параметр уникален для данного человека, его можно исполь-
зовать для однофакторной аутентификации пользователя. Его можно использовать совместно с
паролем или с устройством аутентификации (например, таким, как смарт-карта) для
обеспечения двухфакторной аутентификации.
Биометрическая аутентификация обычно является одним из наиболее простых методов
для пользователей, которые должны проходить аутентификацию. В большинстве случаев
хорошо спроектированная биометрическая система просто снимает показания с человека и
правильно выполняет аутентификацию.
3.1. Биометрические характеристики

Биометрические характеристики делятся на физиологические и поведенческие.
Биометрические характеристики делятся

на физиологические и поведенческие.
Физиологические биометрические характеристики (физические биометрические ха-

рактеристики, статические биометрические характеристики) — биометрические харак-
теристики на основе данных, полученных путем измерения анатомических характеристик
человека.
К физиологическим биометрическим характеристикам можно отнести:
• радужную оболочку глаза;
• отпечаток пальца;
• лицо;
• кисть;
• сетчатку.
Поведенческие биометрические характеристики (динамические биометрические харак-
теристики) — биометрические характеристики на основе данных, полученных путем из-
мерения действий человека.
23
Характерной чертой для поведенческих параметров является их протяженность во

времени — измеряемое действие имеет начало, середину и конец.
К поведенческим биометрическим характеристикам можно отнести:
• голос;
• подпись;
• ритм работы сердца.
Различия между поведенческими и физиологическими характеристиками являются
достаточно искусственными.
Поведенческие биометрические параметры зависят от физиологии: голос зависит от фор-
мы голосовых связок, подпись — от ловкости кисти и пальцев. Некоторые физиологические
биометрические характеристики (например, лицо) могут изменяться в зависимости от
возраста или поведения человека. Поведение человека (например, то, как он кладет палец или
смотрит в камеру) может влиять на эффективность работы системы аутентификации.
Физиологические биометрические характеристики обычно неизменны в течение жизни
человека. Использование этих характеристик для аутентификации обычно воспринимается как
насильственное воздействие, часто как вмешательство в частную жизнь человека.
Поведенческие биометрические характеристики воспринимаются менее болезненно, но они
менее стабильны, чем физиологические черты. Они могут изменяться под влиянием стресса и
болезни и в целом обеспечивают, по сравнению с физиологическими параметрами, менее
качественную аутентификацию.
Поведенческие биометрические параметры достаточно

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

Хотя биометрические технологии различаются объектами и способами измерений, все
биометрические системы работают одинаково (рис. 3.1). Пользователь предоставляет образец
(sample) — опознаваемое, необработанное изображение или запись физиологической или
поведенческой характеристики. С помощью регистрирующего устройства (например, сканера
или камеры), этот биометрический образец обрабатывается для получения информации об
отличительных признаках, в результате чего получается контрольный шаблон (или шаблон для
проверки). Шаблоны представляют собой достаточно большие числовые последовательности;
сам образец невозможно восстановить из шаблона. Контрольный шаблон и есть «пароль»
пользователя.
Все биометрические системы работают одинаково:

пользователь предоставляет образец, с помощью
регистрирующего устройства этот биометрический образец
обрабатывается, в результате чего получается контрольный
шаблон.
24
01011 1 010
10010 Пользователь 100
11001 10 Глава 3. Аутентификация с помощью биометрических характеристик
01110 7
011 Н1
10
Пользователь
Сервер и база данных
Образец аутентификации
Решение
98% _ > 90 %|
Степень Пороговая
Рис 3.1. Схема работы биометрических систем совпадения величина
Контрольный шаблон сравнивается с эталонным шаблоном (или зарегистрированным

шаблоном), созданным на основе нескольких образцов определенной физиологической или
поведенческой характеристики пользователя, взятых при его регистрации в биометрической
системе. Поскольку эти два параметра (контрольный и эталонный шаблон) полностью никогда
не совпадают, то биометрической системе приходится принимать решение о том,
«достаточно» ли они совпадают. Степень совпадения должна превышать определенную
настраиваемую пороговую величину.
Биометрические системы могут ошибаться, контрольный шаблон может быть ошибочно
признан:
• соответствующим эталонному шаблону другого лица;
• несоответствующим эталонному шаблону данного пользователя, несмотря на то что
этот пользователь зарегистрирован в биометрической системе.
Точность биометрической системы измеряется двумя параметрами:
• коэффициентом неверных совпадений (FMR), также известным под названием
ошибка типа I или вероятность ложного допуска (FAR);
• коэффициентом неверных несовпадений (FNMR), также известным под названием
ошибка типа II или вероятность ложного отказа в доступе (FRR).
Биометрические системы могут ошибаться, их точность

измеряется коэффициентом неверных совпадений (F M R ) и
коэффициентом неверных несовпадений (F N M R )
Оба коэффициента отражают способность системы предоставлять ограниченный вход

авторизованным пользователям. Системы с низким значением FMR более защищены, а
системы с низким значением FNMR более просты в использовании. В общем случае для
25
данных систем при задании пороговой величины действует правило: чем ниже FMR, тем выше
FNMR. Таким образом, часто безопасность и простота использования конкурируют между
собой.
Простота регистрации и качество «шаблонов» — важные факторы общей эффективности
биометрической системы. Некачественный «шаблон» может осложнить работу пользователя,
вынуждая его прибегнуть к повторной регистрации в биометрической системе.
3.3. Аутентификация и биометрическое распознавание

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

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

использование негативной идентификации в процессе регистрации пользователя в био-
метрической системе, когда один контрольный шаблон сравнивается со многими, чтобы
проверить, что данное лицо не зарегистрировано в базе данных, и таким образом, пред-
отвратить двойную регистрацию в системе. Этот режим часто используется в крупных
программах по предоставлению социальных пособий, в которых пользователи пытаются
регистрироваться несколько раз для получения пособий под разными именами.
Существует нечто среднее между аутентификацией и распознаванием — «сравнение один
к нескольким» (1:few). Этот тип приложений предполагает идентификацию пользователя по
очень маленькой базе зарегистрированных пользователей. Четкого количественного
разграничения между системами 1:N и 1:few нет, но любую систему, в которой поиск
осуществляется среди более чем 500 записей, следует относить к типу 1:N.
26
Биометрическая Регистрирующее
характеристика устройство Образец Исследуемые черты
Радужная Видеокамера, способная Черно-белое изображение Полоски и бороздки в ра-

оболочка глаза работать в инфракрасном радужной оболочки глаза дужной оболочке глаза
диапазоне, камера для ПК
Отпечаток Периферийное устройство Изображение отпечатка Расположение и направ-
пальца настольного компьютера, пальцев (оптическое, на ление Гребешковых вы-
карта стандарта PC card, кремниевом фото- ступов и разветвлений на
мышь, микросхема или приемнике, ультразву- отпечатке пальцев, мелкие
считыватель, встроенный в ковое, или бесконтактное) детали
клавиатуру
Лицо Видеокамера, камера для ПК, Изображение лица (оп- Форма черепа, относи-
цифровой фотоаппарат тическое, двумерное (2Б- тельное расположение и
фото) или трехмерное форма носа, расположение
(ЭБ-фото)) скул
Кисть Настенное устройство Трехмерное изображение Высота и ширина костей и
верха и боков кисти суставов кисти и пальцев
Сетчатка Настольное или настенное Изображение сетчатки Расположение кровеносных
устройство сосудов на сетчатке
В стадии разработки находятся новые биометрические технологии, связанные с другими

физиологическими характеристиками:
• Сравнение ДНК — это самая совершенная биометрическая технология, дающая
прямое доказательство идентичности личности (кроме однояйцевых близнецов, у
которых одинаковый генотип). Этот метод иногда называется дактилоскопией ДНК,
что сбивает с толку и вводит в заблуждение, поскольку отпечатки пальцев не
«проникают до уровня генома». Биометрические системы, основанные на сравнении
ДНК, могут быть введены в действие лишь через много лет.
• Отпечаток ладони — в этой системе используется расположение линий на ладони че-
ловека, также, как в биометрической технологии, использующей отпечатки пальцев.
• Сосудистые рисунки — расположение вен в различных частях тела человека, включая
запястье и тыльную сторону ладони, а также лицо.
• Сигналы, вырабатываемые сердцем (мозгом, легкими), — в этой системе пользователь
прикасается к датчику «биодинамической подписи» и остается с ним в контакте
некоторое время (в зависимости от точности измерения — до 8 с). За это время датчик
идентифицирует индивидуальные параметры человека.
В стадии разработки находятся новые биометрические

технологии: сравнение ДН К , отпечаток ладони, сосудистые
рисунки, сигналы, вырабатываемые сердцем (мозгом, легкими).
27
Биометрическая Регистрирующее Образец Исследуемые черты
характеристика устройство
Микрофон, Частота, модуляция и продолжительность

Голос телефон Запись голоса голосового образа
Подпись Скорость, порядок линий, давление и
Планшет для Изображение подписи и внешний вид подписи
показания соот-
подписи, перо для ветствующих дина-
ввода данных мических измерений
Динамика Клавиатура Ритм машинописи
нажатия Время задержки (промежуток времени, в
клавиш течение которого пользователь удерживает
конкретную клавишу) время «полета»
(промежуток времени, который требуется
пользователю для перехода с одной
клавиши на другую)
3.4. Недостатки аутентификации с помощью

биометрических характеристик. Возможные атаки
В табл. 3.3 приведены известные методы атак на системы, использующие аутентификацию
с помощью биометрических характеристик, а также способы защиты от подобных атак.
К недостаткам аутентификации с помощью биометричесских характеристик можно
отнести следующие:
Вмешательство в частную жизнь. Пользователям-клиентам в большей степени, чем
пользователям-сотрудникам организаций, небезразличен факт хранения и распространения их
биометрических данных. Если в организации устроено централизованное хранилище
биометрических параметров, пользователи, не имея возможности контролировать
распространение этих данных, опасаются:
• злоупотреблений (например, незаконного обмена с другими организациями);
• нецелевого использования («подмены функции»).
Личные, культурные и религиозные аспекты. Дактилоскопические системы вызывают
неприятие у пользователей, которые считают, что их использование бросает на них тень
преступного свойства, поскольку отпечатки пальцев, как известно, применяются в кри-
миналистике.
Возникают также вопросы гигиены (будет ли прибор, регистрирующий геометрию руки,
обрабатываться антисептическим раствором после каждого использования?) и
травмоопасности (например, в системах сканирования сетчатки, в которых свет направляется
в глаз), а также осознание того факта, что пользователи подвергаются риску причинения вреда
со стороны преступников — от копирования или использования объектов биометрии под
физическим принуждением до потери кисти или пальца.
28
Подделка отличительной черты
Снятие показателей с высоким уровнем детализации При

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

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

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

казатель биометрического датчика — Меры аутентификации принимаются в отношении биомет-
«подпись», которая далее обраба- рических данных, чем гарантируется их поступление только из
тывается системой так, словно была заслуживающих доверия источников. Использование ЭЦП для
получена от реального человека. обеспечения целостности биометрической «подписи».
Непригодность для всех пользователей. От 1 до 3% процентов людей не имеют частей

тела, необходимых для внесения в систему хотя бы одного биометрического параметра. Немые
пользователи не могут использовать голосовые системы. Пользователи, у которых по причине
врожденной болезни, хирургического вмешательства или ранения не хватает пальцев или
кистей, не могут использовать системы, регистрирующие отпечатки пальцев и параметры
кисти.
1. Перечислите физиологические биометрические характеристики.
2. Назовите поведенческие биометрические характеристики.
3. Опишите принцип работы биометрических систем.
4. Назовите параметры, определяющие точность биометрических систем.
5. Приведите примеры атак на системы, использующие аутентификацию с помощью
биометрических характеристик, и способы защиты от подобных атак.
29
Глава 4
АУТЕНТИФИКАЦИЯ
С ПОМОЩЬЮ ОДНОРАЗОВЫХ ПАРОЛЕЙ
В основе всех методов аутентификации на основе пароля лежит предположение о том, что
только законный пользователь может пройти проверку, так как только он знает свой пароль.
Заметим, что используемый при этом идентификатор пользователя злоумышленник может
легко узнать. Особенно, если в качестве идентификатора пользователя используется не
назначаемый пользователю идентификационный номер — ID (случайная строка символов,
состоящая из букв и цифр), а так называемое «имя пользователя».
Так как обычно «имя пользователя» — это различные варианты комбинации имени и
фамилии пользователя, то определить его не составляет большого труда. Соответственно, если
злоумышленнику удастся узнать и пароль пользователя, то ему будет легко представиться
этим пользователем. Насколько бы ни был пароль засекреченным, узнать его иногда не
слишком трудно. Злоумышленник может сделать это, используя различные способы атак (см.
выше раздел «Недостатки методов аутентификации с запоминаемым паролем» в гл. 2).
Для каждой из этих атак есть методы защиты. Но большинство из этих вариантов защиты
обладают различными недостатками. Некоторые виды защиты достаточно дороги (например,
борьба с побочным электромагнитным излучением и наводками оборудования), другие
создают неудобства для пользователей (правила формирования пароля, использование
длинного пароля). Один из вариантов защиты от различных атак на аутентификацию на
основе пароля — переход на аутентификацию с помощью одноразовых паролей.
Применение схем одноразовых паролей стало заметным шагом вперед по сравнению с
использованием фиксированных паролей. Выше мы говорили, что злоумышленник, узнавший
фиксированный пароль, может повторно его использовать с целью выдачи себя за легального
пользователя. Частным решением этой проблемы как раз и является применение одноразовых
паролей: каждый пароль в данном случае используется только один раз.
Одним из вариантов защиты от различных атак на

аутентификацию по паролю является аутентификация
с использованием одноразовых паролей.
Одноразовые пароли (OTP, One-Time Passwords) — динамическая аутентификационная

информация, генерируемая для единичного использования с помощью аутентификационных
устройств (программных или аппаратных).
Одноразовый пароль (OTP) неуязвим для атаки методом анализа сетевого трафика, что
является значительным преимуществом перед запоминаемыми паролями. Несмотря на то, что
злоумышленник может перехватить пароль методом анализа сетевого трафика, поскольку
пароль действителен лишь один раз и в течение ограниченного промежутка времени, у
злоумышленника в лучшем случае есть весьма ограниченная возможность представиться
пользователем с помощью перехваченной информации.
30
Глава 4. Аутентификация с помощью одноразовых паролей
Одноразовый пароль действителен один раз в течение

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

пользуются OTP-токены.
OTP-токен — мобильное персональное устройство, которое принадлежит определенному
пользователю и генерирует одноразовые пароли, используемые для аутентификации данного
пользователя.
Таким образом, аутентификация с помощью одноразовых паролей, по сравнению с
аутентификацией на основе пароля, является аутентификацией с помощью другого фактора
аутентификации — аутентификацией «на основе обладания чем-либо».
Другим важным преимуществом применения аутентификационных устройств является то,
что многие из них требуют от пользователя введения PIN-кода:
• для активации OTP-токена;
• в качестве дополнительной информации, используемой при генерации OTP;
• для предъявления серверу аутентификации вместе с OTP.
Если дополнительно применяется еще и PIN-код, в методе аутентификации используются
два фактора аутентификации, т. е. данный метод относится к двухфакторной аутентификации.
Простейшей схемой применения одноразовых паролей служит разделяемый список. В
этом случае пользователь и проверяющий применяют последовательность секретных паролей,
где каждый пароль используется только один раз.
Естественно данный список заранее распределяется между сторонами аутентифика-
ционного обмена.
Такая схема применяется в настоящее время в некоторых системах «Интернет-банк».
Модификацией этого метода является таблица вопросов и ответов, которая содержит
вопросы и ответы, используемые сторонами для проведения аутентификации, причем каждая
пара используется только один раз. Существенным недостатком этой схемы является
необходимость предварительного распределения аутентифицирующей информации. После
того как выданные пароли закончатся, пользователю необходимо получить новый список.
Такое решение, во-первых, не удовлетворяет современным представлениям об
информационной безопасности, поскольку злоумышленник может украсть или скопировать
список паролей пользователя. Во-вторых, постоянно получать новые списки паролей вряд ли
кому-нибудь понравится.
Вместе с тем, в настоящее время разработано несколько методов реализации технологии
одноразовых паролей, исключающих указанные недостатки. В их основу легли различные
криптографические алгоритмы.
Простейшей схемой применения одноразовых паролей

служит разделяемый список. Существенным недостатком
этой схемы является необходимость предварительного
распределения аутентифицирующей информации.
31
4.1. Аппаратно-программные OTP-токены

OTP-токены имеют небольшой размер и выпускаются в виде:
• карманного калькулятора;
• брелока;
• смарт-карты;
• устройства, комбинированного с USB-ключом;
• специального программного обеспечения для карманных компьютеров, смартфонов,
настольных компьютеров.
4.2. Как работают OTP-токены

Для генерации одноразовых паролей OTP-токены используют хэш-функции или
криптографические алгоритмы:
• симметричная криптография (криптография с одним ключом) — в этом случае поль-
зователь и сервер аутентификации используют один и тот же секретный ключ;
• асимметричная криптография (криптография с открытым ключом) — в этом случае в
устройстве хранится закрытый ключ, а сервер аутентификации использует
соответствующий открытый ключ.
Для генерации одноразовых паролей OTP-токены используют

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

горитмов в реализациях OTP-токенов.
Соответственно механизмы аутентификации, используемые OTP-токенами, можно
разделить на две группы:
• аутентификация с одним секретным ключом,
• аутентификация с открытым ключом.
4.3. Методы аутентификации с помощью OTP-токенов

Обычно в OTP-токенах применяется симметричная криптография. Устройство каждого
пользователя содержит уникальный персональный секретный ключ, используемый для
шифрования некоторых данных (в зависимости от реализации метода) для генерации OTP.
Этот же ключ хранится на сервере аутентификации, который выполняет аутентификацию
данного пользователя. Сервер шифрует те же данные и сравнивает два результата
шифрования: полученный им и присланный от клиента. Если результаты совпадают, то
пользователь успешно проходит аутентификацию.
OTP-токены, использующие симметричную криптографию, могут работать в асинхронном
или синхронном режиме. Соответственно методы, используемые OTP-токенами, можно
разделить на две группы, работающие:
• в асинхронном режиме («запрос-ответ»);
• в синхронном режиме («только ответ», «синхронизация по времени», «синхронизация
по событию»).
32
3141
5926
L
4.3.1. Метод «запрос-ответ» (Challenge-response)
В методе «запрос-ответ» OTP является ответом пользователя на случайный запрос от

сервера аутентификации (рис. 4.1).
Хэш-функция Сервер и база

данных аутентификации
Рабочая станция и ОТР-токен Пользователь

* Пользователь Л
I
J
31415926
- —
|И
31415926
| 27182818
27182818 >
L
Г~
cft6yhnj
★
27182818 |
27182818
Рис. 4.1. Метод «Запрос-ответ»
Пример аутентификации пользователя при использовании OTP-токеном метода «запрос-

ответ»:
1. Пользователь вводит свое имя пользователя на рабочей станции.
2. Имя пользователя передается по сети в открытом виде.
3. Сервер аутентификации генерирует случайный запрос («31415926»).
4. Запрос передается по сети в открытом виде.
5. Пользователь вводит запрос в свой OTP-токен.
6. OTP-токен шифрует запрос с помощью секретного ключа пользователя («cft6yhnj»), в
результате получается ответ («27182818»), который отображается на экране OTP-токена.
7. Пользователь вводит этот ответ на рабочей станции.
8. Ответ передается по сети в открытом виде.
9. Аутентификационный сервер находит запись пользователя в аутентификационной базе
данных и с помощью хранимого им секретного ключа пользователя зашифровывает тот же
запрос.
10. Сервер сравнивает представленный ответ от пользователя («27182818») с вычис-
ленным им самим ответом («27182818»).
11. При совпадении значений аутентификация считается успешной.
4.3.2. Метод «только ответ» (Response only)

В методе «только ответ» аутентификационное устройство и сервер аутентификации
генерируют «скрытый» запрос, используя значения предыдущего запроса. Для начальной
инициализации данного процесса используется уникальное случайное начальное значение,
генерируемое при инициализации OTP-токена.
33
Хэш-функция Сервер и база данных

аутентификации
Рабочая станция и ОТР-токен
пл
I 66260689
Пользователь,
r5tgbhu8
<previous>
----------\ 29979246
29979246 I
m
r5tgbhu8
<previous>
| 66260689 □<^c 66260689 ]
Рис. 4.2. Метод «Только ответ»
Пример аутентификации пользователя при использовании OTP-токеном метода «только

ответ» (рис. 4.2):
1. Пользователь активизирует свой OTP-токен, который вычисляет и отображает ответ на
«скрытый» запрос.
2. Пользователь вводит свое «имя пользователя» и этот ответ («66260689») на рабочей
станции.
3. Имя пользователя и ответ («66260689») передаются по сети в открытом виде.
4. Сервер находит запись пользователя, генерирует такой же скрытый запрос и шифрует
его с помощью секретного ключа пользователя, получая ответ на свой запрос.
5. Сервер сравнивает представленный ответ от пользователя («66260689») с вычисленным
им самим ответом («66260689»).
4.3.3. Метод «Синхронизация по времени» (Time synchronous)

В режиме «синхронизация по времени» аутентификационное устройство и аутентифи-
кационный сервер генерируют OTP на основе значения внутренних часов. OTP-токен может
использовать не стандартные интервалы времени, измеряемые в минутах, а специальные
интервалы времени обычно равные 30 с.
Пример аутентификации пользователя при использовании OTP-токеном метода «син-
хронизация по времени» (рис. 4.3):
1. Пользователь активизирует свой OTP-токен, который генерирует OTP («96823030»),
зашифровывая показания часов с помощью своего секретного ключа.
34
Сервер и база
Хэш-функция данных аутентификации
Рабочая станция и ОТР-токен
х
16yhnji9
1
16yhnji9 *
А
12 : 34
96823030 ]#[ 96823030
Рис. 4.3. Метод «Синхронизация по времени»
2. Пользователь вводит свое «имя пользователя» и этот OTP на рабочей станции.

3. Имя пользователя и OTP передаются по сети в открытом виде.
4. Аутентификационный сервер находит запись пользователя и шифрует показание своих
часов с помощью хранимого им секретного ключа пользователя, получая в результате OTP.
5. Сервер сравнивает OTP, представленный пользователем, и OTP, вычисленный им
самим.
4.3.4. Метод «синхронизация по событию» (Event synchronous)

В режиме «синхронизация по событию» OTP-токен и сервер аутентификации ведут
количественный учет прохождения аутентификации данным пользователем, и на основе этого
числа генерируют OTP.
Пример аутентификации пользователя при использовании OTP-токеном метода
«синхронизация по событию» (рис. 4.4):
1. Пользователь активизирует свой OTP-токен, который генерирует OTP («59252459»),
зашифровывая число раз прохождения аутентификации данного пользователя с помощью
своего секретного ключа.
2. Пользователь вводит свое «имя пользователя» и этот OTP на рабочей станции.
3. Имя пользователя и OTP передаются по сети в открытом виде.
4. Аутентификационный сервер находит запись пользователя и шифрует значение числа
раз прохождения аутентификации данного пользователя с помощью хранимого им секретного
ключа пользователя, получая в результате OTP.
5. Сервер сравнивает OTP, представленный пользователем, и OTP, вычисленный им
самим.
35
Глава 4. Аутентификация с помощью одноразовых
ЧАСТЬ I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ паролей
4.5. Системы одноразовых паролей

Сервер и база данных
Рабочая станция и ОТР-токен 4.5.1. Система S/Key
Система S/Key— система одноразовых паролей, разработанная в Беллкоре (Bell Com-
munication Research Labs, Bellcore Labs) в начале 1990-х гг. в качестве метода регистрации для
UNIX-систем.
Техническая концепция была впервые предложена Лесли Лэмпортом (Leslie Lamport) и
опубликована в 1981 г. Основное отличие подхода Лэмпорта от других методик на основе
принципа «запрос—ответ» состояло в том, что не было базы данных секретных ключей,
поэтому взломщики не могли поставить под угрозу работу системы, украв эту базу данных.
В схеме Лэмпорта (рис. 4.5) используется последовательность значений односторонних
хэш-функций, вычисляемых из базового секрета. Как и в случае традиционной пароль ной
e4rfvgy7 в UNIX-системах, в схеме Лэмпорта использован тот факт, что вычисление
0042
хэшированного значения пароля не представляет сложности, а вот обратное получение пароля
по значению хэша невозможно. В схеме Лэмпорта используется последовательность значений
хэш-функции, каждое из которых вычисляется из предыдущего члена последовательности.
Хэш-функция
Сервер хранит последнее значение хэш-функции в последовательности.
Схему Лэмпорта для трех актов аутентификации можно представить в виде последо-
вательности следующих шагов:
Рис. 4.4. Метод «Синхронизация по событию»
1. Четыре раза последовательно вычисляется значение хэш-функции базового секрета
пользователя. Конечный результат этих вычислений сохраняется в базе данных аутен-
Некоторые OTP-токены могут использовать несколько различных методов реализации
аутентификации с помощью OTP. Наиболее часто комбинируются методы «синхронизация по
времени» и «синхронизация по событию».
4.4. Сравнение методов

qwerty N4a#@JD OTP-аутентификации
' Fmase345 d215F54f j : 15t3c$#43 Гч
Метод «запрос-ответ», работающий в асинхронном режиме, предполагает

У большее
количество шагов, совершаемых пользователем, чем любой из синхронных режимов.
Потенциальная проблема всех методов реализации аутентификации с помощью OTP,
Сервер
работающих в синхронном режиме, — возможность ___! рассинхронизации OTP-токена и сервера,
например:
Рабочая
• в режимах станция
«только ответ» или «синхронизации по событию» сбойН при аутентификации
База данных
может привести к «отставанию» сервера от аутентификационного устройства;
• в режиме+ «синхронизации по времени» часы аутентификационного аутентификации
устройства могут
уйти вперед или отстать от часов сервера.
_■ ■ .-г..*--
| d215F54f~j- - ■;
Потенциальная проблема всех методов реализации
аутентификации с помощью OTP, работающих в синхронном
режиме, — возможность рассинхронизации OTP-токена и
сервера. [_15t3c$#43 ■
При аутентификации с попощью OTP-токенов, как правило, предусматривается вариант

Хэш-функция
решения проблемы рассинхронизации: сервер генерирует несколько возможных вариантов
' | d215F54f
OTP — «ответов» от пользователя за некоторый короткий промежуток времени (для
нескольких событий или единиц измерения
Рис. 4.5. времени).
Схема Лэмпорта
36 37
тификации, а промежуточные выдаются пользователю либо повторно вычисляются им при

каждом акте аутентификации.
2. Пользователь в качестве одноразового пароля предоставляет предпоследнее в по-
следовательности значение хэш-функции.
3. Сервер принимает одноразовый пароль, вычисляет значение хэш-функции и сравнивает
со значением хэш-функции, хранящимся в базе данных аутентификации. Эти значения
должны совпасть.
4. При совпадении (успешной аутентификации) сервер заменяет значение хэш-функции в
учетной записи пользователя (четвертое значение хэш-функции) значением пароля, только
что принятым от пользователя (третьим значением хэш-функции). При следующем входе
пользователя в систему он должен предоставить второе значение хэш-функции, а при
последнем входе — первое значение.
Схема Лэмпорта реализована в системе S/Key. В этой методике используются синхронные
одноразовые пароли. В качестве одноразового пароля пользователь должен предоставлять
предпоследнее значение хэш-функции. Это требует точного учета использованных паролей, а
пользователи не очень сильны в подобной бухгалтерии. Но, как правило, S/Key-серверы
подсказывают пользователю порядковый номер ожидаемого значения хэш-функции. Таким
образом, в системе S/Key используется как бы «запрос—ответ», хотя в действительности эта
информация опционна и предоставляется только для удобства пользователя.
В системе S/Key функция хэширования также включает в себя и случайное число, на-
зываемое «примесью», которое объединяется с базовым секретом при генерации значений
хэш-функции. «Примесь» не позволяет системе S/Key генерировать одинаковые последо-
вательности значений хэш-функции, если пользователь попытается повторно воспользоваться
базовым секретом или использовать один и тот же базовый секрет для разных компьютеров.
Хотя на рисунке показано, что в файле паролей хранится только значение хэш-функции,
система S/Key хранит также значение «примеси» и порядковый номер значения хэш-функции.
Когда S/Key-сервер выдает запрос, содержащий текущий порядковый номер хэш-функции
пользователя, он одновременно выводит и значение «примеси», используемое для генерации
значений хэш-функции.
Как правило, пользователи системы S/Key используют для генерации одноразовых
паролей программно реализованные OTP-токены. Чтобы воспользоваться программным OTP-
токеном для данной системы, пользователь вводит базовый секрет (пароль), порядковый номер
и значение «примеси». OTP-токен итеративно использует функцию хэширования для
генерации правильного значения в последовательности и затем выводит результирующее
значение хэш-функции. После этого пользователь копирует значение хэш-функции в
ожидающее окно запроса пароля.
Как правило, пользователи системы S/Key используют для генерации

одноразовых паролей программно реализованные OTP-токены.
Программные реализации устройства аутентификации существуют для операционных

систем типа UNIX, Microsoft и Macintosh. Программное устройство аутентификации обычно
само обнаруживает запрос системы S/Key, так что оно способно автоматически вычислять
правильное значение одноразового пароля. Когда это возможно, устройство аутентификации
поддерживает функцию вырезания и вставки через буфер, что позволяет избегать ошибок
набора при копировании запроса или ответа. Кроме того, для пользо
38
вателей, которые не имеют возможности запускать на выполнение программу устройства

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

системы S/Key технически несложна, на данный момент
промышленных не существует.
4.5.2. Группа OATH и система HOTP

Система HOTP (HMAC-based One-Time Password System) была разработана в 2005 г. в
рамках инициативы группы открытой аутентификации OATH (Open AuTHentification) и
описана в документе RFC 4226. Данная система основана на концепции OTP-аутентификации
с синхронизацией по событию. Для генерации одноразового пароля используется алгоритм
HMAC (Hashed Message Authentication Code).
Система HOTP основана на концепции OTP-аутентификации

с синхронизацией по событию.
Этот алгоритм публичен и доступен для изучения любыми специалистами. Он обеспе-

чивает возможность аутентификации в широком спектре программного обеспечения, в том
числе и серверного.
Система HOTP предусматривает возможность задания «окна» попыток аутентификации и
синхронизацию сервера аутентификации с OTP-токеном после успешного прохождения
аутентификации.
Значение одноразового пароля вычисляется по формуле
HOTP(K, C) = Truncate(HMAC-SHA-l(K, C)),
где
•K — секретный ключ;
•C — счетчик числа раз прохождения аутентификации;
•HMAC-SHA-1 — процедура генерации HMAC, основанная на функции хэширования
SHA-1;
• Truncate — процедура усечения 20-байтового значения HMAC-SHA-1 до 4 байт.
Пример аутентификации пользователя с помощью HOTP (рис. 4.6):
1. Пользователь генерирует значение HOTP с использованием хранимого на OTP-токене
значения числа раз прохождения аутентификации и секретного ключа (592524594012).
39
Г"* - - -----------
Пользователь Е
e4rfVgy7, 4012 ; ЧАСТЬ I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
№0042 :
ОТР-пин Сервер и база

данных аутентификации
e4rfVgy7,
4012
№0043 :О
2455830 e4rfVgy7,
4 4012
№0044
0 Пользователь
Хэш-функция 5925245 5925245 e4rfVgy7,
9 9 4012
№0045
Рис. 4.6. Система HOTP
2. Пользователь вводит свое «имя пользователя» и OTP на рабочей станции.

3. Имя пользователя и OTP (592524594012) передаются по сети в открытом виде.
4. Аутентификационный сервер находит запись пользователя и генерирует OTP, ис-
пользуя хранимые на сервере значения числа раз прохождения аутентификации данного
пользователя и секретного ключа пользователя и получая в результате OTP (592524594012).
5. Сервер сравнивает OTP, представленный от пользователя, и OTP, вычисленный им
самим.
a. Если значения не совпадают, сервер увеличивает значение числа раз прохождения
аутентификации пользователя на единицу и повторяет попытку.
b. Если значения совпадают — на сервере сохраняется новое значение числа раз про-
хождения аутентификации пользователя.
Аутентификация считается успешной.
c. Если достигнуто максимальное число неуспешных повторов процедуры аутенти-
фикации (задаваемое шириной «окна»), аутентификация считается неуспешной.
40
Атака «Человек посередине»

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

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

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

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

Злоумышленник перехватывает несколько Использование «аппаратных» аутентификационных токенов В
правильных OTP, использованных для входа этом случае достаточно сложно произвести «в реальные
в систему, копирует программный сроки» перебор возможных значений PIN-кода до момента
аутентификационный токен (программное обнаружения владельцем пропажи токена и «ин-
обеспечение), затем он пытается подобрать формирования аутентификационного сервера» о том, что
PIN-код путем перебора его возможных данный токен может быть использован злоумышленником.
значений, для тестирования пробного
значения PIN-кода используются пере-
Подбор PIN-кода аутентификационного токена с помощью известных OTP
хваченные OTP.
41
Нечестный администратор аутентификационных токенов

Злоумышленник является доверенным лицом
либо является посредником доверенного Разделение ответственности при инициализации аутен-
лица, производящего инициализацию тификационных токенов
аутентификационного устройства до В процессе программирования и активирования токена
передачи его владельцу. Он может создать должны участвовать двое или более людей, каждый из
дубликат токена и, используя его, выдавать которых выполняет строго ограниченный набор операций.
себя за владельца.
Примечание
При использовании программных аутентификационных токенов, строго говоря, эмулятор
или отдельный закрытый ключ подтверждает подлинность только рабочей станции, а не
пользователя. Даже при условии защиты с помощью PIN-кода, строгая двухфакторная
аутентификация заменяется на однофакторную. Любому лицу, имеющему физический доступ
к рабочей станции, чтобы представиться пользователем, остается только узнать его PIN-код.
Этот подход может оказаться достаточно эффективным для сотрудников и клиентов,
работающих дома, но он неприемлем для использования в офисе, его целесообразность для
мобильных сотрудников сомнительна.
1. Что такое одноразовые пароли?
2. Опишите принцип работы ОТР-токенов.
3. Приведите пример аутентификации пользователя при использовании OTP-токеном
метода «запрос-ответ».
метода «только ответ».
метода «синхронизация по времени».
метода «синхронизация по событию».
Глава 5
КРИПТОГРАФИЯ С ОТКРЫТЫМ КЛЮЧОМ
5.1. Общие сведения о

криптографии с открытым ключом
5.1.1. Использование криптографии с открытым ключом
В криптографии с открытым ключом (асимметричная криптография) алгоритмы
используют связанные между собой пары ключей, состоящие из открытого и закрытого ключа.
Для каждого человека или объекта генерируется ключевая пара:
• открытый ключ, доступный для всех;
• закрытый ключ, известный только человеку, которому он выдан, и никому другому не
раскрывается и никуда не передается.
Информация, зашифрованная с помощью одного ключа из ключевой пары, может быть
расшифрована только с помощью другого ключа из этой же пары. Ключи математически
связаны между собой так, что, зная открытый ключ, практически невозможно вычислить
закрытый. Пользователь может повсеместно распространять свой открытый ключ, но он
должен обязательно защищать свой закрытый ключ.
Криптографические методы защиты используют операцию преобразования информации,
которая может выполняться одним или несколькими пользователями, обладающими
некоторым секретом, без знания которого (с вероятностью, близкой к единице за раз умное
время) невозможно осуществить эту операцию.
К криптографическим методам защиты в общем случае относятся:
• шифрование информации (термин шифрование объединяет в себе два процесса:
зашифровывание и расшифровывание информации);
• формирование и проверка цифровой подписи электронных документов.
Электронная цифровая подпись (ЭЦП) — это реквизит электронного документа, который
предназначен для защиты данного электронного документа от подделки, получен в результате
криптографического преобразования информации с помощью закрытого ключа электронной
цифровой подписи и позволяющий идентифицировать владельца сертификата ключа подписи,
а также установить отсутствие искажения информации в электронном документе.
Применение электронной цифровой подписи позволяет:
• обеспечить подтверждение авторства (аутентичность) информации;
• обеспечить контроль целостности (в том числе истинности) информации;
• решать вопрос о юридическом статусе электронных документов, а значит, решать
задачу разграничения ответственности между взаимодействующими абонентами
(субъектами).
Таким образом, криптографию с открытым ключом можно использовать для:
• предотвращения возможности несанкционированного ознакомления с информацией
при ее хранении в компьютере или на отчуждаемых носителях, а также при передаче
по каналам связи;
• подтверждения подлинности электронного документа, доказательства авторства
документа и факта его получения от соответствующего источника информации;
• обеспечения гарантий целостности (имитостойкости) — исключение возможности
необнаружения несанкционированного изменения информации;
• аутентификации пользователей системы — владельцев секретных ключей.
43
Ниже приведен пример использования криптографии с открытым ключом для шиф-

рования сообщения.
Для обеспечения конфиденциальности данных Автор может отправить личное сообщение
Получателю, зашифровав его с помощью открытого ключа Получателя (находящегося в
свободном доступе), потому что только Получатель обладает закрытым ключом и может
расшифровать данное сообщение.
Поскольку ассиметричная криптография требует достаточно больших вычислительных
ресурсов, обычно на практике она применяется в комбинации с симметричной криптографией.
Само сообщение шифруется с помощью использования симметричного алгоритма, а
секретный (сеансовый) ключ, использованный при шифровании данного сообщения,
шифруется с помощью ассиметричного алгоритма для передачи сеансовых ключей по сети.
Пример использования криптографии с открытым ключом для электронной цифровой
подписи сообщения приведен на рис. 5.1.
Сервер аутентификации хранит файл открытых ключей всех пользователей.
Для обеспечения удостоверения подлинности источника данных Автор может отправить
Получателю сообщение, зашифровав его с помощью своего закрытого ключа. Получатель
может быть уверен, что сообщение поступило именно от Автора, если он сможет
расшифровать его с помощью использования его открытого ключа. Таким образом, личность
отправителя может быть однозначно удостоверена, поскольку по определению только Автор
имеет доступ к своему закрытому ключу.
Поскольку данные криптографические преобразования производятся над значением хэш-
функции документа, любое изменение содержания документа приводит к уничтожению
подписи автора документа. Таким путем можно гарантировать, что в документ, если он
«содержит подпись» Автора, никто не вносил каких-либо изменений, кроме самого Автора
данного документа.
I
Сервер аутентификации
хранит файл открытых
Хэш-функция ключей всех пользователей
Хэш 1
1
Автор Сообщение Подписанное
а т■
•Г
Получатель
сообщение
Ч т If
■
Т
I
Открытый канал связи
£ Х"" £
Ассимметричный алгоритм
Закрытый ключ Открытый ключ
Рис. 5.1. Пример использования криптографии с открытым ключом
44
-1г
"011010011 Глава 5. Криптография с открытым ключом
0
4
ОО 5.1.2.
1100010100 Аутентификация с помощью открытого ключа
0 ?
4
Аутентификационный сервер хранит файл открытых ключей всех пользователей, а все
пользователи хранят свои закрытые ключи. Пример аутентификации пользователя с помощью
открытых ключей (упрощенный вариант) приведен на рис. 5.2:
1. Сервер посылает пользователю случайную строку, созданную генератором случайных
чисел (ГСЧ).
2. Пользователь шифрует эту строку своим закрытым ключом и посылает ее обратно
серверу вместе со своим именем.
3. Сервер находит в базе данных открытый ключ пользователя и расшифровывает со-
общение, используя этот открытый ключ.
4. Если отправленная и расшифрованная строки совпадают, сервер предоставляет
пользователю доступ к системе.
Никто другой не может воспользоваться закрытым ключом Пользователя, следовательно,
никто не сможет выдать себя за него. Что более важно, Пользователь никогда не посылает на
компьютер свой закрытый ключ. Злоумышленник, перехватывая сообщения, не получит
никаких сведений, которые позволили бы ему вычислить закрытый ключ Пользователя и
выдать себя за него.
ГСЧ
1
w ■0110100110
Пользователь 0110100110
I Закрытый
ключ
тый '
2
0010001100,
ользовател]
П
4 ■ - ■?
' 011010
ч+
0110100110
аутентифи-
кации л
-- Л
Сервер . Открытый
Открытый канал связи ключ
*
3
Рис. 5.2. Аутентификация с помощью открытого ключа (упрощенный вариант)
ГСЧ ГСЧ
Пользователь База данных
----1110101110 аутентифи-
кации
1
0010001100)
Отк
'0110100110
43
£ 110100110
—дч
Закрыты: 1000101000-
ключ
■ 1110101110 Открытый Сервер
канал связи 5 да
Рис. 5.3. Аутентификация с помощью открытого ключа
45
В данной процедуре на шаге 1 производится шифрование «случайной строки, присланной

от сервера», что служит потенциальной уязвимостью процедуры, так как этим может
воспользоваться злоумышленник для взлома данного протокола с помощью подобранного
шифртекста. Безопасные идентификационные протоколы имеют более сложную форму (рис.
5.3):
1. Пользователь выполняет вычисление, основанное на некоторых случайных числах в
своем закрытом ключе, и посылает результат серверу.
2. Сервер посылает другое случайное число.
3. Пользователь выполняет некоторое вычисление, основанное на случайных числах (как
созданных им, так и полученных от сервера) в своем закрытом ключе, и посылает результат
серверу.
4. Сервер выполняет некоторое вычисление для различных чисел, полученных от
Пользователя, и его открытого ключа, проверяя, что Пользователю известен его закрытый
ключ.
5. Если проверка завершается успешно, личность Пользователя подтверждается.
В этом случае шаг 1 позволяет защитить протокол от вскрытия с помощью подобранного
шифртекста.
Данный протокол широко используется, если криптография с открытым ключом
применяется в рамках одного небольшого предприятия, когда число пользователей невелико.
Если же криптографию с открытым ключом используют для большого числа пользователей
или нескольких предприятий, необходимо иметь инфраструктуру для управления ключами.
5.1.3. Аутентификация с помощью открытого ключа на

основе российских криптографических алгоритмов
В 2001 г. по инициативе российской компании «КРИПТО-ПРО» предложены «Ре-
комендации к средствам криптографической защиты информации на взаимодействие
удостоверяющих центров, реестров сертификатов, сертификаты ключей формата X.509 и
электронные документы формата CMS». Указанные Рекомендации составлены с учетом
международных стандартов и рекомендаций, директивы Европейского парламента «Об
электронной цифровой подписи» (1999/C 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 утвердил и опубликовал новые
46
Глава 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. «Информационная технология. Криптографическая защита ин-
формации. Функция хэширования». Этот стандарт определяет процедуру хэширования
подписываемых данных.
47
5.3. Конфиденциальность
и контроль целостности передаваемой информации
Конфиденциальность и контроль целостности информации обеспечивается путем ее
шифрования и имитозащиты. Алгоритмы шифрования и имитозащиты определяются стан-
дартом ГОСТ28147—89. Этот стандарт определяет следующие режимы шифрования данных:
• простая замена, тип шифрования — ECB (Electronic Codebook);
• гаммирование, тип шифрования — CCB (CipherCountBlock);
• гаммирование с обратной связью, тип шифрования — CFB (Cipher Feedback).
Алгоритмы, определяемые ГОСТ 28147—89, являются симметричными и используют
ключи длиной 256 бит.
Алгоритм шифрования стандарта ГОСТ 28147—89 используется в условиях открытого
распределения ключей с выработкой симметричного ключа парной связи, которая
осуществляется с помощью алгоритма Диффи-Хеллмана на базе операций алгоритма ГОСТ Р
34.10—94 или ГОСТ Р 34.10—2001. Ключ Диффи-Хеллмана K(x, у) вырабатывается на
каждой стороне информационного обмена из собственного закрытого ключа и открытого
ключа противоположной стороны, при использовании алгоритма:
• ГОСТ P 34.10—94 ключ K(x, у) вычисляется по формуле K(x, у) = a^modp);
• ГОСТ P 34.10—2001 ключ K(x, у) вычисляется по формуле K(x, у) = ((а х x)(modq))°
°(у°Р), где P — стартовая точка на цикле эллиптической кривой (две координаты по
256 бит), а — синхровектор (64 бит).
Ключ парной связи образуется хэшированием ключа K(x, у) по алгоритму ГОСТ Р 34.11—
94. Этот ключ имеет длину 256 бит и используется в установленной парной связи для
шифрования случайных симметричных ключей сообщений по алгоритму ГОСТ 28147—89.
5.4. Аутентификация связывающихся сторон

Аутентификация связывающихся сторон осуществляется с помощью сертификатов
открытых ключей сторон. Используются сертификаты стандарта X.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.6. Инфраструктура открытых ключей (PKI)

Для использования криптографии с открытым ключом необходимо гарантировать, что
каждый закрытый и открытый ключ управляются корректным образом.
Инфраструктура открытых ключей (Public Key Infrastructure — PKI) предназначена для
управления открытыми ключами и сертификатами с целью поддержки услуг аутентификации,
шифрования, целостности и неотказуемости.
Открытый ключ, связанный с определенным пользователем, должен быть удостоверен
сертификатом открытого ключа. Более того, подлинность сертификата открытого ключа
должна проверяться доверенным учреждением — центром сертификации (CA — certification
autority).
Сертификат открытого ключа — структура данных, состоящая их раздела данных и
раздела подписи.
Раздел данных содержит открытые данные, которые включают, как минимум, открытый
ключ и строку, идентифицирующую сторону (представляемый объект) для связывания с ним
при условии, что открытый ключ подписывающего известен заранее.
Раздел подписи состоит из цифровой подписи органа сертификации под разделом данных.
Тождественность представляемого объекта, таким образом, связывается с заданным открытым
ключом. На практике наиболее часто используются сертификаты формата Х.509 v3.
Орган сертификации (CA — certification autority) — доверенная третья сторона, чья
подпись под сертификатом подтверждает подлинность открытого ключа, связанного с пред-
ставляемым объектом.
Простейшую модель PKI можно построить из одного компонента, который называется
издателем (issuer). Он выполнял бы все необходимые функции. Пользователи использовали бы
криптографию с открытым ключом в своих приложениях, получая и обрабатывая сертификаты
и список аннулированных сертификатов (CRL). В рамках одного компонента трудно
обеспечить необходимый уровень защищенности при выполнении всех необходимых задач,
связанных с созданием и распространением сертификатов и CRL. Поэтому обычно PKI
строится из различных компонентов, каждый из которых предназначен для
специализированного выполнения нескольких задач.
5.7. Аутентификация с помощью открытого ключа

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

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

открытого ключа для получения подлинного открытого ключа пользователя, состоит из
следующих этапов:
1. Получение подлинного открытого ключа CA (одноразовый процесс).
2. Получение идентификатора пользователя.
3. Получение по незащищенному каналу от этого пользователя его сертификата открытого
ключа (согласующегося с его идентификатором).
4. Проверка текущей даты и времени относительно срока действия, указанного в сер-
тификате (при проверке используются локальные доверенные часы);
5. Проверка текущей действительности открытого ключа СА.
6. Проверка подписи под сертификатом пользователя с помощью открытого ключа СА;
7. Проверка того, что сертификат не был отозван.
8. Если все проверки успешны, то сервер аутентификации принимает открытый ключ в
сертификате как подлинный открытый ключ данного пользователя.
5.8. Организация хранения закрытого ключа

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

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

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

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

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

создается ключевой контейнер, содержащий зашифрованное
значение закрытого ключа.
5.8.3. Touch Memory, Memory-карты

В качестве носителя информации можно использовать специализированные устройства
аутентификации — touch memory (электронные ключи в виде так называемых «таблеток») и
Memory-карты, выполненные в виде пластиковых карт примерно такого же размера, как и
кредитные карты, но с встроенной микросхемой. И тот и другой тип устройств представляют
собой сменный носитель информации с уникальным номером, прошиваемым при
изготовлении, и памятью, в которой можно хранить данные пользователя.
Некоторые типы подобных устройств аутентификации предусматривают возможность
двухфакторной аутентификации, требуя ввод PIN-кода для доступа к содержимому
пользовательской памяти.
5.8.4. Смарт-карты и USB-ключи

Смарт-карты (как и Memory-карты) представляют собой пластиковые карты с встроенной
микросхемой. Однако смарт-карты представляют собой более сложное устройство
аутентификации, содержащее микропроцессор и операционную систему, контролирующую
устройство и доступ к объектам в его памяти. Кроме того, смарт-карты, как правило, обладают
возможностью проводить криптографические вычисления.
Смарт-карты находят все более широкое применение в различных областях, от систем
накопительных скидок до кредитных и дебетовых карт, студенческих билетов и телефонов
стандарта GSM.
Несмотря на название — устройства для чтения смарт-карт, как и большинство оконечных
устройств или устройств сопряжения (IFD) способны как считывать, так и записывать
информацию, если позволяют возможности смарт-карты и права доступа. Устройства для
чтения смарт-карт могут подключаться к компьютеру с помощью:
• последовательного порта;
• слота PCMCIA;
• порта USB.
Устройства чтения смарт-карт могут быть интегрированы в клавиатуру.
Некоторые производители выпускают другие виды аппаратных устройств, в которых
смарт-карты объединены с устройством чтения смарт-карты. По свойствам памяти и вы -
числительным возможностям они полностью аналогичны смарт-картам.
Наиболее популярны аппаратные «ключи», использующие порт USB. USB-ключи
привлекательны для некоторых организаций, поскольку USB становится стандартом,
находящим все большее распространение в новых компьютерах: организации не нужно
приобретать для пользователей какие бы то ни было считыватели.
Смарт-карты и USB-ключи по своим возможностям являются интеллектуальными
устройствами.
51
5.9. Интеллектуальные устройства и

аутентификация с помощью открытого ключа
Смарт-карты и USB-ключи могут повысить надежность служб инфраструктуры открытых

ключей PKI (Public Key Infrastructure): смарт-карта может использоваться для безопасного
хранения закрытых ключей пользователя, а также для безопасного выполнения
криптографических преобразований. Безусловно, интеллектуальные устройства
аутентификации не обеспечивают абсолютную защиту, но их защита намного превосходит
возможности обычного компьютера.
Для хранения и использования закрытого ключа разработчики используют различные
подходы. Наиболее простой из них — использование интеллектуального устройства в качестве
дискеты: при необходимости карта экспортирует закрытый ключ, и криптографические
операции осуществляются на рабочей станции. Этот подход является не самым совершенным
с точки зрения безопасности, зато относительно легко реализуемым и предъявляющим
невысокие требования к интеллектуальному устройству.
Два других подхода более безопасны, поскольку предполагают выполнение интел-
лектуальным устройством криптографических операций. При первом пользователь генерирует
ключи на рабочей станции и сохраняет их в памяти устройства. При втором пользователь
генерирует ключи при помощи самого устройства и хранит их в его памяти. В обоих случаях,
после того как закрытый ключ сохранен, его нельзя извлечь из устройства и получить любым
другим способом.
Пользователь генерирует ключи на рабочей станции и

сохраняет их в памяти устройства.
5.9.1. Генерация ключей вне устройства (рис. 5.4)
В этом случае пользователь может сделать резервную копию закрытого ключа. Если
устройство выйдет из строя, будет потеряно, повреждено или уничтожено, пользователь
сможет сохранить тот же закрытый ключ на новой карте. Это необходимо, если пользователю
требуется расшифровать какие-либо данные, сообщения, и т. д., зашифрованные с помощью
соответствующего открытого ключа. Однако закрытый ключ пользователя в этом случае
может быть похищен.
5.9.2. Генерация ключей с помощью устройства (рис. 5.5)
В этом случае закрытый ключ не выходит из устройства, а также нет риска, что зло-
умышленник украдет его резервную копию. Способ использования закрытого ключа —
обладание интеллектуальным устройством. Будучи безопасным, это решение выдвигает вы-
сокие требования к возможностям интеллектуального устройства: оно должно генерировать
ключи и осуществлять криптографические преобразования. Также предполагается, что
закрытый ключ не может быть восстановлен в случае выхода устройства из строя.
52
Смарт-карта
Выполнение
криптографических
операций
Рис. 5.4. Генерация ключей вне устройства
Рис. 5.5. Генерация ключей с помощью устройства

Пользователь генерирует ключи с помощью самого устройства и хранит их в его памяти
53
Защита от данной атаки
Описание атаки Факторизация
ключа
Существенное увеличение размеров ключей — на данный
Злоумышленник может разложить ключ на момент рекомендуется использовать ключи длиной не
множители и вывести значение личного менее 512 бит. Для центров сертификации рекомендуется
ключа пользователя. использовать ключи длиной 2048 бит.
Атака по известным сообщениям

Хэшированная цифровая подпись — владелец формирует
Злоумышленник подготавливает специ- подпись для сообщения, подписывая своим личным
альное сообщение и принуждает владельца ключом хэшированное значение сообщения.
подписать его личным ключом. Данный
результат после преобразования может быть
использован злоумышленником для
формирования нового сообщения и выдачи
его за сообщение от владельца личного
ключа.
Подделка открытого ключа
Сертификаты открытого ключа — публикуется назначение
Злоумышленник может подставить свой ключа владельца, и под этой публикацией ставится
собственный открытый ключ, если полу- заслуживающая доверия подпись.
чатель принимает неаутентифицированные
ключи.
Атака «Человек посередине»
Сертификаты открытого ключа — как для «Подделки
Злоумышленник подставляет свой собст- открытого ключа» (см. выше).
венный открытый ключ вместо другого
ключа и заново шифрует сообщения между
объектами.
Фиктивное имя в сертификате
Требование владения ключом — Сертификаты выдаются
Злоумышленник ставит имя жертвы в заявке только лицу, которое владеет запрошенным именем.
на получение сертификата открытого ключа.
Подмена сертификата
Злоумышленник использует законный Проверка достоверности имени хоста в сертификате — имя в

сертификат для поддельного сервера с сертификате сравнивается с именем хост-машины, от
другим IP-адресом. который получен данный сертификат.
Эффективной защиты на данный момент нет.
Злоумышленник использует фиктивный
орган выдачи сертификатов для создания
поддельных сертификатов и затем за-
ставляет браузеры принять его открытый
ключ данного центра.
Фиктивный центр выдачи сертификатов
54
Использование личного ключа

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

Личный ключ на смарт-карте — личный ключ хранится на
Злоумышленник использует программу смарт-карте, а не в зашифрованном файле.
взлома для получения доступа к личному
ключу законного пользователя, хранимого на
локальном компьютере.
Активная разведка личного ключа
Реализация функции шифрования по личному ключу на смарт-

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

личного ключа, хранимого на дискете или в Создание
генерируется на смарт-карте и никогда ее не покидает.
другом устройстве.
Примечания
• При аутентификации с помощью открытых ключей целесообразно использовать
интеллектуальные устройства аутентификации. При этом весьма важным является
исключительное владение пользователя закрытым ключом, т.е. обеспечение его за-
щиты от компрометации. Это невозможно, если закрытый ключ хранится или крип-
тографические преобразования осуществляются на компьютере пользователя.
• При аутентификации с помощью открытых ключей пользователь может допустить
халатность 1-го типа: интеллектуальные устройства могут быть оставлены на рабочей
станции. Если пользователь, отходя от своего рабочего места, оставляет смарт-карту в
устройстве чтения или USB-ключ в порту, кто-то другой в офисе может легко
представиться данным пользователем. Защита с помощью PIN-кода эффективна, если
сеансы пользователей блокируются после определенного промежутка бездействия, а
для разблокирования необходима повторная аутентификация. Но PIN-коды можно
узнавать, например, «подглядывая из-за плеча». Организа
55
ции должны призывать пользователей всегда носить интеллектуальные устройства с

собой. Это обеспечивается автоматически, если устройства используются для
контроля физического доступа в помещения.
• При аутентификации с помощью открытых ключей пользователь может допустить
халатность 2-го типа: интеллектуальные устройства могут быть утеряны. Организация,
в которой используются интеллектуальные устройства аутентификации, будет
вынуждена каждому пользователю, потерявшему свое устройство, выдавать новое
временное устройство или временно осуществлять аутентификацию с помощью
альтернативного метода. При этом организация должна следить за тем, чтобы
подобные мероприятия не ослабляли безопасность.
• Интеллектуальные устройства могут быть уязвимы по отношению к логическим и
физическим атакам, а также атакам «троянских коней». Каждая организация,
использующая интеллектуальные устройства с целью обеспечения безопасности,
должна быть уверена в том, что производители устройств и разработчики про-
граммного обеспечения позаботились о принятии соответствующих логических и
архитектурных контрмер. Правда, эти меры могут отрицательно повлиять на удобство
использования интеллектуального устройства. Логические атаки осуществляются,
когда интеллектуальное устройство работает в обычных физических условиях, а
важная информация в виде байтов поступает на вход или снимается с выхода
интеллектуального устройства. Физические атаки возможны, когда изменяются
физические параметры, такие как: температура, частота, напряжение — с целью
получения доступа к важной информации в памяти интеллектуального устройства.
Атаки «троянских коней» предполагают размещение несанкционированного при-
ложения на рабочей станции пользователя. Троянская программа ждет, пока поль-
зователь введет действительный PIN-код в приложении, которому он доверяет, что
сделает возможным использование закрытого ключа, а после этого предложит
интеллектуальному устройству выработать цифровую подпись несанкционированных
данных.
1. Из каких элементов состоит ключевая пара и для чего предназначен каждый элемент?
2. Что такое электронная цифровая подпись? Приведите примеры использования.
3. В каких случаях можно использовать криптографию с открытым ключом?
4. Приведите пример использования криптографии с открытым ключом для шифрования
сообщения.
5. Приведите пример аутентификации пользователя с помощью открытых ключей.
6. Для чего предназначена инфраструктура открытых ключей (PKI)?
7. Назовите способы хранения закрытого ключа.
8. Назовите недостатки аутентификации с помощью открытых ключей.
открытых ключей, и способы защиты от подобных атак.
56
Глава 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, выполняемым с помощью автономно работающих программ-взлом-
57
щиков, и к атакам программ-взломщиков, работающих с перехваченными парами «запрос-

ответ».
Классические варианты атак на базу данных SAM появились как результат работ в рамках
проекта Samba и привели к разработке бесплатно распространяемого пакета, позволявшего
коллективно пользоваться файлами между UNIX-серверами и NT-клиентами. Для
синхронизации паролей UNIX-серверу необходимо получение копий значений хэш-функции
паролей NT-пользователей. Чтобы извлекать значения хэш-функции с целью выполнения над
ними атаки угадывания методом проб и ошибок, взломщиками также использовалось
инструментальное средство типа pwdump или его разновидности.
6.1.2. Хэширование в LANMAN

Рассмотрим, как функция хэширования в LANMAN преобразует принадлежащий
пользователю длинный пароль (рис. 6.1).
Сначала функция изменяет пароль до вида 14-символьной цепочки, при необходимости
добавляя или удаляя символы. Затем преобразует все символы в символы верхнего регистра.
Это хороший ход с точки зрения удобства пользования, так как, несмотря на ошибки,
сделанные пользователем при работе с клавишей <Shift>, система все равно распознает его
пароль. Однако это снижает энтропию пароля.
После этого функция разделяет результат на два семибайтовых фрагмента и использует
каждый из них в качестве 56-разрядного ключа для шифрования с помощью алгоритма DES.
Каждый такой ключ используется для отдельного шифрования 64-разрядной константы. В ОС
UNIX алгоритм DES используется так же, только LANMAN опускает добавку.
Длинный LANMAN-пароль пользователя
LongStringofLetters
Ключ для DES Ключ для DES

Преобразование из левой половины из правой половины
в 14 или менее
символов верхнего
регистра, разделение
на две половины,
добавление знаков
четности для
алгоритма DES
ХЭШ строится путем

стыковки левого и правого
шифрованных значений
Z 27F83K5K9465490F9GOWEVJU67098JSON76956KYSHD76J5C3
Рис. 6.1. Хэширование в LANMAN
58
Глава 6. Протоколы аутентификации в локальной сети
Результаты шифрования соединяются в одну цепочку, образуя окончательный хэшированный

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

LANMAN не всегда использует пароли типа «запрос-ответ», так как другие сетевые
продукты требуют применения паролей в виде открытого текста. Это особенно важно при
совместной работе с другими продуктами. Например, некоторые версии пакета Samba для
размещения Windows-совместимых сетевых служб на UNIX-системах использовали прямые
текстовые пароли. Продукты семейства Windows, включая NT, имеют необходимые
специальные программные модули, которые позволяют до некоторой степени авто-
матизировать процесс регистрации в службах, требующих пароли в виде открытого текста.
Администраторы могут устанавливать специальный конфигурационный флаг в реестре ОС
Windows, позволяющий использовать прямые текстовые пароли. В ОС Windows NT
использование подобных паролей затруднено, так что администраторы предупреждаются о
потенциальном риске перехвата паролей.
Поддержка прямых текстовых паролей служит причиной потенциальной проблемы,
называемой «атакой под старину». В процессе этой атаки взломщик заставляет клиента
поверить, что он должен предоставить серверу данные аутентификации в виде открытого
текста. Клиент отвечает, автоматически предоставляя прямой текстовый пароль вместо его
хэширования и использования.
Поддержка прямых текстовых паролей служит причиной

потенциальной проблемы, называемой «атакой под старину».
6.1.4. Метод «запрос-ответ» в LANMAN, NTLM

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

перехватывает запрос и генерирует ответ на основе
пароля владельца.
В общем случае рабочая станция хранит копию хэша пароля, и пользователю не придется
вводить его снова при следующем входе в систему. Наконец, рабочая станция вы
59
числяет ответ, трижды используя алгоритм 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-системам обеспечить
преемственность со старым сетевым про
60
Маскировка под другого человека

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

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

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

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

Внедрение украденного значения хэша в базу
данных SAM и такая модификация ОС Исключение хранения базового секрета в ОС
Windows NT, в результате которой ОС Windows роль базового секрета играет хэш. Такая атака
пользователь выглядит успешно прошедшим может быть сорвана, только если исключить хранение
процедуру регистрации в системе. базового секрета внутри уязвимой операционной системы
Windows. В рамках протоколов LANMAN и NTLM
решения нет. Один из возможных подходов используется в
протоколе Kerberos.
61
5.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.
5.2.1. Архитектура, компоненты, участники протокола

В 1983 г. в МТИ (Массачусетском Технологическом институте) был начат проект
«Афина», целью которого было создание модели предполагаемой среды распределенных
вычислений следующего поколения для академических организаций. Группа участников
проекта «Афина» решила задачу безопасности, связанную с KDC, на основе протокола
Нидхэма—Шредера, но с учетом результатов работы Деннинга и Сакко. Чтобы обеспечить
работу протокола Kerberos в крупномасштабных средах, проект «Афина» должен был
предложить программное обеспечение для обработки процедуры регистрации на клиентских
рабочих станциях и адаптировать серверы для работы с протоколом Kerberos. Программное
обеспечение, адаптированное под работу с протоколом Kerberos, обычно называют
керберезированным.
62
К 1989 г. Стив Миллер (Steve Miller) и Клиффорд Ньюмэнн (Clifford Neumann) с помощью
других сотрудников МТИ сделали четыре версии протокола Kerberos. Версия 4 была первой
выпущенной в общее пользование версией протокола, которая используется до сих пор.
Однако стандартной версией для Internet-сообщества стала версия 5.
Сервер аутентификации
Центр распределения ключей протокола Kerberos состоит из нескольких серверов, которые
выполняют различные функции. Сервер аутентификации реализует протокол, сходный с
протоколом Нидхэма-Шредера. Теоретически этот сервер может выдавать мандаты для обмена
данными с любой керберезированной службой. На практике большинство рабочих станций
использует сервер аутентификации только в целях выдачи мандатов для связи со службой
выдачи разрешений на получение мандатов.
Чтобы получить мандат от сервера аутентификации, пользователь должен сконструировать
сообщение KRB_AS_REQ. Сервер аутентификации отвечает сообщением KRB_AS_REP,
которое содержит мандат и соответствующую статусную информацию. Запрашивая мандат, он
предоставляет данные о своей личности, имя сервера и случайное одноразовое число.
Протокол устанавливает временной период, в течение которого будет действовать коллективно
используемый ключ, называемый в протоколе Kerberos ключом сеанса. Протокол также вводит
в шифруемую по ключу часть идентификатор рабочей станции, с помощью которого он может
контролировать, каким рабочим станциям разрешено использовать конкретный мандат. Это
снижает вероятность несанкционированного использования мандата. Сервер аутентификации
отвечает сообщением KRB_AS_REP, которое содержит мандат и соответствующую статусную
информацию.
Чтобы получить мандат от сервера аутентификации,

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

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

Пользователь использует мандат протокола Kerberos и соответствующий ключ сеанса для
создания сообщения KRB_AP_REQ, чтобы аутентифицировать себя, например, почтовому
серверу. Кроме мандата, пользователь предоставляет еще и так называемый аутентификатор
протокола Kerberos, который представляет собой шифрованный элемент данных, содержащий
имя пользователя (Пользователь) и временною метку. Для шифрования аутентификатора
пользователь применяет тот же ключ сеанса, который был в мандате (рис. 6.2).
Сервер дешифрует полученный мандат, извлекает из него ключ сеанса и использует его для
дешифровки аутентификатора. Имя пользователя в аутентификаторе должно
63
Имя Имя ' Период Случайное Рабочая
пользователя сервера действия число станция
совпадать с именем пользователя в мандате, а временная метка должна быть не очень старой
— обычно в пределах последних пяти минут.
Если запрос проходит эти тесты, сервер посылает ответное сообщение KRB_AP_REP
(если пользователь о нем просит). В этом ответе посылается временная метка из запроса,
шифрованная с использованием ключа сеанса. Как и в случае протокола Нидхэма—Шредера,
ответ имеет смысл, только если алгоритм шифрования не допускает выполнения атак с
помощью переписывания или редактирования методом вырезки и копирования.
' Рабоча
Имя ' Имя Период Ключ я
пользовате сервер действи сеанс станци
Запрос
ля а от пользователя
я а (сообщение
я протокола Ktuberos KRB_AS_REP)
Имя Период Случайное Ключ
сервера действия число сеанса
Сгенерированный
случайным образом
" ключ сеанса
Имя Имя ' Период" Ключ Рабочая Имя Период Случайное Ключ
пользователя сервера действия сеанса станция сервера действия число сеанса
1
Мастер-ключ Мастер-ключ
сервера пользователя Ключ сеанса и
подтверждающие данные
для рабочей станции
пользователя
Поле Назначение
Имя пользователя Клиент, который запрашивает мандат
Ответ, посланный пользователю (сообщение протокола Ktuberos KRB_AS_REP) Рис. 6.2.
Имя сервера Нужная служба. Этот мандат шифруется с использованием мастер-ключа сервера
Аутентификация для сервера (табл. 6.2)
Период действия Время, когда мандат и соответствующий ему ключ сеанса начинают действовать, и
время, когда ключ и мандат теряют свою дееспособность Таблица 6.2
Состав и наименование полей
Ключ сеанса Секретный ключ, коллективно используемый сервером и пользователем
Идентификатор компьютера (или компьютеров), на котором «может» работать

Рабочая станция пользователь
64
Имя Имя Период Ключ Рабочая
пользователя сервера действия сеанса станция
Служба выдачи разрешений на получение мандата (рис. 6.3)

Хотя сервер аутентификации протокола Kerberos можно использовать для генерации
мандатов на работу с отдельной службой, однако проблема заключается в том, что протокол
Kerberos требует использования мастер-ключа для обработки сообщений, которыми
обменивается пользователь с сервером аутентификации, а большинство людей, работая на
компьютере, обычно используют множество служб. Если мастер-ключ хранится на рабочей
станции в то время, когда на ней кто-то работает, то существует риск его похищения.
Чтобы устранить эту проблему, мастер-ключом надо пользоваться как можно более
короткий промежуток времени и убирать его из рабочей станции как можно быстрее. Но это
приводит к другой проблеме: если мы стираем мастер-ключ после завершения подключения к
одному серверу, то нам надо прочитать его снова при попытке подключиться к другому.
Традиционно в протоколе Kerberos в качестве мастер-ключей пользователей используются
запоминаемые пароли, так что в этом случае придется мириться с бесконечными запросами на
ввод пароля. Ни одна из альтернатив не является практичной.
Имя Временная
пользователя метка В протоколе Kerberos в качестве мастер-ключей
пользователей используются запоминаемые пароли.
Таким образом, возникает та же дилемма, которая привела к возникновению ключей

сеанса: нужно вводить временный ключ, который можно использовать для выдачи других
временных ключей. Действительно, проблема решается таким же образом: вместо того чтобы
оставлять мастер-ключ в рабочей станции во время регистрации пользователя, вводится
специальный ключ сеанса, который можно использовать для выпуска мандатов. Здесь
используется хорошо известная в вычислительной технике практика: часто проблему можно
решить, введя еще один уровень косвенности.
В протоколе Kerberos этот дополнительный временный ключ реализуется путем до-
бавления к серверу KDC специального сервера, называемого сервером выдачи разрешений на
получение мандатов. Этот сервер работает с мандатами, которые, конечно, называются
Имя Имя Период Ключ Рабочая Имя Временная
©
пользователя сервера, действия сеанса станция пользователя метка
Ключ
V
сеанса
Мандат сервера
■ Шифрование
Мандат сервера Аутентификатор
Рис. 6.3. Запрос серверу от пользователя (Сообщение протокола Kerberos KRB_AP_REQ)
65
секретных ключей
KDC
протокола
Kerberos
h
Служба
Ключ мандата
выдачи
Ответ разрешения
почтового
сервера
Запрос почтовому Служба выдачи
серверу, содержащий разрешения
Т ■ мандат
Почтовый
сервер
(
Серверное ПО на основе
протокола Kerberos
Рис. 6.4. Взаимодействие рабочей станции KDC протокола Kerberos и почтового сервера
разрешениями на получение мандатов (ticket-granting ticket, TGT). Пользователи могут по-

сылать свои TGT этому специальному серверу, чтобы запрашивать мандаты для других служб.
В предыдущих примерах рассматривался случай установления Пользователем соединения
с почтовым сервером через KDC (рис. 6.4). На практике Пользователь будет устанавливать
связь не только с почтовым сервером. Скорее всего, он, как обычно, подключится к двум или
более файл-серверам, одному или двум серверам печати, а также к другим службам.
Несомненно, рабочая станция пользователя будет подключаться к некоторым из этих служб
автоматически в момент его регистрации в системе. Но могут быть и другие службы, которые
не входят в список регулярно используемых, или такие, к которым нет смысла подключаться
без необходимости.
Благодаря серверу выдачи разрешений на получение мандатов обеспечивается относи-
тельно безопасный и дружественный к пользователю механизм однократной регистрации.
Когда пользователь регистрируется на своей рабочей станции, она немедленно свя-
зывается с сервером аутентификации KDC протокола Kerberos и получает TGT. После этого
рабочая станция получает пароль пользователя (или другие данные аутентификации) и
использует их для дешифровки ответа от сервера аутентификации.
Затем она пересылает TGT серверу выдачи разрешений на получение мандатов, чтобы
получить мандаты на доступ к службам, немедленно необходимым пользователю: к обычно
используемым им файл-серверам, почтовому серверу, серверу печати. Позднее рабочая
станция может снова обратиться к серверу выдачи разрешений за дополнительными
мандатами, если пользователю понадобятся дополнительные серверы. Рабочей станции
больше не надо запрашивать у пользователя ввод пароля, так как для получения допол-
нительных мандатов она просто использует TGT и соответствующий ключ сеанса.
66
Сервер выдачи разрешений имеет собственный ключ, который используется протоколом

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

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

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

Протоколы KDC, подобные протоколу Kerberos, в действительности уделяют основное
внимание аутентификации пользователей сетевым службам. Классические протоколы слабо
или вообще никак не обеспечивают установление личности пользователя для рабочей станции
или даже KDC. Ничто не мешает кому угодно, включая взломщика, обратиться с запросом на
получение мандатов для аутентификации конкретному серверу. Имея возможность
устанавливать связь с KDC пользователя, любой может послать сообщение, заявляющее, что
он — пользователь, и получить мандат для аутентификации почтовому серверу.
Рассматриваемые далее протоколы гарантируют невозможность использования взломщиками
полученных ими мандатов.
Данная ситуация имеет два интересных следствия. Во-первых, это означает, что протокол
Kerberos не обязательно рассматривает сами рабочие станции как отдельные объекты, которые
требуют аутентификации. Вместо этого подразумевается, что они являются
взаимозаменяемыми устройствами, как это и имеет место в среде академических лабораторий.
Во-вторых, у взломщиков есть возможность получить достаточное число мандатов,
относящихся к конкретному человеку, чтобы провести атаку на его мастер-ключ. К счастью,
эти следствия можно устранить, используя некоторые варианты реализации протокола
Kerberos.
Аутентификация рабочих станций

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

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

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

вычислений с «тонким клиентом». Если клиентские рабочие станции просты и достаточно
однородны в сети, то они могут быть взаимозаменяемыми. Не имеет значения, какая рабочая
станция обслуживает пользователя; основной целью аутентификации является запрет
использования не принадлежащих ему ресурсов.
Однако подобное видение не соответствует реальной практике, существующей в орга-
низациях, где преобладают персональные компьютеры на столах сотрудников. В каждом
персональном компьютере имеются локальные файлы, принадлежащие конкретному
владельцу или хранителю. Во многих случаях на нем установлено программное обеспечение,
лицензированное на имя его владельца. Если протокол Kerberos будет аутентифицировать
любого на каждой рабочей станции, то он не позволит контролировать доступ к таким
персональным ресурсам. В подобных случаях рабочая станция должна иметь дополнительную
процедуру аутентификации. Это может быть прямая аутентификация или основанная на
протоколе Kerberos пред аутентификация, которая описывается ниже в этом разделе. Компания
Microsoft в ОС Windows 2000 использовала комбинацию этих методик.
В случае мандатов протокола Kerberos риск состоит в том, что взломщики могут получить
достаточное число мандатов, предназначаемых какому-нибудь важному пользователю, чтобы
провести успешную атаку на его мастер-ключ. В классической среде Kerberos это является
серьезной угрозой, так как основой персональных мастер-ключей служат запоминаемые
пароли.
Предаутентификация
В протоколе Kerberos версии 5 была введена предаутентификация, поэтому серверы
могли аутентифицировать запросы, посылаемые KDC, а не полагаться на аутентификацию
запросов, выполняемую ими потом. Администраторы могут сконфигурировать Kerberos таким
образом, что он будет требовать аутентификации при запросе мандатов или TGT. При этом
KDC осуществляют рассылку шифрованных данных только тем, кто уже знает
соответствующий ключ. Обычно процесс используется для аутентификации пользователя,
получающего от KDC начальный TGT, хотя протокол способен поддерживать широкий набор
альтернатив. Начальная предаутентификация должна быть доступна в виде опции в любой
совместимой версии протокола Kerberos.
При традиционной Kerberos-аутентификации рабочая станция получает ключи от KDC до
того, как ей нужен мастер-ключ пользователя. Так как в протоколе Kerberos в качестве мастер-
ключа обычно используются пароли пользователей, то рабочая станция может отложить
запрос пароля до момента получения отклика от KDC. В случае предаутентификации рабочая
станция должна сначала получить мастер-ключ пользователя, что обычно означает получение
пароля.
68
Повторное воспроизведение со старыми ключами
Маскировка под другого человека Взломщик Механизм «запрос-ответ» в работе протокола KDC с сервером
посылает серверу ранее выпущенный мандат и Сервер посылает пользователю запрос, который требует
воспроизводит посланные клиентом ранее ответа, зависящего от данных пользователя, шиф-
сообщения, шифрованные с помощью этого рованных с помощью ключа сеанса.
ключа.
Автономный взлом и воспроизведение
Атакующая сторона в автономном режиме Временная метка в протоколе KDC Сообщения KDC
взламывает ключ сеанса и использует полу- включают информацию о времени суток, что позволят
ченные сведения для повторного использо- обнаруживать попытки повторного использования
вания мандата, выпущенного с этим ключом. мандатов.
Автономный взлом мастер-ключа
Атакующая сторона запрашивает мандаты от Предаутентификация в KDC

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

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

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

ОС Windows 2000 и последующих ОС
Начиная с ОС Windows 2000, компания Microsoft заменила механизм доменной аутен-
тификации ОС Windows NT, основанный на NTLM, на протокол Kerberos. Процедура
доменной регистрации Windows превратилась в транзакцию, результатом которой является
получение TGT. Отображение на файл-сервер теперь связано с обменом мандатами и ключами
сеанса. Мастер-ключи и другая важная с точки зрения защиты информация хранятся в так
называемой активной директории. Хотя реализация протокола Kerberos в ОС Windows имеет
ряд отличительных элементов, компания Microsoft заявляет, что ее вариант будет
удовлетворять всем требованиям совместимости со стандартным протоколом Kerberos. В
частности, керберезированные Не-Wmdows-приложения будут способны обрабатывать
мандаты Windows, обеспечивая возможность однократной регистрации между Windows- и He-
Windows-приложениями.
Благодаря протоколу Kerberos ОС Windows 2000 и последующие ОС по сравнению с более
ранними продуктами семейства Windows имеют три существенных преимущества:
1. Обеспечивается более быстрая аутентификация на сервере, так как серверу не надо
связываться с контроллером домена для непрямой аутентификации. Вместо этого сервер
просто обрабатывает мандат.
2. Windows использует функции делегирования мандатов для передачи прав доступа
пользователя к серверу посредством другого сервера.
3. Windows использует протоколы Kerberos, которые позволяют центрам распространения
ключей, принадлежащим другим организациям, выдавать права доступа пользователям,
работающим через другие центры распределения ключей контролируемым образом.
Мастер-ключи и аутентификация рабочих станций

Конечно, при вводе технологии Kerberos в продуктовую линию Windows неизбежны до-
работки. Компании Microsoft надо было придерживаться основной линии, чтобы сохранить
совместимость с существующими продуктами и одновременно извлечь хотя бы некоторые
преимущества из защитных функций протокола Kerberos. Это особенно заметно в том, как
Microsoft адаптировала Kerberos к процессу регистрации в рабочей станции ОС Windows.
Как и предполагается, пользователь рабочей станции не видит ничего нового. Когда
пользователь пытается зарегистрироваться, он нажимает на клавиатуре обычные клавиши и
видит на экране паролевый диалог. Он вводит свое имя пользователя, выбирает домен и
набирает на клавиатуре пароль. Но на системном уровне Windows преобразует все это в
транзакции протокола Kerberos.
70
4. Извлечение TGT
для пользователя
«Пользователь»
KDS домена
1. Регистрация
пользователь:
«Пользователь»
пароль: asdt
/ Служба локальной
защиты на станции bat 5. Предоставление
мандата пользователь:
«Пользователь» 4. Использование
для станции bat мандата
Мастер-ключ пользователь:
станции bat «Пользователь»
Ресурсы для станции bat
станции 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).
71
• Затем LSA инициирует SSP-процесс протокола Kerberos и передает ему имя поль-
зователя и мастер-ключ. В отличие от традиционного протокола Kerberos, в ОС
Windows 2000 мастер-ключ оставляется в кэше. Это позволяет рабочей станции
использовать механизм доменной аутентификации ОС Windows NT, если необходимо
обмениваться данными с более старыми серверами. Очевидно, что держать такую
информацию в кэше — это риск, причем совершенно ненужный, если во всей
организации используется механизм аутентификации протокола Kerberos.
• Процесс SSP протокола Kerberos пытается связаться со своим контроллером домена и
получить начальный TGT на имя пользователя. Запрос использует пред-
аутентификацию, основанную на мастер-ключе пользователя.
• Если выбранный домен управляется более старым Windows NT-сервером и протокол
Kerberos недоступен, то процесс LSA выполняет откат и использует NLTM -протокол.
• Если процесс 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;
• аутентификация запросов об уровнях качества обслуживания.
72
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. Также ее можно исполь-
зовать для генерации коллективно используемого секрета временными ключами алгоритма
Диффи—Хеллмана. В этом случае предаутентификационный запрос пользователя содержит
временный ключ Диффи—Хеллмана. По-прежнему пользователь должен под-
Имя владельца: www.bank.com Открытый ключ: 3,5555 Цифровая подпись ЛИЧНый

ключ органа
по выдаче
сертификатов
Рис. 6.6. Методика PKINIT (Public Key Initialization)
73
писать запрос отдельным ключом и предоставить копию сертификата ключа его подписи.
Перед генерацией 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-ключи. Служба управления ресурсами смарт-карт была
интегрирована в операционную систему, и для настройки аутентификации по сертификатам
достаточно активизировать данную службу, установив драйверы считывателей смарт-карт.
При нахождении в домене графический интерфейс OC Windows 2000 (GINA) заменяется
вариантом с поддержкой работы со смарт-картами.
На смарт-карту записывается сертификат и связанный с ним закрытый ключ, выписанные
на доменном центре сертификации с использованием политик, предусматривающих
возможность его использования для интерактивной аутентификации пользователя в системе.
При подключении смарт-карты к рабочей станции для аутентификации пользователя,
хранящийся на ней сертификат используется для запроса TGT, а операция с закрытым
ключом, возможная после ввода PIN-кода, используется для подписания этого запроса.
На смарт-карту записывается сертификат и связанный с ним

закрытый ключ.
74
6.3.2. Возможности использования

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

используется технология PKINIT.
Начальная аутентификация осуществляется путем отправки CMS (Cryptographic 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 и международные стандарты
75
Подделка открытого ключа

Если получатель принимает неаутен- Сертификаты открытого ключа
тифицированный ключ, то взломщик Публикуется назначение открытого ключа владельцу, и под
просто подставляет свой собственный этой публикацией ставится заслуживающая доверия цифровая
ключ вместо правильного ключа. подпись.
Человек посередине
Взломщик представляет собственный Сертификаты открытого ключа
открытый ключ вместо другого ключа и Публикуется назначение открытого ключа владельцу, и под
заново шифрует сообщения между двумя этой публикацией ставится заслуживающая доверия цифровая
объектами. подпись.
Фиктивное имя в сертификате
Взломщик ставит имя жертвы в заявке на Требование владения ключом
получение сертификата открытого Сертификаты выдаются только лицу, которое владеет запро-
ключа. шенным именем.
Подмена сертификата
Взломщик использует законный серти- Проверка достоверности имени хоста в сертификате Имя в
фикат для реализации протокола SSL на сертификате сравнивается с именем хост-машины,
поддельном сервере, который выдает участвующей в SSL-соединении.
себя за другой сервер.
Использование личного ключа
Взломщик полагается на автономную Список аннулированных сертификатов Периодически выпускается
аутентификацию и использует укра- список всех сертификатов, которые были аннулированы.
денный личный ключ. Интерактивный отзыв сертификатов Обеспечивается механизм
выполнения запроса органа по выдаче сертификатов для
подтверждения того, что сертификат не был аннулирован.
Периодическая выдача сертификатов
Выдвигается требование, чтобы все сертификаты были выданы
недавно, и обеспечивается механизм, который позволял бы
сертифицирующим органам выпускать такие сертификаты,
если сертификат не был аннулирован.
1. Назовите основные особенности протоколов LAN Manager и NT LAN Manager.
2. Назовите типы аутентификации в NTLM.
протоколов LANMAN и NTLM, и защиты от них.
4. Перечислите преимущества протокола Kerberos.
5. Опишите функции сервера аутентификации, входящего в состав центра распределения
ключей протокола Kerberos.
6. Приведите примеры атак на Kerberos и способы защиты от них.
7. Перечислите преимущества реализации протокола Kerberos в ОС Windows 2000 и
последующих ОС в сравнении с более ранними продуктами семейства Windows.
8. Приведите пример способа интеграции шифрования в протокол Kerberos.
9. Возможные атаки на Kerberos + PKINIT и методы защиты от них?
76
Глава 7 ЧАСТЬ I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
МЕХАНИЗМЫ АУТЕНТИФИКАЦИИ
ПРИ ОСУЩЕСТВЛЕНИИ ПОДКЛЮЧЕНИЙ
7.2. Протокол PPP CHAP
отделения NAS Name: Password
CHAP используется
"Twiggy”для периодической
Timbuktu аутентификации
Twiggy trustme центрального компьютера или
конечного пользователя с помощью согласования J по трем параметрам. Аутентификация
В настоящее
происходит время
L в- -момент методы
J t----------------Z
установления_ использования паролей
связи,1 но может по-прежнему
быть повторена применяются
и после широко.
ее установления.
Механизмы аутентификации
Аутентификация с помощью по протоколу Point-to-Point
протокола CHAP проходитProtocol (PPP) образом
следующим часто используются
(рис. 7.2): в
среде
1. модемного
Маршрутизатор доступа и включают
отделения Twiggiпротоколы Password
устанавливает связь Authentication Protocolдоступа
с сервером сетевого (PAP),
Challenge Handshake Protocol (CHAP) и Extensible Authentication Protocol
(NAS). CHAP обеспечивает безопасность сети, требуя от операторов обмена «текстовым (EAP). Разработка
протокола EAP секретный
секретом». Этот продолжается, но уженесейчас
ключ никогда он использует
передается существующие и только
по каналу связи.
появляющиеся технологии аутентификации в каналах PPP. Протоколы TACACS+ и Remote
Access Dial-In User Service (RADIUS) поддерживают масштабируемые решения в области
Все протоколы рассмотрены Маршрутизатор и сервер доступа
ниже на примерах, в которых при аутентификации взаи-
используют общий секретный ключ «trustme»
модействуют два или более типовых устройств. Инициатором процесса, как правило,
выступает устройство маршрутизатор отделения (назовем его Twiggi), которое обращается к
серверу сетевого доступа (или NAS). Последний выполняет аутентификацию маршрутизатора
Twiggi и принимает решение. Мы будем называть его аутентификатором, а маршрутизатор
Twiggi — аутентифицируемым устройством.
7.1. Протокол PPP PAP

Аутентификация с помощью протокола PAP выполняется следующим образом (рис. 7.1).
1. Инициатор аутентификации, в нашем примере маршрутизатор отделения Twiggi,
обращается к серверу сетевого доступа и устанавливает с ним связь.
2. После установления связи маршрутизатор передает пару «имя устройства—пароль»
серверу NAS до тех пор, пока аутентификация не будет завершена или пока связь не пре -
рвется.
3. После успешной аутентификации маршрутизатор отделения Twiggi получает под-
тверждение.
Протокол PAP не является сильным аутентификационным методом. Он аутентифицирует
только вызывающего оператора, а пароли пересылаются по каналу, который считается уже
«защищенным». Таким образом, этот метод не дает защиты от использования чужих паролей и
неоднократных попыток подбора пароля. Частота и количество неудачных попыток входа в
сеть контролируются на уровне вызывающего оператора.
Маршрутизатор
отделения Twiggy ID Password
NAS Twiggy
■ZL
© Сравнение
(Twiggy, LetMelm) имени и пароля
О
-©
Посылка подтверждения
Рис. 7.1. Аутентификация с использованием протокола PAP
77
Глава 7. Механизмы аутентификации при осуществлении подключений
2. После установления связи аутентификатор передает вызывающему устройству запрос,

который состоит из имени устройства (или его ID), случайного числа и дополнительных
атрибутов, например, имени центрального сервера (при аутентификации в локальной сети)
или имени пользователя (при удаленной аутентификации).
3. Вызывающее устройство проводит вычисления с помощью хэш-функции. Имя уст-
ройства, случайное число и общий «текстовый секрет» один за другим подаются на вход хэш-
функции. После этого вызывающее устройство отправляет серверу ответ, который состоит из
значения хэш-функции и имени центрального сервера (при аутентификации в локальной сети)
или имени пользователя (при удаленной аутентификации).
4. При получении ответа аутентификатор проверяет поставленное в ответе имя и вы-
полняет те же вычисления.
5. Затем результат этих вычислений сравнивается с величиной, поставленной в ответе.
Если эти величины совпадают, аутентификация считается успешной, система выдает со-
ответствующее уведомление и устанавливает связь.
Секретные пароли на локальном и удаленном устройстве должны быть идентичны.
Поскольку «текстовый секрет» никогда не передается по каналам связи, никто не может
подслушать его с помощью каких-либо устройств и использовать для нелегального входа в
систему. Пока сервер не получит адекватный ответ, удаленное устройство не сможет
подключиться к местному устройству.
CHAP обеспечивает защиту от использования чужих паролей за счет пошаговых изме-
нений аутентификатора и применения
Установление переменной
соединения 2 величины запроса. Повторяющиеся
запросы предназначены
Запрос (ID, для ограничения
случайное времени, в течение которого система теоретически
число, Timbuktu)
остается подверженной любой отдельной хакерской атаке. Частоту и количество неудачных
попыток входа в систему контролирует аутентификатор.
© ключ Timbuktu
ID и случайное число
CHAP обеспечивает защиту от использования чужих паролей за
счет пошаговых изменений аутентификатора и применения
) Хэш-функция/ переменной величины запроса.
Примечание
Хэш
Обычно в качестве односторонней хэш-функции CHAP используется MD5, а общий
[BADFOOD]
секрет хранится в текстовой форме. У компании Microsoft есть Секретный ключпротокола CHAP
свой вариант
Ответ на запрос (BADFOOD, Twiggy) Twiggy ID
(MS-CHAP), где пароль<4(на вызывающей машине и D на аутентификаторе) хранится в
шифрованном виде. Это дает протоколу MS-CHAP некоторое преимущество. В отличие от
стандартного протокола CHAP он может использовать доступные базы данных шифрованных
паролей.
УХэш-функция I
7.3. Протокол PPP EAP

Этот общий протокол аутентификации
Сообщение PPP
об успешной поддерживает множество
идентификации Хэш аутентификационных
6 [BADFOOD]
механизмов. EAP не выбирает конкретный аутентификационный Если на этапе контроля
механизм
соединения и откладывает этот выбор до аутентификации. значенияТакой
совпадают, то
идентификация сценарий позволяет
аутентификатору запросить больше информации успешна до определения конкретного
аутентификационного механизма. Кроме того, это дает возможность использовать
Рис. 7.2. Аутентификация с помощью протокола CHAP
79
78
7.4. Протокол TACACS+

«внутренний» сервер, который реально запускает различные механизмы, тогда как
аутентификатор
TACACS+ является
PPP служит
протоколом
лишь для последнего
обмена аутентификационными
поколения из серии данными.
протоколов TACACS.
TACACS с помощью
— это простой протокола
протокол EAP проходит
управления доступом, следующим
основанный образом (рис. 7.3): User
на стандартах
1. Маршрутизатор
Datagram Protocol (UDP),отделения Twiggi Bolt,
разработанных начинает аутентификацию,
Beranek, and Newman, Inc. устанавливая
(BBN) для связь
Militaryс
сервером(MILNET).
Network сетевого доступа NASCisco
Компания (далеенесколько
аутентификатором).
раз совершенствовала и расширяла протокол
2. После
TACACS, установления
и в результате связи аутентификатор
появилась ее собственнаяотправляет один или
версия TACACS, несколько
известная как запросов
TACACS+. для
аутентификации вызывающего его устройства (маршрутизатора Twiggi). В запросе имеется
поле, где указано, что именно запрашивается. Так, например, здесь можно указать такие типы
запросов, как аутентификация MD5, аутентификация с помощью сертификатов X.509,
одноразовых паролей и т. д. При этом запрос
TACACS типапротокол
— это MD5 сходен с протоколом
управления аутентификации
доступом, основанный
CHAP. на стандартах User Datagram Protocol (UDP).
3. Как правило, аутентификатор отправляет первоначальный аутентификационный запрос,
за которым следуют один или несколько дополнительных запросов о предоставлении
TACACS+ пользуется
аутентификационной транспортным
информации. При протоколом TCP. Модуль-демон
этом первоначальный запрос (процесс,
не является за-
пускаемый
обязательнымна имашине
может UNIX или NT)
опускаться сервера когда
в случаях, «слушает» порт 49, который
аутентификация является портом
обеспечивается иными
протокола
способамиIP, выделенным
(при для протокола
связи по выделенным TACACS.
каналам, Этот порт номерам
выделенным зарезервирован
и т. д.).для выделенных
В этих слу чаях
номеров
вызывающаяRFC сторона
в протоколах UDP пакет
отправляет и TCP. Все текущие
ответных данных версии TACACS
на каждый и расширенные
запрос. Как и пакет
варианты этогоответных
запроса, пакет протоколаданных
используют портполе,
содержит 49. соответствующее полю запроса.
Протокол TACACS+завершает
4. Аутентификатор работаетпроцесс
по технологии клиент/сервер,
отправлением где клиентом
пакета, который TACACS+
свидетельствует об
обычно
успешнойявляется NAS, а сервером
или неуспешной TACACS+, как правило, считается «демон» (т. е. процесс,
запускаемый на машине UNIX или NT). Фундаментальным структурным компонентом
протокола TACACS+ является разделение аутентификации, авторизации и учета (AAA —
Authentication, Authorization, Accounting). Это позволяет обмениваться аутентификационными
сообщениями любой длины и содержания, и, следовательно, использовать для клиентов
TACACS+ любой аутентификационный механизм, в том числе PPP PAP, PPP CHAP и Kerberos.
Аутентификация не является обязательной. Она рассматривается как опция, которая
конфигурируется на месте. В некоторых местах она вообще не требуется, в других местах она
может применяться лишь для ограниченного набора услуг.
Обычно аутентификация предшествует авторизации, однако это не обязательно. В запросе
на авторизацию можно указать, что аутентификация пользователя не проведена (личность
пользователя не подтверждена). В этом случае лицо, отвечающее за авторизацию, должно
самостоятельно решить, допускать такого пользователя к запрашиваемым услугам или нет.
Протокол TACACS+ допускает только успешную или неуспешную авторизацию, однако этот
результат допускает настройку на потребности конкретного заказчика. Авторизация может
проводиться на разных этапах, например, когда пользователь впервые входит в сеть и хочет
открыть графический интерфейс или когда пользователь запускает PPP и пытается
использовать поверх PPP протокол IP с конкретным адресом IP. В этих случаях «демон»
сервера TACACS+ может разрешить предоставление услуг, но наложить ограничения по
времени или потребовать список доступа IP для канала PPP.
Учет представляет собой запись действий пользователя и обычно следует за аутен-
тификацией и авторизацией. В системе TACACS+ учет может выполнять две задачи:
1) учитывать использованные услуги (например, выставление счетов);
2) обеспечивать безопасность. Для этого TACACS+ поддерживает три типа учетных
записей. Записи «старт» указывают, что услуга должна быть запущена. Записи «стоп» говорят
о том, что услуга только что окончилась. Записи «обновление» (update) являются про-
межуточными и указывают на то, что услуга все еще предоставляется. Учетные записи
Рис. 7.3. Аутентификация с помощью протокола EAP

81
80
Клиент и сервер TACACS+ должны

иметь общий секретный ключ
TACACS+
4
5
1. Пользователь 4. Клиент TACACS+ посылает

инициирует соединение зашифрованный пакет серверу TACACS+
PPP с сервером доступа
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 всегда отправляются клиентом, а REPLY — сервером.
Аутентификация начинается, когда клиент отправляет серверу сообщение START, которая
описывает тип будущей аутентификации и может содержать имя пользователя и некоторые
аутентификационные данные. Пакет START отправляется только в качестве первого
сообщения аутентификационной сессии TACACS+ или сразу же после повторного запуска
этой сессии. (Повторный запуск может проводиться по просьбе сервера, которая содержится в
пакете REPLY). Пакет START всегда имеет порядковый номер, равный единице.
В ответ на пакет START сервер отправляет пакет REPLY. Сообщение REPLY указывает,
завершилась ли аутентификация или ее следует продолжить. Если пакет REPLY требует
продолжения аутентификации, он также указывает, какую дополнительную ин-
82
I*
CONTINUE | 1*
START
СТ А Г)Т W-
START -------------------rr
GETUSER
Usemame
1 RESPONSE
nrcpnv™
1
CONTINUE
Сервер доступа Сервер безопасности
Username = foo
—i GETPASS '
Password
Password = foopass
PASS/FAIL
Final status
Рис. 7.5. Аутентификация по протоколу TACACS+
формацию ему нужно предоставить. Клиент собирает эту информацию и отправляет ее

серверу в сообщении CONTINUE.
После аутентификации клиент может начать процесс авторизации (если она требуется).
Сессия авторизации состоит из двух сообщений: сообщения REQUEST (запрос) и следующего
за ним сообщения RESPONSE (ответ). Сообщение REQUEST содержит фиксированное число
полей, которые описывают пользователя или процесс, и переменный набор аргументов,
которые описывают услуги и опции, требующие авторизации.
Аутентификация по протоколу TACACS+ происходит так, как показано на рис. 7.5.
Авторизация TACACS+ показана на рис. 7.6.
• Пакеты содержат пары «атрибут-значение»

•Эти пары определяют авторизационные
параметры пользователя
Рис. 7.6. Авторизация по протоколу TACACS+
83
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 может поддерживать разные методы аутентификации пользователя. Если
пользователь предоставит ему свое имя и оригинальный пароль, этот сервер может
поддержать PPP PAP или CHAP, UNIX login и другие механизмы аутентификации. Обычно
регистрация пользователя состоит из запроса (Access Request), который поступает из NAS на
сервер RADIUS, и соответствующего ответа (положительного или отрицательного), который
выдает сервер. Пакет Access Request содержит имя пользователя, шифрованный пароль, IP-
адрес системы NAS и номер порта. Формат запроса дает возможность пользователю запросить
определенный тип сессии. Например, если запрос производится в алфавитно-цифровом
режиме, из этого следует, что запрашивается услуга одного типа ("Service-Type = Exec-User"),
но если запрос делается в пакетном режиме PPP, значит услуга должна быть другой ("Service
Type = Framed User" или "Framed Type = PPP").
Сервер RADIUS может поддерживать разные методы

аутентификации пользователя: PPP PAP или CHAP,
UNIX login и другие механизмы аутентификации.
Когда сервер RADIUS получает от NAS запрос Access Request, он проводит поиск
указанного имени пользователя в базе данных. Если в базе данных такого имени нет, то сервер
загружает стандартный профиль, используемый по умолчанию, или отправляет
84
2. Сервер доступа запрашивает 5. Сервер RADIUS отвечает

у пользователя имя и пароль сообщениями Accept,
Reject или Challenge
3. Пользователь
отвечает на запрос
б. Клиент RADIUS обрабатывает
параметры, полученные от
сервера вместе с сообщениями
Accept или Reject
Рис. 7.7. Взаимодействие между пользователем, клиентом и сервером RADIUS
пользователю отрицательный ответ. Этот отрицательный ответ может при необходимости

сопровождаться текстом, поясняющим причины отказа.
В системе RADIUS функции аутентификации и авторизации совмещены. Если имя
пользователя найдено в базе данных и пароль указан верно, сервер RADIUS выдает по-
ложительный ответ, в котором приводится список пар атрибутов для данной сессии. Ти-
пичными параметрами являются тип услуги (shell или framed), тип протокола, адрес IP,
присваиваемый пользователю (статический или динамический), список объектов доступа или
статический маршрут, который необходимо добавить в таблицу маршрутизации NAS.
Конфигурационная информация на сервере RADIUS определяет, какие средства следует
установить на машине NAS.
В системе RADIUS функции аутентификации и авторизации

совмещены.
Аутентификация и авторизация RADIUS показаны на рис. 7.8.

Учетные функции протокола RADIUS могут использоваться независимо от функций
аутентификации и авторизации. Они позволяют в начале и в конце каждой сессии отправлять
данные о количестве ресурсов (т. е. времени, пакетов, байтов и т. д.), использованных в ходе
этой сессии. Провайдер услуг Интернет (ISP) может использовать программные средства
контроля доступа и учета RADIUS для удовлетворения специальных требований безопасности
и биллинга.
85
Глава 7. МеханизмыЧАСТЬ
аутентификации при осуществлении
I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ подключений
Сервер Сервер
Хранилище
доступа Packet Type = Access Request безопасности
^Ть'ИТНфНкчПГгр и л с1п|с;|ш*..ш1ншипи
KOMMJiTaTOp
Usemame, Password информации
Маршрут штпр
Ta4 k!L ЛГХТН'ПП
Access Accept/ Access Reject I Г>АР
wi AN
User Service, Framed Protocol оопс
Reply Message
2
Рис. 7.8. Аутентификация и авторизация по протоколу RADIUS
SJII|XIC Аутентнфиклцщи
на обс.'1)Ж111Ш1111с BUHMMCBL i «ш t
I ИЮЛИ Ill'll НО I
Транзакции между клиентом и сервером RADIUS аутентифицируются MUHHLilllUKM с помощью общего
«секрета», который
Клиент ПК
никогда не передается tпо -rpik'p
сетевым каналам.llКроме
Jl/Hl Il'Jl l того,
I.ILI'lI■обмен
:IH №711 любыми
/Ноутбукпаролями
пользовательскими Н’- между ауте ill Injihl kaiai
клиентом
Irli и сервером |1И|[-:<рчаиии
RADIUS идет только в
шифрованномтслсфом
виде,Точка
что исключает IASподслушивание чужих паролей и последующее
доступа
злоупотребление WIAN
ими. ACS
Комиутотор ■Intofl
OLTWP
IE i г птиц s
Рис. 7.9. Модель контроля доступа к портам стандарта 802.1x. Основные элементы
7.6. Стандарт IEEE 802.1x и протокол EAPOL
Стандарт сетевой
Стандарт аутентификации
802.1x описывает IEEE 802.1x
процедуру передачинашел широкую поддержку
EAP-сообщений сервером у произво-
доступа
дителей
(например, сетевого оборудования
коммутатором и ПО как для
или беспроводной беспроводных,
точкой так и для или
доступа) в проводных проводных сетей.
беспроводных
Говоря о технологии сетевой аутентификации пользователей, стоит упомянуть
Ethernet-сетях. При этом стандарт 802.1x напрямую упаковывает EAP-сообщения в Ethernet- протокол PPP,
который
кадры, не применяя для их передачи протокол PPP. Это вызвано тем, что использоватьк
наиболее часто используется для подключения клиентов по коммутируемым линиям
Интернет-провайдерам.
протокол PPP во многих Протокол
случаяхPPP не также используется
обязательно, некоторыми
например, сервис-провайдерами
при подключении Ethernet-
для аутентификации
рабочей станции, не пользователей,
поддерживающейприменяющих
протоколxDSL или кабельные
TCP/IP, или в модемы. Кроме когда
том случае, того,
PPP является частью протокола L2TP,
использование протокола PPP является избыточным. на котором основан безопасный удаленный доступ к
системам на базе Windows 2000 и выше.
В стандарте 802.1x определяется три основных элемента:
•Итак, протокол(Supplicant)
Суппликант PPP изначально использовался
— пользователь, которыйдлянуждается
подключения удаленных
в сетевой аутенти-пользо-
вателей,фикации.
и поэтому он должен был иметь механизмы аутентификации пользователей.
Первоначально поддерживалась(Authentication
• Сервер аутентификации только передача имени
Server) пользователя
— обычно или паролякоторый
RADIUS-сервер, в нешиф-
рованном виде, что фактическую
производит не соответствует современным требованиям
аутентификацию, например Cisco сетевой безопасности.
ACS или Microsoft IAS.
•В последнее
Аутентификаторвремя для протокола были
(Authenticator) разработаны
— сетевое новыенаходящееся
устройство, механизмы аутентификации
между суппли-
под общим
кантом названием
и серверомEAP (Extensible Authentication
аутентификации Protocol).
и предоставляющее Принципы
доступ работы данного
в сеть, например, точка
протокола былиили
доступа рассмотрены выше. Протокол EAP был создан с целью упразднения частных
Ethernet-коммутатор.
механизмов
Ключевым аутентификации и распространения
моментом является то, что сетевые стандартизированных подходов — схем
устройства — аутентификаторы типа
— могут
«запрос-ответ»
быть достаточно (challenge-response)
простыми, поскольку и инфраструктуры,
для реализацииоснованной на публичных
функций 802.1x ключах и
в них требуются
минимальные аппаратные
пользовательских затраты, вСтандартизация
сертификатах. то время как весьмеханизмов
интеллект концентрируется
EAP позволила в RADIUS-
сделать
сервере. Такая схема
аутентификацию имеетдля
прозрачной дополнительные
серверов доступа выгоды и позволяет
различных организовать
производителей. тесную
Например, при
интеграцию управления
подключении пользователя сетевым оборудованием
к серверу удаленного идоступа
сетевыми ПО, что значительно
использовании облегчает
механизма EAP
управлениеPPP
протокола информационной системой
для аутентификации самбольшого предприятия.
сервер доступа не должен знать или поддерживать
конкретные механизмы или алгоритмы аутентификации, его задача в этом случае — лишь
передать пакеты EAP-сообщений RADIUS-серверу, на котором фактически производится
аутентификация. В этом случае сервер Аутентификаторы
доступа исполняетмогут быть достаточно
роль посредника простыми,и
между клиентом
RADIUS-сервером, в задачи которого поскольку
входит для реализации
передача функций 802.1x
EAP-сообщений междув них требуются
ними. Модель
контроля доступа к портам стандарта 802.1x показана на рис. минимальные
7.9. аппаратные затраты.
86 87
Рис. 7.10. Модель контроля доступа к портам стандарта 802.1x. Схема работы
Протокол передачи EAP-сообщений в стандарте 802.1x называется EAPOL (EAP encap-

sulation over LAN) и в настоящее время определен для Ethernet ЛВС, а также беспроводных
сетей стандартов серии IEEE 802.11 и ЛВС, использующих технологии token ring и FDDI. На
рис. 7.10 показана модель контроля доступа к портам стандарта 802.1x.
Протокол передачи EAP-сообщений в стандарте 802.1х

называется EAPOL (EAP encapsulation over LAN) и в настоящее
время определен для Ethernet ЛВС, а также беспроводных сетей
стандартов серии IEEE 802.11 и ЛВС.
Схема работы протокола EAPOL достаточно проста. При этом можно выделить сле-
дующие основные режимы работы:
1. Аутентификатор посылает запрос на аутентификацию (EAP-Request/Identity) суп-
пликанту, как только он определит, что какой-то из его Ethernet-портов перешел в активное
состояние (link active), то есть к нему подключен сетевой адаптер. Таким образом, если
отключить клиентскую станцию, которая уже прошла аутентификацию, и снова подключить к
сетевому порту, то потребуется пройти аутентификацию еще раз.
2. Суппликант посылает сообщение/ответ (EAPResponse/Identity) аутентификатору,
которое затем передается им на сервер аутентификации (RADIUS).
3. Сервер аутентификации в ответ посылает пакет-запрос (challenge) аутентификатору,
который затем переупаковывает его из IP-транспорта в EAPOL и передает суппли- канту. В
различных схемах аутентификации число таких сообщений может изменяться. В EAP
поддерживается как аутентификация клиентской стороны, так и взаимная «сильная»
аутентификация клиента и сервера. Заметим, что только последний вариант считается
приемлемым для использования в беспроводных сетях.
4. Суппликант отвечает на запрос в соответствие с выбранным алгоритмом и передает его
аутентификатору, который пересылает его на сервер аутентификации.
5. Если суппликант предоставляет правильный ответ на запрос, сервер посылает со-
общение об успешной аутентификации суппликанту. В этой ситуации аутентификатор
88
открывает клиенту доступ к ЛВС, который может зависеть от дополнительных параметров,

передаваемых ему RADIUS-сервером, например, от номера ВЛВС (VLAN) или определенного
уровня качества обслуживания (QoS).
Таким образом, использование сетевой аутентификации позволяет предоставлять поль-
зователю определенный номер ВЛВС или уровень качества обслуживания независимо от
точки подключения в корпоративную ЛВС. Это обеспечивает как мобильность пользователей,
так и постоянное соблюдение профиля безопасности сети — если даже сетевые кабели будут
случайно перепутаны, пользователь не сможет войти в ВЛВС (подключиться не к своему
сегменту сети), доступ к которой ему запрещен. Стандарт включает три вида протокола EAP:
• EAP-MD5 — с хэшированием имени пользователя и пароля по алгоритму MD5;
• EAP-OTP — с поддержкой доступа по одноразовым паролям;
• EAP-TLS — аутентификация с установлением защищенного канала (SSL).
7.7. Протокол EAP-TLS

с использованием российской криптографии
7.7.1. Общие сведения

Протокол EAP предоставляет стандартный механизм поддержки дополнительных методов
аутентификации в протоколе PPP. При использовании EAP можно добавить несколько схем
аутентификации, включая смарт-карты, Kerberos, открытые ключи, одноразовые пароли и др.
Существующие в настоящее время реализации протокола EAP фокусируются на
аутентификации клиента к серверу. Однако зачастую требуется взаимная аутентификация
клиента и сервера.
Протоколы PPP (такие, как 3DES, Triple-DES Encryption Protocol) используют сессионные
ключи, поэтому необходимо иметь механизм получения таких ключей. Такой механизм
реализован в протоколе EAP-TLS. Этот протокол позволяет обеим сторонам,
взаимодействующим по протоколу PPP, осуществлять защищенный обмен по заданным
алгоритмам, взаимную аутентификацию и управление ключами на основе протокола TLS.
Протокол EAP-TLS используется в стандарте сетевой аутентификации IEEE 802.1x для
осуществления первоначальной аутентификации субъекта локальной вычислительной сети
(виртуальной частной сети, VPN).
Протоколы PPP (такие, как DES, Triple-DES Encryption

Protocol) используют сессионные ключи, поэтому
необходимо иметь механизм получения таких ключей.
Такой механизм реализован в протоколе EAP-TLS.
Обмен по протоколу EAP-TLS начинается со стандартного обмена аутентификатора и

аутентифицируемого субъекта в соответствии с протоколом EAP. Аутентификатор отправляет
пакет EAP-запроса на аутентификацию субъекту, который в свою очередь отправляет
аутентификатору пакет EAP-ответа, содержащий его идентификатор.
С этой точки зрения в процессе обмена по протоколу EAP между аутентификатором и
субъектом аутентификатор может действовать как промежуточное устройство, накапливающее
приходящие от противоположной стороны пакеты для передачи их RADIUS-сер
89
веру или защищенному серверу. В протоколе EAP-TLS под понятием EAP-сервер под-
разумевается конечная точка в такой цепи, которая общается с субъектом, нуждающимся в
Субъекта, взаимодействующего с EAP-сервером, в дальнейшем будем называть EAP-
клиентом. Получив идентификатор EAP-клиента, EAP-сервер отправляет стартовый пакет
EAP-TLS. Последний представляет собой пакет EAP-запроса, в котором EAP-Type=EAP-TLS,
выставлен стартовый бит (S) и отсутствуют данные.
После этого начинается непосредственный обмен по протоколу EAP-TLS. EAP-клиент
отправляет пакет EAP-ответа, в котором EAP-Type=EAP-TLS. Поле данных этого пакета
инкапсулируется из сообщения client_hello протокола TLS. Шифрование и компрессия пакета
не производятся.
Сообщение client_hello содержит версию протокола TLS, идентификатор сессии, слу-
чайные данные клиента, а также набор поддерживаемых клиентом шифр-сюит. Отправляемая
клиентом версия должна быть не ниже, чем TLS версии 1.0.
После этого EAP-сервер отвечает пакетом EAP-запроса, в котором EAP-Type=EAP-TLS.
Поле данных этого пакета инкапсулируется из одного или более TLS-пакетов. Эти пакеты
содержат в своей совокупности ряд сообщений, формируемый в зависимости от того, со-
здается ли новая сессия или восстанавливается предыдущая. Если создается новая сессия, то
отправляются сообщения server_hello, certificate, certificate_request и server_hello_done. В
случае восстановления предыдущей сессии отправляются сообщения server_hello,
change_cipher_spec и finished.
Сообщение server_hello содержит версию протокола TLS, идентификатор сессии,
случайные данные сервера и выбранную сервером шифр-сюиту.
Если отправленный клиентом идентификатор сессии был нулевым или он не поддер-
живается сервером, то сервер выбирает идентификатор для установления новой сессии. В
противном случае сервер пытается восстановить ранее установленную сессию с заданным
идентификатором.
Идентификатор сессии в рамках протокола TLS служит для повышения эффективности в
тех случаях, когда клиент повторно производит аутентификацию для сервера через небольшой
промежуток времени. То же самое можно сказать и для PPP-аутентификации.
Сообщение certificate представляет собой сертификат, содержащий открытый ключ
сервера, соответствующий выбранной им шифр-сюите в сообщении server_hello.
Сообщение certificate_request (запрос на сертификат клиента) оправляется в том случае,
если сервер требует аутентификацию клиента. В случае EAP-сервера создание такого запроса
желательно, но не обязательно.
После получения этих сообщений EAP-клиент отправляет пакет EAP-ответа, в котором
EAP-Type=EAP-TLS. Поле данных этого пакета инкапсулируется из одного или более TLS-
пакетов, содержащих сообщения change_cipher_spec, client_key_exchange, finished, а также
возможно сообщения certificate и certificate_verify. Если сервер восстановил предыдущую
сессию, то клиент отправляет только сообщения change_cipher_spec и finished.
Что касается сообщения certificate, то возможны следующие варианты ответной реакции
клиента:
1. Сервер не запросил сертификат клиента. В зависимости от настройки верхнего уровня
связь прервется, или продолжается установление связи в соответствии с пунктом 4).
2. Сервер запросил сертификат клиента. У клиента есть сертификат, соответствующий
параметрам Диффи—Хеллмана сертификата сервера. Он передает сообщением certificate этот
сертификат серверу.
3. Сервер запросил сертификат клиента, но у клиента нет сертификата, соответствующего
параметрам Диффи—Хеллмана сертификата сервера. Если клиент не хочет аутенти
90
фикации его сервером, он посылает сообщение certificate пустым. В этом случае система
может быть настроена как на прекращение связи, так и на ее продолжение. Если связь
продолжается, осуществляется переход к пункту 4).
4. У клиента нет сертификата, соответствующего параметрам Диффи—Хеллмана сер-
тификата сервера, но есть сертификат, соответствующий другим параметрам или соот-
ветствующий закрытый ключ предназначен только для подписи. В этом случае клиент
передает свой сертификат сообщением certificate и генерирует эфемеральную пару ключей
(закрытый/открытый) с параметрами сертификата сервера. Если у клиента нет никакого
сертификата, то он генерирует эфемеральную пару ключей (закрытый/открытый) с па-
раметрами сертификата сервера, но сообщение certificate не передает.
Клиент на основе своего закрытого ключа, соответствующего сертификату с параметрами
Диффи—Хеллмана сервера, или закрытого ключа выработанной им эфе- меральной пары и
открытого ключа сертификата сервера формирует ключ Диффи—Хеллмана (ключ обмена),
генерирует премастер-ключ (32 случайных байта) и сообщением client_key_exchange передает
ее серверу. Если клиент вырабатывал эфемерную пару ключей Диффи—Хеллмана, то в этом
же сообщении он отправляет также открытый ключ эфемеральной пары.
После этого у клиента имеются пары ключей Диффи—Хеллмана (закрытый, открытый),
шифр-сюита сессии, премастер-ключ и случайные данные клиента и сервера (32 байта
каждая).
Если клиент в сообщении client_key_exchange передал открытый ключ из эфемеральной
пары и передал свой сертификат, он передает сообщение certificate_verify, содержащее
подпись на закрытом ключе из этого сертификата (с параметрами, отличными от параметров
сертификата сервера) хэш-значения всего диалога клиент/сервер до данного момента.
Клиент переключается на криптографические алгоритмы, соответствующие выбранной
сервером шифр-сюите, и сообщает об этом переходе серверу сообщением change_ci pher_spec.
Из имеющихся данных клиент вырабатывает мастер-ключ (48 байт), а из него и рабочие
ключи. Помимо этого из мастер-ключа и хэш-значения всего диалога клиент/сервер до
данного момента вырабатывается сообщение finished и отправляется серверу.
В случае восстановления сессии сообщение finished вырабатывается из сохраненного в
сессии мастер-ключа.
После этого EAP-сервер отвечает пакетом EAP-запроса, в котором EAP-Type=EAP-TLS.
Поле данных этого пакета инкапсулируется из одного или более TLS-пакетов. Эти пакеты
содержат сообщения change_cipher_spec, finished.
Сервер, если клиент использует эфемеральную пару ключей, вычисляет хэш-значение
всего диалога клиент-сервер до данного момента и проверяет подпись хэша из сообщения
certificate_verify. Этим он проверяет одновременно открытый ключ эфемеральной пары,
переданный клиентом в сообщении client_key_exchange.
Сервер на основе своего закрытого ключа (соответствующего его сертификату) и от-
крытого ключа клиента (из сертификата клиента с параметрами сервера или из выработанной
им эфемеральной пары) формирует ключ Диффи—Хеллмана, ключ обмена и дешифрует
премастер-ключ.
Сервер переключается на криптографические алгоритмы, соответствующие выбранной
сервером шифр-сюите, и сообщает об этом переходе клиенту сообщением change_ci pher_spec.
После всех операций у сервера имеются пары ключей Диффи—Хеллмана (закрытый,
открытый), шифр-сюита сессии, премастер-ключ и случайные данные клиента и сервера (32
байта каждая).
91
Из этих данных сервер вырабатывает мастер-ключ (48 байт), а из него и рабочие ключи.
Помимо этого, из мастер-ключа и хэш-значения всего диалога клиент/сервер до данного
момента вырабатывается сообщение finished, шифруется и отправляется клиенту.
Если аутентификация пройдена успешно, то EAP-клиент отправляет пакет EAP-ответа, в
котором EAP-Type = EAP-TLS. Поле данных этого пакета пустое.
EAP-сервер в случае успешной аутентификации отвечает аналогичным пакетом EAP-
запроса.
Если аутентификация оказывается неуспешной, то формируется пакет, в котором EAP-
Type=EAP-TLS, а в поле запроса содержится TLS-сообщение об ошибке.
7.7.2. Получение ключей

Ключи шифрования, используемые для PPP-шифрования, получаются из TLS мастер-
ключа. Ключи для обеих сторон производятся следующим образом: из мастер-ключа,
полученного в процессе обмена, псевдослучайной функции PRF и случайных данных,
получаемых конкатенацией случайных данных клиента и сервера, вычисляется значение
функции PRF (master secret, "client EAP encryption", random) — 128 байт, после чего вы-
числяется значение PRF (“”, "client EAP encryption", random) — 64 байта (где “” —пустая
строка).
Из полученных первым преобразованием PRF 128 байт последовательно создаются 4
ключа по 32 байта каждый: ключ шифрования клиента (используется для шифрования данных,
отправляемых EAP-серверу), ключ шифрования сервера (используется для шифрования
данных, отправляемых клиенту), ключ аутентификации клиента (используется для подсчета
MAC при отправке сообщений серверу) и ключ аутентификации сервера (используется для
подсчета MAC при отправке сообщений клиенту).
Из полученных вторым преобразованием 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.8. Стандарт IEEE 802.1x в

операционных системах Microsoft
До последнего времени клиент IEEE 802.1х в операционных системах компании Microsoft

802.1x был изначально встроен только в ОС Windows XP, однако относительно недавно
компания выпустила свободно распространяемое дополнение для Windows 2000, позволяющее
и данной ОС производить сетевую аутентификацию по протоколу 802.1x.
В стандартной комплектации Windows XP поддерживает три метода EAP:
• EAP-MD5. Сервер аутентификации запрашивает идентификационные данные у ини-
циатора взаимодействия. Инициатор взаимодействия объединяет запрос со своим
идентификатором и паролем, создает хэш MD5 из всех этих данных и посылает его
обратно на сервер аутентификации. Последний дешифрует принятые данные, и в
случае совпадения их с исходным запросом аутентификация завершается успешно.
Заметим, что Windows не позволяет использование метода EAP-MD5 для
беспроводных подключений по протоколу 802.1x.
• EAP-TLS. Сервер аутентификации открывает сеанс TLS с инициатором взаимо-
действия. Сервер посылает свой цифровой сертификат инициатору взаимодействия, а
он проверяет действительность этого сертификата. После этого инициатор
взаимодействия посылает свой цифровой сертификат на сервер, а тот проверяет
действительность сертификата. Таким образом, клиент и сеть производят взаимную
проверку подлинности, и если каждая из сторон доверяет сертификату другой стороны
и этот сертификат является действительным, аутентификация завершается успешно.
• Защищенный EAP (PEAP). Обмен данными по протоколу PEAP начинается так же, как
и в случае EAP: сервер аутентификации открывает сеанс TLS с инициатором
взаимодействия и посылает ему свой цифровой сертификат для проверки. Если
инициатор взаимодействия доверяет этому сертификату, он удостоверяет свою
подлинность серверу одним из нескольких методов. В настоящее время единственным
доступным методом аутентификации со стороны просителя в Windows является MS-
CHAPv2, в котором инициатор взаимодействия использует традиционные учетные
записи (имена и пароли пользователей и компьютеров) для проверки подлинности. Это
называется PEAP-EAP-MS-CHAPv2. Обратите внимание, что можно также выбрать
вариант PEAP-EAP-TLS, хотя на самом деле в его использовании нет смысла. Он
предусматривает открытие независимого второго сеанса TLS внутри первого; такое
удвоение сеансов TLS замедляет работу по сравнению с методом EAP-TLS.
ПК с установленными ОС семейства Windows 2000/2003 Server и службой IAS может
исполнять функции RADIUS-сервера, который, в свою очередь, выполняет аутентификацию и
авторизацию клиентов, использующих протоколы EAP-TLS, PEAP-MS-CHAP v2 или PEAP-
EAP-TLS.
Клиенты Microsoft 802.1x 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. Механизмы аутентификации
ЧАСТЬ при осуществлении
I. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ подключений
Cisco
мноеNAC умножает
решение защиты отдачу
хоста средств, инвестированныхдоступа,
от несанкционированного в сетевую
будетинфраструктуру
получать доступи
технологию защиты хостов,
к информации о версиисвязывая их вместе
операционной и обеспечивая
системы, этим «заплатках»
о программных возможностьи текущем
контроля
сетевого допуска. системы
состоянии Например, и организация
передавать эту может быть уверена,
информацию что применение
доверенному агентуантивирусных
Cisco (Cisco
программ
Trustобеспечивается
Agent). Хостам, сетью
не Cisco
имеющим— маршрутизаторами, коммутаторами,
необходимых программных беспроводными
обновлений, может
устройствами и устройствами
быть предложен защиты.доступ
ограниченный Таким илиобразом,
вообще Cisco NAC вдополняет
отказано доступе к— а не заменяет
сети.
— •классические
Устройства исетевого
широкодоступа
распространенные
— к сетевымтехнологии
устройствам, защиты: межсетевыеполитику
осуществляющим экраны,
системы обнаружения
контроля вторжений,
допуска, относятсяаутентификацию
маршрутизаторы, пользователей и защиту
коммутаторы, коммуникаций.
точки беспроводного
доступа и устройства защиты. Эти устройства требуют наличия электронных удос-
товерений от оконечного узла, и передают эту информацию на серверы контроля
политики, где и принимается решения о доступе в сеть. На основе политики заказчика
Cisco NAC разрешает сетевой доступ соответствующим
сеть будет проводить соответствующее решение
политике о контроле
и доверенным сетевого
оконечным доступа —и
устройствам
разрешить, запретить, поместить под наблюдение, ограничить.
ограничивает доступ тем устройствам, которые не
• Сервер политики — оценивает защищенность конечной точки по информации,
соответствуют по-
политике.
лученной от устройств сетевого доступа, и определяет для них соответствующую
политику доступа. Основой системы серверов политики являются сервер аутенти-
Состав компонентов
фикации, Cisco иNAC
авторизации приведен(AAA)
отчетности на рис.RADIUS
7.11. — Cisco Secure Access Control
• Доверенный
Server (ACS). агент Cisco (Cisco
Система работаетtrustсовместно
agent) — программное обеспечение,партнеров
с серверами приложений размещаемое на
Cisco
оконечных
NAC, узлах (рабочие
обеспечивающих болеестанции,
широкие серверы и т. п.).проверки
возможности Доверенный агент собирает
электронных удос-
информацию
товерений, о защищенности
такими от множества
как серверы антивирусной программных клиентов, таких, как
политики.
антивирусные клиенты, а затем передает
• Система управления — CiscoWorks VPN/Security Managementэти сведения устройствам сетевого
Solution (VMS)доступа
управ-
Cisco,
ляет которые Cisco
элементами осуществляют контрольCiscoWorks
NAC, а решение допуска. Security
Компания Cisco лицензировала
Information Management
технологию
Solution доверенного
(SIMS) предлагаетагента для своихмониторинга
инструменты партнеров в иобласти
созданияантивирусов, и теперь
отчетов. Партнеры
этот агент может интегрироваться с их клиентским ПО. Доверенный
Cisco NAC предлагают решения для управления своим программным обеспечением агент будет также
на
интегрироваться
конечных узлах. и с Cisco Security Agent, чтобы контролировать доступ, например, в
зависимости
На рис. от уровня
7.12 показаны применения
сценарии программных
развертывания обновлений
Cisco NAC в операционной
в различных системе
сегментах сети.
оконечного устройства. Cisco Security Agent програм-
I lp*liry.intC.1UIOC’
CjtibCE I применение ИС1ИММС11ИС
и IU4CT.I юпление
\N Сервер
ли Minimum
Cisco АС S
WAN
Серверы
других
I ПС ,|И-
III икон
Сервер
Уда.* и шде исправлении
Рис. 7.12.
Рис.Сценарии развертывания
7.11. Компоненты Cisco NAC
Cisco NAC
96 95
Cisco NAC помогает гарантировать соответствие хостов в удаленных или домашних

офисах, которые подключаются к ресурсам центральной компании либо по территориальным
сетям передачи данных, либо по защищенному каналу в Интернете. Сюда входит проверка
соответствия на главном маршрутизаторе или на маршрутизаторе филиала.
• Защита удаленного доступа. Еще до того, как мобильный или удаленный работник
получит доступ в сеть по коммутируемой телефонной линии, по протоколу IPSec или
иному соединению, Cisco NAC гарантирует, что на компьютере работника ус-
тановлены последние версии антивирусов и программных обновлений для опе-
рационной системы.
• Защита беспроводной сети. Cisco NAC проверяет подключенные по беспроводным
каналам хосты на предмет правильности их программных обновлений. Для выпол-
нения этой проверки используется протокол 802.1x и комбинация аутентификации
пользователя и устройства.
• Защита сетевого доступа и центра обработки данных. Cisco NAC контролирует
серверы и персональные компьютеры в офисе еще до того, как им будет предоставлен
доступ к сети, позволяет гарантировать их соответствие антивирусной политике и
политике использования программных обновлений, принятых в компании. Расширяет
контроль допуска на коммутаторах Уровня 2, что позволяет уменьшить риск заражения
вирусами или «червями».
• Соответствие внешних (партнерских) сетей. С помощью Cisco NAC можно прове-
рять не только системы, управляемые IT-подразделением предприятия, но и любую
систему, которая пытается получить доступ в сеть. На соответствие политикам
антивирусов и операционных систем могут быть проверены управляемые и не-
управляемые хосты, принадлежащие в том числе партнерам и подрядчикам. Если на
опрашиваемом хосте отсутствует доверенный агент Cisco (Cisco Trust Agent), то
используется политика доступа по умолчанию.
1. Какие протоколы включены в механизм аутентификации Point-to-Point Protocol (PPP)?
2. Перечислите основные элементы стандарта 802.1x.
3. Какие методы EAP стандарта 802.1х включены в стандартную комплектацию Windows
XP?
4. Опишите взаимодействие между пользователем, клиентом и сервером RADIUS.
5. Опишите метод получения ключей шифрования, используемых для PPP.
Глава 8
АУТЕНТИФИКАЦИЯ
В ЗАЩИЩЕННЫХ СОЕДИНЕНИЯХ
Протоколы безопасности на транспортном уровне SSL и Secure Shell Protocol (SSH)

обеспечивают безопасную передачу данных между клиентом и сервером. Оба протокола
разработаны рабочей группой IETF по безопасности транспортного уровня (Transport Layer
Security — TLS). Безопасный протокол передачи гипертекста S-HTTP предоставляет
надежный механизм Web-транзакций, однако в настоящее время наиболее распространен
протокол SSL. Рамочная структура SOCKS позволяет приложениям клиент/сер- вер в доменах
TCP и UDP удобно и безопасно пользоваться услугами межсетевого экрана. Протокол
безопасности IP (IPSec) представляет собой набор стандартов поддержки целостности и
конфиденциальности данных на сетевом уровне (в сетях IP). X.509 — это стандарт
безопасности, определяющий структуру данных цифрового сертификата и описывающий
вопросы обращения общих ключей. X.509 является важнейшим компонентом инфраструктуры
открытых ключей (PKI).
8.1. Протоколы SSL, TLS
SSL — открытый протокол, разработанный компанией Netscape, который определяет

механизм поддержки безопасности данных на уровне между протоколами приложений
(такими, как Hypertext Transfer Protocol (http), Telnet, Network News Transfer Protocol (NNTP)
или File Transfer Protocol (FTP)) и протоколом TCP/IP. Он поддерживает шифрование данных,
аутентификацию серверов, целостность сообщений и (в качестве опции) аутентификацию
клиентов в канале TCP/IP. SSL был представлен рабочей группе по безопасности консорциума
W3 (W3C) для утверждения в качестве стандартного средства безопасности Web-браузеров и
серверов в сети Интернет.
SSL поддерживает шифрование данных, аутентификацию

серверов, целостность сообщений и (в качестве опции)
аутентификацию клиентов в канале TCP/IP.
Основная цель протокола SSL состоит в том, чтобы обеспечить защиту и надежность
связи между двумя подключенными друг к другу приложениями. Этот протокол состоит из
двух уровней. Нижний уровень, который располагается поверх надежного транспортного
протокола (например, TCP), называется SSL Record Protocol и используется для встраивания
различных протоколов высокого уровня. Один из таких встроенных протоколов — SSL
Handshake Protocol позволяет серверу и клиенту аутентифицировать друг друга и со-
гласовывать алгоритм шифрования и криптографические ключи, прежде чем протокол
приложения произведет обмен первыми битами данных. Одно из преимуществ SSL состоит в
том, что он независим от протоколов приложений. Протокол высокого уровня может
располагаться поверх протокола SSL. Протокол SSL поддерживает безопасность связи,
обеспечивая ей следующие возможности:
98
Глава 8. Аутентификация в защищенных соединениях
• Защищенность. После первоначального квитирования связи применяются средства

шифрования и определяется секретный ключ. Для шифрования данных используются
средства симметричной криптографии (например, DES, RC4 и т. д.).
• Аутентификация участника сеанса связи с помощью общих ключей, т. е. средствами
асимметричной криптографии (например, RSA, DSS и т. д.).
• Надежность. Транспортные средства проводят проверку целостности сообщений с
помощью шифрованного кода целостности (MAC). Для вычисления кодов МАС
используются безопасные хэш-функции (например, безопасный хэш-алгоритм (SHA),
MD5 и т. д.).
Основная цель протокола SSL состоит в том, чтобы

обеспечить защиту и надежность связи между двумя
подключенными друг к другу приложениями.
Протокол SSL состоит из нескольких уровней. На каждом уровне сообщения имеют ряд
полей для указания длины, описания и содержания. SSL воспринимает данные, пред-
назначенные для передачи, делит их на управляемые блоки, проводит компрессию данных
(если это необходимо), использует код MAC, производит шифрование и передает результат.
Принятые данные дешифруются, проверяются, декомпрессируются и реассембли- руются, а
затем передаются клиентам более высокого уровня.
Протокол SSL принят только в рамках HTTP. Другие протоколы могут работать с SSL, но
используют его не часто.
Протокол обеспечения безопасности на уровне передачи данных TLS (Transport Layer
Security Protocol) создан на основе SSL 3.0 компании Netsсаре. Идея заключалась в том, чтобы
опубликовать этот протокол как формальный RFC и придать ему до некоторой степени
некоммерческий статус. Ниже приведено общее описание TLS. Более подробное описание
приведено в RFC 2276 и спецификации SSL.
Протокол TLS состоит из двух уровней: TLS Record Protocol (протокол записей) и TLS
Handshake Protocol (протокол установления связи). TLS Record Protocol действует поверх TCP
и UDP и выполняет следующие функции:
• симметричное шифрование для шифрования. Ключи для такого шифрования гене-
рируются отдельно для каждого соединения и при их создании используется секретная
информация, полученная с помощью другого протокола (такого, как TLS Handshake
Protocol). TLS Record Protocol может быть использован и без шифрования;
• передача сообщений: сюда входит проверка целостности переданных сообщений с
помощью кода идентификации по ключу. Для этого применяется хэширование
(например, SHA, MD5 и др.);
• выступает в качестве оболочки для протоколов более высокого уровня. Примером
такого протокола может служить TLS Handshake Protocol, который позволяет серверу и
клиенту идентифицировать друг друга, выбрать алгоритм шифрования и используемые
ключи до того, как начнут передаваться данные.
Протокол TLS состоит из двух уровней: TLS Record Protocol

(протокол записей) и TLS Handshake Protocol (протокол
установления связи).
99
TLS Handshake Protocol защищает соединение, обеспечивая следующие три функции:

• идентификация другой стороны с помощью шифрования с открытым ключом
(например, RSA, DSS и др.). Такая проверка не является обязательной, но обычно
выполняется, по крайней мере, для одной из сторон;
• разделяемый секретный ключ становится недоступным для перехвата и не может быть
получен даже в случае, если атакующая сторона сможет поместить себя между
соединяемыми сторонами;
• обнаружение злоумышленника при попытке изменить данные.
8.2. Протокол SSH

Протокол Secure Shell (SSH) предназначен для защиты удаленного доступа и других
сетевых услуг в незащищенной сети. Он поддерживает безопасный удаленный вход в сеть,
безопасную передачу файлов и безопасную эстафетную передачу сообщений по протоколам
TCP/IP и X11. SSH, может автоматически шифровать, аутентифицировать и сжимать
передаваемые данные. В настоящее время SSH достаточно хорошо защищен от криптоанализа
и протокольных атак. Он хорошо работает при отсутствии глобальной системы управления
ключами и инфраструктуры сертификатов и при необходимости может поддерживать
инфраструктуры сертификатов, которые существуют в настоящий момент (например,
DNSSEC, простую инфраструктуру открытых ключей (SPKI), X.509).
Протокол Secure Shell (SSH) поддерживает безопасный

удаленный вход в сеть, безопасную передачу файлов и
безопасную эстафетную передачу сообщений по
протоколам TCP/IP и X11.
Протокол SSH состоит из трех основных компонентов:

• Протокол транспортного уровня. Обеспечивает аутентификацию сервера, конфи-
денциальность и целостность данных с отличной защитой эстафетной передачи. В
качестве опции может поддерживаться компрессия данных.
• Протокол аутентификации пользователя. Позволяет серверу аутентифицировать
клиента.
• Протокол соединения. Мультиплексирует шифрованный туннель, создавая в нем
несколько логических каналов.
Все сообщения шифруются с помощью IDEA или одного из нескольких других шиф-
ровальных средств (тройного DES с тремя ключами, DES, RC4-128, Blowfish). Обмен ключами
шифрования происходит с помощью алгоритма RSA, а данные, использованные при этом
обмене, уничтожаются каждый час (ключи нигде не сохраняются). Для защиты от
«подслушивания» (спуфинга) сети IP используется шифрование; для защиты от DNS и
спуфинга маршрутизации — аутентификация с помощью общих ключей. Кроме того ключи
RSA используются для аутентификации центральных компьютеров.
Недостатком протоколов безопасности, действующих на уровне сессий, является их
зависимость от инструкций протокола транспортного уровня. В случае SSL это означает, что
атака на TCP может быстро прервать сессию SSL и потребовать формирования новой сессии,
в то время как TCP будет считать, что все идет нормально.
Более подробные технические детали о протоколе SSH можно получить в рабочей группе
IEFT Secure Shell (secsh).
100
К преимуществам средств безопасности транспортного уровня (например, SSL или SSH)

относятся:
• возможность действий на сквозной основе (end-to-end) с существующими стеками
TCP/IP, существующими интерфейсами прикладного программирования (API)
(WinSock, 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.
101
S-HTTP поддерживает высокий уровень гибкости криптографических алгоритмов,

режимов и параметров. Для того чтобы клиенты и серверы смогли выбрать единый режим
транзакции (так, например, им нужно решить, будет ли запрос только шифроваться или только
подписываться или и шифроваться и подписываться одновременно. Такое же решение нужно
принять и для ответов), используется механизм согласования опций, криптографических
алгоритмов (RSA или DSA для подписи, DES или RC2 для шифрования и т. д.), и выбора
сертификатов (например, «Подписывайтесь своим сертификатом Verisign»). S-HTTP
поддерживает криптографию общих ключей, функцию цифровой подписи и обеспечивает
конфиденциальность данных.
Отметим, что протокол S-HTTP не получил широкого распространения.
8.4. Протокол SOCKS

SOCKS разработан для того, чтобы дать возможность приложениям клиент/сервер в
доменах TCP и UDP удобно и безопасно пользоваться услугами межсетевого экрана. Он дает
пользователям возможность преодолевать межсетевой экран организации и получать доступ к
ресурсам, расположенным в Интернете. SOCKS служит «посредником уровня приложений»:
он взаимодействует с общими сетевыми средствами (например, Telnet и браузер Netscape) и с
помощью центрального сервера (прокси-сервера) от имени компьютера пользователя
устанавливает связь с другими центральными компьютерами.
Протокол SOCKS дает пользователям возможность

преодолевать межсетевой экран организации и получать
доступ к ресурсам, расположенным в Интернете.
SOCKS был разработан много лет назад Дейвом Кобласом (Dave Koblas) из компании SGI,
и сегодня этот код можно бесплатно получить через Интернет. С момента первого выпуска
этот код пережил несколько крупных модификаций, но каждая из них распространялась
бесплатно. 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
вером SOCKS (который конфигурируется самим пользователем в приложении или системным

файлом конфигурации), подключаясь к хорошо известному порту (обычно это порт 1080/TCP).
После установления связи с сервером SOCKS приложение отправляет серверу имя машины и
номер порта, к которому хочет подключиться пользователь. Сервер SOCKS реально
устанавливает связь с удаленным центральным компьютером, а затем прозрачно передает
данные между приложением и удаленной машиной. При этом пользователь даже не
подозревает, что в канале связи присутствует сервер SOCKS.
Трудность использования SOCKS состоит в том, что кто-то должен проводить работу по
замене сетевых системных вызовов версиями SOCKS (этот процесс обычно называется
«SOCKS-ификацией» приложения). К счастью, большинство обычных сетевых приложений
(Telnet, FTP, finger, whois) уже SOCKS-ифицированы, и многие производители включают
поддержку SOCKS в свои коммерческие приложения. Кроме того, SOCKS 5 включает эти
процедуры в свою общую библиотеку: на некоторых системах (например, на машинах Solaris)
можно автоматически SOCKS-ифицировать приложение, поставив общую библиотеку SOCKS
перед «shared libc» в строке поиска библиотек (переменная среды LD_LIBRARY_PATH в
системах Solaris).
Более подробные технические детали можно получить в рабочей группе IETF, рабо-
тающей над проблемой аутентифицированного пересечения межсетевых экранов.
8.5. Семейство протоколов IPSec

IP Security (IPSec) — это семейство протоколов, которые обеспечивают шифрование,
аутентификацию и защиту при транспортировке IP-пакетов; в его состав сейчас входят почти
20 предложений по стандартам и 18 RFC.
IPSec добавляет возможности шифрования и аутентификации в стек протокола TCP/IP на
более низком уровне, чем протоколы прикладного уровня, такие как Secure Socket Layer (SSL)
и Transport Layer Security (TLS). Защита IPSec прозрачна для приложений, поскольку она
осуществляется на нижнем уровне стека TCP/IP. Для защиты приложений средствами IPSec
необходимо, чтобы передача информации осуществлялась через определенный порт. Если для
всех соединений приложения применяют произвольные порты, определить фильтр IPSec,
идентифицирующий потоки сетевых данных этих программ, практически невозможно.
IPSec добавляет возможности шифрования и аутентификации в

стек протокола TCP/IP на более низком уровне, чем протоколы
прикладного уровня.
Приложения не обязательно должны быть IPSec-совместимы, так как данные от клиента к

серверу передаются открытым текстом. Протокол IPSec шифрует полезные данные после их
отправки клиентом и дешифрует до того, как они достигнут приложения на сервере.
Например, протокол Telnet передает реквизиты пользователя и данные программ от-
крытым текстом. Ниже показан сценарий, когда и клиент, и сервер настроены на со гласование
ассоциации безопасности IPSec при обмене данными по Telnet (рис. 8.1).
1. Клиент отправляет пакет серверу. Пакет отправляется с произвольного порта клиента,
но всегда на TCP-порт 23 Telnet-сервера.
103
ТL'llkL'l - li-t НГН Г TClnCt* К.1ИЛП
Kill
Л1 CM I
ПОЛИ гики П ОЛ П I K 1
PS« Ikl
IK
E SAKMP
ISAK
Лрпйпс-р
1Р5м Дрийпср
ins rt I
e
Фи ИШ Фильтры
TCP 11 Hr 21
L11. i
С петли
aii.iM'liMKi b
C ere тли
TCP 79 - -АЛДПТСр
ПДДпТСГ t ' 79 -
блокировать блокировать
Рис. 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) — Использование ал-
горитма хэширования 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). В своей простейшей форме АН предоставляет службы
аутентификации и проверки целостности для передаваемых данных, а ESP — службы
шифрования. АН и ESP — независимые протоколы. Их можно использовать отдельно или в
комбинации для обеспечения целостности и защиты данных от просмотра.
Для защиты данных IPSec предлагает два

протокола: Authentication Headers (АН) и
Encapsulating Security Payloads (ESP).
8.5.2. Протокол Authentication Headers (АН)

АН обеспечивает аутентификацию, целостность и защиту от повтора данных, передавае-
мых в сети. Он не помешает просмотреть данные, но исключает их изменение при передаче.
АН-пакеты используются для аутентификации компьютеров, участвующих в обмене
данными, и для обеспечения целостности передаваемых пакетов, чтобы злоумышленник не
мог изменить или воспроизвести пересылаемые данные. Протокол АН рекомендуется
использовать, когда соединения в рамках рабочей группы или проекта должны быть огра-
ничены определенными компьютерами. АН гарантирует взаимную аутентификацию со-
единенных компьютеров, поэтому в обмене данными могут участвовать только аутен-
тифицированные компьютеры.
Преимущество АН в том, что он обеспечивает возможность взаимной аутентификации для
тех протоколов, которые ее не поддерживают. Если аутентификация перемещается на более
низкий уровень в стеке сетевого протокола, все приложения смогут поддерживать IPSec.
105
8.5.3. Протокол Encapsulating Security Payloads (ESP)

ESP-пакеты позволяют шифровать данные. Кроме того, ESP предоставляет механизмы
аутентификации, целостности и защиты от повтора. Протокол ESP шифрует заголовки TCP
или UDP и данные приложений в IP-пакете. Если туннельный режим IPSec не используется, то
исходный заголовок IP не шифруется.
При выработке решения IPSec протоколы АН и ESP можно совместно использовать в
одном SA для IPSec. Оба протокола обеспечивают целостность данных, при этом АН
защищает весь пакет от изменения, а ESP — только заголовок TCP/UDP и полезные данные от
проверки. Протокол ESP позволяет шифровать данные. Он необходим, когда приложение не
распознает протокол безопасности на прикладном уровне, например SSL.
Поскольку процесс шифрования и дешифрования IPSec происходит на уровне IP/IPSec,
приложение не обязано поддерживать IPSec. Фактически приложение ничего «не знает» о
защите данных средствами IPSec (рис. 8.2).
Шифрование ESP могут применять только операционные системы и сетевые устройства,
поддерживающие IPSec. Если операционная система или сетевое устройство не поддерживают
IPSec, то либо SA IPSec должно разрешить обмен открытым текстом, либо нужно применить
альтернативный процесс шифрования.
Кроме поддержки шифрования, протокол ESP обеспечивает цифровую подпись данных.
Протоколы АН и ESP различаются лишь способами защиты от изменений: АН защищает
пакет целиком, а подпись ESP не защищает IP-заголовок, применяемый для маршрутизации
пакета в сети. При необходимости шифровать данные и обеспечить защиту всех полей в
пакетах нужно настроить SA на внедрение обоих (АН и ESP) протоколов в IPSec.
Г1}Н1ПОЖНРН(;
SSL/TLS
TCP
IP/IPSec
К " I.L lb?l UH
уровень
Фп шчнкий
уровень
Рис. 8.2. «Прозрачная» защита данных средствами IPSec
106
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 для обеспечения обмена аутентифицирован-
107
Удаленный Межсетевой экран
маршрутизатор
—— у
1 Корпоративная
у ■I. ТЕОРЕТИЧЕСКИЕ
ЧАСТЬ ( ОСНОВЫ
10 9\ сеть
Неконтролируемая область
DATA
IP HDR |
V_____________________ -У
HMAC MD5
HMAC SHA
Хэш IP-заголовка и поля данных
1
IP HDR AH DATA
Рис. 8.5. Создание нового аутентификационного заголовка IP
После согласования SA принимается решение о том, следует ли использовать средства

аутентификации, конфиденциальности и целостности данных или ограничиться только
аутентификацией. Если использоваться будут только средства аутентификации, текущий
стандарт предполагает применение хэш-функции, а точнее алгоритма не ниже MD5 с 128-
разрядными ключами. Заголовок пакета и данные пропускаются через хэш-функцию, и
результаты этого вычисления вводятся в специальное поле заголовка AH, как показано на рис.
8.5.
Новый пакет с аутентификационным заголовком, расположенным между заголовком IP и
данными, отправляется через маршрутизатор в пункт назначения. Когда этот пакет попадает
на межсетевой экран, последний проверяет его аутентичность, вычисляя хэш с помощью хэш-
функции, указанной в SA. Обе стороны должны использовать одни и те же хэш-функции. Как
показано на рис. 8.6, межсетевой экран сравнивает вычисленный им хэш с параметрами,
указанными в соответствующем поле AH. Если эти величины совпадают, аутентичность и
целостность данных считаются доказанными (если пакет передан из удаленной точки и при
передаче не был искажен ни один бит).
Отметим, что вставка заголовка АН расширяет пакет и поэтому для данного пакета может
потребоваться фрагментация, которая производится после заголовка AH для исходящих
пакетов и перед ним для входящих пакетов.
Если помимо всего сказанного стороны пожелают использовать средства поддержки
конфиденциальности, SA указывает, что весь трафик, поступающий из удаленного
маршрутизатора на межсетевой экран предприятия, должен аутентифицироваться и
шифроваться. В противном случае межсетевой экран его не пропустит. ESP поддерживает
аутентификацию, целостность и конфиденциальность данных и работает в двух режимах:
туннельном и транспортном, как показано на рис. 8.7 и 8.8.
В туннельном режиме вся датаграмма IP, заголовок IP и данные встраиваются в заголовок
ESP. В транспортном режиме шифруются только данные, а заголовок IP передается в
нешифрованном виде. Современные стандарты требуют использования DES в режиме
цепочки шифрованных блоков (CBC).
109
DATA
NewIP HDR ESP HDR IP HDR
Заголовок IP и поле данных Заголовок IP и поле данных
I I
I I
DATA
IP HDR
Зашифровано
Цифровая подпись Цифровая подпись
(00BADDOG) (00BADDOG)
IP HDR ESP HDR DATA
Рис. 8.6. Проверка аутентичности и целостности данных
Конфиденциальность с шифрованием заголовка IP и данных
IP HDR DATA
Зашифровано
Рис. 8.7. Туннельный режим ESP
Конфиденциальность с шифрованием данных

Отметим, что вставка заголовка АН расширяет пакет и поэтому для данного пакета может
потребоваться фрагментация, которая производится после 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, требующее наличия протоколов AH и ESP.
8.5.6. Планирование режимов IPSec

IPSec можно использовать в одном из двух режимов: транспортном и туннельном. Иногда
требуется обеспечить защиту IPSec на всем протяжении пути от клиента до сервера
назначения. Этот режим называется транспортным (рис. 8.9).
Защита пересылаемых данных осуществляется с помощью протоколов АН, ESP или обоих
одновременно. Данные защищаются на всем пути между двумя компьютерами.
При использовании туннельного режима IPSec (рис. 8.10) защита данных осуществляется
только между двумя определенными точками туннеля или шлюзами. Туннельный режим IPSec
обеспечивает защиту данных, пересылаемых между шлюзами.
Рис. 8.8. Транспортный режим ESP
111
110
Глава 8. Аутентификация
ЧАСТЬ I. ТЕОРЕТИЧЕСКИЕ
в защищенных
ОСНОВЫ
соединениях
Поля, включенные в ESP-заголовок в туннельном и транспортном режимах, не раз-

личаются. Единственное отличие — местоположение ESP-заголовка в пакете туннельного
режима и защите информации исходного IP-заголовка.
Пакеты туннельного режима IPSec отличаются от

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

Перед согласованием SA участники IPSec-соединения должны взаимно аутентифи-
цироваться одним из трех способов:
1. Kerberos. СтандартныйРис. механизм проверки
8.9. Транспортный режимподлинности
IPSec в Windows 2000/2003
обеспечивает стойкую аутентификацию и легко настраивается, так как все компьютеры с
Windows 2000/2003 осуществляют аутентификацию с аналогичными компьютерами в лесу, не
требуя дополнительной настройки. Но Kerberos не годится для аутентификации между лесами.
2. Сертификаты. Для аутентификации участников сети на основе сертификатов в сеансе
IPSec. Для этого сертификаты должны быть выданы центром сертификации (СА), которому
доверяют оба компьютера. Сертификаты обеспечивают надежную аутентификацию для
компьютеров в разных сетях. Компьютеры должны получить сертификаты для
аутентификации до начала согласования SA IPSec.
3. Общие секретные ключи. Общие ключи представляют собой текстовые строки, вве-
денные на обоих компьютерах для подтверждения их подлинности. Использование общих
ключей возможно, когда нельзя применять Kerberos или сертификаты, или при тестировании
фильтров IPSec перед внедрением параметров IPSec в сети.
8.5.8. Алгоритмы шифрования и проверки целостности IPSec

Свойства фильтров IPSec настраиваются для определения алгоритмов IPSec, применяемых
при согласовании безопасности. Для потоков данных, защищенных протоколами АН и ESP,
Рис. 8.10. Туннельный режим IPSec
можно использовать разные алгоритмы.
Если требуется защита АН, в качестве алгоритма проверки целостности можно ис-
пользовать алгоритмы
От клиента Message
к серверу Digest
данные до v5 (MD5) илиначального
достижения Secure Hashшлюза
Algorithm v1 (SHA1). вЕсли
пересылаются не-
требуется шифрование ESP, используется алгоритм цифровой подписи
защищенном виде. Затем при передаче пакетов в сеть назначения к ним применяются MD5 или SHAI и
алгоритм шифрования
определенные Data Encryption
в SA протоколы АН или Standard (DES) или Triple
ESP. На принимающем DESпроисходит
шлюзе (3DES). Алгоритм
процесс
проверки целостности
дешифрования SHAI считается
и верификации данных. Всильнее MD5, а данные
конце процесса алгоритмв виде
шифрования
открытого3DES —
текста
сильнее DES.
передаются на целевой компьютер.
Обычно туннельный режим применяется, когда пакеты должны пройти через открытую
или незащищенную сеть. Туннельный режим подходит для локальных сетей, в которых нет
необходимости защищать данные.
Пакеты туннельного режима IPSec
8.5.9. отличаются
Фильтры от пакетов
протокола транспортного режима тем, что
IPSec
при передаче между шлюзами к пакету добавляется новый заголовок IP. В него вставляется
АН-заголовок между новым
Для идентификации и исходным
протоколов, которые заголовками
необходимоIP. Поля, включенные
защитить средствами АН в заголовок
или ESP,
аутентификации,
надо определить не различаются. Для идентификации протокола используются следующие
IPSec-фильтры.
Аналогично пакет туннельного режима ESP отличается от пакета транспортного режима
характеристики:
ESP• расположением заголовка
IP-адрес источника. МожетESP.
бытьКак и в пакетеIP-адресом,
конкретным туннельного режима АН,
IP-адресом заголовок ESP
определенной
помещается между
подсети или новым
любымиадресом.
старым заголовками IP.
112 113
•IP-адрес назначения. Может быть конкретным IP-адресом, IP-адресом определенной

подсети или любым адресом.
• Тип протокола. Это идентификатор протокола или используемый транспортный
протокол. Например, PPTP использует пакеты GRE, которые определяются по их
идентификатору протокола (47). С другой стороны, Telnet использует в качестве
транспортного протокола TCP, поэтому в IPSec-фильтре для Telnet нужно указывать
тип протокола как TCP.
• Порт источника. Если используются протоколы TCP или UDP, для защищенного
соединения можно определить порт источника. В зависимости от протокола порт
источника устанавливается для конкретного или произвольного порта. Большинство
протоколов в качестве порта источника используют случайный порт.
• Порт назначения. Если применяется TCP или UDP, то для получения данных служит
конкретный порт на сервере. Например, Telnet настраивает сервер для прослушивания
соединений на TCP-порте 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.
IPSec не может защитить:
• Широковещательные 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 и не требует защиты IPSec.
114
• Протокол Internet Key Exchange (IKE). Протокол IKE применяется для согласования
SA между двумя компьютерами, участвующими в передаче данных IPSec. Процесс
согласования IPSec шифровать нельзя. Согласование осуществляется с помощью
пакетов с открытым текстом. При этом определяется порядок защиты следующих
пакетов.
Чтобы обеспечить соответствие фильтров потребностям предприятия, при их разработке
нужно учитывать следующее:
• Для одного компьютера можно назначать только одну политику IPSec. Если фильт-
рованию нужно подвергнуть несколько разных протоколов, необходимо создать
перечень фильтров, включающий все протоколы, и вставить его в список фильтров.
• В среде Windows политики IPSec определяются не для пользователей, а для
компьютеров. Фильтры IPSec определяются только для компьютеров в сети. При этом
не имеет значения, кто из пользователей работает на компьютере.
• Для выбора правильного фильтра нужно задать требования к протоколу. Необходимо
определить следующие атрибуты для каждого фильтра:
1) IP-адрес источника;
2) порт источника;
3) IP-адрес назначения;
4) порт назначения;
5) тип протокола.
• Идентифицировать шифрованный трафик IPSec при прохождении через межсетевой
экран нельзя. Если к пакету был применен протокол ESP, определить, какой протокол
зашифрован в пакете, невозможно. Это может привести к тому, что через межсетевой
экран сможет пройти нежелательный трафик, если межсетевой экран настроен на IKE-
пакеты (UDP-порт 500) и ESP-пакеты (идентификатор протокола 50). Так как данные в
пакете зашифрованы, межсетевой экран не может определить, какой исходный
протокол был защищен IPSec.
• Если определено несколько фильтров, первым вычисляется наиболее конкретный из
них, а наименее конкретный — последним. Порядок вывода на экран при этом не
имеет значения.
• В случае транспортного режима IPSec всегда следует применять пакетные фильтры с
отражением. Отражение обеспечивает шифрование ответных пакетов при их передаче
обратно источнику. В ответных пакетах информация об источнике и назначении будет
обращена. Отражение правил обеспечивает шифрование ответов.
• При определении соединений туннельного режима IPSec для каждого направления
следует создавать фильтр IPSec. Для туннельного режима IPSec нельзя использовать
отраженные пакетные фильтры, так как для заголовка трафика на каждом направлении
должны быть заданы разные конечные точки туннеля.
8.5.10. Преимущества протокола IPSec

К преимуществам поддержки безопасности на сетевом уровне с помощью IPSec следует
отнести:
• поддержку совершенно немодифицированных конечных систем, хотя в этом случае
шифрование нельзя назвать в полном смысле слова сквозным (end-to-end);
• частичную поддержку виртуальных частных сетей (VPN) в незащищенных сетях;
• поддержку других транспортных протоколов, а не только TCP (например, UDP);
115
• защиту заголовков транспортного уровня от перехвата и, следовательно, более на-

дежную защиту от анализа трафика;
• при использовании AH и средств обнаружения повторяющихся операций обес-
печивается защита от атак типа «отказ от обслуживания», основанных на «затоплении»
систем ненужной информацией (например, от атак TCP SYN).
8.6. Протоколы защищенного взаимодействия

и аутентификации для корпоративных
беспроводных локальных сетей
На сегодняшний день лидеры рынка предлагают ряд технологий, которые существенно
повышают безопасность корпоративных сетей WLAN, предоставляющую следующие
возможности для клиентских устройств WLAN:
• Поддержка стандарта IEEE 802.111.
• Поддержка сертификатов безопасности Wi-Fi Alliance — Wi-Fi Protected Access (WPA)
и Wi-Fi Protected Access 2 (WPA2).
• Двусторонняя аутентификация и управление динамическими ключами шифрования
благодаря поддержке IEEE 802.1X.
• Шифрование данных с помощью алгоритмов Advanced Encryption Standard (AES) или
Temporal Key Integrity Protocol (TKIP).
• Поддержка типов аутентификации 802.1X, клиентских устройств и клиентских
операционных систем.
• Подавление активных и пассивных сетевых атак.
• Интеграция с решениями Network Admission Control (NAC) компании Cisco Systems.
• Предотвращение сетевых вторжений (Intrusion Prevention System, IPS) и слежения за
перемещением абонента — прозрачное представление сети в реальном времени.
• Конвергенция безопасности внутренней и внешней сетей Wi-Fi.
Главным постулатом безопасности любой сети, не только беспроводной, является уп-
равление доступом и конфиденциальностью. Одним из надежных способов управления
доступом к WLAN является аутентификация, позволяющая предотвратить доступ не-
санкционированных пользователей к передаче данных через точки доступа. Действенные
меры управления доступом к WLAN помогают определить круг разрешенных клиентских
станций и связать их только с доверенными точками доступа, исключая несанкционированные
или опасные точки доступа. В настоящее время компании, использующие сети WLAN,
внедряют четыре отдельных решения для безопасности WLAN и управления доступом и
конфиденциальностью:
• открытый доступ;
• базовая безопасность;
• повышенная безопасность;
• безопасность удаленного доступа.
8.6.1. Открытый доступ

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

таких как кофейни, университетские городки, аэропорты или другие общественные места,
однако для предприятий этот вариант не подходит. Функции безопасности должны быть
включены на беспроводных устройствах в процессе их установки. Некоторые компании,
однако, не включают функции безопасности сетей WLAN, и тем самым повышают уровень
риска для своих сетей.
8.6.2. Базовая безопасность
Базовая безопасность заключается в использовании идентификаторов сети SSID (Service

Set Identifier), открытой аутентификации, аутентификации с помощью общих и статических
WEP-ключей и аутентификации по MAC-адресу. С помощью этой комбинации можно
настроить элементарные средства управления доступом и конфиденциальностью, однако
каждый отдельный элемент такой защиты может быть взломан.
Идентификатор SSID — общее имя сети для устройств в подсистеме WLAN — служит для
логического обособления данной подсистемы. Он предотвращает доступ любого клиентского
устройства, не имеющего SSID. Однако по умолчанию точка доступа передает в эфир среди
своих сигналов и свой SSID. Даже если отключить передачу в эфир SSID, взломщик или хакер
может обнаружить нужный SSID с помощью скрытого мониторинга сети. Стандарт 802.11,
группа спецификаций для сетей WLAN, выработанная IEEE, поддерживает два средства
аутентификации клиента: открытую аутентификацию и аутентификацию с помощью открытых
ключей.
Идентификатор SSID — общее имя сети для устройств в

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

идентификатора SSID. При аутентификации с помощью открытых ключей точка доступа
посылает на клиентское устройство тестовый текстовый пакет, который клиент должен
зашифровать правильным WEP-ключом и вернуть на точку доступа. Без правильного ключа
аутентификация будет прервана и клиент не будет допущен в группу пользователей точки
доступа.
Аутентификация с помощью общих ключей считается ненадежной, поскольку взломщик,
получивший в свое распоряжение начальное тестовое текстовое сообщение и это же
сообщение, зашифрованное WEP-ключом, может дешифровать сам WEP-ключ. При открытой
аутентификации, даже если клиент проходит аутентификацию и получает доступ в группу
пользователей точки доступа, WEP-защита не позволяет клиенту передавать данные с этой
точки доступа без правильного WEP-ключа.
WEP-ключи могут состоять из 40 или 128 бит и обычно статически определяются сетевым
администратором на точке доступа и каждом клиенте, передающем данные через эту точку
доступа. При использовании статических WEP-ключей сетевой администратор должен
потратить много времени на ввод одинаковых ключей в каждое устройство сети WLAN.
Если устройство, использующее статические WEP-ключи, потеряно или украдено,
обладатель пропавшего устройства может получить доступ к сети WLAN. Администратор не
сможет определить, что в сеть проник несанкционированный пользователь до тех пор, пока не
будет известно о пропаже. После этого администратор должен сменить WEP-ключ
117
на каждом устройстве, использующем тот же статический WEP-ключ, что и пропавшее

устройство. В сети крупного предприятия, включающей сотни или даже тысячи поль-
зователей, это может оказаться невыполнимым. Если же статический WEP-ключ был де-
шифрован с помощью такого инструмента, как AirSnort, администратор никак не узнает о том,
что ключ был взломан несанкционированным пользователем.
Некоторые поставщики решений WLAN поддерживают аутентификацию на базе фи-
зического или MAC-адреса, клиентской сетевой карты (NIC). Точка доступа позволит клиенту
ассоциироваться с точкой доступа только в случае, если MAC-адрес клиента соответствует
одному из адресов в таблице аутентификации, используемой точкой доступа. Однако
аутентификация по MAC-адресу не является адекватной мерой безопасности, поскольку
MAC-адрес можно подделать, а сетевую карту — потерять или украсть.
Другая форма доступной на сегодняшний день базовой безопасности — это WPA или
WPA2 с помощью общих ключей (Pre-Shared Key, PSK). Общий ключ проверяет пользо-
вателей с помощью пароля или кода идентификации (также называемого «фраза-пароль») как
на клиентской станции, так и на точке доступа. Клиент может получить доступ к сети только в
том случае, если пароль клиента соответствует паролю точки доступа. Общий ключ также
предоставляет данные для генерации ключа шифрования, который используется алгоритмами
TKIP (Tenporal Integrity Protocol) или AES для каждого пакета передаваемых данных. Являясь
более защищенным, чем статический WEP-ключ, общий ключ также хранится на клиентской
станции и может быть взломан, если клиентская станция потеряна или украдена.
Рекомендуется использовать общую фразу-пароль, включающую разнообразные буквы,
цифры и не алфавитно-цифровые символы.
Выводы. Базовая безопасность сетей WLAN, основанная на комбинации SSID, открытой
аутентификации, статических WEP-ключей, MAC-аутентификации и общих ключей
WPA/WPA2, является достаточной только для очень небольших компаний или тех, которые не
доверяют жизненно важные данные своим сетям WLAN. Всем прочим организациям
рекомендуется вкладывать средства в надежные решения безопасности сетей WLAN класса
предприятия.
Некоторые поставщики решений WLAN поддерживают

аутентификацию на базе физического адреса или MAC-
адреса, клиентской сетевой карты (N I C ).
8.6.3. Повышенная безопасность

Повышенный уровень безопасности рекомендуется для тех компаний, которым требуется
безопасность и защищенность класса предприятия. При этом для обеспечения безопасности
повышенного уровня, полностью поддерживаемого WPA и WPA2 с двусторонней
аутентификацией 802.1x и шифрования алгоритмами TKIP и AES, целесообразно реализовать
следующие возможности:
• 802.1X для двусторонней аутентификации и динамических ключей шифрования для
каждого пользователя и каждой сессии;
• TKIP для расширения шифрования на базе RC4, например, для хэширования ключей
(для каждого пакета), проверки целостности сообщения (MIC), изменений вектора
инициализации (IV) и ротации широковещательных ключей;
• AES для шифрования данных максимальной защищенности;
• интеграция с Cisco Self-Defending Network и NAC;
118
• возможности системы предотвращения сетевых вторжений (Intrusion Prevention

System, IPS) и слежения за перемещением абонента — прозрачное представление сети
в реальном времени.
Решение по обеспечению повышенного уровня безопасности, как правило, должно
предоставлять:
• Безопасное подключение к сетям WLAN — динамические ключи шифрования должны
автоматически изменяться в соответствии с настройками для обеспечения
конфиденциальности передаваемых данных.
— Шифрование WPA-TKIP должно расширяться такими функциями, как проверка
целостности сообщения (MIC), хэширование ключей (для каждого пакета), изменение
вектора инициализации (IV) и ротация широковещательных ключей.
— WPA2-AES, «золотой эталон» шифрования данных.
• Доверительные отношения и идентификацию в сетях WLAN. Надежное управление
доступом к WLAN должно обеспечивать подключение уполномоченных клиентов
только к доверенным точкам доступа и исключать неавторизованные точки доступа.
Для этого должна применяться двусторонняя аутентификация каждого пользователя и
каждой сессии с применением IEEE 802.1X, разнообразных типов расширяемого
протокола аутентификации (Extensible Authentication Protocol, EAP) и сервера
аутентификации RADIUS (Remote Authentication Dial-In User Service) или сервера
аутентификации, авторизации и учета AAA (Authentication, Authorization and
Accounting).
— Поддержка типов аутентификации 802.1X, клиентских устройств и клиентских
операционных систем.
— Поддержка записей биллинга протокола RADIUS для всех попыток аутен-
тификации.
• Защиту от атак на сети WLAN. Обнаружение несанкционированного доступа, сетевых
атак и несанкционированных точек доступа с помощью надежных средств
предотвращения вторжений IPS, WLAN NAC и расширенных сервисов обнаружения
местоположения. Необходимо использовать средства предотвращения сетевых
вторжений (IPS) класса предприятия, позволяющие непрерывно сканировать радио-
диапазон, обнаруживать несанкционированные точки доступа и прочие несанк-
ционированные события.
Протокол NAC Network Admission Control был специально разработан для адекватной
защиты всех проводных и беспроводных оконечных устройств (таких как персональные
компьютеры, ноутбуки, серверы и КПК), обращающихся к сетевым ресурсам, от угроз
безопасности. Использование протокола NAC позволяет организациям анализировать и
контролировать все устройства, подключающиеся к сети.
8.6.4. Поддержка WPA и WPA2

WPA был представлен Wi-Fi Alliance в 2003 г., а WPA2 был представлен Wi-Fi Alliance в
2004 г. Все продукты, сертифицированные Wi-Fi на соответствие требованиям WPA2,
обязательно взаимодействуют с продуктами, сертифицированными Wi-Fi на соответствие
требованиям WPA. Cisco Unified Wireless Network включает поддержку сертифицированных
Альянсом Wi-Fi механизмов WPA и WPA2.
WPA и WPA2 предоставляют конечным пользователям и сетевым администраторам вы-
сокий уровень уверенности в том, что их данные останутся конфиденциальными, а доступ к
их сетям будет предоставляться только санкционированным пользователям. Оба стан-
119
WPA WPA2
Корпоративный режим (коммерческие, • Аутентификация: • Аутентификация:

правительственные, образовательные IEEE 802.1X/EAP IEEE 802.1X/EAP
структуры) • Шифрование: TKIP/MIC • Шифрование: AES-CCMP
Персональный режим (небольшие • Аутентификация: PSK • Аутентификация: PSK
компании, домашние и персональные • Шифрование: TKIP/MIC • Шифрование: AES-CCMP
системы)
дарта обладают персональным и корпоративным режимами работы, удовлетворяющими

отдельным требованиям этих двух сегментов рынка. Корпоративный режим использует для
аутентификации IEEE 802.1X и EAP, а персональный режим — общие ключи (PSK). Не
рекомендуется применять персональный режим для коммерческих или государственных
решений из-за использования общих PSK-ключей при аутентификации пользователей. PSK-
ключи не считаются достаточно надежной мерой для внедрения на предприятии.
WPA позволяет закрыть все известные уязвимости WEP исходного стандарта безопас-
ности IEEE 802.11. Представляет собой быстрое решение для обеспечения безопасности сетей
WLAN как для предприятий, так и для небольших компаний или домашних систем. WPA
использует алгоритм шифрования TKIP.
WPA2 — это следующее поколение безопасности Wi-Fi. Он представляет собой пред-
ложенный Wi-Fi Alliance вариант ратифицированного стандарта IEEE 802.11i. В его состав
входит рекомендованный Национальным институтом стандартов и технологий (NIST)
алгоритм шифрования AES, использующий протокол CCMP (Counter Mode with Cipher Block
Chaining Message Authentication Code Protocol). WPA2 обеспечивает соответствие требованиям
правительственного стандарта FIPS 140-2 (табл. 8.1).
WPA позволяет закрыть все известные уязвимости WEP

исходного стандарта безопасности IEEE 802.11, WPA2
представляет собой предложенный Wi-Fi Alliance вариант
ратифицированного стандарта IEEE 802.11i.
8.6.5. IEEE 802.1Х-аутентификация и протокол EAP

(Extensible Authentication Protocol)
IEEE приняла 802.1X в качестве стандарта аутентификации для проводных и беспро-
водных сетей. 802.1X поддерживается корпоративными режимами WPA и WPA2. 802.1X
предоставляет сетям WLAN средства мощной двусторонней аутентификации между клиентом
и сервером аутентификации. В дополнение к этому, 802.1X предоставляет динамические
ключи шифрования для каждого пользователя и каждой сессии, избавляя таким образом
администраторов от необходимости обслуживания ненадежных статических ключей
шифрования.
Средствами 802.1X конфиденциальная информация, используемая для аутентификации,
такая, как пароли для входа, никогда не передается в открытом виде без шифрования по
беспроводным сетям. 802.1X обеспечивает надежную аутентификацию для беспроводных
локальных сетей, однако для шифрования дополнительно к 802.1X необходимы алго
120
ритмы TKIP и AES, поскольку стандартное WEP-шифрование стандарта 802.11 уязвимо перед
сетевыми атаками.
Существует несколько типов 802.1Х-аутентификации, предоставляющих различные
подходы к аутентификации, однако, опирающихся на единую структуру, и протокол EAP с
целью обеспечения передачи данных между клиентом и точкой доступа. К ним относятся
следующие: Cisco LEAP, EAP-Flexible Authentication via Secure Tunneling (EAP-FAST), EAP-
Transport Layer Security (EAP-TLS), Protected Extensible Authentication Protocol (PEAP), EAP-
Tunneled TLS (EAP-TTLS) и EAP-Subscriber Identity Module (EAP-SIM).
Для выбора наиболее подходящего типа EAP-аутентификации для развертывания 802.1Х.
рекомендуется провести анализ собственных сетей и систем безопасности. При выборе типа
EAP следует обращать внимание на механизм обеспечения безопасности, используемый для
передачи данных для аутентификации, базу данных аутентификации пользователей,
используемые клиентами операционные системы, доступные клиентам способы обращения,
тип необходимого входа пользователей в сеть, а также наличие серверов RADIUS или AAA.
Разница между уровнями безопасности зависит от типа управляемости EAP, поддер-
живаемых операционных систем, клиентских устройств, преимуществ клиентского про-
граммного обеспечения и передачи аутентификационных данных, требований сертификации,
простоты использования и поддержки устройств инфраструктурой WLAN. Кроме того,
возможно применение нескольких типов EAP в рамках сети — для поддержки спе-
цифического типа аутентификации, клиентского устройства или потребностей конечных
пользователей.
Для аутентификации по 802.1Х может быть использован широкий ассортимент серверов
RADIUS, таких, например, как Cisco Secure Access Control Server (ACS) и AAA RADIUS-сер-
веров различных производителей, например, Interlink Networks (AAA RADIUS).
Применение одного из типов 802.1Х-аутентификации, позволяющего аутентифицировать
клиентскую станцию с помощью вводимых пользователем данных, а не физических атрибутов
клиентского устройства, дает возможность понизить риск, связанный с потерей устройства
или его сетевой карты WLAN. 802.1Х предоставляет и другие преимущества, включая
снижение опасности появления угрозы «человек посередине» («man-in-the-middle») при
аутентификации, централизованное управление шифрованием ключей с ротацией ключей на
базе установленной политики, а также защиту от атак, осуществляемых методом перебора
ключей (brute-force) (рис. 8.11).
Применение одного из типов 802.1Х-аутентификации,

позволяющего аутентифицировать клиентскую станцию с
помощью вводимых пользователем данных, дает
возможность понизить риск, связанный с потерей
устройства или его сетевой карты WLAN.
Другим преимуществом 802.1Х-аутентификации является централизованное управление

группами пользователей сетей WLAN, включающее ротацию ключей на базе политик,
динамическое распределение ключей, динамическое назначение VLAN и запрет SSID. Эти
функции осуществляют ротацию ключей шифрования. Они также позволяют назначить
пользователям определенные VLAN-сети для гарантии того, что пользователи имеют доступ
только к определенным ресурсам.
После удачного проведения двусторонней аутентификации и клиент, и RADIUS-сервер
генерируют одинаковые ключи шифрования, используемые для шифрования всех пере-
121
RADIUS-сервер
2. Точка доступа блокирует
все пользовательские запросы
на доступ в локальную сеть
1. Клиент ассоциируется
с точкой доступа
Автономная точка Коммутатор
доступа Cisco Aironet 1240 AG
Беспроводной клиент
с поддержкой EAP-Fast RADIUS-сервер с поддержкой
аутентификации EAP-Fast и динамической
3. Пользователь предоставляет генерацией ключей шифрования
данные учетной записи
RADIUS-сервер аутентифицирует Пользователя,

Пользователь аутенфицирует RADIUS-сервер
Автономная точка Коммутатор

доступа Cisco 5. RADIUS-сервер передает
_ Aironet 1240 AG ключ Pair-wise Master
Беспроводной клиент Key (PMK) Точке Доступа
с поддержкой EAP-Fast
7. Точка доступа шифрует
8. Клиент и Точка Доступа широковещательный ключ 6. Точка доступа и Клиент
включают шифрование и пред°ставляет ет° Клиенту обмениваются сообщениями,
чтобы получить ключи шифрования
Рис. 8.11. Применение EAP-FAST одного из типов 802.1X

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

посылает этот ключ автономной точке доступа или беспроводному контроллеру локальной
сети, которые сохраняют его для клиента. В результате мы имеем ключи шифрования для
каждого пользователя и каждой сессии, а продолжительность сессии определяется политикой
на RADIUS-сервере. После окончания сессии или при переходе клиента с одной точки доступа
на другую происходит процесс повторной аутентификации, в результате которой генерируется
новый ключ сессии. Повторная аутентификация проходит незаметно для пользователя.
Параметры имени/идентификатора VLAN и параметры SSID передаются на автономную
точку доступа или контроллер беспроводной локальной сети вместе с ключами шифрования и
таймером повторной аутентификации. После получения автономной точкой доступа или
контроллером беспроводной локальной сети имени/идентификатора VLAN, назначаемого для
указанного пользователя, он указывает данного пользователя в метке указанного
имени/идентификатора VLAN. В случае, если точке доступа или контроллеру также
передается список разрешенных SSID, точка доступа или контроллер пытаются обеспечить
данного пользователя действительным SSID для доступа к сети WLAN. Если пользователь
предоставляет SSID, не указанный в списке разрешенных SSID, точка доступа или контроллер
беспроводной локальной сети удаляет ассоциацию с пользователем из сети WLAN.
122
Снижение риска атак, осуществляемых методом перебора ключей (brute-force). Тради-

ционные схемы WLAN на основе статических ключей шифрования легко поддаются взлому
сетевыми атаками, осуществляемыми методом перебора ключей. Атака представляет собой
попытку взломщика получить ключ шифрования путем перебора. Для взлома стандартной
128-битовой WEP-защиты потребуется перебрать максимум 2104 разных ключей.
Использование динамических ключей шифрования стандарта 802.1X, получаемых каждым
пользователем для каждой сессии, делает атаку методом перебора ключей хоть и теоретически
возможной, но крайне сложной для проведения и практически бесполезной.
8.6.6. WPA-шифрование, протокол целостности

временных ключей Temporal Key Integrity Protocol
TKIP представляет собой следующее поколение стандарта обеспечения безопасности
WEP. Как и WEP, TKIP использует метод шифрования, разработанный инженером Роном
Райвестом и известный как алгоритм шифрования Ron's Code 4 (RC4). Однако TKIP улучшает
WEP за счет ликвидации известных уязвимостей WEP и добавления таких функций, как
хэширование ключа каждого пакета, MIC и ротация широковещательных ключей.
TKIP реализует RC4-кодирование потока 128-битовыми ключами для шифрования и 64-
битовыми ключами для аутентификации. За счет шифрования данных ключом, который может
быть использован только предписанным пользователем этих данных, TKIP позволяет
гарантировать получение передаваемых данных в открытом виде только теми, для кого они
предназначены. Шифрование TKIP приводит к 280 триллионам возможных комбинаций
ключей для каждого отдельного пакета данных.
TKIP реализует й04-кодирование потока 128-битовыми ключами

для шифрования и 64-битовыми ключами для аутентификации.
Например, в рамках решения Cisco Unified Wireless Network реализованы алгоритмы Cisco
TKIP и WPA TKIP для автономных точек доступа Cisco Aironet, устройств Cisco Aironet и
совместимых с 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
Аутентификация EAP Аутентификация EAP
Динамическое создание TKIP (Улучшение
ключей шифрования)
DHCP/
RADIUS/
OTP/PKI-серверы
Автономная точка доступа с

поддержкой EAP и TKlP
Рис. 8.12. Снижение риска атак для схемы беспроводной локальной сети с использованием
WPA-802.1X EAP/TKTP
TKIP содержит средства хэширования ключей или создания ключей для каждого пакета
для снижения риска атак с использованием слабых векторов инициализации. При внедрении
поддержки хэширования ключей как на точке доступа, так и на всех ассоциированных
клиентских устройствах, отправитель данных хэширует базовый ключ с помощью вектора
инициализации для создания нового ключа для каждого пакета. Обеспечивая шифрование
каждого пакета своим ключом, хэширование ключа снимает вероятность определения WEP-
ключа с помощью уязвимости векторов инициализации (рис. 8.12).
Message Integrity Check, проверка целостности сообщения для защиты от активных се-
тевых атак. Использование MIC позволяет избежать активных сетевых атак, нацеленных на
поиск ключа шифрования, применяемого для шифрования перехваченных пакетов. При
внедрении MIC как на точке доступа, так и на всех ассоциированных клиентских устройствах
отправитель пакета данных добавляет несколько байтов (для проверки целостности
сообщения) к пакету перед его шифрованием и отправкой. При получении пакета получатель
дешифрует его и проверяет байты MIC. Если байты MIC пакета соответствуют расчетным
данным (рассчитываемым из функции MIC), получатель принимает пакет; в противном случае
получатель уничтожает пакет. С помощью MIC становится возможным отбрасывать пакеты,
измененные злоумышленниками.
Ротация широковещательных ключей. TKIP позволяет сетевым администраторам
осуществлять ротацию как присвоенных конкретному устройству, так и широковещательных
ключей, используемых для шифрования широковещательных и мультивещательных
сообщений. Сетевые администраторы могут конфигурировать политики ротации широ-
ковещательных ключей для точек доступа. Поскольку статический широковещательный ключ
подвержен тем же атакам, что и присвоенные конкретному устройству или статические WEP-
ключи, поддерживается ротация значений ключа для широковещательных ключей,
позволяющая закрыть эту уязвимость.
1. Какие возможности обеспечивает протокол SSL для безопасности связи?
2. Что включает в себя ассоциация безопасности?
3. Перечислите способы аутентификации при использовании протокола IPSec.
4. Какие протоколы IPSec защитить не может?
5. Преимущества протокола IPSec?
124
Глава 9
ПРИМЕНЕНИЕ АППАРАТНЫХ СРЕДСТВ
АУТЕНТИФИКАЦИИ И ХРАНЕНИЯ
КЛЮЧЕВОЙ ИНФОРМАЦИИ
9.1. Аппаратные средства защиты

в современных PKI-решениях
По оценкам компании IDC примерно 74% финансовых потерь связано с проблемами так
называемого «человеческого фактора». Для сравнения, потери от вирусных и хакерских атак
составляют соответственно 4 и 2%.
Поэтому важнейшими приоритетными задачами обеспечения информационной без-
опасности (ИБ) является снижение риска, связанного с человеческим фактором (ненадежность
паролей, сложность их выбора и смены, ошибки администрирования и т. п.).
Таким образом, нельзя построить защищенную систему, не обеспечив надежное решение
проблемы «трех А»:
• аутентификации (ответа на вопрос «Ты кто и как ты можешь доказать, что ты — это
ты?»);
• авторизации («Какие у тебя есть полномочия на доступ к информации и права на
работу в системе?»);
• администрирования («Как безопасно управлять и централизованно администрировать
всю информационную систему?»).
Практически все ведущие продавцы, разработчики операционных систем, систем ИБ,
ERP-систем и бизнес-приложений (Microsoft, Novell, Linux, IBM, Oracle, Cisco, SAP, Check
Point и др.) поддержали PKI и включили в состав своих продуктов поддержку современных
средств двухфакторной аутентификации (смарт-карты, USB-ключи) для безопасного хранения
закрытых ключей и удобной работы с цифровыми сертификатами, обеспечив тем самым
надежное решение проблемы «трех А».
В данной главе приводится сравнение существующих аппаратных и программных средств
защиты закрытых ключей пользователя, применяемых в современных PKI-решениях.
Показывается, что использование программных контейнеров для хранения закрытых ключей
пользователя в памяти компьютера, который сам по себе является потенциально
небезопасным, или на отчуждаемом носителе является недостаточным для того, чтобы
обеспечить должный уровень безопасности закрытого ключа пользователя. В связи с чем PKI-
решения, предполагающие применение таких средств, заведомо уязвимы.
Единственным надежным средством, обеспечивающим сохранность в тайне закрытых
ключей на всех этапах их жизненного цикла (генерация ключевой пары (закрытый ключ —
открытый ключ), хранение, использование и уничтожение закрытого ключа), являются
специализированные устройства, построенные на основе микросхемы смарт-карты. В них
выполняются все криптографические операции с закрытым ключом, а сам закрытый ключ
никогда не покидает устройство и не может быть из него извлечен.
В настоящее время только аппаратные решения — смарт-карты и USB-ключи на основе
микросхемы смарт-карты, аппаратно реализующие криптографические алгоритмы в
соответствии с национальными стандартами — в состоянии надежно защитить закрытый
ключ пользователя даже при работе в небезопасных средах. Об этом следует обязательно
помнить, проектируя архитектуру PKI-решений или планируя их внедрение.
125
9.2. Необходимость применения аппаратных средств

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

Основной постулат криптографии заключается в том, что закрытые ключи доступны
только их владельцам. Если злоумышленник может получить закрытый ключ какой-либо из
сторон, участвующих в информационном обмене, это значит, что он легко может рас-
шифровать все сообщения, посланные этой стороне. Кроме того, он может подписать лю бое
сообщение от имени легального пользователя и успешно исполнить его роль в ин-
формационном обмене. Таким образом, ни о какой безопасности здесь не может быть и речи.
Более тонкий вопрос, который возникает в этом случае, заключается в том, что не-
отказуемость, как свойство ЭЦП, можно также считать утраченным, как только пользователь
получит возможность утверждать, что его закрытый ключ мог быть нелегально использован
(неважно, действительно ли фактическое воровство имело место или нет).
Признание того факта, что закрытый ключ пользователя мог быть нелегально исполь-
зован, является основанием для поддержки судом заявления о том, что подписанный заказ,
финансовый документ или приказ является фальсификацией. Безусловно, наличие такой
возможности для недобросовестных пользователей носило бы разрушительный характер для
системы электронных цифровых подписей в юридическом контексте транзакций.
126
Глава 9. Применение аппаратных средств аутентификации и хранения ключевой информации
Безопасность закрытого ключа пользователя должна быть обеспечена на каждом этапе его
жизненного цикла:
• Генерация ключевой пары (открытый и закрытый ключи).
• Хранение закрытого ключа.
• Использование закрытого ключа (выполнение криптографических операций, тре-
бующих использования закрытого ключа пользователя, например, формирование
электронной цифровой подписи).
• Уничтожение закрытого ключа.
Безопасность закрытого ключа должна быть обеспечена на

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

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

чению безопасности закрытых ключей:
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. Основные угрозы

Важно понимать и отдавать себе отчет в том, что любые персональные компьютеры
представляют собой потенциально небезопасную среду из-за двух основных угроз:
• Возможность физического доступа. В основе угрозы лежит тот факт, что компьютер в
большинстве случаев является физически доступным и незащищенным. И дело даже
не в краже того же ноутбука, хотя и это не исключено. Во многих компаниях
практикуется посменная работа сотрудников. При этом все они используют один и тот
же компьютер — каждый в свою смену. Соответственно никто из них не мо жет знать,
что происходит с компьютером и кто за ним сидит в другую смену.
Нередки случаи, когда, например, секретарь может покинуть свое рабочее место, оставив
пришедшего в офис посетителя предоставленным самому себе. Кто знает с какой целью он
пришел?
128
Во всех этих случаях получить физический доступ к «бесхозному» компьютеру не со-

ставляет никакой сложности. А это значит, что потенциально злоумышленник может получить
доступ к программному хранилищу.
Фактически любой офис является небезопасной средой и представляет возможности для
проникновения злоумышленника, особенно обладающего навыками социальной инженерии.
Программное хранилище закрытых ключей легального пользователя — сотрудника компании
— может быть захвачено, скопировано или украдено вместе с ноутбуком или карманным
компьютером. Причем в качестве злоумышленника можно легко представить не только
«случайного гостя», но и коллегу по работе или даже уборщицу!
Важно отметить, что простой блокировки компьютера недостаточно, ведь злоумышленник
может просто вручную извлечь жесткий диск и прочесть хранящиеся на нем файлы. (Конечно,
можно принять контрмеры против кражи программного хранилища таким способом,
например, зашифровав содержимое жесткого диска компьютера, однако в большинстве
случаев даже такой «грубый» вариант все еще остается возможным).
• Злонамеренное программное обеспечение (malicious software). Вторую серьезную угрозу
представляет быстро растущее и по качеству, и по количеству злонамеренное ПО, к
которому относятся вирусы, сетевые черви, трояны и др. Стремительное
распространение вредоносных программ ежегодно наносит компаниям колоссальный
ущерб.
Заражение с помощью любого типа злонамеренного ПО может иметь разрушительные
последствия для хранящегося на компьютере пользователя закрытого ключа, защищенного
программными средствами. Написанная специально для этих целей программа-шпион
(spyware) может просто считать файл программного хранилища без ведома хозяина
компьютера и послать его своему автору. Такие программы незаметно «подсаживаются» на
компьютер в ходе просмотра обычных с виду web-страниц.
Специализированные вирусы и троянские программы — реальность! Пример — вирус
Caligula, выпущенный в конце 90-х гг. Он был предназначен именно для похищения закрытых
ключей пользователя системы PGP, которые хранились в программном хранилище.
Более того, описанная выше атака может носить массовый характер, и, таким образом,
множество ключей, хранящихся на компьютерах, могут быть считаны и украдены одним
единственным «шпионом».
Специализированные вирусы и троянские программы —

реальность! Пример — вирус Caligula, выпущенный в конце
90-х гг. Он был предназначен именно для похищения закрытых
ключей пользователя системы PGP, которые хранились в
программном хранилище.
Основные контрмеры и обеспечиваемая ими безопасность

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

рованном виде; используется надежный алгоритм шифрования; ключ шифрования фор-
мируется из пароля пользователя (например, с использованием хэш-функции).
Путаница: данный способ состоит в том, чтобы максимально усложнить поиск про-
граммного хранилища тому, кто несанкционированно попытается получить доступ к за-
крытому ключу. По существу, программное хранилище скрывается благодаря маскировке на
жестком диске пользователя. Чтобы усложнить задачу хакера, используется множество
способов, имеющих эффект «путаницы». Например, один из возможных методов состоит в
том, чтобы сначала зашифровать программное хранилище с закрытым ключом и затем
«прятать» ключ в различных местах на диске пользователя.
Рассмотрим безопасность каждой из описанных выше контрмер. Мы вполне можем
согласиться с тем, что эффект «путаницы» действительно может помочь защититься от
неопытных сетевых злоумышленников. Однако опытный хакер, приложив некоторые усилия,
может обойти этот способ защиты. Таким образом, всецело доверять обеспечение
безопасности «путанице» не стоит, так как она не обеспечивает необходимого для PKI-
решений уровня безопасности.
Что же касается шифрования с помощью пароля, его безопасность в значительной степени
зависит от качества используемого пароля. Важно понимать следующее:
• как только злоумышленник стал обладателем зашифрованного программного хра-
нилища, он может попытаться подобрать пароль и по этому паролю расшифровать
нужную информацию;
• число попыток подбора пароля для программного хранилища неограниченно.
Пробуя вводить подобранные пароли, атакующий может угадать необходимую для до-
ступа комбинацию. Такое нападение называют «атакой по словарю» или «словарной атакой» и
оно в достаточной мере эффективно. Единственный способ предотвратить эту угрозу состоит
в применении сложного пароля, содержащего символьные, цифровые, буквенные значения
разных регистров, и к тому же состоящего из случайного набора символов. Качественный
пароль может выглядеть примерно так: g1UY$AM#&6430Ff '@Nk. К сожалению, запомнить
качественные пароли для большинства пользователей не представляется возможным,
особенно если принять во внимание тот факт, что таких паролей может быть несколько. Таким
образом, в большинстве случаев «словарные атаки» очень успешны.
9.2.5. Выводы о безопасности программных хранилищ

Основная проблема программных хранилищ состоит в том, что они зависят от безопас-
ности среды, в которой они находятся, т. е. компьютера. Однако, как мы уже неоднократно
упоминали, персональные компьютеры небезопасны: как только получен физический доступ
или машина заражена вирусом, закрытый ключ пользователя может быть скомпрометирован.
Стоит добавить, что сам факт атаки может остаться незамеченным для пользователя, и
злоумышленник в течение долгого времени сможет расшифровывать корреспонденцию
легального пользователя и отправлять от его имени и за его подписью фальсифицированную
информацию. Таким образом, важнейшее свойство ЭЦП — неотказуемость — не может быть
достигнуто. Именно поэтому программное хранилище обеспечивает относительно низкий
уровень безопасности, и его использование в организациях, оперирующих конфиденциальной
информацией, должно быть исключено.
Для усиления безопасности закрытых ключей пользователя и обеспечения его мобиль-
ности широко используются внешние отчуждаемые носители. Следует отметить, что ис
130
пользование внешних носителей для сохранения программного хранилища (в качестве

носителя может выступать, например, дискета, CD-диск) обеспечивает мобильность, однако
несущественно повышает безопасность. Содержимое такого носителя загружается на
локальный компьютер всякий раз, когда пользователю необходима ключевая информация
(например, для формирования ЭЦП документа). Удобство и простота — важные
преимущества использования портативного внешнего устройства по сравнению со
стандартным программным хранилищем. Однако эти преимущества не повышают защи-
щенность системы. Почему?
На первый взгляд, кажется, что раз закрытый ключ пользователя не сохранен на ноутбуке
или стационарном компьютере, он надежно защищен. Ведь теперь злоумышленник нуждается
в физическом доступе к внешнему устройству пользователя, а такое устройство мобильно и
его значительно проще обезопасить, чем тот же ноутбук или персональный компьютер. Его
можно хотя бы просто всегда носить с собой.
Однако можно вполне обоснованно утверждать, что достигаемое повышение защи-
щенности (по сравнению с программным хранилищем) крайне незначительно.
• Во-первых, если внешний носитель, например, дискета, даже на короткое время
окажется в руках злоумышленника, он сможет считать с нее информацию. Причем
легальный пользователь — хозяин дискеты — может никогда не узнать о факте ко-
пирования его данных и, следовательно, их компрометации.
• Во-вторых, загруженный с дискеты на компьютер закрытый ключ уязвим для любого
вредоносного программного обеспечения, имеющегося на компьютере пользователя.
• В-третьих, опасность для утечки данных представляют так называемые файлы
подкачки (swap-файлы). В большинстве операционных систем они используются для
временного хранения данных, которые выгружаются для ускорения работы системы.
Облегчая работу компьютеру, технология подкачки всегда несет опасность записи на
жесткий диск в открытом виде данных, которые должны оставаться зашифрованными.
Исходя из вышеперечисленного, можно сделать вывод о том, что уровень безопасности
закрытых ключей пользователя, обеспечиваемый внешними носителями, ненамного выше
уровня безопасности, обеспечиваемого программными хранилищами. Усилить защиту клю-
чевой информации, записанной на взятую нами в качестве примера дискету, можно с по-
мощью пароля. Однако, как мы уже говорили выше, простой пароль уязвим, и, следовательно,
уровня обеспечиваемой им защиты недостаточно. Также не стоит забывать о вирусах, которые
может содержать компьютер пользователя. Парольная защита здесь бессильна.
Использование программных хранилищ — это слишком большой риск для организации,
так как обеспечивает слишком низкий уровень безопасности. При этом последствия вирусной
атаки могут быть необратимыми. Это необходимо учитывать при построении системы
информационной безопасности.
9.2.6. Аппаратные устройства с криптографическими возможностями

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

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

операций аппаратные устройства обеспечивают более
высокий уровень защиты ключевой информации, так как
закрытые ключи никогда не экспортируются из устройства.
Тот факт, что закрытый ключ никогда не экспортируется из памяти устройства, является
фундаментальным шагом вперед к максимально безопасному хранению закрытых ключей.
Рассмотрим снова обозначенную нами парадигму угроз безопасности, но теперь через призму
аппаратного устройства с криптографическими возможностями:
1. Злонамеренное программное обеспечение (malicious software). Предположим, что поль-
зователь подключает аппаратное устройство с криптографическими возможностями на
инфицированную вирусом машину и вводит пароль для авторизации в появившемся на экране
монитора окне. Существует вероятность того, что вирус, находящийся в компьютере, может
подменить собой пользователя и, действуя от его имени, использовать аппаратное устройство
(токен) для подписи сообщения. Однако реализация такой атаки ограничена во времени — она
осуществима только на время физического подключения токена к компьютеру.
2. Физический доступ (phisycal access). Вспомним еще раз о том, что в обсуждаемом нами
типе токенов закрытый ключ хранится в защищенной памяти устройства и никогда не
покидает ее. Поэтому воспользоваться им для проведения криптографических преобразований
можно только в случае получения злоумышленником физического доступа к устройству
(кража, похищение и др.). Если злоумышленник сумеет получить токен легального
пользователя, возникнет угроза компрометации хранящейся в его памяти информации.
Безопасность в этом случае обеспечивается лишь степенью физической защиты,
обеспечиваемой самим устройством. У простейших токенов она минимальна, поэтому сломать
ее и извлечь ключевую информацию не составляет большого труда. Справедливости ради,
отметим, что для взлома защиты часто необходимо разрушить сам токен или просто украсть
его, а, значит, нападение будет обнаружено легальным пользователем. В некоторых случаях,
эта цена слишком высока.
3. В дополнение к перечисленным выше рискам и угрозам, существует потенциально
более разрушительный тип нападения на аппаратные токены — атака на побочные каналы
(side channel attack). Получив физический доступ к токену, атакующий может получить
информацию о закрытых ключах пользователя, измерив такие показатели, как время и
мощность, затраченные в ходе выполнения токеном криптографических преобразований. Да,
возможно, такой тип атаки покажется неправдоподобным, однако на деле он представляет
собой высокоэффективный способ считывания закрытого ключа, к тому же не повреждающий
само устройство.
9.2.7. Смарт-карты и USB-кпючи на основе микросхем смарт-карт

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

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

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

так и в виде USB-ключа, что существенно расширяет область их применения. Более того,
устройства, базирующиеся на технологиях смарт-карт, можно дополнить RFID-меткой для
радиочастотной идентификации, благодаря чему они могут использоваться не только для
входа в сеть, но и для контроля доступа в помещения.
Мобильность смарт-карт и USB-ключей позволяет пользователю безопасно работать в
«запрещенной среде», так как ключи шифрования и ЭЦП генерируются аппаратно
микросхемой смарт-карты, никогда не покидают ее и не могут быть извлечены или пе-
рехвачены.
Большие возможности смарт-карт и USB-ключей на основе микросхемы смарт-карты
позволяют им работать со всеми приложениями, использующими технологии смарт-карт, что
делает их незаменимым средством для проведения защищенных финансовых транзакций,
применения в приложениях, предназначенных для электронной коммерции, а также для
безопасного доступа в корпоративную сеть, к защищенным информационным ресурсам,
порталам и др.
Реализуя принцип двухфакторной аутентификации, данный тип устройств может быть
использован злоумышленником только в том случае, если он будет иметь физический доступ к
устройству и знать его PIN-код, защищенный от подбора. Во всех остальных случаях кража
смарт-карты или USB-ключа на основе микросхемы смарт-карты бесполезна.
Также важно отметить, что существуют международные стандарты безопасности, которые
разработаны специально для смарт-карт и USB-ключей, среди которых наиболее широко
применяются стандарт CWA 14169 (стандарт для изделий, реализующих электронную
подпись — безопасные устройства создания подписи secure signature-creation devices, SSCD) и
профиль защиты для смарт-карт «Smart Card Protection Profile (SCSUG-SCPP)». Многие
производители смарт-карт и USB-ключей на основе микросхем смарт-карт для приложений
информационной безопасности (среди них в первую очередь компания Aladdin — SafeNet)
сертифицируют свою продукцию на соответствие этим стандартам.
К основным особенностям смарт-карт можно отнести следующие:
• Смарт-карты изначально проектируются с учетом требований обеспечения безопас-
ности хранящихся и обрабатываемых на них данных. Существует ряд международных
открытых стандартов (например, семейство стандартов ITSEC) в области обеспечения
безопасности для смарт-карт, которыми руководствуются разработчики.
• Физически (на уровне «железа») и логически (средствами встроенной операционной
системы) обеспечивается защищенное хранение данных и защищенная обработка
данных внутри микросхемы смарт-карты (а не на внешних модулях памяти).
• Аппаратная реализация криптографических алгоритмов.
133
Глава 9. Применение аппаратных
ЧАСТЬ
средств
I. ТЕОРЕТИЧЕСКИЕ
ОСНОВЫ
и хранения ключевой информации
•Другие
Аппаратная
типы персональных
реализация криптографических
идентификаторов (Dallas
функций, Touch
в томMemory,
числе функций
магнитныегенерации
карты,
радио-метки, средства
ключевых генерации одноразовых
пар (открытый/закрытый паролей
ключи), и пр.) сильно
формирования ЭЦП проигрывают смарт-
с использованием
картам закрытого
и USB-ключам.
ключа.
•Преимуществами использования
Обеспечение безопасности технологии
закрытых смарт-карт
ключей в качестве
пользователя на всехсредств
этапах аутенти-
их жиз-
фикации и хранения
ненного циклаключевой информации
(генерация, хранение, пользователей
использование,являются:
уничтожение).
• Архитектурное решение,
Поддержка смарт-карт специально
включена спроектированное
в наиболее популярныедля использования
версии операционныхв системах
систем
обеспечения
для информационной
компьютеров — Microsoft безопасности.
Windows (PC/SC), Linux и его клоны, MAC OS (Open
• Защищенность
Card Framework).микросхем
Это снижает смарт-карт
объем ПОотот различных
разработчика видов атак
средств (по анализу
аутенте- по-
нификации
требляемой
и хранения мощности, от послойноготребуемый
ключевой информации, сканирования, от изучения
к установке разрушающими
на рабочей станции
методами и пр.)
пользователя. Упрощается процесс развертывания устройств в корпоративной среде, их
• Для микросхем
поддержки смарт-карт существуют общепринятые международные стандарты по
и сопровождения.
безопасности,
• Простая которыми
конструкция руководствуются
устройства, за счет чего разработчики микросхем и смарт-карт
повышаются надежность стабильность и
операционных систем для смарт-карт, такие как стандарт CWA 14169
работы устройства в целом (так как используется меньшее число компонентов). — стандарт для
изделий, реализующих
• Становится возможным электронную
сертифицировать подпись — безопасные
устройство устройства
аутентификации создания
и хранения
подписи secure
ключевой signature-creation
информации в целом, а неdevices, SSCD; профиль
только отдельных защиты для
его компонентов. Длясмарт-карт
устройств
«Smart Card Protection
аутентификации Profile (SCSUG-SCPP).
и хранения ключевой информации, построенных на основе
• Сертификация
микроконтроллера, чащепроизводится
изделий на соответствие
всего разработчику международным лишь
удается сертифицировать стандартам
один изв
независимых испытательных лабораториях,
компонентов устройства, но не устройство в целом. а не самим производителем на со-
ответствие собственным
• Возможность декларациям.
создания устройств аутентификации и хранения ключевой информации
пользователей в различных форм-факторах: смарт-карты и USB-ключа. Формат смарт-
карты наиболее востребован корпоративными заказчиками, которые применяют смарт-
карты как единое устройство для контроля логического доступа (доступ к
информационным ресурсам) и физического доступа (контроль доступа в помещения,
визуальный контроль по фотографии, напечатанной на поверхности смарт-карты).
Смарт-карты также необходимы на защищенных рабочих станциях, где по
требованиям безопасности недопустимо использование портов USB.
Разработчик средств аутентификации и хранения ключевой информации может расширить
функции устройства путем написания так называемых пакетов для операционной системы
смарт-карты или Java-аплетов (если речь идет о Java-карте). Функции могут быть расширены
разработчиком устройства, например для добавления поддержки национальных алгоритмов
шифрования или расширения функций устройства. Хорошим примером является USB-ключ
eToken PRO (Java) производства компании Aladdin, в котором поддержка российских
криптографических алгоритмов (в соответствии с ГОСТ Р 34.10—2001 и ГОСТ Р 34.11—94)
реализована в виде Java-аплета, исполняемого на смарт-карте.
9.3. Типовые требования к средствам аутентификации и

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

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

Данная поддержка должна быть реализована:
• на аппаратном уровне (реализация национальных криптографических алгоритмов
самим устройством);
• на программном уровне (ПО промежуточного слоя — библиотека PKCS#11 и/или
криптопровайдер стандарта Microsoft CSP, — позволяющее разработчикам при-
кладного ПО легко встроить поддержку устройств в свои продукты).
При аппаратной реализации национальных криптографических алгоритмов разработчик
устройства в первую очередь должен обеспечить поддержку национального стандарта ЭЦП
(генерация устройством пар открытый/закрытый ключ, их безопасное хранение,
использование и гарантированное уничтожение).
Также следует предусмотреть совместимость с наиболее распространенными типами
национальных средств криптографической защиты информации (СКЗИ) (в России —
КриптоПро CSP, Домен-К, Signal-COM, Верба-OW и др.) и возможность импорта ключевой
информации пользователей этих СКЗИ с незащищенных носителей (дискета, реестр Windows)
в устройство.
9.3.2. Поддержка международных криптографических стандартов

Для участия в международном информационном обмене следует предусмотреть аппа-
ратную и программную поддержку устройством международных и межгосударственных
криптографических стандартов. Примером действующего международного стандарта является
алгоритм RSA. В качестве межгосударственного стандарта стран СНГ выступает алгоритм
формирования и проверки ЭЦП в соответствии с ГОСТ Р 34.310—2004.
9.3.3. Сертификация средств аутентификации и

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

быть сертифицированы в системе сертификации средств защиты информации. Средства
аутентификации и хранения ключевой информации также реализуют аппаратно (и
программно) национальные криптографические алгоритмы. Они относятся и к категории
СКЗИ, что потребует от разработчика наличия лицензии на деятельность в данной области, а
также выполнения предусмотренных процедур их проектирования и разработки (например,
положение ПКЗ-2005).
Таким образом, разработчик должен иметь лицензии на соответствующие виды де-
ятельности и предусмотреть сертификацию создаваемых средств:
• в системе сертификации средств защиты информации (ФСТЭК России);
• в Федеральной Службе Безопасности России (как СКЗИ);
• в отраслевых системах добровольной сертификации (например, ГАЗПРОМСЕРТ) — по
требованию потребителя.
9.3.4. Возможность использования без установки дополнительного

ПО
на клиентской рабочей станции
Данное требование вытекает из сценариев использования устройства пользователем в
системах Интернет-банкинга, системах дистанционного банковского обслуживания (ДБО) и
других сферах, где очень важны как доступность услуги (сервиса) самому широкому кругу
пользователей, так и обеспечение юридической значимости транзакций (действий),
выполняемых пользователем в процессе работы.
Выполнение требования доступности сервиса (услуги) приводит к тому, что необходимо
предусмотреть возможность полноценной работы пользователя с рабочих станций
(терминалов), где у него нет прав локального администратора и поэтому нет возможности
проводить установку ПО. Все компоненты, необходимые для функционирования устройства,
должны либо входить в состав наиболее популярных операционных систем, либо быть
доступны для автоматического скачивания с сайтов обновлений к ОС (например, для OC
семейства Microsoft Windows, это сайт Windows Update).
9.3.5. Размещение и исполнение нескольких приложений на

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

циклом устройств
Массовый характер использования средств аутентификации и хранения ключевой
информации предусматривает их эмиссию большому числу пользователей. При этом не-
обходимо иметь единую централизованную систему управления этими устройствами, которая
позволяет:
137
• вести реестр выпущенных устройств;

• управлять их жизненным циклом (при любых масштабах эмиссии);
• обеспечивать пользователей web-сервисами самообслуживания для самостоятельного
(и удаленного) решения задач, возникающих в процессе эксплуатации устройств;
• вести аудит использования устройств (во внутрикорпоративной сети);
• создавать отчеты (управленческие, для служб ИТ и ИБ).
9.3.7. Два форм-фактора исполнения: USB-кпюч и смарт-карта

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

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

распространенными
средствами аутентификации и хранения
ключевой информации пользователей
В настоящее время наиболее распространенным средством аутентификации и хранения
ключевой информации пользователей являются электронные ключи eToken компании Aladdin.
По состоянию на начало 2008 г., компания Aladdin контролировала 70—75% российского
рынка этих средств. Оставшийся сегмент рынка был распределен между изделиями
отечественных производителей — электронные ключи ruToken (компания Актив), Шипка
(ОКБ САПР) и зарубежных — электронные ключи iKey (Rainbow Technologies, ныне —
SafeNet), RSA SecurlD (RSA, ныне — подразделение EMC).
В процессе перехода на новые средства аутентификации и хранения ключевой ин-
формации должна быть обеспечена полная обратная совместимость с уже имеющимися у
заказчика аналогичными средствами. Так как электронные ключи eToken PRO занимают
доминирующее положение на российском рынке средств аутентификации и хранения
ключевой информации, а электронные ключи eToken PRO (Java) полностью обратно
совместимы с eToken PRO, то выбор именно eToken PRO (Java) в качестве платформы для
средств следующего поколения представляется наиболее целесообразным.
9.4. Особенности корпоративного использования

персональных средств аутентификации и
9.4.1. Многоуровневая ролевая модель доступа
При корпоративном внедрении крайне важна возможность реализации многоуровневой
ролевой модели доступа. Как правило, эта модель включает следующие уровни разграничения
полномочий доступа к персональным средствам аутентификации и хранения ключевой
информации:
• Уровень пользователя. Конечный пользователь использует пользовательский PIN-код
для выполнения ежедневных задач аутентификации, доступа к данным и т. д.
• Уровень администратора информационной безопасности (офицера ИБ). Админи-
стратор ИБ устанавливает ряд параметров для применяемых в организации средств
аутентификации и хранения ключевой информации (например, требования к качеству
PIN-кода), соответствующих действующей политике ИБ. Администратор ИБ
использует PIN-код администратора при необходимости разблокирования
персонального идентификатора и/или смены забытого PIN-кода пользователя.
139
• Уровень производителя. PIN-код этого уровня используется для:

^ полного переформатирования персонального средства аутентификации и хранения
ключевой информации с полным удалением всех хранящихся в памяти устройства
данных;
^ установки параметров, соответствующих требованиям действующей политики ИБ на
предприятии (например, максимально допустимое число последовательных
неудачных попыток ввода PIN-кода до блокирования устройства).
В данной модели каждый из субъектов действует на своем уровне в рамках делегиро-
ванных ему полномочий и установленных ограничений. Применяемые средства аутен-
тификации и хранения ключевой информации должны поддерживать все три уровня
разграничения полномочий.
9.4.2. Интеграция с системами контроля и

управления доступом в помещения (СКУД)
Смарт-карты и USB-ключи могут выступать как единое средство доступа к различным
информационным ресурсам, а смарт-карты с нанесенной на них информацией о владельце и
его фотографией — еще и как средство визуальной идентификации.
140
Смарт-карты и USB-ключи могут применяться как единое

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

чипом, Proximity), используемым в бесконтактных «электронных проходных». Это позволит
повысить уровень безопасности и удобства — смарт-карта или токен не может быть оставлен
подключенным к компьютеру или передан другому лицу, так как без него нельзя покинуть
помещение. Также становится возможным отслеживание перемещения сотрудников, а при
интеграции с системами телефонии — перевод звонков в те помещения, где в данный момент
находится сотрудник.
9.4.3. Централизованная система управления
При корпоративном внедрении проектов, использующих технологии PKI, необходимо

централизованно управлять распределением и вести учет всех средств аутентификации и
хранения ключевой информации, используемых в организации. Это могут быть смарт-карты,
USB-ключи, генераторы одноразовых паролей, комбинированные устройства (например, USB-
ключ с микросхемой смарт-карты и генератором одноразовых паролей).
Система централизованного учета и управления необходима для поддержки исполнения
политики ИБ организации и является эффективным средством интеграции различных средств
защиты информации (СЗИ).
Централизованная система управления должна:
• производить централизованное автоматическое тиражирование/обновление/удале- ние
пользовательских данных в памяти устройств, а также проводить их разблокировку и
форматирование;
• обеспечивать блокировку утерянных персональных средств аутентификации и хра-
нения ключевой информации, выполнять отзыв (блокировку) содержавшихся на них
аутентификационных данных и ключевой информации;
• позволять использовать групповые политики для делегирования и отзыва прав и пол-
номочий пользователям, а также реализовать единую политику назначения PIN-кодов
персональных идентификаторов;
• определять список приложений ИБ, доступ к которым имеет владелец данного
средства аутентификации;
• собирать статистику и вести аудит использования средств аутентификации и хранения
ключевой информации;
• интегрироваться со службой каталога (например, Microsoft Active Directory или
OpenLDAP);
• осуществлять дистанционное обновление программного обеспечения на клиентских
рабочих местах.
141
9.5. Централизованная система управления

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

Применение аппаратных средств аутентификации и хранения ключевой информации
пользователей ставит задачи контроля их распространения и управления их жизненным
циклом в рамках организации. Без системы управления обеспечение таких связей может
оказаться чрезвычайно сложным и длительным, что приводит к большим затратам на
внедрение и росту вероятности возникновения ошибок.
Для примера возьмем сотрудника, который только поступил на работу в организацию.
Назначение и регистрация средства аутентификации. Чтобы начать работу, сотруднику
необходимо получить токен. Без системы управления администратор должен перед этим
вручную настроить и «привязать» токен к учетной записи пользователя, используя различные
системы для формирования и сохранения учетных записей нового сотрудника в памяти токена.
Такой процесс регистрации токенов вручную несет в себе вероятность ошибки.
Предоставление новому сотруднику неправильных учетных записей и/или прав доступа,
может привести к нарушению режима ИБ.
Восстановление PIN-кода токена. Если сотрудник забыл PIN-код своего токена, то он не
сможет пройти аутентификацию, войти в сеть и выполнить свою работу. Без инструмента
самообслуживания для восстановления PIN-кода токена, вместо того, чтобы быстро
восстановить PIN-код самостоятельно, сотрудник должен связаться со службой поддержки
пользователей. При этом тратятся время и средства компании.
Замена утерянного токена. Сотрудник может потерять токен. При этом администратор
должен вручную:
• отозвать (заблокировать) все учетные записи пользователя для доступа ко всем
информационным системам, с которыми работал пользователь;
• сформировать новые учетные записи;
• выдать пользователю новый токен и занести в его память новые учетные записи.
142
При этом опять возникает вероятность ошибки, так как администратор может забыть
отозвать некоторые учетные записи, с помощью которых пользователь позже сможет получить
несанкционированный доступ.
При наличии в организации 100 и более токенов система

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

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

Регистрация. Токен «связывается» с конкретным пользователем и регистрируется в сис-
теме, в соответствии с ролью пользователя в организации и корпоративными политиками
безопасности. В память токена записываются аутентификационные данные и ключевая
информация.
Использование и поддержка. Аутентификационные данные и ключевая информация
пользователя, а также настройки самого токена периодически изменяются. Например, это
может произойти из-за перевода сотрудника на другую должность, когда изменяется круг
приложений, с которыми работает пользователь, а также при регламентной смене аутен-
тификационных данных. Пользователь самостоятельно осуществляет поддержку токена
(например, смену PIN-кода). При утере или повреждении токена хранящиеся в его памяти
аутентификационные данные и ключевая информация либо аннулируются, либо восста-
навливаются, если это возможно.
Отзыв. Когда сотрудник покидает организацию, назначение токена ему отменяется.
Аутентификационные данные и ключевая информация пользователя, хранящиеся в памяти
токена, аннулируются.
Возврат в эксплуатацию. Токен может быть выдан новому сотруднику. Перед реги-
страцией токена он должен быть приведен в исходное состояние и персонализирован для
нового пользователя.
Ниже приведен обзор главных стадий и процессов жизненного цикла токенов.
9.5.3. Выпуск и распространение

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

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

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

«Потеря токена» и «Повреждение токена»
Система управления обеспечивает быстрый процесс замены утерянного или повреж-

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

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

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

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

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

экономию средств и времени для организации.
9.6. Типовые требования к

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

ления жизненными циклами различных устройств и приложений. Она должна давать
организации возможность централизованно управлять всеми аспектами использования
токенов.
145
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 расширяется
схема экземпляра AD. TMS хорошо сочетается с уже существующей в организации
инфраструктурой информационных технологий. Система предоставляет интерфейс управ-
146
ления в AD, позволяющий администраторам выполнять свои функции по отношению к

Гл
токенам средствами, сходными с созданием и управлением групповыми политиками. ав
В TMS применяется веб-интерфейс для взаимодействия пользователя с системой. Поль- а
9.
Организационные политики Пользователи и устройства
зователь имеет возможность самостоятельно управлять токеном через настраиваемый веб-сайт Пр
им
предприятия. Это дает пользователям возможность регистрировать токены и сразу начинать их ен
использовать, переустановить забытый PIN-код (разблокировать токен) и выполнять иные ен
ие
действия (рис. 9.1). ап
па
Открытая модульная архитектура TMS позволяет управлять использованием токенов с ра
т
применением решений по безопасности сторонних разработчиков. Эта возможность ны
достигается путем применения «коннекторов» TMS — настраиваемых подключаемых х
ср
модулей, используемых на сервере. Компания Aladdin предоставляет набор для разработчика ед
ст
коннекторов TMS, который позволяет поставщикам решений безопасности создавать в
собственные коннекторы и тем самым дополнять свои решения, использующие eToken, ау
т
средствами администрирования. В настоящее время разработаны коннекторы для УЦ ен
т
«КриптоПро УЦ» и УЦ RSA Keon. и
ф
ик
ац
9.7.1. Назначение ии
и
хр
• Поэкземплярный учет и регистрация всех аппаратных и программных средств аутен- ан
тификации и хранения ключевой информации, используемых сотрудниками. ен
ия
• Ускорение ввода в эксплуатацию электронных ключей и смарт-карт, автоматизация кл
юч
процессов выдачи eToken сотруднику, персонализация eToken, запись ключевой ев
информации и аутентификационных данных в память eToken. ой
ин
• Управление жизненным циклом средств аутентификации и хранения ключевой ин- ф
ор
формации: обновление аутентификационных данных и ключевой информации, ма
ци
предоставление/отзыв прав доступа к приложениям при изменении служебных и
обязанностей/увольнении сотрудника, замена устройства при его утере/повреж- дении,
Приложение безопасности
вывод устройства из эксплуатации.
• Аудит использования сотрудником выданного ему средства аутентификации и хра-
нения ключевой информации (фиксируются все Рис. 9.1.
фактыСистема управления TMS
использования устройства
сотрудником на компьютере предприятия, изменения хранящихся в памяти устройства
данных).
• Подготовка отчетов для руководителей служб ИТ и ИБ об использовании сотрудниками
средств аутентификации и хранения ключевой информации (на основе данных аудита
средствами встроенного генератора отчетов, также имеется возможность экспорта
данных во внешние средства построения отчетов).
• Техническая поддержка и сопровождение пользователей средств аутентификации через
веб-сайт технической поддержки: переустановка забытого пользователем PIN-кода
устройства, синхронизация генератора одноразовых паролей, обработка типовых
ситуаций «пользователь забыл eToken», «пользователь потерял eToken», «пользователь
повредил/сломал eToken».
9.7.2. Возможности
• Поддержка всех типов и моделей электронных ключей eToken (смарт-карты, USB-
ключи, комбинированные USB-ключи, программные или виртуальные токены).
• Интеграция со службой каталога Microsoft Active Directory.
148
• Веб-сайты для самостоятельного решения пользователем проблем, возникающих в

ходе эксплуатации eToken, оказания технической поддержки пользователям eToken
специалистом сервисной службы (help desk web site), веб-сайт для администрирования
системы.
• Открытая архитектура, позволяющая добавлять в систему поддержку новых при-
ложений и аппаратных устройств (через механизм коннекторов).
• Масштабируемое, распределенное администрирование:
^ администрирование систем eToken TMS, установленных в разных доменах, с одного
рабочего места администратора;
^ ролевое администрирование, возможность делегирования полномочий.
• Аудит использования средств аутентификации и хранения ключевой информации
сотрудниками, гибкая система построения отчетов на основе данных аудита.
• Отказоустойчивость и масштабируемость системы, поддержка кластерных технологий
Microsoft Windows 2003/2008.
• Централизованная установка клиентского ПО на рабочие станции пользователей.
• Широкий спектр поддерживаемых клиентских ОС: Windows, Linux, Mac OS; любая
ОС при использовании одноразовых паролей.
• Полная поддержка русского языка.
• Виртуальный токен — уникальное программное решение, позволяющее пользователю,
находящемуся вне офиса, даже в случае утери/повреждения eToken продолжить работу
с компьютером или получить безопасный доступ к ресурсам.
9.8. Практика: комплексная система на базе

единого персонального средства аутентификации и
На примере простой гипотетической корпоративной системы попробуем выяснить, с
какими трудностями чаще всего приходится сталкиваться при выборе единого персонального
средства аутентификации и хранения ключевой информации, на основе каких принципов
можно сформулировать критерии такого выбора.
Современные системы обеспечения информационной безопасности состоят, как правило,
из нескольких объединенных посредством централизованного управления подсистем,
включающих в себя разнородные сервисы безопасности. Следовательно, и задачи управления
доступом пользователей с помощью единого персонального средства аутентификации к
различным подсистемам, подчас не связанным напрямую между собой, отнюдь не кажутся
тривиальными. Тем более что еще несколько лет назад производители систем защиты
информации (СЗИ) настраивали их работу только на определенные типы аутентификаторов.
Поэтому до сих пор для доступа к одному защищенному приложению пользователю
приходится пользоваться дискетой, к другому — смарт-картой, а к третьему — токеном или
труднозапоминаемым паролем. С точки зрения централизованного управления доступом и
прозрачного администрирования при наличии десятков информационных систем более
удобным является введение единого персонального идентификатора, в котором надежно
хранятся параметры доступа пользователя во все разрешенные области информационного
пространства предприятия.
149
9.8.1. Бизнес-задачи по защите корпоративной информации

Наша гипотетическая организация в той или иной степени решает такие задачи, как:
• разграничение и контроль доступа зарегистрированных во внутренней сети поль-
зователей к рабочим станциям и корпоративным информационным ресурсам;
• организация защиты корпоративных ресурсов, в том числе баз данных, содержащих
информацию, утечка которой критична для существования бизнеса компании;
• предоставление безопасного доступа к порталу компании, в том числе к защищенным
веб-страницам;
• защищенный обмен информацией территориально удаленных подразделений;
• внедрение и поддержка сервиса электронной цифровой подписи (ЭЦП);
• защищенный вход в бизнес-приложения;
• защита корпоративной почты и документооборота;
• организация полноценной работы удаленных пользователей;
• физическая защита рабочих помещений (системы контроля и управления доступом);
• оперативное и эффективное управление информационной инфраструктурой.
Данный перечень условимся считать оптимальными бизнес-требованиями комплексной
защиты. При этом под задачей организации защищенного доступа к корпоративной сети, как
уже упоминалось, будем понимать применение технологий, основанных на использовании
закрытых ключей и цифровых сертификатов стандарта Х.509.
Например, для сетей под управлением сервера Windows 2000/2003/2008 эта технология
основана на возможности запрета доступа к сети по паролю и разрешения доступа по
предъявлении пользователем сертификата из защищенной памяти персонального
идентификатора (смарт-карты или USB-ключа) и проверке его валидности (протокол Kerberos
+ PKINIT).
Вопрос защиты корпоративных баз данных рассмотрим на примере СУБД Oracle, по-
скольку начиная с версии 8i данная СУБД оснащена встроенной поддержкой PKI, что
позволяет организовывать доступ к корпоративной базе по предъявлении цифрового сер-
тификата, сформированного штатными средствами Oracle.
Проблемы организации доступа к корпоративному порталу, защищенным приложениям и
обеспечение работы удаленных пользователей проанализируем на примере технологий,
основанных на использовании цифровых сертификатов.
Для применения ЭЦП в качестве гарантии конфиденциальности (защита от НСД),
целостности (защита от внесения изменений), доступности для легальных пользователей,
аутентичности (подтверждение авторства) и неотказуемости (несмотря на внесенные из-
менения в документы и почтовые сообщения) требуется применение средств криптогра-
фической защиты информации (СКЗИ). При этом персональное средство аутентификации и
хранения ключевой информации должно обеспечить надежное хранение ключевых
контейнеров применяемых СКЗИ.
Физическая защита рабочих помещений пользователей обеспечивается, как правило, с
помощью систем контроля и управления доступом, основанных на применении RFID-тех-
нологий (Radio Frequency Identification Device — радиочастотная идентификация).
Можно выделить основные технологии информационной защиты, позволяющие решать
типичные проблемы, составляющие вышеперечисленный оптимальный набор бизнес-задач:
• аутентификация пользователей;
• криптографическая защита электронных документов (шифрование, ЭЦП);
• межсетевое экранирование, защита каналов связи и VPN;
• RFID-технологии.
150
Иные технологии, не вошедшие в список, будем считать комбинацией перечисленных

выше методов (например, защиту удаленного доступа или беспроводных соединений можно
рассматривать как комбинацию технологии аутентификации и защиты сетевого трафика).
Каждая из перечисленных технологий в той или иной степени связана с активным ис-
пользованием персональных устройств аутентификации и хранения ключевой информации:
• в рамках систем аутентификации данные устройства используются в качестве но-
сителей атрибутов доступа пользователей к информационным и (или) вычислительным
ресурсам;
• в рамках СКЗИ — для хранения ключевых контейнеров и выполнения криптопре-
образований;
• при защите каналов связи и организации VPN — для аутентификации удаленных
пользователей и сетевых устройств, выработки сеансовых ключей шифрования
трафика;
• в рамках систем контроля и управления доступом (СКУД), основанных на исполь-
зовании RFID-технологии, персональные устройства играют центральную роль
маркеров доступа, в зависимости от состояния которых принимается решение о
допуске пользователей в те или иные помещения.
Таким образом, проблема выбора единого персонального средства аутентификации и
хранения ключевой информации может быть решена путем приобретения универсального
устройства, отвечающего перечисленному оптимальному набору бизнес-задач по защите
информации, плюс возможность интеграции с установленными средствами защиты и
унаследованными (как правило, не поддерживающими сертификат Х.509) приложениями.
Рассмотрим типичные трудности, с которыми можно столкнуться при этом.
9.8.2. Проблемы выбора персонального устройства

Если вы хотите объединить все установленные системы защиты информации и применить
для доступа единое средство аутентификации и хранения ключевой информации, то
неизбежно столкнетесь со следующими трудностями:
• системы защиты информации работают с конкретными типами идентификаторов;
• СКЗИ настроены на использование определенных идентификаторов;
• RFID-метки размещаются только в смарт-картах;
• не все типы идентификаторов могут быть универсальными (применимыми к разным
системам).
В частности, для того, чтобы полностью отвечать бизнес-задачам защиты информации,
персональный идентификатор должен как минимум содержать процессор для выполнения
криптографических операций на закрытом ключе пользователя и иметь достаточно большой
(порядка 20—40 килобайт) запас свободной энергонезависимой памяти для записи цифровых
сертификатов (каждый сертификат занимает в среднем от 1,5 до 2 Кбайт) и других параметров
доступа к системам, которые не могут поддерживать использование сертификатов стандарта
Х.509 для аутентификации. Прежде чем рассмотреть существующие идентификаторы с точки
зрения выполнения перечисленных выше задач, попробуем сформулировать критерии выбора.
151
9.8.3. Критерии выбора

Для выбора персонального средства аутентификации и хранения ключевой информации
предлагается применять следующие минимальные бизнес-критерии.
1. Обеспечение строгой (двухфакторной) аутентификации при доступе к корпоративной
сети, информационным ресурсам, защищенным приложениям.
2. Возможность защищенного хранения в персональном идентификаторе ключевого
контейнера, сформированного СКЗИ, закрытого ключа пользователя (в терминах PKI).
3. Обеспечение защиты критичной информации от несанкционированного доступа.
4. Наличие необходимого объема свободной памяти в персональном идентификаторе для
записи ключевой информации и других параметров доступа пользователя к защищенным
ресурсам.
5. Надежность идентификатора как хранилища ключевой информации (физическая
защита чипа, гарантированный срок применения, соответствие отечественным и меж-
дународным стандартам).
6. Приемлемая средняя стоимость.
Насколько хорошо отвечают широко известные типы идентификаторов (парольная защита,
дискета, устройство iButton, USB-ключи/смарт-карты) сформулированным критериям?
Детальный анализ показывает, что парольная защита, дискета и устройства iButton не
отвечают указанным критериям. Наиболее приемлемыми (исходя из минимальных критериев)
являются устройства класса USB-ключа eToken. Заметим, что функционально eToken PRO и
смарт-карта, содержащая чип, идентичны, поскольку eToken — это смарт-карта и считыватель
в одном устройстве.
Парольная защита не может использоваться для решения рассматриваемых задач защиты
корпоративной информации.
Несложно объяснить, почему до сих пор многие заказчики предпочитают пользоваться
персональными идентификаторами в виде дискеты. На этот выбор влияют три фактора: низкая
стоимость, большой объем памяти и то, что дискета в качестве носителя поддерживается
практически всеми отечественными производителями систем криптографической защиты
информации. При этом не учитывается тот факт, что в случае попадания дискеты в руки
злоумышленника (этого достаточно — никакой защиты нет) от вашего имени (а во многих
случаях и с вашей подписью) могут быть совершены действия, последствия которых приведут
к краху бизнеса предприятия. К тому же дискета недолговечна, скажем, в интенсивно
используемых приложениях типа систем «клиент-банк» в течение года приходится менять
десятки дискет в расчете на одного пользователя. При этом на каждую замену тратятся время
и деньги не только пользователя, но и производителя системы.
Не представляется возможным персонифицировать пользователя «таблеток» iButton.
Характерно на этот счет высказывание одного из специалистов по защите информации: «При
использовании "таблетки" iButton в качестве персонального идентификатора вы получаете
защиту корпоративной информации на уровне домофона».
Таким образом, в качестве универсальных персональных идентификаторов можно
порекомендовать только устройства класса процессорной смарт-карты и USB-ключа
(например, смарт-карты или USB-ключи eToken компании Aladdin).
152
1. На каких этапах должна быть обеспечена безопасность закрытого ключа пользователя?
2. Перечислите подходы к обеспечению безопасности закрытых ключей.
3. Опишите жизненный цикл токенов.
4. Перечислите функции централизованной системы управления.
5. Перечислите основные критерии выбора персонального средства аутентификации и
хранения ключевой информации.
Список использованной литературы

1. A Guide to Understanding Identification and Authentication in Trusted Systems, U.S. National Com puter
Security Center.
2. Курило А. П. и др. Обеспечение информационной безопасности бизнеса. — М.: БДЦ-Пресс, 2005.
3. Документ RFC 4226, http://www.ietf.org/rfc/rfc4226.txt.
4. eToken NG-OTP. Краткая справочная информация. — Компания Aladdin, эксплуатационная
документация, 2006.
5. Федеральный закон Российской Федерации от 10 января 2002 г. N 1-ФЗ «Об электронной цифровой
подписи».
6. Ричард Э. Смит. Аутентификация: от паролей до открытых ключей. — М.: Вильямс, 2002.
7. Рекомендации к средствам криптографической защиты информации на взаимодействие удосто-
веряющих центров, реестров сертификатов, сертификаты ключей формата X.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. Рассел Ч., Кроуфорд Ш., Джеренд Дж. Microsoft Windows Server 2003. Справочник администратора.
— М.: Издательство «Эком», 2006.
12. Мак-Федрис П. Microsoft Windows XP. Полное руководство. — М.: Вильямс, 2006.
13. [CMS] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3852, July 2004.
14. [CPALGS] Popov, V., Kurepkin, I., 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. [CPPK] 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.
153
17. [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.
18. [SMIME] B. Ramsdell, «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message
Specification», RFC 3851, July 2004.
19. Веб-сайт компании Майкрософт для технических специалистов (на русском языке)
http://technet.microsoft.com/ru-ru/default.aspx.
20. Майкл Уэнстром. Организация защиты сетей Cisco (Managing Cisco Network Security). Изда-
тельство «Вильямс», 2003, 768 стр. ISBN 5-8459-0387-4, 1-5787-0103-1.
21. Шиндер Д. Основы компьютерных сетей. Серия: Cisco Press, 2002 г., 656 стр., ISBN: 5845902851,
1587130386.
22. Дэвид В. Чепмен мл., Энди Фокс. Брандмауэры Cisco Secure PIX Издательство: Вильямс, 2003 г.,
384, с ил. ISBN: 5-8459-0463-3, 1-5870-5035-8.
23. Кэтрин Пакет. Создание сетей удаленного доступа 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. Альваро Ретана, Дон Слайс, Расс Уайт. Принципы проектирования корпоративных IP-сетей.
Издательство: Вильямс, 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
ЧАСТЬ II. ПРАКТИКА
Рис. 1.1. Служба каталога
ЛСТ1У| DIPFC 1 CiKf i I.H'lit 1СЛТ] 41 RV]CI.S
ttltll И.Л11.
jtmvhn
A i ' I ' I V I П К КС [ O H ' S ( I lh Ч J WORKSTAl \<>\i
Рис. 1.2. Служба аутентификации с помощью сертификатов
158
Глава 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) является
для администраторов основным инструментом в построении корпоративной инфраструктуры
с возможностью защищенного обмена идентификационными данными. Здесь обыч-
C O M PA NftYк SU \ I Ял РА R I NI К
SIMJJI KXJUS Р Л Н Т Е Ч k W I . B A P F А ! он
СИ № М1Л1 thk
ЯШ PARTM.ES
HI SI Rt Ч
lSIAULlSIltD bSI AlH ISHfct>
AL ГIVI П1Е1 i ГОНЧ v m i I J K i L ( i RY

I I h i k s l l L > \ s i RV l t 1 4 N h i k . u l r № 41- H v и i s
Рис. 1.3. Служба управления федеративными отношениями
159
но возникает ряд вопросов, разрешить которые позволяет именно 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)
Основные цели и задачи данной службы (рис. 1.4):
• исключение неавторизованного доступа и компрометации конфиденциальной ин-
формации (отметим, что RMS предназначен для защиты информации вне сети/инф-
раструктуры владельца);
• снижение рисков, связанных с потерей конкурентноспособности организации.
• повышение безопасности информации с помощью постоянной защиты данных;
• простое внедрение готового решения с возможностью интеграции с приложениями
(Microsoft Office System) почтовой системы и службой каталога Active Directory;
• интеграция с продуктами третьих фирм с помощью использования комплекта раз-
работчика (RMS SDK).
1.1.5. Служба управления идентификацией

(Identity Lifecycle Management)
Основные цели и задачи службы управления идентификацией (рис. 1.5):
• простое и эффективное управление большим количеством цифровых удостоверений
различных форматов;
• снижение рисков и стоимости владения при ручном управлении (provisioning и de-
provisioning) идентификаторами пользователей (user identities);
160
Рис. 1.4. Служба защиты информации
V l iv t I H n t.( Ul RY
\ \ /
I I L I П К И Й \С\1
ЛЧГ) Ч\1 IHI СлЯр \ 1 Л1 \ к \ м
I t l 1 CYC I [ S’. Ms
M vs U.L Ml NI
1 M Ml SYSTEM IdraUty Lifecycle HR SYSTEM
Vfn linger 2007

Рис. 1.5. Служба управления идентификацией
161
• упрощение управления средствами аутентификации пользователей, такими как смарт-

карты и цифровые сертификаты;
• упрощение поддержки пользователей, например, при смене паролей.
Преимущества при ее использовании :
• реализация принципа «один пользователь — одна учетная запись в системе»;
• объединение управления всеми видами цифровых удостоверений и носителей;
• создание единого метакаталога организации;
• возможность автоматизации обслуживания и самообслуживания пользователей (на-
пример, при смене пароля или изменении 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 также обеспечивает поддержку следующих протоколов:
• X.509 v3/Smartcard;
• проверка подлинности Digest;
• проверка подлинности .NET Passport;
• аутентификация удаленного пользователя — расширенный протокол EAP-TLS;
• аутентификация при установлении защищенного канала — протокол SSL/TLS;
• аутентификация хостов при установлении сеанса IP Security.
162
Использование протокола Lan Manager крайне нежелательно из-за его невысокой на-
дежности. Вместе с тем, он нередко используется в сетях Active Directory. Это мотивируется
необходимостью обеспечения «совместимости» с клиентами на основе Windows 9Х. Однако,
после установки клиента Active Directory Services (ADSC) в Windows 9Х появляется
возможность поддержки протокола аутентификации NTLM v2, что позволяет отказаться от
использования LM в сети. Кроме того, установка клиента ADS предоставляет ряд других
преимуществ, таких как поиск через Глобальный каталог, изменение пароля на любом
контроллере домена и пр. В Windows NT 4.0 поддержка NTLM v2 появляется после установки
пакета Service Pack 4.
Таким образом, в смешанной сети, где присутствуют pre-Windows 2000 компьютеры, для
повышения безопасности аутентификации рекомендуется:
1) установить на все компьютеры Windows 9X клиент ADS;
2) установить на все компьютеры с Windows NT 4.0 пакет обновлений не ниже 4-го;
3) через групповую политику запретить использование LM и NTLM.
Дополнительную информацию см. в статье KB239869 на веб-узле корпорации Microsoft.
Наиболее защищенным является протокол аутентификации Kerberos, реализованный
в ОС Microsoft, начиная с Windows 2000. Ниже перечислены его основные преимущества.
Более эффективная аутентификация на серверах. При аутентификации по протоколу
NTLM серверу приложений приходится подключаться к контроллеру домена при проверке
каждого клиента. С Kerberos такая необходимость отпадает — здесь аутентификация
производится за счет проверки удостоверения, представленного клиентом. Индивидуальное
удостоверение клиент получает от контроллера единожды, после чего может неоднократно
использовать его на протяжении всего сеанса работы в сети.
Взаимная аутентификация. Протокол NTLM позволяет серверу идентифицировать своих
клиентов, однако не предусматривает верификации сервера ни клиентами, ни другими
серверами. Этот протокол разрабатывался для сетей, в которых все серверы считаются
легитимными. В отличие от него, Kerberos такого допущения не делает, поэтому проверяет
обоих участников сетевого подключения, каждый из которых в результате может точно узнать,
с кем поддерживает связь.
Делегированная аутентификация. Когда клиент сети Windows обращается к ресурсам,
службы операционной системы прежде всего производят его идентификацию. Во многих
случаях для выполнения этой операции службе достаточно информации на локальном
компьютере. Как NTLM, так и Kerberos, обеспечивают все данные, необходимые для иден-
тификации пользователя на месте, однако иногда их бывает недостаточно. Некоторые
распределенные приложения требуют, чтобы при подключении к серверным службам на
других компьютерах идентификация клиента производилась локально службой самого этого
клиента. Проблему помогает решить Kerberos, где предусмотрен специальный механизм
представительских билетов, который позволяет на месте идентифицировать клиента при его
подключении к другим системам. В протоколе NTLM такая возможность отсутствует.
Упрощенное управление доверительными отношениями. Одно из важных достоинств
взаимной аутентификации по протоколу Kerberos состоит в том, что доверительные от-
ношения между доменами Windows Server 2003 по умолчанию являются двусторонними и
транзитивными. Благодаря этому в сетях с множеством доменов не придется устанавливать
много явных доверительных отношений. Вместо этого все домены большой сети можно
свести в дерево транзитивных отношений взаимного доверия. Удостоверение, выданное
системой безопасности для любого домена, может приниматься во всех ветвях дерева. Если же
сеть содержит несколько деревьев, то удостоверение любого из них будет приниматься по
всему «лесу».
163
Совместимость. В основе своей реализации протокола Kerberos корпорация Microsoft

использовала стандартные спецификации, рекомендованные группой IETF. Благодаря такому
подходу удалось обеспечить аутентификацию клиентов Windows 2000/XP во всех сетях,
которые поддерживают 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
Клиент получает ответ сервера, расшифровывает его, а затем сравнивает полученный

результат со временем, которое было указано в исходном аутентификаторе. Если эти данные
совпадают, можно быть уверенным, что аутентификатор дошел именно до требуемого сервера,
и именно требуемый сервер на него ответил. Таким образом выполняется взаимная
аутентификация клиента и сервера.
Остается решить одну проблему: каким образом безопасно передать клиенту и серверу (и
только им) копии секретного ключа?
Для решения проблемы обмена ключами и был введен третий участник — посредник
между клиентом и сервером. В протоколе 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 ограничиваются выдачей
билета. Ей больше не нужно следить за тем, все ли отправленные сообщения до ставлены
соответствующим адресатам. Даже если какое-нибудь из них попадет не туда, — ничего
страшного не случится. Расшифровать клиентскую копию сеансового ключа может
165
только тот, кто знает секретный долговременный ключ данного клиента, а чтобы прочесть
содержимое сеансового билета, нужен долговременный секретный ключ сервера.
Получив ответ KDC, клиент извлекает из него сеансовый билет и свою копию сеансового
ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в
оперативной памяти).
Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение,
состоящее из билета, который по-прежнему зашифрован с помощью долговременного ключа
этого сервера, и собственного аутентификатора, зашифрованного с помощью сеансового
ключа. Этот билет в комбинации с аутентификатором как раз и составляет удостоверение, по
которому сервер определяет «личность» клиента.
Сервер, получив «удостоверение личности» клиента, с помощью своего секретного ключа
расшифровывает сеансовый билет и извлекает из него сеансовый ключ, который затем
использует для дешифрования аутентификатора клиента. Если все проходит нормально,
делается заключение, что удостоверение клиента выдано доверенным посредником, то есть
службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В
этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из
аутентификатора клиента и в таком виде пересылает ее клиенту в качестве собственного
аутентификатора.
Одно из достоинств сеансовых билетов состоит в том, что серверу не нужно хранить
сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений
(credentials cache) клиента, который направляет билет на сервер каждый раз, когда хочет
связаться с ним. Сервер, со своей стороны, получив от клиента билет, расшифровывает его и
извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто
стереть его из своей памяти.
Такой метод дает еще одно преимущество: у клиента исчезает необходимость обращаться
к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые билеты можно
использовать многократно. На случай же их хищения устанавливается срок годности билета,
который KDC указывает в самой структуре данных. Это время определяется политикой
Kerberos для конкретного домена. Обычно срок годности билетов не превышает 8 ч, т. е.
стандартной продолжительности одного сеанса работы в сети. Когда пользователь
отключается от нее, кэш-память удостоверений обнуляется, и все сеансовые билеты вместе с
сеансовыми ключами уничтожаются.
Итак, в процедуре аутентификации используются:
• индивидуальный (он же долговременный) ключ компьютера (сервера и рабочей стан-
ции), который создается при включении компьютера в домен и хранится в Active
Directory;
• сеансовый ключ, который генерируется KDC для конкретной пары абонентов
безопасности, и используется при аутентификации.
При этом возникает вопрос: «Каким же образом клиент взаимодействует с KDC?». Ведь
очевидно, что это взаимодействие также должно быть безопасным.
Когда пользователь проходит регистрацию, клиент Kerberos, установленный на его
рабочей станции, пропускает введенный пароль через функцию хэширования. В результате
формируется криптографический ключ, с помощью которого аутентификатор пользователя
шифруется и затем пересылается ближайшему KDC. Получив запрос от клиента, KDC
обращается в базу AD, находит в ней учетную запись нужного пользователя и извлекает из
соответствующего ей поля долговременный ключ. Такой процесс — вычисление одной копии
ключа по паролю и извлечение другой его копии из базы данных — выполняется всего лишь
один раз за сеанс, когда пользователь входит в сеть впервые. Сразу же после получения
пользовательского пароля и вычисления долговременного
166
ключа клиент Kerberos рабочей станции запрашивает сеансовый билет и сеансовый ключ,
которые используются во всех последующих транзакциях с KDC на протяжении текущего
сеанса работы в сети.
На запрос пользователя KDC отвечает специальным сеансовым билетом для самого себя,
так называемый билет на выдачу билетов (ticket-granting ticket), или билет TGT. Как и
обычный сеансовый билет, TGT содержит копию сеансового ключа для связи службы (в
данном случае — KDC) с клиентом. В сообщение с билетом TGT также включается копия
сеансового ключа, с помощью которой клиент может связаться с KDC.
Билет TGT шифруется с помощью долговременного ключа службы KDC, а клиентская
копия сеансового ключа — с помощью долговременного ключа пользователя.
Получив ответ службы KDC на свой первоначальный запрос, клиент расшифровывает
свою копию сеансового ключа, используя для этого копию долговременного ключа
пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из
пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится:
вся последующая связь с KDC будет шифроваться с помощью сеансового ключа. Как и все
другие сеансовые ключи, он имеет временный характер и действителен до истечения срока
действия билета TGT либо до выхода пользователя из системы. По этой причине такой ключ
называют сеансовым ключом регистрации (logon session key).
С точки зрения клиента билет TGT почти ничем не отличается от обычного. Перед
подключением к любой службе, клиент, прежде всего, обращается в кэш-память удос-
товерений и извлекает оттуда сеансовый билет для этой службы. Если его нет, он начинает
искать в этой же кэш-памяти билет TGT. Найдя его, клиент извлекает оттуда же со-
ответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор,
который вместе с TGT высылает в KDC. Одновременно туда направляется запрос на се-
ансовый билет для требуемой службы.
По аналогии с аутентификацией на сервере аутентификация при входе в домен использует
индивидуальный (долговременный) ключ пользователя, сеансовый ключ для связи
пользователя и 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 такой
ключ генерируется автоматически, когда между доменами устанавливаются доверительные
отношения. Служба выдачи билетов каждого домена регистрируется в центре KDC другого
домена в качестве главного абонента безопасности. В результате служба выдачи билетов
каждого домена начинает рассматривать службу выдачи билетов второго домена, как еще одну
свою службу. Благодаря этому клиент, прошедший аутентификацию и зарегистрировавшийся в
системе, может запрашивать и получать сеансовые билеты для нее.
167
Теперь рассмотрим, что происходит, когда пользователь с учетной записью в домене West
запрашивает доступ к серверу из домена East. Прежде всего, клиент Kerberos, установленный
на рабочей станции этого пользователя, посылает запрос в службу выдачи билетов своего
домена, в котором просит выдать сеансовый билет для доступа на нужный сервер. Служба
выдачи билетов домена West проверяет список своих абонентов безопасности и убеждается,
что такого сервера среди них нет. Поэтому она направляет клиенту так называемый билет
переадресации (referral ticket), который представляет собой TGT, зашифрованный с помощью
междоменного ключа, общего для служб KDC доменов West и Company. Получив билет
переадресации, клиент использует его для подготовки другого запроса на сеансовый ключ.
Однако на этот раз запрос пересылается в службу выдачи билетов домена Company, откуда в
ответном пакете приходит билет переадресации для домена East, зашифрованный с помощью
междоменного ключа, общего для служб KDC доменов Company и East. Наконец,
направляется запрос на сеансовый ключ в домен, где находится учетная запись нужного
сервера, то есть, в домен East. Его служба выдачи билетов пытается расшифровать билет
переадресации с помощью собственной копии междоменного ключа. Если попытка удается,
центр KDC направляет клиенту сеансовый билет на доступ к соответствующему серверу
своего домена.
Определенную сложность для протоколов аутентификации создают многоуровневые
клиент-серверные приложения. Здесь клиент может подключаться к серверу, который, в свою
очередь, должен будет подключиться к другому серверу более высокого уровня. Для этого
первому серверу понадобится билет на подключение ко второму. В идеале такой билет должен
ограничивать доступ первого сервера ко второму лишь теми функциями, на которые клиент
имеет права.
Для решения этой проблемы в протоколе Kerberos имеется специальный механизм — так
называемое делегирование аутентификации. По существу в такой ситуации клиент поручает
свою аутентификацию серверу. С этой целью он уведомляет службу KDC о том, что данный
сервер имеет право представлять клиента. Такой подход называется импер- сонацией (concept
of impersonation).
Делегирование аутентификации возможно двумя способами. Во-первых, клиент может
получить билет на подключение к серверу высшего уровня, а затем передать его ближайшему
серверу. Билеты, полученные таким способом — клиентом для ближайшего сервера —
называются представительскими (proxy tickets). Однако на этом пути имеется одна серьезная
трудность: чтобы получить представительский билет, клиенту нужно знать имя сервера
высшего уровня. Решить проблему помогает второй способ делегирования аутентификации.
Здесь клиент передает на ближайший к нему сервер свой билет TGT, который тот по мере
необходимости использует для запроса собственных билетов. Билеты TGT, полученные таким
образом, т. е. по удостоверению клиента, называются передаваемыми (forwarded tickets). Какой
из описанных способов применяется службой KDC, зависит от политики Kerberos.
Необходимо отметить, что предложенная в Kerberos схема зависит от сложности исполь-
зуемых паролей. Повысить надежность аутентификации позволяет применение смарт-карт и
криптографии с открытым ключом. На смарт-карте хранятся личный ключ пользователя и
цифровой сертификат с открытым ключом. Для доступа к личному ключу необходимо ввести
уникальный для данной карты PIN-код (Personal Identification Number).
Повышение безопасности при использовании смарт-карт обусловлено нескольким
факторами.
Во-первых, все операции с ключами выполняются непосредственно на смарт-карте, ключи
никогда не хранятся в файловой системе компьютера и скомпрометировать их гораздо
сложнее.
168
Во-вторых, аутентификация становится двухфакторной, т. е., чтобы зарегистрироваться в

системе, необходимо:
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.
169
Собственно дескриптор безопасности представляет собой структуру данных, состоящую

из двух списков управления доступом: Discretionary Access Control List (DACL) и System
Access Control List (SACL). Оба списка имеют одинаковую структуру и, в свою очередь,
состоят из набора элементов Access Control Entry (ACE). Однако ACE списка DACL содержит
назначение прав для конкретного SID, в то время как ACE списка SACL указывает, какие
действия конкретного SID должны протоколироваться системой аудита. Заметим, что DACL
объекта Active Directory может содержать строки ACE, назначенные отдельным атрибутам.
Тем самым в Active Directory администратор может назначать права доступа не только на
уровне объекта, но и на уровне конкретного атрибута объекта. Например, можно
разрешить/запретить редактирование номера рабочего телефона для пользователей такого-то
подразделения.
В Active Directory и в файловой системе NTFS реализован механизм наследования прав
доступа. Наследование позволяет существенно упростить назначение прав доступа в ука-
занных иерархических структурах. По умолчанию, объект, создаваемый на каком-либо уровне
иерархии, например, файл File.doc, унаследует права доступа с родительского уровня, что
избавляет администратора от необходимости явно указывать права на объект. С другой
стороны, администратор всегда может на любом уровне иерархии отключить наследование и
задавать права доступа явным образом. В общем случае ACL объекта состоит из
унаследованных с верхнего уровня списков управления доступом плюс прав, заданных
непосредственно для данного объекта (явные назначения). Такой механизм формирования
списков позволяет эффективно делегировать полномочия в каталоге AD.
ACE может содержать как разрешающее так и запрещающее право доступа, например,
запрет на операцию записи. Запрещающее право доступа имеет приоритет, причем неважно,
назначен запрет непосредственно пользователю или группе, членом которой он является.
Если при просмотре списка DACL выясняется, что пользователь не имеет доступа к объ-
екту (встретился запрещающий ACE, содержащий SID пользователя или одной из его групп),
то дальнейший просмотр списка прекращается.
Таким образом, для повышения эффективности Windows Server 2003 упорядочивает
элементы ACE следующим образом:
• явные запреты;
• явные разрешения;
• унаследованные запреты;
• унаследованные разрешения.
Сумма полномочий пользователя после просмотра списка — личных, групповых, явных,
унаследованных — образует его эффективные права.
1.3. Система аудита

Active Directory
Даже если мы уверены в том, что в нашей сети используется надежный и безопасный
протокол аутентификации, а списки управления доступом корректно настроены, мы, конечно
же, хотим знать, кто и когда пытался проникнуть в нашу систему, кто и когда пытался
получить доступ к папке с важной конфиденциальной информацией, удалось это
злоумышленнику или нет. Ответы на эти и другие вопросы нам поможет получить система
аудита.
170
При настройке аудита администратор должен указать, какие типы событий его интересуют
и на каких машинах. После чего система аудита начинает отслеживать указанные события и
фиксировать их в специальном журнале аудита — 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 Кбайт, и указать алгоритм поведения системы при
заполнении журнала. Для критически важных компьютеров рекомендуется не переписывать
журнал, чтобы не терять записи, которые могут оказаться весьма важными для анализа
потенциальных или возникших проблем. Более того, в объекте групповой или локальной
политики существует настройка, согласно которой компьютер принудительно выключается,
если журнал аудита переполняется и фиксировать события становится невозможно.
171
Поскольку Security Log является важной составляющей системы безопасности, со-

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

инфраструктуры открытых ключей
Система строгой двухфакторной аутентификации пользователей основана на применении
методов асимметричной криптографии и использует в качестве атрибутов аутентификации
цифровые сертификаты открытых ключей формата Х.509, размещенные на персональных
смарт-картах или USB-ключах пользователей. Централизованное применение сертификатов
открытых ключей требует наличия в составе информационной системы организации
инфраструктуры открытых ключей (Public Key Infrastructure, PKI), обеспечивающей выпуск и
дальнейшее сопровождение цифровых сертификатов.
К основным задачам инфраструктуры открытых ключей (PKI) относятся:
• централизованное формирование, управление и хранение сертификатов открытых
ключей;
• предоставление доступа прикладным информационным системам к сертификатам
открытых ключей и спискам аннулированных сертификатов (Certificate Revocation List,
CRL);
• поддержка многофакторной (двухфакторной) аутентификации пользователей в домене
службы каталога, при доступе к корпоративным веб-ресурсам, а также поддержка
шифрования и ЭЦП при обмене электронными сообщениями.
Дополнительно к PKI часто предъявляются следующие требования:
• интеграция с применяемой в организации службой каталога;
• обеспечение возможности гибкого масштабирования PKI с целью интеграции с новыми
корпоративными прикладными системами и распределения нагрузки;
• поддержка основных промышленных стандартов PKI, используемых в приложениях со
встроенными средствами работы с PKI:
— семейство стандартов X.509;
— стандарты серии PKCS;
— криптографические алгоритмы RSA, SHA-1, MD5;
— российские государственные стандарты в области криптографической защиты ин-
формации — ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94, ГОСТ 28147-89;
— протокол LDAP v2.
Удостоверяющий центр на Windows Server 2003 и 2008 может поддерживать следующие
конфигурации:
• отдельный удостоверяющий центр либо полная интеграция с Active Directory;
• корневой или подчиненный удостоверяющий центр.
Обычно таких возможностей оказывается достаточно для решения большинства задач в
организации.
172
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.
173
.'VullllriDtlrjlOlS L usioitkcrv
еС отпетое
Employees
Armt/v CtY tllttlJ
КГУОШСГ*
limplcivccv IHPOMf CiiHlumft

irctrtnfy CdUtonitien
Ch.injjm* 1>|ццрл1С1
Partner Portal
’jfllKTV ililu
Employees buppfy C hu nk
I f-li iny'
I kesnurces
Рис. 1.6. MIIS с набором «коннекторов»
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
Сценарии электронной почты

о Создание глобального списка рассылки (Global Address List):
• Объединение множества лесов Exchange, множества почтовых систем; о
Автоматизированное управление группами.
1.7. Системы обеспечения

Ключевая часть решений по управлению доступом и учетными записями — способ
создания, изменения и удаления идентификационных данных. Этот жизненный цикл
управления идентификацией обычно описывается как обеспечение. Оно использует инфор-
мацию пользователя, содержащуюся в инфраструктуре каталогов организации, чтобы
ускорить выдачу и аннулирование пользовательских учетных записей и прав доступа к ин-
формационным ресурсам: электронную почту, телефонную службу, приложения, трудовые
ресурсы, бизнес-линейку, функциональные приложения, допуск в интрасеть и внешнюю сеть,
а также сервисы службы поддержки.
Автоматизация данных процессов может снизить затраты и серьезно увеличить произ-
водительность. Например, подсчитано, что простое действие по автоматизации сбрасывания
паролей составляет 48 % обращений в службу поддержки для организаций с 10 000 поль-
зователей и более. Кроме того, автоматизация процессов может сократить время, требуемое
для получения пользовательских учетных записей и прав доступа, более чем с недели до
нескольких часов. Это также сильно снижает время, затрачиваемое управляющими делами на
заполнение сопутствующей документации, так же как и время, затрачиваемое персоналом
отдела финансов, отдела трудовых ресурсов и отдела ИТ на подтверждение и выполнение
запросов на доступ.
Удаление и повторное обеспечение — другие ключевые функции систем обеспечения.
Если работник покидает или меняет свою должность, система обеспечения может быстро
изменить или аннулировать учетные записи и пользовательские права доступа.
Как говорилось выше, корпорация Microsoft обеспечивает данный уровень функцио-
нальных возможностей как часть MIIS. В перспективе системы обеспечения MIIS позволяют:
• «встроенным» работникам — автоматическое создание учетных записей в связанных
системах, основанных на «триггерах» или событиях, таких, как приглашение на работу
и добавление к системе трудовых ресурсов или другой официальной системе;
• «невстроенным» работникам — автоматическое удаление или приостановка учетных
записей в связанных системах, когда работник удаляется из системы трудовых
ресурсов или другой официальной системы;
• атрибутам идентификации «Брокер» — автоматическое создание или синхронизация
данных идентификации между двумя или множеством систем.
Автоматизация деловых процедур — другая важная возможность системы обеспечения,
которая используется больше всего во время встраивания работника. При встраивании нового
работника компания может использовать MIIS для предоставления:
• простого обеспечения — работник впускается в различные связанные системы,
которые для него открыты;
• одношагового обеспечения автоматизации деловых процедур — за один шаг менеджер
или другое уполномоченное лицо уведомляется по электронной почте о том, что новый
работник приглашен на работу и готов к обеспечению. Менеджер или
175
уполномоченное лицо выдает свое решение (да/нет), и учетные записи работника

автоматически создаются или не создаются в зависимости от решения;
• многошагового обеспечения автоматизации деловых процедур — сходного с обеспе-
чением автоматизации деловых процедур, исключая количество более одного ра-
ботника в процессе обеспечения, который должен авторизовать новое приглашение на
работу. Многошаговая автоматизация деловых процедур возможна при использовании
BizTalk Server вместе с MIIS4;
• комплексное обеспечение — более редкий сценарий, в котором телефон, кредитная
карта, пейджер или другие элементы внесистемной учетной записи работника
обеспечиваются как часть процесса встраивания. Вместе со специализированными
продуктами третьих фирм (т. е. Business Layers) MIIS может выполнять необходимые
сложные задачи обеспечения.
MIIS предоставляет широкий набор возможностей обеспечения «из коробки» для
удовлетворения нужд компании. Компании, для которых требуются возможности, пре-
восходящие предоставляемые MIIS сегодня, могут выиграть от использования 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 делает не-
возможным скрытую модификацию, добавление или удаление части передаваемых данных.
177
В Oracle Advanced Security предусмотрена аутентификация службами третьих сторон:

• Kerberos;
• Entrust/PKI;
• Remote Authentication Dial-In User Service (RADIUS);
• службой LDAP-каталога.
OAS позволяет организации использовать существующую инфраструктуру безопасности,
например Kerberos, PKI, RADIUS для сильной аутентификации в СУБД Oracle 10g.
Аутентификация службами третьих сторон
Kerberos
Kerberos — система аутентификации доверенной третьей стороной, основанная на ис-
пользовании сервером аутентификации и субъектом так называемого общего секретного
ключа. Она гарантирует безопасность коммуникаций и надежность доверенной стороны.
Kerberos обеспечивает однократную регистрацию, централизованное хранение паролей,
прозрачную аутентификацию через связи БД, а также средства усиленной безопасности на
рабочих станциях.
PKI
Аутентификация на основе цифровых сертификатов опирается на инфраструктуру
открытых ключей (PKI) — современную технологию, использующую для идентификации
субъектов в распределенной среде криптографию с открытыми ключами. При этом не
требуется специального сервера аутентификации. Аутентификация пользователей
(приложений) выполняется на серверах БД в рамках предприятия. СУБД 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 служба каталога представлена следующими компонентами:
178
Способ Хранение ключей Преимущества Недостатки
Имя/пароль БД
• Распостраненность • Пароль либо легко подбира-
• Возможность выбора любой ется, либо сложно запоминается
платформы клиента/сервера • Пароль доступен для комп-
• Простота использования роментации
• Возможность задать правила фор-
мирования пароля (качество пароля)
Kerberos Файл • Шифрование ключевой инфор- • Требуется дополнительная
мации настройка сервера на протокол
• Возможность временнОго огра- Kerberos
ничения действия ключа • Небезопасное хранение ключей
• Поддержка однократной регист- • Управление ключевой инфор-
рации Single Sign-On мацией не средствами Oracle
• Поддержка смарт-карт технологий
RADIUS Файл/ • Сильная аутентификация • Возможность компрометации
Внешняя БД • Возможность сочетать двухфак- ключевой информации
торную аутентификацию с другими • Недостаточная надежность
методами UDP-протокола
• Возможность интеграции с любыми • Требуется установка RADlUS-
технологиями, поддерживающими сервера
данный протокол (To- kenCard, • Возможно, потребуется до-
SecurlD, биометрические устройства) полнительное кодирование для
• Возможность выбора любой клиента
платформы клиента/сервера • Не рекомендуется использовать
карты SecurID с версии 9i Oracle
SSL/PKI Файл/Реестр/ • Двухфакторная аутентификация • Возможность компромента-

Смарт-карта • Возможность централизованного ции ключей при хранении
управления пользователями и в файле/реестре
приложениями, а также ключевой • Подтверждено со стороны
информацией Oracle только использование
• Возможность выбора любой смарт-карт NCipher
платформы клиента/сервера • При использовании смарт- карт
• Поддержка однократной регист- других производителей требуется
рации Single Sign-On дополнительное ПО
179
ная информация, например, пароль. Пользователь может изменить собственный пароль в

любое время. Информация о пользователе и пароле хранится в словаре БД, причем пароль
криптографически защищен от несанкционированной модификации.
Программное обеспечение СУБД 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-каталоге на основе паролей, а также цифровых сертификатов X.509.
Аутентификация пользователей в Enterprise User Security выполняется по-разному для
приложений, работающих в архитектуре клиент—сервер (двухзвенной), и для приложений,
работающих в Web-архитектуре (трехзвенной).
В двухзвенной архитектуре пользователь непосредственно подключается к базе данных,
используя свои идентификационные данные (имя/пароль или цифровой сертификат). Сервер
базы данных передает данные пользователя в Oracle Internet Directory, который их проверяет и
в случае успешной проверки организует соединение пользователя с так называемой
разделяемой схемой, к которой ему разрешен доступ. Корпоративные пользователи не
являются пользователями базы данных и поэтому могут не иметь собственных схем в базе.
Пользователи соединяются с базой данных и работают с требуемыми объек
180
Глава 2. Обеспечение безопасности доступа на основе рекомендаций и продуктов Oracle и Aladdin
тами в разделяемой схеме в соответствии с привилегиями, предоставленными им сервером

Oracle Internet Directory. Для получения привилегий пользователям назначается одна или
несколько корпоративных ролей, созданных в LDAP-каталоге.
Существует прямое соответствие между корпоративными ролями и ролями в базе данных.
После успешной аутентификации сервер базы данных запрашивает у Oracle Internet Directory
набор всех корпоративных ролей пользователя, создает сессию и предоставляет этой сессии
роли (привилегии), закрепленные за корпоративными ролями в базе данных. В результате
пользователь, зарегистрированный в LDAP-каталоге, получает возможность работать с базой
данных с правами, описание которых хранится в OID. В этом случае в СУБД Oracle
отсутствует необходимость создавать учетные записи пользователей и управлять ими.
В многозвенной архитектуре аутентификация пользователей происходит на сервере
приложений. Между сервером приложений и сервером базы данных устанавливаются до-
верительные отношения, и все пользователи, зарегистрированные в OID, открывают сессии от
имени одного или нескольких так называемых прокси-пользователей БД. В этом случае
пользователи 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. В этом случае код приложений не меняется, все действия сводятся к
изменению конфигурации серверов приложений и баз данных.
181
Клиент
Ог'имы
Fipuyvp
они I.E
ЛГ> Directory и ". -1
\1Ч Wmilou',
Oniclc liitcmci Directory
Рис. 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 позволяет не только повысить безопасность данных и удобство управления
182
учетными записями пользователей, но и обеспечивает более гибкое управление системой

безопасности предприятия в условиях изменения организационной структуры или политики
безопасности, а также при появлении новых информационных систем.
2.1.1.2. Двухфакторная аутентификация в СУБД Oracle

на основе встроенных средств безопасности Oracle Advanced Security
На предприятии для доступа к прикладным программным системам, реализованным на
базе СУБД 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
доступ к определенной
БД с определенными правами
SSL
t
t Клиент Oracle Сервер БД Oracle Internet
Directory
Рис. 2.2. Архитектура предоставления доступа
183
«взломаны» методом простого перебора паролей. Определенные неудобства вызывает и

привязка ключевого контейнера к конкретной рабочей станции. Хранение идентифика-
ционных данных и ключей шифрования пользователей на персональных съемных носи-
телях eToken компании Aladdin решает обе проблемы. Во-первых, сертификаты хранятся
непосредственно в смарт-карте или USB-ключе eToken, секретный ключ находится в за-
щищенной памяти и никогда ее не покидает; во-вторых, сертификаты «мобильны» — ра-
ботать с приложениями Oracle можно с любой рабочей станции и от имени любого поль-
зователя корпоративной сети. Все, что требуется для настройки на стороне клиента, —
это указать, что ключевой контейнер помещен в хранилище сертификатов (Certificate
Store) Microsoft.
В момент запроса на соединение с БД служба eToken SecurLogOn позволяет сетевым
драйверам Oracle «видеть» сертификаты, установленные на eToken. Аутентификация
проходит в два этапа:
1) запрос на выбор сертификата (в зависимости от выбранного сертификата пользо-
ватель будет работать с определенной БД, схемой и правами). Если сертификат единст-
венный, он выбирается автоматически;
2) запрос PIN-кода смарт-карты или USB-ключа eToken для авторизации на опера-
ции с секретным ключом.
Когда клиенту требуется предъявить свой сертификат, служба смарт-карты «подска-
зывает» ему, какой сертификат следует брать из смарт-карты. Для подтверждения подлин-
ности сервера клиенту необходим секретный ключ для расшифрования ответа сервера.
Секретный ключ находится в защищенной памяти смарт-карты, и все операции с ним
выполняет встроенный в карту криптопроцессор. Для таких операций требуется допол-
нительная авторизация, т. е. запрашивается PIN-код. Когда между клиентом и сервером
установлены доверительные отношения, сервер проверяет наличие отличительного имени
пользователя, для которого издан сертификат клиента, в LDAP-каталоге — Oracle Internet
Directory. Если он найден, дополнительно определяются экземпляр БД, схема и набор прав
для клиента. После этого сервером создает-
ся сессия пользователя с указанными пара-
метрами. Сетевой обмен между клиентом и
сервером происходит по соединению, защи-
щенному определенным криптоалгоритмом.
Такой подход позволяет на практике
реализовать двухуровневую модель орга-
низации защищенного доступа пользова-
теля к данным (СУБД) с помощью цифро-
вых сертификатов Х.509, установленных
в eToken. Легальные пользователи корпора-
тивной сети (под управлением контролле-
ра домена Windows 2000/2003) могут авто-
ризоваться в сети (рис. 2.3) только после
успешной аутентификации по смарт-карте,
включающей предъявление соответствую-
щего сертификата (первый уровень). На
втором уровне защиты доступ авторизо-
ванных пользователей корпоративной сети
к защищенным данным СУБД возможен
Рис. 2.3. Двухуровневая модель доступа
только при предъявлении соответствующе-
к защищенным данным с помощью го сертификата Oracle.
цифровых сертификатов Х.509
184
Глава 2. Обеспечение безопасности доступа на основе
ЧАСТЬ рекомендаций и продуктов Oracle и Aladdin
II. ПРАКТИКА
Результатом
• сертифицированное
настройки средство
сервера БД,защиты
клиентских
информациирабочих(СКЗИ),
станцийкоторое
и установки
устанавливает
серти-
фикатовзащищенное
пользователей соединение между является
на смарт-карты клиентом и сервером
надежная по протоколу
аутентификация, SSL/TLS,
шифрованный
трафик использует сертификаты/ключи
между рабочими станциями и для аутентификации
сервером, на серверном
и самое главное — строгаякомпоненте;
персонализация
• eToken
доступа RTE —повышения
в БД. Помимо драйверы смарт-карт
надежности,иаутентификация
USB-ключей eToken и дополнительное
с использованием ПО
eToken дает
компании Aladdin
ряд преимуществ для работы
по сравнению с ними.
с традиционным (логин/пароль) методом. Прежде всего,
Личное хранилище
электронный ключ даетсертификатов
возможностьипользователю
секретных ключей пользователя
различных на рис.не2.4
приложений обозначено
хранить «где
буквой A,ив не
попало» качестве физического
запоминать носителяимена
необходимые используется
и пароли. USB-ключ или смарт-карта
Зная один PIN-код и eToken.
выбрав
Хранилище из
сертификат сертификатов и секретных
предложенного списка, ключей, используемое
можно, имея ПО СКЗИправа
соответствующие на стороне сервера,
и привилегии,
обозначено буквой
обращаться Б. Как БД,
к конкретной правило, оно
причем представляет
с любой рабочей собой файл формата PKCS#12.
станции.
Аутентификациябезопасности
Администратор выполняется за несколько
получает пришагов:
этом дополнительные удобства в виде цент-
1. Прикладное
рализованного ПО посылает
управления запрос
доступом серверу БД
и контроля на соединение.
работы системных администраторов. Все эти
2. Oracle Client делает попытку соединиться
возможности управления обеспечивает единый инструмент — с сервером БДслужба
по обычному
каталоговпротоколу.
Oracle Internet
3. СКЗИ
Directory. перехватывает
Существующие запрос отв Oracle
получают «лице»Client и перенаправляет
службы каталогов единую его точку
в защищенный канал.
входа — своего
Если портал
рода защищенный канал клиент—сервер.
архитектуры еще не установлен, При ПО
этомСКЗИ выполняетслучаев
в большинстве аутентификацию
изменений нав
серверном компоненте
прикладном с помощью ключа, который хранится на USB-ключе или смарт-карте
ПО не требуется.
eToken. В случае успешной аутентификации создается защищенный канал передачи данных.
4. В процессе
2.1.1.З. Варианты аутентификации eToken RTE осуществляет
усиления безопасности доступа в СУБД дополнительную
Oracle с авторизацию
(запрос PIN-кода) для выполнения операций с секретным
помощью сертифицированных криптографических средств защиты ключом.
5. Oracle Client авторизует пользователя по имени и паролю.
Для решения взаимодействие
Дальнейшее задачи, описанной в предыдущем
между клиентом разделе,
и серверомпредлагаются два варианта
осуществляется уси-
по защи-
ления
щенному безопасности на основе
каналу прозрачно длясертифицированных криптографических средств защиты.
прикладного приложения.
В качестве ПО для выпуска сертификатов могут использоваться программные продукты,
Базовая
которые аутентификация/авторизация
автоматизируют и защита канала
функции удостоверяющих связи (УЦ). Эти программные
центров
Архитектура
продукты должны типового решения и аутентификация
быть сертифицированы ФСТЭК, представлены
ФСБ РФ (например,на рис. 2.4. В данном
программный
варианте
комплекс используются
«Удостоверяющий следующие компоненты: УЦ»).
Центр «КриптоПро
• прикладное ПО, которое реализует интерфейс пользователя для решения бизнес-задач
Базовая аутентификация/авторизация
прикладной системы; по протоколу Kerberos
и защита канала связи
• ПО Oracle Client, которое обеспечивает взаимодействие между клиентом и сервером по
Второй
сети; вариант усиления безопасности на основе сертифицированных криптографи-
ческих средств защиты отличается от первого только тем, что аутентификация выполняется по
протоколу Kerberos. Это дает возможность отказаться от ввода имени пользователя и пароля в
процессе авторизации в БД.
Архитектура типового решения и процесс аутентификации представлены на рис. 2.5. В
данном варианте используются следующие компоненты:
• прикладное ПО, которое реализует интерфейс пользователя для решения бизнес-задач
прикладной системы;
• ПО Oracle Client, которое обеспечивает взаимодействие между клиентом и сервером по
сети. В данной схеме используется функциональность опции Advanced Security
Options; это расширение СУБД Oracle устанавливается на стороне сервера баз данных;
• сертифицированное СКЗИ, которое устанавливает защищенное соединение между
клиентом и сервером по протоколу SSL/TLS, использует сертификаты/ключи для
аутентификации на серверном компоненте;
• eToken RTE — драйверы смарт-карт и USB-ключей eToken и дополнительное ПО
компании Aladdin для работы с ними.
Личное хранилище сертификатов и секретных ключей пользователя на рис. 2.5 обозначено
буквой A, в качестве физического носителя используется USB-ключ или смарт-кар-
Рис. 2.4. Базовая аутентификация/авторизация и защита канала связи. Общая схема решения
186 185
1ИЭЧЛ R СТ2И11ИМ к.111С1ГГ2

I Л.
KJHU.1 свят»
кшинигмным OK Н1
iTI.S/SSI I
m
llpDKWLU Nf;irp»
t
eToken КТГ
СсопмЬи
I fIP|□ iпгч]ith■ ipciiu■ ■ |нос I ' Г' С№П1<МШ1№Ки114« '
. -\-----------СКЗИ-----------J ----------------:------------. CK3IIIRTH)
ПО Oracle t’licm I | ПО Oracle C licm (ce|»re|>)
Пр|1К.и4Н1.11! ПО
Kerberos
Сервер БД
Cf pik'p jjiTeKni'I'HkJLiHH "|
KLTIVM ri l)(.
Рис. 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, полученному ранее. Даль-
нейшее взаимодействие между клиентом и сервером ведется по защищенному каналу
прозрачно для приложения.
187

которые автоматизируют функции удостоверяющих центров (УЦ). Эти программные
продукты должны быть сертифицированы ФСТЭК, ФСБ России (например, программный
комплекс «Удостоверяющий Центр «КриптоПро УЦ»).
2.1.2. Обеспечение безопасности доступа к данным и

приложениям информационной системы организации на
основе Oracle Application Server
2.1.2.1. Усиленная аутентификация пользователей в неоднородной
среде приложений на основе Oracle Application Server — Oracle iAS 10g
Компании необходимо обеспечить надежную аутентификацию пользователей в сложной
среде распределенной обработки данных в условиях работы большого количества приложений
управления предприятием. Для аутентификации пользователей при доступе к ресурсам Oracle
E-Business Suite должны использоваться цифровые сертификаты формата X.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 с ис-
точниками осуществляется с помощью профилей (коннекторов, плагинов), опре-
деляющих правила и направления миграции данных.
188
Рис. 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);
• сертификаты формата X.509;
• защита секретного ключа пользователя PIN-кодом.
Таким образом, Oracle iAS 10g обеспечивает максимальную защищенность аутенти-
фикационных данных.
Двухфакторная аутентификация в Oracle iAS 10g
В решениях на базе Oracle iAS 10g может быть реализован механизм двухфакторной
аутентификации на базе сертификатов X.509. При этом в качестве первого фактора аутен-
тификации выступают сертификаты, а в качестве второго фактора — аппаратные носители
сертификатов и секретных ключей пользователей. Аппаратные носители — смарт-карты —
способны осуществлять генерацию секретного ключа пользователя и выполнять с его по-
мощью криптографические операции. Секретный ключ в данном случае не покидает фи -
зические границы аппаратного носителя. В качестве аппаратных носителей ключевой
информации могут использоваться аппаратные носители, которые способны взаимодей-
ствовать с криптопровайдером операционной системы Windows. Таким решением, например,
является USB-ключ или смарт-карта eToken PRO компании Aladdin. Взаимодействие eToken с
криптопровайдером Windows осуществляется с помощью ПО eToken RTE (Run-Time
Environment).
Способы аутентификации
Сервер Single Sign-On в составе Oracle iAS 10g может использовать в качестве пользо-
вательского интерфейса протокол HTTP(S). Таким образом, возможны следующие способы
аутентификации:
189
• аутентификация по имени и паролю пользователя;

• SSL-аутентификация по протоколу HTTPS с предъявлением сертификатов X.509.
Любой из приведенных методов может быть усилен применением аппаратных носителей.
Пример аутентификации по имени и паролю пользователя приведен на рис. 2.7.
Э эр( гистр иррБ&ТЬСЯ

Baevге имя иавдвиплн м ушгминьй ггкчлъ ринтрщн*
Ии.Ч ЛППг-:01 jri'T-1 |
Лхцагь
Рис. 2.7. Форма аутентификации Oracle Identity Management с вводом имени пользователя и пароля
Пример SSL-аутентификации по протоколу HTTPS с использованием USB-ключей и

предъявлением сторонами своих сертификатов иллюстрируют рис. 2.8 и 2.9. При под-
Рис. 2.8. Окно выбора сертификата
190
ключении к компьютеру 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 Integration
and Provisioning;
• 2 сервера для размещения компонентов Single Sign-On и Delegated Administration
Services;
• 2 устройства балансировки нагрузки.
Рекомендуемая топология приведена на рис. 2.10.
На данной иллюстрации:
• LBR#1, LBR#2 — Load Balancer — устройства балансировки нагрузки;
• IM1, IM2 — серверы с размещенными компонентами OSSO и DAS;
• OID1, OID2 — серверы с размещенными компонентами OID и DIP.
191
Поддерживаемые аутентификационные устройства

Так как платформа 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 с помощью цифровых сертификатов X.509. Такую же связь можно установить между
сервером приложений и сервером базы данных. Благодаря этому на серверах может быть
введен явный запрет на соединения по открытому протоколу (не SSL). При этом для
приложений, требующих соединения с каким-либо сервером по открытому протоколу
(например, для администрирования сервера), в сетевых настройках данного сервера явно
указываются IP-адреса, для которых действует исключение из общего запрета.
eToken SecurLogon для Oracle Application Server можно интегрировать с Token Manage-
ment System (TMS) — системой управления жизненным циклом USB-ключей и смарт-карт.
eToken SecurLogon встраивается
Рис. 2.10. Рекомендуемая в различные
топология инфраструктуры
развертывания открытых
решения Oracle ключей
Identity — не только
Management
Oracle iAS 10g, но и Microsoft Windows 2000/XP/2003, RSA Keon и т. п., что обеспечивает
возможность централизованного выпуска сертификатов и управления правами пользователей
в рамках всей информационной инфраструктуры предприятия, а не только подсистем на
основе продуктов Oracle.
Нижний слой представлен двумя серверами баз данных с размещенными агентами Real
Application Clusters и данными, вынесенными на сетевое хранилище (Shared Disk Storage).
Преимущества
Решение
ВозможностиeTokenавторизации
SecurLogon для Oracle Application Server обеспечивает значительно более
высокую безопасность за счет:
Решения на основе Oracle iAS 10g не реализуют авторизационные требования при доступе
• отказа от передачи имен пользователей и паролей по сети в открытом виде;
к не-Огаск-приложениям. Доступ пользователей к тем или иным данным после пройденной
• применения двухфакторной программно-аппаратной аутентификации вместо од-
аутентификации (авторизации) осуществляется собственно средствами не-Огаск-приложений.
нофакторной;
Oracle Internet Directory позволяет группировать пользователей в зависимости от их прав
• использования
доступа, однако в данномзащищенного шифрованием
случае авторизация носитканала передачи
бинарный данных;
характер, т. е. пользователи из
• взаимной аутентификации сервера и клиента;
выделенных групп могут проходить авторизацию средствами Single Sign-On, а другим в
• эффективного
доступе будет отказано.применения встроенных средств и механизмов защиты Oracle
Application Server.
Поддерживаемые платформы
Способы аутентификации, применяемые в eToken SecurLogon для Oracle Application Server
Решения на основе Oracle iAS 10g
на основе технологии авторизации ориентированы
Oracle на совместимость
Single Sign-On, удобнее для спользователей,
решениями Oracle,
чем
такими как Oracle
стандартные E-Business
способы, Suite, Oracle
поскольку Portalзапоминания
требуют и др. Информационные системы
единственного и платформы
PIN-кода, а не
от сторонних
множества производителей
имен пользователя ви явном
сложныхвидепаролей,
не поддерживаются.
необходимых Такие решения
для доступа позволяют
к различным
также обеспечить SSO по отношению к трехзвенным приложениям других поставщиков.
приложениям.
192 193
• защита канала
Принципы работыпередачи данныхeToken
и архитектура криптографическими
SecurLogon для методами;
Oracle Application Server
•Процесс
усиленная аутентификация пользователей при доступе
аутентификации иллюстрирует рис. 2.11, на котором к приложениям информа- этапы
цифрами обозначены
ционной системы;
аутентификации:
1• иинтеграция
2 — взаимнаясо штатными механизмами
аутентификация аутентификации/авторизации
клиента и сервера приложений с помощьюOracle Application
цифровых
Server. Х.509. Сертификат пользователя с секретным ключом установлен в памяти
Решение
eToken, предусматривает
а сертификат сервераиспользование программных продуктов,
приложений (HTTP-сервера) с секретнымреализующих
ключом — рос-в
сийские криптоалгоритмы.
контейнере Поставщики
wallet (файле формата PKCS#12).криптографических средств защиты должны иметь
лицензии
3 — после ФСБ успешной
России, аутентификации
а само ПО —компонент сертификаты
SingleпоSign-On
соответствующему классу
сервера приложений
проверяет Применяемые
в LDAP-каталоге методы
(Oracle встраивания
Internet Directory, решения
OID) наличиев инфраструктуру
учетной записи Oracle
поль-
Application
зователя, дляServer не должны
которого издан этотнарушать лицензионных
сертификат. соглашений
Причем проверка можетнавыполняться
использование ПО
по всем
поставщика
полям (Oracle,или
сертификата поставщиков
просто по ОС для сервера или
отличительному клиентских
имени владельца рабочих станций).
сертификата.
4 — если учетная запись пользователя найдена, то устанавливается защищенное со-
Описание
единение по решения
протоколу SSL и пользователь получает доступ к приложению с правами,
Основными
соответствующими компонентами
его учетнойрешения,
записи. представленного на рис. 2.12, являются:
•Сервер
приложения (applications),
приложений должен быть которые реализуют
настроен интерфейс пользователя
на аутентификацию с помощьюи протокола
бизнес-логику
SSL.
Сервер информационной
приложений выступает системы;
по отношению к серверу базы данных как обычный клиент и
имеет• одно
клиентили(Web-браузер), который обеспечивает
несколько постоянных соединений с взаимодействие между клиентом и
сервером базы данных.
сервером приложений;
• сертифицированное СКЗИ (подключаемый модуль сервера Apache (mod_ssl), адап-
тированный для работы с российской криптографией), который устанавливает за-
щищенное соединение между клиентом и сервером по протоколу SSL/TLS, использует
сертификаты/ключи для аутентификации на серверном компоненте;
• eToken RTE (драйверы смарт-карт и USB-ключей eToken компании Aladdin и до-
полнительное ПО для работы с ними).
В качестве физических носителей ключей и сертификатов пользователей применяются
USB-ключи или смарт-карты eToken. Физическое хранилище сертификатов и секретных
ключей, используемое модулем СКЗИ в составе прокси-сервера, определяется производителем
СКЗИ.
которые автоматизируют функции удостоверяющих центров (УЦ). Эти программные
продукты должны быть сертифицированы ФСТЭК, ФСБ РФ (например, программный
комплекс «Удостоверяющий Центр «КриптоПро УЦ»).
Принцип функционирования
1. Пользователь информационной системы пытается получить доступ к защищенному
ресурсу (приложению). Клиент посылает запрос на аутентификацию прокси-серверу.
2. Производится стандартная аутентификация по SSL-протоколу. При этом eToken RTE
осуществляет дополнительную авторизацию (запрос PIN-кода) для выполнения операций с
секретным ключом. Логику работы с сертификатами, изданными с использованием
российских криптоалгоритмов,
Рис. 2.11. Процесс аутентификации реализует модульSecurLogon
с помощью eToken СКЗИ (mod_ssl),
для Oracle имплементированный
Application Server в
сервер Apache.
3. При успешной аутентификации создается защищенный: канал передачи данных между
клиентом и прокси-сервером, а все запросы в дальнейшем перенаправляются на Oracle HTTP
Server (OHS). Необходимые
2.1.2.2. Встраивание для сертифицированных
авторизации заголовки запросов устанавливаются прокси-
криптографических
серверомсредств
на основании информации, полученной
в информационные системыиз сертификата,
на платформе предъявленного
Oracle клиентом в
процессеApplication
Server
4. Затем обращение к приложению перехватывается компонентом Single Sign-On (SSO)
Постановка
Oracle Applicationзадачи
Server, который обеспечивает штатный процесс авторизации пользователя и
использует
Основной вызов подключаемого
задачей является модуля авторизации
построение (Customинформационной
защищенной SSO plug-in). системы, ис-
пользующей технологии и инфраструктуру Oracle Application Server. Данная задача делится на
три подзадачи:
194 195
2.1.2.3. Смарт-карты и USB-ключи eToken для аутентификации и

Канал связи,
авторизации в приложениях Oracle Business Intelligence EE
защищенный СКЗИ
(TLS/SSL)
Основной задачей является построение защищенной информационной системы, ис-
пользующей технологии и инфраструктуру Oracle Application Server. Данная задача делится на
четыре подзадачи:
• защита канала передачи данных криптографическими методами;
• усиленная аутентификация пользователей при доступе к приложениям информа-
ционной системы;
• безопасное хранение ключей и сертификатов;
• интеграция со штатными механизмами аутентификации/авторизации Oracle Application
Server.
Применяемые методы встраивания решения в инфраструктуру и/или приложения Oracle
Application Server не должны нарушать лицензионных соглашений на использование ПО
поставщика (Oracle, поставщиков ОС для сервера или клиентских рабочих станций).
TLS/SSL (LAN/WAN)
— настраиваемые компоненты
— компоненты поставщиков
СКЗИ
Рис. 2.12. Аутентификация и защита канала передачи данных с помощью eToken SecurLogon
для Oracle Application Server и средств криптографической защиты
Решение позволяет создавать информационные системы на платформе Oracle Application

Server, которые не только обладают повышенной безопасностью, но и соответствуют
требованиям лицензирующих организаций. Описанная выше схема опирается только на
документированные возможности
Рис. 2.13. Аутентификация используемого
и авторизация ПО и Oracle
в приложениях соответственно не нарушает
Business Intelligence EE ли-
цензионных соглашений напосредством
его применение.
смарт-карт и USB-ключей eToken
196 197
Основными компонентами решения, представленного на рис. 2.13, являются:
• приложения (applications), которые реализуют интерфейс пользователя и бизнес-логику
приложений Oracle BI EE и Oracle BI 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
огглссе
широким функционалом (от управления финансами и производством до отношений с пос-

^ Л\
тавщиками и клиентами), данный комплекс консолидирует в среде бизнес-приложений
обширную конфиденциальную информацию о деятельности компании.
Основными целями проекта по обеспечению защищенного доступа к ресурсам про-
граммного комплекса являются:
• предоставление безопасного доступа с удаленных рабочих станций к корпоративным
информационным ресурсам 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 позволяет выполнять распределенные вычисления и
легко масштабируется на уровнях приложений и базы данных, что означает возможность
установки нескольких экземпляров служб на уровне приложений, расположенных на разных
компьютерах, объединенных в сеть.
Клиент Приложения БД
Рис. 2.14. Трехуровневая модель Oracle E-Business Suite
199
Уровень клиента
Уровень клиента представлен Интернет-браузером, а также Java-машиной, функци-
онирующей как добавочный компонент (add-on) браузера; он обеспечивает визуальный
интерфейс пользователя (рис. 2.15).
Java-Enabled
Browser Concurrent Processing
with Jlnitiator Server
Reports Server
Admin Server
Клиент Приложения
Рис. 2.15. Взаимодействие клиента и приложений
Компоненты уровня клиента и уровня приложений могут взаимодействовать как в рамках

локальной (LAN), так и глобальной сети (WAN).
Пользователь в браузере вводит адрес (URL), являющийся адресом веб-сервера эк-
земпляра Oracle E-Business Suite. Работа с Oracle E-Business Suite начинается с аутенти-
фикации и авторизации пользователя, т. е. с ввода имени и пароля (рис. 2.16).
При успешной аутентификации/авторизации браузер переадресуется на стартовую
страницу, соответствующую введенному имени пользователя. Затем данное имя (учетная
запись) используется для различных целей, в том числе аудита и ограничения доступа.
Рис. 2.16. Форма авторизации доступа к Oracle E-Business Suite с вводом имени пользователя и пароля
200
Й C'jHomef ftelattfmfce
F'settf Mitten OirK U >:g.-ti£tern Т?
MflfT-t
Г5К'яг- 1 I At* T'iftiSLllMI Hl&lOfV
Т2ТСТНГТ!!Т"НТТ
Wnriidnw 1 he* ViUnn
__________________________
Lo<n*-l In A: JALEE
Favorites
. Ed> f aw4t: )
oi Mfificetj VAyt
liH
3fi Si'tb Orders
J УслМ.С'деп Triosactugr.!
J ЬШЕШ Ним
а sabnm n»?-»4i
C'+Jlllifl.t'. I Huinr I LsSfi'Jl I I rlv'j

Гц-п-tft .\П1Г*’Ч| Лi r&t lilM ЛЧ1
AhMSMTt'ir
Рис. 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).
201
c
Web-сервер
Web-сервер обрабатывает запросы от браузера клиента и формирует HTML-страницы для
отсылки результата. Web-сервер содержит следующие компоненты (рис. 2.18):
• прослушиватель (Web-listener);
• сервер сервлетов (Java servlet engine);
• серверные страницы Java (Java Server Pages).
Browser running
Jlnitiator, a Java
plug-in
Forms client
running in the
same browser ©
Web Listener Клиент Приложения БД

Рис. 2.19. Взаимодействие сервера форм с базой данных и браузером клиента
3
Forms Server Forms Listener Servlet. Она дает возможность взаимодействовать процессам
архитектура
времени
User исполнения сервера форм с клиентом через Web-сервер и использовать HTTP- или
Interface
Logic
HTTPS-протоколы. Помимо возможности работы по глобальной сети такая архитектура
позволяет восстанавливать прерванные соединения, использовать меньшее количество портов
и обеспечивает более высокий уровень безопасности при передаче данных в Интернете.
Однако в рамках такой архитектуры возрастает сетевой трафик (в среднем на 40%). Это
Рис. 2.18. Уровень приложений
приводит к увеличению времени отклика для клиента LAN на 8—10 %, а для клиента WAN —
до 30%.
По возможности Web-сервер обслуживает запросы самостоятельно, при необходимости
Уровень базы
передавая данных
запросы в сервер сервлетов, например, для извлечения информации из базы данных.
Непосредственно
Уровень базы данныхWeb-сервером выполняются
также представлен наборомHTML-приложения, которые
сервисов и обеспечивает имеют
хранение и
следующие особенности:
манипулирование данными Oracle E-Business Suite.
• не используют Oracle Forms;
• безопасности
Схема OracleHTML
разработаны на чистом E-Business Suite
и Java Script;
•Стандартная
динамически формируют
система HTML-страницы,
безопасности исполняяSuite
Oracle E-Business Java-код;
базируется на четырех ком-
• для формирования страниц используют репозиторий БД.
понентах — аутентификации, авторизации, аудите и безопасности сети. Аутентификация
осуществляется по имени пользователя и паролю. Возможности имеющейся специальной
Сервер форм
системы настройки политики управления паролями и их качеством, как правило, персоналом
Сервер форм Oracle
не используются, и все Forms Server присущие
недостатки, обслуживает формы Oracle по
аутентификации E-Business
паролям,Suite и обеспе-
сохраняются.
чивает
Короткиеграфический
и простые интерфейс
пароли легкопользователя. Сервер
подбираются; форм ивзаимодействует
длинные сложные тяжелос запомнить,
БД, извлекая
и
поэтому их
нужную часто записывают,
информацию, что иявляется
формирует грубым
отображает нарушением
окна на уровнеполитики
клиента,безопасности;
инициирует
слишком редкая
изменения в БДсмена
(рис. пароля
2.19). пользователями
Дополнительно существенно
сервер формснижает
кэшируетвсенеобходимые
усилия специалистов
данные
по информационной
(например, безопасности.
большие списки) на уровне клиента.
Системаформ
Сервер авторизации обеспечивает управление
может взаимодействовать правами
с браузером и привилегиями,
клиента по протоколам назначенными
HTTP, HTTPS
определенной
и учетной
Socket (TCP/IP), записью,БДа —
а с сервером система аудита позволяет
по протоколу протоколировать и обрабатывать
Oracle Net*8.
информацию о транзакциях, выполненных от имени определенного пользователя по учетной
Forms
записи. Listener Servlet Suite поддерживает работу всех своих компонентов по протоколу
Oracle E-Business
HTTPS, что обеспечивает
Для работы сервера форм защитув каналов передачи
локальной сети, данных.
как правило, используется режим Socket.
Помимо
Такой режимсвоевременного
является наиболее обновления, повышенияоднако,
производительным, качества
непаролей и регулярного
позволяет аудитак
получить доступ
для защиты приложений при доступе к ним через Интернет рекомендуется использовать
Oracle E-Business Suite через глобальную сеть, для этого используется специальная
протокол HTTPS. После выполнения ряда процедур (как автоматизированных,
202 203
так и выполняемых вручную) все компоненты 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-Business Suite на
основе цифровых сертификатов X.509 при доступе к серверу и шифрование согласно
протоколу SSL. Благодаря этому на сервере может быть введен явный запрет на соединения по
открытому протоколу (не SSL). При этом для приложений, требующих соединения с сервером
Oracle E-Business Suite по открытому протоколу (например, для администрирования), в
сетевых настройках сервера явно указываются IP-адреса, для которых действует исключение
из общего запрета.
В продукте предусмотрена возможность интеграции с Oracle Application Server Single
Sign-On. Такая интеграция обеспечивает однократную регистрацию пользователя при доступе
к различным ресурсам и централизованное управление правами пользователей приложений.
Продукт позволяет использовать один и тот же eToken для доступа в помещения (по
встроенной в карту радиометке) и в различные системы приложения (не только входящие в
пакет приложений Oracle для электронного бизнеса).
204
Продукт можно интегрировать с Token Management System (TMS) — системой управления

жизненным циклом eToken в масштабах предприятия. С помощью TMS можно организовать
централизованную подготовку eToken к работе, удаленное обслуживание (в том числе
разблокирование PIN-кода), отзыв полномочий и т. д.
Продукт встраивается в различные инфраструктуры открытых ключей — не только Oracle
Identity Management, но и Microsoft Windows 2000/XP/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) предоставляет следующие преимущества:
• возможность постепенного перевода пользователей с прежней системы аутенти-
фикации на новую систему;
205
Одним из преимуществ предложенного решения является организация удаленного

доступа к бизнес-приложениям Oracle E-Business Suite с помощью защищенного SSL-про-
токола, обеспечивающего надежную защиту передаваемой информации. Соединение
осуществляется в два этапа. Сначала в ходе двусторонней аутентификации сервера и
пользователя происходит установление SSL-сессии и подтверждение подлинности обеих
сторон. На втором этапе обеспечивается защита обмена данными с помощью шифрования
канала, в результате чего достигается конфиденциальность и целостность передаваемой
информации.
Предлагаемое типовое проектное решение позволяет существенно повысить уровень
защищенности информации без внесения каких-либо изменений в систему. В результате
компания получает возможность предоставлять пользователям безопасный доступ с уда-
ленных рабочих станций к корпоративным информационным ресурсам на базе Oracle E-
Business Suite. Доверенное информационное пространство можно расширить в случае роста
потребностей компании, обеспечив при этом необходимый уровень информационной
безопасности. Это решение необходимо, прежде всего, компаниям, располагающим развитой
сетью удаленных филиалов или мобильных рабочих мест.
2.1.4. Управление доступом и учетными данными пользователей на

основе программных продуктов Oracle Identity и Access Management
Suite
Технологии Oracle для управления учетными данными пользователей,

их правами и доступом
Приступая к реализации технологии управления учетными данными (реквизитами),
правами и доступом пользователей, корпорация Oracle рассматривала три ключевых критерия,
которые определяют современный подход к созданию корпоративных служб управления
каталогами и учетными данными: полноту решения, интегрируемость, открытость и
поддержку неоднородных сред.
ПолнотаРис. решения.
2.20. Схема использования
Современныеклонированных
требования ксервисов уровняпо
решениям приложений
управлению учетными
данными диктуют необходимость охвата полного спектра функциональных возможностей
управления идентификацией — от первоначальной подготовки к работе до долгосрочного
управления,
• безопасное
от высокой
хранениебезопасности
ключевой информации;
доступа к развернутым в масштабах организации
приложениям и информационным
• возможность ресурсам
безопасной работы до авторизации
в глобальной сети; и аутентификации доступа с
тонкой
• возможность
детализацией проверки
параметров
подлинности
доступа,
клиентов,
определяемой
снижение политикой
рисков атак, информационной
например, путем
безопасности организации.
подбора пароля.
На начальной стадииЗаказчики
Интегрируемость. выполнения предпочитают
проекта необходимо
работатьразвернуть
с крупными следующие
производителями
програм-
программного
мные продукты: обеспечения, которые
Oracle Internet в состоянии
Directory тесно интегрировать
(OID), представляющиий технологии
собой реализациюуправления
LDAP-
учетными
каталога, и данными
корпоративный и бизнес-приложения.
удостоверяющий центр Именно
(УЦ) здесь
на базедостигается
Microsoft CA,наибольший
который,
экономический
помимо генерации эффект. Недостаточно
цифровых просто предоставить
сертификатов, обеспечиваетинструменты
организацию для юридически
управления
учетными
значимого данными
документооборота
и управления
с применением
доступом. Заказчикам
ЭЦП в качестве
требуется,
аналога
чтобы собственноручной
эти инструменты
были полностью интегрированы в деловую активность организации. Технологии Oracle
подписи.
позволяют
Двухфакторная
выполнять аутентификация
это критическиприважное
доступетребование
к СУБД позволяет
и обеспечивают
на порядок
интеграцию
повыситьс
такими
уровеньбизнес-приложениями, как Oracle проводить
информационной безопасности, E-Business постоянный
Suite, mySAPаудит
Business
всех Suite, PeopleSoft,
действий в сис-
JD
теме,
Edwards,
а такжеSiebel.
полностью исключить перехват идентификационной информации пользователя
потенциальным
Открытостьзлоумышленником. Защита данныхсред.
и поддержка неоднородных Ключевое
на рабочих требование
станциях сегодняшнего
пользователей может
дня
бытьсостоит
реализована
в том,с помощью
что заказчикам
продукта
необходимы
Secret Disk
решения,
компании способные
Aladdin. Он
качественно
обеспечиваетработать
защитув
неоднородной
конфиденциальнойИТ-инфраструктуре.
информации, В хранящейся
ходе проектов и по централизации
обрабатываемой ведения
на учет
персональных
компьютерах под управлением ОС Microsoft Windows.
206 207
Функциональность Название компонента
Управление Web-доступом Oracle Access Manager

Аудит и обеспечение соответствия законодательству Oracle Identity Manager & Oracle Access Manager
Oracle Identity Federation
Однократная регистрация в федеративных (партнерских)
сетях
Согласование идентификационных данных и их доставка Oracle Identity Manager
во внешние хранилища
Коннекторы (доставка ID-данных) Oracle Identity Manager Connectors
Реализация LDAP-каталога Oracle Inernet Directory
Виртуальный LDAP-каталог Oracle Virtual Directory

Однократная регистрация на серверах приложений Oracle Oracle SSO & Oracle Access Manager
Сервис делегирования прав администрирования Delegated Administration Service

Платформа интеграции LDAP-каталогов Directory Integration Platform
208
Oracle Internet Directory — это реализация протокола LDAP версии 3, объединяющая

стандартные подходы к организации служб каталогов и опирающаяся на надежность и
масштабность СУБД Oracle. Служба каталогов Oracle представляет собой приложение на
основе СУБД Oracle, тесно интегрированное с сетевыми службами и управляющими
средствами Oracle. Используя OID и применяя методы централизованной авторизации, можно
хранить в едином хранилище данные о сервисах, предоставляемых продуктах, а также о
пользователях и их правах в едином хранилище. OID опирается на СУБД Oracle и активно
использует его возможности по обработке больших объемов данных и поддержке
одновременной работы с базой данных большого числа пользователей. Емкость одного
сервера каталогов оценивается в полмиллиарда записей.
СУБД Oracle — основа службы каталогов — спроектирована так, что системные опе-
рации, такие, как резервное копирование, добавление файлов данных, установка допол-
нительных приложений, могут проходить без остановки СУБД и не требуют отключения
пользователей. Восстановление после системных сбоев происходит автоматически. Для
обеспечения защиты от отказа аппаратных средств в архитектуру серверов LDAP заложена
возможность развертывания распределенной системы, состоящей из нескольких отдельных
серверов, обменивающихся информацией о происходящих изменениях и добавлениях. Во
время простоя одного сервера LDAP другие берут на себя задачи обслуживания поль-
зователей. После восстановления сервера, претерпевшего сбой, происходит полная синхро-
низация данных. Серверы OID пользуются проверенными на практике механизмами
репликации данных Oracle Advanced Replication.
OID обеспечивает три уровня авторизации пользователей: анонимный доступ, доступ по
паролю и авторизацию, основанную на сертификатах безопасности, распространяемых в
рамках инфраструктуры SSL v3. Разграничение прав доступа осуществляется админи-
стратором. Он может гибко контролировать доступность элементов хранения каталога,
предоставляя права и управляя доступом пользователей как к записям и их атрибутам, так и к
целым ветвям дерева каталогов.
Управление Web-доступом
Технология разработана в целях обеспечения централизованного управления доступом
корпоративных пользователей к информационным ресурсам организации с высокой степенью
детализации прав и привилегий доступа, применяется для разнородных прикладных сред, а
также интеграции с такими компонентами ИТ-инфраструктуры, как корпоративный
информационный портал, программное обеспечение для организации коллективной работы с
корпоративной информацией и бизнес-приложениями, например ERP, CRM, SCM.
Oracle Access Manager предоставляет комплексный набор сервисов по централизованному
управлению доступом пользователей к различным информационным ресурсам предприятия, в
том числе Web-ресурсам и приложениям. В программном продукте полностью реализована
концепция защищенного доступа к ресурсам предприятия (аутентификация, авторизация и
аудит). Развитые средства авторизации и аудита действий пользователей и администраторов
системы позволяют существенно повысить уровень безопасности работы с информационными
ресурсами.
Oracle Access Manager может работать с широким набором LDAP-каталогов, серверов
приложений, Web-серверов, серверов порталов и бизнес-приложений, поставляемых ве-
дущими производителями ПО.
Централизованное управление учетными записями пользователей, политиками доступа и
аудита существенно снижает риски несанкционированного доступа к ресурсам, особенно для
организаций с большим количеством сотрудников и различных информационных ресурсов.
209
Управлять учетными записями пользователей позволяют:

• развитые средства проектирования полей учетных записей пользователя, определения
групп пользователей и организационной структуры предприятия, а также удобный
интерфейс для создания учетных записей, групп, оргструктуры;
• широкий набор различных типов групп пользователей: статический, динамический,
вложенный, гибридный, на основе подписки. Особенно интересны динамические
группы, позволяющие определять группу на основе, например, условий назначения
атрибутов учетных записей. Использование групп существенно упрощает адми-
нистрирование политик доступа;
• средства автоматизации определения и исполнения потоков работ, состоящих как из
шагов взаимодействия с различного рода администраторами/менеджерами, так и шагов
по получению/передаче данных. Используются для реализации бизнес-процессов
утверждения при регистрации пользователей, регистрации их в группах, для передачи
идентификационных данных во внешние системы и др.;
• средства самообслуживания, которые дают возможность конечным пользователям
самостоятельно создавать свои учетные записи, а также изменять в них данные
(например, свои пароли) в рамках предоставленных им полномочий. В случае
необходимости с изменением поля учетной записи может быть связан поток работ,
который, может, например, запросить разрешение на конкретную операцию у
руководителя данного сотрудника. Средства самообслуживания существенно снижают
расходы организации на администрирование пользователей и их прав доступа;
• делегированное администрирование пользователей и политик доступа, которое обес-
печивает создание многоуровневых иерархий администраторов, каждого со своими
полномочиями, а также распределение нагрузки, и легко адаптируется к бизнес-
структуре организации.
Особенностями управления доступом пользователей являются:
• поддержка аутентификации пользователей на основе имен и паролей, цифровых
сертификатов, смарт-карт (в том числе — eToken), биометрии и др.;
• возможность взаимодействия с внешними системами с целью расширенной аутен-
тификации и/или авторизации на основе имен и паролей, цифровых сертификатов,
смарт-карт, биометрии и др.;
• поддержка авторизации пользователей и групп на основе политик авторизации
(развитый аппарат для определения сложных политик доступа);
• наличие средств тестирования политик доступа и графического интерфейса для
определения защищаемых информационных ресурсов и политик доступа;
• авторизация доступа к группе приложений на основе однократной аутентификации
(Single Sign-On, SSO, федеративный SSO).
Oracle Access Manager позволяет осуществлять аудит действий, выполняемых средствами
управления учетными данными и доступом пользователей, на основе политик аудита, при
этом возможна запись данных аудита в базу данных, что повышает надежность и
защищенность этих данных. Продукт поставляется с набором предопределенных отчетов,
например, по неуспешным авторизациям (по пользователям или ресурсам), по созданию,
активации, деактивации пользователей, по изменению данных в учетных записях.
Распространение и согласование учетных данных
Данная технология служит для автоматизации сложного и рутинного процесса реги-
страции и управления большим количеством учетных записей пользователей в неодно
210
родной ИТ-инфраструктуре, когда имеется большое число различных LDAP-каталогов,

разнородных приложений и общекорпоративных сервисов (таких, например, как электронная
почта). Доставка учетных данных осуществляется с помощью программного продукта Oracle
Identity Manager, характерными особенностями которого являются:
• полный технологический цикл авторизации доступа, гарантирующий, что доступ к
нужным ресурсам осуществляется быстро, непротиворечиво и в полном соответствии
с корпоративными политиками доступа;
• прямое подключение (за счет использования коннекторов) к приложениям управления
кадрами (Human Resourses Management Systems — HRMS) и их данным, что позволяет
предоставлять сотрудникам организации санкционированный руководством доступ ко
всем корпоративным приложениям и информационным ресурсам, которые им
необходимы для выполнения должностных обязанностей;
• широкий спектр средств подключения (коннекторов) к операционным системам, базам
данных, LDAP-каталогам, средствам обеспечения коллективной работы, приложениям
и устройствам, что избавляет от рутинных работ по разработке дополнительных
коннекторов.
Виртуальные каталоги
Программный продукт Oracle Virtual Directory позволяет отказаться от принципа фи-
зического хранения учетных данных в едином LDAP-каталоге. В качестве альтернативы Oracle
Virtual Directory предоставляет возможность создавать представления, которые объединяют
атрибуты идентификации данного объекта, взятые из других физически отделенных друг от
друга хранилищ учетных данных, включая и LDAP-каталоги. Таким образом, создается
виртуальный каталог, синдицирующий в режиме реального времени данные из различных
хранилищ учетных данных и предоставляющий эти «взгляды» (views) общекорпоративным
сервисам и приложениям. Особенно удобно использование виртуальных LDAP-каталогов при
построении корпоративных порталов.
Однократная регистрация в федеративных (партнерских) сетях

По мере того как все больше организаций переносят свои бизнес-процессы в ИТ-инф-
раструктуру, появляется насущная потребность в расширении границ бизнес-процессов до
дочерних структур и бизнес-приложений партнеров. Системы, которые помимо собственной
ИТ-инфраструктуры, затрагивают также и ИТ-инфраструктуры партнерских организаций,
носят название федеративных. Интеграция на федеративных началах (федерирование учетных
данных) позволяет организациям работать независимо, но объединяться для достижения
деловых целей.
Очевидно, что в федеративных системах для обеспечения доступа внешних пользователей
к корпоративным приложениям и информационным ресурсам необходим жесткий учет
регистрационных записей пользователей с целью защиты от несанкционированного доступа к
корпоративным ресурсам. Работу с учетными данными в федеративных системах
обеспечивает программный продукт Oracle Identity Federation, использующий для доступа к
другим системам управления учетными данными пользователей многопротокольный шлюз,
поддерживающий все стандарты федерирования, включая SAML, Liberty, WS-Federation.
В итоге успешно аутентифицированные в партнерской сети пользователи могут под-
ключаться к ресурсам другой сети без повторной аутентификации.
211
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) и сервисов синхронизации учетных данных между OID и другими хранилищами
Directory Integration Platform (DIP). Для работы с приложениями, работающими в архитектуре
«клиент—сервер», пользователи регистрируются в базах данных Oracle как пользователи
СУБД с соответствующими правами.
Цели и задачи решения
Важнейшими задачами проектирования системы управления доступом, учетными дан-
ными и однократной регистрации пользователей крупного предприятия являются:
• создание иерархии хранения учетных данных пользователей — работников пред-
приятия;
• организация единого хранилища учетных записей;
• управление учетными данными и обеспечение их целостности и непротиворечивости;
• сокращение трудозатрат ИТ-специалистов и пользователей АСУ при управлении
учетными данными;
• построение системы однократной регистрации, обеспечивающей подключение со-
трудников со своих рабочих мест к информационным ресурсам предприятия без
дополнительного предъявления учетных данных;
• синхронизация учетных данных в целевых системах в рамках всей информационной
инфраструктуры предприятия.
212
В целях развития АСУ предприятия предусматривается совершенствование систем,

автоматизирующих отдельные бизнес-процессы, более полная интеграция всех автомати-
зированных систем в единую АСУ предприятия, а также создание на предприятии единой
системы управления доступом и учетными данными в рамках ИТ-инфраструктуры, которая
объединяет:
• 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-каталоге
шаблоны, обеспечивающие автоматический вход зарегистрированных пользовате
213
лей в приложения. Клиентская часть ESSO позволяет автоматически выгружать эти шаблоны
на рабочие станции, опознавать окна и формы приложений для ввода атрибутов
аутентификации и подставлять в эти формы данные пользователей.
Для организации сквозного управляемого процесса от заведения учетной записи
пользователя в MS AD до его прозрачного подключения к разрешенным корпоративным
приложениям требуется интеграция системы однократной регистрации ESSO с системой
распространения учетных данных пользователей (Oracle Identity Manager). Без такой ин-
теграции администраторы прикладных систем сами должны создавать учетные записи
пользователей в приложениях и каким-то образом сообщать им их учетные имена и пароли.
Для интеграции выполняется установка адаптера OIM для ESSO, который позволяет
безопасно помещать в контейнер пользователя на LDAP-каталоге его учетные данные для
подключения к целевым системам.
Итак, на первом этапе с помощью программных продуктов Oracle Identity Manager и
Oracle ESSO строится единая система управления учетными данными, к которой подключа-
ются Microsoft AD, Lotus Notes и одна информационная система, построенная на БД Oracle.
На втором этапе происходит увеличение количества пользователей системы, и су-
ществующая архитектура системы управления учетными данными расширяется за счет
программных комплексов OID, OEBS, OFA.
Функциональная архитектура решения и потоки данных между информационными
системами представлены на рис. 2.21.
Для распространения однократно введенных учетных данных сотрудников в инфра-
структуру предприятия вводятся Oracle Identity Manager и коннекторы к различным ин-
P.MK. I.r
станция
I ogori М-ll lager
ESSO сервер
Manage (MJW .UHIIUX
metu
Conwie
Password Reset
Microsoft
/^-Oracle hktrW) A Access i tnteipnsc
Applicatio
n Dl
■-.i I
1.0(1 is
on [' nit
IlHtllt'H ■ I- .. I- ■ ■ Приложен
FSSO ия
provisionin Ofndc Identity Мдпадсг Oracle
.Oraclfl g
QjlvAV.p Oracle
rssol Г - Budne*
bCillfelCiLIiJp Suite
Oracle
Financial
Рис. 2.21. Функциональная архитектура решения

214
формационным системам предприятия. Развертывание Oracle Enterprise SSO позволяет

осуществлять прозрачное подключение пользователей при доступе к различным инфор-
мационным системам предприятия на основе учетных данных приложений, которые
клиентская часть ESSO извлекает из контейнера пользователя в MS AD.
Управление учетными записями и правами на информационные системы
OIM обладает функциональностью управления жизненным циклом учетных данных
пользователей информационной системы. Для создания, изменения учетной записи, а также
назначения, исключения прав на информационную систему предприятия либо администратор,
либо сам пользователь инициирует запрос на выполнение потока работ в Web-интерфейсе
OIM. Запрос проходит процесс согласования с уполномоченными лицами и после успешного
утверждения 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 теми же данными из OIM, которые получают конечные информационные
системы. Пользователь может не знать свой пароль и учетное имя в информационной системе,
но при этом иметь доступ к информационной системе через ESSO Logon Manager.
Применение ESSO позволяет предоставлять доступ к информационным системам
предприятия на основе единственной аутентификации на Microsoft Windows. Опционально ее
можно заменить на более сильную аутентификацию с использованием, например, ключей или
смарт-карт eToken компании Aladdin. Смена пароля или учетного имени в приложениях
происходит без участия и ведома пользователя. Парольная политика ведется в OIM, пароли
распространяются в информационные системы через соответствующие коннекторы.
В OIM предусмотрена возможность создания исторических отчетов о предоставленных
пользователям правах доступа к прикладным системам.
Интеграция Oracle Identity Manager и Oracle ESSO в информационную систему пред-
приятия позволяет создать единую систему управления учетными данными пользователей и
их правами в корпоративной информационной системе, развернуть систему однократной
регистрации, обеспечивать ведение общей политики паролей в информационной системе, а
также аудит учетных данных и прав на ресурсы предприятия.
215
2.1.4.2. Организация единого доступа пользователей компании-

оператора мобильной связи к сервисам, предоставляемым через
web, на основе продуктов Oracle Virtual Directory и Oracle Access
Manager
Компания — оператор мобильной связи предлагает своим клиентам различные Wap-сер-
висы и услуги, предоставляемые через Web, например, сервис самообслуживания (контроль
счетов, смена тарифов), сервис загрузки контента, поисковый сервис и т. д. Для обслуживания
пользователей (абонентов) в компании используется несколько Web-приложений, при этом
часть их них принадлежит партнерам компании. Большинство приложений имеет
собственную инфраструктуру:
• различные технологии формирования интерфейса пользователя (php, .NET);
• разные серверы приложений (MS IIS, Apache, SunJavaWS, JBoss);
• разные серверы баз данных (Oracle, MS SQL, MySQL, SunJavaDS).
Каждое приложение имеет собственных внутренних пользователей, для каждого из
которых создается учетная запись. Если пользователь работает с несколькими приложениями,
то для него создается несколько учетных записей. Учетные записи абонентов хранятся в базах
данных приложений, т. е. каждое приложение располагает собственным, уникальным
репозиторием пользователей (рис. 2.22). Все приложения оснащены инструментами
управления учетными записями и правами доступа пользователей. Работа каждого
приложения контролируется администраторами.
В связи с диверсификацией бизнеса, территориальным расширением и развитием деловых
отношений с партнерскими организациями, предоставляющими услуги клиентам оператора
мобильной связи, компании необходимо обеспечить качество, гибкость и
nuiuoHirii
tIS
П]'Н.|пЖ'.И1Ьг
Приложение
СУБД Ofuclf СУБД MySQL

ID nwiHwemril ID тимовяте.кп ID паль ют геле
I [> nftThJOWTfilf It
.Ll* il l I г1£ЕИф A
xiy jymrihiili A iLiM иутснтиф. и
Лм]0|П1ипнн . I Till & IIH I rlllil'Jh A
It
VliropH kILIIIII
AHopKWnH
А шины
It
Длинны H
Л ш и пи
Мчнмн
Рис. 2.22. Первоначальная организация доступа пользователей к сервисам, предоставляемым через Web
216
надежность сервисов и предложить своим абонентам и партнерам ряд дополнительных услуг

для повышения безопасности и удобства работы с 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
217
можно настроить таким образом, чтобы поддерживался необходимый уровень его до-
ступности и безопасности.
Внутри виртуального каталога в дереве данных о каталоге (Directory Information Tree —
DIT) для каждого приложения создается своя ветвь пользователей, в результате возникает
единое пространство для поиска пользователей. Именно на основе виртуального каталога
Sim jjrr f Si MI 1
JavjWS
Javans Javans
1
VKIClIC I'M....... MySQl MySQI
Mobile
JBo»t Ппчг1
Search е Oi mv
iSEi
Wcb'LluriO IT ■ao^ki.'lpvK.i j|H HI(K1UI^|KI |i гi.11;11L'|h■ ■

Рис. 2.24. Приведение всех ID-данных к одному формату и определение атрибутов для аутентификации
Sim
WebC.ate JavnWS
MySQL
Server
Mobile (IriLle
Search itEI
MySQL+
Oniric -*-
SQt.
t. Main
Рис. 2.25. Внешняя аутентификация пользователей приложениями по контексту http-заголовков
218
Ресурсы, защищенные Процесс аутентификации и авторизации

Oracle Access Manager пользователей в Oracle Access Manager,
Oracle Virtual Directory
m
V
HTTP (S) SSO
LDAP каталог
cookie1 * для хранения политик
3 доступа к приложениям
Apach
веб сервер Oracle Oracle
Access Virtual
Server Directory
Коннекторы
Oracle Virtual Directory
IIS & ASP К каждому источнику
Apps учетных записей
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-
приложение защищается шлюзом (модулем, входящим в составе OAM). Все обращения
пользователей к приложениям контролируются этими шлюзами, где с помощью сервера
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).
219
Решение технических проблем

Аут е н ти ф и ка ц и я в о бход с т а н д а рт н ых м еха н и зм ов
Решение 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. Для обеспечения масштабности и отказоустойчивости системы на региональном
220
уровне установлены серверы промежуточного слоя, которые являются точками контакта для
клиентов, где необходимо осуществлять аутентификацию и авторизацию клиентов.
Аутентификация и авторизация выполняются на основе цифровых сертификатов, вы-
даваемых головным Удостоверяющим Центром. Авторизованные клиенты получают доступ к
информационным ресурсам и в зависимости от предоставленных им прав могут читать или
изменять хранящуюся в базе данных информацию. Подключение клиентов проходит в
защищенном режиме с помощью шифрования.
Централизованная система управления доступом является одной из ключевых служб,
штатная работа которой позволяет решить широкий спектр задач обеспечения информа-
ционной безопасности организации. Необходимость предоставлять авторизованным поль-
зователям право изменять данные организации федерального уровня и в то же время
обеспечивать защиту от несанкционированного доступа — наиболее очевидные из них.
Учитывая ценность конфиденциальных данных организации, решение должно предус-
матривать механизмы, позволяющие быстро реагировать на изменяющиеся требования со
стороны пользователей и владельцев информации.
Права пользователей на доступ к ресурсам наиболее удобно определять в LDAP-каталогах,
предоставляющих универсальный способ хранения и обработки регистрационных данных
пользователей информационных систем, учетных данных субъектов информационно-
вычислительных процессов, компонентов инфраструктуры и т. д. Наличие LDAP-каталогов
позволяет целиком вынести за рамки приложений все, что касается обработки учетных
данных, и предоставлять эту обработку приложениям по стандартизованному LDAP-
протоколу как общедоступный сервис. Следующие задачи — аутентификация пользователей,
анализ их запросов на доступ к ресурсам и собственно предоставление доступа к ресурсам —
требуют обращений к LDAP-каталогам и формируют дополнительные требования к общему
решению по управлению доступом.
Необходимо также иметь в виду, что в ряде подсистем идентификационные данные
пользователей могут храниться не в LDAP-каталогах, а непосредственно в базах данных, с
которыми работают корпоративные приложения, или в доменах Microsoft Windows NT. Все
эти хранилища учетных данных нужно интегрировать. Однако простое хранение
идентификационных данных пользователей в LDAP-каталогах и их использование в ло-
кальных приложениях не являются комплексным решением, необходима единая служба
управления LDAP-каталогами и идентификационными данными пользователей.
Должны быть предусмотрены механизмы интеграции со средствами сильной аутенти-
фикации, территориальная распределенность и достаточное количество точек аутентифика-
ции, наличие интерфейсов администрирования (в том числе — делегированного) и само-
обслуживания, проверка политик (например, диапазонов IP-адресов), поддержка федера-
тивного доступа с установлением доверительных отношений между хранилищами учетных
данных нескольких организаций, аудит действий пользователей организации и т. п.
Основными целями создания единой службы управления доступом АСУ организации
федерального уровня являются:
• консолидация средств контроля доступа, аутентификации и аудита для реализации
полномасштабной политики информационной безопасности в рамках всех подсистем
организации, организация единой точки входа для тех подсистем, где это необходимо;
• автоматизация процессов регистрации учетных записей клиентов АСУ организации,
назначения им прав пользования ресурсами АСУ организации, выдачи и ан-
нулирования сертификатов;
221
•максимально возможная централизация решения с учетом специфики территориальной

распределенности организации и необходимости обеспечивать точки доступа для
представителей других государственных структур по всей Российской Федерации;
• повторное использование компонентов решения для обеспечения федеративного
доступа.
Важнейшими задачами являются создание надежной, гибкой и открытой для контроля
соответствующими органами инфраструктуры управления доступом, обеспечивающей
бесперебойное функционирование АСУ организации федерального уровня и ее развитие в
перспективе.
Концепция защищенного доступа к информации (авторизации, аутентификации и аудита)
может быть в полной мере реализована только в системе, где обеспечены единство и
унификация средств управления отдельными компонентами информационной инф-
раструктуры. При проектировании подобных систем необходимо применять модульный
принцип, позволяющий интегрировать и повторно использовать при необходимости от-
дельные компоненты. Решение задачи создания единой службы управления доступом — это,
прежде всего, построение правильной архитектуры, позволяющей логически выделить и
сгруппировать специализированные модули. Типовая архитектура развертывания единой
службы управления доступом, обычно бывает представлена пятью уровнями:
• службы каталогов;
• репозитория (хранилища) политик;
• принятия решений (слоем приложений);
• применения политик;
• интеграции (слоем программных интерфейсов).
Для объединения существующих подсистем в рамках АСУ организации федерального
уровня используется интегрированный набор средств управления учетными данными Oracle
Identity & Access Management Suite, компоненты которого функционально соответствуют всем
пяти уровням. Создание единой службы управления доступом АСУ организации федерального
уровня осуществляется на базе программных продуктов Oracle Access Manager и Oracle
Identity Federation. В случае необходимости синхронизации учетных данных эти продукты
могут быть дополнены Oracle Identity Manager.
На рис. 2.27 представлена схема возможной интеграции служб управления доступом и
учетными данными при наличии нескольких хранилищ учетных данных.
Рис. 2.27. Схема интеграции служб управления доступом и учетными данными
222
L'L’fmnMrKJiM
13м; in MK i'
К-ИЕС1МЫ Hi’ Ссрлср уиршыснин I .DA I3 111- :| н IIVLILI! jbli'il III LJf
i Iu4
Рис. 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).
223
to
to
(OID)
LDAP-
каталог с
поддерж
кой
функций ЧА
метаката СТ
Ь
лога II.
ПР
АК
ТИ
КА
Службы каталогов Хранилище политик Слой принятия решения Слой применения политик Интеграция / интерфейс Рис. 2.29.
Модульная схема развертывания единой службы управления доступом

Первый этап проекта — создание службы управления доступом в одном регионе

На этом этапе на передний план выступают вопросы оптимизации; в частности —
обеспечения отказоустойчивости системы и минимизации расходов. Схема развертывания
предполагает установку точек доступа AccessGates во всех региональных центрах, а серверов
Access Server — в самых крупных из них. Точки доступа AccessGates настраиваются на
последовательный опрос списка из ближайших серверов Access Server и при отсутствии у
какого-нибудь сервера Access Server соединения с другими компонентами Oracle Identity &
Access Management Suite или со службой каталогов переключаются на следующий.
Также на этом этапе оценивается, стоит ли использовать стандартную службу каталогов
(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 — программный продукт, предназначенный для виртуализации опе-
рационных систем. Виртуализация — технология или набор технологий, позволяющих
сделать вычислительные ресурсы автономными и независимыми от окружающих ком-
понентов. Особенностью данного продукта является использование гипервизора Xen, под-
226
Глава 3. Обеспечение безопасности доступа на основе продуктов компании Citrix Systems
!. 11.Г1Л * Г.ГЛ L 1111 v y \ctScakt

I dgcSic'hl I 'U
Access- G-3iev.,iy1 Доставка V»cb-
MtlMII rnplll IE ЬСИЖНЫЛ! llpIL lOACHHIl
11 po 11JNOл 11T СЛ M I СНГ r 11 1ЮСТУ11 Ъ Мри 1ЛШГНИНЦ
Citrix XcriScrvx*#™
ДОС lJHk.il JMfOU'HTH
Mill |»y JAM IIJ pHL-jVi
Приложения
WANSCJIM'4 Xot Desktop'u
Ускорен IbC ДОСТаВКИ Доставка Г 1К Citrix XcnApp' 1
НрПЛОЖСН till «'lIllJllUN

HocroDHi ttnidow*-
№ ipiLllltLIU приложен ИII
Рис. 3.1. Инфраструктура доставки приложений компании Citrix Systems
держивающего паравиртуализацию. Гипервизор — микроОС, которая предоставляет сервис

виртуальных машин операционным системам, установленным поверх нее, обеспечивая
изоляцию гостевых ОС друг от друга, защиту, безопасность и эмуляцию определенных
компонентов в случае необходимости, а также разделение и управление ресурсов хост-
машины. Паравиртуализация — метод виртуализации, при котором операционная система
виртуальной машины «знает» о том, что она работает в виртуальной среде. Это достигается за
счет модификации виртуализированной операционной системы.
В поставку данного ПО в зависимости от редакции может входить Citrix Provisioning
Server for Data Center.
Citrix Provisioning Server — программное обеспечение, позволяющее осуществлять
потоковую доставку операционных систем (серверных или клиентских) по сети, в том числе
на компьютеры, не имеющие жестких дисков. Здесь необходимо отметить, что в данном
случае вся вычислительная работа выполняется на том устройстве, куда происходила
потоковая доставка.
Citrix NetScaler — аппаратный комплекс, обеспечивающий доставку Web-приложений
конечному пользователю. В этот комплекс заложены механизмы, обеспечивающие: муль-
типлексирование запросов, сжатие информации и ее кеширование, перенаправление запросов,
балансировку нагрузки, анализ трафика как в направлении Web-сервера, так и в обратном,
защита трафика и логики приложений с помощью межсетевого экрана приложений.
Citrix XenApp — программное обеспечение, отвечающее за доставку пользователям
приложений Windows. Пользователь получает на используемое устройство, на котором
запущен клиент Citrix Application, изменения экрана, а на сервер, в свою очередь, передаются
коды нажатых на клавиатуре клавиш и изменения позиций курсора. Приложение в данном
случае выполняется на стороне сервера и использует его вычислительные ресурсы. Таким
образом, мы получаем независимость от операционной системы и аппаратного обеспечения на
стороне клиента, так как основная функция клиента — только отображение информации.
Citrix XenDesktop — система доставки персональных компьютеров из Дата-центра на
устройство пользователя. Под доставкой персонального компьютера понимается доставка
графического интерфейса клиентской операционной системы. При этом персональный
компьютер, находящийся в Дата-центре, может представлять собой виртуальную машину или
аппаратный комплекс, например блейд-ПК. Блейд-ПК — разновидность персонального
компьютера, представляющего собой модуль, содержащий в себе процессор, память,
227
материнскую плату и устанавливаемый в специализированное шасси. Жесткий диск и

видеоподсистема могут быть опциональными. Все операции ввода-вывода осуществляются
через шасси, которое также содержит в себе модули управления. Доступ пользователей к
таким ПК осуществляется только по сети.
Необходимо отметить, что в этом продукте используются технологии, заложенные в Citrix
XenApp, и в зависимости от редакции могут быть доступны дополнительные компоненты.
Редакция ПО — это разновидность ПО от одного производителя, имеющая одинаковый
базовый функционал и отличающаяся друг от друга дополнительным функционалом или
дополнительными продуктами, поставляющимися в рамках той или иной редакции.
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 XenApp.
3.2. Компоненты систем,

построенных с использованием XenApp
Прежде чем начать обсуждение процесса аутентификации и авторизации в системах,
построенных с использованием XenApp, необходимо остановиться на компонентах, из
которых эти системы строятся.
Существует несколько версий и редакций программного обеспечения Citrix Systems, с
помощью которого строятся системы удаленного доступа.
1. Citrix Access Essentials 2.0 — версия для малого бизнеса, с ограничением в макси-
мальное количество пользователей — 75.
2. Citrix Presentation Server 4.0 for UNIX — версия для заказчиков, использующих IBM
AIX, HP-UNIX или Solaris. Эту версию в данной книге мы не рассматриваем.
228
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 активно использует возможности служб каталога, совместно с которыми
iceiti-c
Server
Ciirix XenApp
Socnire
Клиент FiicWall
FiftWjli Wch I nlcil-Xc
Ciirt\ XcjiAfip
STA
XML Service
kodino I.IL'P
.ЗПМСИ.1
Рис. 3.2. Примерная схема подключения пользователя к Citrix XenApp
229
это ПО работает. Служба каталогов — иерархическая служба, содержащая в себе информацию

об объектах организации и их свойствах. Так, Citrix XenApp поддерживает работу при
использовании в организации как службы каталога Active Directory компании Microsoft, так и
Novell Directory Services (NDS).
Аутентификация в среде Citrix XenApp осуществляется с помощью следующих меха-
низмов:
• пароли;
• смарт-карты;
• токены;
• биометрические решения.
Некоторые из этих решений могут потребовать дополнительные программно-аппаратные
комплексы, которые приобретаются у других поставщиков.
Вышеперечисленные механизмы для своей работы используют один из следующих
протоколов аутентификации:
• Windows NT LAN 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 XenApp расширяет использование протокола Kerberos. После того, как пользователь
входит в систему на клиентском устройстве, он может подключиться к Citrix XenApp без
необходимости проходить снова аутентификацию. Пароль пользователя не передается на Citrix
XenApp, вместо этого происходит обмен токенами аутентификации согласно Generic Security
Services API (GSSAPI) стандартизованного в Internet RFC 1509.
230
Этот аутентификационный обмен происходит внутри виртуальных каналов протокола Citrix

ICA и не требует никаких дополнительных протоколов или портов. Также нужно отметить, что
этот аутентификационный обмен не зависит от метода входа в систему, и поэтому может быть
использован совместно с паролями, смарт-картами или биометрическими методами. Для
использования аутентификации Kerberos в Citrix XenApp клиент и сервер должны быть
правильно сконфигурированы. При необходимости Групповые Политики Службы Каталога
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 XenApp в среде Microsoft Active Directory
Ниже мы приведем некоторые рекомендации по использованию Citrix XenApp в среде
Microsoft Active Directory.
Компания Citrix рекомендует следующие конфигурации фермы серверов, использующей
Active Directory:
• все серверы должны находиться в одном домене;
• у домена фермы серверов нет доверительных отношений с доменами, не исполь-
зующими Active Directory;
• ферма серверов находится в одном лесу Active Directory.
231
Заметим, что это рекомендации, а не требования. Тем не менее, наличие нескольких до-
менов или доверительных отношений с доменами, не использующими 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
пущено приложение (если для распределения нагрузки используется Load Manager

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

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

запуска приложения клиент инициирует сеанс ICA с сервером.
Перечисление
Перечисление — это процесс, при котором клиент передает данные, чтобы обнаружить
серверы в сети и получает информацию по опубликованным приложениям фермы серверов.
В процессе перечисления клиенты общаются с Citrix XML Service или обозревателем ICA
в зависимости от протокола просмотра, выбранного на клиенте.
Перечисление производится в случае, когда:
• Web Interface или клиентское ПО Program Neighborhood посылает запрос с целью
обнаружения приложения на сервере. При использовании Load Manager (диспетчер
нагрузки) компонента Citrix XenApp для Windows, Advanced Edition и Enterprise
Edition, клиент получает адрес сервера с минимальной загруженностью.
• Пользователи Program Neighborhood выводят список Набора приложений в Мастере
«Найти новый набор приложений».
• Пользователи Program Neighborhood выводят список серверов или опубликованных
приложений в Мастере «Добавить новое ICA-подключение» для создания поль-
зовательского ICA-подключения.
233
Сеансы ICA
Сеанс ICA — это канал связи клиента и сервера, создаваемый пользователем для запуска
приложения. В рамках сеанса ICA сервер передает экран с окном приложения на клиентское
устройство доступа, а устройство посылает приложению, запущенному на сервере, коды
нажимаемых пользователем клавиш, операций мыши и локальные данные.
Порт по умолчанию для входящего трафика сеансов ICA на серверах — 1494.
Если включается функция надежного сеанса, то трафик ICA туннелируется с помощью
общего шлюзового протокола, использующего по умолчанию ТСР порт 2598. Как и в случае
ICA-трафика, для входящих данных во время сеансов с XenApp используется выбранный порт,
а динамически назначаемый порт используется для исходящего трафика. Порты 1494 и 2598
должны быть открыты только для внутреннего входящего трафика.
Исходящий порт на серверах, используемых для сеансов ICA, назначается динамически в
момент создания сеанса.
Кроме компьютеров, на которых запущен Citrix XenApp, в создании сеанса ICA могут
участвовать и другие компоненты, например, компьютеры, на которых запущен Web Interface,
прокси-серверы и веб-обозреватели. В любом случае основной канал связи для сеанса ICA
располагается между клиентом и сервером.
Конфигурирование перечисления
Пользователь подключается к серверам и приложениям из набора приложений или
пользовательских ICA-подключений на клиенте. Перечисление — это процесс, позволяющий
найти серверы и опубликованные приложения в ответ на запросы клиента.
• Когда пользователь запускает приложение из набора приложений, Citrix XenApp
обнаруживает сервер, на котором находится данное приложение и, таким образом,
клиент может подключиться к серверу и запустить приложение.
• Когда пользователь создает пользовательское подключение, то функция «пере-
числение» позволяет получить список опубликованных приложений или серверов в
ферме. Пользователь выбирает приложение или сервер, для которого будет создаваться
пользовательское подключение.
Безопасность сеансов, создаваемых клиентами, подключающимися через Интернет,
должна обеспечиваться при помощи Secure Gateway или Access Gateway.
3.2.1. Настройка доступа пользователей к опубликованным ресурсам

Перед публикацией ресурсов необходимо проверить, как настройки учетных записей
пользователей могут повлиять на их доступ к ресурсам. Ресурсы публикуются для опре-
деленных пользователей и групп пользователей. Мастер публикации приложений позволяет
настроить два типа доступа к приложениям: анонимный доступ и доступ для явных
(настроенных) учетных записей.
Анонимные пользователи
Во время установки Citrix XenApp программа создает специальную группу анонимных
пользователей. По умолчанию анонимным пользователям предоставляются гостевые
разрешения. Публикация приложений для группы анонимных пользователей позволяет
полностью исключить необходимость проверки подлинности при доступе к этим прило-
жениям. Когда пользователь запускает приложение, настроенное для анонимных поль
234
зователей, сервер не требует указания явного имени пользователя и пароля для входа на сервер
и запуска приложения. Анонимным пользователям предоставляются минимальные права на
сеансы, включающие следующие ограничения:
• десятиминутный интервал ожидания при отсутствии действий пользователя;
• выход из системы при разрыве соединения или истечении интервала ожидания;
• пользователь не может изменить пароль (пароль не требуется).
По окончании сеанса анонимного пользователя пользовательские сведения не сохра-
няются. Сервер не сохраняет настройки рабочего стола, принадлежащие пользователю файлы
и другие ресурсы, созданные или настроенные для клиента.
Примечание. Учетные записи анонимных пользователей, которые Citrix XenApp создает
во время установки, не требуют дополнительной настройки. Если нужно изменить их
свойства, можно сделать это с помощью стандартных средств управления учетными записями
пользователей Windows.
Явные пользователи (Explicit Users)

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

Пользователи получают доступ к опубликованным ресурсам с помощью ICA-подклю-
чений и сеансов. Подключения — это порты сетевого протокола, настроенные на ожидание
подключения на компьютере под управлением Citrix XenApp. Когда клиент соединяется с
сервером через подключение, он устанавливает сеанс. Сеанс — это активный канал, который
работает на сервере, пока пользователь не выйдет из системы.
В этой главе описывается управление доступом пользователей к ресурсам фермы серверов
путем настройки входов в систему, конфигурации подключений, а также мониторинга,
оптимизации и управления сеансами.
Настройка входов пользователей в систему

По умолчанию, когда вход в систему разрешен, Citrix XenApp не ограничивает поль-
зовательский доступ к опубликованным приложениям. Следовательно, пользователи могут
запускать несколько подключений и подключаться к любым опубликованным приложениям,
на использование которых они имеют право. Вы можете контролировать способность
пользователей подключаться к серверу, разрешая и запрещая вход в систему.
По умолчанию после установки Citrix XenApp входы активны.
Управление видом пользовательского входа
Во время подключения к серверу пользователи видят все сведения о подключении и
состоянии входа в последовательности экранов, начиная с момента, когда они дважды
щелкают по значкам приложений на клиентском устройстве до проверки подлинности и
запуска опубликованного приложения в сеансе.
235
Citrix XenApp контролирует вид входа, пропуская окна состояния, созданные операци-
онной системой Windows сервера, во время подключения пользователя. Для этого программа
установки Citrix XenApp использует следующие локальные групповые политики Windows для
сервера, на который вы устанавливаете продукт:
• Административные шаблоны ^ Система ^ Удалить сообщения о состоянии за-
грузки/завершения работы/входа/выхода;
• Административные шаблоны ^ Система ^ Подробные или обычные сообщения о
состоянии.
Однако групповые политики, настроенные в Active Directory, имеют приоритет над
эквивалентными локальными групповыми политиками, настроенными для отдельных
серверов. Поэтому если вы установите Citrix XenApp на серверы, входящие в домен Active
Directory, и настроите групповые политики Active Directory, эти политики могут помешать
Citrix XenApp скрыть экраны состояния, сгенерированные операционной системой Windows
на отдельных серверах. В этом случае пользователи увидят экраны состояния, созданные ОС
Windows во время подключения к этому серверу. Для обеспечения оптимальной
производительности не настраивайте такие групповые политики в Active Directory.
Предоставление пользователям функции Workspace Control

Функция Workspace Control позволяет пользователям быстро отключаться от всех ра-
ботающих приложений и переподключаться к ним, или выходить из всех работающих
приложений. Workspace Control позволяет пользователям перемещаться между клиентскими
устройствами и получать доступ ко всем своим открытым приложениям после входа.
Например, Workspace Control может помочь работникам, нуждающимся в быстром переходе
между рабочими станциями и доступе к одному набору приложений при каждом входе в Citrix
XenApp. Если вы разрешите этот режим в Workspace Control, работники смогут отключаться
от нескольких приложений на одном клиентском устройстве, а затем подключаться к ним,
чтобы открыть приложения на другом клиентском устройстве.
Для пользователей, подключающихся через Web Interface или Program Neighborhood Agent
можно настраивать (или разрешить пользователям настраивать) следующие операции:
• Вход. По умолчанию Workspace Control позволяет пользователям переподключаться ко
всем работающим приложениям во время входа без необходимости в повторном
открытии отдельных приложений. С помощью Workspace Control пользователи могут
открывать автономные приложения и приложения, активные на другом клиентском
устройстве. После отключения от приложения оно продолжит работу на сервере. Если
в организации есть пользователи, которые часто меняют рабочее место и которым
необходимо, чтобы некоторые приложения работали на одном клиентском устройстве,
когда они переподключаются к поднабору приложений на другом устройстве, можно
настроить режим переподключения на открытие только тех приложений, от которых
пользователь отключился ранее.
• Переподключение. После входа на ферму серверов пользователи могут переподклю-
читься ко всем приложениям в любое время, нажав кнопку «Переподключить». По
умолчанию переподключение открывает отключенные приложения и все активные
приложения, работающие на другом клиентском устройстве. Переподключение можно
настроить на открытие только тех приложений, от которых пользователь отключился
ранее.
• Выход из системы. Для пользователей, которые открывают приложения через Web
Interface, можно настроить команду «Выход» на выход только из Web Interface и всех
активных сеансов или на выход только из Web Interface.
236
• Отключение. Пользователи могут отключиться от всех работающих приложений без

необходимости в отключении всех приложений в отдельности. По умолчанию функция
Workspace Control включена в ферме серверов и доступна только для пользователей,
которые получают доступ к приложениям через Web Interface или Program
Neighborhood Agent.
Когда пользователь переходит на новое клиентское устройство, пользовательские по-
литики, назначение клиентских дисков и конфигурация принтеров изменяются соот-
ветственно. Политики и назначения применяются в соответствии с клиентским устройством, с
которого подключается пользовательский сеанс. Например, медицинский работник завершает
сеанс на клиентском устройстве в пункте первой помощи больницы, а затем выполняет вход
на рабочую станцию в рентгеновской лаборатории больницы, при этом политики, назначения
принтеров и назначения клиентских устройств для сеанса рентгеновской лаборатории
применяются, как только пользователь выполняет вход на клиентское устройство лаборатории.
Дополнительные сведения о включении и настройке Workspace Control для пользователей
см. в документе Citrix Web Interface Administrator's Guide.
Настройка пользовательских подключений

Citrix XenApp позволяет запускать приложения, опубликованные на сервере, обеспечивая
подключение различных платформ через клиентское ПО Citrix XenApp.
Если подключение обрывается, сеанс, который его использует, останется активным, пока
его состояние не будет изменено функцией автоматического переподключения, параметрами
ICA Keep-Alive или администратором Citrix.
Несколько клиентов могут создавать сеансы, используя одно подключение к серверу. Citrix
XenApp связывает идентификатор пользователя и подключение с каждым сеансом.
Защита ферм серверов

Здесь мы дадим общие указания по планированию безопасных сред Citrix.
Защита доступа к серверам
Первый и важный этап обеспечения безопасности фермы серверов — защита доступа к
серверам и их консолям управления.
Защита Консоли XenApp Console

Консоль XenApp может подключаться ко всем серверам фермы. Запускайте консоль только
в средах, в которых перехват пакетов невозможен. Убедитесь, что доступ к консоли имеют
только администраторы. Можно настроить права NTFS так, чтобы пользователи без прав
администратора не могли выполнять операцию Execute для исполняемого файла консоли
(Ctxload.exe).
Использование разделов NTFS. Чтобы обеспечить необходимый уровень контроля доступа
для всех файлов, установленных Citrix XenApp Server, устанавливайте XenApp Server только
на разделы, отформатированные в NTFS.
Установка и настройка службы SNMP. По умолчанию служба SNMP не устанавливается
на компьютеры под управлением Windows Server 2003. При установке службы необходимо
задать параметр community string. Может потребоваться создание «белого списка» для
ограничения доступа к службе SNMP с удаленных IP-адресов. Служба Windows SNMP
237
по умолчанию поддерживает несколько привилегий на чтение и запись, однако необходимо

также дать службе 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
потребуется создание учетной записи 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 XenApp
можно включить следующие компоненты для защиты сетевой передачи данных:
• шифрование средствами протокола ICA;
• Citrix SSL Relay;
• служба Secure Gateway;
• Secure Ticket Authority (служба STA)
• Межсетевые экраны
Использование средств шифрования протокола ICA

Протокол ICA предлагает встроенное шифрование на стороне клиента и сервера, добавляя
дополнительный уровень защиты от раскрытия данных сеанса. Используйте шифрование ICA
(Citrix SecureICA) для шифрования данных, передаваемых между сервером под управлением
Citrix XenApp Server и клиентом. Шифрование ICA помогает предотвратить перехват данных.
В отличие от шифрования SSL/TLS, шифрование ICA, если ис
239
пользуется отдельно, не обеспечивает проверку подлинности сервера. Поэтому, теоретически,

данные можно перехватить во время передачи по сетям общего пользования и перенаправить
на поддельный сервер. Кроме того, шифрование ICA не включает проверку целостности
данных. Шифрование ICA — только один из аспектов комплексной стратегии безопасности.
Уровень шифрования ICA для опубликованного приложения можно задать на странице
Properties (свойства) приложения или с помощью политик Citrix. Кроме того, необходимо
включить шифрование ICA на стороне клиента. См. документацию по клиенту, который
планируется развернуть.
В целом шифрование ICA нужно использовать если:
• необходима безопасная внутренняя связь в рамках LAN или WAN; или есть по-
требность в безопасном внутреннем доступе в Интранет;
• необходима безопасная связь с устройствами под управлением ОС Microsoft DOS или
Win16;
• клиентское ПО работает на старых устройствах, которые невозможно модерни-
зировать;
• риск «атаки изнутри» невысок.
Использование Secure Gateway

Для обеспечения шифрования SSL/TLS между безопасным шлюзовым сервером Ин-
тернета и клиентом с поддержкой SSL в сочетании с шифрованием данных HTTP, пере-
даваемых между веб-обозревателем и веб-сервером, используется Secure Gateway. Secure
Gateway упрощает передачу данных через межсетевые экраны и улучшает безопасность,
обеспечивая единую точку входа и безопасный доступ к фермам серверов.
Secure Gateway следует использовать, если требуется:
• скрыть внутренние IP-адреса;
• обезопасить общий доступ к серверам фермы;
• двухфакторная аутентификация (в сочетании с Web Interface);
Использование Secure Gateway позволяет добиться следующих преимуществ:
• безопасный доступ к Интернету;
• устранение необходимости в публикации адресов каждого сервера Citrix XenApp;
• упрощение управления серверными сертификатами;
• единая точка шифрования и доступа к серверам.
Для создания шлюза, изолированного от компьютеров под управлением Citrix XenApp,
используется Secure Gateway. Организация шлюза упрощает передачу данных через меж-
сетевой экран, так как входящий и исходящий трафики ICA проходят через широко ис-
пользуемый порт. Secure Gateway обеспечивает повышенную масштабируемость. Однако,
поскольку данные ICA шифруются только между клиентом и шлюзом, может потребоваться
защита трафика между шлюзом и серверами Citrix XenApp, включая серверы, на которых
работает служба Citrix XML Service. Дополнительные сведения о настройке Secure Gateway
см. в документе Secure Gateway Administrator’s Guide.
Использование службы Secure Ticket Authority

Служба Secure Ticket Authority (STA) выполняет выдачу билетов сеансов по запросам на
подключение к ресурсам, опубликованным на сервере Citrix XenApp. На билетах сеанса
основываются процедуры проверки подлинности и авторизации для доступа к опубли-
кованным ресурсам. Служба STA устанавливается одновременно с установкой XenApp.
240
Передача данных Порт по умолчанию
Citrix XML Service 80

Access Management 135
Citrix SSL Relay 443
Сеансы ICA (от клиентов к серверам) 1494
Клиент-сервер (направёенный UDP) 1604
Сервер-сервер 2512
Консоёь XenApp-сервер 2513
Надежность сеанса «Session Reliability» 2598
Сервер-сервер Microsoft SQL иёи Oracle 139, 1433 иёи 443 дёя MS-SQL
Консоёь License Management 8082
Сервер-сервер ёицензий 27000
3.2.2. Настройка проверки подлинности пользователя

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

Если пользователи выполняют вход, используя смарт-карты или сквозную аутенти-
фикацию, необходимо установить отношения доверия между сервером Web Interface и всеми
серверами фермы, к которым Web Interface обращается для доступа к опубликованным
приложениям. Без отношений доверия команды Disconnect, Reconnect и Log Off
241
(«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 делит порт с IIS, можно использовать функцию ограничения IP-адреса в IIS для
ограничения доступа к службе Citrix XML Service.
Настройка входа Kerberos

Клиенты Citrix XenApp для 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 XenApp требует входа по смарт-карте.
Kerberos требует, чтобы для фермы серверов было включено разрешение DNS-адресов
средствами службы Citrix XML Service, или для Active Directory было включено обратное
разрешение DNS.
242
Использование смарт-карты с Citrix XenApp

В среде Citrix XenApp можно использовать смарт-карты:
• аутентификации пользователей в сетях и компьютерах;
• защищенной передачи данных по сети;
• цифровой подписи содержимого.
Если вы используете смарт-карты для аутентификации в сети, пользователям также будет
доступна аутентификация для доступа к приложениям и содержимому, опубликованному на
серверах. При этом функциональность смарт-карты сохраняется и внутри этих приложений.
Например, опубликованное приложение Microsoft Outlook может требовать вставки смарт-
карты в устройство для чтения клиентского устройства для входа на сервер. После
аутентификации пользователей для доступа к приложению они смогут добавлять цифровую
подпись к сообщениям электронной почты с помощью сертификатов смарт-карты.
Компания Citrix тестировала смарт-карты, соответствующие стандарту ISO 7816 для карт
с электрическими контактами (также известных как контактные карты), которые взаи-
модействуют с компьютерными системами через устройства для чтения смарт-карт. Устрой-
ство чтения подключается к компьютеру через последовательный порт, USB или PCMCIA.
Citrix поддерживает криптографические смарт-карты PC/SC, используемые для крип-
тографических операций, таких как цифровые подписи и шифрование. Криптографические
карты обеспечивают безопасное хранение закрытых ключей, которые, в частности, могут
использоваться в системах на основе инфраструктуры PKI (Public Key Infrastructure). В таких
картах криптографические функции выполняются в самой смарт-карте. Это означает, что
закрытые ключи и цифровые сертификаты никогда не покидают карту.
Кроме того, Citrix поддерживает двухфакторную аутентификацию для повышенной
безопасности. Помимо простого предъявления смарт-карты (один фактор) для выполнения
операции требуется PIN-код (второй фактор), известный только пользователю. Это позволяет
гарантировать, что лицо, использующее смарт-карту, является ее законным владельцем.
Смарт-карты можно также использовать в Web Interface для Citrix XenApp. Дополни-
тельные сведения о настройке Web Interface для поддержки см. в документе Web Interface
Administrator’s Guide (Руководство администратора Web Interface).
Требования к смарт-картам
Ниже приводятся основные инструкции по использованию смарт-карт с Citrix XenApp.
Для сервера необходимы следующие компоненты:
• программное обеспечение PC/SC;
• программное обеспечение Cryptographic Service Provider (CSP).
Предупреждение. Citrix Presentation Server не поддерживает функциональные специ-
фикации стандарта PKCS компании RSA Security Inc по персональным криптографически
маркерам.
Компоненты, которые необходимо установить на устройстве с поддерживаемым кли-
ентским ПО Citrix XenApp:
• программное обеспечение PC/SC;
• драйверы устройства для чтения смарт-карт;
• устройство для чтения смарт-карт.
Операционные системы клиента и сервера могут включать PC/SC, CSP и драйверы
устройства для чтения смарт-карт. Сведения о том, поддерживаются ли эти компоненты или их
необходимо заменить специализированным программным обеспечением, можно получить у
поставщика смарт-карт.
243
Если вы используете сквозную аутентификации для передачи учетных записей от кли-

ентского устройства Windows 2000 или Windows XP серверному сеансу смарт-карты, необ-
ходимо установить ПО 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.
Практические занятия». — М.: «ЭКОМ Паблишерз», 2007.
4. Windows Server 2008. Официальный сайт. http://www.microsoft.com/Rus/windows-
server/default.mspx
5. Пошаговые руководства для установки, настройки и использования систем Windows
Server 2008. http://www.microsoft.com/rus/windows-server/tutorials/default.mspx
6. Windows Server TechCenter, http://technet.microsoft.com/ru-ru/windowsserver/default.aspx
7. Воронин А. Безопасный доступ к Oracle E-Business Suite OC 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/?ID=602973
9. Додохов А., Сабанов А. О дополнительных возможностях защиты данных в среде
Oracle9i, BYTE, № 5/2005,
http://www.aladdin.ru/catalog/etoken_products/oracle/public_detail.php?ID=7264
244
11. Сабанов А. Безопасность баз данных. Что, от кого и как надо защищать. Connect, №
4/2006, http://www.aladdin.ru/catalog/etoken_products/oracle/public_detail.php?ID=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.m/catalog/etoken_products/suite/tech_details.php
14. eToken SecurLogon для Oracle Application Server
www.aladdin.ru/catalog/etoken_products/oas/
15. eToken SecurLogon для Oracle E-Business Suite,
www.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
http://www.oracle.com/technology/documentation/database10gr2.html
19. Oracle E-Business Suite. Каталог. http://download.oracle.com/otndocs/ebs/oracle-ebs-
catalogue-full.pdf
20. Oracle Fusion Middleware. Каталог продуктов.
http://www.oracle.com/global/ru/pdfs/index.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. MetaFrame Presentation Server Security Standards and Deployment Scenarios, Citrix Systems,
2004.
24. Citrix Advanced Concepts Guide, Vol. 3, Security, Citrix Systems, 2007.
Источники
1. http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectorycertificates
ervi- ces.mspx» (Службы сертификации Active Directory AD CS)
2. http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectorydomainserv
i- ces.mspx (Службы доменов Active Directory AD DS)
3. http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectoryfederations
ervi- ces.mspx (Службы федерации Active Directory AD FS)
4. http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectorylightweight
directo- ryservices.mspx (Службы Active Directory облегченного доступа к каталогам AD
LDS)
5. http://technet2.microsoft.com/windowsserver2008/en/servermanager/activedirectoryrightsmana
gement- services.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. http://go.microsoft.com/fwlink/?LinkId=101268 (Hyper-V)
12. http://technet2.microsoft.com/windowsserver2008/en/servermanager/networkpolicyandaccessse
rvic- es.mspx (Службы сетевой политики и доступа)
13. http://technet2.microsoft.com/windowsserver2008/en/servermanager/printservices.mspx
(Службы печати)
245
15. http://technet2.microsoft.com/windowsserver2008/en/servermanager/terminalservices.mspx (Службы

терминалов)
16. http://technet2.microsoft.com/windowsserver2008/en/servermanager/uddiservices.mspx (Службы UDDI)
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/b15988/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 Server
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 Server
10.1.3.1 / Oracle Containers for J2EE (OC4J) Security Guide)
22. http://download-uk.oracle.com/docs/cd/B40078_02/doc/bi.1013/b31765.pdf (Oracle BI Suite Enterprise
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 BI Suite
Enterprise Edition 10.1.3.2 / Publisher User Guide)
Edition 10.1.3.2 / Presentation Services Administrator Guide)
Edition 10.1.3.2 / Deployment Guide)
26. http://download-uk.oracle.com/docs/cd/B40078_02/doc/bi.1013/b32481/toc.htm (Oracle BI 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-29fd6146977b1033.
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.citrix.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/CTX112190 Clients for Windows Administrator's Guide-10.x EN
42. http://www.ietf.org/rfc.html Request for Comments Repository
43. http://www.ietf.org/rfc/rfc1509.txt?number=1509 Internet EFC 1509
ЧАСТЬ III
ЛАБОРАТОРНЫЕ РАБОТЫ
Лабораторная работа № 1
ПОДГОТОВКА СТЕНДА,
УСТАНОВКА И НАСТРОЙКА ПО,
ПОДГОТОВКА ЭЛЕКТРОННЫХ КЛЮЧЕЙ eToken
Цель работы
Подготовить стенд для выполнения работ по теме «Обеспечение безопасности доступа к
данным информационной системы организации с помощью продуктов Microsoft и Aladdin.
Типовые решения». Подготовить к работе электронные ключи eToken.
Общие сведения о ключах eToken

Смарт-карты и USB-ключи
Смарт-карты, как и Memory-карты, представляют собой пластиковые карты с встроенной
микросхемой. Однако смарт-карта — достаточно сложное устройство, которое содержит
микропроцессор и операционную систему, контролирующую устройство и доступ к объектам
в его памяти. Кроме того, смарт-карты, как правило, обладают возможностью проводить
криптографические вычисления.
Несмотря на название — устройство для чтения смарт-карт — большинство оконечных
устройств или устройств сопряжения (IFD) способны как считывать, так и записывать, если
позволяют возможности смарт-карты и права доступа. Устройства для чтения смарт-карт
могут подключаться к компьютеру с помощью:
• последовательного порта;
• слота PCMCIA;
• порта USB.
Устройства чтения смарт-карт могут быть интегрированы в клавиатуру.
Некоторые производители выпускают другие аппаратные устройства, в которых смарт-
карта объединена с ее устройством чтения. По характеристикам памяти и вычислительным
возможностям они аналогичны смарт-картам. Наиболее распространены аппаратные ключи,
использующие порт USB. USB-ключи привлекательны для некоторых организаций, поскольку
USB становится стандартом, находящим все большее распространение в новых компьютерах:
организации не нужно приобретать для пользователей какие бы то ни было считыватели.
Для получения доступа к цифровым сертификатам пользователя на этапе аутентификации
в систему и для хранения закрытых ключей пользователей для связки Kerberos + + PKINIT в
ОС Windows 2000/2003 используются смарт-карты. Служба управления ресурсами смарт-карт
интегрирована в операционную систему, и для настройки аутентификации по сертификатам
достаточно активизировать данную службу, установив драйверы считывателей смарт-карт.
При нахождении в домене графический интерфейс OC Windows 2000/2003 (GINA) заменяется
вариантом с поддержкой работы со смарт-картами.
На смарт-карту записывается цифровой сертификат и связанный с ним закрытый ключ,
выписанные на доменном центре сертификации с использованием политик, пред-
усматривающих возможность его использования для интерактивной аутентификации
пользователя в системе.
248
При подключении смарт-карты к рабочей станции для аутентификации пользователя

хранящийся на ней сертификат используется для запроса TGT, а операция с закрытым
ключом, возможная после ввода PIN-кода, используется для подписи этого запроса.
Модели eToken
Ключ eToken — персональное средство аутентификации и хранения данных, аппаратно
поддерживающее работу с цифровыми сертификатами и электронными цифровыми
подписями (ЭЦП). eToken выпускается в форм-факторах USB-ключа или смарт-карты.
USB-ключ 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 и обеспечивают высокий уровень безопасности
(сертификат ITSEC LE4).
Кроме PIN-кода пользователя в eToken PRO предусмотрен пароль администратора. С его
помощью, например, можно сменить забытый PIN-код. Пароль администратора также можно
менять.
eToken PRO можно форматировать с помощью утилиты eToken Properties, входящей в
состав набора драйверов eToken Run Time Environment 3.65. При форматировании:
• из памяти eToken PRO удаляется вся информация;
• устанавливается PIN-код;
• возможно задание пароля администратора;
• возможно задание ключа форматирования для предотвращения несанкционированного
переформатирования.
249
ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ
Описание работы
Для изучения возможностей продуктов 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;
250
Задание
1. Изучить теоретические вопросы, изложенные в начале лабораторной работы.
2. Подготовить стенд.
3. Установить и настроить программное обеспечение, необходимое для работы с ключами
eToken.
4. Подготовить к работе ключи eToken.
5. Оформить отчет по лабораторной работе.
6. Ответить на контрольные вопросы.
Порядок выполнения работы
Описание стенда
Для обеспечения проверки возможности настройки режимов работы встроенных
(штатных) средств обеспечения безопасности Windows Server 2003 и Windows XP, по-
строенных на основе технологий смарт-карт и основных концепциях построения PKI-систем,
на базе Windows Server 2003 CA, ключей и смарт-карт 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 XP, рабочая
станция предприятия.
Для нормального функционирования стенда рекомендуется следующая минимальная
конфигурация рабочей станции:
• центральный процессор — Pentium III 1 ГГц;
• оперативная память — 1 Гб;
• объем свободного места на жестком диске — 20 Гб;
• наличие порта USB версии 2.0.
Кроме того, для настройки и последующей работы стенда потребуется следующее
программное обеспечение:
• операционная система Windows XP Professional;
• VMware версии 6.0 или выше;
• CD-ROM с дистрибутивом (либо образ диска) Windows 2003 Server;
251
• Microsoft Exchange 2003;

• CD-ROM с дистрибутивом (либо образ диска) Windows XP 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 (Остановить сервис) и затем Применить.
252
Дополнительно в списке VMNet host выберите пункт Disable (Отключить).
Выберите вкладку Host virtual Network Mapping.

Задайте адрес для VNNet1.
253
Лабораторная
ЧАСТЬ работа РАБОТЫ
III. ЛАБОРАТОРНЫЕ №1
Задайте виртуальной
Настройка адрес для VMNet8. VM SRV
машины
Машина VM SRV представляет собой контроллер домена northwind.ru. Полное имя
компьютера — server.northwind.ru.
Характеристики виртуальной машины VMSRV
Ниже приведены минимальные характеристики виртуальной машины:
• оперативная память — 384 Мб;
• суммарный объем жесткого диска — 3 Гб;
• сетевая плата — 2 шт.;
• устройство CD-ROM (IDE);
• контроллер USB.
Для нормальной работы виртуальной машины рекомендуется увеличить (по возможности)
объем оперативной памяти, например, до 512 Мб. При определении размера оперативной
памяти обращайте внимание на минимальные, рекомендуемые и максимально возможные
(исходя из характеристик хоста) значения.
Если на хосте установлен сетевой адаптер и он использует те же параметры сети, что и

виртуальные адаптеры VMware, то на время работы со стендом либо отключите его от сети,
либо в свойствах данного сетевого адаптера выберите пункт Отключить (Disable).
Настройка сетевых параметров

Для настройки сетевых параметров виртуальной машины VM SRV выполните следующие
шаги:
Откройте файл виртуальной машины в VMware.
В секции Commands (Команды) нажмите Edit virtual machine settings (Редактирование
настроек виртуальной машины).
Для
Еслисетевой карты Ethernet
же параметры в секции
сети сетевого Network
адаптера Connection
и виртуальных (СетевоеVMware
адаптеров соединение) уста-
на рабочей
новите
станциизначение Custom: ничего
не пересекаются, Specific virtual
делать не network
надо. (Другое: Особенная виртуальная сеть) и в
выпадающем списке выберите
На время выполнения значение VMNet1
практических (Host-only).
работ отключите клиента Firewall на хосте.
254 255
Аналогично для сетевой карты NIC2 установите значение VMNet8 (Host only).
Нажмите OK.
Загрузите операционную систему на VM SRV.
Откройте Пуск ^ Настройка ^ Панель управления ^ Сетевые подключения (Start ^
Settings ^ Control Panel ^ Network connections).
Переименуйте сетевые подключения на LAN (соответствует адаптеру Ethernet) и Internet
(соответствует адаптеру Ethernet 2).
256
Вызовите
Настройка свойства подключения
виртуальной машины VM LAN
WS и установите параметры протокола TCP/IP:
Характеристики виртуальной машины 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 (Другое: Особенная виртуальная сеть) и в
выпадающем списке выберите значение VMNet1 (Host-only).
Вызовите свойства подключения Internet и установите параметры протокола TCP/IP:
Загрузите операционную систему на VM WS.

Откройте Пуск ^ Настройка ^ Панель управления ^ Сетевые подключения (Start ^ Settings
^ Control Panel ^ Network connections).
258 257
Вызовите свойства подключения LAN и установите параметры протокола TCP/IP:
Настройка виртуальной сети

Присоедините виртуальную машину VM WS к домену VM SRV. Кроме того, в моде-
лируемой сети предприятия создайте несколько пользователей.
Присоединение VM WS к домену VM SRV Для
присоединения VM WS к домену VM SRV:
• Загрузите операционные системы виртуальных машин VM SRV и VM WS.
• Перейдите к свойствам Мой компьютер (My Computer) системы VM WS.
• Перейдите на вкладку Имя компьютера (Computer Name) и нажмите Изменить
(Change).
• Введите имя домена northwind.ru и нажмите OK.
259
Укажите имя и пароль учетной записи администратора на системе VM SRV и нажмите

OK.
После появления окна с подтверждением того, что компьютер присоединен к домену,

нажмите OK. Для того чтобы внесенные изменения вступили в силу, VM WS потребуется
перезагрузить.
После этого вы можете зарегистрироваться на VM WS с помощью учетной записи ло-

кального администратора либо с помощью учетной записи доменного администратора. Далее,
если не будет указано обратное, для входа ВСЕГДА будет использоваться доменный
пользователь.
260
Задайте
Создание пароль
нового для пользователя. Отключите опцию Требовать смену пароля при сле-
дующем входе в систему (User must change password at next logon).
Для того чтобы создать пользователя выполните следующие шаги:
Запустите на VM SRV Пуск ^ Программы ^ Администрирование ^ Active Directory —
Пользователи и компьютеры (Start ^ Programs ^ Administrative Tools ^ Active Directory —
Users and Computers).
В директории Users (Пользователи) создайте нового пользователя.
Нажмите Далее (Next) для создания почтового ящика с параметрами по умолчанию.
Задайте ему имя для входа в сеть и нажмите Далее (Next).
262 261
Нажмите Готово (Finish).

. Щ| Jf.
К/Мй№ Л/бзктВ№LJ,~ ЦрЦ
-L. -I !■ Itl ш~
rpyvnitiUCfUOttCn*.
Г р^г» безопасное f к We*nbers ипо nave

групп* б1НА10«е*к OT5 А***Ф*СП мчр
BESSШ
Пеоедестигь
ICenunCOft -У •■***.#**,#* мл*
йтпр*окг*
Wt iDomiri почту
M deffun cortroto i n №
Control Счтаг» Kt HIM! AidomenîWta
Gunfe ! ■EJ <**де t**<
ьамлум«у : Gbc<44 Designated admrtstTaCof*
Ь*вфпи £J,V*rffc. Member* n If® <*CM> <an
JWfc* Eu*‘H *ccotrt lot QjMt
■VtnjC Wky ■>cxp for tr* Mefc and Su
От Mlt 5*v** n IЫ
! ■‘«•сдаа ;™r Deagrialed admnstrator«
rtvt * * verrii* « ассод*
rpynftlMHAMNKlii ij №■* W n*
погъзоы»егк
jj Arw»::ewBocp:«4Q*
C-Tr^jfciT.rt СГСШяр- ШИС11 Ei JJ *Лйй «ДО OOUPCT*.
Для выполнения дальнейших лабораторных работ необходимо по приведенному выше

сценарию
На вкладке
создать двухгрупп
Члены пользователей.
(Members) нажмите
Один пользователь
Добавить (Add).
будет администратором. Для этого
нужно создать пользователя, используя следующие данные:
• имя: «Admin»;
• фамилия: «Инициалы вашего имени и фамилии»;
• имя для входа в сеть: «Admin_»Инициалы вашего имени и фамилии».
Второго пользователя нужно создать, используя следующие данные:
• имя: «User»;
• фамилия: «Инициалы вашего имени и фамилии»;
• имя для входа в сеть: «:№ег_»Инициалы вашего имени и фамилии».
Предоставление пользователю прав администратора

Для выполнения практических работ потребуется предоставить созданному пользователю
«Admin_»Инициалы вашего имени и фамилии» права администратора. Чтобы это сделать,
выполните следующую последовательность действий:
Запустите на VM SRV Пуск ^ Программы ^ Администрирование ^ Active Directory —
пользователи и компьютеры (Start ^ Programs ^ Administrative Tools ^ Active Directory — users
and computers).
В папке Users выберите группу Администраторы домена (Domain Admins) и правой
клавишей мыши откройте свойства данной группы.
264 263
Введите имя пользователя, которому вы предоставляете права администратора («Admin_»

Инициалы ва0его имени и фамилии»), затем нажмите Проверить имена (Check Names).
Если имя пользователя введено верно, нажмите OK.
После того как пользователь оказался в списке членов данной группы, нажмите OK.
Закройте программу «Active Directory — пользователи и компьютеры».

265
Установка и настройка программного обеспечения

для работы с ключами eToken
eToken Run Time Environment (eToken RTE) — это среда функционирования устройств
eToken, включающая все необходимые драйверы и утилиту «Свойства eToken» (eToken
Properties). С помощью утилиты «Свойства eToken» вы можете:
• осуществлять настройки параметров eToken и его драйверов;
• просматривать общую информацию относительно eToken;
• импортировать, просматривать и удалять сертификаты и ключевые контейнеры RSA;
• форматировать eToken;
• настраивать критерии качества PIN-кодов.
По умолчанию в eToken Run Time Environment 3.65 предусмотрен интерфейс на анг-
лийском языке. При установке пакета eToken Run Time Environment 3.65 Russian User Interface
(eToken RTE 3.65 RUI) язык интерфейса eToken RTE 3.65 изменяется на русский.
Согласно требованиям для проведения данной части работы необходимо выполнить
следующие действия:
Убедитесь, что на вашем компьютере присутствуют и находятся в рабочем состоянии
порты USB.
Запустите файл RTE_3.65.msi. На экране появится окно приветствия программы ус-
тановки RTE.
В окне приветствия программы установки eToken Run Time Environment нажмите Next
(Далее).
В окне eToken Run Time Environment 3.65 Setup/End-User License Agreement ознакомьтесь
с Лицензионным соглашением (на английском языке). Если вы согласны с его условиями,
выберите I accept the license agreement (Я принимаю условия лицензионного
266
соглашения) и нажмите Next (Далее) для того, чтобы продолжить установку. Если вы не
согласны с условиями лицензионного соглашения, нажмите Cancel (Отмена), а в появившемся
окне — Yes (Да), чтобы выйти из программы установки.
1\ с ТАЕПЯМЛ IHTK- Г тлгпгопгчП ). ijj Sclup
tad-Utei iHtn-tt А#**лпми Fbuv — ъ! Пн

k|!» ермпцг* eToic en 1
RTE
AL AW13 N KNO ВД L¥DCE SVifT E Г, US L T D. г TOKEN
ENTERPRISE END USER LICENCE AGREEMENT

IMPORTANT INFORMATION ■ FLELA5E READTttS
AGREEMENT CAREFULLY b£frjR£ OPENING THE PACK AGE
ANDttft USING THE CONTENTS" TH£R£OF AHDtOR PEFORE
DOWNLOADING OR INSTALLING THE SOFTWARE PROGRAM
ALL ORDERS fQP-AHD USE OF THE iTOKEN ENTERPRISE
PRODUCTS (e;Urj чтКвда
knishDa Wif«*S. чйьг*. iiktde*. Ct-RQH tTglmi" k=7* wl KCQK*4 lecbnt J| ismentiice)
И^еенЁн -РГЬЙНЕС) SUPPLIED
01 к(.кг Чн kenia чк*п'
ОI * nol кс«' Пн-кепи 4«er«44
■ Baci ~| Haf ■___J [ Cimi ,
Отсоедините все eToken от компьютера и в окне eToken Run Time Environment 3.65
Setup/Ready to Install the Application нажмите Next (Далее).
267
Подождите некоторое время, пока программа завершит установку. После завершения

установки появится окно c сообщением eToken Run Time Environment 3.65 has been suc-
cessfully installed. Нажмите Finish (Готово).
Для удобства дальнейшей работы необходимо установить русификацию драйвера eToken

RTE. Для того чтобы установить eToken RUI, выполните следующее:
Запустите программу установки eToken RUI (RTE_3.65.RUI.msi). На экране появится окно
приветствия программы установки.
В окне приветствия программы установки eToken RUI нажмите Далее.
268
В окне eToken RTE 3.65 Russian User Interface\roTOBa к установке программы нажмите
Установить.
Дождитесь завершения установки. После завершения установки eToken RUI в окне eToken
RTE 3.65 Russian User Interface/Программа InstallShield Wizard завершена нажмите Готово.
269
Подготовка ключей eToken

Для того чтобы иметь доступ к полным возможностям утилиты «Свойства eToken»,
выполните следующие действия:
Нажмите Пуск ^ Выполнить (Start ^ Run). В появившемся окне в строку ввода Открыть
(Open) введите regedit для запуска программы редактора реестра.
В окне редактора реестра выберите ветвь \HKEY_LOCAL_MASHINE\SOFTWARE\

Aladdin\eToken\eTProperties.
I□ п pcccipa
'Ъти'П ■■■■■ nfi*i л
h* EYxLRREWT .USER
Иг FttOCfil P
HARDWARE OMOOOOOOOI
РЕСДОЯО ihilt ft ft f «ДО67295]
-I SECLF'ITT
SOFTWARE
bTouil
CflmdCfltralK
Cepe
гГСЛР
e‘Cert Store
j «"propffbw
«эй ь fwfri фV _LCO*l.^W*OlJCp*-* SWAHE УйкйгАе S с*игин 1РгЕрМвЕ
Укажите в области Система счисления (Base) значение Шестнадцатеричное

(Hexadecimal). Присвойте параметру Advanced значение f.
270
Закройте окно редактора реестра.

Для того чтобы виртуальная машина могла использовать устройства USB (в частности
eToken), подсоединенное к компьютеру, на котором эта машина запущена:
Выберите в VMware окно виртуальной машины, в которой вы хотите использовать eToken.
Из меню программы VMware выберите VM/Removable Device/USB Portl/Anonymous USB
Device (...)
При появлении следующего окна нажмите ОК.
В будущем, чтобы исключить появление данного окна, установите флажок 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.
271
Для дальнейшего выполнения работы необходимо отформатировать ключи eToken,

используемые для выполнения лабораторной работы. Для того чтобы отформатировать eToken
PRO, выполните следующее:
Нажмите Пуск ^ Программы (Все программы) ^ eToken Properties (Start ^ Programs (All
Programs) ^ eToken ^ Properties). В окне утилиты «Свойства eToken» выберите eToken для
форматирования.
272
Нажмите кнопку Форматирование.
Для изменения параметров форматирования, принятых по умолчанию, нажмите Па-

раметры. Появится окно Параметры форматирования eToken.
Для форматирования eToken с созданием Aladdin File System (файловой системы Aladdin)
оставьте пункт Инициализировать eToken отмеченным.
В секции Назначение PIN-кода оставьте значения полей PIN-код и Подтверждение по
умолчанию (1234567890).
273
Задайте пароль администратора. Для этого установите флажок Задать пароль адми-
нистратора и введите пароль (1234567890) в поля Пароль и Подтверждение.
Выберите вкладку Настройки.
274
В поле
Для начала eToken выберитев соответствующий
Цветформатирования цвет сзначка
окне Свойства eToken eToken.
предупреждением о потере данных
при В
форматировании нажмите
разделе Счетчики OK. попыток ввода задайте количество неправильных попыток
неудачных
ввода PIN-кода и пароля администратора равным 15.
Выберите вкладку Ключ форматирования.
Процесс форматирования будет отображаться в окне Форматирование eToken. Дождитесь

завершения процесса форматирования.
По окончании форматирования появится сообщение об успешном завершении фор-

матирования. Нажмите OK.
Проверьте, что в разделе Текущий ключ форматирования отмечен пункт Ключ фор-
матирования по умолчанию, а в разделе Новый ключ форматирования не отмечен пара-
метр Назначить ключу форматирования значение.
Внимание! Назначение ключа форматирования может иметь необратимые
последствия.
Нажмите OK.
Закройте утилиту «Свойства
В окне Форматирование .
нажмите
eToken»
eToken Запустить.
Для дальнейшего выполнения лабораторной работы необходимо настроить параметры
работы ключей eToken. Для этого выполните следующее:
Нажмите Пуск ^ Программы (Все программы) ^ eToken ^ eToken Properties (Start ^
Programs (All Programs) ^ eToken/eToken Properties).
Примечание. В процессе работы с программой, для внесения изменений в пара-
метры eToken, необходимо будет ввести его PIN-код. После его ввода вы можете
вносить необходимые изменения в различных окнах программы, пока вы не выйдите
из программы.
После запуска программы в окне Свойства eToken отображается общая информация
относительно выбранного eToken:
цвет и имя eToken, в строке Имя считывателя — устройство чтения (физическое или
виртуальное), в строке Модель — модель eToken.
276 275
В случае успешной смены PIN-кода на экране появится окно с сообщением PIN-код

успешно изменен. При появлении этого окна нажмите OK.
Для дальнейшего выполнения лабораторной работы необходимо переименовать ис-

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

тельские PIN-коды (заданные по умолчанию) на используемые в лабораторной работе ключи
eToken. Используйте простые пароли, например 123456 или 654321. Для этого выполните
следующее:
Для смены PIN-кода нажмите Сменить PIN-код...
В окне Свойства eToken введите текущий PIN-код в поле Текущий PIN-код (по умолчанию
1234567890), а новый PIN-код — в поля Новый PIN-код и Подтверждение:
— в окне справа отображается качество задаваемого вами нового PIN-кода, оно должно
быть в «зеленой зоне», в противном случае заданное вами значение не будет принято;
— если вы нажмете кнопку Показать рекомендации, вы увидите текущие требования по
качеству пароля, которым он должен соответствовать.
Нажмите OK. (Кнопка OK неактивна до тех пор, пока не введена удовлетворительная
информация в поля Новый PIN-код и Подтверждение).
Задайте имя для первого eToken в формате: «Айтш»_»Ваша фамилия».

Задайте имя для второго eToken в формате: «User»_»Ваша фамилия».
Для настройки требований, накладываемых на предприятии на качество PIN-кодов eToken
и паролей администратора, служит пункт Качество паролей из состава утилиты «Свойства
eToken».
Информация о качестве PIN-кодов и паролей хранится в файле etpass.ini, расположенном в
системной папке %systemroot%\system32 (по умолчанию — C:\WINDOWS\System32).
Программа позволяет создавать и редактировать конфигурационные файлы для их
последующего распространения среди пользователей eToken.
Требования к качеству PIN-кода и пароля администратора общие. Поэтому для краткости
при описании задания критериев качества будем использовать термин пароль. Требования
задаются путем задания критериев качества пароля.
Для запуска настройки параметров качества паролей eToken запустите утилиту «Свойства
eToken», нажав Пуск ^ Программы (Все программы) ^ eToken ^ eToken
278 277
На хосте
Properties (Start ^ Programs
создайте (All Programs)
свои настройки ^ eToken
качества ^ eToken
паролей Properties)
eToken, и выберите
используя утилиту на вкладке
«Свойства
Компьютер
eToken» . пункт Качество паролей.
С помощью программы Notepad (Блокнот) откройте файл c:\windows\system32\etpass.ini и
внесите дополнительные изменения, усиливающие качество паролей.
Установите единые установки критериев качества паролей на все машины. Для этого
скопируйте файл etpass.ini на VM WS и VM SRV в директорию c:\windows\system32\.
Для того чтобы убедиться в применении заданных критериев качества паролей (PIN-кода)
eToken, необходимо в утилите «Свойства eToken» изменить пароль и попытаться задать
пароль, не удовлетворяющий заданным критериям качества.
Результат тестирования критериев качества паролей можно считать положительным, если
не удается изменить пароль пользователя на пароль, заведомо этим критериям не
удовлетворяющий.
Содержание отчета
Отчет оформляется один на бригаду из одного-двух исполнителей.
В отчете с титульным листом установленной формы (Приложение А) необходимо
представить следующие сведения:
1. Наименование и цели работы.
2. Краткую характеристику учебного стенда (по составу доступных пользователю функций
управления и индикаций, распределению ресурсов, функций, вариантов набора
преобразований).
3. Функциональную схему учебного стенда с пояснениями и комментариями.
4.ВЗаданные
открывшемся окнекачества
критерии Настройка параметров
паролей качества паролей
eToken, установленные eToken
в ходе можно работы.
выполнения просмат-
ривать и изменять значения
5. Подготовиться параметров,
для устных ответов на влияющих
контрольныена вопросы.
качество паролей, а также выявлять
качество текущих паролей.
Для того чтобы проверить соответствие пароля выбранным критериям, введите пароль в
строку Проверка качества введенного пароля.
Под строкой Проверка качества введенного пароля в процентах условно отображается
качество введенного пароляКонтрольные
согласно критериямвопросы
файла etpass.ini. В нижнем поле окна
выводится информация о причинах несоответствия введенного пароля этим критериям.
1. Как подготовить к работе учебный стенд?
2. Как ввести в действие учебный стенд?
3. Каковы признаки готовности учебного стенда?
4. Каким образом можно инициализировать eToken?
5. Каким образом можно задать сложность пароля для eToken?
6. Каким образом можно распространить критерии качества пароля eToken на другие
компьютеры?
279
Приложение А
Титульный лист
(образец)
ГОУ ВПО Томский государственный университет

систем управления и радиоэлектроники (ТУСУР)
Кафедра комплексной информационной безопасности

электронно-вычислительных систем (КИБЭВС)
ПОДГОТОВКА СТЕНДА, УСТАНОВКА И НАСТРОЙКА ПО,

ПОДГОТОВКА ЭЛЕКТРОННЫХ КЛЮЧЕЙ eToken
(наименование лабораторной работы)
Отчет по лабораторной работе дисциплины

«Безопасность вычислительных сетей»
Выполнили:
Студенты гр.
(Ф.И.О.)
(Ф.И.О.)
Принял:
Руководитель
(Ф.И.О)
(год)
281
УСТАНОВКА И НАСТРОЙКА ЦЕНТРА
СЕРТИФИКАЦИИ, ИСПОЛЬЗОВАНИЕ КЛЮЧЕЙ
ETOKEN В ДОМЕНЕ WINDOWS SERVER 2003
Для выполнения работ по теме «Обеспечение безопасности доступа к данным ин-
формационной системы организации с помощью продуктов Microsoft и Aladdin. Типовые
решения» установить и настроить Центр сертификации Windows Server 2003 CA и научиться
использовать электронные ключи eToken для аутентификации пользователей в домене
Windows Server 2003.
Общие сведения об аутентификации пользователей

в домене Windows Server 2003 c помощью цифровых сертификатов
и ключей eToken
Инфраструктура открытых ключей (PKI)

Основой построения инфраструктуры открытых ключей (PKI) на базе Windows Server
2003 является Центр сертификации (Certification Authority, CA) — один из компонентов
сервера Windows Server 2003. Центр сертификации получает и обрабатывает запросы на
издание цифровых сертификатов (X.509), идентифицирует и подтверждает такие запросы,
издает сертификаты, используя шаблоны сертификатов, обновляет и аннулирует сертификаты,
публикует сертификаты, создает и обрабатывает Списки аннулированных сертификатов
(Certificate revocation lists, CRLs), а также сохраняет в журнале все операции с сертификатами.
Центр сертификации (CA) также выполняет операции по хранению и восстановлению
CA интегрирован со службой каталогов (Active Directory, AD) и использует AD для
получения информации о пользователях и для хранения ключевых контейнеров.
При использовании электронных ключей eToken CA позволяет копировать цифровые
сертификаты и закрытые ключи в защищенную память eToken.
Для изучения возможностей Microsoft Windows Server 2003 CA и электронных ключей
eToken для обеспечения аутентификации пользователей в домене Windows Server 2003 и
безопасности доступа к данным информационной системы работа делится на две части:
• установка и настройка Центра сертификации (CA), подготовка его консоли, издание
сертификатов;
• использование ключей eToken для регистрации в домене, для запуска приложений от
имени другого пользователя и для подключения сетевых дисков с использованием прав
доступа другого пользователя.
282
Установка и настройка Центра сертификации (CA),

подготовка консоли Центра сертификации, издание сертификатов
Данная часть работы предназначена для установки и настройки Центра сертификации,
подготовки к работе консоли Центра сертификации и издания сертификатов, которые будут
использоваться при выполнении основной части лабораторной работы. Для выполнения
данной части работы необходимо:
Установить Центр сертификации на виртуальную машину VM SRV.
Настроить Центр сертификации:
• Создать шаблон сертификата.
• Включить шаблоны сертификатов.
Настроить консоль Центра сертификации:
• Установить пакет Windows Server 2003 Administration Tools.
• Подготовить консоль Центра сертификации.
• Подготовить консоль управления доменными политиками.
• Установить групповую политику для автоматической выдачи сертификатов. Издать
сертификаты:
• Настроить станцию выписки сертификатов.
• Добавить Центр сертификации в список доверенных узлов.
• Подготовить консоль управления сертификатами.
• Получить сертификат агента получения заявок.
• Издать сертификаты с помощью агента получения заявок.
• Издать сертификаты без помощи агента получения заявок.
• Скопировать сертификаты с закрытыми ключами на eToken.
• Проверить работу стенда.
• Проанализировать полученный результат.
Использование ключей eToken для регистрации в домене,

для запуска приложений от имени другого пользователя
и для подключения сетевых дисков с использованием прав доступа
другого пользователя
Данная часть работы предназначена для обучения использованию ключей eToken при
выполнении основных операций по безопасному доступу к информационным ресурсам
домена Windows Server 2003 — регистрация пользователя в домене, запуск приложений и
подключение сетевых дисков от имени другого пользователя с использованием электронных
ключей eToken. Для выполнения данной части работы необходимо:
• Выполнить регистрацию в домене с помощью eToken.
• Установить для пользователя требование использования смарт-карты при инте-
рактивном подсоединении к компьютеру.
• Установить групповую политику требования использования смарт-карты при ин-
терактивном подсоединении к компьютеру.
• Установить блокирование компьютера и принудительный выход пользователя при
отключении eToken.
Выполнить запуск приложений от имени другого пользователя:
• С использованием графического интерфейса.
• С использованием командной строки.
283
Выполнить подключение сетевых дисков с использованием прав доступа другого

пользователя:
• С использованием графического интерфейса.
• С использованием командной строки.
Проанализировать полученный результат.
Задание
1. Изучить теоретические вопросы, изложенные в начале данной лабораторной работы.
2. Установить и настроить Центр сертификации.
3. Выписать сертификаты, скопировать их в ключи eToken.
4. Выполнить регистрацию пользователя в домене с использованием eToken.
5. Выполнить запуск приложений от имени другого пользователя с использованием eToken.
6. Выполнить подключение сетевых дисков с использованием прав доступа другого
пользователя с использованием eToken.

Установка Центра сертификации
Для установки Центра сертификации на контроллер домена выполните следующие шаги:
Зарегистрируйтесь на компьютере VM SRV под именем пользователя с правами адми-
нистратора.
Выполните Пуск ^ Настройка ^ Панель управления ^ Установка и удаление программ
(Start ^ Control Panel ^ Add or Remove Programs).
Нажмите Установка компонентов Windows (Add/Remove Windows Components). Выберите
пункт Certificate Services и нажмите Далее (Next).
284
Появится предупреждающее сообщение о том, что после установки Центра сертификации

на сервер нельзя будет изменить имя сервера (имя его домена). Если имя сервера уже
установлено и меняться не будет, нажмите Да (Yes).
В окне Мастер компонентов Windows (Windows Components Wizard) нажмите Далее

(Next). Выберите пункт Корневой ЦС предприятия (Enterprise root CA) и нажмите Далее
(Next).
Задайте Общее имя для этого ЦС (Common name). Для задания имени ЦС используйте
инициалы имени и фамилии + Root. Затем нажмите Далее (Next).
285
Нажмите Далее (Next).
Появится предупреждение, что служба IIS будет временно остановлена. Нажмите Да (Yes).
Для продолжения потребуется дистрибутив Windows 2003 Server. При работе с VM SRV
необходимо будет подключить образ данного диска к этой виртуальной машине. Для этого вам
понадобится ISO-образ данного диска (либо установочный CD-ROM).
Из меню программы VMware, в которой у вас запущена VM SRV, выберите VM ^ Settings.
После этого появится окно Virtual Machine Control Panel. На закладке Hardware выберите CD-
ROM, укажите путь к образу диска, установите опцию Device status — Connected. Нажмите
OK.
286
Примечание. Система установки автоматически обнаружит появление 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 будет
использоваться при издании сертификатов.
287
В окне Свойства нового шаблона (Properties of NewСоздание

Template)шаблона
на закладке Общие
сертификата
(General) в поле Отображаемое имя шаблона (Template display name) введите Aladdin
Для того чтобы создать шаблон сертификата Aladdin Smartcard User, выполните сле-
Smartcard User.
дующее:
Запустите консоль Центра сертификации Пуск Программы ^ Администрирование ^ Центр
сертификации (Start ^ Programs ^ Administrative Tools ^ Certification Authority). Выберите
Центр сертификации, который вы хотите настроить.
Щелкните правой кнопкой мыши на Шаблоны сертификатов (Certificate Templates) и
выберите Управление (Manage).
Откройте
В закладку
окне certtmpl Обработка
— [Certificate запросавыберите
Templates] (Request шаблон
Handling). Назначьте со
Пользователь параметру Ми-
смарт-картой
нимальный размер ключа (Minimum key size) значение 1024. Нажмите Поставщики (CSPs).
(Smartcard user), щелкните правой кнопкой мыши и выберите Скопировать шаблон (Duplicate
Template).
288 289
ЧАСТЬ работаРАБОТЫ
В окне Выделить
Свойства нового
CSP (CSP
шаблона
Selection)
(Properties
выберите
of New
Запросы
Template)
должны
нажмите
использовать
OK. Убедитесь
один из
в
следующих
том, что шаблон
CSP Aladdin
(Requests
Smartcard
must useUser
oneпоявился
of the following
в списке
CSPs).
Шаблоны сертификатов
(Certificate
В списке Templates).
Поставщики служб криптографии (CSPs) выберите eToken Base Cryptographic
Provider
Закройте
и нажмите
окно certtmpl
OK. — [Certificate Templates].
Для выполнения лабораторной работы создайте шаблоны сертификатов в соответствии
с указанными ниже параметрами, остальные параметры оставьте без изменений:
Параметры шаблона
Примечание.
Имя шаблона Этот CSP присутствуетОбработка
в списке,запроса
только если на компьютере, с которого
осуществляется настройка создаваемого шаблона, установлен eToken RTE.
Базовый шаблон Минимальный CSP Требования выдачи
размер ключа
В окне Свойства нового шаблона (Properties of New Template) откройте вкладку Тре-
бования выдачи (Issuance Requirements).
Aladdin Smartcard Пользователь со eToken Base Указанное число авто-
User смарткартой Cryptographic ризованных подписей: 1
Цель: (Smartcard User) Provider Тип политики: политика
применения Политика
Вход 1024 eToken Base применения: агент запроса
Aladdin Smartcard со смарткартой Cryptographic сертификата
Logon (Smartcard Logon) Provider
Пользователь Microsoft
Aladdin Exchange Exchange (Exchange Enhanced
Sign & Encrypt User) Cryptographic
Цель: подпись и Provider
шифрование
Поставьте флажок Указанного числа авторизованных подписей (This number of authorized

signatures) и убедитесь, что этот параметр принимает значение 1.
Убедитесь, что параметр В подписи требуется указать тип политики (Policy type required in
signature) принимает значение Политика применения (Application Policy).
Из списка Политика применения (Application Policy) выберите Агент запроса сертификата
(Certificate Request Agent).
290
Включение шаблонов сертификатов
После того как шаблон сертификата создан, его необходимо включить. Для включения
шаблона сертификата, выполните следующее:
Запустите консоль Центра сертификации Пуск ^ Программы ^ Администрирование ^
Центр сертификации (Start ^ Programs ^ Administrative Tools ^ Certification Authority).
Выберите Центр сертификации, который вы хотите настроить.
В дереве консоли щелкните правой кнопкой мыши Шаблоны сертификатов (Certificate
Templates) и выберите Создать (New). Щелкните Выдаваемый шаблон сертификата
(Certificate Template to Issue).
291
В окне Включение шаблонов сертификатов (Enable Certificate Templates) выберите

шаблон Aladdin Smartcard User и нажмите OK.
Для выполнения лабораторной роботы включите созданные шаблоны сертификатов

Aladdin Smartcard User, Aladdin Smartcard Logon, Aladdin Exchange Sign & Encrypt и шаблон
сертификата агента подачи заявок (Enrollment Agent).
Установка пакета Windows Server 2003 Administration Tools

Настроить Центр сертификации вы можете как на самом сервере, так и с любого
компьютера, входящего в домен. Компьютер, с которого осуществляется настройка Центра
сертификации, должен работать под управлением операционной системы Windows Server
2003 или Windows XP 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
Примечание. Система автоматически обнаружит появление компакт-диска,

запустится опция 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).
В меню Консоль (Console) выберите Добавить или удалить оснастку (Add/Remove snap-in).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите Добавить (Add).
294
В окне Добавить изолированную оснастку (Add Standalone snap-in) выберите Certification

Authority и нажмите Добавить (Add).
В окне Certification Authority выберите Another computer и введите имя сервера, на ко-
тором установлен CA.
Нажмите Готово/Finish.
В окне Добавить изолированную оснастку (Add Standalone snap-in) нажмите Закрыть
(Close).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите OK.
Сохраните настройки консоли на рабочем столе (Консоль ЦС).
295
Подготовка консоли управления доменными групповыми политиками

Если на вашем компьютере нет готовой консоли для управления доменными групповыми
политиками, подготовьте ее, выполнив следующие шаги:
Зарегистрируйтесь на компьютере под именем доменного администратора.
Запустите программу Пуск ^ Выполнить ^ mmc (Start ^ Run ^ mmc).
В меню Консоль (Console) выберите Добавить или удалить оснастку (Add/Remove snap-
in).
В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите Добавить (Add).
В окне Добавить изолированную оснастку (Add Standalone snap-in) выберите Редактор
объектов групповой политики (Group Policy Object Editor) и нажмите Добавить (Add).
В появившемся окне выберите с помощью кнопки Обзор (Browse) выберите Default

Domain Policy (Политика домена по умолчанию).
296
Нажмите Готово (Finish). Издание сертификатов

В окне Добавить изолированную оснастку (Add Standalone snap-in) нажмите Закрыть
Для издания сертификатов пользователей необходимо настроить станцию выписки
(Close).
сертификатов и получить сертификат
В окне Добавить/удалить агента получения
оснастку (Add/Remove заявок.
snap-in) Выписывать
нажмите OK. сертификаты
можно как с помощью агента получения заявок, так и без него.
Сохраните настройки консоли на рабочем столе (Domain policy).
Кроме того, необходимо произвести настройку хоста для выписки сертификатов на
устройство eToken. Необходимость Установка групповой
настройки политики
хоста вызвана особенностями работы VMware
с портами USB. Длядля настройки хоста требуется
автоматической внестисертификатов
выдачи изменения в реестр Windows, чтобы
это сделать выполните следующие шаги:
Для того в чтобы
Создайте программепользователи могли переиздавать
Notepad («Блокнот») сертификаты
или любом другом текстовомавтоматически
файле файл
(reenrollment), кроме настроек Центра сертификации отредактируйте
данных реестра (Registration Entries, *.reg), например vm_usb_correct.reg. соответствующий
объект групповой
Введите политики.
следующий текст:
Зарегистрируйтесь на компьютере под именем доменного администратора.
Windows Registry
Запустите созданнуюEditor Version
ранее 5.00 Domain Policy.
консоль
Отредактируйте объект групповой политики Конфигурация пользователя ^ Конфигурация
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmusb\Parameters]
Windows
@="" ^ Параметры безопасности ^ Политики открытого ключа ^ Параметры
автоматической подачи заявок (User Configuration ^ Windows Setting ^ Security Settings ^
"PowerStateOnOpen—dword:00000000
Public Key Policies ^ Autoenrollment Settings):
"PowerStateOnClose"=dword:00000000"
"EnableRemoteWakeup"=dword:00000001
"MinPowerStateUsed"=dword:00000003
"MinPowerStateUnused"=dword:00000003
"AbortPipesOnPowerDown"=dword:00000001
"SuppressPnPRemoveDlg"=dword:00000001
"RequestTimeout'—dword:00002710
"ShortTransferOk'—dword:00000001
"MaxIsoPackets"=dword:00000040
"UnconfigureOnClose'—dword:00000001
"ResetDeviceOnClose"—dword:00000000
Сохраните файл и запустите его. На предложение внести данные в реестр ответьте Да
(Yes).
После успешного внесения данных в реестр нажмите OK.
Примечание. Если не внести указанные изменения в реестр Windows, то
выписать сертификат можно будет только на смарт-карту eToken. На USB-ключ
eToken выписать сертификат будет невозможно — при попытке это сделать будет
выведено окно с сообщением о неизвестной ошибке.
— выберите
Настройка Подавать
станции заявки на сертификаты автоматически (Enroll certificates
выписки сертификатов
automatically);
Добавление Центрафлажок
— установите сертификации в список
Обновлять доверенных
сертификаты узлов
с истекшим сроком действия, обновлять
Для выписки
отозванные сертификатов
и устанавливать с использованием
сертификаты в состоянииприложения
ожидания Internet
(RenewExplorer
expiredнеобходимо
certificates,
предварительно настроитьand
update pending certificates, его параметры
remove revoked безопасности.
certificates); Для этого:
Запустите
— приложение
установите Internet Explorer.
флажок Обновлять Откройте
сертификаты на пункт
основеменю Сервис
шаблонов ^ Свойства обоз-
ревателя (Tools ^ Internet
(Update certificates that useOptions).
certificates Откройте вкладку Безопасность (Security).
templates).
Выберите зону Надежные
Примечание. узлы (Trusted
Данный объект можно sites) и нажмите
использовать кнопку
как Узлы (Sites).
в доменных Введите
политиках, так и в
адрес Центра сертификации (http :// server . northwind
политиках, применяемых к отдельным подразделениям. . ru / certsrv) и нажмите Добавить (Add).
Нажмите OK.
Чтобы обновленная политика начала действовать немедленно, выполните на контр-
оллере домена команду gpupdate /force.
298 297
Выберите зону Надежные узлы (Trusted sites) и нажмите кнопку Другой (Custom level).
В поле На уровень: установите значение Низкий и нажмите OK.
299
Подготовка консоли управления сертификатами

Зарегистрируйтесь на компьютере VM WS под именем доменного администратора.
Запустите программу Пуск > Выполнить > mmc (Start > Run > mmc).
В меню Консоль (Console) выберите Добавить или удалить оснастку (Add/Remove snap-
in). В окне Добавить/удалить оснастку (Add/Remove snap-in) нажмите Добавить (Add).
В окне Добавить изолированную оснастку (Add Standalone snap-in) выберите Серти-
фикаты (Certificates) и нажмите Добавить (Add).
Выберите моей учетной записи пользователя (My user account).
300
На
В окнестранице
Добавить
Мастер
изолированную
запроса сертификата/Типы
оснастку (Add Standalone
snap-in)
(Certificates
нажмите Закрыть
Request
Wizard/Certificate
(Close). Types) в списке Типы сертификатов (Certificate types) выберите тип Агент
подачи
В окне
заявок
Добавить/удалить
(Enrollment Agent).
оснастку (Add/Remove snap-in) нажмите OK.
Сохраните настройки консоли
Примечание. Для обеспечения на рабочем столе (Консоль
защиты Сертификатов).
от несанкционированного издания
сертификатов на сертификат агента подачи заявок устанавливается пароль. Для
Получение сертификата агента получения заявок
этого установите опции Дополнительно (Advanced) и только после этого нажмите
Далее (Next).«Консоль сертификатов».
Запустите
В дереве консоли разверните Сертификаты — текущий пользователь (Certificates —
Current User).
Щелкните правой кнопкой мыши на папку Личные (Personal), выберите Все задачи (All
tasks) и щелкните на пункт меню Запросить новый сертификат (Request New Certificate).
В следующем окне установите опцию Включить усиленную защиту закрытого ключа

(Enable strong private key protection) и нажмите Далее (Next).
На первой странице мастера запроса сертификатов нажмите Далее (Next).
302 301
На странице Мастер запроса сертификата/Понятные имя и описание для сертификата

(Certificates Request Wizard/Certificate Friendly Name and Description) введите желаемое
название сертификата и его описание. Нажмите Далее (Next).
На странице Мастер запроса сертификата/Завершение работы мастера запроса сер-

тификатов (Certificates Request Wizard/Completing the Certificate Request Wizard) проверьте
выбранные параметры сертификата. Если вам необходимо внести какие-либо изме
303
нения, нажмите Назад (Back). Для того чтобы сформировать запрос на выдачу сертификата,
нажмите Готово (Finish).
Если вы активизировали защиту закрытого ключа сертификата агента подачи заявок,

появится окно Создание нового ключа подписи RSA (Creating a new RSA signature key).
Нажмите на кнопку Уровень безопасности... (Set Security Level).
Выберите опцию Высокий (High) и нажмите Далее (Next).
304
Введите пароль, который необходимо будет вводить при использовании данного сер-
тификата. Нажмите Готово (Finish).
Появится окно Создание нового ключа подписи RSA (Creating a new RSA signature key)c
информацией о том, что установлен высокий уровень безопасности. Нажмите OK.
При успешном завершении процесса издания сертификата на экране появится окно с

сообщением: Запрос на сертификат выдан успешно (The certificate request was successful).
305
Издание сертификатов с помощью агента получения заявок

Для дальнейшего выполнения лабораторной работы выпишите сертификаты для
пользователя «Аётш_»Инициалы вашего имени и фамилии» c помощью агента получения
заявок, используя шаблоны:
— Aladdin Smartcard User;
— Aladdin Smartcard Logon.
Для того чтобы подать заявку на сертификат пользователя, получить сертификат и за-
писать его в память eToken, следуйте приведенной ниже инструкции:
Подсоедините eToken, на который вы хотите поместить сертификат. Используйте
программу «eToken Properties», чтобы убедиться, что вы подсоединили нужный ключ.
Запустите Microsoft Internet Explorer.
На домашней странице веб-узла службы сертификации http://server.northwind.ru/certsrv
нажмите на гиперссылку Request a certificate (Запросить сертификат).
На странице Request a Certificate (Запросить сертификат) нажмите на гиперссылку

advanced certificate request (расширенный запрос сертификата).
306
Нажмите Request a certificate for a smart card on behalf of another user by using the smart
card certificate enrollment station (Запросить сертификат смарт-карты пользователя, ис-
пользуя сертификат агента подачи заявок).
При открытии следующей страницы подтвердите, что вы не возражаете против установки

на вашу машину ActiveX компонентов. Нажмите Yes (Да).
Введите пароль к сертификату агента подачи заявок и нажмите OK.
307
На странице Smart Card Certificate Enrollment Station в списке Certificate Template

(Шаблон сертификата) выберите шаблон Aladdin Smartcard User. В поле Administrator
Signing Certificate выберите ваш сертификат агента подачи заявок (если вы выберете его еще
раз, от вас снова потребуется ввести его пароль). Нажмите Select User (Выбрать
пользователя) для выбора пользователя, которому вы собираетесь выписать сертификат.
Введите имя пользователя, для которого вы хотите издать сертификат. Нажмите кнопку
Проверить имена, чтобы убедиться, что вы правильно набрали имя.
308
Выберите вашего пользователя и нажмите OK.
После выбора пользователя на странице Smart Card Certificate Enrollment Station по-
явится кнопка Enroll (Записать).
Убедитесь в том, что в списке Certification Authority (Центр Сертификации) выбран

верный Центр сертификации.
Если все поля заполнены верно, нажмите Enroll (Записать).
В процессе издания сертификата у вас будет запрашиваться PIN-код вашего eToken,
введите его.
309
В случае успешного издания сертификата и записи его в память 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
Издание сертификатов без помощи агента получения заявок

Для дальнейшего выполнения лабораторной работы выпишите сертификат для поль-
зователя «и8ег_»Инициалы вашего имени и фамилии» без помощи агента получения заявок,
используя шаблон Aladdin Exchange Sign & Encrypt.
Для того чтобы подать заявку на сертификат пользователя, получить сертификат и за-
писать его в память eToken, следуйте приведенной ниже инструкции:
На домашней странице веб-узла службы сертификации http://server.northwind.ru/certsrv
нажмите Request a certificate (Запросить сертификат).
На странице Request a Certificate (Запрос сертификата) нажмите advanced certificate
request (расширенный запрос сертификата).
Нажмите Create and submit a request to this CA (Создать и представить на рассмотрение
запрос к ЦС).
В разделе Certificate Template (Шаблон Сертификата) выберите шаблон Aladdin Exchange
Sign & Encrypt. В поле Name (Имя) укажите имя пользователя, для которого вы выписываете
сертификат, а в поле E-mail укажите его E-mail адрес.
В разделе Key Options (Настройки Ключа) все параметры оставьте без изменений:
Р+р _____________________________________________________________________________________
&<'*** Out* * '4*4 ■ РГ и
■ I h f c m d t brhvx+d 1 1
-'I■ t \ C —'
Г■
K*] bi¥ 1Ш* ааи1*1Л1Ш1
fcrr caiwnr TrWTW OVHI itmjpid b b - J i p n "рпт
Г^!4 'jrf Ьгзг li 'H □ СЧЙЬ Ч-/Ч НЧП k + r

П БЬлт n Ihv L>: w r.r 11 | J"
glrMj гЛ* СЙЦКЮЛ I*»k*ш riVFgxi *■' Wf
лпи dm IA*JIVI niftACiW paw f.v+i nr
iWjf.'.VnriCA^cKlicjli Vot-.TVje1 r# ял M±WW.-met
Ач ртсж ir u и ■ m nS* UTJJ
311
В разделе Additional Options (Дополнительные настройки) в поле Friendly Name (Ото-

бражаемое имя) укажите назначение сертификата (например, Exchange avorontsov — сер-
тификат пользователя avorontsov для использования с программой Exchange) и нажмите
Submit (Подтвердить).
A d jfldg fr.il OfldwMe_______________________________________________________________________________

Rйф1*нРйпп*и ®CWC OPKCS1Q
HiShAlgflrdhni SHA1 *
oietf to Atgo nfflirfif
□Saw requetf to a file
Allnbylei
Ftêntfiif Narne EiccNa^ge
5ulimfi >
На странице Potential Scripting Violation (Возможное нарушение выполнения сценария)

нажмите Да (Yes).
В случае успешного издания сертификата появится окно с сообщением The certificate you
requested was issued to you (Запрашиваемый вами сертификат был для вас выписан).
Нажмите Install this certificate (Установить этот сертификат).
312
На странице Potential Scripting Violation (Возможное нарушение выполнения сценария)

В случае успешной записи сертификата в локальное хранилище данного компьютера

появится окно Certificate Installed (Сертификат установлен).
Копирование сертификата с закрытым ключом на eToken

Для дальнейшего выполнения лабораторной работы произведите импорт сертификата
для шифрования и цифровой подписи электронной почты пользователя «User_» Инициалы
вашего имени и фамилии» на eToken «User «Ваша фамилия». При импорте не удаляйте
оригинальный сертификат с закрытым ключом, он необходим для последующего
выполнения лабораторной работы.
Для того чтобы скопировать сертификат с закрытым ключом на eToken, следуйте
приведенной ниже инструкции:
Подсоедините eToken, на который вы хотите поместить сертификат. Используйте
программу eToken Properties (Свойства eToken), чтобы убедится, что вы подсоединили
необходимый ключ.
313
Запустите утилиту «Свойства eToken». Нажмите Пуск ^ Программы ^ eToken ^ eToken

Properties (Start ^ Programs ^ eToken ^ eToken Properties).
В окне утилиты «Свойства eToken» выберите нужное устройство eToken. Перейдите в
расширенный режим, нажав кнопку Дополнительно. Введите PIN-код eToken и нажмите OK.
Выберите вкладку Сертификаты и ключи и нажмите кнопку Импортировать сертификат.
314
Выберите Хранилище личных сертификатов

Регистрация в доменевскачестве
помощью источника
eTokenсертификата. Нажмите
OK.
Для того чтобы зарегистрироваться в домене с помощью eToken, выполните следующее:
После появления окна Операционная система Windows подключите eToken.
Примечание. Утилита Свойства eToken позволяет также импортировать сер-

тификаты, хранящиеся в файлах #PKCS12 (pfx).
В окне Импорт сертификата выберите сертификат, который вы хотите импортировать на
eToken, и нажмите Записать.
В окне Вход в Windows (Log on to Windows) в поле PIN-код (PIN) введите PIN-код.
Нажмите OK.
Установка Рекомендуется
для пользователя удалять
требования оригинальный
использования сертификат
смарт-карты прис ключом после его
импорта на eToken.
интерактивном подсоединении к компьютеру
В случае
Для успешного
того чтобы импорта
разрешить сертификата
регистрацию напоявится сообщение
компьютере только сИмпорт осуществлен
использованием смарт-
успешно.
карт, Нажмите
выполните ОК.
следующее:
Откройте Active Directory — пользователи и компьютеры (Active Directory — users and
computers).
В дереве консоли откройте директорию Users.
Дважды щелкните по учетной записи пользователя в списке, которому вы хотите ус-
тановить данное требование.
В окне учетной записи пользователя откройте вкладку Учетная запись (Account).
В списке Параметры учетной записи (Account options) установите флажок Для инте-
рактивного входа в сеть нужна смарт-карта (Smart card is required for interactive logon).
316 315
Нажмите OK.
Чтобы внесенные изменения начали действовать немедленно, выполните на контр-
Установка групповой политики требования использования смарт-карты при
интерактивном подсоединении к компьютеру
Для того чтобы установить требование использования смарт-карт при интерактивном
подсоединении к компьютеру на все компьютеры, которые входят в домен, выполните
Запустите программу Политика безопасности домена (Domain Security Policy), нажав Пуск
^ Программы ^ Администрирование (Start ^ Programs ^ Administrative Tools).
Перейдите в папку Параметры безопасности ^ Локальные политики ^ Параметры
безопасности (Security Settings ^ Local Policies ^ Security options). Установите параметр
Interactive logon: Require smart card в соответствии с рисунком.
Установите флажок Определить следующий параметр политики (Define this policy
setting).
Выберите Включен (Enabled).
317
Если вы хотите, чтобы обновленная политика начала действовать немедленно, введите

на контроллере домена команду 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
Запуск приложений от имени другого пользователя

Использование графического интерфейса
Для того чтобы запустить приложение от имени другого пользователя с использованием
графического интерфейса, выполните следующее:
Подсоедините eToken с сертификатом пользователя, от имени которого вы хотите за-
пустить приложение.
Щелкните правой кнопкой мыши по значку программы, которую вы хотите запустить
(например, «Локальная политика безопасности») и выберите Запуск от имени (Run as).
В окне Запуск от имени другого пользователя (Run As) выберите Учетная запись ука-
занного пользователя (The following user). Из списка Пользователь (User name) выберите
сертификат пользователя, под которым вы хотите запустить приложение.
В поле ГШ-код(РШ) введите PIN-код eToken, на котором находится данный сертификат.

Нажмите OK.
319
Использование командной строки

Для того чтобы запустить приложение от имени другого пользователя, при исполь-
зовании интерфейса командной строки, выполните следующее:
Подключите 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@northwind.ru).
Выберите номер устройства чтения для использования 'Пользователь со смарт-картой:
Введите номер устройства:
3
Введите PIN-код соответствующего eToken. Если вы предоставили сертификат поль-
зователя, который обладает правами для запуска данной программы, то эта программа
запустится в новом окне.
Используется карта в устройстве 3. Введите PIN-код:
Попытка запуска chkdsk от имени пользователя «Administrator — DS Root» ...
320
Подключение сетевых дисков

с использованием прав доступа другого пользователя
Использование графического интерфейса
Для того чтобы подключить сетевой диск, используя права другого пользователя, с
использованием графического интерфейса, выполните следующее:
Подключите eToken с сертификатом пользователя, обладающего необходимыми пра-
вами доступа, которые вы хотите использовать для подсоединения сетевого диска.
Запустите «Проводник» (нажмите на Пуск (Start) правой кнопкой мыши). Из меню Сервис
(Tools) выберите Подключить сетевой диск... (Map Network Drive...).
Введите в поле Диск () имя диска (например, Z:), которое вы хотите назначить под-
ключаемому ресурсу, а в поле Папка () полное имя ресурса, который вы хотите подсоединить
(например — «\\server\c$») и нажмите Готово.
Если имеющихся прав у текущего пользователя недостаточно для доступа к данному

ресурсу, появится окно, предлагающее предоставить регистрационные данные другого
пользователя, обладающего необходимыми правами.
321
Из списка Пользователь (User name) выберите сертификат пользователя, обладающего

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

операционная система найдет несколько eToken с сертификатами, предназначенными для
входа в сеть по смарт-карте (Smart Card Logon), будет выведен список соответствующих
устройств с указанием имен пользователя.
В поле PIN-код (PIN) введите PIN-код eToken, на котором находится данный сертификат, и
— Для
нажмите каждого устройства, в котором Windows не обнаружит eToken, будет выведено
OK.
сообщение об ошибке Нет карты в устройстве чтения 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>
Подключите eToken с сертификатом пользователя, обладающего необходимыми пра-
вами доступа, которыеДанный дискиспользовать
вы хотите отключаетсядля для подсоединения
удобства проведения практических
сетевого диска.
работ.
В командной строке введите net use <имя диска> <имя ресурса> /sm (например, имя
диска — Z:, а имя ресурса — \\ca\c$):
C:\Documents and Settings\avorontsov>net use Z: \\server\c$ /sm
322 323
В отчете с титульным листом установленной формы (Приложение А) необходимо
4. Выполненные настройки Центра сертификации, шаблоны сертификатов, созданные в
ходе выполнения лабораторной работы.
5. Подготовиться для устных ответов по контрольным вопросам.
1. Какие дополнительные средства (утилиты) необходимо установить для того, чтобы
подготовить к работе Центр сертификации?
2. Какие поля можно задавать в шаблоне сертификата?
3. Как издать сертификаты без помощи агента получения заявок?
4. Каким образом можно скопировать сертификат в память ключа eToken?
5. Как можно выполнить запуск приложений от имени другого пользователя с исполь-
зованием командной строки?
(образец)


УСТАНОВКА И НАСТРОЙКА ЦЕНТРА СЕРТИФИКАЦИИ,

ИСПОЛЬЗОВАНИЕ КЛЮЧЕЙ eToken В ДОМЕНЕ
WINDOWS SERVER 2003

Выполнили:
(Ф.И.О.)
(Ф.И.О.)
Принял:
(Ф.И.О)
(год)
325
ИСПОЛЬЗОВАНИЕ eToken
ДЛЯ БЕЗОПАСНОГО ДОСТУПА
К ИНФОРМАЦИОННЫМ РЕСУРСАМ,
ДЛЯ ШИФРОВАНИЯ И ДЛЯ ЭЦП
Изучить возможности использования ключей eToken для безопасного доступа к ин-
формационным ресурсам организации, для шифрования информации и для ЭЦП в при-
ложениях MS Office.
Общие сведения о безопасном доступе

к информационным ресурсам организации
Удаленный доступ к рабочему столу (RDP)

В Windows XP существует возможность выполнять аутентификацию пользователей по
ключу eToken при входе в систему терминального клиента. Аутентификация производится с
помощью цифрового сертификата X.509, хранящегося в памяти ключа, точно так же, как если
бы пользователь физически находился за данной рабочей станциеи. В предыдущих
лабораторных работах по теме «Обеспечение безопасности доступа к данным
информационной системы организации с использованием продуктов Microsoft и Aladdin.
Типовые решения» такие сертификаты уже использовались при регистрации пользователя в
домене Windows Server 2003, при запуске приложений и для доступа к сетевым дискам от
имени другого пользователя.
Помимо аутентификации при терминальном подключении все приложения, работающие
со смарт-картами, к которым пользователь обращается в течение сеанса, могут использовать
ключ eToken.
Для того чтобы пользователи имели доступ к рабочему столу, необходимо предоставить
им такую возможность средствами ОС Windows. Программа «Подключение к удаленному
рабочему столу» позволяет с легкостью подключаться к серверу терминалов или другому
компьютеру, работающему под управлением Windows. При необходимости имеется
возможность указать параметры каждого подключения и сохранить их в файле для
последующего использования.
По умолчанию удаленный доступ к рабочему столу предоставляется администраторам.
Чтобы обычные пользователи могли также подключаться к рабочему столу, необходимо
предоставить им соответствующие права. Кроме того, можно предоставить пользователю
право удаленно подключаться к контроллеру домена.
Виртуальные частные сети (VPN)

При развертывании PKI в основу использования виртуальной частной сети (Virtual
Private Network, VPN) положен протокол расширенной аутентификации (Extensible
Authentication Protocol, EAP). Подключаться к сети через VPN-соединения могут только те
пользователи, учетные записи которых настроены для таких подключений. Возмож-
326
ность подключения пользователей к корпоративным серверам через VPN-соединения

задается настройками сервера. Кроме сервера и учетной записи пользователя необходимо
также соответствующим образом настроить рабочую станцию — установить сертификат ЦС,
а также создать и настроить VPN-соединение.
Общие сведения о протоколе EAP
Для проверки подлинности подключений виртуальных частных сетей (VPN), под-
держивающих протокол PPTP или L2TP, применяются методы проверки на уровне
пользователей, основанные на протоколе PPP. К этим методам относятся протоколы:
— Password Authentication Protocol (PAP);
— Challenge Handshake Authentication Protocol (CHAP);
— Shiva Password Authentication Protocol (SPAP);
— Microsoft Challenge Authentication Protocol (MS-CHAP);
— Extensible Authentication Protocol (EAP).
Благодаря новым возможностям, предлагаемым протоколами EAP и IPSec (Internet
Protocol security), виртуальные частные сети обеспечивают повышенную безопасность для
удаленных пользователей.
Протокол EAP является расширением протокола Point-to-Point Protocol (PPP). На нем
основаны несколько методов проверки подлинности, предусматривающих обмен учетными
записями и прочими сведениями произвольного объема. Протокол EAP был разработан с
учетом растущей потребности в средствах проверки подлинности, использующих более
широкий круг устройств системы безопасности; он предлагает стандартную архитектуру для
поддержки дополнительных методов проверки подлинности в рамках PPP.
С помощью EAP можно реализовать поддержку нескольких алгоритмов проверки
подлинности — так называемых типов EAP, к числу которых относятся:
— генераторы кода доступа:
— одноразовые пароли;
— средства проверки подлинности на основе открытых ключей с помощью смарт-карт,
сертификатов и др.
Сочетание протокола со строгими типами является ключевым компонентом технологии
безопасных подключений виртуальных частных сетей (VPN). Например, строгие типы EAP,
основанные на сертификатах, обеспечивают более надежную защиту от попыток «грубого»
взлома системы или подбора пароля, чем другие протоколы проверки подлинности,
использующие пароли, такие как CHAP и MS-CHAP.
Операционная система Windows XP включает поддержку двух типов EAP:
— EAP-MD5 CHAP (аналог протокола проверки подлинности CHAP);
— EAP-TLS (применяется для проверки подлинности на основе сертификатов поль-
зователей).
EAP-TLS — это метод взаимной проверки подлинности, при котором и клиент, и сервер
должны предоставлять доказательства своей подлинности. В ходе сеанса EAP-TLS клиент
удаленного доступа отправляет свой сертификат пользователя, а сервер удаленного доступа
— свой сертификат компьютера. Если хотя бы один из этих сертификатов не будет передан
или окажется недействительным, подключение разрывается.
Защищенное подключение к Web-серверу (HTTPS)
Для исключения несанкционированного доступа к веб-северу используется защищенный
протокол HTTPS. Рекомендуется создать новый защищенный веб-сервер и для исключения
несанкционированного доступа к такому серверу рекомендуется максимально ограничить
возможности аутентификации пользователя, исключив анонимную
327
аутентификацию, а также другие стандартные способы аутентификации. При работе с

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

Microsoft Office 2003 использует технологию Microsoft Authenticode, позволяющую
снабжать электронные документы (файлы) электронной цифровой подписью (ЭЦП).
Электронная цифровая подпись представляет собой зашифрованную с помощью за-
крытого ключа автора контрольную сумму электронного документа. Для вычисления
контрольной суммы используется известный автору и адресату алгоритм (хэш-функция). Для
того, чтобы проверить электронную цифровую подпись, используется открытый ключ автора
документа. Открытый ключ автора содержится в сертификате ключа подписи и
распространяется вместе с ним. Такой механизм позволяет, с одной стороны, проверить
целостность электронного документа, а с другой — удостоверить его авторство.
Для проверки электронной цифровой подписи пользователь должен иметь действующий
сертификат (формата X.509) отправителя. Поэтому при отправке подписанного сообщения
адресату передается его электронная цифровая подпись, а также, как правило, сертификат
ключа подписи автора.
При успешной проверке электронной цифровой подписи адресат подтверждает, что
документ был получен от владельца сертификата ключа подписи (автора) и документ не был
изменен.
Microsoft Office 2003 позволяет создавать ЭЦП в документах, создаваемых с помощью
приложений: Word 2003, Excel 2003, Power Point 2003.
Для изучения возможностей использования ключей eToken для безопасного доступа к
информационным ресурсам организации, для шифрования информации и для ЭЦП в
приложениях MS Office работа делится на четыре части:
• удаленный доступ к рабочему столу с использованием eToken (RDP);
• настройка виртуальной частной сети (VPN);
• создание защищенного веб-сервера и настройка доступа по HTTPS;
• использование шифрования и ЭЦП в приложениях MS Office.
Удаленный доступ к рабочему столу с использованием eToken

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

• Настроить подключение к удаленному компьютеру с помощью eToken.
• Предоставить обычным пользователям возможность удаленного доступа к компью-
теру.
• Предоставить пользователям права Log on through Terminal Services на контроллере
домена.
• Проверить удаленный доступ к рабочему столу сервера с рабочей станции.
Настройка виртуальной частной сети

Данная часть работы предназначена для настройки сервера маршрутизации с исполь-
зованием протокола EAP, а также для настройки учетной записи пользователя для ис-
пользования VPN-соединений на примере организации удаленного доступа пользователей к
рабочему столу (RDP).
• Настроить сервер маршрутизации и удаленного доступа.
• Настроить учетную запись пользователя для использования VPN-соединений.
• Установить сертификат Центра сертификации на рабочую станцию.
• Создать VPN-соединение на рабочей станции.
• Настроить параметры VPN-соединения на рабочей станции.
• Установить VPN-соединение.
• Проверить сведения об установленном VPN-соединении.
Создание защищенного веб-сервера

и настройка доступа по HTTPS
Данная часть работы предназначена для создания дополнительного защищенного веб-
сервера, настройке подключения к защищенному веб-серверу с использованием протокола
HTTPS и проверке доступа к защищенному веб-сайту, созданному на защищенном веб-
сервере.
• Создать дополнительный защищенный веб-сервер.
• Настроить подключение к новому веб-серверу по протоколу HTTPS.
• Создать DNS-имя для нового веб-сервера.
• Настроить рабочую станцию.
• Настроить сетевые подключения на хосте.
• Настроить файл hosts на хосте.
• Проверить доступ к веб-сайту по HTTPS.
Использование шифрования и ЭЦП в приложениях MS Office

Данная часть работы предназначена для настройки использования электронной циф-
ровой подписи (ЭЦП) в приложениях MS Word 2003 и MS Outlook 2003, а также для защиты
электронных сообщений при использовании технологии Outlook Web Access.
329

• Создать ЭЦП в MS Word 2003.
• Проверить работу с ЭЦП в MS Word 2003.
• Настроить MS Outlook 2003 для шифрования и ЭЦП сообщений.
• Настроить MS Outlook 2003 для нового пользователя.
• Настроить параметры MS Outlook 2003 для шифрования и ЭЦП сообщений.
• Настроить Outlook Web Access для шифрования и ЭЦП сообщений.
• Проверить использование MS Outlook 2003 для защиты сообщений электронной
почты.
• Создать сообщения с ЭЦП.
• Создать зашифрованное сообщение.
• Открыть зашифрованные сообщения.
• Проверить ЭЦП в сообщении.
Задание
2. Настроить стенд, рабочую станцию и контроллер домена.
3. Установить и настроить защищенный веб-сервер.
4. Настроить и проверить удаленный доступ к рабочему столу с использованием eToken.
5. Настроить и проверить работу виртуальной частной сети с использованием eToken.
6. Создать защищенный веб-сервер и настроить доступ по протоколу HTTPS.
7. Настроить и проверить использование шифрования и ЭЦП в MS Word 2003 и в MS
Outlook 2003.

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

Для того чтобы администраторам предоставить возможность удаленного доступа к
компьютеру, выполните следующие действия:
Подсоединитесь к компьютеру VM WS пользователем с правами администратора.
Запустите Пуск ^ Панель управления ^ Система (Start ^ Control Panel ^ System). В окне
Свойства системы (System Properties) откройте вкладку Удаленные сеансы (Remote).
Установите флажок Разрешить удаленный доступ к этому компьютеру (Allow users to connect
remotely to this computer). Нажмите OK.
330
При появлении окна Удаленные сеансы (Remote Sessions) нажмите OK.
Предоставьте администраторам, зарегистрированным при выполнении предыдущих

Настройка
лабораторных работ, подключения
возможность удаленногокдоступа
удаленному компьютеру
к VM SRV.
с использованием eToken
На VM SRV закройте все программы и выйдите из системы.
Настройка
Для тогоконтроллера домена
чтобы настроить удаленное подключение к удаленному компьютеру, выполните
Подсоединитесь к компьютеру VM WS пользователем с правами администратора.
Запустите
Запустите ПускПодключение к удаленному
^ Панель управления рабочему
^ Система столу (Remote
(Start ^ Control DesktopВ окне
Panel ^ System). Connection),
Свойства системы (System Properties) откройте вкладку Удаленное использование (Remote).^
нажав Пуск ^ Все программы ^ Стандартные ^ Связь (Start ^ Programs ^ Accessories
Communications).
Установите флажок Разрешить удаленный доступ к этому компьютеру (Allow users to connect
В окне
remotely to Подключение
this computer).кНажмите
удаленному
OK. рабочему столу (Remote Desktop Connection) в поле
Компьютер (Computer) введите IP-адрес или DNS имя компьютера, к которому вы на-
страиваете подключение.
Нажмите Параметры (Options).

Откройте вкладку Локальные ресурсы (Local Resources). Установите флажок смарт-карты
(Smart cards).
332 331
Перейдите на закладку Общие (General). Введите IP-адрес машины, для которой

создается подключение (для сервера VW SRV задайте IP-адрес 192.168.1.145). Нажмите
Сохранить как (Save As), сохраните настроенное подключение на рабочем столе хоста
(например, под именем CA.rdp).
Подключите eToken с сертификатом пользователя «Admin»_» Инициалы вашего имени и

фамилии».
Для подключения к удаленному рабочему столу нажмите Подключить (Connect).
Если на удаленном компьютере открыт сеанс пользователя, то для подключения к
удаленному рабочему столу необходимо его завершить. Для этого в окне предупреждения
333
В окне Пользователи удаленного рабочего стола (Remote Desktop Users), используя

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

RDP-подключение (дважды щелкните мышкой на файл CA.rdp).
Примечание. В окне Вход в Windows (Log on to Windows) в поле PIN-код (PIN)
введите PIN-код.
После установления удаленного подсоединения к рабочему столу сервера CA завершите
его (Пуск ^ Завершение работы (Start ^ Log Off)).
Подключите eToken с сертификатом пользователя «User»_» Инициалы вашего имени и
фамилии». Попытайтесь подсоединиться к удаленному рабочему столу, используя созданное
вами RDP-подключение.
Предоставление обычным пользователям

возможности удаленного доступа к компьютеру
Для того чтобы обычным пользователям предоставить возможность удаленного доступа
к компьютеру, выполните следующие действия:
Подсоединитесь к компьютеру пользователем с правами администратора.
Откройте Пуск ^ Панель управления ^ Система (Start ^ Control Panel ^ System).
В окне Свойства системы (System Properties) откройте вкладку Удаленное использование
(Remote).
Установите флажок Разрешить удаленный доступ к этому компьютеру (Allow users to
connect remotely to this computer). Для того, чтобы к компьютеру могли подключаться
пользователи, не имеющие полномочий локального администратора, нажмите Выбрать
удаленных При предоставлении
пользователей удаленного доступа к компьютеру пользова-
(Select remote Users).
тель автоматически добавляется в локальную группу Remote Desktop Users. Если уда-
ленный доступ предоставляется к контролеру домена, то пользователь добавляется
в доменную группу Remote Desktop Users.
Закройте окно Свойства системы (System Properties), нажав OK.
Предоставление пользователю права

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) и нажмите OK.
334 335
Чтобы внесенные изменения начали действовать немедленно, выполните на контр-

Подключите eToken с сертификатом пользователя «ивег»_»Инициалы вашего имени и
фамилии». Попытайтесь подсоединиться к удаленному рабочему столу, используя созданное
вами 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
В окне приветствия мастера нажмите Далее (Next).
В окне Конфигурация (Configuration) выберите опцию Удаленный доступ (VPN или

модем) (Remote access (dial-up or VPN)) и нажмите Далее (Next).
337
В окне Удаленный доступ (Remote Access) установите флажок Доступ к виртуальной

частной сети (VPN) (VPN) и нажмите Далее (Next).
В окне Соединение по VPN (VPN Connection) выберите сетевой интерфейс Internet, к

которому будут подключаться удаленные компьютеры для установления VPN-соединений.
Установите флажок Безопасность с использованием фильтров статических пакетов
338
(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-адресов
DHCP сервером;
— Из заданного диапазона адресов (From a specified range of addresses) — для того
чтобы задать один или несколько диапазонов адресов вручную.
В окне Назначение диапазонов IP-адресов (Address Range Assignment) нажмите Создать
(New), чтобы ввести диапазон IP-адресов.
339
В окне Новый диапазон адресов (New Address Range) в поле Начальный IP-адрес (Start
IP address) введите первый адрес диапазона (192.168.1.201), а в поле Конечный IP-адрес (End
IP address) — последний (192.168.1.205). Нажмите OK.
Примечание. Общее число адресов должно быть не менее чем на 1 больше необ-
ходимого числа VPN-подключений к данному серверу.
В окне Назначение диапазонов IP-адресов (Address Range Assignment) нажмите Далее
(Next).
Для завершения работы мастера нажмите Готово (Finish).
МаМ 1 |l' f- Ч.Г* I Ч~|ЬПГ||!|'| I I I ,1Ш||-Г I i'lili;---- ■■ г,1| .1ПЧ" ■" -.4 II Д1П I VIM
^янршение работы •i4-dcifi.ii л- наа и мм

сервера H-i|iwpviii-i*iiHH и удалеинйГй
шипуна
Усяеимз- ^лмршйиа рлсот а мастера серкс-а
Г№ ■
г. -1ЦЫ1.5Я Vpfl душ яцж дш»1 К.Я11ТЧГП- □

ГЛ-Д £(Ч11J
ЧГМШР ^-t»fTu tlQfi-fcinaV 'Кг+ЭТь-С-з Н$йОЩрВД

iX-fcffii ■r-el'Tiejr unm ПфПьШЬаТ«№! !ia *im йШШ
I -MV**«:* н iu «4.*> DДО!$£ Д|?ПФЙМ*Л*«&
NJTi■;-*■: CM p 1} 1.Гn -.
ДП» lirpbnvra Н«*гга МЛ-ÎTB "wrp.y 1СФС4Н>

В окне Управление несколькими серверами удаленного доступа (Managing Multiple
Remote Access Servers) выберите опцию Нет, не использовать маршрутизацию и удаленный
доступ для проверки подлинности запросов на подключение (No, use Routing and Remote
Access to authenticate connection requests) и нажмите Далее (Next).
340 341
В окне Маршрутизация и удаленный доступ (Routing and Remote Access) нажмите OK.
Примечание. Для применения заданных параметров операционной системе Windows

Server 2003 потребуется некоторое время.
В дереве консоли выберите сервер, щелкните правой кнопкой мыши и нажмите Свойства
(Properties).
В окне свойств сервера откройте вкладку Общие (General). Установите опцию Марш-
рутизатор (Router) и выберите Только локальной сети (Local area network (LAN) routing only),
а также опцию Сервер удаленного доступа (Remote access server).
342
Откройте вкладку Безопасность (Security). Нажмите Методы проверки подлинности

(Authentication Methods).
Примечание. Из протоколов, которые вы можете выбрать в окне Методы про-

верки подлинности (Authentication Methods), только EAP поддерживает проверку
подлинности с использованием смарт-карт. Для того чтобы пользователи могли при
обращении к серверу идентифицировать себя только с помощью eToken, из всех про-
токолов оставляется только EAP.
В окне Методы проверки подлинности (Authentication Methods) нажмите OK.
На остальных
В окне Методызакладках оставьте
проверки параметры
подлинности по умолчанию.
(Authentication В окне свойств
Methods) снимитесервера
все флажки,
нажмите OK.
кроме Протокол расширенной проверки подлинности (EAP) (Extensible Authentication
При появлении окна с сообщением о необходимости перезагрузки маршрутизатора
Protocol).
Закройте административную консоль Маршрутизация и удаленный доступ (Routing and

Remote Access).
Настройка учетной записи пользователя

для возможности использования VPN-соединений
Для выполнения дальнейшей части лабораторной работы необходимо предоставить
пользователю <АЛтт»_»Инициалы вашего имени и фамилии» возможность подключаться с
использованием VPN-соединений. Для того чтобы предоставить пользователю возможность
подключаться с использованием VPN-соединений, выполните следующие действия:
Нажмите Методы EAP (EAP Methods). В окне Методы EAP (EAP Methods) убедитесь в
Запустите программу Active Directory — Пользователи и компьютеры (Users and Computers).
том, что в списке Методы (Methods) присутствует строка Smart Card or other certificate.
Нажмите OK.
344 343
Выберите пользователя, которому вы хотите предоставить возможность подсоединяться

через VPN-соединения, и, используя правую кнопку мыши, перейдите к его свойствам.
В окне свойств учетной записи откройте вкладку Входящие звонки (Dial-In). В разделе
Разрешение на удаленный доступ (VPN-модем) (Remote Access Permission (Dial-in or VPN))
установите опцию Разрешить доступ (Allow access) и нажмите OK.
Примечание. Эта вкладка отсутствует при настройке с рабочей станции.

345

Для того чтобы подготовить рабочую станцию для использования VPN-соединений,
необходимо установить на ней сертификат Центра сертификации.
Установка сертификата Центра сертификации на рабочую станцию
Для того чтобы установить сертификат Центра сертификации на рабочую станцию,
выполните следующие действия:
Скопируйте сертификат ЦС на рабочий стол станции.
Примечание. Сертификат Центра сертификации находится в корне диска C:
сервера, на котором установлен Центр сертификации.
На рабочем столе хоста выполните щелчок правой кнопкой мыши на сертификате ЦС и
выберите команду Установить сертификат (Install Certificate).
В окне приветствия мастера импорта сертификатов нажмите Далее (Next).
346
При появлении сообщения с предложением добавить сертификат в корневое хранилище

После окончания процесса импорта появится окно с сообщением «Импорт успешно
выполнен». Нажмите OK.
Создание VPN-соединения на рабочей станции

Для того чтобы на рабочей станции настроить VPN-соединение к серверу ЦС, выполните
На рабочей станции откройте Панель управления (Control Panel).
Если вы используете вид панели управления по категориям, выберите Сеть и Под-
ключения к Интернету (Network and Internet Connections).
Выберите Сетевые подключения (Network Connections).
347
Нажмите Создание нового подключения (Create a new connection), чтобы запустить

мастер новых подключений.
В первом окне мастера новых подключений нажмите Далее (Next).
В окне Тип сетевого подключения (New Connection Type) выберите Подключить к сети
на рабочем месте (Connect to the network at my workplace) и нажмите Далее (Next).
В окне Сетевое подключение (Network Connection) выберите Подключение к вирту-

альной частной сети (Virtual private network connection) и нажмите Далее (Next).
348
В окне Имя подключения (Connection Name) введите имя создаваемого подключения
(VM SRV Internal LAN) и нажмите Далее (Next).
В окне Публичная сеть (Public Network) выберите Не набирать номер для предвари-
тельного подключения (Do not dial the initial connection) и нажмите Далее (Next).
349
В окне Выбор VPN-сервера (VPN Server Selection) введите IP-адрес сервера (в соот-
ветствии с настройками сервера — 192.168.73.145) и нажмите Далее (Next).
В окне Смарт-карты (Smart Cards) выберите Использовать мою смарт-карту (Use my

smart card) и нажмите Далее (Next).
350
В окне Доступность подключения (Connection Availability) выберите только для меня (My
use only) и нажмите Далее (Next).
Для завершения работы мастера нажмите Готово (Finish).
351
Примечание. По завершении работы мастера настройки система автоматиче-

ски запустит данное соединение. Нажмите Отмена (Cancel) для того, чтобы про-
извести настройку параметров данного VPN-соединения.
Настройка параметров VPN-соединения на рабочей станции
Созданное подключение в данный момент не позволяет подключиться к серверу, по-
скольку не определены параметры входа в сеть. Для того чтобы на рабочей станции на-
строить параметры VPN-соединения, выполните следующие действия:
На рабочей станции откройте Панель управления (Control Panel).
Если вы используете вид панели управления по категориям, выберите Сеть и Под-
Щелкните по значку VPN-соединения правой кнопкой мыши и выберите Свойства
(Properties).
352
В окне свойств
Свойствасоединения
смарт-картыоткройте вкладку
или другого Безопасность
сертификата (Security).
(Smart Card orВыберите опцию
other Certificate
Дополнительные
Properties) (выборочные
в области параметры)
При подключении Advanced
(When (Custom
connecting) settings)
выберите и нажмите мою
использовать Па-
раметры (Settings).
смарт-карту (Use my smart card). Установите флажок Проверка сертификата сервера
(Validate server Certificate). Установите флажок Подключение к серверам (Connect to these
servers) и введите DNS-имя VPN-сервера (server.northwind.ru). В списке Доверенные кор-
невые центры сертификации (Trusted Root Certification Authorities) установите флажок,
соответствующий центру сертификации, присутствующему в пути сертификации серти-
фиката VPN-сервера (DS Root). Нажмите OK.
В окне Дополнительные параметры безопасности (Advanced security settings) установите

значение поля Шифрование данных — обязательное (отключиться если нет шифрования)
(Require encryption (disconnect if server declines)). В обёасти Безопасный вход (Logon
Security) выберите Протокол расширенной проверки подлинности (EAP) (Use Extensible
Authentication Protocol (EAP)) и выберите Смарт-карта или иной сертификат (шифрование
включено) (Smart Card or other Certificate (encryption enabled)). Нажмите Свойства (Properties).
В окне Дополнительные параметры безопасности (Advanced security settings) нажмите

OK.
В окне свойств соединения нажмите OK.
Установка VPN-соединения
Для того чтобы получить доступ к корпоративным ресурсам с помощью VPN-под-
ключения, выполните следующее.
Откройте Панель управления (Control Panel).
Если вы используете вид панели управления по категориям, выберите Сеть и под-
Убедитесь в том, что ваш eToken подключен к компьютеру. На USB-ключе eToken должен
гореть световой индикатор. Для установки VPN-соединения к компьютеру должен быть
подключен только один eToken, содержащий сертификат, предназначенный для входа в сеть
по смарт-карте (Smart Card Logon).
В разделе Виртуальная частная сеть (VPN) (Virtual Private Network) дважды щелкните по
значку соответствующего подключения.
Введите PIN-код.
354 353
Примечание. Данный адаптер включается для обеспечения условий проведения

следующего практического задания.
На хосте создайте и настройте VPN-соединение. Выполните следующие действия:
Зайдите в сетевые свойства, выберите адаптер «...VMnetl», вызовите контекстное меню и
выберите пункт Отключить (Disable);
Перейдите в командную строку (используйте Пуск ^ Выполнить ^ cmd (Start ^ Run ^ cmd);
В командной строке запустите команду ping 192.168.1.145 и ping 192.168.1.2;
Используя созданное вами соединение, подсоединитесь по VPN к VM SRV, используя
сертификат пользователя «Admin»_»Инициалы вашего имени и фамилии»;
В командной строке запустите команду ping 192.168.1.145 и ping 192.168.1.2;
Запустите на хосте «Проводник» и выберите в меню Сервис (Tools) пункт Подключить
сетевой диск... (Map Network Drive). Попытайтесь подсоединиться к папке \\ca\c$
(используйте входное имя и пароль доменного администратора);
Отключитесь от VPN;
На хосте зайдите в сетевые свойства, выберите адаптер ...VMnet1 и через правую кнопку
мыши задайте для него параметр Включить (Enable).
Сведения об установленном VPN-соединении

Для того чтобы получить сведения о параметрах установленного VPN-соединения,
выполните следующее:
Щелкните правой кнопкой мыши по значку установленного соединения и выберите
Состояние (Status).
В окне состояния соединения откройте вкладку Сведения (Details).
355
Создание дополнительного веб-сервера

Для создания дополнительного сервера, работающего по тому же порту, что и основной,
но с другим DNS именем, выполните следующие действия:
Откройте программу System Manager, нажав Пуск ^ Программы ^ Microsoft Exchange
(Start ^ Programs ^ Microsoft Exchange).
Выделите раздел HTTP, открыв Northwind (Exchange) ^ Servers ^ SERVER ^ Protocols.
Нажмите правую клавишу мыши и выберите Создать ^ HTTP Virtual Server (New ^ HTTP
Virtual Server).
356
В окне Свойства (Properties) задайте имя для веб-сервера (например — OWA) и нажмите
кнопку Advanced.
В окне Свойства (Properties) нажмите OK.

Закройте все окна, нажав OK. Закройте программу System Manager.
Настройка подключения к новому веб-серверу по HTTPS

Для настройки подключения к новому веб-серверу по HTTPS выполните следующие
действия:
Запустите программу Диспетчер служб IIS (Internet Information Services (IIS)) Manager,
нажав Пуск ^ Программы ^ Администрирование (Start ^ Programs ^ Administration Tools).
В дереве консоли разверните узел данного сервера, щелкните правой кнопкой мыши
Internet Information Services ^ Server (локальный компьютер) ^ Веб-узлы (Internet Information
Services ^ SERVER (local computer) ^ Web Sites) и выберите Свойства (Properties).
В открывшемся окне выберите существующую запись и нажмите кнопку Modify.
В окне Свойства: Веб-узлы (Web Sites Properties) перейдите на вкладку Безопасность

В открывшемся
каталога окне в поле
(Directory Security). Host name
Установите введите
флажок DNS-имя веб-сервера
Сопоставление (например —
службы каталогов
owa.northwind.ru)
Windows и нажмите
(Enable the WindowsOK. directory service mapper). Нажмите OK.
358 357
В окне Свойства: OWA (OWA Properties) откройте вкладку Веб-узел (Web Site). Назначьте
Появится окно Изменение наследования (Inheritance Overrides). Нажмите Select All, а
веб-сайту порт SSL (например, 443).
потом нажмите OK.
В окне Диспетчер служб IIS (Internet Information Services (IIS) Manager) Выберите новый
веб-сайт (OWA) и перейдите к редактированию его свойств.
360 359
Откройте вкладкуЭто
Примечание. Безопасность каталога
делается для того, (Directory Security).все
чтобы исключить В секции Управление
способы до-
аутентифи-
ступом и проверка
кации подлинности
для доступа (Authentication
к сайту, кроме SSL. and access control) нажмите Изменить (Edit).
В Диспетчер IIS (IIS Manager) окне нажмите Да (Yes).
В разделе Безопасные подключения (Secure Communications) нажмите Сертификат

(Server Certificate), чтобы запустить мастер сертификатов.
CfiOrt I tfi.L _U«i

I triA+pK» jMMfM** 01Г $ I E *ргтгч.«4 гОЕ ]
ОеЙ-#жп J Efecipocfr'icnii^! | i£4H ДШЧШШАВ-ЗР Ли* ь*«лъ*
2-ллуйСг иснимите
В окне Методы проверки подлинности (Authentication methods) H Г1Р все флажки и
нажмите OK.
Упр-зел**-» алстугсм i* провч» ■ гта^тчигш
Разреши*» мн^+етошкт^чи
юменегм слс-заме промр и
Г15я‘«-и “-■тн A'Wf^rgirp рк^ил
Of jWpfcP.'Mi-J FP m Lt-rHtft-WTT
ПрмЕктаегщ#*» достуи ьш отказ с
+ С=ч 444 ; пвдим
1Р-М(И!*й* fc№ цнендеме«бе
лктср«гтл рЬ»--»-грл-ь
[<-ЭСНШС№С rpjfp. ЧОчИчгЧ
wxnsow ГШ ярИ • ■
Н)М{ПЛр
На первой странице мастера сертификатов веб-сервера нажмите Далее (Next).
362 361
На странице Сертификат сервера (Server Certificate) выберите Создание нового сер-

тификата (Create a new certificate) и нажмите Далее (Next).
363
В списке
На поставщиков
странице Отложенныйвыберите Microsoft RSAзапрос
или немедленный SChannel Cryptographic
(Delayed Provider
or Immediate и
Request) вы-
нажмите
берите Далее (Next).
Немедленно отправить запрос в локальную службу сертификации (Send the request
immediately to an online certification authority) и нажмите Далее (Next).
На странице Настройка имени и безопасности (Name and Security Settings) введите имя
для сертификата WEB-сервера (например — owa.northwind.ru) и длину криптографического
ключа (напримерСведения
На странице — 1024).обУстановите флажок
организации Выбор Information)
(Organization поставщикавведите
шифрования
название(CSP) для
вашей
данного сертификата (Select cryptographic service provider (CSP) for
организации — Northwind и подразделения — EDU и нажмите Далее (Next). this certificate) для
выбора поставщика криптографических средств (CSP) для запрашиваемого сертификата.
364 365
На странице Полное имя узла (Your Site’s Common Name) введите полное доменное имя
вашего сайта — owa.northwind.ru и нажмите Далее (Next).
На странице Сведения о местоположении (Geographical Information) введите страну,

регион и населенный пункт. Нажмите Далее (Next).
На странице Порт SSL (SSL Port) убедитесь в том, что указан верный номер порта SSL,
используемый WEB-сервером.
366
ЧАСТЬ
III. ЛАБОРАТОРНЫЕ
работа РАБОТЫ
№3
На странице Отправка запроса сертификата (Certificate Request Submission) проверьте

введенную информацию. Если вам необходимо внести какие-либо изменения, нажмите Назад
(Back). Для формирования запроса на сертификат нажмите Далее (Next).
На странице Выбор службы сертификации (Choose a Certification Authority) выберите

Центр сертификации. Нажмите Далее (Next).
Если сертификат веб-сайта установлен, в последнем окне мастера сертификата WEB-

сервера будет присутствовать сообщение «A certificate is now installed on this server».
Примечание. Этот Центр сертификации должен совпадать или находиться в

доверительных отношениях со всеми центрами сертификации, выдающими сер-
тификаты пользователям, которые должны будут получать доступ к защищенному
сайту.
В разделе Безопасные подключения (Secure communications) нажмите Изменить (Edit).
368 367
В первом окне мастера списков доверия сертификатов нажмите Далее (Next).
В окне Сертификаты в списке доверия (Certificates in the CTL) нажмите Добавить из

хранилища (Add from Store).
4i™-P ■ft!.' Чгтчч^ ПЙ;
51W4[IF
ВР*1ШйРГ
«к-fc r
_ *fca>
окне Безопасные
4D“1№ MM
SJ.U--E.
подключения
ляг
(Secure communications) установите флажки Требуется
безопасный канал ‘TJ- (SSL)
йЯ£гВ.. (Require
л:М J secure channel (SSL)) и Требуется 128-разрядное шифро-
Jww ния-г _I
вание-•--1
(Require 128-bit
-i-. ■- bvm г —- —
encryption). .ii
Выберите Требовать сертификаты клиентов (Require client
it certificates), установите флажок i Разрешить
— сопоставление сертификатов клиентов
L
(Enable client 1 certificate
*—■ mapping). iДля того чтобы при авторизации посетителей сайта могли
использоваться сертификаты, выданные различными центрами сертификации, служат
списки доверенных сертификатов. Для того чтобы составить новый список, установите
флажок Включить список доверенных сертификатов (Enable certificate trust list). Нажмите
Создать (New), чтобы запустить мастер составления списков доверенных сертификатов.
В окне Выбор сертификата (Select Certificate) выберите сертификат Центра сертифи-

кации (DS Root) и нажмите OK. В окне Сертификаты в списке доверия (Certificates in the CTL)
нажмите Далее (Next).
369
370
В окне Имя и описание (Name and Description) введите название списка сертификатов
(например — Northwind IIS CTL). Нажмите Далее (Next).
Проверьте параметры списка сертификатов; если вам необходимо внести какие-либо

изменения, нажмите Назад (Back). Для завершения работы мастера составления списка
нажмите Готово (Finish).
При успешном завершении работы мастера на экране появится окно с сообщением

«Мастер списка доверия сертификатов успешно завершил работу.» («The Certificate Trust List
wizard succeeded.»). Нажмите OK.
371
В окне Безопасные подключения (Secure Communications) нажмите OK.

В окне свойств сайта нажмите OK.
В окне Изменение наследования (Inheritance Overrides) нажмите Выделить все (Select All)
для того, чтобы сделанные настройки были применены ко всем сайтам данного сервера, и
нажмите OK.
В дереве консоли Диспетчер служб IIS (Internet Information Services (IIS) Manager)
щелкните правой кнопкой мыши по имени сервера — SERVER (локальный компьютер)
(SERVER (Local computer)). В контекстном меню выберите Все задачи > Перезапуск IIS (All
Tasks > Restart IIS).
372
В окне Остановка, запуск или перезагрузка (Start/Stop/Restart) выберите пункт Перезапуск

служб Интернета на SERVER (Restart Internet Services on SERVER) и нажмите OK.
Создание DNS-имени для нового веб-сервера

Чтобы создать DNS-имя для нового веб-сервера выполните следующие mara:s
Запустите на сервере программу DNS (DNS Manager), нажав Пуск ^ Программы ^
Администрирование (Start ^ Programs ^ Administrative Tools).
Выделите папку SERVER ^ Зоны прямого просмотра ^ northwind.ru (SERVER ^ Forward
Lookup Zones ^ northwind.ru) и через правую клавишу мыши выберите Создать псевдоним
(CNAME) (New Alias (CNAME)).
373
В окне Новая запись ресурса (New Resource Record) в поле Псевдоним (Alias name)
введите DNS-имя нового веб-сайта (например — owa) относительно домена northwind.ru, а в
поле Полное доменное имя (Fully qualified domain name) ведите его полное DNS-имя.
Нажмите OK.

Настройка сетевых подключений на хосте
Действия выполняются на хосте.
На хосте зайдите в сетевые свойства и измените параметры для подключения «...VMnetl»
в соответствии с рисунком.
Отсоедините сетевой кабель от адаптера LAN на хосте (если он использует сеть

192.168.1.0).
374
Настройка
В окне файла
Выборhosts на хостесертификата (Select certificate) выберите сертификат поль-
цифрового
зователя «Айтш»_»Инициалы
Отредактируйте вашего
на хосте файл hostsимени и файл
(данный фамилии». Используйте
находится в папке Просмотр серти-
C:\Windows\system32\drivers\etc). Для этого выполните следующие действия:сертификат.
фиката (View certificate) для того, чтобы убедиться, что выбран правильный
Откройте файл, выполнив двойной щелчок мыши. В появившемся окне Выбор про-
граммы (Select program) выберите программу «Блокнот» («Notepad») и нажмите OK.
В окне Сертификат (Certificate) в поле указан пользователь, кому выдан данный сер-
тификат. Нажмите OK.
В окне программы введите:

192.168.1.145ca.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). В появившемся
окне нажмите OK.
В окне Выбор сертификата (Select Certificate) нажмите OK. В

появившемся окне введите PIN-код eToken.
376 375
Результат тестирования доступа к защищенному веб-сайту можно считать положи-

тельным, если не удается подключиться к сайту по протоколу 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
В окне Параметры перейдите на вкладку Безопасность. В секции Параметры совместного

использования для данного документа нажмите Цифровые подписи...
В окне Цифровая подпись нажмите Добавить...
378
В появившемся окне нажмите Да.
В окне Выбор сертификата выберите сертификат, позволяющий создавать ЭЦП (на-

пример — User DS). Нажмите OK.
В появившемся окне введите PIN-код eToken.
379
В окне Цифровая подпись установите опцию Присоединять сертификаты к добавляе-

мым подписям и нажмите OK.
В окне Параметры нажмите OK.

Закройте документ.
Проверка ЭЦП в Word 2003
Для проверки ЭЦП в Word выполните следующие действия:
Откройте документ, содержащий ЭЦП. Для проверки подписи дважды щелкните
указателем мыши на знак ЭЦП в правом нижнем углу экрана данного документа.
Откроется окно Цифровая подпись. В нем будет показан сертификат, с помощью которого
подписан данный документ, а также информация о данном сертификате (кем данный
сертификат издан и т.п.)
380
Примечание. Для того чтобы система могла проверить сертификат, с помощью

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

Для того чтобы новый пользователь мог использовать Outlook 2003, необходимо вы-
полнить следующие действия:
Зарегистрируйтесь на компьютере под пользователем, для которого вы хотите настроить
Outlook (например — «Шег»_»Инициалы вашего имени и фамилии»).
Запустите Microsoft Office Outlook 2003, нажав Пуск ^ Программы ^ Microsoft Office (Start ^
Programs ^ Microsoft Office).
В окне Настройка Outlook 2003 нажмите Далее.
381
В окне Настройка учетной записи выберите опцию Да и нажмите Далее.
В окне Учетные записи электронной почты выберите опцию Microsoft Exchange Server и
нажмите Далее.
В окне Учетные записи электронной почты в поле Microsoft Exchange Server введите имя
сервера (например — server), отключите опцию Использовать режим кэширования Exchange
и в поле Имя пользователя введите входное имя пользователя. Нажмите Проверить имя для
того, чтобы проверить введенную информацию.
382
После того, как система уточнит информацию, в окне Учетные записи электронной почты
нажмите Далее.
383
В окне Учетные записи электронной почты нажмите Готово.
В появившемся окне нажмите OK.
Настройка параметров Outlook 2003 для шифрования и ЭЦП сообщений

Для того чтобы настроить параметры Outlook 2003 для возможности шифрования и ЭЦП
сообщений, необходимо выполнить следующие действия:
Зарегистрируйтесь на компьютере под пользователем, для которого вы хотите настроить
параметры Outlook (например — «№ег»_»Инициалы вашего имени и фамилии»).
Запустите приложение Microsoft Office Outlook 2003, нажав Пуск Программы ^ Microsoft
Из меню Сервис перейдите в раздел Параметры.
384
В окне Параметры перейдите на вкладку Безопасность. В секции Шифрованная элек-

тронная почта нажмите Параметры.
385
В окне Изменения настройки безопасности в секции Сертификаты и алгоритмы нажмите

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

будете создавать ЭЦП для сообщений (например — сертификат пользователя «User»_»
Инициалы вашего имени и фамилии», предназначенный для Защиты сообщений
электронной почты) и нажмите OK.
В окне Изменения настройки безопасности нажмите OK.

В окне Параметры нажмите Опубликовать в глобальном списке адресов.
386
В появившемся окне введите PIN-код и нажмите OK.
В окне Параметры нажмите OK.

Настройка Outlook Web Access для шифрования и ЭЦП сообщений
Для того чтобы настроить параметры Outlook Web Access для шифрования и ЭЦП со-
общений, необходимо выполнить следующие действия:
подключен к компьютеру. На USB-ключе eToken должен гореть световой индикатор.
Войдите на сайт Outlook Web Access (https://owa.northwind.ru), используя eToken с сер-
тификатом пользователя, для которого вы хотите настроить параметры Outlook Web Access.
В открывшемся окне выберите раздел Параметры.
387
В окне Параметры в разделе Безопасность электронной почты нажмите кнопку Загрузить.
Примечание. Если управление S/MIME уже установлено на компьютер, кнопка

Загрузить отсутствует, вместо нее появляется кнопка Переустановить.
388
В окне Параметры в панели управления нажмите Закрыть.

Для удаления управления 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
В появившемся
почтовом ящике данного
окне пользователя
введите выберите
PIN-код eToken папку
и нажмите Входящие.
OK.
Дважды щелкните мышью на сообщение, содержащее ЭЦП.
В окне с сообщением нажмите на значок подписи (справа внизу в заголовке письма).
Создание зашифрованного сообщения

Для того чтобы в Outlook 2003 создать зашифрованное сообщение, необходимо вы-
Зарегистрируйтесь на компьютере под пользователем, от имени которого вы хотите
создать сообщение.
На Панели управления нажмите Создать (сообщение).
В поле Кому... укажите получателя письма (например — admin_ds) и на панели уп-
В окне Цифровая подпись представлены результаты проверки ЭЦП (например, в данном
равления установите опцию Зашифровать сообщение. При необходимости укажите тему и
примере подпись является действительной и достоверной). Для получения дополнительной
введите сам тест сообщения. На Панели управления нажмите Отправить.
информации о сертификате, с помощью которого создана данная ЭЦП, нажмите Сведения.
Проверка ЭЦП в сообщении

Для того чтобы в Outlook 2003 произвести проверку ЭЦП в сообщении, необходимо
выполнить следующие действия:
Зарегистрируйтесь на компьютере под пользователем, на имя которого пришло со-
общение с ЭЦП.
Запустите приложение
В окне Свойства Microsoft
безопасности Office Outlook
сообщения 2003, нажав
представлена Пуск
более Программы
подробная ^ Microsoft
информация о
Office (Start ^ Programs
сертификате, ^ Microsoft
использованном дляOffice).
создания ЭЦП данного сообщения.
390 391
Открытие зашифрованного сообщения

Для того чтобы в Outlook 2003 открыть зашифрованное сообщение, необходимо вы-
Зарегистрируйтесь на компьютере под пользователем, на имя которого пришло за-
шифрованное сообщение.
В почтовом ящике данного пользователя выберите папку Входящие.
Дважды щелкните мышью на зашифрованное сообщение.
В появившемся окне введите PIN-код eToken и нажмите OK.
392
В окне с сообщением нажмите на значок зашифрованного

Использование сообщения (справа внизу в
Outlook Web Access
загоёовке письма).
для защиты сообщений электронной почты
Создание сообщений с ЭЦП

Для того чтобы в Outlook Web Access создать сообщение с ЭЦП, необходимо выполнить
Войдите на сайт Outlook Web Access (например, https://owa.northwind.ru), используя
eToken с сертификатом пользователя, от имени которого вы хотите создать сообщение. На
Панели управления нажмите Создать (сообщение).
В поле Кому... укажите получателя письма и на панели управления установите опцию
Подписать. При необходимости укажите тему и введите сам тест сообщения. На Панели
управления нажмите Отправить.
В окне Свойства безопасности сообщения представёена информация о параметрах,

испоёьзованных при шифровании данного сообщения.
Создание шифрованных сообщений

Для того чтобы в Outlook Web Access создать зашифрованное сообщение, необходимо
eToken с сертификатом пользователя, от имени которого вы хотите создать сообщение.
На Панели управления нажмите Создать (сообщение).
В поле Кому... укажите получателя письма и на панели управления установите опцию
Зашифровать сообщение. При необходимости укажите тему и введите сам тест сообщения.
На Панели управления нажмите Отправить.
394 393
Проверка ЭЦП в сообщениях

Для того чтобы в Outlook Web Access произвести проверку ЭЦП в сообщении, необ-
ходимо выполнить следующие действия:
eToken с сертификатом пользователя, на имя которого пришло сообщение с ЭЦП.
В почтовом ящике данного пользователя выберите папку Входящие.
Дважды щелкните мышью на сообщение, содержащее ЭЦП.
В окне с сообщением нажмите на значок подписи (справа внизу в заголовке письма).
В окне Цифровая подпись представлены результаты проверки ЭЦП (например, в данном

примере цифровая подпись этого сообщения действительна и является доверенной).
395
Содержание
Открытие шифрованных сообщений отчета
В отчете с титульным листом установленной формы (см. Приложение А) необходимо
4. Описание настроек сервера и рабочей станции для удаленного доступа к рабочему
столу.
5. Описание настроек виртуальной частной сети.
6. Настройки созданного нового защищенного веб-сервера для доступа к нему по про-
токолу HTTPS.
7. Настройки MS Word 2003 и MS Outlook 2003 для применения ЭЦП.
Для того чтобы в Outlook 2003 открыть зашифрованное сообщение, необходимо вы-
1.Убедитесь в том,учебный
Как настроить что вашстенд
eToken с сертификатом,
для дающим
работы виртуальной правосети?
частной на доступ к сайту,
подключен к компьютеру.
2. Как использовать ЭЦПНавUSB-ключе eToken должен гореть световой индикатор.
MS Word 2003?
3.Войдите на сайт
Как создать Outlook Web
защищенный Access (например, https://owa.northwind.ru), используя
веб-сервер?
eToken с сертификатом пользователя,
4. Каким образом можно настроить MS на имя которого
Outlook 2003 пришло зашифрованное
для шифрования сообщение.
сообщений?
5.ВВпочтовом ящике данного
чем заключаются пользователя
отличия протоколов выберите
PPP и EAP? папку Входящие.
Дважды щелкните мышью на зашифрованное сообщение.
В окне будет представлено само сообщение (расшифрованное), а справа внизу в за-
головке письма будет стоять значок зашифрованного сообщения.
396
(образец)


ИСПОЛЬЗОВАНИЕ eToken ДЛЯ БЕЗОПАСНОГО ДОСТУПА

К ИНФОРМАЦИОННЫМ РЕСУРСАМ
ДЛЯ ШИФРОВАНИЯ И ДЛЯ ЭЦП

Выполнили:
(Ф.И.О.)
(Ф.И.О.)
Принял:
(Ф.И.О)
(год)
398
СОПРОВОЖДЕНИЕ ФУНКЦИОНИРОВАНИЯ
ЦЕНТРА СЕРТИФИКАЦИИ,
ПОВЫШЕНИЕ ЗАЩИЩЕННОСТИ СИСТЕМ
НА ОСНОВЕ WINDOWS SERVER 2003
Изучить практические вопросы по сопровождению функционирования Центра сер-
тификации и рассмотреть практические советы по повышению защищенности систем на
основе Windows Server 2003.
Общие сведения по сопровождению функционирования

Центра сертификации и повышению безопасности систем
на основе Windows Server 2003
Архивирование и восстановление ЦС
В данной лабораторной работе будут рассмотрены практические вопросы по сопро-
вождению функционирования Центра сертификации, которое, помимо изученных ранее
операций настройки и выпуска сертификатов, включает архивирование и восстановление
состояния системы (компьютера, на котором установлен ЦС), архивирование и
восстановление собственно самого ЦС, а также такие операции, как архивирование
сертификатов, аннулирование и удаление сертификатов.
Первая часть работы посвящена вопросам архивирования сертификатов. Кроме того,
специалистами компании Microsoft рекомендовано регулярное архивирование данных на
компьютере, выполняющем функции Центра сертификации. В процессе сопровождения
функционирования Центра сертификации также может потребоваться архивирование данных
и самого Центра сертификации.
В процессе выполнения работы слушатели познакомятся с рекомендациями спе-
циалистов компании Microsoft по сопровождению функционирования Центра сертификации.
Обеспечение безопасности клиентов нижнего уровня

Степень безопасности всякой системы определяется степенью безопасности ее самого
слабого звена. Именно поэтому необходимо постоянно выявлять такие звенья и повышать
уровень их защищенности.
Обеспечение безопасности клиентов нижнего уровня — задача не из легких. Кроме того,
она относится к разряду задач, которыми часто пренебрегают при внедрении новой
операционной системы. Хотя настройку защиты Windows 9x и Windows NT вряд ли можно
назвать увлекательной работой, однако глубокое понимание всех проблем, связанных с
безопасностью этих систем, поможет лучше подготовиться к настройке доменов Windows.
Все методы и средства, которые используются для защиты клиентов нижнего уровня,
имеют аналоги в системах Windows 2000/XP: оснастке Group Policy соответствует редак-
399
тор системной политики 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 CA придерживаться
следующих правил:
• Держать корневой ЦС отключенным от сети и хранить его в физически защищенном
месте, например в сейфе. В данной лабораторной работе Центр сертификации и
контроллер домена находятся на одном компьютере, исходя из удобства изложения
материала. В действительности же лучше создать Центр сертификации независимо от
контроллера домена.
• Не создавать в больших организациях, интенсивно использующих структуру PKI и
соответствующие приложения, более четырех уровней иерархии ЦС. При не-
обходимости лучше расширять иерархию, создавая на соответствующих уровнях
дополнительные, специализирующиеся на определенных типах сертификатов ЦС, а
также оптимизировать распределение ЦС по предприятию.
• Возобновлять сертификаты ЦС задолго до истечения их срока действия.
• Обеспечивать регулярное и своевременное обновление публикуемого CRL, чтобы
учесть и потребности в своевременном извещении об отозванных сертификатах, и
необходимость выполнения репликации изменений. Иными словами, нужно следить,
чтобы CRL не устаревал еще до того, как он будет реплицирован на всех доменах
всеми контроллерами доменов.
• Защищать резервную копию секретного ключа ЦС и базы данных и хранить их в
надежном месте.
• Своевременно обновлять программное обеспечение с помощью сервисных пакетов и
модулей обновления.
• Заблаговременно отрабатывать и проверять план действий в нештатных ситуациях.
Для изучения практических вопросов по сопровождению функционирования Центра
сертификации и повышению безопасности систем на основе Windows Server 2003 работа
делится на две части:
• сопровождение функционирования Центра сертификации;
• повышение безопасности клиентов нижнего уровня.
400
Обслуживание Центра сертификации

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

Данная часть работы предназначена для ознакомления с практическими советами и
рекомендациями по повышению уровня безопасности клиентов нижнего уровня в системах,
построенных на основе Windows Server 2003. Для выполнения данной части работы
необходимо:
• Изучить отказ от аутентификации LM, NTLM v.1:
— провести установку алгоритма аутентификации NTLM v.2 на клиенте;
— запретить алгоритмы аутентификации LM и NTLM v.1 на контроллере домена.
• Настроить запрет создания и хранения значений хэш-функций LM на контроллере
домена.
• Настроить парольную политику домена.
• Изучить возможность усиления безопасности на уровне сетевого трафика:
— выполнить отключение протокола NetBIOS;
— выполнить включение SMB-подписи.
Задание
2. Провести архивирование сертификата вместе с закрытым ключом.
3. Выполнить резервное копирование и восстановление состояния системы.
4. Переиздать сертификат корневого Центра сертификации.
5. Корректно удалить Центр сертификации.
6. Изучить практические рекомендации по работе с центром сертификации.
7. Выполнить отказ от аутентификации LM, NTLM v.1.
8. Настроить запрет создания и хранения значений хэш-функций LM на контроллере
домена.
9. Выполнить отключение протокола NetBIOS.
10. Выполнить включение SMB-подписи.
401

Сопровождение функционирования Центра сертификации
Архивирование сертификата вместе с закрытым ключом
Для того чтобы заархивировать сертификат вместе с закрытым ключом, следуйте
приведенной ниже инструкции:
Запустите Консоль Сертификатов.
В дереве консоли разверните Сертификаты — текущий пользователь ^ Личные ^ Сер-
тификаты (Certificates — Current User ^ Personal ^ Certificates).
Выберите сертификат и щелкните по нему правой кнопкой мыши, выберите Все задачи
(All tasks^ щелкните Экспорт (Export).
На первой странице мастера запроса сертификатов нажмите Далее (Next).
На странице Экспортирование закрытого ключа (Export Private Key) выберите опцию Да,
экспортировать закрытый ключ (Yes, export the private key) и нажмите Далее (Next).
402
На странице Имя файла экспорта (File to Export) введите имя файла, куда будет помещен
сертификат с закрытым ключом, и нажмите Далее (Next).
На странице Формат экспортируемого файла (Export File Format) нажмите Далее (Next).
На странице Завершение работы мастера экспорта сертификатов (Completing the

Certificate Export Wizard) нажмите Готово (Finish).
На странице Пароль (Password) введите пароль и нажмите Далее (Next).
В случае успешного экспорта сертификата с закрытым ключом появится экран с со-

общением Экспорт успешно выполнен (The export was successful). Нажмите ОК.
404 403
Резервное копирование состояния системы

Создание резервной копии
Для того чтобы создать резервную копию состояния системы (System State), необходимо
Выберите на сервере Пуск ^ Программы ^ Стандартные ^ Служебные ^ Архивация
данных (Start ^ Programs ^ Accessories ^ System Tools ^ Backup).
На первой странице Мастер архивации или восстановления (Backup or Restore Wizard)
На странице Элементы для архивации (Items to Back Up) установите флажок System
State, предварительно открыв Рабочий Стол ^ Мой Компьютер (Desktop ^ My Computer).
Mac Гер atnwMbi*1 DOCC f аНвЬпЬиШ
Зммлнти АЛА лрхыпдции

М&рне $we№it самрлгн^ьдие*». rare* M*i ФЙИГЧ»
На странице Архивация или восстановление (Backup or Restore) выберите опцию Ар-

хивация файловДриады
и параметров (Back
щр.^.нмт? up files доа
на «осите^ andпрос^чщ»
settings) иCM.fCi*i+4ra
нажмите Далее
Уст (Next).
q п-5R м ала к*а я»-*:» и. !*вд еяад етйрь*е трябуггеА армиям!*
Ню слейует аримеи^свлть
Рлбо*«« стал | ^:с*г4,и>(?.^вш
Mot«. с*лютее
Ж Дда3.5(А|
СЧР Certticale- Serve
Ж U-^ tytfwfC]
□ ^ mtAfllD) _Чг:ом • Chti
» Олл: Rep:
X HRM€FPP_EH IE |
•П
Syiieni Male R«o □ ^SYSVOl

‘ □ _) Момаоеулвиты
UJ Сетевое окр^т-е*»^
< Неяй
страницеЧто
На странице Имя, тип и расположение
следует архивации
архивировать (What (Backup
to Back Type, Destination,
Up) выберите and Name)
опцию Предоставить
выберите директорию
возможность и имя файла,
выбора объектов для где будет храниться
архивации (Let me резервная копия
choose what состояния
to back up) и системы
нажмите
(например
Next — c:\backup\SystemState). Нажмите Далее (Next).
(Далее).
406 405
На странице Завершение мастера архивации и восстановления (Completing the Backup or

Restore Wizard) нажмите Готово (Finish).
После окончания резервного копирования в появившемся окне нажмите Закрыть (Close).
407
Восстановление из резервной копии

Для того чтобы восстановить состояние системы из резервной копии необходимо вы-
Если Центр сертификации установлен на контролере домена, то перезагрузите сервер и
загрузите его в режиме Directory Services Restore Mode (Windows domain controllers only) (для
этого в процессе загрузки нажмите F8, чтобы попасть в меню Windows Advanced Options).
Для запуска на сервере программы Архивация данных (Backup) выполните двойной

щелчок мышью на файле, в котором у вас хранится резервная копия System State (например
— c:\backup\SystemState).
На первой странице Мастер архивации и восстановления (Backup or Restore Wizard)
На странице Архивация и восстановление (Backup or Restore) выберите опцию Вос-

становление файлов и параметров (Restore files and settings) и нажмите Next (Далее).
408

После окончания восстановления данных в окне Ход архивации (Restore Progress)
нажмите Закрыть (Close).
На странице Что следует восстанавливать (What to Restore) установите флажок System

State (File/SystemState.bkf) и нажмите Next (Далее).
В появившемся окне нажмите Да (Yes) для перезагрузки VM SRV в обычном режиме.
Отзыв и удаление сертификата

Для того чтобы отозвать сертификат, необходимо выполнить следующие действия:
Запустите консоль Центра сертификации Certification Authority (Пуск ^ Программы ^
Администрирование (Start ^ Programs ^ Administrative Tools)).
Выберите Центр сертификации, сертификаты которого вы хотите отозвать, и выберите
папку Выданные сертификаты (Issued Certificates).
Щелкните правой кнопкой мыши по сертификату, который вы хотите отозвать, и вы-
берите Все задачи ^ Отзыв сертификата (All Tasks ^ Revoke Certificate).
На странице Завершение мастера архивации и восстановления (Completing the Backup or

Restore Wizard) нажмите Готово (Finish).
В окне Отзыв сертификатов (Certificate Revocation) выберите причину отзыва серти-

фиката (например — Сертификат заменен (Superseded)) и нажмите Да (Yes).
410 409
Для того чтобы удалить сертификат из списка опубликованных сертификатов для

учетной записи пользователя, необходимо выполнить следующие действия:
Запустите программу Active Directory — пользователи и компьютеры (Active Directory —
users and computers), нажав Пуск ^ Программы ^ Администрирование (Start ^ Programs ^
Administrative Tools). Включите опцию Дополнительные функции (Advanced Features) из
меню Вид (View).
Перейдите в директорию Users. Щелкните правой кнопкой мыши по учетной записи

пользователя, у которого вы хотите удалить сертификат. Выберите Свойства (Properties).
Перейдите на закладку Опубликованные сертификаты (Published Certificates), выберите
из списка сертификат, который вы хотите удалить, и нажмите Удалить (Remove).
411
В появившемся окне нажмите Да (Yes).
Архивация и восстановление Центра сертификации Для

архивации Центра сертификации:
Используя «Проводник», создайте новую директорию C:\Backup_CA, куда будет помещен
архив Центра сертификации.
На виртуальной машине VM SRV запустите Центр Сертификации (Certification Authority).
Выделите DS Root и выберите Все задачи ^ Архивация ЦС (All Tasks ^ Back up CA).
412
В окне приветствия мастера архивации Центра сертификации нажмите Далее (Next).
Примечание: Данный пароль очень важен, поскольку в системе не предусмотрено

альтернативного восстановления на случай утери пароля.
Установите опции Закрытый ключ и сертификат ЦС (Private key and CA certificate) и
Certificate database and certificate database log (База данных сертификатов и ее журнал),
укажите в поле Архивировать в следующее место (Back up to this location) директорию
C:\Backup_CA.
Чтобы воспользоваться созданной архивной копией Центра сертификации выполните

следующие шаги:
На виртуальной машине VM SRV запустите Центр Сертификации (Certification Authority).
Задайте пароль, который будет использоваться для защиты архива.
414 413
Выделите DS Root и выберите Все задачи ^ Восстановление ЦС (AH Tasks ^ Restore CA).
После появления сообщения об остановке службы сертификации нажмите OK.
В окне приветствия мастера восстановления Центра сертификации нажмите Далее (Next).
415
Установите опции Закрытый ключ и сертификат ЦС (Private key and CA certificate) и

Certificate database and certificate database log (База данных сертификатов и ее журнал),
укажите в поле Восстанавливать из следующего места (Restore from this location) дирек-
торию C:\Backup_CA. Затем нажмите Далее (Next).
Введите пароль к архивной копии Центра сертификации и нажмите Далее (Next).

416
На экране появится окно Переиздать новый сертификат ЦС (Renew CA Certificate) с

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

(Yes).
Нажмите OK.
Центр сертификации получит новый сертификат, после чего его необходимо будет снова
запустить.
Примечание: Вместо этой последовательности действий вы можете выполнить
на сервере команду certutil —renewcert [reusekeys], где [reusekeys] — необязательный
ключ, указывающий на то, что вы не хотите менять ключевую пару. Без этого па-
раметра новому сертификату будет соответствовать закрытый ключ, отличный
от закрытого ключа старого сертификата.
Переиздание сертификата корневого Центра сертификации
Корректное удаление Центра сертификации
Если время действия сертификата корневого Центра сертификации заканчивается и/или
вы Для
хотите изменить
того ключевую
чтобы удалить пару,сертификации,
Центр вам следует переиздать
выполните наданный сертификат.
сервере следующую Новый
по-
сертификат будет иметь
следовательность действий: серийный номер, отличный от серийного номера прежнего
сертификата. Для того чтобы
Создайте защищенную переиздать
паролем сертификат
резервную корневого
копию Центра Центра сертификации,
сертификации с помощью
выполните
консоли или накоманды
сервере следующие действия:
certutil — backup <путь>, где <путь> — путь к папке, в которую вы
В дереве
хотите сохранитьконсоли
архив.выделите Центр сертификации, щелкните правой кнопкой мыши,
выберите Все задачи > Обновить
Отклоните все запросы сертификат
на получение ЦС (All tasksПодайте
сертификата. > Renewкоманду
CA Certificate).
на внеочередное
выполнение процедур автоматической выдачи сертификатов (certutilВ-pulse).
Если Центр сертификации запущен, потребуется его остановка. этом случае на экране
появится
Службаокно с предложением
каталогов остановить
Active Directory Центр сертификации.
должна растиражироватьНажмите Да (Yes). об откло-
информацию
ненных запросах на получение сертификата, а групповые политики — довести эту ин-
формацию до пользователей. Для того чтобы применить политики немедленно, выполните
команду gpupdate /force.
Если Центр сертификации является промежуточным, отзовите его сертификат в центре
сертификации, выдавшем данный сертификат. В качестве причины отзыва укажите
Прекращение работы (Cease of Operation).
418 417
Если Центр сертификации является корневым:

— отзовите все выданные им сертификаты с указанием причины Прекращение работы
(Cease of Operation);
— удалите сертификат данного Центра сертификации из всех созданных вручную
объектов групповой политики.
Опубликуйте в соответствующем центре сертификации список отзыва сертификатов
вручную с помощью консоли, либо с помощью команды certutil — crl.
Удалите системный компонент Certificate Services с помощью мастера компонентов
Windows (Windows Components Wizard).
Для того чтобы удалить из Active Directory оставшуюся информацию об удаленном
центре сертификации, выполните команду certutil —dsdel «<имя>«, где <имя> — имя
удаленного Центра сертификации.
Удалите лишние сертификаты из хранилищ, выполнив следующие команды:
— certutil — delstore ca "<имя>";
— 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 XP по умолчанию для
аутентификации при регистрации в сети используется протокол 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, необходимо
Откройте на рабочей станции Пуск ^ Панель управления ^ Администрирование (Start
Control Panel ^ Administrative Tools), запустите программу Локальные политики безопасности
(Local Security Policy).
Перейдите в папку Параметры безопасности (Secure Settings). Установите значение
параметра Network security: LAN Manager authentication level равным Send NTLMv2 response
only\refuse LM & NTLM.
419
Запрет алгоритма аутентификации LM и NTLM v. 1

на контроллере домена
Для того чтобы на контроллере домена запретить использование алгоритмов LM и NTLM

v.1 для аутентификации, необходимо выполнить следующие действия:
Откройте на контролере домена Пуск ^ Программы ^ Администрирование (Start ^
Programs ^ Administrative Tools), выберите программу Политика безопасности контроллера
домена (Domain Controller Security Policy).
безопасности (Security Settings ^ Local Police ^ Security Options). Установите значение
параметра Network security: LAN Manager authentication level равным Send NTLMv2 response
only\refuse LM & NTLM.
420
Для того чтобысоздания

Запрет на контроллере домена
и хранения настроить
хэшей LM на парольную политику
контроллере доменадомена, не-
обходимо выполнить следующие действия:
Для того чтобы
Откройте на контроллере
на контролере домена домена запретить создание
Пуск ^ Программы и хранение хэшей
^ Администрирование (StartLM, не-
^ Pro-
обходимо выполнить следующие
grams ^ Administrative действия:программу Политика безопасности контроллера
Tools), выберите
Откройте
домена (DomainнаController
контролере домена
Security Пуск > Программы > Администрирование (Start >
Policy).
Programs > Administrative
Перейдите Tools), выберите
в папку Политики программу
учетных записей Политикапаролей
> Политика безопасности контроллера
(Account Polices ^
домена
Password (Domain
Policy).Controller
УстановитеSecurity Policy).
параметры в соответствии с рисунком.
Перейдите в папку Параметры безопасности > Локальные политики > Параметры без-
опасности (Security Settings > Local Police > Security Options). Найдите параметр Network
security: Do not store LAM Manager hash value on next password change. Активизируйте данный
параметр.
Перезагрузите сервер или выполните команду gpupdate /force.
Возможности усиления безопасности

на уровне сетевого трафика
Отключение протокола NetBIOS

Протокол Установка
NetBIOS и именаданной опции
NetBIOS не приводит к в
использовались удалению
качествеуже существую-
основных в опе-
щих LM хэшей паролей. С этого момента не будет больше вычисляться
рационных системах, предшествовавших Windows 2000. Операционные системы и храниться
Windows
LMхэш
Server 2003 паролей
и Windows для XPновых пользователей
поддерживают иличерез
NetBIOS новых паролей
TCP/IP для старых с
для совместимости
устаревшим программным обеспечением. Если вы не используете программы,
обращающиеся к ресурсам
Перезагрузите сервер и по именам
рабочую NetBIOS,чтобы
станцию, отключите NetBIOS через
активизировать TCP/IP.изменения.
внесенные
Для того чтобы на рабочей машине отключить протокол NetBIOS, необходимо выполнить
следующие действия: Настройка парольной политики домена
Зарегистрируйтесь на рабочей станции под именем пользователя с правами админи-
стратора.
В гетерогенной среде полный отказ от использования паролей может распространяться
Перейдите
только к свойствамвход
на интерактивный Сетевое окружение
в систему (My Networkработающих
пользователей, Place). на компьютерах под
Выберите Windows
управлением адаптер LAN (Local
2000, Area Network)
Windows и перейдите
XP и Windows к его
Server свойствам.
2003. Пароль необходим для
Выберите
других пунктаутентификации
вариантов Internet Protocol(TCP/IP) и нажмите
и является Properties (Свойства).
неотъемлемым атрибутом учетной записи
пользователя. Поэтому безопасность сетевой инфраструктуры в значительной мере зависит
от стойкости паролей.
422 421
ЧАСТЬ работа №
III. ЛАБОРАТОРНЫЕ 4
РАБОТЫ
Выберите вкладку WINS и в разделе Свойства NetBIOS (NetBIOS Settings) выберите

значение Отключить NetBIOS через TCP/IP (Disable NetBIOS over TCP/IP) и нажмите OK.
Закройте все окна.
В появившемся окне нажмите Дополнительно (Advanced).
Включение SMB-подписи
Протокол 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 423
— Microsoft network sever: Digitally sign communications (always): Включен (Enabled).
Перезагрузите сервер и рабочую станцию или выполните команду gpupdate /force (на
сервере и на рабочей станции).
В отчете с титульным листом установленной формы (см. Приложение А) необходимо
425

4. Описание настроек протокола аутентификации на сервере и на рабочей станции.
5. Описание действий по архивации и восстановлению Центра сертификации.
1. Как проводить процедуры резервного копирования и восстановления Центра сер-
тификации?
2. Как настроить использование протокола аутентификации NT LM v.2?
3. Как усилить безопасность на уровне сетевого трафика?
4. Какие есть рекомендации по работе с центром сертификации и PKI-службой?
(образец)


СОПРОВОЖДЕНИЕ ФУНКЦИОНИРОВАНИЯ
ЦЕНТРА СЕРТИФИКАЦИИ,
ПОВЫШЕНИЕ ЗАЩИЩЕННОСТИ СИСТЕМ
НА ОСНОВЕ WINDOWS SERVER 2003

Выполнили:
(Ф.И.О.)
(Ф.И.О.)
Принял:
(Ф.И.О)
(год)
427
ДОСТУП В СУБД ORACLE С АУТЕНТИФИКАЦИЕЙ
ПО ИМЕНИ ПОЛЬЗОВАТЕЛЯ И ПАРОЛЮ
В LDAP-КАТАЛОГЕ
Изучение системы централизованного управления пользователями, ролями, базами
данных и приложениями, построенной на основе LDAP-каталога Oracle Internet Directory.
Применение методик настройки сервера БД Oracle и клиентских рабочих станций для
аутентификации и авторизации пользователей службами LDAP-каталога. Получение навыков
работы с программным обеспечением конфигурации сервера баз данных Oracle и доступу к
СУБД Oracle с помощью аутентификации и авторизации по имени пользователя и паролю в
LDAP-каталоге.
Примечание. Установленное на предоставляемом стенде программное обеспе-

чение является собственностью корпорации Oracle. Данное программное обеспечение
может быть свободно загружено с сайта производителя
http://www.oracle.com/technology/software/products/oracle9i/index.html. Перед ис-
пользованием его в составе данного стенда или при самостоятельной установке,
пожалуйста, ознакомьтесь с лицензионным соглашением по адресу
http://www.oracle.com/technology/software/popup-license/standard-license.html. Про-
граммное обеспечение для функционирования стенда является собственностью
компании 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 (OID).
OID предоставляет возможность использования двух типов аутентификации:
1. Однократный пароль пользователя.
2. Сертификат пользователя (в данной лабораторной работе не рассматривается).
428
Однократный пароль пользователя

Дает возможность аутентификации во многих базах данных с предъявлением един-
ственного имени и пароля пользователя. Данная возможность реализуется в опции СУБД
Oracle Advanced Security. Учетные записи пользователей и пароли хранятся в OID и
защищены с помощью криптографических методов и контрольных списков доступа (Access
Control Lists — ACL).
Объекты хранения OID
Ниже перечислены основные типы объектов каталога, относящихся к управлению
аутентификацией:
• Пользователи масштаба организации (далее, пользователи);
• Роли пользователей масштаба организации (далее, роли);
• Домены;
• Базы данных;
• Соответствия пользователь—схема;
• Административные группы.
Пользователи
Определяются, хранятся и управляются службами каталога. Каждый пользователь
уникально идентифицируется в рамках информационной системы организации. Поль-
зователи определяются в любом поддереве LDAP-каталога OID. Объекты, описанные ниже,
могут определяться только в поддереве каталога со специальным именем
«CN=OracleContext».
Роли
Пользователям могут назначаться роли, которые определяют набор прав доступа к той
или иной базе данных. Роли также хранятся и управляются в LDAP-каталоге OID. Роли могут
содержать так называемые «глобальные роли», каждая из которых определяется в соот-
ветствующей базе данных. Глобальная роль содержит привилегии, которые располагаются в
базе данных, но управляются службой каталога. Таким образом, роль — есть контейнер для
глобальных ролей. Роль может быть назначена одному или многим пользователям.
Замечание. База данных получает глобальные роли пользователя после его регистрации (аутентификации и
авторизации). Поэтому изменения в наборе глобальных ролей для пользователя вступают в силу
только после следующего события регистрации в базе данных.
Домены
Домен представляет собой группу ролей и баз данных. Доменом, например, может являться
подразделение организации или небольшая организация в целом. Поддерево домена
составляют три типа объектов: роли, соответствия схем баз данных и группы ад-
министраторов данного домена.
Базы данных
Представляют собой набор информации об определенном экземпляре сервера базы
данных Oracle. Данные объекты каталога создаются с помощью программного инструмента
Oracle Enterprise Security Manager в процессе регистрации базы данных.
429
Наименование Описание
OracleDBCreators
Члены данной группы
(cn=OracleDBCreators,cn=OracleContext...) могут создавать новые
базы данных, что подразумевает их регистрацию в каталоге с
помощью Oracle Enterprise Security Manager. Они имеют права
create и modify к объектам и атрибутам баз данных. Они также могут
модифицировать домен по умолчанию.
Члены группы OracleContextAdmins могут добавлять
пользователей в эту группу с помощью Oracle Enterprise Security
Manager. В Oracle Enterprise Security Manager данная группа
обозначается как Database Registration Admins.
OracleContextAdmins
Члены группы OracleContextAdmins могут модифицировать лю-
бую группу. В Oracle Enterprise Security Manager данная группа
обозначается как Full Context Management.
OracleDBSecurityAdmins
Члены группы OracleDBSecurityAdmins
(cn=OracleDBSecurityAdmins,cn=OracleContext...) имеют все
привилегии на поддерево каталога OracleDBSecurity. Они имеют
доступ ко всем доменам организации и ответственны за:
• Управление группой OracleDBSecurityAdmins
• Создание новых доменов
• Перемещение баз данных между доменами
В Oracle Enterprise Security Manager данная группа обозначается как
Database Security Management.
OracleUserSecurityAdmins
Члены группы OracleUserSecurityAdmins
(cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext...)
отвечают за безопасность для пользователей Oracle. Например, они
могут модифицировать пароль пользователя.
В Oracle Enterprise Security Manager данная группа обозначается как
Directory User Management.
OraclePasswordAccessibleDo
mains Членами этой группы являются домены, содержащие базы данных, для
которых разрешен однократный пароль пользователя.
430
Рис. 1. Схема каталога OID
Пример схемы каталога приведен на рис. 1.
При установке OID в нем создаются некоторые объекты схемы, относящиеся к управ лению базами данных, ролями и пользователями. Суперпользователь (администратор OID) с отличительным именем
«cn=orcladmin» добавляется во все созданные административные группы. Далее, в схему могут добавляться дополнительные домены, группы и пользователи.
Процесс настройки и дальнейшей аутентификации пользователя

с однократным паролем (рис. 2)
1. Администратор БД настраивает сетевую конфигурацию экземпляра базы данных для взаимодействия со службой каталога OID. Это может быть сделано вручную (редактирование файла конфигурации) или с
помощью служебной утилиты Net Configuration Assistant. Настройка заключается в указании имени компьютера (IP-адреса), на котором функционирует OID, номеров портов,
назначенных OID, а также имени контекста Oracle (корневого элемента каталога). В задачи администратора БД входит также создание общих схем и глобальных ролей.
2. Пользователь, являющийся членом группы OracleDBCreators, регистрирует экземпляр базы данных в каталоге OID. Регистрация экземпляра базы данных делает доступным
получение информации о пользователях, ролях, соответствиях схем и т.д., хра нящейся в каталоге OID, для данного экземпляра. Процесс регистрации создает объект «база данных» в выбранном контексте
Oracle и вносит в каталог необходимую информацию, однозначно определяющую указанный экземпляр. Завершением процесса регистрации является внесение отличительного имени (DN) базы данных в параметры ини-
циализации сервера. Взаимодействие сервера базы данных и службы каталога OID про-
431
trtr
сходит по защищенному протоколу (SSL)
и только после успешной взаимной аутен-
тификации также по SSL-протоколу. Для
осуществления SSL-аутентификации эк-
земпляр сервера БД использует ключевой
контейнер (т.н. wallet), содержащий откры-
тый и закрытый ключи, а также сертификат
базы данных. Аналогичный ключевой кон-
тейнер имеет и служба каталога OID. Для
регистрации используется служебная утили-
та Enterprise Security Manager.
1. Администратор БД или администратор
безопасности с помощью утилиты Enterprise
Security Manager создает в каталоге OID (ес-
ли это необходимо) домены, роли и пользова-
телей.
2. Пользователь инициирует соединение
с базой данных, используя имя и пароль.
3. База данных проводит процесс аутен-
тификации и авторизации пользователя,
включающий следующие шаги:
Рис. 2. Настройка аутентификации
с помощью однократного пароля • поиск отличительного имени (DN) по
предъявленному имени и извлечение
правила проверки предъявленного
пароля;
проверка пароля с помощью извлеченного правила и поиск (локально в базе данных)
схемы, явно назначенной данному пользователю;
поиск общей схемы в каталоге OID, если локально схему найти не удалось; извлечение
ролей пользователя и соответственное назначение глобальных ролей для
установленной сессии пользователя.
Методические указания
Подготовка стенда
Минимальные аппаратные требования к хост-машине
Процессор PIV-1400 и выше, 1024M RAM — и более, 12 Gb дискового пространства. OS
Windows 2000/XP, клиентское ПО VMWare (6.0.0 и выше).
Установка виртуальной машины (рис. 3)
1. Распаковать архив с образом виртуальной машины на жесткий диск хост-машины
(например, в каталог D:\VM\SERVER). Архив с образом виртуальной машины находятся на
демонстрационном диске в каталоге \VM\SERVER.
2 Архив содержит файлы:
EDU-Oracle-Server-DataDisk-f001.vmdk
432
Рис. 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... ^ Virtual
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
Параметр Описание
«Гостевая» операционная система • Windows 2003 Server Enterprise Edition SP1

ПО Oracle
• Oracle Database Server 9i (9.2.0.8) Enterprise Edition
• Oracle Internet Directory (9.2.0.8)
Служба Описание
OracleServiceORCL Экземпляр базы данных. Запускается от имени учетной записи

пользователя OC «oracle» при старте системы.
OracleOraHome92TNSListener
Сетевая служба экземпляра БД. Запускается от имени учетной
записи пользователя OC «oracle» при старте системы.
OracleDirectoryService_ORCL Служба каталога Oracle Internet Directory (OID). Запускается от

имени учетной записи пользователя OC «oracle» вручную.
Таблица 2.1
Службы, запускаемые на стенде
434
Пользователь Пароль Описание
Administrator Welcomel Администратор ОС.

Oracle Welcomel
Пользователь ОС, администратор БД Oracle, входит в
группы «Administrators» и «ORA_DBA».
Sys Welcome1 Пользователь БД, администратор Oracle.
System Welcomel Пользователь БД, суперпользователь Oracle.
orcladmin (cn=orcladmin) welcome Пользователь OID, администратор OID
Параметр Значение Описание
ORACLE_HOME E:\Ora92 Директория установки сервера Oracle.
ORACLE_SID/SERVICE ORCL Имя экземпляра БД/Имя службы
HOSTNAME EDU Имя машины, где установлен экземпляр БД Oracle
Oracle port 1521 Порт для обслуживания обычных соединений

2484 Порт для обслуживания SSL-соединений
Oracle SSL port
Таблица 4
Параметры сервера
EDU БД и службы
Имя машины, каталога OID
где установлена служба OID
OID host
OID port 4054 Порт OID для обслуживания обычных соединений
OID SSL port 4057 Порт OID для обслуживания SSL соединений
Сетевые алиасы (описатели соединений в ORACLE_HOME\network\admin\tnsnames.ora)
ORCL Для соединения с БД по обычному протоколу
ORCLSSL Для соединения с БД по SSL-протоколу
Ключевые Используются для установления защищенного соединения и взаимной аутен-

контейнеры тификации между экземпляром БД и службой каталога OID. Размещаются в каталогах
«E:\Wallets\DB», «E:\Wallets\OID» для базы данных и OID соответственно. Пароль к
(wallets) ключевым контейнерам «Welcome!» — для обоих контейнеров
Таблица 5
Другие параметры стенда
435
Параметр Значение
IP адрес/маска подсети 192.168.12.1/255.255.255.0
Имя компьютера/имя рабочей группы EDU/EDUCATION

Таблица 6
Сетевые настройки операционной системы стенда
Подготовка к работе
Создание точки отката
Эта процедура необязательная, но рекомендуется ее выполнить для возможности
приведения виртуальной машины в исходное состояние.
• Выбрать меню окна консоли VMWare (рис. 3) «VM ^ Snapshot ^Take Snapshot...».
• В открывшемся окне мастера «Take Snapshot» задать имя точки отката и опци-
ональное описание, нажать «OK».
Задание
Запуск виртуальной машины
Настроить доступ для и подготовка к«user2»
«user»,
пользователей работе сервера базы данных Oracle
для «ORCL»
работы с экземпляром базы данных Oracle в одной общей схеме
«SHAREDSCHEMA». При успешной установке сеанса пользователи должны получить роль «GLOBALROLE», назначаемую службой каталога OID. Для учетных
• В окне консоли VMWare ( см. рис. 3) в панели «Commands» выбрать «Start this virtual
записей пользователей в каталоге использовать контекст Oracle, созданный по умолчанию («edu»). Использовать домен по умолчанию («OracleDefaultDomain»). База поиска
machine».
«cn=users, dc=edu, dc=com») (рис. 4).
пользователей также задается по умолчанию (
• После завершения загрузки операционной системы Windows 2003 Server нажать
Здесь:
комбинацию клавиш Ctrl + Alt + Ins и зарегистрироваться в системе как пользователь
1 — контекст Oracle;
«oracle» с паролем «Welcomel».
2 — домен для регистрации базы данных и ролей;
• Подождать, пока стартует экземпляр Oracle.
3 — зарегистрированный экземпляр базы данных;
• С рабочего стола из папки «bats» запустить «start_oid.bat» для старта службы Oracle
4 — соответствие роли и глобальной роли базы данных;
Internet Directory (OID).
5 — соответствие пользователей и общей схемы базы данных;
• Подождать, пока служба OID перейдет в состояние «Started».
6 — база поиска пользователей.

Сетевые настройки
На данномф-* ndu
этапе—-производится
—{_!_) настройка сетевых служб экземпляра базы данных для
IDilahjj«
получения возможности
L
связи со службой каталога OID. Данная процедура выполняется с
помощью служебной a&Wt ------------------
утилиты Net Configuration -—*** Assistant.
1.
[щит*
Запустить Net Configuration Assistant. Start ^ All Programs... ^ Oracle-OraHome92 ^
Or*f irf)crjul£>amjm
Configuration and Migration Tools ^ Net Configuration ' Assistant. В открывшемся окне мастера
выбрать «DirectoryФО ErlirpniB
Usage Rglvi
Configuration», далее — кнопка «Следующий» (рис. 5).
J ,
2. В открывшемся окне j FTtt*piiidL
мастера se,F!nlP
выбрать «Select the directory server you want to use. The
directory server must be(yd User) configured for Oracle usage» («Выберите сервер каталога,
already
который вы хотите использовать. Сервер
uMrl................... T - Tкаталога
— должен быть настроен на использование
сервером Oracle» ), далее —.■J кнопка «Следующий» (рис. 6).
utarJ.........
В открывшемся окне 1выбрать тип каталога — «Oracle Internet Directory».), далее —
3.
кнопка «Следующий» (рис.bY

*..................
I-7). 1
___I и-КГЙ. U, L:-#a L■ ВЛ1
4. В открывшемся окне в поле ввода «Hostname»задать имя сервера, где установлена
служба OID, в полях ввода «Port» и «SSL Port» — номера портов службы OID для обычных и
SSL-соединений соответственно. Вводимые значения должны соответствовать настройкам
( см. табл. 4), далее — кнопка «Следующий» (рис. 8).
5. В открывшемся окне в списке выбора контекста выбрать контекст «cn=OracleContext,
dc=edu,dc=com». Не следует выбирать «cn=OracleContext», который является корневым
Служба KDT зл or a OID Экземпляр БД [ORCL)
контекстом Oracle и предназначен для хранения служебной информации. Далее — кнопка
«Следующий» (рис. 9).
Рис. 4. Схема объектов каталога и базы данных
436 437
Рис. 5. Окно мастера Net Configuration Assistant. Выбор действия
Or л« ftr *4rt I ill Kin AtmtMl: (Hrnfory IA jyr I i -ilinir .tl
L fiOG = * - lF‘ Of г !ЛИЙПП фЦ )Q CC-.mc *lP
■ rates! tnsanecmrys-ew зияешьMMI

flVJE-1 -aiififfi rw MfDTjiifTO Sji OIK te иедк
■ ratetl DД eii€tiorv Sfiftfcl rtu wJrfl И uSg, ind CGffdur* IT-E»

dne-itery ьнггег ret OncH {CitiiiM di irppi riu Osatlo
H-ihtrr-i ind Or-fecte L Pnbsd о пв£ ВS4»rv !■
Create addrt ?na« f.r upgrad* cri&lreg C?*aciB Contort tAdvisrrodi
Create ef урдраê г-.? OwH Schema <Ай#вК1ф
■ гиена \ Г. ^г^дуций J|
Рис. 6. Окно мастера Net Configuration Assistant. Выбор варианта настройки
438
Рис. 7. Окно мастера Net Configuration Assistant. Выбор типа каталога
Рис. 8. Окно мастера Net Configuration Assistant. Сетевая конфигурация
439
6. «Следующий» (рис. 10).

В открывшемся окне мастера убедиться, что контекст выбран верно, далее — кнопка
В открывшемся окне мастера нажать кнопку «Готово». Работа Net Configuration Assistant будет завершена.
7. Следует проверить содержимое файла конфигурации OID ORACLE_HOME\ network\ADMIN\ldap.ora. Для рассмотренного варианта настройки его
содержимое должно быть следующим:
#LDAP.ORA Network Configuration File: E:\ora92\network\admin\ldap.ora
#Generated by Oracle configuration tools.
DEFAULT_ADMIN_CONTEXT = «dc=edu,dc=com»
EDU:4054:4057)
DIRECTORY_SERVERS= (
DIRECTORY_SERVER_TYPE = OID
Указанные настройки могут быть произведены непосредственно перед редактированием файла конфигурации ORACLE_HOME\network\ADMIN\ldap.ora.
Создание общих схем

и глобальных ролей
Данный этап предполагает создание общей схемы, в которой будут работать пользователи, успешно прошедшие аутентификацию и авторизацию в OID. Общая схема может быть получена двумя
путями:
• создана;
• преобразована из обычной схемы.
Оба способа реализуются с помощью SQL-команд CREATE USER или ALTER USER соответственно. Необходимо также создать одну или несколько глобальных ролей, которые будут
использоваться для установки соответствия ролей базы данных и ролей каталога OID. Глобальные роли создаются с помощью SQL команды CREATE ROLE. Все команды должны выполняться от имени пользователя,
имеющего требуемые привилегии.
Рис. 9. Окно мастера Net Configuration Assistant. Выбор контекста.
Рис.
Рис. 10. 11. мастера
Окно Окно SQL-консоли. Соединение
Net Configuration с БД
Assistant. от имени SYS
Завершение настройки
440 441
Рис. 12. Окно SQL-консоли. Создание общей схемы
* Оiii lr Sfl* "Win _d

Г\м«с4. QOMCK ГЦраивтры Справка w i t h t h e
0 1 . О Р з п Ч Oracle d a t a n i n l n g o p t i o n s J S e c v e r
Release b.Z.o.e.o - Production
5(]l> crpate user sharedschotw idPJIt1 f 1 ert globally as
П ол ь з о ват е л ь с о зд а н .
Sfll> grant СОН»Cl,RI$DURC1 to sharedschena;
Прим и .1 et и и предос i анлгни.
Рис. 13. Окно SQL-консоли. Назначение ролей общей схеме
442
♦ Пг.м1г SQt "l’lu%
Гп-и/л г~Ч PiПаедиегр»

I ..npser л
orant COHHF !,(RESOURCEro sharedschona
npeaoc i
S QL > r»t jtobalrolo Identmed globally
Pll.1l.
^ UI I
Рис. 14. Окно SQL-консоли. Создание глобальной роли
1. Запустить SQL-консоль. Start ^ Run... , в поле «Open» указать sqlplusw «/as sysdba».
Откроется окно SQL-консоли, соединенное с экземпляром базы данных от имени поль-
зователя «SYS» (рис. 11).
2. Для создания новой общей схемы выполнить SQL-команду:
CREATE USER <имя схемы> IDENTIFIED GLOBALLY AS";*)
Для преобразования имеющейся схемы в общую выполнить SQL-команду:
ALTER USER <имя-обычной-схемы> IDENTIFIED GLOBALLY AS **>
Например, для создания новой общей схемы с именем «SHAREDSCHEMA» следует

выполнить:
SQL>create user sharedschema identified globally as ‘ ’ (рис. 12).
3. Назначение ролей «CONNECT» и «RESOURCE» в созданной общей схеме для воз-
можности работы (соединение со схемой, создание в ней объектов и т.д.) производится с
помощью SQL-команды GRANT. В рассматриваемом примере:
SQL> grant CONNECT, RESOURCE to sharedschema (рис. 13).
4. Создание глобальной роли БД производится с помощью SQL-команды CREATE ROLE
<имя-роли> IDENTIFIED GLOBALLY. В рассматриваемом примере создать роль с именем «
GLOBALROLE»:
SQL> create role globalrole identified globally (рис. 14).
*) '' — две одинарные кавычки

**) следует иметь в виду, что при преобразовании существующий пароль обычной схемы будет
утерян.
443
Рис. 15. Enterprise Security Manager. Окно регистрации
Рис. 16. Окно консоли Enterprise Security Manager. Объекты схемы
444
Регистрация базы данных

Для регистрации используется служебная утилита Enterprise Security Manager. В данном примере следует зарегистрировать экземпляр базы данных с именем
«ORCL» в домене «OracleDefaultDomain» (домен, создаваемый по умолчанию) в контексте Oracle « dc=edu,dc=com».

1. Запустить Enterprise Security Manager. Start All Programs... ^ Oracle-OraHome92 ^ Integrated Management Tools ^ Enterprise Security Manager. В открывшемся окне регист-
рации выбрать«Password Authentication», ввести требуемые поля (см. табл. 3 и 4) и нажать кнопку «ОК» (рис. 15).
Общий вид консоли Enterprise Security Manager приведен на рис. 16.
A — Дерево объектов контекстов Oracle.
B — Панель свойств выделенного объекта дерева.
С — Меню.
1 — Хост-машина, на которой установлен каталог OID.
2 «edu» (создан при установке OID).

— Контекст Oracle
3 — Домен «OracleDefaultDomain» (пока не содержит ролей).

4 — База поиска пользователей (пользователи должны располагаться ниже в данном под
дереве). При создании пользователей в других поддеревьях, отличительные имена этих поддеревьев должны быть перечислены в данном списке.
5 — Закладка доступных в данном контексте доменов. Вначале пустая.
6 — Версия контекста. По умолчанию версия совместима с Oracle 8i.
7 — Список пользователей, входящих во все базы поиска (4).
2. Добавить домен, в котором будет зарегистрирована база данных («OracleDefaultDomain»), в список доступных доменов контекста «dc=edu,dc=com». Для этого выбрать закладку «Accessible Domains» в панели
свойств контекста «edu» (п. 5 рис. 15).
Рис. 18. Окно консоли Enterprise Security Manager. Диалог регистрации базы данных
Далее — кнопка «Add». В открывшемся окне со списком имеющихся доменов выбрать

«OracleDefaultDomain» и нажать «OK». В списке доступных доменов должен присутствовать
«OracleDefaultDomain», далее — кнопка «Apply» (рис. 17). Нажатие кнопки «Apply» —
обязательно.
3. Выбрать в меню (п. С на рис. 16) «Operations» ^ «Register Database...». В открывшемся окне
заполнить требуемые значения в соответствии с табл. 4*^. В качестве значения кон-
TOU2 л lat'dl-G ».*д1 г it • П" comm p mol m

Ewbfiaa Uftr Stc^wln* rvamn
room?
-
iwp.iimr !r-n м Тля Danari s f
п-зта::-TU Ml*
:■BHflnTVI tolowne SOL □ РВГИШП а пи
rtflfeff UUDW
)4аг (ftiOflCL,
eniQnilHC'flriHri.ar'iflir.dLtrflni' 'tap** ца31р
OK
Рис. 19.Рис.
Окно17.консоли Enterprise
Окно консоли Security
Enterprise Manager.
Security Сообщение
Manager. о регистрации
Список базы данных
доступных доменов
445
446
Oracle Context») выбрать «edu», опционально можно отметить пункт выбора «Store TNS Connect String» (сохранить строку связи в каталоге), далее — кнопка «OK» (рис. 18).
текста («
В случае успешной регистрации базы данных в каталоге Enterprise Security Manager отобразит сообщение о завершающем этапе регистрации (см. п. 3.4). Нажать кнопку
«OK» (рис. 19). При этом значение для «Oracle SID» вводится строго в верхнем регистре.
4. Для завершения регистрации следует установить параметр инициализации «RDBMS_SERVER_DN» (отличительное имя базы данных в каталоге OID) для экземпляра базы данных «ORCL».
Внимание! В связи с тем, что служба каталога OID использует изменяемую

базу данных (текущая конфигурация), перед дальнейшими
операциями следует остановить сервер OID. Для этого
выполнить командный файл «C:\Documents and
Settings\oracle\Desktop\ bats\stop_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). Значение параметра RDBMS_SERVER_DN регистрозависимо и должно
в точности соответствовать указанному в сообщении. Следует обратить внима ние на синтаксис команды: при ее выполнении нужно применять одиночные кавычки для значения параметра, а не двойные, как указано в
сообщении.
Чтобы убедиться в правильности установки, выполнить команду «show parameter rdbms_server_dn» (рис. 20).
5. Запустить сервер OID с помощью выполнения командного файла «C:\Documents and

Settings\oracle\Desktop\bats\stop_oid.bat».
Рис. 20. Окно SQL-консоли. Завершение регистрации базы данных

447
Рис. 21. Окно Enterprise Security Manager. Проверка регистрации базы данных
6. Проверка регистрации базы данных в каталоге:
6.1. Запустить утилиту Enterprise Security Manager. Зарегистрированный экземпляр базы данных должен отображаться в свойствах домена «
OracleDefaultDomain» (закладка «Databases»), при этом его отличительное имя (п. 2 рис. 20) должно в точности совпадать с параметром инициализации
«RDBMS_SERVER_DN» (см.п.3.4).
6.2. Следует убедиться (и в случае необходимости изменить), что значение списка выбора «User Authentication» (п. 1 рис. 21) установлено в «Oracle Wallet
(SSL) and Password» (разрешен вход пользователей по предъявлению имени и однократного пароля).
7. Следует повторно проверить содержимое файла конфигурации OID ORACLE_ HOME\network\ADMIN\ldap.ora (аналогично п. 1.8).
Создание ролей и установление соответствия с глобальными ролями
На данном шаге в каталоге создаются роли и каждой из них ставится в соответствие ранее созданные глобальные роли базы данных (см. п. 2). Пользователи, которым будет назначена созданная роль,
после аутентификации и авторизации в каталоге OID, получат набор привилегий, определяемых соответствующей глобальной ролью (в данном примере это привилегии CONNECT и RESOURCE (см. п. 2)).
1. В окне консоли Enterprise Security Manager выбрать пункт меню «Operations» ^ «Create Enterprise Role...» (п. C рис. 15). В открывшемся окне выбрать
контекст « edu», домен «OracleDefaultDomain» и ввести имя роли, например «EnterpriseUserRole». Далее — кнопка «OK» (рис. 22).
2. В окне консоли Enterprise Security Manager выбрать созданную роль в дереве объектов, в панели свойств роли выбрать закладку «Database Global Roles», нажать
«Add...». В открывшемся окне выбрать «ORCL» (ранее зарегистрированный экземпляр базы данных). В открывшемся окне ввести значения для регистрации в базе данных. В качестве пользователя
кнопку
(«Username») выбирается SYSTEM (см. табл. 3), далее — кнопка «OK» (рис. 23).
448
Рис. 22. Окно Enterprise Security Manager. Создание роли
В открывшемся окне в нижней панели выбрать ранее созданную в п.2 глобальную роль
«GLOBALROLE»,далее — кнопка «OK» (рис. 24).
После закрытия окна выбора ( см. рис. 23) следует нажать кнопку «Apply».
Рис. 23. Окно Enterprise Security Manager. Регистрация в базе данных.
449
Рис. 24. Окно Enterprise Security Manager. Выбор глобальной роли
Рис. 25. Окно Enterprise Security Manager. Создание пользователя

Создание пользователей
3. Далее — как
Пользователи, выбрать указано«Enterprise
былозакладку выше, могут создаваться Roles» . Выбрать
в поддеревьях каталога, кото рые «edu»
имя контекста перечислены из
в списка «Oracle(п. Context»
выбора пользователей
базе поиска и нажать
4 рис. 16). В данном «Add...»
кнопкубудут
примере созданы два .
Из предложенного списка ролей выбрать
с именами «EnterpriseUserRole»
«userl » и «user2» c базой поискаи нажать кнопку «OK». Далее — «OK» (рис. 27).
«cn=Users,dc=edu,dc=com». Обоим пользователям будет
назначена роль «EnterpriseUserRole» и они оба будут работать с базой «ORCL» в общей схеме «sharedschema».
Дополнительные
1.
настройки и соответствия полъзователъ—общая схема
В окне консоли Enterprise Security Manager выбрать пункт меню «Operations» ^ «Create Enterprise User...» (п. C рис. 16). В открывшемся окне выбрать
контекст заполнить
Установкатребуемые
соответствия (закладка «User Naming»
поляпользователь , рис. возможно
— общая схема 25): как для каждого пользователя индивидуально, так и для группы пользователей,
• ниже
находящихся База поиска (Base)
выбранного — «cn=Users,dc=edu,dc=com».
поддерева каталога. В настоящем примере соответствие будет назначено для каждого из созданных пользователей индивидуально.
•1. Имя (First Name) —

Для возможности «userl».
аутентификации пользователей, входящих в базы поиска, следует:
•1.1. Фамилия (Surname)

В консоли — «и»
Enterprise (опционально).
Security Manager в дереве объектов выделить «users» в поддереве «User’s by search base».
•1.2. Идентификатор
В панели свойств
(Userвыбрать
ID) — «userl»
закладку
(может
«Allow
и неDatabase
соответствовать
Access», имени).
отметить пункт выбора «Allows Logon to Authorized Enterprise Domain» и нажать кнопку «Apply» (рис. 28).
•2. Для установки

Суффикс соответствия
(User ID следует:
Suffix) — пустой по умолчанию (опционально).
•2.1. В консоли Enterprise

Email (Email Security
Address) — поManager в дереве
умолчанию объектов выделить «ORCL» в поддереве «Databases». В панели свойств выбрать закладку 'Database Schema Mapping' и нажать кнопку «Add...».
(опционально).
• Общее имя (Common Name) — «userl».
2. «Password». Выбрать пункт «Enter manually» (задать пароль вручную), ввести в поле пароля («New Password») и в
Далее — выбрать закладку
поле подтверждения ( «Verify Password») значение пароля, в данном примере — «Welcome!» (рис. 26).
450 451
Рис. 28. Окно Enterprise Security Manager. Установка возможности аутентификации
Рис. 26. Окно Enterprise Security Manager. Задание пароля

Add DM. Чггггпыт M.itflf«III» |V
сп= От laCorvipJ
сп- ftrjrleSi hem aversion
dcxom
dc*EDU
cn±Cjlend»r Sender
;->i4 tn=Or[)ups '^4
tn-OfMlECOP^rt Э-*
сгг=и*ег?
(■>T4 tri=orcladmln
kn=useM
DireclorvErfly crt=u^flj[ ir-Uiur-i flc = udg.Uc-:C.T,

Subtree Level ■ trv-r -in-:
Si Hfl p 6Н№ВД$СНЕМЛ
f o k j Cancel
l-lr'il
Рис. 29. Окно Enterprise Security Manager. Установка соответствия общей схеме
Рис. 27. Окно Enterprise Security Manager. Задание роли
453
452
Рис. 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. Нажать кнопку «OK» и повторить те же действия для пользователя «user2».
2.6. Нажать кнопку «Apply» (рис. 30).
Тестирование полученной конфигурации
Тестирование полученной конфигурации сводится к проверке собственно возможности
успешной аутентификации пользователей в базе данных, а также проверка использования
общей схемы разными пользователями. Проверка производится с помощью SQL-консоли
(утилита Oracle SQL*Plus).
• Запустить SQL-консоль. Start ^ Run... , в поле «Open» указать «sqlplusw/nolog».
Откроется окно SQL-консоли, не соединенное с экземпляром базы данных.
• Ввести команду соединения с базой данных от имени пользователя «userl».
• SQL> connect user1/Welcome1@orcl.
• Должно отобразиться сообщение об успешной аутентификации/авторизации.
• Ввести 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.
454
Рис. 31. Окно SQL-консоли. Сеанс пользователя userl
.+ |*м1г Ч»'l-liit ,1П) х|

-я I'tJP'e !?^ГГ Пф*ч-гг*4 Si}l У
спите! u-^rrl/1/ГICUfW-lUOKCI
CaPHnUPHP. (,-----------------■ — Усогшнл» «дтммпифммшм
3QL? ib'lrcl 'flflTIT * ~iT~i itlljllh1,1) Imp IJUJI;
SYS^COHI EK.T( ■ uiEflcmj ■, ■ sis? i OHJISCKL >

SHAHT DSCHfin 4----Гщнн eww f*nm
50L> nrlr-ct fj|i ciltiilt'uttnDî'nitffkil UiBh) l i o n iluj] ;
SYS_C(JH1 [ X T (' USE H( MU ■,' IX1ERHAL_HflPlE ' ]
СЧЧ15Я- J, Efl' ll5fr? , Й«- M)4 .flc- ECP fJfJIfllrf |пЩ#ЛМ"0* JrJI* fHflPbOiMiTJIhWfcT
'.Ql > HIKI * fi on

HBI.E +-------------- -------------■----------------- Список ролей
СОНМ г; I Plomi, tahJNJUfMk-biri (KiieitfiJ i"r->i-

HE SDIIRI:I СЕ
HHJHIE
- Г*™М\П+ЩН f'lVTj.. lf.HHj4Dhllv.l-f -YfjtOJ
S0L> | Utyntiy hJflbWlOH (Jfl
Рис. 32. Окно SQL-консоли. Сеанс пользователя user2
455
Должен отобразиться список ролей, назначенных текущему сеансу. В списке должна

присутствовать глобальная роль «GLOBALROLE».
Аналогичную проверку следует провести для пользователя «user2». Результат должен
быть точно таким же, за исключением значения для отличительного имени пользователя (рис.
31 и 32).
Варианты заданий
Вариант 1. Организовать доступ для пользователя «userl» для работы с экземпляром ба-
зы данных Oracle «ORCL» в общей схеме «SHAREDSCHEMA». При успешной установке се-
анса пользователь должен получить роль «GLOBALROLE» и «EDU_ROLE», назначаемые
службой каталога OID. Для учетной записи пользователя в каталоге использовать контекст
Oracle, созданный по умолчанию («edu»). Для регистрации базы данных и создания ролей ис-
пользовать домен по умолчанию («OracleDefaultDomain»). База поиска пользователей зада-
ется новым поддеревом, созданным в произвольной точке дерева каталога в контексте
«edu».
Вариант 2. Организовать доступ для пользователя «userl» для работы с экземпляром
базы данных Oracle «ORCL» в общей схеме «SHAREDSCHEMA». При успешной установке
сеанса пользователь должен получить роль «GLOBALROLE», назначаемую службой
каталога OID. Для учетной записи пользователя в каталоге использовать контекст Oracle,
созданный по умолчанию ('edu'). Для регистрации базы данных и создания ролей создать
новый домен. База поиска пользователей задается новым поддеревом, созданным в
произвольной точке дерева каталога в контексте «edu».
Отчет представляется с титульным листом установленной формы, приведенной в конце
лабораторной работы № 1.
1. Каковы основные компоненты для построения системы аутентификации по одно-
кратному паролю?
2. Назовите основное назначение службы каталога Oracle Internet Directory (OID).
3. Какие методы предлагает система для аутентификации пользователей масштаба
предприятия?
4. Какие объекты каталога отвечают за аутентификацию по однократному паролю?
5. Что такое роль масштаба предприятия?
6. Что такое административные группы?
7. Какую связь описывает соответствие пользователь-схема?
8. Каким образом может быть задано соответствие пользователь-схема?
9. Что такое общая схема? В чем ее отличие от обычной схемы?
10. Что такое глобальная роль базы данных?
11. В чем состоят этапы процесса аутентификации по однократному паролю?
12. Для чего необходима процедура регистрации базы данных в каталоге OID?
13. В какой ветке каталога OID могут быть зарегистрированы пользователи?
14. Какой командой SQL создается общая схема?
15. Какими привилегиями должна обладать общая схема?
16. Какие операции выполняются с помощью утилиты Oracle Enterprise Security Manager?
17. В чем отличие в выборе уровня «Subtree» или «Entry» при задании соответствия
пользователь-схема?
18. В чем преимущество аутентификации по однократному паролю по сравнению с тра-
диционной аутентификацией средствами базы данных?
456
(образец)



ПО ИМЕНИ ПОЛЬЗОВАТЕЛЯ И ПАРОЛЮ
В LDAP-КАТАЛОГЕ

Выполнили:
(Ф.И.О.)
(Ф.И.О.)
Принял:
(Ф.И.О)
(год)
457
НА ОСНОВЕ СЕРТИФИКАТОВ
Изучение системы централизованного управления пользователями, ролями, базами
данных и приложениями, построенной на основе LDAP-каталога Oracle Internet Directory.
Применение методик настройки сервера БД Oracle и клиентских рабочих станций для
аутентификации по цифровым сертификатам, установленным в хранилище файловой
системы, а также на смарт-картах или USB-ключах. Получение навыков работы со
служебными утилитами для конфигурации сервера баз данных Oracle для доступа в СУБД
Oracle по протоколу SSL. Получение общих сведений об инфраструктуре открытых ключей и
смарт-карт-технологии.
Примечание. Установленное на предоставляемом стенде программное обеспечение является собственностью
корпорации Oracle. Данное программное обеспечение может быть свободно загружено с сайта производителя
http://www.oracle. com/technology/software/products/oracle9i/index.html. Перед использованием его в составе данного стенда или
при самостоятельной установке, пожалуйста, ознакомьтесь с лицензионным соглашением по адресу
http://www.oracle.com/technology/ software/popup-license/standard-license.html. Программное обеспечение для функционирования
стенда является собственностью компании 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 (OID).
OID предоставляет возможность использования двух типов аутентификации:
1. Однократный пароль пользователя (в данной лабораторной работе не рассматри-
вается).
2. Сертификат пользователя.
Аутентификация в базе данных по сертификатам пользователя базируется на исполь-
зовании протокола SSL, который помимо сильной аутентификации обеспечивает защиту
канала передачи данных криптографическими методами.
458
Сертификат пользователя
Дает возможность аутентификации во многих базах данных с предъявлением един-
ственного цифрового сертификата пользователя. Данная возможность реализуется в опции
СУБД Oracle Advanced Security. Учетные записи пользователей и сертификаты формата
X.509 хранятся в OID и защищены с помощью контрольных списков доступа (Access Control
Lists — ACL). Схема работы и общая структура объектов каталога OID описана в
лабораторной работе № 5.
Хранилища ключей и сертификатов пользователя

Механизм взаимной аутентификации по SSL-протоколу между клиентом и сервером
предусматривает использование пары открытый—закрытый ключ. Открытый ключ является
составной частью сертификата пользователя и может открыто храниться и передаваться по
незащищенным каналам связи. Закрытый ключ содержит очень важную в плане
безопасности информацию, которая должна быть надежно защищена от компрометации.
Таким образом, выбор способа хранения ключей напрямую влияет на уровень защищенности
информационной системы. Основным хранилищем сертификатов и ключей пользователя, с
которыми может работать ПО Oracle, является ключевой контейнер (wallet), который
физически может существовать как:
• файл операционной системы;
• компонент хранилища сертификатов Microsoft.
Использование файла для хранения ключевого контейнера — наиболее простой способ,
но он обеспечивает наименьшую степень защиты ключевой информации. Защита от
несанкционированного использования обеспечивается парольной защитой. При этом
установлены минимальные требования к качеству пароля. В версии СУБД Oracle 10g
возможно хранение сертификата пользователя (открытый ключ) в файле (с парольной
защитой), а закрытого ключа — на смарт-карте, защищенной PIN-кодом. Такой способ
хранения значительно более надежен. ПО клиента Oracle может работать с ключевым
контейнером в виде файла, только если он имеет имя ewallet.sso. Такой файл не требует
пароля, но при этом доступен только для пользователя операционной системы, от имени
которого и был создан данный файл.
Использование хранилища сертификатов Microsoft также предполагает привязку
ключевого контейнера к учетной записи пользователя операционной системы. Физически в
этом случае ключевая информация хранится в базе реестра ОС Windows и зашифрована на
ключе конкретного пользователя. После успешной аутентификации пользователя на рабочей
станции ключевая информация расшифровывается и становися доступной для дальнейшего
использования, в том числе и для ПО Oracle.
Оба рассмотренных типа хранилищ имеют существенный недостаток — привязку к
четной записи операционной системы. Это прежде всего снижает общую защищенность
информационной системы, так как отсутствует дополнительное ограничение доступа
«пользователь ОС — пользователь ИС». Существуют и трудности в администрировании
клиента Oracle — необходимо поддерживать в актуальном состоянии все ключевые
контейнеры на рабочей станции для всех учетных записей, а также предусмотреть
соответствующие каждому пользователю сетевые настройки ПО клиента Oracle.
Указанные недостатки отсутствуют в хранилище ключевой информации, расположе- ном
полностью на аппаратном носителе — смарт-карте или USB-ключе eToken (производитель
Aladdin Knowledge Systems). Для использования такого хранилища требуется
дополнительное ПО (SecurLogon for Oracle от Aladdin Software Solution R. D.). Сетевые
459
настройки в данном случае не отличаются от

настроек с использованием хранилища
Microsoft, но в процессе аутентификации
ключи и сертификаты выбираются из фи-
зического хранилища — смарт-карты или USB-
ключа. Такую возможность обеспечивает
SecurLogOn for Oracle, расширяющий
возможности штатного механизма поиска
ключей и сертификатов (рис. 1).
Рис. 1. Механизм расширения штатных
возможностей Oracle Advanced Security Процесс настройки и дальнейшей
аутентификации пользователя с цифровым
сертификатом, установленным на смарт-
карте (рис. 2)
дминистратор БД настраивает сетевую

конфигурацию экземпляра базы данных для
взаимодействия со службой каталога OID.
Это может быть сделано вручную (редакти-
рование файла конфигурации) или с по-
мощью служебной утилиты Net
Configuration Assistant. Настройка заключа-
ется в указании имени компьютера (IP-ад-
реса), на котором функционирует OID, но-
меров портов, назначенных OID, а также
имени контекста Oracle (корневого элемен-
та каталога). В задачи администратора БД
входит также создание общих схем и гло-
бальных ролей.
Пользователь, являющийся членом груп-
пы OracleDBCreators, регистрирует экземп-
ляр базы данных в каталоге OID. Регистра-
Рис. 2. Настройка аутентификации ция экземпляра базы данных делает доступ-
с использованием цифрового сертификата ным получение информации о
пользователях, ролях, соответствиях схем
и т.д., хранящейся в каталоге OID, для дан-
ного экземпляра. Процесс регистрации создает объект «база данных» в выбранном кон-
тексте Oracle и вносит в каталог необходимую информацию, однозначно определяющую
указанный экземпляр. Завершением процесса регистрации является внесение отличи-
тельного имени (DN) базы данных в параметры инициализации сервера. Взаимодейст-
вие сервера базы данных и службы каталога OID происходит по защищенному прото-
колу (SSL) и только после успешной взаимной аутентификации также по SSL-протоко-
лу. Для осуществления SSL-аутентификации экземпляр сервера БД использует
ключевой контейнер (т.н. wallet), содержащий открытый и закрытый ключи, а также сер-
тификат базы данных. Аналогичный ключевой контейнер имеет и служба каталога OID.
Для регистрации используется служебная утилита Enterprise Security Manager.
Администратор БД или администратор безопасности с помощью утилиты Enterprise
Security Manager создает в каталоге OID (если это необходимо) домены, роли и пользователей.
460
Пользователь инициирует соединение с базой данных, используя файл, смарт-карту или

USB-ключ с установленным на них личным ключом и сертификатом.
База данных проводит процесс аутентификации и авторизации пользователя, включающий
следующие шаги:
• аутентификацию пользователя по SSL- протоколу;
• поиск учетной записи по отличительному имени (DN), извлекаемому из поля Subject
предъявленного сертификата;
• поиск общей схемы в каталоге OID;
• извлечение ролей пользователя и соответственное назначение глобальных ролей для
установленного сеанса пользователя.
Общие рекомендации
Настоящая лабораторная работа выполняется только при успешном выполнении ла-
бораторной работы № 5 (Доступ в СУБД Oracle аутентификацией по имени пользователя и
паролю в LDAP-каталоге). Стенд, подготовленный и настроенный в рамках выполнения
лабораторной работы № 5, должен быть запущен в соответствии с инструкциями раздела
«Подготовка к работе».
Подготовка клиентского стенда

для выполнения работы

• Процессор PIV-1400 и выше, 1024M RAM — и более, 12 Gb дискового пространства.
• OS Windows 2000/XP, клиентское ПО VMWare (6.0.0 и выше).
Установка виртуальной машины
1. Распаковать архив с образом виртуальной машины на жесткий диск хост-машины

(например, в каталог D:\VM\CLIENT). Архив с образом виртуальной машины находятся на
демонстрационном диске в каталоге \VM\CLIENT. Архив содержит файл
winXP_SP2_Oracle10_client_edu.vmdk.
2. Для размещения файлов конфигурации виртуальной машины создать каталог
D:\VM\CLIENT\CFG.
3. Запустить клиент VMWare. Из меню консоли VMWare выбрать File->New... ^ Virtual
Machine.
4. В открывшемся окне мастера выбрать «Next».
5. В открывшемся окне «Select the Appropriate Configuration» выбрать «Custom», далее
— «Next».
6. В открывшемся окне «Select a Virtual Machine Format» выбрать «New — Workstation 6»,
далее — «Next».
7. В открывшемся окне «Select a Guest Operating System» выбрать «Microsoft Windows» в
панели «Guest Operating System», а в списке выбора «Version» — «Windows XP Professional»,
далее — «Next».
461
Рис. 3. Виртуальная машина стенда
8. В открывшемся окне «Name the Virtual Machine» ввести имя (например, «EDU-Oracle-
Client») в поле ввода «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 Type» выбрать «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\CLIENT\winXP_SP2_Oracle10_client_edu.vmdk»), далее — «Finish».
Консоль VMWare отобразит созданную виртуальную машину (рис. 3).
462
«Гостевая» операционная система Windows XP Professional SP2
ПО Oracle Oracle Client Runtime 10g (10.2.0.1)
Служба Описание
Aladdin SecurLogon for ORACLE Служба поддержки аутентификации в Oracle по

смарт-картам или USB-ключам eToken
eToken Notification Service Служба оповещений eToken RTE
Таблица 2
Службы, запускаемые на стенде (автоматически)
Administrator Welcomel Администратор ОС
oracle Welcome1 Пользователь ОС
Таблица 3
Учетные записи и пароли пользователей
Параметр Значение Описание
ORACLE_HOME C:\oracle\ora10 Директория установки ПО Oracle
Сетевые алиасы (описатели соединений в ORACLE_HOME\network\admin\tnsnames.ora)
EDU Для соединения с БД по обычному протоколу

Таблица 4
EDULSSL
Параметры сервера Для
БД исоединения с БД поOID
службы каталога SSL протоколу
Ключевые Используются для установления защищенного соединения и взаимной аутен-

контейнеры тификации клиента и базы данных (только для тестов). Размещается в каталоге
(wallets) «C:\oracle\WaUets\ordadmm». Пароль к ключевому контейнеру «Welcomel».
Таблица 5
Другие параметры стенда
Параметр Значение
IP адрес/маска подсети 192.168.12.200/255.255.255.0
Имя компьютера/имя рабочей группы EDU-CLIENT/EDUCATION
Таблица 6
Сетевые настройки операционной системы стенда
463
Задание
Для пользователя «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» задать имя точки отката и опци-
ональное описание, нажать «OK».
Рис. 4. Схема объектов каталога и базы данных (аналогично лабораторной работе № 5).
464
Запуск виртуальной машины

и сеанса пользователя
1. В окне консоли VMWare (рис. 3) в панели «Commands» выбрать «Start this virtual
machine».
2. После завершения загрузки операционной системы Windows XP Professional нажать
комбинацию клавиш Ctrl + Alt + Ins и зарегистрироваться в системе как пользователь
«Oracle» с паролем «Welcomel».

Настройки сетевых дескрипторов
На данном этапе производится настройка сетевых дескрипторов клиента Oracle для
связи с базой данных. Настраиваются два дескриптора: для обычного и SSL-протоколов.
Параметры сетевых служб сервера приведены в табл. 4 лабораторной работы № 1. Про-
цедура настройки выполняется с помощью служебной утилиты Net Configuration Assistant.
1. Запустить Net Configuration Assistant. Start ^ All Programs... ^ Oracle-OraClientlOg ^
Configuration and Migration Tools ^ Net Configuration Assistant. В открывшемся окне мастера
выбрать «Local Net Service Name Configuration», далее — кнопка «Следующий» (рис. 5).
2. В открывшемся окне мастера выбрать «Add» («Добавить» ) из предлагаемых вари-
антов выбора, далее — кнопка «Следующий» (рис. 6).
Рис. 5. Окно мастера Net Configuration Assistant. Выбор действия
465
Рис. 6. Окно мастера Net Configuration Assistant. Выбор добавления сетевого дескриптора
3. В открывшемся окне задать в поле ввода «Service Name» имя экземпляра базы данных — « ORCL».), далее — кнопка «Следующий» (рис. 7).
Рис. 7. Окно мастера Net Configuration Assistant. Задание имени экземпляра базы данных
466
Рис. 8. Окно мастера Net Configuration Assistant. Задание протокола
4. В открывшемся окне выбрать «TCP» из списка протоколов. Далее — кнопка «Следующий» (рис. 8).
5. «Host name» ввести имя сервера, где установлен сервер базы данных Oracle — «EDU», из вариантов выбора порта указать «Use the
В открывшемся окне в поле ввода
standard port number of 1521» («Использовать стандартный номер порта 1521»). Далее — кнопка «Следующий» (рис. 9).
Рис. 9. Окно мастера Net Configuration Assistant. Задание параметров сервера базы данных
467
Рис. 10. Окно мастера Net Configuration Assistant. Тест соединения
6. В открывшемся окне мастера выбрать «No, do not test» («Нет, не тестировать»), так как тестирование соединения с базой данных будет сделано позднее. Далее — кнопка
«Следующий» (рис. 10).

7. В открывшемся окне мастера в поле ввода «Net service Name» задать имя дескриптора, например, «EDU». Далее, кнопка «Следующий» (рис. 11).
Рис. 11. Окно мастера Net Configuration Assistant. Имя дескриптора
468
Рис. 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\ora10\network\admin\tnsnames.ora
# Generated by Oracle configuration tools.
EDUSSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = EDU)(PORT = 2484))

)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
(SID = ORCL)
)
(SECURITY=
469
(AUTHENTICATION_SERVICE = TCPS)
(SSL_SERVER_CERT_DN=«cn=ORCL,cn=OracleContext,dc=edu,dc=com»)
)
)
EDU =
(DESCRIPTION =
(ADDRESS_LIST =
(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. Установить
Рис. параметр
14. Окно Net Manager,конфигурации «Oracle Advanced
объект «Profile».вНастройка Security»
«Oracle Advanced (п.1 рис. 14), вы-
Security»
брать закладку «SSL’. Переключатель типа конфигурации «Configure SSL for» (п.3 рис. 14)
установить в «Client». В списке выбора «Credential Configuration» (п. 2 рис. 14) выбрать «Microsoft Certificate». Установить значение в списках выбора пп.4, 5, 6 в значения, ука-
занные на рис. 14.
3. В меню Net Manager выбрать File Save

Network Configuration. Затем, File Exit.
Работа мастера будет завершена.
4. Следует проверить созданный файл конфигурации ORACLE_HOME\network\ADMIN\ sqlnet.ora. Для рассмотренного варианта настройки
сервера его содержимое должно быть следующим:
--------начало файла sqlnet.ora---------------------------------------------------------------------
# sqlnet.ora Network Configuration File: c:\oracle\ora10\NETWORK\ADMIN\sqlnet.ora
# Generated by Oracle configuration tools.
SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)
SSL_VERSION = 3.0
SSL_CLIENT_AUTHENTICATION = TRUE SSL_SERVER_DN_MATCH = Yes WALLET_LOCATION =
(SOURCE =
(METHOD = MCS)
)
--------конец файла sqlnet.ora----------------------------------------------------------------------
Рис. 13. Окно Net Manager, объект «Profile». Настройка «Naming»

471
470
Создание ключевого контейнера (wallet) для пользователя «userl» и его установка на смарт-
карту или USB-ключ eToken
Для создания wallet используется служебная утилита Wallet Manager. Данный этап подразумевает следующие процедуры:
• генерация ключевой пары (закрытый — открытый ключ);
• генерация запроса на сертификат для пользователя userl (cn=user1, 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» (пароль ключевого контейнера), в данном примере — «Welcomel» и «Confirm Password» (подтверждение
введенного пароля). Следует обратить внимание на требования по качеству пароля. Пароль должен быть длиной не менее 8 символов, содержать как буквы, так и цифры и спе циальные символы. В списке «Wallet
type» (тип контейнера) следует выбрать «Standard». Далее, нажать кнопку «ОК» (рис. 15). Будет создан «пустой» контейнер, содержащий лишь сгенерированную пару открытый/закрытый
ключ.
2. В открывшемся окне диалога с подтверждением создания Wallet и запросом подтверждения на создание запроса на сертификат пользователя следует выбрать «Да» (рис. 16).
Рис. 15. Wallet Manager. Пароль для ключевого контейнера
472
Рис. 17.3. Wallet Manager. Сообщение об успешном создании запроса

Рис. 16. Wallet Manager. Создание запроса на сертификат пользователя
3. «Key Size» (длина открытого ключа (бит)) выбрать 1024 и, не заполняя остальные поля, нажать кнопку «Advanced» (рис. 17.1). В от-
В открывшемся окне диалога в списке
DN' ввести отличительное имя пользователя «userl», т.е. его полное имя в каталоге OID (см. рис. 4 и лабораторную работу № 5) — «cn=user1,
крывшемся окне диалога ввести в поле ввода '
cn=users, dc=edu, dc=com». Регистр символов не учитывается. Далее — кнопка «OK» (рис. 17.2). В открывшемся окне сообщения о создании запроса на сертификат пользователя
нажать «OK» (рис. 17.3).
Рис. 18. Wallet Manager. Запрос на сертификат пользователя создан
4. После создания запроса на сертификат окно Wallet Manager будет следующий вид
(рис. 18):
1. ОбъектРис. 17.1. Wallet
запроса наManager. Запрос
сертификат параметров сертификата
пользователя пользователя
(статус сертификата — «Requested» (за
прошен)).
2. Список сертификатов доверенных удостоверяющих центров, добавляемый
автомати
чески.
3. Имя пользователя, для которого сформирован запрос.
4. Параметры открытого ключа.
5. Содержимое запроса на сертификат в .Ь64-кодировке.
5. Сертификаты доверенных удостоверяющих центров, которые были добавлены ав-
томатически, следует удалить для уменьшения суммарного размера ключевого контей
Рис. 17.2. Wallet Manager. Запрос отличительного имени пользователя
474
473
нера. Это важно, если в дальнейшем ключевой контейнер предполагается импортировать на аппаратный носитель. Для удаления сертификатов следует воспользоваться контекстным меню удаляемого доверенного
сертификата, либо из меню «Operations» ^ «Remove Trusted Certificate» (рис. 19.1 и 19.2). В окне подтверждения на удаление доверенного сертификата следует выбрать «Да».
6. После удаления всех доверенных сертификатов следует добавить в список серти фикат тестового удостоверяющего центра (УЦ). Файл с сертификатом тестового УЦ —
C:\oracle\wallets\CA-EDU.cer. Импорт сертификата производится из меню Wallet
flail* Coer aeons нищ
Certmcaie (Requested Certificate
Trustee Certificates
Ctj:;s l Pub" г Primary CsrliliLili
L - i o't i ru sted C e-rf--1- ■! ate
- I.1JS .■ Puhf( PrirtiaiVirertincJilii
Rerf".raTriisteiceiuriLjM
-"SdMi3Pu(l : Prinnanr Certified
-"SSecuf e 3em*r C ertiflc aBon Auffiontf
VglSlOO
C>berTrus[£r)9l
Cube iTrust Global Rom
serin Hi?mtiei
Рис. 19.1. Wallet Manager. Удаление доверенного сертификата
fiP0r«te WflWt Mwp

й/э™ unsraDons b«=yp
yf-^y Add £? rtfUal? Rfitiwasl
Import У EerCertmc ate

import iPtrsiHl emocete
Tic alon AJ
кадпор uartmcaite Resueas
■ ib -.г.
Ppmrn user С-яптПсМ?
ntat an
Рещсрге Trusted свгиПЕ iv*
■jmanh'
6 доп иаег оагилсак
F rpgrl L MflCno Hijutst
Еччзп Trusted Cflrtfflir^TR fbnciiimn

Export £Л Три Ым! Cm ates иф(2(М(
Export pallet им cati
(ш
Рис. 19.2. Wallet Manager. Удаление доверенного сертификата
475
Manager («Operations» ^ «Import Trusted Certificate...») или из контекстного меню списка

доверенных сертификатов («Import Trusted Certificate...») (рис. 20.1). В открывшемся окне
диалога выбора источника для импорта выбрать «Select a file that contains the certificate» и
нажать «OK» (рис. 20.2). В открывшемся диалоге выбора файла выбрать файл с
сертификатом и нажать «Открыть». Сертификат с именем «For Education Purpose only» должен
появиться в списке доверенных сертификатов (рис. 20.3).
7. Далее следует сохранить содержимое запроса на сертификат в файле для после-
дующей отправки в тестовый УЦ. Экспорт запроса производится из меню Wallet Manager
(«Operations’ -> «Export Certificate Request...») или из контекстного меню для запроса («Export
Certificate Request...) (рис. 21.1). В открывшемся диалоге выбора места сохранения,
позиционироваться на предварительно созданную директорию (например,
C:\oracle\wallets\user1), выбрать имя файла (например, userl-req.csr) и нажать «Сохранить»
(рис. 21.2).
Рис. 20.3. Wallet Manager. Импорт доверенного сертификата

i i!. re- >talp
-
Hd faquKl
!“■ irKipop Цви СегОИ*1н
' ■ Intpnd Jhiried Cwtrtlcite
Ciflrileart R r-;.ir
it
ч geftiave Usan С.еп/Г':*!
й TruHPd
1?1
E^nortUsei СечШаПе
Enrol СвПЙШв
Erpon “'utled C en-Uile
Evporr fft Trusted
Cartel
EJHOI: ala
й a
Рис. 21.1. Wallet Manager. Сохранение запроса на сертификат

8. Сохранить созданный Wallet с помощью меню «Wallet» ^ «Save as...». В открывшемся окне диалога выбора директории для сохранения позиционироваться, например, на
директорию C:\oracle\wallets\user1 и нажать «OK» (рис. 22).
Получение сертификата пользователя, подписанного доверенным УЦ

1. Запустить web-браузер (например, Microsoft Internet Explorer). В адресной строке ввести URL web-страницы тестового УЦ, который развернут на сервере EDU — «http://edu/certsrv/» (рис. 23). На
открывшейся домашней странице тестового УЦ выбрать ссылку «Request a certificate» (запрос сертификата). На открывшейся странице вы

477
476
брать ссылку «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
(CMC 2. или
В окне PKCS#10 утилиты файл) или послать
Wallet Managerзапрос на обновление
выполнить сертификата всертификата
импорт полученного base-64 коди- в
ровке (PKCS#7 файл)). На открывшейся странице
ключевой контейнер. Для этого выбрать пункт меню «Operations» -> «Import выбрать ссылку «Browse for file to insert User».
На запрос системы
Certificate...», безопасностипункт
либо аналогичный о разрешении выполнения
контекстного ActiveX-скрипта
меню объекта ответить
«Certificate» «Да»На
(рис. 24.1). .В
поле ввода
запрос «Full path
о способе name»
ввода ввести полное
сертификата выбратьимя файла
«Selectс запросом
a file thatнаcontains
сертификат the (см. п. 3.7)
ertificate»
либо воспользоваться
(выбрать файл, содержащий кнопкой «Обзор...»идля
сертификат) поиска
нажать «OK» файла, далееВ—
(рис. 24.2). диалоге «Read!»файла
кнопкавыбора (рис.
23.1). Полесохраненный
выбрать ввода текста сертификат «Saved request» должно заполниться
(user1-cer.cer) и нажать содержимым запроса, далее
«Открыть». Сертификат будет—
кнопка «Submit»
импортирован в. На Wallet, и окно Wallet
открывшейся Manager
странице выбратьбудет «Base 64 encoded»
соответствовать
пункт рис. и24.3.перейти Статуспо
ссылке «Download (п. 1) изменился
Certificate»на (рис. (готов).
«Ready»23.2). В списке доверенных
В открывшемся сертификатов
окне системы безопасности (п. 2)
только
выбрать один сертификат
«Сохранить» тестового
. На УЦ. Поле «Subject
запрос директории » сертификата
и имени (п. 3) точно
файла указать соответствует
« C:\oracle \wallets\user1» и
отличительному
«userl-cer.cer» соответственно. имени пользователя
Закрыть окно«user1»
браузера. в каталоге OID. На закладке перечислены
остальные свойства сертификата (п. 4).
3. Сохранить ключевой контейнер с помощью команды меню «Wallet» ^ «Save». Также в
данном меню необходимо отметить пункт выбора «Auto Login» (рис. 25). Далее, завершить
|,.‘3, *43 !>!Л|
работу Wallet Manager — «Wallet» ^-«Exit».
После Ц-in С ИГЕ га работы Wallet Manager, директория C:\oracle\wallets\user1 должна
' пдалзавершения
"L ■■ подл
содержать Iniuta с f'tfcфайлы:
следующие JH
• ewallet.p12 — ключевой контейнер, готовый к использованию для аутентификации

Р&Ф1Т»» С it» FiTi»i1
9 клиента;
[Jn'i.flrl Ulll' CEftflCItt
■Згшп** TnrttrS CurtfE-
? tlr
q-чи.п i ■ iir Ciinar j1» ijjiir.ii ■; FIT*C Гг
гр ^
HI
iippgrl Trjltlfl Cd^-' Vd

F чип 4ii Гпх*М Ctrtrti io:
E.-pnrl fUlM
Рис. 23.1. Тестовый удостоверяющий центр. Издание сертификата пользователя
Рис. 24.1. Wallet Manager. Импорт сертификата пользователя
Рис. 23.2. Тестовый

Рис. 24.2. удостоверяющий
Wallet Manager. Импорт
центр. Издание
480 479
Рис. 24.3. Wallet Manager. Готовый ключевой контейнер
Рис. 25. Wallet Manager. Сохранение ключевого контейнера. Завершение работы
• cwallet.sso — копия ewallet.p12, используемая для открытия контейнера без предъ-

явления пароля. Действительна только для пользователя, создавшего данный файл
(т.е. для пользователя «oracle»);
• userl-req.csr — запрос на сертификат пользователя «userl»;
• userl-cer.cer — подписанный сертификат пользователя «userl».
4. Для аутентификации с использованием смарт-карты или USB-ключа eToken следует
импортировать созданный ключевой контейнер на аппаратный носитель. Для этого
необходимо скопировать файл ключевого контейнера в файл с расширением .pfx (на-
481
пример, в файл ewallet.pfx, расположенный в директории, в которой был сохранен

ewallet.p12). Далее, в проводнике windows выделить файл ewallet.pfx, и из контекстного меню
выбрать пункт «Install PFX» (рис. 26.1).
5. В открывшемся окне мастера импорта нажать кнопку «Далее».
6. В следующем окне выбора импортируемого файла проверить полный путь к файлу
«ewallet.pfx» и нажать кнопку «Далее» (рис. 26.2).
Рис. 26.1. Импорт ключевого контейнера. Запуск мастера.
Рис. 26.2. Импорт ключевого контейнера. Выбор файла
482
Рис. 26.3. Импорт ключевого контейнера. Пароль для ключевого контейнера
7. В открывшемся окне мастера ввести пароль ключевого контейнера (в данном примере

— «Welcomel»), отметить пункт выбора «Пометить этот ключ как экспортируемый...» и нажать
кнопку «Далее» (рис. 26.3).
Замечание. Хотя закрытый ключ при импорте на смарт-карту помечается как экспортируемый, он остается
недоступным для копирования со смарт-карты или перемещения на другой носитель.
8. Вставить смарт-карту eToken в устройство для считывания или подключить USB-ключ

в USB-порт компьютера. Консоль виртуальной машины должна распознать подключенное
оборудование и отобразить иконку подключения. В меню консоли виртуальной машины
«VM» ^ «Removable Devices» ^ «USB Devices» должен быть отображен отмеченный пункт
«Aladdin Knowledge USB device (Port 1)» (рис. 26.4). Если данный пункт не отмечен, то
отметить его.
9. В окне выбора хранилища сертификатов мастера выбрать пункт «Поместить все
сертификаты в следующее хранилище» и нажать кнопку «Обзор...». В окне выбора хра-
нилища отметить пункт «Показать физические хранилища», в панели дерева хранилищ
выделить «Личные» «eToken» и нажать кнопку «OK», затем кнопку «Далее» (рис. 26.5).
10. В окне завершения работы мастера нажать кнопку «Готово» (рис. 26.6)
11. В открывшемся окне запроса PIN-кода смарт-карты или USB-ключа eToken ввести
валидный PIN-код и нажать кнопку «OK» (рис. 26.7). PIN-код для смарт-карты или
483
USB-ключа eToken задается при инициализации (форматировании) данного устройства

администратором, по умолчанию задается «1234567890».
Рис. 26.4. Импорт ключевого контейнера. Подключение смарт-карты или USB-ключа
Рис. 26.5. Импорт ключевого контейнера. Выбор хранилища.
484
12. В окне сообщения Тестирование SSL-аутентификации

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

механизмом, используемым в Oracle. Возможность соединения с базой данных следует
проверить с помощью утилиты SQL*Plus. Для установления соединения нужно исполь-
зовать сетевой дескриптор с именем «EDUSSL», настроенный в п. 1. Перед тестированием
требуется коррекция файла сетевой настройки клиента Oracle
(ORACLE_HOME\network\ADMIN\sqlnet.ora), в нем следует указать корректный тип поиска wallet — файл.
1. В текстовом редакторе открыть c:\oracle\ora10\network\ADMIN\sqlnet.ora. Изменить фрагмент
настройки
WALLET_LOCATION =
(SOURCE =
(METHOD = MCS)
)
на
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = c:\oracle\wallets\user1)
)
)
Рис. 26.6. Импорт ключевого контейнера. Завершение работы мастера

Сделанные изменения следует сохранить.
2. Провести тест соединения с базой данных по SSL-протоколу:
• Запустить SQL-консоль. Start ^ Run... , в поле «Open» указать «sqlplusw /nolog».
• Ввести команду соединения с базой данных с использованием ключевого контейнера
пользователя «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.
Рис. 26.7. Импорт ключевого контейнера. Ввод PIN-кода
486 485
t №*cle ■&!)(’'PtiH-
■J>" Q.W, ГЦрАМТ^г VTJ nr-f !■
S0l> совпрЦ /Г4г ilii-я^ J C[Vt litfEND - i
-------------------------------------—----------------"
---------------1 УСПППЫШТ! .ТуДП'ГНЛ141[^Л1|
ИиГПГ
SOI.* stint ■ii'if-K-rtm'.■Ê,^,;Jcr»_uiri " | Frnn rtEial”
a»s_ciMi LKI [1 HI hn ’ r<scss i MJIIEI1 >
SHAHI fr^CM L 14» <; Т*куLUl* CVt-JlT ГММЫ
SOU sf 1 и;t i)i^_cHkfxt{'iKfrtn‘.'«timiiljiiM') Fm EIIJ.H;
SYS_CD HI F КI { ' USE -HI HU' . ' EX ГIRHHI _I40MI ' )
WUHli.CA'UlIH, ElC-fdLI.El£-fBI1 0|ЦЯ1гЧ1М1МЛк)гЛ» JhUV MAMMUJIMlIf
S O I > E f l r t l ■ ( J O I I -VO-1. ^ к U ll rolrtj

KOLl ^-------------------— ----------------------------------CmirDupo™
---------■ fhvi.'l. ii.MraJUMF-lnir общи/
COhKCl i
RE СЕШНСЕ
^ Ct niRflL
- ГЛМЫ\ПЫ*?а pCtfl\L, kjl-JMV4L' W h i> •
HOl£
VTjtT.i t Jtyuriy pumJflWrt (ЧП
Рис. 27. Окно SQL-консоли. Результат теста
Тестирование SSL аутентификации

с использованием смарт-карты или USB-ключа eToken
Использование смарт-карты или USB-ключа eToken для аутентификации требует

установки дополнительного ПО на стороне клиента Oracle. Возможность соединения с базой
данных проверяется также с помощью утилиты SQL*Plus. Для установления соединения
нужно использовать сетевой дескриптор с именем «EDUSSL», настроенный в п.1. Перед
тестированием требуется коррекция файла сетевой настройки клиента Oracle
(ORACLE_HOME\network\ADMIN\sqlnet.ora), в нем следует указать корректный тип поиска wallet —
хранилище Microsoft, которое расширено для возможности чтения ключей и сертификатов с
физического хранилища — смарт-карты или USB-ключа eToken.
1. В текстовом редакторе открыть c:\oracle\ora10\network\ADMIN\sqlnet.ora. Изменить фрагмент
настройки
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHODDATA =
(DIRECTORY = c:\oracle\wallets\user1)
487
)
)
на
WALLET_LOCATION =
(SOURCE =
(METHOD = MCS) # MSC — Microsoft Certificate Store )
Сделанные изменения следует сохранить.

2. Провести тест соединения с базой данных по SSL-протоколу:
• Запустить SQL-консоль. Start ^ Run... , в поле «Open» указать «sqlplusw/nolog».
• Вставить смарт-карту 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», «external_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
1. Каковы основные компоненты для построения системы аутентификации с исполь-
зованием PKI?
2. Основное назначение службы каталога Oracle Internet Directory (OID).
3. Какие методы предлагает система для аутентификации пользователей масштаба
предприятия?
4. Какие объекты хранятся в ключевом контейнере (wallet)?
5. В чем состоят этапы процесса аутентификации по сертификату пользователя?
6. Для чего необходима процедура регистрации базы данных в каталоге OID?
7. Какова роль УЦ в организации PKI аутентификации?
8. Что такое доверенный сертификат?
9. Какими недостатками обладает хранение ключевой информации в файлах ОС?
10. Преимущества в плане безопасности при PKI-аутентификации.
11. Преимущества использования смарт-карт или USB-ключей при хранении ключевого
материала.
12. Назовите общие шаги по изданию сертификата для пользователя.
(образец)


ДОСТУП В СУБД ORACLE C АУТЕНТИФИКАЦИЕЙ

НА ОСНОВЕ СЕРТИФИКАТОВ

Выполнили:
(Ф.И.О.)
(Ф.И.О.)
Принял:
(Ф.И.О)
(год)
490
РЕЖИМЫ РАБОТЫ ПРОТОКОЛА 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 (AH) — обеспечивает условия для аутентификации и защиты
данных.
Протоколы защиты передаваемого потока данных могут работать как в транспортном, так
и в туннельном режиме. При работе в транспортном режиме IPSec обрабатывает только
информацию транспортного уровня — данный режим рассчитан на работу между
пользователями. В туннельном режиме с целыми IP-пакетами. IPSec в режиме тунне-
лирования в основном используется на шлюзах безопасности для конфиденциальной и
достоверной доставки информации между двумя территориально удаленными сегментами
локальной сети. Шлюзы безопасности также могут использовать транспортный режим, но
только в том случае, когда они выступают в роли хоста.
IPSec обеспечивает аутентификацию, целостность и шифрование путем добавления
одного или двух специальных заголовков в IP-дейтаграмме.
Протокол AH обеспечивает аутентификацию и проверку целостности в IP-дейтаграммы.
Аутентификация означает, что роследня действительно была послана истин-
491
ным отправителем, а целостность — не была изменена в процессе передачи данных по сети.

Протокол ESP обеспечивает шифрование содержимого дейтаграммы, а также аутен-
тификацию и проверку целостности. AH и ESP используются между двумя хостами, которые
могут быть конечными станциями или шлюзами.
Существует несколько режимов защиты данных IPSec:
• ESP c проверкой целостности;
• ESP без проверки целостности;
• ESP+AH (шифрование плюс проверка целостности);
• AH (проверка целостности).
Протокол управляет ключами и используется совместно c IPSec, предоставляя до-
полнительные возможности, гибкость и упрощение конфигурации для стандартов IPSec.
Работа IKE состоит из двух фаз:
— установка ассоциаций безопасности (security associations (SA)) между двумя кли-
ентами;
— установка связи между двумя SA и генерация ключевой пары для IPSec.
При этом используются два метода IKE аутентификации:
— с помощью предопределенного ключа (Pre-Share IKE Authentication);
— с помощью цифровых сертификатов (Digital Certificates IKE Authentication).
Для того чтобы оценить возможность установки IPSec-криптотуннеля между марш-
рутизаторами при использования модуля NME-RVPN, требуется проверить:
— метод аутентификации IKE, основанный на использовании предопределенного
ключа;
— метод аутентификации 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 AH и/или IPsec ESP;
• пакетную фильтрацию трафика с использованием информации в полях заголовков
сетевого и транспортного уровней:
— на сетевом уровне — по IP v4 адресам и/или полю «протокол» IP заголовка;
— на транспортном уровне — по направлению установления TCP соединений и
составу сервисов (сервисных протоколов);
• загрузку политики из внешнего файла;
• различные наборы правил обработки трафика на различных интерфейсах;
• получение сертификатов открытых ключей по протоколу LDAP;
• событийное протоколирование, которое может быть интегрировано с событийным
протоколированием маршрутизатора;
• реализацию заданной дисциплины взаимодействия (аутентификацию и/или защиту
трафика) для каждого защищенного соединения, доступ в заданном защи
492
№ Наименование Краткое описание Производитель, ссылка
1 Модуль NME-RVPN
Программно-аппаратное решение
www.s-terra.com
(предмет исследования для
лабораторной работы)
2 Cisco 2821 С2800 Software Маршрутизатор Cisco www.cisco.com
(C2800NM-IPVOICE-M), Version
12.4(9.9)PI5
3 Cisco 7206 С7200 Software (C7200- Маршрутизатор Cisco www.cisco.com
JS-M), Version 12.3(18)
4 Catalyst 3560; C3560 Software Коммутатор Cisco www.cisco.com
(C3560-ADVIPSERVICESK9-M),
Version 12.2(25)SEE
5 Рабочие станции с сетевой картой Рабочие станции (как конечные
10/100/1000 BaseTX сетевые устройства)
IP-телефоны Cisco IP-телефоны Cisco (любые модели), www.cisco.com
6 например, 7941 или 7961
7 Кабельное оборудование (UTP Кабельное оборудование (провода
кабель САТ5) для соединения)
Программа Iperf v 1.7 (для генерации ПО http://dast.nlanr.net/projects/
8 трафика) Iperf/iperfdocs_1.7.0.php
9 Программа Wireshark 0.99 (для ПО http://wireshark.org/docs/
анализа пакетов) wsug_html
493
Изучение работы криптотуннеля

с использованием предопределенного ключа
Данная часть работы предназначена для изучения и тестирования создания IPSec VPN
туннеля с использованием предопределенного ключа (Pre-Shared Keys). Предопределенный
ключ позволяет клиентам организации использовать индивидуальные распределенные
секретные данные для аутентификации зашифрованных туннелей до шлюза, используя IKE.
Обмен ключами по алгоритму Диффи—Хельмана объединяет открытый и закрытый ключи
для создания секретных данных, которые можно использовать для аутентификации
участников IPSec-туннеля. Секретные данные могут быть распространены между двумя и
более участниками, при этом обмен обычно осуществляется по защищенному внеполосному
каналу. Однако, если используется предопределенный ключ и один из участников не
сконфигурирован с помощью того же ключа, IKE SA не может быть установлен. IKE SA — это
предварительное условие для установки IPSec SA. Необходимо сконфигурировать
предопределенный ключ на всех участниках.
Преимущество использования предопределенного ключа состоит в том, что эту техно-
логию можно использовать в небольших сетях с числом клиентов не превышающим десяти.
• Как минимум два маршрутизатора с установленным на каждом модулем NME-RVPN,
две рабочие станции клиентов с установленным сетевым адаптером.
• Создать предустановленный ключ для каждого из маршрутизаторов.
• Провести необходимое количество тестов для получения достоверного результата.

с использованием сертификатов
Аутентификация с применением технологии PKI (Public Key Infrastructure (Инфра-
структура открытых ключей, сертификаты X.509) позволяет клиентам организации ис-
пользовать цифровые сертификаты для аутентификации защищенных туннелей. Меж-
дународный стандарт X.509 определяет формат цифрового сертификата. Сертификаты X.509
базируются на методе шифрования с открытым ключом. Каждый сертификат наряду с другой
информацией (сроком действия, именем владельца и т.п.) содержит открытый ключ.
Сертификаты подписываются Certificate Authority (CA), что позволяет подтвердить
подлинность сертификата, информации, содержащейся в сертификате и, в конечном итоге,
удаленного хоста. Подлинность CA проверяется в соответствии с его свидетельством,
которое является общедоступным.
Преимуществом использования цифровых сертификатов является тот факт, что, каждый
VPN-клиент и каждый маршрутизатор владеют собственным сертификатом и аутен-
тификация происходит при участии СА. Сеть становится масштабируемой и обеспечивает
более безопасную аутентификацию с помощью цифровых сертификатов по сравнению с
предопределенными ключами. Появляется возможность настроить неограниченное число
VPN-клиентов без дополнительной модификации конфигураций шлюза по умолчанию.
• В настройках модуля прописать метод аутентификации с использованием серти-
фикатов.
• Провести необходимое количество тестов для получения достоверного результата.
494

в различных режимах работы IPSec
IPSec устанавливает четыре основных признака безопасного соединения по IP и на-
дежной передачи данных: конфиденциальность данных (Confidentiality), их целостность
(Integrity), идентификацию другой стороны и данных (Authentication) и неотказуемость non-
repudiation). В зависимости от требований безопасности можно создать комбинацию из
различных алгоритмов шифрования и хэширования, и таким образом модуль NME-RVPN
может быть настроен с определенным уровнем гибкости.
При разработке проекта организации Site-to-Site VPN становятся критичными следующие
факторы:
• уровень безопасности, требуемый для VPN;
• требования к производительности, которые могут оказывать влияние на выбор
механизма безопасности, когда необходимо найти баланс между безопасностью и
функциональностью.
IPSec предлагает два режима передачи: транспортный и туннельный. При транспортном
режиме — реальный IP-заголовок (следовательно, и IP-адрес) остается без изменений, а
заголовок IPSec вставляется между заголовком IP и остальными заголовками или
соответственно данными. При таком способе передачи изменения затрагивают только
транспортный уровень пакета IP, а собственно данные могут быть аутентифицированы и/или
зашифрованы.
Транспортный режим может использоваться при организации VPN-туннелей между
хостами, в остальных случаях требуется туннельный режим, при котором изменяется весь
пакет IP. Защита распространяется на заголовок IP и данные, причем вместо исходного со-
здается новый заголовок IP с другими IP-адресами, при этом размер пакета увеличивается на
20 байт. Туннельный режим может использоваться в следующих случаях:
— между сетевыми устройствами (наиболее используемая конфигурация). Сетевое
устройство (маршрутизатор или брандмауэр) обеспечивают функциональность IPSec-шлюза.
Таким образом, конечным пользователям нет необходимости устанавливать какое-либо
программное обеспечение u1076 для работы IPSec;
— между сетевым устройством и хостом. Организация удаленного доступа по VPN, когда
ПК используется для доступа в корпоративную сеть. Для защиты данных IPSec использует
несколько режимов:
• ESP c проверкой целостности;
• ESP без проверки целостности;
• ESP+AH (шифрование + проверка целостности);
• AH (проверка целостности).
Предпочтительнее использовать совокупность протоколов ESP и AH, при этом данные
зашифровываются и происходит проверка их целостности. При этом защищается весь пакет
вместе с IP-заголовком, что позволяет отражать атакаи типа man-in-the-middle (человек
посредине). Однако в этом режиме происходит значительное увеличение пакета данных. Если
учесть, что ESP добавляет в транспортном режиме к размеру пакета данных дополнительно
37 байт, а в туннельном режиме — 57 байт, и AH — 24 и 44 соответственно, то размер пакета
данных может увеличиться на 81 байт или больше (при использовании AES).
Таким образом, чаще всего используется только протокол ESP, поскольку при ис-
пользовании только протокола AH добавляется дополнительная нагрузка к заголовку пакета
в процессе аутентификации, но при этом не обеспечивается защита данных путем их
шифрования.
495
Для выполнения данной проверки необходимо:

• В настройках модуля прописать используемый вариант набора преобразований.
• Провести необходимое число испытаний для получения достоверного результата.
Задание
1. Изучить теоретические вопросы, изложенные в начале лабораторной работы.
2. Подготовить модельный стенд.
3. Изучить возможности настройки и управления программным обеспечением CSP VPN
Gate на модуле NME-RVPN.
Разработка стенда
Для обеспечения проверки всех выбранных параметров функциональности модуля NME-

RVPN необходимо провести анализ режимов работы и разработать базовую конфигурацию
стенда (рис. 1), которая позволяет проводить проверку требуемых характеристик путем
перекоммутации используемого оборудования и добавления дополнительных
периферийных устройств (IP-телефонов, анализаторов сети и т.д.). Это позволяет сократить
время и затраты на специальное оборудование при проведении лабораторной работы.
При построении данного стенда с учетом составленных требований, документации по
готовым решениям и рекомендации для построения защищенных сетей компании Cisco
Systems, выбрано следующее оборудование и программное обеспечение:
• модули NME-RVPN;
• Cisco 2821 С2800 Software (C2800NM-IPVOICE-M), Version 12.4(9.9)PI5;
• Cisco 7206 С7200 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
lTJ.Ift 0.2/74
PA Ла
бо
».ч> ра
то
I AW! рн
JJ ; ■ii-r-i ая
ра
бо
та
Г. Ц/* №
VLAN J99 7
Cranium ,nn
МОНИТОРИ
НГИ Cii (i.-fi
VIA*
Ch 'Drtt 4VI
WAS
ifclplUMI С uiicciiC'cCHiicti
+W
m к J WYcmln IIIUK; nt
11 № M
Рабочая станин*
Кабельные соединении
oftofiYrimiaiiMK
Рис. 1. Конфигурация стенда для проведения лабораторной работы

чо
чо 1721*0 1.04
со 172 110 2,04
ЧА
СТ
Ь
III.
ЛА
Б
О
РА
Т
О
Р
si-vs m Н
Ы
Е
РА
Б
О
Т
Ы
121^/24
Маршруты lop Co IPScc VPN туннель
ЧСЖЛУ СС7МЧИ
аироенным модулем
KJ-ГХ:. IMIIIC спели ItCHiin JPScc VPN туннель

Рлоочол cniiniMU обору .иными* .пн yjiAicHiKwu
доступа
Ноутбук.
Рис. 2. Конфигурация стенда для проверки базовой функциональности

Для проведения лабораторной работы по изучению функциональности модуля NME-
RVPN будет использоваться конфигурация стенда, приведенная на рис. 2.
Изучение организации криптотуннеля

с использованием предопределенного ключа
Согласно требованиям для проведения данной части работы необходимо выполнить
1. Использовать маршрутизаторы Cisco 2821#12 и Cisco 2821#30 с установленным на
каждом модулем NME-RVPN.
2. Соединить маршрутизаторы, как показано на рис. 2.
3. Клиентские рабочие станции (3 и 5) необходимо подключить к внешнему интерфейсу
модуля.
4. Настроить оба модуля для возможности организации IPSec-туннелей в соответствии с
требованиями. Конфигурация маршрутизаторов Cisco 2821 и модулей NME-RVPM
представлена в приложении А (табл. 1, 2).
5. На компьютерах 3 и 5 в локальных сетях в качестве шлюза по умолчанию необходимо
прописать IP-адрес интерфейса Fa0/1 модуля NME-RVPN. Таким образом, весь трафик будет
проходить через данный модуль.
6. Создать предустановленный ключ для каждого из маршрутизаторов. Если в политике
IKE для аутентификации сторон используется предустановленный ключ, то его можно
создать с помощью графического Webbased-интерфейса управления модулем в разделе Pre-
Shared Keys.
Поскольку для каждого партнера согласовывается отдельный предустановленный ключ,
в данном разделе создаются и редактируются предустановленные ключи для разных
партнеров. При аутентификации сторон с помощью предустановленных ключей для
удаленного хоста в качестве идентификатора используется либо имя хоста, либо IP-адрес
интерфейса этого хоста.
7. В настройках модуля прописать метод аутентификации с помощью предустанов-
ленных ключей. Для указания метода аутентификации, используемого в рамках протокола
IKE, применяется команда authentication. Ниже приведен пример назначения метода
аутентификации на предопределенных ключах в качестве метода аутентификации,
используемого в рамках протокола IKE. Остальные параметры устанавливаются по
умолчанию:
router(config)#crypto isakmp policy 10
router(config-isakmp)#authentication pre-share
router(config-isakmp)#exit
8. Установить защищенное соединение между клиентами.
9. Для того чтобы убедиться в возможности организации криптотуннеля с использо-
ванием предопределенных ключей при верных настройках оборудования, достаточно
провести тестирование модуля в заданной конфигурации один раз.
10. Результат тестирования, согласно спецификации IPSec, можно считать положи-
тельным, если обе стороны могут обмениваться защищенными данными. Результаты
проведенных тестов можно оценить с помощью ICMP-запроса (выполнить команду ping) на
IP-адрес устройства, находящегося в защищаемой маршрутизатором сети. Пример
положительного результата при установке VPN-туннеля:
Команда ping выполняется на рабочей станции с IP-адресом 2.2.2.99
499
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:\>
Изучение работы криптотуннеля с

использованием сертификатов
Для проведения данной части работы необходимо выполнить следующие действия.
каждом модулем NME-RVPN. Конфигурации маршрутизаторов Cisco 2821 представлены в
приложении А (табл. 3).
2. Соединить маршрутизаторы так, как показано на учебном стенде.
модуля.
4. Настроить оба модуля для возможности организации IPSec туннелей в соответствии с
требованиями. Конфигурация модулей NMERVPM представлена в приложении А (табл. 2).
5. На компьютерах 3 и 5 в локальных сетях в качестве шлюза по умолчанию необходимо
прописать IP-адрес интерфейса Fa0/1 модуля NME-RVPN. Таким образом, весь трафик будет
проходить через данный модуль.
6. Выбрать метод получения сертификата: с использованием центра сертификатов или
использовать сертификаты, полученные заранее. Для проведения тестирования можно
использовать Центр сертификации (использующий стандарты ГОСТ 28147—89, ГОСТ Р 34.10
—94, ГОСТ Р 34.11—94, ГОСТ Р 50739—95) или использовать сертификаты, полученные
заранее. Если предполагается использовать предоставленные заранее сертификаты, то их
необходимо импортировать в модуль NME-RVPN. СА-сертификаты можно ввести в 16-
ричном виде с помощью интерфейса командной строки (Command Line Interface (CLI)).
500
Для регистрации локального сертификата в модуле используется утилита командной

строки cert_mgr import.
Пример работы команды приведен ниже.
rvpn-30:/opt/VPNagent/bin# ./cert_mgr import -f nm2/nm2.pem -kc nm1 1 OK
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 с использованием всех указанных режимов
необходимо выполнить следующие действия.
каждом модулем NME-RVPN. Конфигурации маршрутизаторов Cisco 2821 представлены в
приложении А (табл. 3).
2. Соединить маршрутизаторы как показано на учебном стенде.
модуля.
4. Настроить оба модуля для возможности организации IPSec туннелей в соответствии с
требованиями.
5. На рабочих станциях клиентов прописать IP адрес из той подсети, в которой ус-
тановлена рабочая станция и в качестве шлюза по умолчанию — IP адрес внешнего ин-
терфейса модуля.
6. Сформировать набор преобразований.
Для формирования набора преобразований используется команда crypto ipsec transform-
set.
Набор преобразований — это приемлемая комбинация протоколов защиты, крип-
тографических алгоритмов и других параметров, применяемых в защищаемом IPSec-
трафике. В процессе согласования параметров IPSec SA партнеры соглашаются на
использование конкретного набора преобразований для защиты конкретного потока данных.
Можно сконфигурировать несколько наборов преобразований и затем назначить один (или
несколько конкретной записи криптографической карты. Этот набор преобразований
используется при согласовании параметров IPSec SA для защиты потока данных,
определенного в списке доступа записи криптографической карты. Набор преобразований
определяет использование протоколов IPSec: ESP и AH, и указывает на
501
криптографические алгоритмы, которые следует использовать с этими протоколами. Данные

протоколы могут использоваться как отдельно, так и одновременно.
Для создания набора преобразований следует описать от одного до трех преобразо-
ваний. Каждое из преобразований должно содержать описание используемых протоколов
(AH, ESP) и криптографических алгоритмов. В данной работе будут рассматриваться за-
падные криптоалгоритмы, это связано с ограничением программного обеспечения модуля.
7. В настройках модуля прописать используемый вариант набора преобразований.
Рекомендуемые настройки модуля NME-RVPN для проведения тестирования режимов
работы IPSec и описание возможных комбинаций преобразований приведены в приложении
А (табл. 4).
8. Установить защищенное соединение между клиентами (выполнить команду ping на
клиентских машинах).
9. Для того чтобы убедиться в возможности организации криптотуннеля с использо-
ванием всех указанных режимов при верных настройках оборудования, достаточно провести
тестирование каждого из режимов работы IPSec один раз.
10. Результат тестирования согласно спецификации IPSec можно считать положи-
тельным, если обе стороны могут обмениваться защищенными данными.
Оценка результатов проводится так же, как в предыдущем пункте.
В отчете с титульным листом установленной формы (см. Приложение В) необходимо
4. Измеренные значения, полученные в ходе выполнения работы.
1. Как подготовить к работе учебный стенд?
2. Как ввести в действие учебный стенд?
3. Назовите признаки готовности учебного стенда.
4. Назовие способы получения сертификата.
5. Что означает защищенное соединение?
6. Какие методы аутентификации IKE вы знаете? На чем эти методы могут быть ос-
нованы?
7. Как определить, что IPSec VPN-туннель не установлен и обмен данными не возможен?
Что для этого необходимо сделать?
8. Какие режимы защиты данных использует IPSec? Чем они различаются?
9. Какие два режима передачи предлагает IPSec? В чем их различие?
10. Какой из вариантов использования совокупности протоколов является наиболее за-
щищенным?
502
2821_30
2821_12
2821 12#sh run 2821_30#sh run
version 12.4 version 12.4
service timestamps debug datetime msec service timestamps debug datetime msec
service timestamps log datetime msec service timestamps log datetime msec
no service password-encryption no service password-encryption
hostname 2821_12 hostname 2821_30
boot-start-marker boot-start-marker
boot system flash c2800nm-ipvoicemz. boot system flash:c2800nm-ipvoicemz.
124-9.9.PI5 124-9.9.PI5
boot-end-marker boot-end-marker
! !
! !
ip cef ip cef
interface Loopback0 !
! interface Loopback0
ip address 5.5.5.1 255.255.255.255 ip address 5.5.5.3 255.255.255.255
interface GigabitEthernet0/0 interface GigabitEthernet0/0

ip address 172.16.0.3 255.255.255.0 ip address 172.17.0.2 255.255.255.252
ip virtual-reassembly duplex auto
duplex full speed auto
interface GigabitEthernet0/1
speed auto !
interface GigabitEthernet0/1 ip address 1.1.1.1 255.255.255.0
ip address 2.2.2.1 255.255.255.0 shutdown
ip nbar protocol-discovery duplex auto
ip virtual-reassembly speed auto
shutdown !
duplex full interface Special-Services-Engine1/0
speed auto ip address 10.10.10.1 255.255.255.252
! no keepalive
interface Special-Services-Engine1/0 !
ip address 20.20.20.1 255.255.255.252 ip route 0.0.0.0 0.0.0.0
no keepalive GigabitEthernet0/0
! ip route 1.1.1.0 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.10.10.2
503
Окончание табл. 1
2821_30
2821_12
213.24.233.129 ip route 2.2.2.0 255.255.255.0
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0
GigabitEthernet0/0 ip route 172.16.0.0 255.255.255.0
20.20.20.2
Cisco 2821#12 RVPN Cisco2821#30 RVPN
rvpn-12#sh run RVPN-30#sh run

crypto ipsec df-bit copy crypto isakmp identity address crypto ipsec df-bit copy crypto isakmp identity address
username cscons password csphostname rvpn-12 enable username cscons password csphostname RVPN-30 enable
password csp ! password csp ! Таблица 2
Настройка модулей NME-RVPN
crypto isakmp policy 1 hash md5 encryption des crypto isakmp policy 1 hash md5 encryption des
authentication pre-share group 1 ! authentication pre-share group 1 !
crypto isakmp key cisco123 address 10.10.10.2 crypto isakmp key cisco123 address 20.20.20.2
crypto ipsec transform-set ts esp-des crypto ipsec transform-set ts esp-des

esp-md5-hmac esp-md5-hmac
mode tunnel mode tunnel
ip access-list extended lans permit ip 2.2.2.0 0.0.0.255 i p access-list extended lans permit ip 1.1.1.0 0.0.0.255
1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255
crypto map cm 1 ipsec-isakmp match address lans set crypto map cm 1 ipsec-isakmp match address lans set
transform-set ts set pfs group1 set peer 10.10.10.2 ! transform-set ts set pfs group1 set peer 20.20.20.2 !
! !
interface FastEthernet0/0 ip address 20.20.20.2 interface FastEthernet0/0 ip address 10.10.10.2
255.255.255.252 crypto map cm interface FastEthernet0/1 255.255.255.252 crypto map cm interface FastEthernet0/1
ip address 2.2.2.10 255.255.255.0 ! ip address 1.1.1.10 255.255.255.0 !
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
Cisco 2821#12 Cisco2821#30
nm1#sh run crypto ipsec df-bit copy crypto isakmp identity nm2#sh run crypto ipsec df-bit copy crypto isakmp identity
dn username cscons password csp hostname nm1 enable dn username cscons password csp hostname nm2 enable
password csp ! password csp !
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 !
crypto ipsec transform-set ts esp-des crypto ipsec transform-set ts esp-des

esp-md5-hmac esp-md5-hmac
mode tunnel mode tunnel
ip access-list extended lans permit ip 2.2.2.0 0.0.0.255 ip access-list extended lans permit ip 1.1.1.0 0.0.0.255
1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255
crypto map cm 1 ipsec-isakmp match address lans set crypto map cm 1 ipsec-isakmp match address lans set
transform-set ts set pfs group1 set peer 10.10.10.2 ! transform-set ts set pfs group1 set peer 20.20.20.2 !
interface FastEthernet0/0 ip address 20.20.20.2 interface FastEthernet0/0 ip address 10.10.10.2

255.255.255.252 crypto map cm interface FastEthernet0/1 255.255.255.252 crypto map cm interface FastEthernet0/1
ip address 2.2.2.10 255.255.255.0 snmp-server community ip address 1.1.1.10 255.255.255.0 snmp-server community
public ! public !
crypto ca trustpoint sterra_ technological_trustpoint crl crypto ca trustpoint sterra_ technological_trustpoint crl
optional optional
crypto CA certificate chain sterra_ crypto CA certificate chain sterra_
technological_trustpoint technological_trustpoint
certificate 0101010101010101 certificate 0101010101010101
308201893082012CA0030201020208010101010 308201893082012CA0030201020208010101010
1010101300E060A2B06010401AD590103020500 1010101300E060A2B06010401AD590103020500
3032310B30090603550406130252553110300E0 3032310B30090603550406130252553110300E0
505
Cisco 2821#12 Cisco2821#30
60355040A1307732D74657272613111300F0603 60355040A1307732D74657272613111300F0603
55040313084E6F746172794341301E170D30343 55040313084E6F746172794341301E170D30343
13032393137303035325A170D30393130323931 13032393137303035325A170D30393130323931
37303035325A3032310B3009060355040613025 37303035325A3032310B3009060355040613025
2553110300E060355040A1307732D7465727261 2553110300E060355040A1307732D7465727261
3111300F060355040313084E6F7461727943413 3111300F060355040313084E6F7461727943413
05E3016060A2B06010401AD5901060206082A86 05E3016060A2B06010401AD5901060206082A86
48CE3D030107034400044104D1BC76EDE6128E8 48CE3D030107034400044104D1BC76EDE6128E8
32D5D029F4E741E35FC2E99D23E086C10DC6772 32D5D029F4E741E35FC2E99D23E086C10DC6772
8ABAB5E666ED9881AB73F1543F1A6C7049FD8CE 8ABAB5E666ED9881AB73F1543F1A6C7049FD8CE
381E97BE2294A499F976F1CD559C8B7CA35A323 381E97BE2294A499F976F1CD559C8B7CA35A323
3021300F0603551D130101FF040530030101FF3 3021300F0603551D130101FF040530030101FF3
00E0603551D0F0101FF040403020106300E060A 00E0603551D0F0101FF040403020106300E060A
2B06010401AD590103020500034700304402204 2B06010401AD590103020500034700304402204
1991DE0A1B1C176B097A8825A9FDEFB6D57982B 1991DE0A1B1C176B097A8825A9FDEFB6D57982B
AA995C1DA11164E0F443E542022036E923625D7 AA995C1DA11164E0F443E542022036E923625D7
8A172525FADD52E18A09E296141EB24688C97F2 8A172525FADD52E18A09E296141EB24688C97F2
9CB405578DDED8 9CB405578DDED8
quit quit
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

end end
nm1# 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
Тип преобразования Имя Описание
ah-md5-hmac Протокол АН c алгоритмом аутентификации ГОСТ Р

AH Transform (один из списка) 34.11-94 HMAC
ah-sha-hmac Протокол АН с алгоритмом аутентификации SHA
ESP Encryption Transform (один из
списка) esp-des Протокол ESP с алгоритмом ГОСТ 28147-89 Протокол
esp-3des ESP с 168-битным алгоритмом 3DES Протокол ESP с 128-
esp-aes-128 битным алгоритмом AES Протокол ESP c 192-битным
esp-aes-192 алгоритмом AES Протокол ESP c 256-битным алгоритмом
esp-aes-256 AES
ESP Authentication Transform
(один из списка) esp-md5-hmac Протокол ESP с алгоритмом аутентификации MD5 ГОСТ
Р 34.11-94 HMAC
esp-sha-hmac Протокол ESP с алгоритмом аутентификации SHA
Пример заданной конфигурации:

RVPN-30(config)#crypto ipsec transform-set
<cr>
ah-md5-hmac //режим AH
ah-sha-hmac //режим AH
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
//использовать режим AH+ESP с проверкой целостности
router(config)#crypto ipsec transform-set ts ah-sha-hmac //
использовать режим AH
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-crypto-trans)# exit
Приложение В
(образец)


РЕЖИМЫ РАБОТЫ ПРОТОКОЛА IPSec

НА МОДУЛЕ MME-RVPN ПРИ ИСПОЛЬЗОВАНИИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ CSP VPN GATE
ДЛЯ АУТЕНТИФИКАЦИИ И ЗАЩИТЫ ДАННЫХ

Выполнили:
(Ф.И.О.)
(Ф.И.О.)
Принял:
(Ф.И.О)
(год)
508
НАСТРОЙКА WEB INTERFACE 4.X
ДЛЯ ИСПОЛЬЗОВАНИЯ СМАРТ-КАРТ
Изучение возможности использования двухфакторной аутентификации в продуктах Citrix

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
Подготовка стенда для выполнения работы

Процессор 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-
1E6E218ACCE4&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. Архив содержит файлы:
ctxs_cps_plt.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).
Рис. 1 Предлагаемая структура каталога для виртуального стенда
510
Рис. 2 Подключение утилиты VMRCplus к Virtual Server
Рис. 3. Добавление существующей виртуальной машины
6. Затем в меню, выбираем пункт «Virtual Machine» ^ «Add» (рис. 3) и в открывшемся

окне переходим в каталог, где расположен файл конфигурации виртуальной машины.
7. Нажимаем кнопку «Open» (рис. 4).
8. Повторяем операции 6 и 7 для оставшихся машин виртуальной среды.
9. В зависимости от объема установленной на машине-хосте памяти изменяем объем
ОЗУ в виртуальной машине. Для этого устанавливаем курсор на виртуальную машину, чьи
параметры мы будем редактировать, нажимаем правую кнопку мыши и выбираем пункт —
«Settings» (рис. 5).
10. В открывшемся окне редактируем параметр «Memory», а также, если мы хотим иметь
возможность отменить результаты нашей работы, включаем параметр «Enable undo disks».
11. Нажимаем кнопку «Apply» и затем «OK» (рис. 6).
12. Повторяем операции 9-11 для остальных виртуальных машин (рис. 7).
511
Рис. 4. Открытие файла конфигурации виртуальной машины
Рис. 5 Редактирование настроек виртуальной машины
512
CTXS-DC
«Гостевая» • Windows 2003 Server Enterprise Edition SP2

операционная система
Объем • 512 Мб (по умолчанию)
оперативной памяти • Можно уменьшить до 256 Мбайт в случае ограниченного объема оперативной
памяти на хост машине
Сетевые карты • 1 — для внутренней сети

• 1 — привязана к физическому адаптеру, для подключения извне
Роль
• Контроллер домена WWC.COM
• Сервер сертификатов
• Маршрутизация во внешнюю сеть
• DNS сервер Почтовый сервер (POP3, SMTP)
• Файл-сервер
• Сервер приложений
CTXS-SQL
514
Дополнительное ПО
• MS SQL Server 2005 Enterprise Edition
• Citrix EdgeSight
• Citrix SmartAuditor
• Citrix Password Manager
Объем
оперативной памяти • 1024 Мбайт (по умолчанию)
• Можно уменьшить до 512 Мбайт в случае ограниченного объема оперативной
Роль
• Сервер баз данных для продуктов Citrix
• Хранилище учётных данных для использования Citrix Password Manager
• Компьютер для подготовки потоково-доставляемого ПО (Профайлер)
• Консоль мониторинга производительности
• Сервер и консоль для видеологирования терминальных сессий (SmartAuditor)
CTXS-CPS

• Citrix XenApp 4.5 с Feature Pack 1 и Hotfix Rollup Pack 2
• Агенты Citrix Password Manager, Citrix EdgeSight, Citrix SmartAuditor
Объем
оперативной памяти 1024 Мбайт (по умолчанию)
• Можно уменьшить до 512 Мбайт в случае ограниченного объема оперативной
Роль
• Терминальный сервер
• Сервер лицензий Citrix
• Web-сервер для доступа к опубликованным приложениям

Administrator Evaluation1 Администратор домена WWC.COM и Citrix XenApp
Ctxsuser1 Evaluation1 Пользователь домена WWC имеет доступ ко всем опубликованным
приложениям, кроме консолей администрирования, и не имеет возможности
запуска приложений с использованием технологии потоковой доставки
Таблица 2
Ctxsuser2 Evaluation1 Учетные записи и пароли пользователей
То же
Ctxsuser3 Evaluation1 —”—
Ctxsuser4 Evaluation1 Пользователь домена WWC имеет доступ ко всем опубликованным
приложениям, кроме консолей администрирования, и может запускать
приложения с использованием технологии потоковой доставки
Ctxsuser5 Evaluation1 То же
Ctxsuser6 Evaluation! —”—
515
РАБОТЫ
Задание
Организовать доступ для пользователей, использующих смарт-карты, в двух вариантах
— стандартная аутентификация по смарт-картам и сквозная аутентификация.
Запуск виртуальных машин и подготовка
к работе виртуального окружения
До начала использования виртуальных машин необходимо обновить версию «VM
Additions» (оптимизированные драйверы для гостевых машин).
• Запускаем каждую машину нашего виртуального стенда. Для этого устанавливаем
курсор на запись соответствующую машине, которую мы хотим включить и нажав
правую клавишу мыши из появившегося контекстного меню выбираем Turn On.
• Для подключения к консоли виртуальной машины, опять нажимаем правую кнопку
мыши, предварительно выбрав нужную включенную виртуальную машину из
контекстного меню выбираем VM Console.
• Используя учетную запись «Administrator» входим в систему, нажав комбинацию
клавиш Right + Alt + Del.
• В окне «Console Manager» выбираем пункт меню Media ^ Install Current VM Additions
(рис. 8).
• В гостевой операционной системе начнется установка дополнений.
Рис. 9 Завершение установки дополнений гостевой операционной системы
• После завершения процесса установки инсталлятор предложит перезагрузить систему

(рис. 9).
• После перезагрузки поле Additions: изменит цвет с красного на черный, что будет
указывать на последнюю доступную версию дополнений гостевой операционной
системы.
• Установив дополнения гостевой системы, необходимо сохранить изменения в образе
виртуальной машины, для чего в окне «Console Manager» необходимо выбрать меню
Control ^ Undo Options ^ Shut Down Guest OS and Commit Undo Disks.
Рис. 8 Установка дополнений для гостевой машины
516 517
Установка лицензий Citrixдля XenApp Platinum

При загрузке набора виртуальных машин с сайта Citrix Systems вы проходите реги-
страцию, и через некоторое время на указанный во время регистрации адрес электронной
почты вы получите файлы временных лицензий (cps_eva_eval_license.lic и
cps_eva_eval_license_cag.lic).
Эти файлы необходимо поместить в виртуальную машину CTXS-CPS в каталог
C:\Program FiIes\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
ПЯС51 • “ ITT"Ж’П 1
s
C t r a Accm AAmntwd Eflbcrt Caacir«fl UM ~"i л!- iM fy Й »
GUa Ассам G«May EMMpitaa Edacai Свккшя Uaar гм Ми И в и й
Г
CA'-c Ассам Caraway №mla>* lawn Caecim* Uaar -^И'У « Q .■?
C4B Surf ч> ьсама Зам id» E -1 5ВД i
CAB XanAf* i.PraiartMn SaM>| АдааМ Смкшаа Uw -H ■Э Й г
CiM ИмЛДО iPWSHUDW CMCIrfWI Uftir CAhl* И в я ДИ
CAB KarfApp iFiaaartMn 5a"*| CaaciaiWA Uaar LaUw V) jl m i
iLmisnrt UMT t-фШязшП jo rt 0
0.»>1 Им: V» о‘ AM Ц И S*P X, Ж*

Hrt«h □ CamfAt I* Ikanaa Imafllnr» В
Рис. 12 Настройка прав

доступа для каталога
«•►«Ml a
Clients Camptrta Ucama IIIWWMMT В
Рис. 11 Временные лицензии для виртуального стенда
Открываем «My computer» ^ «Local disk C:» ^ «Eval Resources» ^ далее на каталоге
«Clients» нажимаем правую кнопку мыши и выбираем «Sharing and Security», затем пе-
реходим на вкладку «Security».
На данной вкладке нужно нажать кнопку «Add» и в открывшемся окне выбрать группу
пользователей «Domain Users» (рис. 12).
Этой группе пользователей необходимы права «Read&Execute», «List Folder Contents» и
«Read». После присвоения необходимых прав, нажимаем кнопку «Apply» и «OK» (рис. 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 XP или
Windows Vista, которые можно загрузить с сайта компании Microsoft —
http://www.microsoft.com/downloads/details.aspx?FamilyID=21EABB90-958F-4B64-B5F1-
73 D013
Рис. A413 C8EF&displaylang
Присвоение прав =en, а также компьютер CTXS-SQL.
доступа группе «Domain
Users».
519
520

Вариант 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 FiIes\Citrix\ICA Client»
(рис. 15). В секции [WFClient], добавьте следующие строки:
EnableSSOnThruICAFile=On
SSOnUserSetting=On
Рис. 14 Установка клиента ICA
521
HeAa Control Osptav Settings 5рео4 Hejp
[ Uc*MLeta_dc селЬм an.LpzjA
Г: Program I lies LitrtxICA Client
JiHO ^ ■ Swath Fetes

| _) С:\Р»осгагя FleslotrutfCA cler*
Hera - feel Type
,ipjwvt»ru - Notepad
i Lor/tgjr-stxn Fl= £* FfcfrnM феи Й*
_jfcsocrco
5 5L P r0 4y Ho 3 t - ' h : «3
jjjecrdo SSLNoCACertS-0
^афоп.Л SSLClphers-ALL
O'***fv.ri PttQijA Ci: Li LinthE nib t Й U -Y&5
âcpwv.Sre P H^ u i d. L au n c hv i s i b l e
i,$J тхк«Ц.Л CuST 11 f- o i i
^cgpcfg-(«
4 ~i LI E Е5йГ»Тлг Ul CAF1 1 E
^CgpCore.d osonus er- sic t T: t ng-on
^conceritr.dl
J^controgc*
fflcpvTewer.e
w
Рис. 15 Настройка клиентской машины
4. Выполните вход на сервер CTXS-CPS под учетной записью пользователя

Administrator. Убедитесь, что задействована служба Windows Directory Service Mapper. По
умолчанию она выключена в IIS. Для включения этой службы, необходимо запустить MMC
оснастку 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» и «OK» (рис. 16).
5. Теперь необходимо установить следующие параметры для Виртуального Каталога IIS
6.0:
• Require secure channel (SSL);
• Ignore client certificate;
• Enable client certificates.
Для этого в открытой оснастке Internet Information Services (IIS) Manager раскрываем узел
Web Sites, устанавливаем курсор на Default Web Site, нажимаем правую кнопку мыши и в
выпавшем меню выбираем пункт «Properties». Далее переходим на закладку
522
Рис. 16. Включение службы Windows directory service mapper
«Directory Security» и в секции «Secure Communications» нажимаем кнопку «Edit». В

открывшемся окне устанавливаем параметры, в соответствии со снимком экрана (рис. 17).
После установки параметров и нажатия кнопки ОК, мы возвращаемся на предыдущий
экран, где мы должны сделать следующие операции:
1) нажимаем кнопку Apply;
2) нажимаем кнопку Select All;
3) для завершения настройки нажимаем OK (рис. 18).
6. Теперь необходимо выполнить работы по настройке Citrix XenApp.
Для включения аутентификации по смарткартам, откройте консоль управления Access
Management Console, для этого выполните: «Start» ^ «All 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
Рис. 17. Установка

параметров Secure
Communications для
метакаталога Default
Web Sites
Рис. 18. Завершение

настройки метакаталога
Default Web Sites
524
Рис. 19. Запуск консоли управления
Рис. 20. Включение сквозной аутентификации по смарт-картам
525
ЧАСТЬ работаРАБОТЫ
Вариант 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) для завершения настройки нажимаем OK (рис. 22).
Пункт 6, выполняется аналогично Варианту № 1.
После
Рис. выполнения пункта 6, вариант 2 Лабораторной работы закончен.
21. Установка
параметров Secure
Примечание: При использовании стандартной аутентификации по смарт-кар-
Communications
там
для доступ к Web Interface URL будет приводить к запросу пользователя о необхо-
метакаталога
димости
Default Webвыбора
Sites используемого сертификата, а также ввода 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.
Рис. 22. Завершение
Отчет представляется с тиутульным листом установленной формы.
настройки
метакаталога
Default Web Sites
526 527
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? Чем они различаются?
Приложение A
(образец)


НАСТРОЙКА WEB INTERFACE 4.X

ДЛЯ ИСПОЛЬЗОВАНИЯ СМАРТ-КАРТ

Выполнили:
(Ф.И.О.)
(Ф.И.О.)
Принял:
(Ф.И.О)
(год)
529
НАСТРОЙКА 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).
Сервер с Secure Gateway рекомендуется устанавливать в демилитаризованной зоне
(DMZ) для формирования защищенного периметра вокруг компонентов Citrix в корпо-
ративной сети. Secure Gateway аутентифицирует пользователей, подключающихся через
Интернет и формирует безопасный канал обмена данными между клиентским устройством и
Citrix XenApp.
Secure Gateway — это приложение, выполняющееся как сервис на сервере размещенном
в DMZ. Этот сервер представляет собой единую точку доступа к защищенной корпоративной
сети. Таким образом, Secure Gateway выступает в роли посредника для всех соединений,
запрашивающих подключение к корпоративной сети из Интернета.
Для повышения безопасности можно построить решение из двух демилитаризованных
зон: во внешней будет располагаться Citrix Secure Gateway, а во внутренней — Citrix Secure
Gateway Proxy. Secure Gateway Proxy выступает в роли изолирующего элемента
530
для трафика, направленного от Secure Gateway к серверам, расположенным в защищенной

зоне сети и для трафика, идущего в обратном направлении.
В корпоративной сети может быть установлено один или несколько серверов с Citrix
XenApp. Такая группа серверов, называемая фермой, используется для размещений
опубликованных ресурсов, к которым пользователи получают доступ по сети.
Secure Gateway взаимодействует со следующими компонентами Citrix XenApp для
проведения процедур аутентификации и входа:
Citrix Web Interface. Обеспечивает доступ пользователей, использующих Интернет-
браузер к опубликованным ресурсам на ферме серверов Citrix XenApp. Web Interface
работает совместно с Secure Gateway для предоставления интерфейса входа в систему и
способствует аутентификации и авторизации запросов на подключение к ферме серверов.
Secure Ticket Authority (STA). Задачей STA является выдача сессионных билетов в ответ
на запрос на подключение к опубликованным ресурсам на Citrix XenApp. Эти билеты
являются основой процессов аутентификации и авторизации для доступа к опубликованным
ресурсам. Во время установки Citrix XenApp 4.5 служба STA устанавливается автоматически.
В отличие от предыдущих версий, здесь нет необходимости выделять отдельный сервер для
установки STA.
Служба Citrix XML. Когда Secure Gateway обеспечивает безопасный доступ к опуб-
ликованным на ферме серверов ресурсам, служба Citrix XML отвечает за информацию о
доступности и расположении опубликованных ресурсов. Для своей работы вместо протокола
UDP используется протокол TCP, что позволяет осуществлять соединения через
большинство межсетевых экранов. По умолчанию порт службы Citrix XML — 80.
Citrix XenApp Web Plugin. Клиентское ПО для подключения к Citrix Web Interface/ Citrix
Secure Gateway.
Для проведения работ мы будем использовать набор виртуальных машин, описанный в
лабораторной работе № 8.
Помимо 3 машин из лабораторной работы № 8, нам потребуется дополнительная
виртуальная машина под управлением клиентской ОС. Такую виртуальную машину можно
установить самостоятельно или загрузить VHD-файл с установленной Windows XP или
Windows Vista с сайта компании Microsoft — http://www.microsoft.com/downloads/
details.aspx?FamilyID=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en. Перед
началом использования этой виртуальной машины необходимо обновить версию «VM
Additions» (оптимизированные драйверы для гостевых машин), так как это описано в
лабораторной работе № 8. Этой машине необходимо задать параметры из табл. 1 и 2.
Также нам понадобится дополнительное программное обеспечение:
— Свободно распространяемая утилита TCPView, предназначенная для контроля портов
и адресов подключения. Загрузить ее необходимо с сайта компании Microsoft
http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx
— Компонент Citrix Secure Gateway 3.1, обеспечивающий безопасное подключение к
опубликованным приложениям. Этот компонент можно загрузить с сайта компании Citrix
https://www.citrix.com/English/ss/downloads/details.asp?downloadId=1681216&productId=186
Secure Gateway 3.1 (требуется регистрация).
В результате всех вносимых изменений наш стенд должен соответствовать рис. 1.
531
ЧАСТЬCTXS-DC
III. ЛАБОРАТОРНЫЕ РАБОТЫ
• Windows 2003 Server Enterprise Edition SP2

«Гостевая» операционная система
CTXS-CPS
Объем оперативной памяти • 512 Мбайт (по умолчанию) 192.168.100.3
• Можно уменьшить до 256 Мбайт в случае ограниченного
Windows Serverобъема
2003
оперативной памяти на хост-машине Citrix XenApp
Сервер лицензий Citrix
Сетевые карты • 1 — для внутренней сети Клиенты и агенты Citrix
• 1 — привязанна к физическому адаптеру, для подключения
Citrix извне
Web Interface
Роль • Контроллер домена WWC.COM

TEST • Сервер сертификатов
192.168.100.10• Маршрутизация во внешнюю сеть
Windows XP • DNS-сервер
ПК не включенный в• домен.
Почтовый сервер (POP3, SMTP)
Утилита TCPView • Файл-сервер
CTXS-DC
192.168.100.1
Windows Server 2003
Контроллер домена
Служба сертификатов
Два сетевых интерфейса CTXS-SQL
Служба маршрутизации 192.168.100.2
DHCP Windows Server 2003
К физическому Secure Gateway
адаптеру Дополнительные
компоненты Citrix
Рис. 1. Схема стенда виртуальных машин
Таблица 1
Установленное ПО и аппаратные характеристики виртуальных машин
532
Параметр
Описание
CTXS-SQL

• Citrix Secure Gateway 3.1
• MS SQL Server 2005 Enterprise Edition
• Citrix EdgeSight
• Citrix SmartAuditor
• Citrix Password Manager
Объем оперативной памяти
• 1024 Мбайт (по умолчанию)
• Можно уменьшить до 512 Мбайт в случае ограниченного объема
оперативной памяти на хост машине

Роль
• Сервер Secure Gateway
• Сервер баз данных для продуктов Citrix
• Хранилище учётных записей для использования Citrix Password
Manager
• Компьютер для подготовки потоково-доставляемого ПО (Профайлер)
• Консоль мониторинга производительности
• Сервер и консоль для видеологирования терминальных сессий
(SmartAuditor)
CTXS-CPS

• Citrix XenApp 4.5 с Feature Pack 1 и Hotfix Rollup Pack 2
• Агенты Citrix Password Manager, Citrix EdgeSight,
Citrix SmartAuditor
Объем оперативной памяти
• 1024 Мбайт (по умолчанию)
• Можно уменьшить до 512 Мбайт в случае ограниченного объема
оперативной памяти на хост машине

Роль
• Терминальный сервер
• Сервер лицензий Citrix
• Web сервер для доступа к опубликованным приложениям
TEST
«Гостевая» операционная система • Windows XP Professional Edition SP2

• Утилита TCPView
• Клиенты для подключения к Citrix XenApp
Объем оперативной памяти • 128 Мбайт
Роль • Клиентский компьютер, не входящий в состав домена WWC
533
Evaluationl ЧАСТЬАдминистратор домена
III. ЛАБОРАТОРНЫЕ WWC.COM
РАБОТЫ и Citrix XenApp
WWC\Administrator
TEST\Test_user - Тестовая учётная запись на компьютере TEST
Таблица 2
Используемые учетные записи и пароли пользователей
Задание
Организовать доступ для пользователей, получающих доступ к опубликованным при-
ложениям, извне с помощью механизма безопасного подключения.
Для приведения виртуального стенда к рабочему виду после первой лабораторной ра-
боты необходимо запустить каждую машину (CTXS-DC, CTXS-CPS и CTXS-SQL) нашего
виртуального стенда. Для этого устанавливаем курсор на запись, соответствующую машине,
которую мы хотим включить и, нажав правую клавишу мыши, из появившегося контекстного
меню выбираем Turn On.
Для подключения к консоли виртуальной машины опять нажимаем правую кнопку мыши,
предварительно выбрав нужную включенную виртуальную машину, из контекстного меню
выбираем VM Console.
После загрузки машины и подключения к виртуальной консоли, нам для каждой вир-
туальной машины, необходимо выполнить сброс Undo-диска (рис. 2).
Когда вы завершите возврат стенда в первоначальное состояние, снова включаем все
четыре виртуальные машины в следующем порядке — CTXS-DC, CTXS-SQL, CTXS-CPS,
TEST. Рекомендуется включать следующую машину после окончания загрузки предыдущей.
В виртуальную машину под управлением Windows XP нам необходимо установить до-
полнительное ПО — утилиту TCPView. С сайта компании Microsoft загружаем утилиту в виде
архивного файла. Переносим этот файл на компьютер TEST, распаковываем его в
подходящий каталог.
Рис. 2 Сброс Undo-диска и возврат к первоначальному состоянию виртуального стенда
534

Вначале необходимо проверить, какие порты используются при стандартном под-
ключении через Web Interface. Для этого выполняем вход с учетной записью test_user на
виртуальную машину CiTRIX Welcome toутилита
TEST, где у нас установлена the Secure TCPView. Gateway
Устанавливаем клиентское ПО Citrix 3.1 setup CTXS-CPS.
с сервера
1. Нажимаем «Start» ^ «Run» и в открывшемся окне набираем \\ctxs-cps\Eval
Resources\Clients. При запросе учетных * n данных вводим «ЛЖ» логин и пароль пользователя
r i ■■■
Administrator. Из списка возможных подкаталогов открываем «Citrix ICA Windows Clients». В
открывшейся папке выбираем файл «ICA32PKG.MSI»
[HI C-n/d H JI- ' ч I1A41 iи- Htr копируем
dill и этот файл на локальный
компьютер в каталог «C:\Clients\». û'.Fi-uFif ■.thr*'1-
2. Запускаем файл «ica32pkg.msi» ■vifli.:4,
на исполнение. Установка проходит с параметрами по
riii [ir.j*4+ [iHwitj (y Mîî i*. *-1
умолчанию.
Запускаем Интернет Обозреватель,U'W^'O'V'fd
осуществляем(r-ilitHMI подключение 1*4 к Citrix
Г1ГГ XenApp и за-
пускаем любое опубликованное приложение, 1Ч4ЖЛ Of например Notepad. Ш
г ^<|.v>ntt«iaJ|l>)I«H||I«WI
ы «IHJBIIHW №*w «Wh'ibrmKil*.
Затем запускаем утилиту TCPView и с ее помощью контролируем порт по которому
произошло подключение к серверу CTXS-CPS (рис. 3).
Так как у нас включена опция Session Reliability, то мы видим, что используется порт 2598.
Если мы отключим эту опцию, то подключение будет происходить по порту 1494.
Ill " I t>»H
Таким образом, при подключении к опубликованным приложениям нам придется
открывать в межсетевых экранах дополнительные порты. Первоначальное обращение к
серверу Web InterfaceРис. проходит по экран
4. Начальный 80 или 443 порту,
установки Citrixно Secure дляGateway
дальнейшей
3.1 работы с при-
ложением задействуются дополнительные порты.
Установка и настройка Citrix Secure Gateway.
С сайта компании Citrix, по вышеприведенной ссылке мы загружаем Citrix Secure
Используя доменную учетную запись Administrator, выполняем вход на компьютер CTXS-
Gateway 3.1. Запускаем процедуру установки (рис. 4):
SQL, на который мы будем устанавливать Citrix Secure Gateway.
На этом этапе нажимаем кнопку Next и переходим к следующему экрану с лицензионным
соглашением (рис. 5).
Рис. 3. Контроль используемого при работе с опубликованными приложениями порта

Рис. 5. Экран лицензионного соглашения
535
536
Рис. 6. Выбор варианта установки
Для продолжения дальнейшей установки вам необходимо согласиться с лицензионным

соглашением и нажать кнопку Next (рис. 6).
Так как на нашем стенде виртуальных машин мы устанавливаем Secure Gateway в ло-
кальной сети, то нам для продолжения работы необходимо выбрать режим установки —
Secure Gateway (рис. 7).
Рис. 7. Выбор каталога для установки Secure Gateway
537
Рис. 10. Завершение процесса установки Citrix Secure Gateway

Рис. 8. Выбор учетной записи, под которой будет работать Secure Gateway
На открывшемся экране, прежде чем приступить к процедуре установки, система

Соглашаемся
предлагает с каталогом
проверить по умолчанию
введенные параметры,и чтобы
нажимаем
прикнопку Next для их
необходимости перехода
можно кбыло
сле-
дующему экрану (рис. 8).
скорректировать. Если вся информация верна, нажимаем кнопку Next (рис. 10).
На
Послеэтомзавершения
экране предлагается
процессавыбрать учетную
установки запись
система под которой
предложит будет выполняться
осуществить настройку
Citrix Secure Gateway. Согласно рекомендациям
сервиса до запуска Secure Gateway (рис. 11). по построению безопасных систем ре-
комендуется выбратьнанекнопку
После нажатия привилегированную учетную
ОК, запустится запись,
мастер, такуюэкраном
первым как NETWORK SERVICE
которого будет
(рис. 9).
информационное сообщение о назначении данного конфигуратора. Нажав на кнопку Next, вы
перейдете к следующему экрану (рис. 12).
На открывшемся экране Вам будет предложено выбрать один из двух режимов на-
стройки. Для полной настройки службы выбираем режим Advanced и нажимаем кнопку Next
(рис. 13).
Выбираем имеющийся на сервере сертификат для Полного имени сервера (FQDN) —
ctxs-sql.wwc.com. Именно по этому имени в дальнейшем мы будем подключаться к сер-
I о Lau n rthe tideway mullConFigur

b SeciMt 13-aieây b e W aia ion
t Wizard
А с я п f c e
Ckt OK b iwnch che $Kiat G otwrj '•«zwd
CTXS-SQL
Рис. 11. Экран
Рис. 9. начального запуска
Экран проверки настройки
значений, службы Citrix
необходимых Secure Gateway
для установки
538 539
Рис. 12. Выбор режима настройки
веру Secure Gateway. На следующем экране необходимо выбрать протокол безопасности

(рис. 14).
На этом экране выбираем протоколы SSLv3 и TLSvl, из пакетов шифрования выбираем оба
пакета (All). Для варианта GOV, будут доступны алгоритмы шифрования, сов-
Рис. 13. Выбор сертификата сервера
540
Рис. 14. Выбор протокола безопасности и пакетов шифрования
местимые со стандартом FIPS-140, а для COM будет доступно коммерческое шифрование

(RSA с RC4 128 MD5 или RSA c RC4 128 SHA) (рис. 15).
В открывшемся окне необходимо указать, какой интерфейс будет использоваться для работы
Secure Gateway. Также необходимо указать, на каком порту будет отвечать на за-
Рис. 15. Установка интерфейса и порта обслуживаемого сервисом Secure Gateway
541
Рис. 17. Настройка

соединения
с STA-сервером
ЬНж'асе
1ЛГОГЕ Llflttnjy Cool4ur.1tМП »Ч/*гН
Рис. 16. Настройка ограничений на исходящий трафик
1------------------------------------------
’CuuAf О Hv itrw nnwg tv * ?
Дтаичот 4-tW",
^ Iblrv: 1 ■. -.-.il-Vhiw, :■ ДОШ9*4Г,
CITRIX
просы этот
приложение
(h* 1Л
f“ Irrttibd ЦП (fki
<t th* 5* Так как на компьютере CTXS-SQL порт 443 уже обслуживает
сервис.
на(CTfUMr
Internet Information Service, мы указываем другой порт, например, 8443.
другое
r Qp«l ■ lc. кпи

В открывшемся экране
(ГЧ iWrfc Htrf-ЮЕ; м^> можно настроить ограничения на исходящий трафик. В данной
fr4 IPU rf Ibflработе
лабораторной w«b Irtwfaut
этот функционал не используется, поэтому выбираем «No outbound
traffic restrictions» (рис. 16).
1 w**------------------------------------------------------
В открывшемся окне добавляем сервер STA (рис. 17). Для этого нажимаем кнопку Add и
fS**1- |во вновь
■ s-cpt открывшемся
т-tic ronj окна заполняем поле FQDN. Служба STA располагается на сервере
Citrix XenApp,
ran*i Г7------------- соответственно в данное поле мы вводим CTXS-CPS.WWC.COM. Здесь также
Eeoj« iftflFibdntcr.
можно ■настроить
F£ шифрование
^ |к Г It44tblrtaf «*ini трафика между STA-службой и сервером Secure Gateway. Так
как оба сервера|ivрасполагаются
■Senfc в рамках локальной сети, мы не включаем шифрование.
Нажимаем нопку OK и затем Next.
На двух следующих экранах соглашаемся со значениями по умолчанию и попадаем на
экран настройки соединения с Web Interface (рис. 18).
Так как мы хотим, чтобы пользователь для доступа к опубликованным приложениям
указывал адрес Secure Gateway, то мы указываем режим доступа Indirect. В связи с тем, что
сервис Web Interface располагается на другом по отношению к сервису Secure Gateway
физическом сервере, то очищаем чекбокс Installed on this computer.
В поле FQDNуказываем полное DNS имя сервера — CTXS-CPS.WWC.COM.
Рис. 18. Настройки
В***-' > Спя соединения с сервером
Web Interface
542 543
Рис. 21. Результаты работы утилиты диагностики Secure Gateway
Если наша конфигурация настроена правильно, то в результате работы мы

должны увидеть следующее (рис. 21).
После подтверждения, что Secure
Рис. 19. Настройка Gateway
параметров на сервере
логирования событий CTXS-SQL настроен
корректно, используя доменную учетную запись Administrator, переключаемся в
консоли виртуальных
На последнем экране машин
настройки на необходимо
сервер CTXS-CPS, где установлен
указать глубину логированиясервис
событийWeb
на
Interface.Secure Gateway. Соглашаемся с принятым по умолчанию уровнем и на следующем
сервере
Запускаем
экране утилиту
соглашаемся администрирования
с запуском настроенной службы— Access Management
Secure gateway Console и в этой
(рис. 19).
консоли раскрываем узел Web Interface ? Web Access Site (рис. 22).
Прежде чем перейти к настройке службы Web Interface на сервере CTXS-CPS, необ-
В средней
ходимо проверитьчасти экрана находим
работоспособность элемент
нашей «Manage secure client access» и, нажав
конфигурации.
левой
Дляклавишей мыши,
этого запускаем выбираем
утилиту Secureпункт «Edit
Gateway Gateway Settings»
Diagnostics (рис. 20). (рис. 23).
В открывшемся окне производим следующие операции:
1. В поле Address (FQDN) вводим полное DNS-имя сервера, на котором
установлена служба Secure Gateway — CTXS-SQL.WWC.COM.
2. Указываем порт, по которому будет отвечать эта служба — 8443.
3. Нажимаем кнопку Add.
Рис. 20. Запуск утилиты диагностики

Рис. 22. Изменение настроек Web Interface
544
545
Рис. 25. Изменение маршрута по умолчанию

Рис. 23. Настройка параметров соединения с сервисом Secure Gateway
В открывшемся окне необходимо установить курсор на строку «Default»«Direct»
4. И вкнопкук
и нажать открывшемся окне 25).
«Edit» (рис. вводим имя сервера, на котором запущена служба STA
— CTXS-CPS.WWC.COM.
Во вновь открытом окне в выпадающем меню необходимо выбрать значение
После Direct»
«Gateway нажатия кнопкикнопку
и нажать OK остается
OK. изменить настройки Citrix XenApp с точки
зрения DMZ. Для этого в средней части экрана, опять находим элемент «Manage
secure client access» и после нажатия левой клавиши мыши выбираем пункт «Edit
DMZ Settings» (рис. 24).
Рис. 24. Изменение настроек DMZ

Рис. 26. Подключение к Citrix Web Interface
546
547
РАБОТЫ
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,
администраторРис.сделал этот адреса
27. Контроль сервер членом
сервера домена.
и порта Допустимо ли это? Если
подключения
нет, то почему?
12. Secure Gateway может использовать протокол SSL или протокол TLS. В чем
состоит
На различие между
этом настройка сервера этими
Web двумя протоколами?
Interface завершена.
13. Теперь
В организации
необходимо проверить, как работаетвыдачи
используется свой центр сертификатов.
наше решение. Дляиспользуя
Для этого, сервера
Secure
учетную Gateway
запись выданнасертификат
test_user компьютере наTEST,
имя сервера
запускаем sg.Интернет
При подключении черези
Обозреватель
Интернет, пользователь сообщает, что у него появляется предупреждение
в строке адреса набираем https://ctxs-sql.wwc.com:8433/Citrix/Web/auth/login.aspx. о
неверном сертификате. Администратор, подключаясь из локальной
Обратите внимание на то, что нам необходимо в явном виде указать порт 8433, так сети, с
как онтакой ошибкойотнезначения
отличается сталкивается. Как можно
по умолчанию — решить
443 (рис.эту проблему?
26).
14. Используя
Администратор выписал
учетные сертификат
записи для сервераAdministrator
пользователя Secure Gateway с именем
домена sg-
WWC,
001.company.ru. При настройке Secure Gateway система
подключаемся к опубликованным приложениям и запускаем приложение WordPad. приняла этот
Для сертификат. Компания
контроля адреса и портапредоставила
подключениядоступ к своей
запускаем информационной
утилиту TCPView (рис.системе
27).
компани-
Как ям-партнерам.
видно, соединение Партнер сподключаясь
установлено через на
сервером CTXS-SQL, Интернет,
котором получает
запущена
службапредупреждение
Secure Gateway о по
невозможности
порту 8443. Этопроверки
означает, сертификата. Почему?
что мы настроили Как можно
доступ к Citrix
XenApp, используя безопасный доступ и можем открыть на межсетевом экране
всего один порт для осуществления такого доступа. В нашем случае это порт 8443.
1. Объясните различие между стандартным подключением к серверу Web
Interface с использованием SSL и подключением через Citrix Secure Gateway.
2. Какие ограничения применяются при настройке Secure Gateway в режиме Direct?
3. Какие протоколы могут быть использованы для подключения к Secure Gateway?
4. Как можно защитить соединение между сервером Secure Gateway и сервером
Web Interface?
548
Приложение A
Титульный
лист (образец)


НАСТРОЙКА SECURE GATEWAY

ДЛЯ БЕЗОПАСНОГО ПОДКЛЮЧЕНИЯ
К ОПУБЛИКОВАННЫМ ПРИЛОЖЕНИЯМ
ИЗ НЕДОВЕРЕННЫХ СРЕД ПЕРЕДАЧИ ДАННЫХ

Выполнили:
(Ф.И.О.)
(Ф.И.О.)
Принял:
(Ф.И.О)
(год)
550
Теория и практика обеспечения безопасного доступа
Учебное пособие для вузов
Афанасьев Алексей Алексеевич, Веденьев Леонид Тимофеевич,

Воронцов Алексей Андреевич, Газизова Эльвира Рафаиловна,
Додохов Александр Леонидович, Крячков Антон Викторович,
Полянская Ольга Юрьевна, Сабанов Алексей Геннадьевич,
Скида Максим Александрович, Халяпин Сергей Николаевич
Шелупанов Александр Александрович
Под редакцией
доктора техн. наук, профессора А. А. Шелупанова;
генерального директора ЗАО «Аладдин Р. Д.» С. Л. Груздева;
кандидата физ.-мат. наук, старшего научного сотрудника,
руководителя аналитического отдела ЗАО «Аладдин Р. Д.» Ю. С. Нахаева
Авторский коллектив выражает благодарность за помощь

в подготовке проекта компаниям
Aladdin, Cisco, Citrix, Microsoft, Oracle, Крипто-Про
h » [ 11
Aladdin i\i, CITR;X
CISCO
Microsoft КРИПТО
ф^ПРО
ORACUG
ВЫШЛИ В СВЕТ И ИМЕЮТСЯ В ПРОДАЖЕ
Горбатов В. С., Полянская О. Ю. Основы техно- Информационная безопасность открытых систем:

логии PKI. - 2-e изд., стереотип. - М.: Горячая Учебник для вузов. В 2-х томах. Том 1 - Угрозы,
линия-Телеком, 2012. - 248 с.: ил., ISBN 978-59912- уязвимости, атаки и подходы к защите / С. В.
0213-8. Запечников, Н. Г. Милославская, А. И. Толстой, Д.
Рассматриваются основы технологии инфраструктур В. Ушаков. - М.: Горячая линия- Телеком, 2006. -
открытых ключей. Даются базовые определения. 536 с.: ил., ISBN 5-93517-291-1.
Анализируются основные подходы к реализации В учебнике рассматриваются основы информационной
инфраструктур открытых ключей, описываются безопасности открытых систем на примере интранет.
архитектура, структуры данных, компоненты и сервисы Вводятся основные определения и понятия. Описываются
PKI. Предлагается классификация стандартов и современные угрозы, уязвимости базовых составляющих
спецификаций в области инфраструктур открытых ключей. интранет и удаленные сетевые атаки на них. Подробно
Рассматриваются проблемные ситуации и риски, политика рассматриваются концептуальные подходы к обеспечению
PKI, правовые аспекты использования технологии PKI. информационной безопасности в открытых системах и
Описываются программные продукты ведущих мировых и вопросы разработки политики безопасности.
российских компаний- производителей программного Анализируются этапы создания комплексной системы
обеспечения для поддержки PKI. обеспечения информационной безопасности для интранет
Для студентов и аспирантов высших учебных и сервисы безопасности.
заведений, слушателей курсов повышения квалификации, Для студентов высших учебных заведений и
а также для широкого круга читателей, интересующихся слушателей курсов повышения квалификации.
современными проблемами информационной Рябко Б. Я., Фионов А. Н. Криптографические
безопасности. методы защиты информации: Учебное пособие для
Запечников С. В., Милославская Н. Г., Толстой А. вузов. - 2-е изд., стереотип. - М.: Горячая линия-
И. Основы построения виртуальных частных Телеком, 2012. - 229 c.: ил., ISBN 978-59912-0286-
сетей. Учебное пособие для вузов. - 2-е изд., 2.
стереотип. - М.: Горячая линия-Телеком, 2012. - Изложены основные подходы и методы современной
криптографии для решения задач, возникающих при
249 с., ISBN 978-5-9912-0215-2. обработке, хранении и передаче информации. Основное
Изложены основы построения виртуальных частных
внимание уделено новым направлениям криптографии,
сетей (VPN). Даны основные определения. Рассмотрена
связанным с обеспечением конфиденциальности
технология туннелирования в сетях. Подробно взаимодействий пользователей компьютеров и
анализируются стандартные протоколы построения VPN и компьютерных сетей. Рассмотрены основные шифры с
управление криптографическими ключами в VPN. открытыми ключами, методы цифровой подписи, основные
Выделяются особенности различных вариантов и схем криптографические протоколы, блоковые и потоковые
создания VPN. В качестве примеров реализации VPN шифры, криптографические хеш-функции, а также редко
приведена информация о различных продуктах российских встречающиеся в литературе вопросы о конструкции
предприятий. доказуемо невскрываемых криптосистем и криптографии
Для студентов высших учебных заведений, на эллиптических кривых. Изложение теоретического
обучающихся по специальностям «Компьютерная материала ведется достаточно строго, но с
безопасность» и «Комплексное обеспечение использованием элементарного математического
информационной безопасности автоматизированных аппарата. Подробно описаны алгоритмы, лежащие в
систем», и слушателей курсов повышения квалификации. основе криптографических отечественных и
Запечников С. В. Криптографические протоколы и международных стандартов. Приведены задачи и
упражнения, необходимые при проведении практических
их применение в финансовой и коммерческой
занятий и лабораторных работ.
деятельности: Учебное пособие для вузов. - М.: Для студентов, обучающихся по направлению
Горячая линия-Телеком, 2007. - 320 с., ISBN 5- «Телекоммуникации», может быть полезна специалистам.
93517-318-2. Хорев П. Б. Криптографические интерфейсы и их
В систематизированном виде изложены основы
использование. - М.: Горячая линия-Телеком, 2007.
теории криптографических протоколов и практики их
применения в финансовой и коммерческой деятельности.
- 278 с.: ил., ISBN 978-5-93517-331-9.
Рассмотрены основы использования
Наряду с рассмотрением современных методов синтеза и
криптографических интерфейсов в приложениях
анализа основных классов криптографических протоколов,
основное внимание уделяется специальным их операционной системы Windows, создаваемых на языках
применениям: защищенным каналам передачи программирования Object Pascal и C++, а также в
информации, системам электронных платежей, приложениях для сети Интернет, создаваемых на языках
защищенному электронному документообороту. сценариев JavaScript и VBScript. Изложение материала
Рассматриваются проблемы криптографической защиты сопровождается примерами создания и хранения крип-
многосторонних транзакций и коммерческих сделок, тографических ключей, шифрования и расшифрования
криптографических методов обеспечения государственно- файлов и сообщений, их хеширования, вычисления и
правовых отношений, осуществляемых с использованием проверки электронной цифровой подписи, работы с
технических средств компьютерных систем. сертификатами открытых ключей и их хранилищами.
Для студентов высших учебных заведений, Для разработчиков программных средств защиты
обучающихся по специальностям 090102 - «Компьютерная информации, специалистов, интересующихся
безопасность» и 090105 - «Комплексное обеспечение современными методами и средствами криптографической
информационной безопасности автоматизированных
Справки по телефону: (495) 737-39-27, WWW.TECHBOOK.RU

Аутентификация. Теория и практика-2012

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Аутентификация. Теория и практика-2012

Загружено:

Авторское право:

Доступные форматы

Аутентификация

Рекомендовано Учебно-методическим объединением

А93 Аутентификация. Теория и практика обеспечения безопасного доступа к

Учебное издание Аутентификация

Учебное пособие для вузов

ISBN 978-5-9912-0257-2 © ЗАО «Аладдин Р.Д.», 2009, 2012

ЧАСТЬ II. БАНТИКА.....................................................................................................................155

ЧАСТЬ III. ЛАБОРАТОРНЫЕ РАБОТЫ......................................................................................247

Судьба данного учебного пособия весьма необычна. На партнерской конференции по

Замечания, предложения и пожелания просьба направлять по адресу:

634050, Томск, пр-т Ленина, д.40

129226 Москва, ул. Докукина, д. 16 корп. 1

1.1. Основные понятия и определения

1.2. Роль и задачи аутентификации.

Четвертый элемент — владелец системы (администратор), который несет ответственность

Независимо от типа системы аутентификации в ней всегда

Примером аутентификации является вход физического лица в систему по паролю.

В компьютерных системах аутентификация и управление

В идеале доступ к информации выдается по принципу

В настоящее время необходимо аутентифицировать и

На основе знания • Пароль или парольная фраза

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

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

1.3.1. Многофакторная аутентификация

Аутентификация может быть реализована с помощью одного из трех факторов аутен-

В документе NCSC-TG-017 вводятся термины для различных

Трехфакторная аутентификация использует комбинацию трех факторов аутентификации

При многофакторной аутентификации используется

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

Чем длиннее и сложнее пароль, тем он более стойкий.

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

Парольная аутентификация является наиболее простым

2.2. Методы парольной аутентификации

Рис. 2.1. Аутентификация на основе открытого пароля

Пример аутентификации пользователя на основе открытого пароля:

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

2.2.2. Аутентификация на основе хэшированного пароля

Кража парольного файла

Описание атаки Защита от данной атаки

На пользователей: Политика нераскрытия паролей

Политика смены паролей

Для того чтобы заставить поль- Сигнал о принуждении

Описание атаки Защита от данной атаки

Подглядывание из-за плеча

Злоумышленник скрыто уста- Безопасность рабочих помещений

Анализ сетевого трафика

Атака на «золотой пароль»

Злоумышленнк записывает Использование надежных протоколов аутентификации Надежные

Атака методом воспроизведения

3.1. Биометрические характеристики

Биометрические характеристики делятся

Физиологические биометрические характеристики (физические биометрические ха-

Характерной чертой для поведенческих параметров является их протяженность во

Поведенческие биометрические параметры достаточно

3.2. Как работают биометрические системы

Все биометрические системы работают одинаково:

Контрольный шаблон сравнивается с эталонным шаблоном (или зарегистрированным

Биометрические системы могут ошибаться, их точность

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

3.3. Аутентификация и биометрическое распознавание

В режиме аутентификации биометрическая система

В биометрических системах, работающих только в режиме аутентификации, возможно

Радужная Видеокамера, способная Черно-белое изображение Полоски и бороздки в ра-