Что понимается под идентификацией пользователя
Идентификация, аутентификация и авторизация – в чем разница?
Мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», хотя на самом деле речь идет об аутентификации. Ничего страшного в этом нет, часто обе стороны диалога понимают, что в действительности имеется в виду. Но всегда лучше знать и понимать слова, которые употребляем.
Определения
Что же значат все эти термины, и чем соответствующие процессы отличаются друг от друга?
Примеры
Пользователь хочет войти в свой аккаунт Google (Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов). Вот что при этом происходит:
Аутентификация без предварительной идентификации лишена смысла – пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
Идентификация без аутентификации не работает. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, известное только данному пользователю: например, одноразовый код для подтверждения входа.
А вот авторизация без идентификации и аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны всем. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный субъект. Несмотря на это, система его все же авторизовала – то есть выдала право прочитать этот документ.
Но если вы открыли этот документ для чтения только определенным пользователям, то им в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа – авторизоваться.
Если же речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного субъекта на чтение вашей переписки.
Что еще важно знать
Аутентификация – пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только простенький пароль, то какой-нибудь злоумышленник может ваш аккаунт угнать. Поэтому:
Идентификация, аутентификация и авторизация — в чем разница?
Объясняем на енотах, в чем разница между идентификацией и авторизацией, а также зачем нужна аутентификация, тем более двухфакторная.
Это происходит с каждым из нас, причем ежедневно: мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», когда на самом деле речь идет об аутентификации.
Ничего такого уж страшного в этом нет — пока идет бытовое общение и обе стороны диалога по контексту понимают, что в действительности имеется в виду. Но всегда лучше знать и понимать слова, которые употребляешь, а то рано или поздно нарвешься на зануду-специалиста, который вынет всю душу за «авторизацию» вместо «аутентификации», кофе среднего рода и такое душевное, но неуместное в серьезной беседе слово «ихний».
Идентификация, аутентификация и авторизация: серьезные определения
Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:
Объясняем идентификацию, аутентификацию и авторизацию на енотах
Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:
Аутентификация без предварительной идентификации лишена смысла — пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
Идентификация без аутентификации — это просто глупо. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, что может быть известно только данному пользователю: например, одноразовый код для подтверждения входа.
А вот авторизация без идентификации и тем более аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны вообще кому угодно. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный енот. Несмотря на то, что енот совершенно неопознанный, система его все же авторизовала — то есть выдала право прочитать этот документ.
А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа — авторизоваться.
А уж если речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного енота на чтение вашей переписки — если, конечно, он не идентифицируется с вашим логином и не аутентифицируется с вашим паролем. Но тогда это уже не будет неопознанный енот, поскольку Google однозначно определит этого енота как вас.
Теперь вы знаете, чем идентификация отличается от аутентификации и авторизации. Что еще важно понимать: аутентификация — пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только слабенький пароль, то какой-нибудь енот может ваш аккаунт угнать. Поэтому:
Идентификация и аутентификация
Идентификация — это определение пользователя в системе по его признаку. Обычно речь идет о логине, которым является электронная почта, мобильный телефон или комбинация чисел и цифр, придуманная системой или пользователем.
Идентификация, аутентификация и авторизация
Если пользователь намерен зайти в систему под своими учетными данными, он проходит и идентификацию, и аутентификацию. Например, при входе на какой-то сайт, в банкинг, в сервис электронных платежей, в личный кабинет МФО, коммунальной компании.
Как проходит идентификация пользователя:
После идентификации и аутентификации происходит авторизация. Система понимает, что это за пользователь, что это именно он. Далее она определяет, что он может делать, предоставляет ему определенные права. Это и есть авторизация.
Биометрическая аутентификация
Вариантов аутентификации пользователей становится все больше, компании и сервисы активно применяют в этом биометрию человека. На сегодня существуют такие методы:
В последнее время банки стали активно применять аутентификацию клиента по голосу. Они создают базу голосовых данных: если клиент в ней есть, то при звонке он проходит голосовую аутентификацию и получает нужную информацию или услугу без дополнительных подтверждений личности.
Благодаря созданию биометрических способов аутентификации пользователи стали более защищенными. Некоторые системы применяют двойную биометрическую аутентификацию, например, считывают сразу и отпечаток пальцев, и геометрию руки.
Конспект по дисциплине ИБ на тему «Идентификация и аутентификация»
Онлайн-конференция
«Современная профориентация педагогов
и родителей, перспективы рынка труда
и особенности личности подростка»
Свидетельство и скидка на обучение каждому участнику
Идентификация и аутентификация
4.1.1. Введение
Цели изучения темы
изучить содержание и механизмы реализации сервисов безопасности «идентификация» и «аутентификация».
Требования к знаниям и умениям
Студент должен знать:
механизмы идентификации и аутентификации;
идентификаторы, используемые при реализации механизма идентификации и аутентификации.
Студент должен уметь:
использовать механизмы идентификации и аутентификации для защиты информационных систем.
Ключевой термин: идентификация и аутентификации.
Идентификация и аутентификации применяются для ограничения доступа случайных и незаконных субъектов (пользователи, процессы) информационных систем к ее объектам (аппаратные, программные и информационные ресурсы).
Структурная схема терминов
4.1.2. Определение понятий «идентификация» и «аутентификация»
Идентификация и аутентификации применяются для ограничения доступа случайных и незаконных субъектов (пользователи, процессы) информационных систем к ее объектам (аппаратные, программные и информационные ресурсы).
Общий алгоритм работы таких систем заключается в том, чтобы получить от субъекта (например, пользователя) информацию, удостоверяющую его личность, проверить ее подлинность и затем предоставить (или не предоставить) этому пользователю возможность работы с системой.
Наличие процедур аутентификации и/или идентификации пользователей является обязательным условием любой защищенной системы, поскольку все механизмы защиты информации рассчитаны на работу с поименованными субъектами и объектами информационных систем.
Дадим определения этих понятий.
Идентификация – присвоение субъектам и объектам доступа личного идентификатора и сравнение его с заданным.
Аутентификация (установление подлинности) – проверка принадлежности субъекту доступа предъявленного им идентификатора и подтверждение его подлинности. Другими словами, аутентификация заключается в проверке: является ли подключающийся субъект тем, за кого он себя выдает.
При построении систем идентификации и аутентификации возникает проблема выбора идентификатора, на основе которого осуществляются процедуры идентификации и аутентификации пользователя. В качестве идентификаторов обычно используют:
набор символов (пароль, секретный ключ, персональный идентификатор и т. п.), который пользователь запоминает или для их запоминания использует специальные средства хранения (электронные ключи);
физиологические параметры человека (отпечатки пальцев, рисунок радужной оболочки глаза и т. п.) или особенности поведения (особенности работы на клавиатуре и т. п.).
Наиболее распространенными простыми и привычными являются методы аутентификации, основанные на паролях – конфиденциальных идентификаторах субъектов. В этом случае при вводе субъектом своего пароля подсистема аутентификации сравнивает его с паролем, хранящимся в базе эталонных данных в зашифрованном виде. В случае совпадения паролей подсистема аутентификации разрешает доступ к ресурсам системы.
Парольные методы аутентификации по степени изменяемости паролей делятся на:
методы, использующие постоянные (многократно используемые) пароли;
методы, использующие одноразовые (динамично изменяющиеся) пароли.
Использование одноразовых или динамически меняющихся паролей является более надежным методом парольной защиты.
В последнее время получили распространение комбинированные методы идентификации и аутентификации, требующие, помимо знания пароля, наличие карточки (token) – специального устройства, подтверждающего подлинность субъекта.
Карточки разделяют на два типа:
пассивные (карточки с памятью);
активные (интеллектуальные карточки).
Самыми распространенными являются пассивные карточки с магнитной полосой, которые считываются специальным устройством, имеющим клавиатуру и процессор. При использовании указанной карточки пользователь вводит свой идентификационный номер. В случае его совпадения с электронным вариантом, закодированным в карточке, пользователь получает доступ в систему. Это позволяет достоверно установить лицо, получившее доступ к системе и исключить несанкционированное использование карточки злоумышленником (например, при ее утере). Такой способ часто называют двукомпонентной аутентификацией.
Интеллектуальные карточки кроме памяти имеют собственный микропроцессор. Это позволяет реализовать различные варианты парольных методов защиты, например, многоразовые пароли, динамически меняющиеся пароли.
Методы аутентификации, основанные на измерении биометрических параметров человека, обеспечивают почти 100 % идентификацию, решая проблемы утери или утраты паролей и личных идентификаторов. Однако эти методы нельзя использовать при идентификации процессов или данных (объектов данных), они только начинают развиваться, требуют пока сложного и дорогостоящего оборудования. Это обусловливает их использование пока только на особо важных объектах.
Примерами внедрения указанных методов являются системы идентификации пользователя по рисунку радужной оболочки глаза, по почерку, по тембру голоса и др.
Новейшим направлением аутентификации является доказательство подлинности удаленного пользователя по его местонахождению. Данный защитный механизм основан на использовании системы космической навигации, типа GPS (Global Positioning System). Пользователь, имеющий аппаратуру GPS, многократно посылает координаты заданных спутников, находящихся в зоне прямой видимости. Подсистема аутентификации, зная орбиты спутников, может с точностью до метра определить месторасположение пользователя. Высокая надежность аутентификации определяется тем, что орбиты спутников подвержены колебаниям, предсказать которые достаточно трудно. Кроме того, координаты постоянно меняются, что исключает их перехват. Такой метод аутентификации может быть использован в случаях, когда авторизованный удаленный пользователь должен находиться в нужном месте.
4.1.3. Механизм идентификация и аутентификация пользователей
Общая процедура идентификации и аутентификации пользователя при его доступе в защищенную информационную систему заключается в следующем.
Пользователь предоставляет системе свой личный идентификатор (например, вводит пароль или предоставляет палец для сканирования отпечатка). Далее система сравнивает полученный идентификатор со всеми хранящимися в ее базе идентификаторами. Если результат сравнения успешный, то пользователь получает доступ к системе в рамках установленных полномочий. В случае отрицательного результата система сообщает об ошибке и предлагает повторно ввести идентификатор. В тех случаях, когда пользователь превышает лимит возможных повторов ввода информации (ограничение на количество повторов является обязательным условием для защищенных систем) система временно блокируется и выдается сообщение о несанкционированных действиях (причем, может быть, и незаметно для пользователя).
Если в процессе аутентификации подлинность субъекта установлена, то система защиты информации должна определить его полномочия (совокупность прав). Это необходимо для последующего контроля и разграничения доступа к ресурсам.
В целом аутентификация по уровню информационной безопасности делится на три категории:
Первая категория обеспечивает защиту только от несанкционированных действий в системах, где нарушитель не может во время сеанса работы прочитать аутентификационную информацию. Примером средства статической аутентификации являются традиционные постоянные пароли. Их эффективность преимущественно зависит от сложности угадывания паролей и, собственно, от того, насколько хорошо они защищены.
Устойчивая аутентификация использует динамические данные аутентификации, меняющиеся с каждым сеансом работы. Реализациями устойчивой аутентификации являются системы, использующие одноразовые пароли и электронные подписи. Устойчивая аутентификация обеспечивает защиту от атак, где злоумышленник может перехватить аутентификационную информацию и использовать ее в следующих сеансах работы.
Однако устойчивая аутентификация не обеспечивает защиту от активных атак, в ходе которых маскирующийся злоумышленник может оперативно (в течение сеанса аутентификации) перехватить, модифицировать и вставить информацию в поток передаваемых данных.
Постоянная аутентификация обеспечивает идентификацию каждого блока передаваемых данных, что предохраняет их от несанкционированной модификации или вставки. Примером реализации указанной категории аутентификации является использование алгоритмов генерации электронных подписей для каждого бита пересылаемой информации.
4.1.4. Выводы по теме
Идентификация и аутентификации применяются для ограничения доступа случайных и незаконных субъектов (пользователи, процессы) информационных систем к ее объектам (аппаратные, программные и информационные ресурсы).
Общий алгоритм работы таких систем заключается в том, чтобы получить от субъекта (например, пользователя) информацию, удостоверяющую его личность, проверить ее подлинность и затем предоставить (или не предоставить) этому пользователю возможность работы с системой.
Идентификация – присвоение субъектам и объектам доступа личного идентификатора и сравнение его с заданным.
Аутентификация (установление подлинности) – проверка принадлежности субъекту доступа предъявленного им идентификатора и подтверждение его подлинности.
В качестве идентификаторов в системах аутентификации обычно используют набор символов (пароль, секретный ключ, персональный идентификатор и т. п.), который пользователь запоминает или для их запоминания использует специальные средства хранения (электронные ключи). В системах идентификации такими идентификаторами являются физиологические параметры человека (отпечатки пальцев, рисунок радужной оболочки глаза и т. п.) или особенности поведения (особенности работы на клавиатуре и т. п.).
В последнее время получили распространение комбинированные методы идентификации и аутентификации, требующие, помимо знания пароля, наличие карточки (token) – специального устройства, подтверждающего подлинность субъекта.
Если в процессе аутентификации подлинность субъекта установлена, то система защиты информации должна определить его полномочия (совокупность прав). Это необходимо для последующего контроля и разграничения доступа к ресурсам.
В целом аутентификация по уровню информационной безопасности делится на три категории: статическая аутентификация, устойчивая аутентификация и постоянная аутентификация.
Постоянная аутентификация является наиболее надежной, поскольку обеспечивает идентификацию каждого блока передаваемых данных, что предохраняет их от несанкционированной модификации или вставки.
4.1.5. Вопросы для самоконтроля
Что понимается под идентификацией пользователя?
Что понимается под аутентификацией пользователей?
Применим ли механизм идентификации к процессам? Почему?
Перечислите возможные идентификаторы при реализации механизма идентификации.
Перечислите возможные идентификаторы при реализации механизма аутентификации.
Какой из механизмов (аутентификация или идентификация) более надежный? Почему?
В чем особенности динамической аутентификации?
Опишите механизм аутентификации пользователя.
Что такое «электронный ключ»?
Перечислите виды аутентификации по уровню информационной безопасности.
Какой из видов аутентификации (устойчивая аутентификация или постоянная аутентификация) более надежный?
4.1.6. Ссылки на дополнительные материалы (печатные и электронные ресурсы)
Галатенко В. А. Основы информационной безопасности. – М: Интернет-Университет Информационных Технологий – ИНТУИТ. РУ, 2003.
Грязнов Е., Панасенко С. Безопасность локальных сетей – Электрон. журнал «Мир и безопасность» № 2, 2003. – Режим доступа к журн.: www.daily.sec.ru.
Щербаков А. Ю. Введение в теорию и практику компьютерной безопасности. – М.: Издательство Молгачева С. В., 2001.
В. Г. Олифер, Н. А. Олифер. Компьютерные сети. Принципы, технологии, протоколы. – СПб: Питер, 2000.
Карпов Е. А., Котенко И. В., Котухов М. М., Марков А. С., Парр Г. А., Рунеев А. Ю. Законодательно-правовое и организационно-техническое обеспечение информационной безопасности автоматизированных систем и информационно-вычислительных сетей / Под редакцией И. В.Котенко. – СПб.: ВУС, 2000.
Спортак Марк, Паппас Френк. Компьютерные сети и сетевые технологии. – М.: ТИД «ДС», 2002.
Идентификация и аутентификация. Так ли все просто?
Идентификация и аутентификация. Так ли все просто?
Идентификация и аутентификация. Так ли все просто?
Идентификация и аутентификация – это один из основных механизмов защиты, который, пожалуй, на сегодняшний день наиболее исследован. Вместе с тем, большинство исследований посвящено различным способам хранения и ввода идентификационной информации о пользователе. Однако разработчики средств защиты почему-то забывают (что наглядно иллюстрируют возможности большинства представленных на рынке средств защиты), что задача иденетификации и аутентификации в своей постановке, когда речь заходит о компьютерной безопасности, куда шире, чем задача контроля входа пользователя в систему.
Требования нормативных документов к механизму идентификации и аутентификации.
Прежде всего, обратимся к формализованным требованиям в области защиты информации, попробуем в них найти ответ на вопрос, какими же функциями должен быть наделен механизм идентификации и аутентификации? Формализованные требования к механизму идентификации и аутентификации пользователей задаются действующим сегодня нормативным документом «Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации».
Видим, что, выдвигается требование, состоящее в необходимости идентификации и аутентификации пользователя именно при запросах на доступ.
Заметим, что в требованиях к СВТ 4-го класса защищенности вообще задачи идентификации и аутентификации пользователя при входе в систему и при запросе на доступ разделены на две самостоятельные задачи, кроме того, здесь появляется некое понятие «субъект» в общем виде.
Что же представляет собою запрос на доступ к ресурсу? В общем случае подобный запрос может быть охарактеризован тем, какой пользователь обращается к ресурсу (идентификатор пользователя, определяющий, кому нужен ресурс), какой процесс (приложение) обращается к ресурсу (идентификатор процесса, определяющий для решения каких задач пользователю нужен ресурс), и, собственно, к какому ресурсу осуществляется обращение (идентификатор объекта доступа).
Естественно, возникает вопрос, с какой целью необходима какая-либо идентификация и аутентификация субъекта и объекта доступа при запросах на доступ к ресурсу. Ведь в любой системе защиты предполагается, что реализуется механизм идентификации и аутентификации пользователя при входе в систему. Результатом этого является однозначная идентификация пользователя, запускаемые им процессы наследуют этот идентификатор, т.е. именно от лица идентифицированного пользователя и обращаются к ресурсу, на чем, кстати говоря, и строится в своей основе разграничительная политика доступа к ресурсам. С объектом доступа вообще все понятно, например, файловый объект, казалось бы, однозначно идентифицируется своим полнопутевым именем. Какие здесь еще проблемы?
Задача идентификации и аутентификации субъекта «пользователь» при запросах на доступ
Этапы идентификации и аутентификации пользователя, реализуемые ОС Windows
Этапы идентификации и аутентификации пользователя, реализуемые в системе (на примере ОС Windows), представлены на рис. 1.
Первый шаг идентификации, поддерживаемый режимом аутентификации, реализуется при входе пользователя в систему. Здесь следует выделить возможность входа в штатном и в безопасном режиме (Safe Mode). В порядке замечания отметим, что принципиальным отличием безопасного режима является то, что при запуске системы в безопасном режиме можно отключить загрузку сторонних по отношению к системе драйверов и приложений. Поэтому, если в системе используется добавочная СЗИ от НСД, можно попытаться загрузить систему в безопасном режиме без компонент СЗИ от НСД, т.е. без средства защиты. С учетом же того, что загрузить систему в безопасном режиме может любой пользователь (в Unix системах – только Root), то СЗИ от НСД должна обеспечивать возможность входа в систему в безопасном режиме (после идентификации и аутентификации) только под учетной записью администратора.
Второй шаг состоит в запуске пользователем процессов, которые уже, в свою очередь, порождают потоки (именно потоки в общем случае и осуществляют обращение к ресурсам). Все работающие в системе процессы и потоки выполняются в контексте защиты того пользователя, от имени которого они так или иначе были запущены. Для идентификации контекста защиты процесса или потока используется объект, называемый маркером доступа (access token). В контекст защиты входит информация, описывающая привилегии, учетные записи и группы, сопоставленные с процессом и потоком. При регистрации пользователя (первый шаг, см. рис. 1) в системе создается начальный маркер, представляющий пользователя, который входит в систему, и сопоставляющий его с процессом оболочки, применяемой для регистрации пользователя. Все программы, запускаемые пользователем, наследуют копию этого маркера. Механизмы защиты в Windows используют маркер, определяя набор действий, разрешенных потоку или процессу.
Рис.1. Этапы идентификации и аутентификации пользователя
В порядке замечания отметим следующее. С одной стороны, это очень полезная опция, которая может быть использована в корпоративных приложениях, когда на одном компьютере требуется обрабатывать конфиденциальные и открытые данные. При этом предполагается, что для обработки данных различных категорий создаются различные учетные записи. Данная опция предполагает, что одновременно (без перезагрузки) можно обрабатывать данные различных категорий, например, под одной учетной записью обрабатывать необходимым приложением конфиденциальные данные, под другой учетной записью запустить Internet-приложение (у Вас на мониторе может быть открыто одновременно два окна). Естественно, что реализация данной возможности выставляет и дополнительные требования к СЗИ от НСД (например, при подобном запуске приложения ОС Windows между пользователями не изолируется буфер обмена, который в ОС является «принадлежностью» рабочего стола).
В порядке замечания отметим, что аналогичная ситуация имеет место и в ОС семейства Unix, где существуют понятия идентификатора и эффективного идентификатора (под которым собственно и осуществляется запрос доступа к ресурсам).
Вывод. Требование «КСЗ должен обеспечивать идентификацию пользователей при запросах на доступ…» актуально и должно реализовываться современными СЗИ от НСД. При этом задача защиты при выполнении этого требования сводится к контролю корректности олицетворения при запросах доступа к ресурсам, т.к. именно использование сервиса олицетворения может привести к неконтролируемой смене исходного идентификатора.
Реализация механизма идентификации и аутентификации при запросах доступа к ресурсам
В общем виде решение задачи должно состоять в следующем. При запросе доступа к ресурсу должны выявляться факты произошедшего олицетворения (соответственно, субъектом доступа здесь выступает процесс, для которого анализируется наличие олицетворяющего маркера доступа) и проверяться их корректность в соответствии с заданными разрешениями (запретами), что проиллюстрировано на рис. 2. Очевидно, что проверка прав субъекта доступа к ресурсу должна осуществляться уже после проверки корректности его идентификации.
Рис.2. Укрупненный алгоритм идентификации и аутентификациипри запросе доступа к ресурсу
Таким образом, в качестве субъекта доступа выступает процесс (в том числе, это обусловливается и тем, что различные процессы (приложения) могут затребовать и различных правил разрешенных (запрещенных) олицетворений, что невозможно обеспечить, если в качестве субъекта доступа принять пользователя – учетную запись).
Ограничения возможности корректного решения задачи
Ограничения, о которых пойдет далее речь, в первую очередь, относятся к реализации разграничительной политики доступа к устройствам.
Разграничение доступа к устройствам – это задача противодействия внутренним ИТ-угрозам (в частности, решаемая для защиты информации от санкционированных пользователей – инсайдеров), которая далеко не единственная в данных приложениях, но, пожалуй, сегодня наиболее обсуждаемая.
Заметим, что в нормативном документе «Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации» вопросы контроля доступа пользователей к устройствам (начиная с СВТ 4-го класса защищенности) формируются в виде отдельного требования: КСЗ должен включать в себя механизм, посредством которого санкционированный пользователь надежно сопоставляется с выделенным ему конкретным устройством.
Чтобы понять суть существующих ограничений, проанализируем, как ОС Windows (в ОС семейства Unix рассматриваемые проблемы не столь критичны, т.к. устройства в них монтируются к файловой системе) работает с устройствами, и сразу натолкнемся на проблему (решения рассматриваемой задачи, реализуемые собственно ОС Windows, рассматривать не будем, т.к. они не удовлетворяют требованиям применения в корпоративных приложениях). Проблема здесь состоит в том, что многие устройства предполагают возможность взаимодействия с ними приложения не напрямую, а через драйвер. В этом случае запрос доступа к устройству осуществляется от лица пользователя System (варианты решения задачи на прикладном уровне рассматривать не будем, ввиду их априорной уязвимости). Возникает вопрос, а откуда взять идентификатор пользователя, который инициировал это обращение к устройству. Можно, конечно, «посмотреть», какой пользователь зарегистрирован в системе, и фильтровать запросы доступа применительно к его учетной записи (кстати говоря, подобный подход реализуется некоторыми специализированными средствами защиты). Но не будем забывать, что современные ОС Windows многопользовательские. Как отмечалось выше, начиная с Windows XP, возможность входа в многопользовательский режим уже вынесена в интерфейс (например, из проводника можно по правой кнопки мыши выбрать опцию запуска приложения с правами другого пользователя – получим многопользовательский режим). В многопользовательском режиме в системе одновременно зарегистрировано уже несколько пользователей, при этом выявление учетной записи, от которой осуществлен запрос доступа к устройству, становится неразрешимой (или, по крайней мере, весьма сложно корректно решаемой) задачей.
В результате получаем некорректное решение задачи защиты в общем виде, которое обусловливается не особенностью частного решения, а архитектурной особенностью ОС. А ведь решение по реализации обработки на компьютере одним и тем же пользователем как открытой, так и конфиденциальной информации, априори предполагающее задание различных режимов обработки (соответственно, различных прав доступа к ресурсам) информации различной категории, состоящее в том, что информация различной категории обрабатывается одним и тем же пользователем под различными учетными записями, на сегодняшний день, на наш взгляд, является единственно эффективным решением.
В порядке замечания отметим, что существуют средства, предполагающие иные подходы к решению задачи задания различных режимов обработки информации различной категории одним пользователем (не разделение по учетным записям), однако эффективность подобных средств в данной работе анализироваться не будет (это вопрос самостоятельного исследования).
Таким образом, видим, что задача идентификации пользователя может решаться некорректно именно в тех приложениях, для использования в которых и предназначено средство защиты.
При этом будем учитывать, что для обращения к подобным устройствам, как правило, необходимо приложение (отдельная программа), взаимодействующая с драйвером устройства. С учетом сказанного можем заключить, что данную задачу можно решить с использованием механизма обеспечения замкнутости программной среды, разрешив/запретив пользователю запуск приложения для работы с устройствами (при доступе к объекту файловой системы идентификатор пользователя всегда, в том числе, и при многопользовательском режиме, может быть корректно определен, при этом, конечно, не будем забывать о необходимости идентификации и аутентификации при запросах доступа к ресурсам – это первая из рассмотренных нами задач).
Вывод. Требование «КСЗ должен включать в себя механизм, посредством которого санкционированный пользователь надежно сопоставляется с выделенным ему конкретным устройством» для ряда устройств (взаимодействующих по средством драйвера) технически невыполнимо. Поэтому для опосредованного выполнения данного требования должны применяться механизмы защиты, позволяющие ограничивать взаимодействие конкретных пользователей с устройствами с использованием тех механизмов контроля доступа к ресурсам, которые позволяют однозначно идентифицировать пользователя при запросе доступа к ресурсу.
Задача идентификации и аутентификации субъекта «процесс» при запросах на доступ.
Прежде всего, несколько слов об альтернативных подходах к реализации разграничительной политики доступа к ресурсам. В качестве субъекта доступа (для которого разграничиваются права доступа к ресурсам) в общем случае необходимо рассматривать ту сущность, которая по каким-либо соображениям не пользуется доверием (для нее и следует ограничивать права доступа). Если мы говорим о внутренних ИТ-угрозах (противодействие попыткам хищения информации со стороны санкционированных пользователей – инсайдеров), в качестве субъекта доступа, в первую очередь, следует рассматривать пользователя. При этом в равной мере актуальны задачи разграничения прав доступа к ресурсам как между различными пользователями (чтобы один пользователь не получил доступ к информационным ресурсам другого пользователя), так и для одного пользователя. В последнем случае необходимо ограничивать (либо разделять, если пользователем может обрабатываться и открытая, и конфиденциальная информация) режимы обработки информации (по сути – это уже «сессионный» контроль доступа к ресурсам).
Однако на практике не менее актуальной является задача разграничения прав доступа к ресурсам для субъекта «процесс».В общем случае именно процесс следует рассматривать в качестве источника возникновения внешней ИТ-угрозы. Тому может быть несколько причин, что следует из приведенной классификации известных типов вирусов, положим их в основу классификации процессов, несущих в себе угрозу:
• Несанкционированные (сторонние) процессы. Это процессы, которые не требуются пользователю для выполнения своих служебных обязанностей и могут несанкционированно устанавливаться на компьютер (локально, либо удаленно) с различными целями, в том числе, и с целью осуществления несанкционированного доступа (НСД) к информации’
• Критичные процессы. К ним мы отнесем две группы процессов: к процессам первой группы отнесем те, которые запускаются в системе с привилегированными правами, например, под учетной записью System, к процессам второй группы те, которые наиболее вероятно могут быть подвержены атакам, например, сетевые службы. Атаки на процессы первой группы наиболее критичны, что связано с возможностью расширения привилегий, в пределе – получения полного управления системой; атаки на процессы второй группы наиболее вероятны.
• Скомпрометированные процессы – процессы, содержащие ошибки (уязвимости), ставшие известными, использование которых позволяет осуществить НСД к информации. Отнесение данных процессов в отдельную группу обусловлено тем, что с момента обнаружения уязвимости и до момента устранения ее разработчиком системы или приложения может пройти несколько месяцев. В течение этого времени в системе находится известная уязвимость, поэтому система не защищена.
• Процессы, априори обладающие недекларированными (документально не описанными) возможностями. К этой группе мы отнесем процессы, являющиеся средой исполнения (прежде всего, это виртуальные машины, являющиеся средой исполнения для скриптов и апплетов, и офисные приложения, являющиеся средой исполнения для макросов).
На самом деле, процесс всегда несет в себе угрозу компьютерной безопасности. Даже если не акцентировать свое внимание на закладках (особенно этот вопрос актуален для свободно распространяемого ПО, либо ПО иностранного производства для особо критичных приложений), всегда высока вероятность ошибки программирования в приложении, предоставляющей злоумышленнику недекларируемую разработчиком ПО возможность НСД.
Таким образом, если вероятность угрозы, исходящей со стороны пользователя, еще можно снизить, то вероятность угрозы со стороны процесса всегда высока.
Заметим, что угроза, порождаемая процессом, далеко не всегда является внешней ИТ-угрозой. Инсайдер также может запустить стороннюю программу, модифицировать код санкционированного приложения, воспользоваться недекларируемой возможностью ПО.
Другими словами, разграничительная политика доступа к ресурсам для процессов носит более общий характер и обязательно должна реализовываться СЗИ от НСД (если, конечно, мы говорим об эффективном средстве защиты информации). Задача обеспечения компьютерной безопасности в рассматриваемых приложениях в основе своей сводится к задаче контроля запуска и локализации действий процессов на защищаемом компьютере.
На практике трудно себе представить ситуацию, когда может понадобиться реализация разграничительной политики доступа к ресурсам либо только для субъекта «пользователь», либо только для субъекта «процесс». Поэтому актуальна задача комплексирования.
Заметим, что техническое решение, реализующее данный подход, нами запатентовано (А.Ю.Щеглов. Система разграничения доступа к ресурсам, патент №2207619, приоритет от 12.07.2001).
Вернемся к вопросам идентификации и аутентификации, но уже применительно к субъекту доступа «процесс». Идентификатором его является полнопутевое имя. Таким образом, для корректной идентификации субъекта «процесс» необходимо предотвратить возможность запуска процессов под иными именами и предотвратить возможность модификации исполняемых файлов, полнопутевые имена которых разрешены для выполнения.
Напрашивается очевидное решение – контролировать разрешенные к запуску исполняемые файлы на целостность (естественно, асинхронно, перед запуском). Однако данное решение обладает слишком серьезными недостатками, чтобы рекомендовано его для использования в общем случае. Причем основной недостаток здесь связан не с очевидной сложностью администрирования данного механизма, а с влиянием механизма на вычислительный ресурс защищаемого компьютера (это ведь исполняемые файлы не только приложений, но и всех системных процессов). Поэтому будем рассматривать данную возможность в качестве опциональной, рекомендуемой для использования в случаях, когда невозможно предотвратить модификацию разрешенного к запуску исполняемого файла иными средствами, например, когда приложение должно запускаться с внешнего накопителя, хранящегося у пользователя.
Для решения рассматриваемой задачи в общем случае целесообразно использовать механизм обеспечения замкнутости программной среды.
В общем случае создание замкнутой программной среды достигается за счет исполнения механизмом контроля доступа регламента запуска и обеспечения целостности ПО. При этом механизм считается реализованным корректно лишь при условии, если выполняются требования к полноте и корректности разграничений прав на запуск исполняемых файлов. Под полнотой разграничений понимается возможность регламентировать доступ для операции «выполнить» для всех ресурсов, из которых возможен запуск ПО, а под корректностью – способность противодействия любой модификации разрешенных к исполнению объектов, а также запуску под их именем других (несанкционированных) программ.
В предлагаемой нами реализации для локализации программной среды необходимо регламентировать права доступа к папкам (каталогам, подкаталогам), из которых пользователям разрешено (запрещено) запускать исполняемые файлы. С учетом принятых правил размещения приложений и необходимости запуска системных процессов, целесообразно разрешать выполнение программ только из каталогов \Program Files, куда следует устанавливать приложения, и \Winnt (WINDOWS). А чтобы предотвратить возможность модификации санкционированных исполняемых файлов, запись пользователям в эти каталоги, напротив, следует запретить.
Вопросы корректности идентификации объекта доступа
Здесь, на первый взгляд, проблем вообще не существует. Однако если внимательно рассмотреть архитектурные принципы реализации и возможности современных универсальных ОС, точка зрения на этот вопрос радикально меняется. В качетсве примера рассмотрим предоставляемые современными ОС Windows возможности идентификации файлового объекта при запросе доступа.
В NTFS файловый объект может быть идентифицирован различными способами:
• файловые объекты, задаваемые длинными именами, характеризуются той отличительной особенностью, что к ним можно обращаться как по длинному, так и по короткому имени, например к каталогу «\Program files\» можно обратиться по короткому имени «\Progra
1\»;
• файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться), например короткое имя для каталога «C:\Documents and Settings\USER1\Главное меню» выглядит как «C:\Docume
1\». К этим объектам также можно обратиться как по длинному, так и по короткому имени;
• файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.
Пусть установленная в вашей информационной системе СЗИ от НСД не перехватывает и не анализирует лишь один подобный способ обращения к файловому объекту, и, по большому счету, она становится полностью бесполезной (рано или поздно, злоумышленник выявит данный недостаток средства защиты и воспользуется им).
Вывод. Из сказанного выше получаем следующее требование к идентификации объекта доступа – объект доступа должен однозначно идентифицироваться при любом допустимом способе обращения к нему (при любом способе его идентификации приложением) на доступ.
Мы в исследовании не затронули вопросы ссылок, возможность обращения к файловым объектам по их ID, что на практике реализуется рядом приложений, и т.д.
Таким образом, проведя данное исследование, видим, насколько сложна задача идентификации и аутентификации как в своей постановке в общем виде, так и в решении, если, конечно, говорить о построении эффективного средства защиты информации, сколько механизмов защиты должно быть реализовано в составе СЗИ от НСД для решения данной задачи в общем виде. А если хотя бы одного из рассмотренных механизмов в средстве защиты нет – уже уязвимость! Кстати говоря, о термине «эффективность» в данных приложениях. Заметим, что СЗИ от НСД не может обладать высокой или низкой эффективностью (это не параметр производительности). СЗИ от НСД либо защищает, либо нет. Если существует хотя бы один канал обхода средства защиты, рано или поздно им воспользуется злоумышленник, как следствие, в этом случае правомерно утверждать, что данная СЗИ от НСД не обладает потребительской стоимостью (или просто бессмысленна для практического использования). Здесь невольно возникает вопрос (это уже в части формализации требований к СЗИ от НСД – сегодня очень актуальный вопрос), а как подразделять СЗИ от НСД на какие-либо классы или группы? СЗИ от НСД высокого класса обеспечивает защиту, а низкого нет (иного не дано)? Напрашивается вывод о том, что подобное разделение СЗИ от НСД на какие-либо группы или классы по функциональным возможностям и по набору механизмов защиты недопустимо! Тогда на основании чего могут быть введены классификационные признаки СЗИ от НСД?