Данного состояния процесса представлен на. Основные понятия

Требования к знаниям и умениям

Студент должен знать:

• механизмы идентификации и аутентификации;

• идентификаторы, используемые при реализации механизма идентификации и аутентификации.

Студент должен уметь:

• использовать механизмы идентификации и аутентификации для защиты информационных систем.

Ключевой термин

Ключевой термин: Идентификация и аутентификация.

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

Второстепенные термины

• Определение понятий «идентификация» и «аутентификация»

• Механизм «идентификации» и «аутентификации» пользователей

Структурная схема терминов

4.1.1 Определение понятий «идентификация» и «аутентификация»

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

Дадим определения этих понятий.

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

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

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

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

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

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

Парольные методы аутентификации по степени изменяемости паролей делятся на:

• методы, использующие постоянные (многократно используемые) пароли;

• методы, использующие одноразовые (динамично изменяющиеся) пароли.

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

Карточки разделяют на два типа:

• пассивные (карточки с памятью);

• активные (интеллектуальные карточки).

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

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

Методы аутентификации, основанные на измерении биометрических параметров человека, обеспечивают почти 100% идентификацию, решая проблемы утери или утраты паролей и личных идентификаторов. Однако эти методы нельзя использовать при идентификации процессов или данных (объектов данных), они только начинают развиваться, требуют пока сложного и дорогостоящего оборудования. Это обусловливает их использование пока только на особо важных объектах.

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

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

4.1.2 Механизм «идентификация» и «аутентификация» пользователей

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

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

В целом аутентификация по уровню информационной безопасности делится на три категории:

1. статическая аутентификация;

2. устойчивая аутентификация;

3. постоянная аутентификация.

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

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

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

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

Выводы по теме

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

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

3. Идентификация — присвоение субъектам и объектам доступа личного идентификатора и сравнение его с заданным.

4. Аутентификация (установление подлинности) — проверка принадлежности субъекту доступа предъявленного им идентификатора и подтверждение его подлинности.

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

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

6. Если в процессе аутентификации подлинность субъекта установлена, то система защиты информации должна определить его полномочия (совокупность прав). Это необходимо для последующего контроля и разграничения доступа к ресурсам.

7. В целом аутентификация по уровню информационной безопасности делится на три категории: статическая аутентификация, устойчивая аутентификация и постоянная аутентификация.

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

Контрольные вопросы:

1. Что понимается под идентификацией пользователя?

2. Что понимается под аутентификацией пользователей?

3. Применим ли механизм идентификации к процессам? Почему?

4. Перечислите возможные идентификаторы при реализации механизма идентификации?

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

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

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

   Другими словами, идентификация пользователя - это получение от него ответа на вопрос: «Кто ты?» Скажем, Вася. А аутентификация - это требование: «А теперь докажи, что ты именно Вася» и последующая проверка доказательств. То есть проверка, действительно ли пользователь является тем, за кого он себя выдает.

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

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

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

   На самом деле в реальных системах эталонный пароль может храниться в таблице в зашифрованном виде (например, в файле /etc/passwd или /etc/shadow в Linux-системах) или вместо пароля сохраняется его хэш (о хэшировании см. статью «Электронная цифровая подпись», «Мир ПК», ). Это не позволит злоумышленнику, получившему доступ к хранилищу эталонов, ознакомиться с паролями всех пользователей системы.

   В более сложных случаях (прежде всего при удаленной аутентификации) предъявляемая пользователем аутентификационная информация и ее эталонный образец могут дополнять друг друга, участвуя в каких-либо криптографических преобразованиях. Для этого используются различные протоколы сетевой аутентификации. Пример ее приведен в статье , «Мир ПК», № 12/04.)

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

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

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

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

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

   Поговорим о достоинствах и недостатках упомянутых выше методов.

   Пароль

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

   Недостатков же у парольной аутентификации не счесть.

   Во-первых, очень часто неискушенные пользователи выбирают простые или легко угадываемые пароли:

   Во-вторых, пароль могут подсмотреть или перехватить при вводе.

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

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

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

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

   Существуют системы, включающие пароль под принуждением : пользователь применяет один пароль для нормального входа в систему, а другой, также предопределенный пароль, сигнализирует модулю аутентификации о том, что пользователя принуждают к входу в систему. Программы прозрачного шифрования, например, предоставляют при вводе пароля под принуждением дезинформацию, предварительно подобранную принуждаемым пользователем (о прозрачном шифровании см. статью , «Мир ПК», № 4/02).

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

   Уникальный предмет

   Рис. 2. Пример USB-токена: ruToken

   Для аутентификации пользователей наиболее часто применяются следующие предметы: смарт-карты, карты с магнитной полосой, электронные таблетки iButton, USB-токены (рис. 2).

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

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

   Недостатков у «предметной» аутентификации несколько меньше, чем у парольной, а именно следующие:

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

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

   Биометрическая аутентификация

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

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

   1. Отпечатки пальцев. Известно, что они уникальны для каждого человека, причем не меняются на протяжении жизни. Для сканирования отпечатков пальцев применяется самое дешевое оборудование (по сравнению с другими методами биометрической аутентификации), кроме того, данный метод привычен для пользователей и не вызывает каких-либо опасений. Однако считается, что недорогие сканеры отпечатков пальцев можно обмануть специально изготовленным искусственным пальцем.
   2. Рисунок радужной оболочки глаза. Это на сегодня наиболее точный метод биометрической аутентификации. Но многие пользователи боятся процесса сканирования радужной оболочки, да и оборудование для сканирования является дорогостоящим. К тому же данный способ вызывает нарекания со стороны правозащитников. Они говорят, что глаз человека несет много информации о состоянии его здоровья, о злоупотреблении спиртными напитками, наркотиками и т.д. Есть опасения, что эту информацию о пользователях (побочную для процесса аутентификации) настроенная соответствующим образом система может сохранять, после чего возможно ее использование им во вред.
   3. Черты лица. Данная технология распознавания считается очень перспективной, поскольку именно по чертам лица узнают друг друга люди. К сожалению, системы, реализующие данный метод, пока не блещут точностью.

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

   * * *

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

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

   Сергей Панасенко - начальник отдела разработки ПО фирмы «Анкад», канд. техн. наук. С ним можно связаться по е-mail: [email protected] .

   1. 1. Соколов А.В., Шаньгин В.Ф. Защита информации в распределенных корпоративных сетях и системах. М.: ДМК Пресс, 2002. Исключительно познавательная книга, охватывающая практически все темы защиты информации. Один из ее разделов посвящен теории идентификации и аутентификации пользователей, а также протоколам сетевой аутентификации.
   2. 2. Леонтьев Б. Хакинг без секретов. М.: Познавательная книга плюс, 2000. Содержит «список часто употребляемых паролей» и другую полезную информацию, касающуюся парольной аутентификации.
   3. 3. Медведовский И.Д., Семьянов П.В., Леонов Д.Г. Атака на Internet. М.: ДМК Пресс, 2000. Одна из глав этой книги целиком посвящена методам социальной инженерии.
   4. 4. Евангели А. PC Week/RE 2003, № 7, с. 24-25. Технологии биоидентификации и биометрический рынок. Статья, подробно описывающая методы биометрической аутентификации и существующие технические решения.
   5. 5. Матвеев И.А., Ганькин К.А. Распознавание человека по радужке // Системы безопасности, 2004, № 5, с. 72. Подробно описаны технические особенности аутентификации по рисунку радужной оболочки глаза.

   1 М.С. Горбачев, 1991.

   13 июня 2007 г. 10:51

   А.Щеглов, К.Щеглов

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

   Требования нормативных документов к механизму идентификации и аутентификации

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

   Прежде всего, обратимся к формализованным требованиям в области защиты информации, попробуем в них найти ответ на вопрос, какими же функциями должен быть наделен механизм идентификации и аутентификации? Формализованные требования к механизму идентификации и аутентификации пользователей задаются действующим сегодня нормативным документом "Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации".

   Для СЗИ от НСД, используемых для защиты конфиденциальной информации (5 класс СВТ) требования к механизму идентификации и аутентификации состоят в следующем:

   ● Комплекс средств защиты информации (КСЗ) должен требовать от пользователей идентифицировать себя при запросах на доступ.

   ● КСЗ должен подвергать проверке подлинность идентификации - осуществлять аутентификацию.

   ● КСЗ должен располагать необходимыми данными для идентификации и аутентификации.

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

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

   Заметим, что в требованиях к СВТ 4-го класса защищенности вообще задачи идентификации и аутентификации пользователя при входе в систему и при запросе на доступ разделены на две самостоятельные задачи, кроме того, здесь появляется некое понятие "субъект" в общем виде.

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

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

   Задача идентификации и аутентификации субъекта "пользователь" при запросах на доступ

   Этапы идентификации и аутентификации пользователя, реализуемые ОС Windows

   Этапы идентификации и аутентификации пользователя, реализуемые в системе (на примере ОС Windows), представлены на рис. 1.

   Первый шаг идентификации, поддерживаемый режимом аутентификации, реализуется при входе пользователя в систему. Здесь следует выделить возможность входа в штатном и в безопасном режиме (Safe Mode). В порядке замечания отметим, что принципиальным отличием безопасного режима является то, что при запуске системы в безопасном режиме можно отключить загрузку сторонних по отношению к системе драйверов и приложений. Поэтому, если в системе используется добавочная СЗИ от НСД, можно попытаться загрузить систему в безопасном режиме без компонент СЗИ от НСД, т.е. без средства защиты. С учетом же того, что загрузить систему в безопасном режиме может любой пользователь (в Unix системах – только Root), то СЗИ от НСД должна обеспечивать возможность входа в систему в безопасном режиме (после идентификации и аутентификации) только под учетной записью администратора.

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

   Рис.1. Этапы идентификации и аутентификации пользователя

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

   В порядке замечания отметим следующее. С одной стороны, это очень полезная опция, которая может быть использована в корпоративных приложениях, когда на одном компьютере требуется обрабатывать конфиденциальные и открытые данные. При этом предполагается, что для обработки данных различных категорий создаются различные учетные записи. Данная опция предполагает, что одновременно (без перезагрузки) можно обрабатывать данные различных категорий, например, под одной учетной записью обрабатывать необходимым приложением конфиденциальные данные, под другой учетной записью запустить Internet-приложение (у Вас на мониторе может быть открыто одновременно два окна). Естественно, что реализация данной возможности выставляет и дополнительные требования к СЗИ от НСД (например, при подобном запуске приложения ОС Windows между пользователями не изолируется буфер обмена, который в ОС является "принадлежностью" рабочего стола).

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

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

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

   Вывод. Требование "КСЗ должен обеспечивать идентификацию пользователей при запросах на доступ…" актуально и должно реализовываться современными СЗИ от НСД. При этом задача защиты при выполнении этого требования сводится к контролю корректности олицетворения при запросах доступа к ресурсам, т.к. именно использование сервиса олицетворения может привести к неконтролируемой смене исходного идентификатора.

   Реализация механизма идентификации и аутентификации при запросах доступа к ресурсам

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

   

   Рис.2. Укрупненный алгоритм идентификации и аутентификации при запросе доступа к ресурсу

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

   Ограничения возможности корректного решения задачи

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

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

   Чтобы понять суть существующих ограничений, проанализируем, как ОС Windows (в ОС семейства Unix рассматриваемые проблемы не столь критичны, т.к. устройства в них монтируются к файловой системе) работает с устройствами, и сразу натолкнемся на проблему (решения рассматриваемой задачи, реализуемые собственно ОС Windows, рассматривать не будем, т.к. они не удовлетворяют требованиям применения в корпоративных приложениях). Проблема здесь состоит в том, что многие устройства предполагают возможность взаимодействия с ними приложения не напрямую, а через драйвер. В этом случае запрос доступа к устройству осуществляется от лица пользователя System (варианты решения задачи на прикладном уровне рассматривать не будем, ввиду их априорной уязвимости). Возникает вопрос, а откуда взять идентификатор пользователя, который инициировал это обращение к устройству. Можно, конечно, "посмотреть", какой пользователь зарегистрирован в системе, и фильтровать запросы доступа применительно к его учетной записи (кстати говоря, подобный подход реализуется некоторыми специализированными средствами защиты). Но не будем забывать, что современные ОС Windows многопользовательские. Как отмечалось выше, начиная с Windows XP, возможность входа в многопользовательский режим уже вынесена в интерфейс (например, из проводника можно по правой кнопки мыши выбрать опцию запуска приложения с правами другого пользователя – получим многопользовательский режим). В многопользовательском режиме в системе одновременно зарегистрировано уже несколько пользователей, при этом выявление учетной записи, от которой осуществлен запрос доступа к устройству, становится неразрешимой (или, по крайней мере, весьма сложно корректно решаемой) задачей.

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

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

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

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

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

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

   Задача идентификации и аутентификации субъекта "процесс" при запросах на доступ

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

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

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

   ● Критичные процессы. К ним мы отнесем две группы процессов: к процессам первой группы отнесем те, которые запускаются в системе с привилегированными правами, например, под учетной записью System, к процессам второй группы те, которые наиболее вероятно могут быть подвержены атакам, например, сетевые службы. Атаки на процессы первой группы наиболее критичны, что связано с возможностью расширения привилегий, в пределе – получения полного управления системой; атаки на процессы второй группы наиболее вероятны.

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

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

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

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

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

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

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

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

   ● разграничение прав доступа к объектам процессов вне разграничений пользователей (эксклюзивный режим обработки запросов процессов - доступ к объекту разрешается, если он разрешен процессу);

   ● разграничение прав доступа к объектам пользователей вне разграничений процессов (эксклюзивный режим обработки запросов пользователей - доступ к объекту разрешается, если он разрешен пользователю);

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

   Заметим, что техническое решение, реализующее данный подход, нами запатентовано (А.Ю.Щеглов. Система разграничения доступа к ресурсам, патент №2207619, приоритет от 12.07.2001).

   Вернемся к вопросам идентификации и аутентификации, но уже применительно к субъекту доступа "процесс". Идентификатором его является полнопутевое имя. Таким образом, для корректной идентификации субъекта "процесс" необходимо предотвратить возможность запуска процессов под иными именами и предотвратить возможность модификации исполняемых файлов, полнопутевые имена которых разрешены для выполнения.

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

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

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

   В предлагаемой нами реализации для локализации программной среды необходимо регламентировать права доступа к папкам (каталогам, подкаталогам), из которых пользователям разрешено (запрещено) запускать исполняемые файлы. С учетом принятых правил размещения приложений и необходимости запуска системных процессов, целесообразно разрешать выполнение программ только из каталогов \Program Files, куда следует устанавливать приложения, и \Winnt (WINDOWS). А чтобы предотвратить возможность модификации санкционированных исполняемых файлов, запись пользователям в эти каталоги, напротив, следует запретить.

   Заметим, что если в качестве субъекта доступа может выступать как сущность "пользователь", так и сущность "процесс", то данный механизм защиты позволит настраивать замкнутость программной среды не только для пользователей, но и для процессов. В этом случае можно разрешить любому процессу, либо контролируемому процессу (как субъекту) запуск исполняемых файлов только из каталогов \Program Files, и \Winnt (WINDOWS) и запретить прикладным процессам запись в них. Очевидное достоинство этого решения в "равноправности" разграничений для всех пользователей - вне зависимости от корректности их идентификации при доступе к ресурсам (в частности, атаки на расширение привилегий становятся невозможными).

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

   Вопросы корректности идентификации объекта доступа

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

   В NTFS файловый объект может быть идентифицирован различными способами:

   ● файловые объекты, задаваемые длинными именами, характеризуются той отличительной особенностью, что к ним можно обращаться как по длинному, так и по короткому имени, например к каталогу "\Program files\" можно обратиться по короткому имени "\Progra~1\";

   ● файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться), например короткое имя для каталога "C:\Documents and Settings\USER1\Главное меню" выглядит как "C:\Docume~1\USER1\5D29~1\". К этим объектам также можно обратиться как по длинному, так и по короткому имени;

   ● файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.

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

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

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

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

   В заключение отметим, что в данной работе на примере исследования лишь одной, на первый взгляд, наиболее изученной сегодня задачи защиты информации, авторы сделали попытку убедить читателя, что защита информации – это очень сложная научно-техническая и инженерная задача. К сожалению, исторически нас приучили к тому, что средство защиты может быть простым в использовании и в администрировании. Большую (на наш взгляд, отрицательную) роль в этом сыграли антивирусные средства, основанные на сигнатурном анализе – "нажал две кнопки, запустил "черный ящик", все проверил, безопасность обеспечена". Однако сигнатурные анализаторы – это не средства защиты – это средства контроля (сравнение с эталоном). Поэтому, с одной стороны, они могут быть простыми в использовании (задача лишь в пополнении набора эталонов, которая для потребителя "прозрачна"), с другой стороны, их использование принципиально не может обеспечить эффективной защиты (принципиально невозможно обеспечить выполнение требования к полноте и достаточности набора эталонов). Если же мы говорим о корпоративных приложениях, где конфиденциальные данные являются потенциальным товаром, т.е. обладают потребительской стоимостью, к вопросам компьютерной безопасности необходимо относиться серьезно, необходима соответствующая квалификация лиц, отвечающих на предприятии за защиту информации (о разработчиках СЗИ от НСД уж и не говорим). В этом случае потребитель уже должен ожидать от разработчика средств защиты не простых, а эффективных и обоснованных решений!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   1. Задание минимальной длины используемых в системе паролей. Это усложняет атаку путем подбора паролей. Как правило, рекомендуют устанавливать минимальную длину в 6-8 символов.
   2. Установка требования использовать в пароле разные группы символов - большие и маленькие буквы, цифры, специальные символы. Это также усложняет подбор.
   3. Периодическая проверка администраторами безопасности качества используемых паролей путем имитации атак , таких как подбор паролей "по словарю" (т.е. проверка на использование в качестве пароля слов естественного языка и простых комбинаций символов, таких как "1234").
   4. Установка максимального и минимального сроков жизни пароля, использование механизма принудительной смены старых паролей.
   5. Ограничение числа неудачных попыток ввода пароля (блокирование учетной записи после заданного числа неудачных попыток войти в систему).
   6. Ведение журнала истории паролей, чтобы пользователи, после принудительной смены пароля, не могли вновь выбрать себе старый, возможно скомпрометированный пароль.

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

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

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

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

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

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

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

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

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

   • сервер аутентификации (англ. Authentication Server , сокр. AS);
   • сервер выдачи разрешений (англ. Ticket Granting Server, сокр. TGS ).

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

   
   Рис. 5.1.

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

   1. C->AS: {c} .

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

   2. AS->C: {{TGT}K AS_TGS , K C_TGS }K C ,
      • K C - основной ключ C ;
      • K C_TGS - ключ, выдаваемый C для доступа к серверу выдачи разрешений TGS ;
      • {TGT} - Ticket Granting Ticket - билет на доступ к серверу выдачи разрешений

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

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

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

   3. C-> TGS : {TGT}K AS_TGS , {Aut 1 } K C_TGS , {ID}

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

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

   4. TGS ->C: {{ TGS }K TGS_SS ,K C_SS }K C_TGS ,

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

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

   5. C->SS: { TGS }K TGS_SS , {Aut 2 } K C_SS

      где Aut 2 ={c,t 4 } .

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

   6. SS->C: {t 4 +1}K C_SS

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

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

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

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

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

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

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

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

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

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

   В сетевой среде, когда стороны идентификации/аутентификации территориально разнесены, у рассматриваемого сервиса есть два основных аспекта:

   • 1. что служит аутентификатором (то есть используется для подтверждения подлинности субъекта);
   • 2. как организован (и защищен) обмен данными идентификации/аутентификации.

   Субъект может подтвердить свою подлинность, предъявив, по крайней мере, одну из следующих сущностей:

   • 1. нечто, что он знает (пароль, личный идентификационный номер, криптографический ключ и т.п.);
   • 2. нечто, чем он владеет (личную карточку или иное устройство аналогичного назначения);
   • 3. нечто, что есть часть его самого (голос, отпечатки пальцев и т.п., то есть свои биометрические характеристики).

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

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

   • - установление подлинности и определение полномочий субъекта при его допуске в систему,
   • - контролирование установленных полномочий в процессе сеанса работы;
   • - регистрация действий и др.

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

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

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

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

   Обычно методы аутентификации классифицируют по используемым средствам. В этом случае указанные методы делят на четыре группы:

   • 1. Основанные на знании лицом, имеющим право на доступ к ресурсам системы, некоторой секретной информации - пароля.
   • 2. Основанные на использовании уникального предмета: жетона, электронной карточки и др.
   • 3. Основанные на измерении биометрических параметров человека - физиологических или поведенческих атрибутах живого организма.
   • 4. Основанные на информации, ассоциированной с пользователем, например, с его координатами.

   Рассмотрим эти группы.

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

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

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

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

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

   Известны следующие методы парольной защиты, основанные на одноразовых паролях:

   • - методы модификации схемы простых паролей;
   • - методы «запрос-ответ»;
   • - функциональные методы.

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

   При использовании метода «запрос-ответ» система задает пользователю некоторые вопросы общего характера, правильные ответы на которые известны только конкретному пользователю.

   Функциональные методы основаны на использовании специальной функции парольного преобразования. Это позволяет обеспечить возможность изменения (по некоторой формуле) паролей пользователя во времени. Указанная функция должна удовлетворять следующим требованиям:

   • - для заданного пароля x легко вычислить новый пароль;
   • - зная х и y, сложно или невозможно определить функцию.

   Наиболее известными примерами функциональных методов являются: метод функционального преобразования и метод «рукопожатия».

   Идея метода функционального преобразования состоит в периодическом изменении самой функции. Последнее достигается наличием в функциональном выражении динамически меняющихся параметров, например, функции от некоторой даты и времени. Пользователю сообщается исходный пароль, собственно функция и периодичность смены пароля. Нетрудно видеть, что паролями пользователя на заданных -периодах времени будут следующие: x, f(x), f(f(x)), ..., f(x)n-1.

   Метод «рукопожатия» состоит в следующем. Функция парольного преобразования известна только пользователю и системе защиты. При входе в АС подсистема аутентификации генерирует случайную последовательность x, которая передается пользователю. Пользователь вычисляет результат функции y=f(x) и возвращает его в систему. Система сравнивает собственный вычисленный результат с полученным от пользователя. При совпадении указанных результатов подлинность пользователя считается доказанной.

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

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

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

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

   Карточки разделяют на два типа:

   • - пассивные (карточки с памятью);
   • - активные (интеллектуальные карточки).

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

   Иногда (обычно для физического контроля доступа) карточки применяют сами по себе, без запроса личного идентификационного номера.

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

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

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

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

   Перспективным направлением развития карточек является наделение их стандартом расширения портативных систем PCMCIA (PC Card). Такие карточки являются портативными устройствами типа PC Card, которые вставляются в разъем PC Card и не требуют специальных устройств чтения. В настоящее время они достаточно дороги.

   3. Методы аутентификации, основанные на измерении биометрических параметров человека, обеспечивают почти 100 % идентификацию, решая проблемы утраты паролей и личных идентификаторов. Однако такие методы нельзя использовать при идентификации процессов или данных (объектов данных), так как они только начинают развиваться (имеются проблемы со стандартизацией и распространением), требуют пока сложного и дорогостоящего оборудования. Это обусловливает их использование пока только на особо важных объектах и системах.

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

   Таблица 1. Примеры методов биометрии

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

   Назовем наиболее используемые биометрические атрибуты и соответствующие системы.

   • · Отпечатки пальцев. Такие сканеры имеют небольшой размер, универсальны, относительно недороги. Биологическая повторяемость отпечатка пальца составляет 10-5 %. В настоящее время пропагандируются правоохранительными органами из-за крупных ассигнований в электронные архивы отпечатков пальцев.
   • · Геометрия руки. Соответствующие устройства используются, когда из-за грязи или травм трудно применять сканеры пальцев. Биологическая повторяемость геометрии руки около 2 %.
   • · Радужная оболочка глаза. Данные устройства обладают наивысшей точностью. Теоретическая вероятность совпадения двух радужных оболочек составляет 1 из 1078.
   • · Термический образ лица. Системы позволяют идентифицировать человека на расстоянии до десятков метров. В комбинации с поиском данных по базе данных такие системы используются для опознания авторизованных сотрудников и отсеивания посторонних. Однако при изменении освещенности сканеры лица имеют относительно высокий процент ошибок.
   • · Голос. Проверка голоса удобна для использования в телекоммуникационных приложениях. Необходимые для этого 16-разрядная звуковая плата и конденсаторный микрофон стоят менее 25 $. Вероятность ошибки составляет 2 - 5%. Данная технология подходит для верификации по голосу по телефонным каналам связи, она более надежна по сравнению с частотным набором личного номера. Сейчас развиваются направления идентификации личности и его состояния по голосу - возбужден, болен, говорит правду, не в себе и т.д.
   • · Ввод с клавиатуры. Здесь при вводе, например, пароля отслеживаются скорость и интервалы между нажатиями.
   • · Подпись. Для контроля рукописной подписи используются дигитайзеры.
   • 4. Новейшим направлением аутентификации является доказательство подлинности удаленного пользователя по его местонахождению. Данный защитный механизм основан на использовании системы космической навигации, типа GPS (Global Positioning System). Пользователь, имеющий аппаратуру GPS, многократно посылает координаты заданных спутников, находящихся в зоне прямой видимости. Подсистема аутентификации, зная орбиты спутников, может с точностью до метра определить месторасположение пользователя. Высокая надежность аутентификации определяется тем, что орбиты спутников подвержены колебаниям, предсказать которые достаточно трудно. Кроме того, координаты постоянно меняются, что сводит на нет возможность их перехвата.

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

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

   • 1. Статическая аутентификация;
   • 2. Устойчивая аутентификация;
   • 3. Постоянная аутентификация.

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

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

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

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

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

   Этапы аутентификации.

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

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

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

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

   Есть и другие варианты хранения эталонов, например, такой:

   Ei = f(IDi, Ai).

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

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

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

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

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

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