идентификация и аутентификация. обзор технологий и методов

Пример на основе скуд

Рассмотрим случай, который поможет объяснить данную разницу, на примере системы контроля и управления доступом[3] (далее – СКУД).

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

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

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

Из двух типов устройств к пункту 2.19 (Шифровальные (криптографические) средства) приложения № 2 к Решению Коллегии Евразийской экономической комиссии от 21.04.2022 N 30 можно отнести только считыватель, т.к. он выполняет криптографические функции в рамках процедуры аутентификации, а значит содержит шифровальные средства.

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

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

Методы, основанные на измерении биометрических параметров человека

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

Методы, основанные на использовании субъектом ис секретного идентификатора – пароля

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

Авторизация

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


Авторизация не просто дает вам возможность зайти в систему, но и разрешает совершать там определенные операции: читать документы, отправлять письма, изменять данные — под тем самым идентификатором, который вы предъявили в самом начале.

Советы:

Актуальность

Количество объектов, на которых функционируют системы контроля доступа с незащищенной технологией идентификации исчисляется десятком тысяч. Несмотря на поступательное развитие технологий в современных системах контроля доступа в качестве идентификатора используются карты, работающие по открытому протоколу передачи данных на частоте 125 кГц, выпускаемые под марками EM Marin (EM4100, EM4102, TK4100), HID Prox и Indala.

О нецелесообразности использования proximity карт для организации СКУД в материалахуязвимость технологий считывания и повторное воспроизведение карт доступа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идентификатор доступа


Идентификатор доступа – уникальный признак субъекта либо объекта доступа, позволяющий отличать его от

В системах контроля и управления доступом используются следующие виды идентификаторов (согласно ГОСТ Р 51241-2008):

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

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

Методы аутентификации

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


Если в процессе аутентификации подлинность субъекта установлена, то СКУД предоставляет ему физический и/или логический доступ в соответствии с его полномочиями (совокупностью прав).

Миграция с технологии proximity на защищенные технологии

Лидеры средств идентификации предлагают различные способы апгрейда систем. Самые распространенные из них:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Особенности при нотифицировании

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

В соответствии с Решением ЕЭК от 21 апреля 2022 г. № 30 нотификация оформляется на товары, относящиеся к одной или нескольким из категорий товаров из перечня[1]. Одной из наиболее важных и распространенных категорий является категория 2:

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

(так, около 30% всех товаров, отраженных в Едином реестре нотификаций[2], поддерживают криптографические функции в рамках реализации процедуры аутентификации или ЭЦП.

Переход на защищенные технологии идентификации

Чем заменить устаревшие Proximity карты в действующей системе СКУД

Переход с карты на смарт-карту или с карты на биометрическую карту?

На выставке ISC West, которая прошла с 15 по 17 апреля в Лас-Вегасе, разработчик и производитель средств аутентификации по отпечаткам пальцев, компания Zwipe продемонстрировала биометрические решения, в которых используется биометрическая карта.

Как это работает? На биометрической карте установлен сканер отпечатков пальцев с 3D-технологией, а также RFID-чип, который обеспечивает поддержку популярных технологий согласно стандарту ISO 14443, включая бесконтактные карты DESFire EV1 и MIFARE Classic.

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

Примечания

  1. 1,01,1Перечень категорий товаров, являющихся шифровальными средствами, технические и криптографические характеристики которых подлежат нотификации (приложение № 4 к приложению № 9 к Решению Коллегии Евразийской экономической комиссии от 21 апреля 2022 г. № 30)
  2. Единый реестр нотификаций о характеристиках шифровальных (криптографических) средств и товаров, их содержащих
  3. Система контроля и управления доступом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

Похожее:  Сниффер — что за зверь — Хакер

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *