Вы находитесь в разделе Типовых решений систем безопасности
Часть 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. В качестве параметров задается, какой процесс, с правами какого пользователя должен быть запущен, и пароль этого пользователя. Утилита запускается с правами текущего пользователя, утилита взаимодействует с системной службой 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. Используя данный интерфейс, следует задать настройки, описанные выше. Рассмотрим, какие возможности обеспечивает реализация описанного технического решения. Прежде всего, здесь следует говорить о том, что это совершенно самостоятельный механизм идентификации и аутентификации. Поэтому, кроме возможности подключения различных аппаратных аутентификаторов, при реализации данного подхода могут быть выполнены все необходимые требования к корректности реализации механизма, как в части регистрации событий, так и в части предоставления возможности входа в систему в безопасном режиме только администратору. Поскольку данный механизм является в полном объеме добавочным, решаются задачи резервирования механизмов защиты. Кроме того, при использовании данного механизма, оказывается эффективное противодействие атакам, направленным на несанкционированное создание учетной записи нового пользователя. Дело в том, что доступ в систему может получить только пользователь, учетная запись которого создана, как в системе, так и в СЗИ НСД. В качестве замечания отметим, что в работе нами не рассматривались дополнительные задачи идентификации и аутентификации, решаемые при ослабленных механизмах контроля доступа к ресурсам (например, разрешение доступа к закодированным данным с использованием ключевой информации, что порой используется в системах криптографической защиты – данное решение нами рассматривалось в предыдущей части работы) – здесь мы рассмотрели только основные (можно сказать, ключевые) проблемы идентификации и аутентификации пользователей и пути их решения. Итак, в этой и в предыдущих частях работы нами были рассмотрены, пожалуй, все ключевые задачи обеспечения компьютерной безопасности, и предлагаемые нами подходы к их решению – к построению соответствующих механизмов защиты. Естественно, что когда эффективная защита информация может быть обеспечена лишь некоторой совокупностью механизмов (об этом мы говорили ранее), как следствие, появляется задача комплексирования механизмов в системе защите (не случайно, свои СЗИ НСД мы называем Комплексными системами защиты), состоящая в определении на основании каких-либо соображений оптимального набора механизмов защиты в системе. Исследованию данных вопросов мы посвятим следующую часть нашей работы. Читайте далее:  Ведение в теорию надежности защиты информации. задачи резервирования механизмов защиты Распространение видеонаблюдения в сферах, не связанных с безопасностью Особенности использования поворотных видеокамер В школьном округе харт планируется установка систем видеонаблюдения Видеонаблюдение как искусство Проектирование видеосистем с учетом требований к безопасности объектов Гост р 51558-2008. каким ему быть ? Сравнение технических решений для цифровых систем охранного телевидения Подрядчикам по электротехнике предлагают заняться системами видеонаблюдения Как измерять разрешающую способность ,попытка осмысления, Британские системы видеонаблюдения - не только для закоренелых преступников 3.2. объективы телевизионных камер Новый видеосервер axis 250s преобразует аналоговый видеосигнал Новая телевизионная камера на поворотном устройстве cyberscout Помещение охраны
|
