Требования к идентификации и аутентификации. Требования к аутентификации

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

Дата добавления: 2013-12-23 ; просмотров: 3040 ; Нарушение авторских прав

ПРИНЦИПЫ ЗАЩИТЫ ИНФОРМАЦИИ ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА. ИДЕНТИФИКАЦИЯ. АУТЕНТИФИКАЦИЯ. АВТОРИЗАЦИЯ

Анонимное распределение ключей

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

1. А выбирает пару: открытый ключ — секретный ключ (для этого протокола он держит оба ключа в секрете).

2. ЦРК генерирует непрерывный поток ключей.

3. ЦРК шифрует ключи, один за одним, своим открытым ключом.

4. ЦРК передает зашифрованные ключи, один за одним, в сеть.

5. А выбирает ключ случайным образом.

6. А шифрует выбранный ключ своим открытым ключом.

7. А ожидает некоторое время и посылает дважды зашифрованный ключ обратно в ЦРК.

8. ЦРК расшифровывает дважды зашифрованный ключ своим секретным ключом, оставляя ключ зашифрованным один раз открытым ключом А.

9. ЦРК посылает зашифрованный ключ назад пользователю А.

10. А расшифровывает ключ своим секретным ключом.

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

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

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

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

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

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

Формализованные требования к данным механизмам защиты состоят в следующем:

• Должны осуществляться идентификация и проверка подлинности субъектов доступа при входе в систему по идентификатору (коду) и паролю условно-постоянного действия длиной не менее шести буквенно-цифровых символов (для классов защищенности 1Г и 1В по классификации АС)

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

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

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

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

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

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

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

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

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

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

Начиная с четвертого класса защищенности, в дополнение выдвигается требование:

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

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

Задачи механизмов идентификации и аутентификации в обеспечении компьютерной безопасности

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

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

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

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

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

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

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

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

В качестве замечания отметим, что, во-первых, рассматриваемые далее в статье решения апробированы при создании семейства СЗИ НСД – КСЗИ Панцирь (для ОС семейства Windows, в частности КСЗИ “Панцирь” для ОС Windows 2000/XP/200 — разработка НПП Информационные технологии в бизнесе, во-вторых, они либо уже запатентованы, либо находятся в стадии патентования, поэтому без нарушения авторских прав, рассмотренные в работе технологии не могут быть реализованы в разработках иных производителей.

Механизм контроля олицетворения

Основу данного подхода к решению проблемы составляет следующее утверждение:

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

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

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

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

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

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

Важным условием корректности реализации любого механизма, реализующего разграничительную политику доступа к ресурсам, в том числе, и рассматриваемого в работе, является реализация системой защиты разрешительной разграничительной политики (Все, что не разрешено (явно не прописано), то запрещено — об этом мы подробно говорили в одной из предыдущей частей нашей работы), при которой задаются (явно прописываются) разрешенные виды олицетворения. Предусмотрена также и запретительная политика контроля олицетворения. Для упрощения настроек механизма, процессы, как субъекты доступа, могут задаваться не только своими полнопутевыми именами, но и именами папок (тогда заданные разграничения действуют на все процессы, запускаемые из папки, для которой установлены разграничения), либо масками. Интерфейс настройки механизма, реализованный в КСЗИ “Панцирь” для ОС Windows 2000/XP/2003, приведен на рис. 11.2.

Замечание. В процессе работы системы сервисом олицетворения пользуются не только прикладные, но и системные процессы. Рассматриваемый механизм может эффективно быть использован и с целью контроля олицетворения потоков, запускаемых системными процессами, при этом данный механизм позволяет реализовать и принципиально новые свойства защиты. Например, при авторизации пользователя при входе в систему, потоки, запускаемые процессом winlogon, олицетворяются с учетной записью авторизуемого пользователя. При использовании данного механизма (пример настроек приведен на рис. 11. можно управлять тем, какие пользователи могут входить в систему. Для настроек, представленных на рис. 11.2, это только пользователи Administrator и User Наличие иных учетных записей заведенных в системе, не даст возможности войти под ними в систему. Это очень важное свойство защиты, т.к. очень часто, результатом успешной атаки (целью проведения атаки) является несанкционированное заведение новой учетной записи в группе Администраторы, с последующим входом в систему под этой учетной записью (с привилегиями администратора).

Механизмы контроля запуска процессов

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

Запрет запуска критичных утилит. Этот подход реализуется механизмом обеспечения замкнутости программной среды (описан в шестой части нашей работы). Суть применения его здесь состоит в обеспечении невозможности запуска пользователями утилит, позволяющих запускать процессы с правами другого пользователя, в частности, утилиту runas.exe. Заметим, что применительно к конкретному способу запуска процесса с правами другого пользователя при этом задача защиты решается в общем виде (что еще контролировать, если невозможно осуществить сам факт запуска), однако это решение носит частный характер в том смысле, что необходимо обладать информацией обо всех возможностях (утилитах), предоставляющих подобный сервис. Кроме того, возможна конфликтная ситуация, предполагающая необходимость разрешения запуска утилиты, ввиду предоставления ею, кроме рассматриваемого, иных сервисов.
Сведение режима функционирования ОС к однопользовательскому. Суть предлагаемого подхода состоит в предоставлении СЗМ НСД возможности регистрации только одного пользователя в системе в сеансе взаимодействия с компьютером. При этом под сеансом будем понимать временной интервал, начиная с момента регистрации пользователя в системе, до момента ее перезагрузки. Сведение режима к однопользовательскому может быть реализован следующим образом. Будем контролировать с заданным периодом число зарегистрированных пользователей в системе – запрещенным событием будет регистрация более одного пользователя. Реакцией на подобное событие может быть завершение сеанса пользователя, зарегистрированного вторым и др. Что мы получаем – по сути, сведение режима функционирования к однопользовательскому (при этом ОС остается многозадачной, но все задачи могут запускаться только под учетной записью одного зарегистрированного пользователя), причем другой пользователь сможет зарегистрироваться только после перезагрузки компьютера. Заметим, что при использовании такого подхода задача предотвращения запуска процесса с правами другого пользователя решается в общем виде – вне зависимости от наличия утилит, предоставляющих подобный сервис (контролируется и предотвращается сама возможность регистрации в системе более одного пользователя). Заметим, что возможность решения рассматриваемой задачи предлагаемым здесь способом следует из приведенной ниже упрощенной схемы работы системы по запуску процесса с правами другого пользователя — и в этом случае процессом winlogon осуществляется регистрация пользователя. Данный подход характеризуется набольшей общностью решения задачи и может использоваться в 95-99% приложений ОС семейства Windows. Пожалуй, одно из немногих приложений, где данный подход неприменим – это защита терминальных серверов, по своей сути реализующих многопользовательскую обработку.
Контроль смены первичного маркера доступа. Чтобы перейти к рассмотрению предлагаемого здесь подхода, прежде всего, рассмотрим упрощенную схему запуска процесса с правами другого пользователя, реализуемую ОС Windows совместно с утилитами, предоставляющими подобный сервис, приведена на рис.11. Рассмотрим, как работает данная схема.

Для того, чтобы запустить процесс (программу) с правами другого пользователя, пользователь по своей учетной записью запускает программу-проводник, позволяющую запускать соответствующую утилиту, например, runas. В качестве параметров задается, какой процесс, с правами какого пользователя должен быть запущен, и пароль этого пользователя. Утилита запускается с правами текущего пользователя, утилита взаимодействует с системной службой svchost, запущенной с правами System., которая взаимодействует с процессом winlogon, осуществляющим регистрацию входа нового пользователя в систему. При регистрации нового пользователя, потоки, запускаемые процессом winlogon олицетворяют себя с правами регистрируемого пользователя (как отмечали ранее, если запретить подобное олицетворение, см. рис.11.2, регистрация нового пользователя в системе будет невозможна). Далее системная служба svchost запускает процесс, запуск которого запросил пользователь, с правами System, после чего, осуществляет смену первичного маркера доступа для запущенного процесса – смену маркера доступа System на маркер доступа нового пользователя – процесс функционирует под учетной записью нового пользователя.

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

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

Теперь вернемся к рассмотрению описываемого здесь подхода. Из рис. 11.3 видим, что смена первичного маркера доступа осуществляется уже после запуска процесса, который изначально запускается с правами System.Видим, что если идентифицировать субъект доступа парой: идентификатор и эффективный идентификатор, то рассматриваемый процесс будет характеризоваться парой: System, Новый пользователь. Но ведь именно эта пара параметров и контролируется нами при решении задачи контроля олицетворения (см. выше). Из сказанного можем сделать вывод, что решение задач контроля олицетворения и контроля смены первичного маркера доступа базируется на одних и тех же принципах – контроль идентификатора субъекта доступа – пары: идентификатор и эффективный идентификатор пользователя. Следовательно, что и подтверждено экспериментально, в обоих этих случаях может использоваться один и тот же механизм защиты, описанный выше (интерфейс представлен на рис.11. . Аналогично тому, как это описывалось ранее, для любого прикладного процесса (в пределе для всех) здесь можно запретить смену первичного маркера доступа System на маркер любого другого пользователя (эффективное имя пользователя в интерфейсе на рис.11.2 при этом должно задаваться маской *). В этом случае запустить соответствующий прикладной процесс (в пределе, любой прикладной процесс) с правами другого пользователя, даже зная его учетные данные – имя и пароль, становится невозможным.

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

Механизмы контроля входа в систему

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

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

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

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

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

дата и время входа (выхода) субъекта доступа в систему (из системы) или загрузки (останова) системы;
результат попытки входа: успешная или неуспешная (при НСД);
идентификатор (код или фамилия) субъекта, предъявленный при попытке доступа;
код или пароль, предъявленный при неуспешной попытке.

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

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

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

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

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

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

Теперь рассмотрим предлагаемый нами подход к реализации механизма идентификации и аутентификации пользователя при входе в систему, реализованный и апробированный в семействе КСЗИ Панцирь для ОС Windows.

Схема, иллюстрирующая предлагаемый нами подход, представлена на рис. 11.5.

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

Работает механизм защиты следующим образом. При каждом запуске штатной (встроенный в ОС механизм) идентификации и аутентификации пользователя при входе в систему, запускается добавочная идентификация и аутентификация, т.е. активизация добавочного механизма инициируется запуском штатной процедуры. Следовательно, добавочный механизм стартует и при штатном, и при безопасном режимах входа в систему. Заметим, что добавочная процедура авторизации запускается перед штатной, поэтому на мониторе появляется окно авторизации пользователя, реализуемой добавочным механизмом защиты. Настройки добавочного механизма содержат учетные параметры пользователей (имя и пароль), заведенных в СЗИ НСД и соответствующие этим пользователям пароли ОС, заведенные в системе (соответственно одному имени пользователя в СЗИ НСД задаются пароль для авторизации в СЗИ НСД и пароль для авторизации в ОС). При прохождении авторизации в СЗИ НСД, добавочный механизм защиты автоматически (уже без участия пользователя) сам вводит в систему значение системного пароля пользователя, авторизовавшегося в СЗИ НСД. При успешной авторизации системное окно ввода пароля не выводится – пользователь осуществляет вход в систему. Проиллюстрируем сказанное схемой, представленной на рис. Настройка механизма состоит в следующем. Со входа 8 задаются учетные данные (имя и пароль) для авторизации пользователя механизмом добавочной защиты (если используется режим аппаратной аутентификации, значение заведенного пароля записывается на соответствующий внешний носитель). Со входа 9 задаются учетные данные пользователя для авторизации встроенным в ОС механизмом защиты, заведенный пользователю пароль заносится и в блок 4, и в блок При запросе доступа в систему (со входа блок 2 запускает интерфейс для авторизации пользователя в СЗИ НСД — со входа 6 (например, с внешнего носителя). При успешной авторизации пользователя в СЗИ НСД, блоком 2 выдается в блок 4 запрос пользователя на доступ в систему и системный пароль, причем системный пароль подставляется блоком 2 в блок 4 без запуска интерфейса 3 (автоматически) — на выход 10 выдается сигнал об успешном прохождении пользователем процедуры авторизации. В противном случае, возможны два решения (соответственно, одноуровневая, либо двухуровневая авторизация). В режиме одноуровневой авторизации, вход в систему пользователя становится невозможен. В режиме двухуровневой авторизации блоком 4 запускается блок 3, и пользователю предлагается пройти авторизацию со входа 5 в стандартном окне системной авторизации – в блоке При успешной авторизации вырабатывается сигнал на выходе 10.

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

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

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

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

На рис.11.6 представлен интерфейс настройки добавочного механизма идентификации и аутентификации, реализованный в нашей разработке КСЗИ Панцирь для ОС Windows. Используя данный интерфейс, следует задать настройки, описанные выше.

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

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

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

Идентификация и аутентификация. Так ли все просто?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1\». К этим объектам также можно обратиться как по длинному, так и по короткому имени;
• файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.

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

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

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

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

Смотрите так же: Как оформить синквейн красиво. Как оформить синквейн красиво

Leansummit.ru