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

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

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

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

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

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

Рис. 5.24.

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

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

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

• 1. На основе знания чего-либо. Примерами могут служить пароль, персональный идентификационный код (PIN), а также секретные и открытые ключи, знание которых демонстрируется в протоколах типа запрос-ответ.
• 2. На основе обладания чем-либо. Обычно это магнитные карты, смарт-карты, сертификаты и устройства touch memory.
• 3. На основе каких-либо неотъемлемых характеристик. Эта категория включает методы, базирующиеся на проверке биометрических характеристик пользователя (голос, радужная оболочка и сетчатка глаза, отпечатки пальцев, геометрия ладони и др.) В данной категории не используются криптографические методы и средства. Аутентификация на основе биометрических характеристик применяется для контроля доступа в помещения или к какой-либо технике.

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

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

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

При сравнении и выборе протоколов аутентификации необходимо учитывать следующие характеристики:

• 1. Наличие взаимной аутентификации. Это свойство отражает необходимость обоюдной аутентификации между сторонами аутентификационного обмена.
• 2. Вычислительная эффективность. Количество операций, необходимых для выполнения протокола.
• 3. Коммуникационная эффективность. Данное свойство отражает количество сообщений и их длину, необходимую для осуществления аутентификации.
• 4. Наличие третьей стороны. Примером третьей стороны может служить доверенный сервер распределения симметричных ключей или сервер, реализующий дерево сертификатов для распределения открытых ключей.
• 5. Гарантии безопасности. Примером может служить применение шифрования и цифровой подписи .

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

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

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

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

Рис. 5.25. Классификация протоколов аутентификации

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

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

Передача идентификатора и пароля от пользователя к системе может проводиться в открытом и зашифрованном виде.

Схема простой аутентификации с использованием пароля показана на рис. 5.26.

Рис. 5.26. Схема простой аутентификации с использованием пароля

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

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

Длина PIN- кода должна быть достаточно большой, чтобы минимизировать вероятность определения правильного PIN-кот методом проб и ошибок. С другой стороны, длина PIN- кода должна быть достаточно короткой, чтобы дать возможность держателям карт запомнить его значение. Согласно рекомендациям стандарта /50 9564-1 длина Я/УУ-кода должна содержать от 4 до 12 буквенно-цифровых символов. Однако в большинстве случаев ввод нецифровых символов технически невозможен, поскольку доступна только цифровая клавиатура. Поэтому обычно Я/УУ-код представляет собой 4-6-разрядное число, каждая цифра которого может принимать значение от 0 до 9.

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

Изменяемый Р1И-код может быть изменен согласно пожеланиям пользователя или заменен на число, которое пользователю легче запомнить. Простейшей атакой на Я/УУ-код, помимо подглядывания через плечо за вводом его с клавиатуры, является угадывание его значения. Вероятность угадывания зависит от длины п угадываемого Я/УУ-кода, от составляющих его символов т (для цифрового кода т = 10, для буквенного - т = 32, для буквенно-цифрового - т = 42 и т.д.), от количества разрешенных попыток ввода /" и выражается формулой:

Я = / / т п. (5.16)

Если Я/УУ-код состоит из 4 десятичных цифр, а число разрешенных попыток ввода равно трем, т.е. п = 4, т = 10, / = 3, то вероятность угадывания правильного значения Я/УУ-кода составит Я = 3/10 4 = = 0,00003, или 0,03%.

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

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

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

• а) односторонняя аутентификация;
• б) двусторонняя аутентификация;
• в) трехсторонняя аутентификация.

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

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

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

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

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

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

Рис. 5.27.

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

Протоколы аутентификации с симметричными алгоритмами шифрования реализуются в следующих вариантах:

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

Введем следующие обозначения:

гА - А;

г В - случайное число, сгенерированное участником В ;

/Д - метка времени, сгенерированная участником А;

Е к - симметричное шифрование на ключе К (ключ Одолжен быть предварительно распределен между А и В).

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

А->В:Е К ((А,В). (5.17)

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

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

Модель односторонней аутентификации с использованием слу-чаиных чисел можно представить в следующем виде:

• (5.18)
• (5.19)

А В: гВ.

А -» В: Е к (г В , В).

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

Модель двусторонней аутентификации, использующая случайные значения, можно представить в следующем виде:

• (5.20)
• (5.21)
• (5.22)

А В гВ.

А -> В: Е к (гА , гВ . В). А

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

Широко известными протоколами, обеспечивающими аутентификацию пользователей с привлечением в процессе аутентификации

третьей стороны, являются протокол распределения секретных ключей Нидхэма и Шредера и протокол Kerberos.

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

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

Получатель

Отправитель

Сообщение М

	- и к (М)
Сообщение М Дайджест т

Рис. 5.28. Применение для аутентификации односторонней

хеш-функции с параметром-ключом

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

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

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

• а) функция симметричного шифрования ЕК заменяется функцией /? А;
• б) проверяющий вместо установления факта совпадения полей в расшифрованных сообщениях с предполагаемыми значениями вычисляет значение однонаправленной функции и сравнивает его с полученным от другого участника обмена информацией;
• в) для обеспечения возможности независимого вычисления значения однонаправленной функции получателем сообщения в протоколе 1 метка времени /Л должна передаваться дополнительно в открытом виде, а в сообщении 2 протокола 3 случайное число гА должно передаваться дополнительно в открытом виде.

Модифицированный вариант протокола 3 с учетом сформулированных изменений имеет следующую структуру:

А (5.23)

А^В: гА, ИК (гА, г В , В). (5.24)

А В: НК (гА, гВ, А). (5.25)

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

А, РА(г, В). Л -> В: г.

Отправитель

Получатель

Рис. 5.29.

дополненному секретным ключом К

• (5.26)
• (5.27)

Участник В выбирает случайным образом г и вычисляет значение л: = h (г) (значение л: демонстрирует знание г без раскрытия самого значения г), далее он вычисляет значение е = РА(г, В). Под РА подразумевается алгоритм несимметричного шифрования (например, RSA, Шнорра, Эль-Гамаля, Вильямса, LUC и т.д.), а под И(-) - хеш-функция. Участник В отправляет сообщение (2.11) участнику А. Участник А расшифровывает е = РА(г, В) и получает значения г" и В", а также вычисляетх"= И(г). После этого производится ряд сравнений, доказывающих, что л: = х"и что полученный идентификатор /Гдействи-тельно указывает на участника В. В случае успешного проведения сравнения участник Л посылает г. Получив его, участник В проверяет, то ли это значение, которое он отправил в первом сообщении.

В качестве примера приведем модифицированный протокол Нидхема и Шредера, основанный на несимметричном шифровании. Протокол имеет следующую структуру (PB - алгоритм шифрования открытым ключом участника В):

• (5.28)
• (5.29)
• (5.30)

А^В.РВ (г,А). А Н). А

4. Строгая аутентификация, основанная на использовании цифровой подписи. В рекомендациях стандарта Х509 специфицирована схема аутентификации, основанная на использовании цифровой подписи,

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

Для описания данной схемы аутентификации используются следующие обозначения:

tA, гА,гВ - временная метка и случайные числа соответственно;

SA А;

SB - подпись, сгенерированная участником В;

cert А - А;

cert В - сертификат открытого ключа участника В.

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

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

• а) односторонняя аутентификация с применением меток времени:
  • (5.31)

А -> В: certA, tA , В , SA (tA , В).

После принятия данного сообщения участник В проверяет правильность метки времени /Л, полученный идентификатор В и, используя открытый ключ из сертификата семА, корректность цифровой подписи ЗАЦА, В).

• б) односторонняя аутентификация с использованием случайных чисел:
  • (5.32)
  • (5.33)

А -» В: сеМА, гА, В, 8А{гА , гВ, В).

Участник В , получив сообщение от участника Л, убеждается, что именно он является адресатом сообщения; используя открытый ключ участника Л, взятый из сертификата сепА, проверяет корректность подписи БА{гА, гВ , В) под числом гА, полученным в открытом виде, числом г В , которое было отослано в первом сообщении, и его идентификатором В. Подписанное случайное число гА используется для предотвращения атак с выборкой открытого текста.

• в) двусторонняя аутентификация с использованием случайных чисел:
  • (5.34)
  • (5.35)
  • (5.36)

А В: г В.

А -» В: сеМА, гА, В , А(гА, гВ. В). А

В данном протоколе обработка сообщений 1 и 2 выполняется так же, как и в предыдущем протоколе, а сообщение 3 обрабатывается аналогично сообщению 2.

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

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

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

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

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

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

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

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

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

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

Однако голос можно записать на пленку или другие носители. Поэтому для предотвращения подлога голоса в алгоритм аутентификации включается операция запроса отклика. Эта функция предлагает пользователю при входе в систему ответить на предварительно подготовленный и регулярно меняющийся запрос, например такой: «Повторите числа О, 1,5».

Системы аутентификации по узору радужной оболочки и сетчатки глаз. Эти системы можно разделить на два класса:

• а) использующие рисунок радужной оболочки глаза;
• б) использующие рисунок кровеносных сосудов сетчатки глаза.

Сетчатка человеческого глаза представляет собой уникальный

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

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

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

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

Первым кодируется прикус, который различается: 1 - ортогнатие, 2 - прогения, 3 - прямой, 4 - открытый, 5 - смешанный, 6 - глубокий. По этим результатам формируется первая часть цифрового кода.

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

Третьим результатом кодирования предлагается считать смещение зуба от нулевой оси в диапазоне А/2, -А/2, где А - максимальное значение отклонения зуба, идентифицируемого от оси при первоначальной санации.

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

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

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

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

Сравнение

Как проходит процедура аутентификации? Вот некий пользователь вознамерился прочитать свежий спам в своем электронном почтовом ящике. Он заходит на сайт почтового сервиса, читает рекламу и новости, но никаких писем ему пока не показывают – система не знает ни о его личности, ни о его намерениях. Когда в форму ввода логина и пароля он впишет свои «username/qwerty» и отправит эту информацию, начнется процесс аутентификации. Система проверит, существует ли пользователь с таким именем, совпадает ли введенный пароль с его учетной записью. Во многих случаях соответствия подобных идентификаторов достаточно, однако сервисы, где безопасность данных в приоритете, могут запрашивать и другие сведения: наличие сертификата, определенный IP-адрес или дополнительный код верификации.

Пройденная аутентификация означает, что пользователь действительно тот, кем представляется. Однако этого мало для предоставления ему доступа к данным – начинается процесс авторизации. В случае с почтовыми сервисами клиенты имеют равные права: каждый из них может просматривать письма и документы, редактировать их и создавать новые. А вот в социальных сетях или на форумах посетители принадлежат к определенной группе, и авторизация помогает системе определить, что позволено Юпитеру и не позволено быку. К примеру, у вас нет права писать сообщения пользователю, который добавил вас в черный список; вы не можете добавлять в сообщения ссылки на видео, пока не набрали определенное количество постов; вы можете просматривать фотографии человека, добавившего вас «в друзья». В локальных системах у учетной записи пользователя может не быть доступа к некоторым программам, стоять запрет на редактирование или копирование документов.

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

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

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

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

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

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

Наконец-то открывается заветная дверь, и охранник допускает сотрудника к определенной двери. Допуск получен — состоялась авторизация .

В виртуальном мире все практически так же, как в реальном. Только имена “персонажей” меняются. Сотрудник охраны — это сервер, контролирующий вход на сайт. А пришедший на работу менеджер — пользователь, который хочет попасть в свой аккаунт.

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

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

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

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

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

• одноразовый пароль или PIN-код;
• магнитные карты, смарт-карты, сертификаты с цифровой подписью;
• биометрические параметры: голос, сетчатка глаза, отпечатки пальцев.

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

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

Может быть как односторонней — когда только пользователь доказывает системе свою истинность, так и двусторонней — сервер и клиент взаимно подтверждают свою подлинность по системе “запрос-ответ”. Такой тип 2FA используется в токене Protectimus Ultra и позволяет, среди прочего, устранить риск попадания на фишинговые сайты.

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

Между терминами “авторизация” и “аутентификация” разница довольно значительна. Часто можно услышать или прочитать в интернете выражение “двухфакторная авторизация”, но оно, строго говоря, не является корректным. Ведь авторизация пользователя — это предоставление ему полномочий в какой-либо системе, окончательный ответ на вопрос: “Можно ли допустить этого человека к той или иной информации или функциям?”. И в силу своей однозначности авторизация никак не может быть двухфакторной.

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

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

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

Аутентификация (authentification ) предотвращает доступ к сети нежелательных лиц и разрешает вход для легальных пользователей. Процесс аутентификации следует отличать от процесса идентификации.

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

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

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

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

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

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

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

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

Авторизация субъекта доступа происходит после успешной идентификации и аутентификации. При авторизации субъекта операционная система выполняет действия, необходимые для того, чтобы субъект мог начать работу в системе. Например, авторизация пользователя в операционной системе UNIX включает в себя порождение процесса, являющегося операционной оболочкой, с которой в дальнейшем будет работать пользователь. В операционной системе Windows NT авторизация пользователя включает в себя создание маркера доступа пользователя, создание рабочего стола и запуск на нем от имени авторизуемого пользователя процессаUserinit, инициализирующего индивидуальную программную среду пользователя. Авторизация субъекта не относится напрямую к подсистеме защиты операционной системы. В процессе авторизации решаются чисто технические задачи, связанные с организацией начала работы в системе уже идентифицированного и аутентифицированного субъекта доступа.

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

децентрализованная схема, базирующаяся на рабочих станциях.

В первой схеме сервер управляет процессом предоставления ресурсов пользователю. Главная цель таких систем – реализовать «принцип единого входа». В соответствии с централизованной схемой пользователь один раз логически входит в сеть и получает на все время работы некоторый набор разрешений по доступу к ресурсам сети. Система Keгberоsс ее сервером безопасности и архитектурой клиент-сервер является наиболее известной системой этого типа. Системы ТАСАСSиRADIUS, часто применяемые совместно с системами удаленного доступа, также реализуют этот подход.

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

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

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

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

Идентификационные данные

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

Принципалом (principal) называется объект, в котором содержатся идентификационные данные пользователя и роли, к которым он принадлежит. Интерфейс IPrincipal имеет свойство Identity, которое возвращает объект Ildentity, и метод IsInRole, с помощью которого можно проверить, действительно ли пользователь является членом конкретной роли.

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

В.NET доступны следующие классы принципалов: WindowsPrincipal и GenericPrincipal . Однако помимо них также можно создавать собственные специальные классы принципалов, реализующие интерфейс IPrincipal.

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

Сначала понадобится импортировать пространства имен System.Security.Principal и System.Threading. Далее нужно указать, что.NET должна автоматически подключать принципал к соответствующей учетной записи Windows, поскольку из соображений безопасности.NET автоматически не заполняет свойство потока CurrentPrincipal. Сделать это можно следующим образом:

Using System; using System.Collections.Generic; using System.Linq; using System.Security.Principal; using System.Threading; namespace ConsoleApplication1 { class Program { static void Main(string args) { AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal); } } }

Для получения доступа к деталям учетной записи Windows можно использовать метод WindowsIdentity.GetCurrent() , однако он больше подходит в ситуации, когда доступ к принципалу требуется получить лишь один раз. Если нужен многократный доступ к принципалу, лучше с помощью метода SetPrincipalPolicy установить политику так, чтобы текущий поток сам предоставлял доступ к принципалу. Этот метод указывает, что принципал в текущем потоке должен хранить объект Windows Identity.

Все предназначенные для идентификации классы, подобные Windows Identity, реализуют интерфейс IIdentity. Этот интерфейс имеет три свойства (AuthenticationType, IsAuthenticated и Name), которые должны быть обязательно реализованы во всех производных идентификационных классах.

Добавьте следующий код для получения доступа к свойствам принципала из объекта Thread:

WindowsPrincipal principial = (WindowsPrincipal)Thread.CurrentPrincipal; WindowsIdentity identity = (WindowsIdentity)principial.Identity; Console.WriteLine("Тип идентификации: " + identity.ToString()); Console.WriteLine("Имя: " + identity.Name); Console.WriteLine("Пользователи? " + principial.IsInRole(WindowsBuiltInRole.User)); Console.WriteLine("Администраторы? " + principial.IsInRole(WindowsBuiltInRole.Administrator)); Console.WriteLine("Аутентифицирован: " + identity.AuthenticationType); Console.WriteLine("Анонимный? " + identity.IsAnonymous); Console.WriteLine("маркер: " + identity.Token);

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

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

Декларативное обеспечение безопасности на основе ролей

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

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

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

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

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

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

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

Using System; using System.Security; using System.Security.Principal; using System.Security.Permissions; namespace ConsoleApplication1 { class Program { static void Main(string args) { AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal); try { ShowMessage(); } catch (SecurityException exception) { Console.WriteLine("Исключение " + exception.Message); } finally { Console.ReadLine(); } } static void ShowMessage() { Console.WriteLine("Текущий принципиал зарегистрировался локально и является членом группы Users"); } } }

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

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