Аутентификация. Теория и практика-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 не должны
которого издан этотнарушать лицензионных
сертификат. соглашений
Причем проверка можетнавыполняться
исп�

Аутентификация. Теория и практика-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. Аутентификация и биометрическое распознавание

В режиме аутентификации биометрическая система

В биометрических системах, работающих только в режиме аутентификации, возможно