Вы находитесь в разделе Типовых решений систем безопасности
Вопросы корректности реализации механизмов защиты от нсд добавочными средствамиВ данной статье рассмотрим вопросы корректности реализации средств добавочной защиты от несанкционированного доступа (СЗИ НСД). Актуальность подобного исследования, на наш взгляд, обусловливается следующими двумя причинами. Во-первых, СЗИ НСД, призванные наделять систему новыми свойствами защиты (об этом шла речь в первых двух частях работы, и этим, на наш взгляд, прежде всего, и определяются потребительские свойства СЗИ НСД ), при некорректной их реализации, могут вносить собственные уязвимости, причем последствия от внесения подобных уязвимостей могут быть куда более значимы, чем положительный эффект, связанный с реализацией новых свойств защиты (напомним, что, как отмечалось в первой части работы, СЗИ НСД в ряде приложений предполагают использование добавочной защиты вместо встроенной). Поэтому потребитель, приобретая добавочную СЗИ НСД, должен обладать информацией, достаточной, чтобы быть уверенным в корректности ее реализации. Во-вторых, несмотря на то, что требования к корректности реализации СЗИ НСД определены в соответствующих нормативных документах, вполне естественно то, что в подобных документах не может быть представлена подробная детализация требований, учитывающая специфику реализации конкретного программного средства, в частности ОС (в противном случае, под каждую ОС, а в общем случае, и под каждую версию ОС одного семейства, должен был бы быть свой документ, регламентирующий требования к механизмам защиты). Тогда возникает вопрос достаточности, а также проблема трактовки требований разработчиками и потребителями СЗИ НСД в каждом конкретном случае – с учетом особенностей архитектурной реализации системного средства, как следствие, вопрос о необходимости дополнительных уточняющих требований к корректности реализации СЗИ НСД для конкретных ОС и их версий.Заметим, что для исследуемого нами вопроса, не так важно, на каких принципах построена формализация требований к механизмам защиты (в этом случае определяются функциональные возможности механизмов, а не вопросы корректности их реализации). Важно то, что если в соответствии с теми или иными требованиями механизм защиты должен присутствовать в системе, то он должен быть реализован корректно, а вопросы корректности реализации, как увидим далее, в большой мере определяются уже тем, для использования с каким системным ПО механизм разработан. Исследование будем проводить посредством рассмотрения формализованных требований к механизмам защиты, применительно к ОС семейства Windows (естественно, будем говорить о технологии NT). Целью же данного исследования будет анализ того, в какой мере требуется уточнение требований, применительно к конкретному системному программному средству, соответственно, анализ того, в какой мере отсутствие подобных уточняющих требований может повлиять на вопросы корректности реализации механизма защиты. Проводя исследование, мы также попытаемся сформулировать уточняющие требования, учитывающие особенности архитектуры конкретного системного ПО. Однако, сразу оговоримся, что приводимое в работе исследование, сделанные по работе выводы и предложения являются лишь частным мнением автора (приведенным с целью обсуждения данной проблемы), которое сформировалось в результате практической работы по созданию СЗИ НСД семейства “Панцирь” (разработка ЗАО “НПП “Информационные технологии в бизнесе”). Прежде всего, ответим на вопрос: для кого предназначено данное исследование? Наверное, трудно предположить ситуацию, когда разработчики средств защиты, берясь за задачу создания добавочной СЗИ НСД под конкретную ОС, не обладают должными знаниями по основам ее архитектурной реализации и функционирования (сегодня найти источник подобной информации практически по любой ОС не составляет труда), из которых и вытекают требования к корректности реализации механизмов защиты добавочными средствами. Возможно результаты исследования, проводимого авторами в работе, покажутся им очевидными (по крайней мере, так должно быть). Однако, не будем забывать, что существуют еще и потребители средств защиты, которые в своей массе могут не столь хорошо владеть основами компьютерной безопасности, а ведь именно им необходимо быть уверенными в корректности реализации приобретенной и устанавливаемой на защищаемый объект СЗИ НСД, именно им придется использовать возможности СЗИ НСД. Поэтому, на наш взгляд, в первую очередь, именно потребителям СЗИ НСД необходима в достаточном объеме детализация требований к корректности реализации механизмов защиты добавочными СЗИ НСД, о чем мы и будем говорить далее. Так как в одной статье невозможно говорить сразу обо всех механизмах защиты СЗИ НСД, выберем для рассмотрения, на наш взгляд, наиболее важный из них (по нашему мнению, ключевой) – механизм управления доступом к ресурсам. Поскольку номенклатура защищаемых ресурсов достаточно велика (файловые объекты, объекты реестра ОС, устройства, сетевые ресурсы и т.д.), ограничимся рассмотрением только задач управления доступом к файловым объектам (естественно, далее будем говорить о файловой системе NTFS). С учетом возможности реализации альтернативных моделей контроля доступа к файловым объектам (наиболее распространены схемы избирательного и полномочного контроля доступа) рассмотрим только избирательное управление (еще его называют дискреционным доступом, однако этот термин требует некоторого уточнения, что мы далее и сделаем), с учетом того, что требования к реализации данного механизма в СЗИ НСД регламентируются для средства вычислительной техники (СВТ), начиная уже с шестого класса защищенности (т.е. должны выполняться по существу любой СЗИ НСД). Таким образом, в данной работе, на конкретном примере исследования только одного механизма защиты, предлагается рассмотреть, на наш взгляд, одну из ключевых проблем создания средств добавочной защиты. При этом отметим, что объектом наших исследований являются ни в коей мере не конкретные реализации СЗИ НСД, а лишь собственно требования к механизмам защиты и известные (опубликованные) архитектурные особенности рассматриваемой ОС, представляющие для нас интерес, в части проводимого нами анализа формализованных требований, применительно к конкретному системному ПО. Приведем формализованные базовые требования (к СВТ шестого класса защищенности) к рассматриваемому в работе механизму защиты, в соответствии с действующим сегодня нормативным документом , которые в установлены для дискреционного принципа контроля доступа:
Это, как раз и есть те общие формализованные требования (видим, что в них нет никаких ссылок на тип и версию системного ПО), которые мы будем далее рассматривать, в части исследования вопросов целесообразности их уточнения с учетом архитектурных особенностей системного ПО, в нашем случае – ОС Windows (технологии NT, файловая система NTFS). Приступим к анализу этих требований. Естественно, что требование: «КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа» собственно и определяет дискреционный принцип контроля доступа (задает, что должна быть реализована схема избирательного, а не полномочного управления доступом). Требование: «КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.)» важно в той части, что если субъект всегда наименован (любое обращение к файловому объекту характеризуется SID, в частности, именем пользователя, от лица которого осуществляется обращение к ресурсу), то информация может, храниться как в файловом объекте, который всегда может быть идентифицирован (иначе к нему не осуществить доступ штатными средствами), так и не обладать идентифицирующими признаками – это, так называемая, остаточная информация (информация, остающаяся на носителе после удаления или модификации файлового объекта штатными средствами). Доступ к остаточной информации можно получить средствами, так называемого, прямого доступа к памяти. Данное требование задает, что подобная задача защиты от НСД уже не является функцией дискреционного принципа контроля доступа (в соответствующих нормативных документах, начиная с СВТ пятого класса, данная задача защиты возлагается на отдельный механизм защиты - очистка памяти: «При первоначальном назначении или при перераспределении внешней памяти КСЗ должен предотвращать доступ субъекту к остаточной информации»). Рассматривая требования, прежде всего, остановимся на кажущемся противоречии двух из них: «КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа» и «Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)». Поясним суть возможной противоречивой трактовки данных требований. В общем случае принято считать, что дискреционная модель управления доступом основывается на предоставлении доступа к объектам владельцами этих объектов. Это основная модель управления доступом к ресурсам, реализуемая современными ОС, в том числе, ОС Windows. С целью реализации данной модели в схему управления доступом к ресурсам для ОС включена такая сущность, как «Владелец» объекта (например, это пользователь, создавший файловый объект). «Владелец» файлового объекта наделяется привилегией задавать разграничения прав доступа к объекту, которым он «владеет», чем, по существу, и реализуется дискреционная модель, в данном случае, предполагающая включение пользователя в схему назначения (изменения) ПРД. Однако данная схема администрирования противоречит другому требованию, которым однозначно задается, что право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)», т.е. никак не обычным пользователям, в том числе и создающим файловые объекты. Противоречия в этих требованиях нет, если дать правильное определение сущности «Владелец». С этой целью надо соотнести такие категории, как «Владелец» и «Собственник» информации. Применительно к исследуемому вопросу, будем говорить, что собственник – это лицо (не обязательно физическое), которому принадлежит информация, владелец – лицо, получающее информацию от собственника во временное владение, с целью ее обработки вычислительным средством. Очевидно, что если говорить об использовании компьютера в домашних целях, то пользователь, работающий на персональном компьютере, как правило, одновременно является и собственником, и владельцем информации, как следствие, он должен иметь право назначать (изменять) ПРД к обрабатываемой им информации. Заметим, что именно такая схема исторически сложилась и широко используется встроенными механизмами защиты ОС. Однако такая схема не годится для реализации разграничительной политики доступа к информации, обрабатываемой на предприятии, что и формализуется в требовании: «Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)». Рассмотрим, чем это обусловлено. Здесь, как правило, «Собственник» и «Владелец» (в данном случае пользователь, получающий информацию во временное владение, для ее обработки) различные лица. Пользователь в рамках своих служебных обязанностей с использованием вычислительного средства осуществляет обработку информации, предоставленной собственником, как следствие, может осуществлять действия с этой информацией только в рамках правил, установленных собственником. Доверенным же лицом собственника, как раз, и выступает выделенный субъект (администрация, служба безопасности и т.д., на практике, как правило, это администратор безопасности), в задачи которого входит назначать (изменять) ПРД в соответствии с политикой безопасности, формируемой собственником информации. Таким образом, можем сделать вывод, что противоречия в рассматриваемых требованиях, регламентирующих, в первую очередь, правила создания СЗИ НСД для защиты конфиденциальной информации, обрабатываемой на предприятии, нет. Нужно лишь корректно определить, кто есть собственник, а кто владелец информации, применительно к защищаемому объекту. В двух словах остановимся на том, к чему может привести невыполнение данных требований. Здесь можем выделить два аспекта. Во-первых, если пользователь, как временный владелец, получает неограниченные права по обработке информации собственника, то, как следствие, он, прежде всего, и несет в себе наибольшую угрозу хищения данной информации (во многом это объясняет тот факт, что на сегодняшний день большинство хищений информации осуществляется непосредственно пользователями, что, на наш взгляд, напрямую связано с реализуемой во многих современных ОС схемой управления доступом к ресурсам). Во-вторых, в данном случае становится «размытой» роль лица (например, администратора безопасности), отвечающего за защиту информации собственника. Дело в том, что, не назначая ПРД, соответственно и не реализуя их соответствующими механизмами защиты, администратор не может и отвечать за защиту, как следствие, за хищение информации собственника. Итак, разобравшись в этом вопросе, рассмотрим, как же необходимость выполнения требования: «Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)» сказывается на реализации дискреционного механизма управления доступом к файловым объектам для ОС Windows – какие уточняющие требования к его реализации могут быть сформулированы.
 Продолжим свои исследования, для чего вновь вернемся к рассмотрению требования: «Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту)», а также тесно связанного с ним требования: «Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов)». С этими требованиями связаны основные условия корректности реализации механизма, причем, как в общем случае, так и применительно к конкретной ОС. Прежде всего, из требования: «КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.)» уточним, что под субъектом доступа здесь понимается пользователь (об этом мы еще поговорим ниже, учитывая, что собственно доступ к объекту осуществляется потоком, порождаемым процессом). Прежде всего, можем видеть, что из рассмотренных требований логично вытекает требование к индуктивности модели безопасности (напомним, что модель безопасности принято называть индуктивной, если для системы, однажды установленной в безопасное состояние, гарантируется нахождение системы в безопасном состоянии в последующие моменты времени). В нашем случае индуктивность модели безопасности рассматриваемого механизма достигается, при выполнении двух условий, которые также могут быть отнесены к уточняющим требованиям:
Продолжая данную тему, остановимся, на наш взгляд, на крайне важном моменте – рассмотрим требования к дискреционному принципу контроля доступа в случае его совместного использования с мандатным принципом контроля доступа (начиная с СВТ четвертого класса защищенности СВТ, в соответствии с ). Заметим, что следуя , базовые требования к дискреционному контролю доступа здесь те же, что рассматривались нами выше (они несколько дополнены, но об этом поговорим далее). Однако, здесь возникают следующие вопросы – обоими этими принципами в их трактовке, представленной в , задаются требования к реализации индуктивной модели безопасности – насколько это оправдано и к чему приводит? Рассмотрим, в чем состоят особенности реализации дискреционного принципа контроля доступа в данных приложениях. Во-первых, модель полномочного управления доступом (на основе меток безопасности, или, как называют, мандатное управление), априори являющаяся индуктивной, является частным случаем индуктивной модели дискреционного управления, что не сложно строго доказать (подобным дискреционным механизмом можно реализовать все возможности, с учетом основного назначения полномочного управления – не допустить снижения мандатного механизма, т.к. в обоих случаях реализуется принудительное управление ), и его преимущество перед дискреционным в этом случае состоит лишь в упрощении задачи администрирования, за счет использования меток. Во-вторых, одновременное использование мандатного механизма (который разграничивает доступ не между субъектами и объектами, а между категориями субъектов и объектов) и дискреционного уже предполагает реализацию дискреционным механизмом запретительной разграничительной политики доступа: «Все, что не запрещено (явно не указано), то разрешено» (в противном случае при настройке дискреционного механизма потребуется повторить все разграничения, заданные для мандатного механизма, и еще внести дополнительные разграничения для субъектов и объектов внутри категорий, т.е. не о каком упрощении администрирования в этом случае уже речь не идет, а применение мандатного механизма при этом становится просто бессмысленным – только усложняет задачу администрирования). Заметим, что для СВТ, использующих полномочное управление доступа, именно мандатный механизм призван обеспечивать индуктивность модели безопасности, являясь здесь первичным, дискреционный же механизм реализуется в дополнение к мандатному, с целью разграничения доступа внутри категории. Сказанное выше также можно рассматривать, как весьма важное уточняющее требование. Пример интерфейса настроек дискреционного механизма, реализованного в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003 в дополнение к мандатному, приведен на рис.3.2  Итак, выше мы рассматривали общие требования, без учета специфики защищаемого системного ПО. Данная специфика, в первую очередь, проявляется, когда речь заходит о следующем (в соответствии с представленными требованиями): «Для каждой пары (субъект - объект) должно быть задано явное и недвусмысленное перечисление допустимых типов доступа …» и «…должен быть применим к каждому объекту и каждому субъекту…». Теперь, применительно к понятиям «Объект» и «Субъект» рассмотрим архитектурные особенности ОС Windows (в том числе, файловой системы NTFS), накладывающие свои уточняющие требования к корректности реализации в СЗИ НСД дискреционного принципа контроля доступа для ОС данного семейства. 1. Объект доступа. В качестве ключевой проблемы корректной реализации рассматриваемых требований отметим проблему возможной неоднозначности идентификации файлового объекта. Это обусловливается тем, что в NTFS файловый объект может быть идентифицирован различными способами. Рассмотрим эти способы:
Другая проблема обусловливается тем, что как собственно ОС, так и некоторые сторонние приложения не позволяют разграничить права доступа для различных пользователей к некоторым файловым объектам (если подобные ПРД назначить, то это приведет к некорректности работы системы или соответствующего приложения). В качестве примера подобного файлового объекта, доступ к которому требует дополнительных разграничений, можно отнести папку: “All Users” на системном диске. Естественно, что выполнение рассмотренного требования является обязательным при категорировании информации, в противном случае, становится невозможным противодействовать понижению категории информации. С учетом сказанного, можем сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД должна иметь возможность собственными средствами разделять любую папку, неразделяемую системой и приложениями, между пользователями. Последнее, на что здесь обратим внимание – это то, что файловые объекты имеют различное функциональное назначение. В частности, к этим объектам следует отнести и любой объект на системном диске, содержащий системные файлы (естественно, если невозможно предотвратить возможность модификации пользователями системного диска, говорить о какой-либо защите не приходится). С учетом сказанного, можем сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД должна иметь возможность в полном объеме разграничивать права доступа пользователей к любому файловому объекту, вне зависимости от его функционального назначения. Субъект доступа. В качестве ключевой проблемы корректной реализации рассматриваемых требований отметим проблему возможной неоднозначности идентификации субъекта доступа. Это обусловливается тем, что непосредственно к объекту обращается поток, порождаемый процессом, который запускается пользователем. ОС реализована таким образом, что любой запускаемый пользователем процесс наследует маркер безопасности (в общем случае – SID пользователя), то же происходит и с потоком, при его порождении процессом. Однако в общем случае поток, осуществляющий доступ к ресурсу, может обладать маркером безопасности, отличным от маркера пользователя, соответственно, при его доступе к ресурсу уже будут действовать ПРД другого пользователя. Рассмотрим эти возможности:
С учетом сказанного, можем сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД, в рамках реализуемого ею контроля доступа к ресурсам, должна осуществляться контроль корректности идентификации субъекта доступа (соответственно, контроль соответствия маркера доступа (access token) пользователя и потока, обращающегося к ресурсу. Другое, на что здесь следует обратить внимание – это то, что субъекты доступа (пользователи) могут принципиально различаться по своей сути. В частности, к субъектам доступа относятся и системные пользователи (так называемые, виртуальные, которые либо всегда присутствуют в системе, например, пользователь System, либо создаются при подключении некоторого ПО, например, СУБД), так как эти пользователи также обращаются к ресурсам, следовательно и к ним могут быть применимы ПРД. В качестве замечания отметим, что с ограничениями на возможность задать ПРД для пользователя System, связана большая доля атак на расширение привилегий (в частности это атаки на переполнение буфера приложений). Целью подобных атак является использование ошибки в приложении, запущенном, как правило, с системными правами, с целью получить управление данным приложением, т.е. получить права пользователя System в системе. Если для пользователя System в полном объеме назначать (изменять) ПРД, то подобные атаки станут не актуальными, как таковые (не зачем будет получать права системного пользователя, если это не добавит привилегий доступа к ресурсам). С учетом сказанного, можем сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД должна иметь возможность в полном объеме разграничивать права доступа любого пользователя (в том числе и системных) к любому файловому объекту. Прежде чем, попытаться подытожить и обобщить все сказанное, остановимся еще на одном моменте. Выше мы исследовали базовые требования к дискреционному принципу контроля доступа (для СВТ шестого класса защищенности). Однако, при переходе к другим классам данные требования расширяются, в частности, начиная с четвертого класса защищенности появляется требование: КСЗ должен содержать механизм, претворяющий в жизнь дискреционные ПРД, как для явных действий пользователя, так и для скрытых, обеспечивая тем самым защиту объектов от НСД (т.е. от доступа, недопустимого с точки зрения заданного ПРД). Под “явными” здесь подразумеваются действия, осуществляемые с использованием системных средств - системных макрокоманд, инструкций языков высокого уровня и т.д., а под “скрытыми” - иные действия, в том числе с использованием собственных программ работы с устройствами. Заметим, что данное требование, на наш взгляд, регламентирует уже подходы к реализации механизма замкнутости программной среды с использованием дискреционного принципа контроля доступа. Это уже вопрос самостоятельного серьезного исследования, которое выходит за рамки настоящей работы. В качестве замечания отметим, что когда речь заходит о замкнутости программной среды, на наш взгляд, уже следует говорить не только об исполняемых файлах (собственных программ пользователей), но и о скриптах, макросах и т.д. В данном приложении задача защита от НСД уже тесно связана с задачей антивирусного противодействия. Итак, обобщим полученные результаты и сделаем выводы по работе (естественно, что на основании проведенного в работе исследования требований только к одному механизму защиты). Выводы по работе.
В качестве же замечания отметим, что в данной части работы исследован лишь один аспект корректности реализации добавочных СЗИ НСД, связанный с корректностью реализации отдельных механизмов защиты. Вместе с тем, необходимо понимать, что СЗИ НСД – это внешнее по отношению к ОС средство, как следствие, ОС не обеспечивает защиту СЗИ НСД (от загрузки системы без СЗИ НСД, от удаления компонент добавочной защиты в процессе функционирования системы и т.д.). Поэтому, при использовании добавочного средства защиты, актуальной становится задача защиты самой добавочной СЗИ НСД. Эту задачу и пути ее решения мы рассмотрим в следующей части нашей работы. Читайте далее:  1 - 7 мая 2006 года Я помню, как все начиналось ,часть 6, 5 - 11 июня 2006 года 24 - 31 июля 2006 года 14 - 20 августа 2006 года 11 - 17 сентября 2006 года 9 - 15 октября 2006 года 6 - 12 ноября 2006 года 27 - 30 ноября 2006 года 11 - 17 декабря 2006 года 29 - 31 января 2007 года 12 - 18 февраля 2007 года
|
