Вы находитесь в разделе Типовых решений систем безопасности
Принципы и механизмы доверительного контроля доступа к ресурсам. вопросы антивирусной защитыВ данной части работы рассматривается очень важная проблема защиты информации, состоящая в том, что именно процесс (а не пользователь) может нести в себе уязвимость, используемую для несанкционированного доступа к информации, как следствие, именно процесс становится основным субъектом при контроле доступа к ресурсам, причем, как в задачах защиты информации от несанкционированного доступа (НСД), так и в задачах антивирусной защиты. На основании сравнительного анализа задач защиты информации от несанкционированного доступа (НСД) с задачами антивирусной защиты, делается вывод о том, что задачи антивирусной защиты являются подмножеством множества задач защиты информации от НСД, а не классом самостоятельных задач защиты информации. Предлагаются принципы и механизмы доверительного контроля доступа к ресурсам, которые могут эффективно использоваться в задачах защиты информации от НСД и, как следствие, в задачах антивирусной защиты. Основу существующих принципов контроля доступа к ресурсам (рассматривались нами в третьей и пятой частях работы) составляет задание прав и разграничений на основании определенных правил доступа субъектов (пользователей) к объектам, в частности, к файловым объектам. Данный способ контроля доступа реализуется современными средствами защиты информации от несанкционированного доступа (НСД), в частности ОС, и формализован в соответствующих нормативных документах. При этом любой процесс, запускаемый пользователем (в том числе, и пользователем System), наследует права доступа пользователя, его запустившего. Другими словами, поток, порождаемый процессом, обращается к ресурсу с правами пользователя (если, естественно, не произведено олицетворения с маркером безопасности другого пользователя, но это отдельный вопрос, рассмотренный нами в третьей части работы). Однако именно процесс, и может нести в себе уязвимость, используемую для несанкционированного доступа к информации. Тому может быть несколько причин, положим их в основу классификации процессов, которая нам далее понадобится при изложении материала:
Сразу оговоримся, что, если сервис по запуску процессов, предоставляется непосредственно системой, поэтому именно на нее (решаться на системном уровне) должны возлагаться вопросы защиты от НСД, связанные с несанкционированными, критичными и скомпрометированными процессами, то защита сервисов, связанных предоставлением процессом возможности среды исполнения, уже является задачей разработчиков приложений, предоставляющих подобные сервисы. Таким образом, может быть обозначена проблема осуществления контроля доступа к ресурсам с учетом доверия к процессам или доверительного контроля доступа к ресурсам. Естественно, что учет доверия к процессам при контроле доступа к ресурсам возможен только в том случае, если процесс можно рассматривать, как самостоятельный субъект доступа, а не субъект, наследующий права доступа пользователя (в противном случае, следует говорить о доверии к пользователю, а не к процессу). Основу предлагаемых нами принципов доверительного контроля доступа к ресурсам, составляет включение в схему разграничения прав доступа к ресурсам, наряду с субъектом доступа пользователь, субъекта доступа процесс, в предположении, что права доступа этих субъектов не совпадают. Предлагаемое нами запатентованное решение (Патент № 220761 подробно описано в первой части работы, и состоит в следующем. В общем случае при управлении доступом к ресурсам следует различать два самостоятельных субъекта доступа – пользователь и процесс. При этом предлагается управлять доступом (разграничивать права доступа) не только для субъекта пользователь, но и для субъекта процесс, причем могут быть выделены следующие схемы задания разграничительной политики доступа к ресурсам:
Прежде, чем перейти к рассмотрению предлагаемых нами подходов и технических решений остановимся на рассмотрении еще одной группы проблем – проблем антивирусной защиты. На сегодняшний день, как-то принято рассматривать задачи антивирусного противодействия и защиты от несанкционированного доступа к информации (НСД), как две самостоятельные, практически независимые задачи. Наверное, это обусловлено тем, что основу данных способов защиты исторически составляют совершенно различные подходы – в основе антивирусной защиты лежит сигнатурный анализ данных (например, “тела” файла) на наличие в нем (и идентификация по заданной сигнатуре типа) признаков исполняемого файла, наличия макросов и т.д., в то время, как в основе защиты от НСД находится реализация разграничительной политики доступа к ресурсам (механизмы контроля доступа к ресурсам). Попробуем разобраться в вопросе, так ли действительно независимы рассматриваемые задачи защиты, и в какой мере могут средства защиты от НСД быть использованы при решении задачи антивирусного противодействия. С этой целью, прежде всего, приведем укрупненную классификацию вирусных атак:
Из приведенной классификации видим, что проблемы антивирусной защиты полностью аналогичны проблемам защиты информации от НСД (в рассматриваемой их части), основу здесь также составляет вопрос доверия к процессу (а с учетом приведенной классификации процессов, можем видеть, что задачи защиты от НСД несколько шире, чем задачи антивирусной защиты). Следовательно, можем сделать выводы:
В качестве же замечания отметим, что недостатки подходов к антивирусной защите, связанных с поиском вирусов на основе сигнатурного анализа данных, и на основе поведенческих анализаторов работы приложений, всем давно известны и в работе не рассматриваются. Теперь перейдем к предлагаемым нами подходам, рассматривать которые будем в соответствии с приведенной выше классификацией процессов. В качестве замечания отметим, что, во-первых, рассмотренные в статье решения апробированы при создании семейства СЗИ НСД – КСЗИ Панцирь (для ОС семейства Windows) - разработка НПП Информационные технологии в бизнесе, во-вторых, они либо уже запатентованы, либо находятся в стадии патентования, поэтому без нарушения авторских прав, рассмотренные в работе технологии не могут быть реализованы в разработках иных производителей. Несанкционированные (сторонние) процессы. Противодействие запуску на защищаемом компьютере несанкционированных (сторонних) процессов обеспечивается механизмом обеспечения замкнутости программной среды. Под обеспечением замкнутости программной среды в общем случае понимается локализация на защищаемом компьютере возможности запуска программ пользователями механизмом управления доступом к ресурсам (контролем доступа на исполнение файлов). Особенностью механизма обеспечения замкнутости программной среды является следующее – механизм реализован корректно только при условии, если им выполняются требования к полноте и к корректности разграничений к исполняемыми файлами. С учетом сказанного, делаем вывод, что механизм обеспечения замкнутости программной среды и механизм управления доступом к исполняемому файлу (к запуску программ) в общем случае два различных механизма защиты (причем один реализуется по средством другого). При этом под полнотой разграничений понимаем возможность разграничить доступ “на исполнение” для всех компьютерных ресурсов, с которых возможен запуск программы, а под корректностью разграничений понимаем отсутствие какой-либо возможности модификации разрешенных к запуску исполняемых файлов, а также запуск под их именем других (несанкционированных) программ. Практическое использование данного механизма защиты связано с определенными трудностями. Так, ряд известных нам добавочных СЗИ НСД решают эту задачу, по средством задания списка разрешенных к запуску исполняемых файлов – процессов (при этом выполняется ряд мероприятий по обеспечению корректности решения задачи – исполняемые файлы в разграничениях задаются их полнопутевыми именами, причем они должны располагаться только на жестком диске, и к разрешенным на запуск исполняемым файлам запрещается доступ на запись), с последующим заданием соответствующих разграничений для исполняемых файлов. Кто хоть раз пробовал настроить подобный механизм, представляет насколько это сложно, причем, как в части создания, так и в части модификации списка (списков, если они различны для различных пользователей) разрешенных к запуску процессов. Во-первых, подобных файлов в системе (а это ведь не только файлы приложений, но и системные исполняемые файлы) может быть достаточно много, во-вторых, один процесс, может запускать другой, и для корректной работы приложения необходимо разрешить на запуск все его процессы, установив соответствующие разграничения на исполняемые файлы. Не случайно разработчики известных нам добавочных средств защиты пытаются, хоть как-то, упростить настройку данного механизма – вводят малую автоматизацию с использованием средств аудита, прилагают отдельные инструкции по настройке данного механизма. Как следствие, велика вероятность ошибок в администрировании механизма, причем критичных ошибок, в том числе, связанных с корректностью функционирования, как приложений, так и собственно системы. Подход же к решению задачи, связанный с заданием контрольных сумм разрешенных к запуску исполняемых файлов, предполагающий осуществление контроля исполняемых файлов перед их запуском, нами не рассматривается (механизм контроля целостности, сильно влияющий на загрузку вычислительного ресурса, принято использовать в случае, когда невозможно корректно решить задачу средствами контроля доступа). Предлагаемый нами подход к реализации механизма обеспечения замкнутости программной среды состоит в следующем. Замкнутость программной среды предлагается определять не списком разрешенных к запуску процессов, а каталогом (каталогами), из которых пользователям разрешается запуск исполняемых файлов. Проиллюстрируем сказанное на примере. Пусть все разрешенные к запуску процессы располагаются (устанавливаются) только в каталогах C:\Program Files и С:\Windows (на системном диске C:\), это целесообразно, так как следует контролировать запуск и системных процессов. Реализуя разрешительную разграничительную политику доступа к ресурсам (Все, что не разрешено (явно не указано), то запрещено) – это основное условие корректности реализации механизма, разрешим пользователям на исполнение только каталоги C:\Program Files и С:\Windows, причем не разрешим пользователям доступ к этим каталогам “на запись” (чем запретим создание и модификацию расположенных в этих каталогах файловых объектов). Рассмотрим, к чему это приведет. Пользователь сможет запустить программу только из заданных каталогов, причем только с жесткого диска, и не сможет модифицировать исполняемые файлы разрешенных к запуску процессов, причем, как прикладных, так и системных. Теперь вернемся к проблеме сложности администрирования. При подобной реализации механизма, в части его администрирования, сохраняются все исходные (выполняемые до установки средства добавочной защиты) действия администратора – он штатными средствами должен инсталлировать программы в заданные каталоги, в частности C:\Program Files и С:\Windows, и штатными же средствами удалять программы. Рассмотренные же выше разграничения задаются лишь несколькими записями при настройке механизма защиты. Интерфейс настройки механизма обеспечения замкнутости программной среды в КСЗИ Панцирь для ОС Windows 2000/XP/2003, приведен на рис.6.1. Важнейшим условием корректности реализации механизма обеспечения замкнутости программной среды является следующее – в системе не должно существовать какой-либо возможности несанкционированной модификации каталогов с разрешенными к запуску исполняемыми файлами. Следовательно, данные каталоги должны быть закрыты “на запись” (должна предотвращаться любая возможность их модификации) любым пользователем, в том числе, и привилегированными пользователями, в частности, пользователем System. Из этого следует, что всем пользователям, включая привилегированных, следует запрещать доступ на запись к системному диску. Способ решения данной задачи (реализованный и апробированный в КСЗИ Панцирь) с иллюстрацией настроек механизма контроля доступа к ресурсам достаточно подробно описан в первой части нашей работы. Таким образом, задача контроля доступа к ресурсам с учетом доверия к процессам или доверительного контроля доступа к ресурсам несанкционированных (сторонних) процессов сводится к обеспечению замкнутости программной среды, что не позволяет запускать несанкционированные (сторонние) процессы и модифицировать санкционированные (разрешенные к запуску) на компьютере процессы (соответственно, их исполняемые файлы). Теперь вернемся к проблеме антивирусной защиты и покажем, что механизм обеспечения замкнутости программной среды в полном объеме оказывает противодействие трем (из четырех возможных, в соответствии с представленной ранее классификацией) группам вирусных атак: Вредные программы, Вирусы, Черви. Заметим, что это наиболее критичные вирусные атаки (характеризуются наиболее значимыми последствиями для зараженного объекта). Вредные программы и Черви (отличаются лишь способом заражения – локальное или сетевое) – это ни что иное, как некие сторонние программы, которые не должны запускаться на защищаемом компьютере – решение этой задачи и является назначением механизма обеспечения замкнутости программной среды. Вирусы же призваны заражать исполняемые файлы, разрешенные к запуску - противодействие этому собственно заложено в требовании к корректности реализации механизма обеспечения замкнутости программной среды. Из приведенного выше описания механизма обеспечения замкнутости программной среды следует, что даже при проникновении рассматриваемых вирусов на защищаемый компьютер, как локально, так и из сети, они не смогут нанести никакого ущерба, т.к. данные сторонние программы не смогут быть запущены в принципе. Заметим, что задача антивирусной защиты в данном случае решается в общем виде, за счет того, что реализуется разрешительная разграничительная политика – не требуется обнаруживать исполняемые файлы, запуск которых несет в себе угрозу (не нужен анализ сигнатур, не требуется обновление вирусных баз и.д.), кроме того, реализация данного подхода практически не влияет на загрузку вычислительного ресурса. В части же использования данного механизма с целью противодействия вирусным атакам четвертой группы, отметим, что следует максимально ограничить возможность пользователя по запуску программ, являющихся соответствующей средой исполнения (по возможности, исключить эти программы из разрешенных к запуску).  Рис.6.1 Интерфейс настройки механизма обеспечения замкнутости программной среды в КСЗИ Панцирь Теперь вернемся к проблеме антивирусной защиты и покажем, что механизм обеспечения замкнутости программной среды в полном объеме оказывает противодействие трем (из четырех возможных, в соответствии с представленной ранее классификацией) группам вирусных атак: Вредные программы, Вирусы, Черви. Заметим, что это наиболее критичные вирусные атаки (характеризуются наиболее значимыми последствиями для зараженного объекта). Вредные программы и Черви (отличаются лишь способом заражения – локальное или сетевое) – это ни что иное, как некие сторонние программы, которые не должны запускаться на защищаемом компьютере – решение этой задачи и является назначением механизма обеспечения замкнутости программной среды. Вирусы же призваны заражать исполняемые файлы, разрешенные к запуску - противодействие этому собственно заложено в требовании к корректности реализации механизма обеспечения замкнутости программной среды. Из приведенного выше описания механизма обеспечения замкнутости программной среды следует, что даже при проникновении рассматриваемых вирусов на защищаемый компьютер, как локально, так и из сети, они не смогут нанести никакого ущерба, т.к. данные сторонние программы не смогут быть запущены в принципе. Заметим, что задача антивирусной защиты в данном случае решается в общем виде, за счет того, что реализуется разрешительная разграничительная политика – не требуется обнаруживать исполняемые файлы, запуск которых несет в себе угрозу (не нужен анализ сигнатур, не требуется обновление вирусных баз и.д.), кроме того, реализация данного подхода практически не влияет на загрузку вычислительного ресурса. В части же использования данного механизма с целью противодействия вирусным атакам четвертой группы, отметим, что следует максимально ограничить возможность пользователя по запуску программ, являющихся соответствующей средой исполнения (по возможности, исключить эти программы, из разрешенных к запуску). Критичные процессы. Для этой группы процессов следует, по возможности, установить жесткие разграничения прав доступа к защищаемым ресурсам. Заметим, что если выше (механизм обеспечения замкнутости программной среды) в основном речь шла о разграничении прав доступа для пользователей, здесь мы уже говорим непосредственно о процессах, т.е. все сказанное ниже уже касается процессов и основывается степени нашего доверия к процессу. Суть предлагаемого подхода состоит в следующем. Средствами контроля доступа необходимо создать такие условия функционирования для данного процесса, при которых получение несанкционированных возможностей управления процессом (например, при обнаружении в процессе уязвимости), не позволит осуществить какой-либо иной доступ к ресурсам, кроме как необходимый для корректного функционирования критичного процесса. Своего рода, по аналогии со сказанным выше, здесь решаем задачу обеспечения замкнутости доступа процесса к ресурсам. Такая возможность появляется при включении в схему контроля доступа к ресурсам субъекта доступа процесс, как самостоятельного субъекта доступа (можно задавать, как эксклюзивные права доступа для процесса, так и комбинированные, если одновременно следует учитывать и права доступа пользователей). Реализация данного подхода возможна в том случае, если разграничения для субъекта процесс можно устанавливать ко всем значимым ресурсам вычислительного средства. Например, в КСЗИ Панцирь такое решение реализовано в диспетчерах (драйверах) контроля доступа:
Интерфейс настройки разграничений доступа для субъектов процесс в КСЗИ Панцирь для ОС Windows 2000/XP/2003, приведен на рис.6.2.  Рис.6.2 Интерфейс настройки разграничений доступа для субъектов процесс в КСЗИ Панцирь При контроле доступа к файловым объектам процесс может рассматриваться и как субъект доступа, и как объект доступа (исполняемый файл, для которого устанавливается атрибут Выполнение, см. рис.5. . Используя данную возможность может быть обеспечена замкнутость программной среды уже не для пользователя, а для процесса, в данном случае, для критичных процессов. Отдельно следует рассмотреть возможность контроля олицетворения потоками, порождаемыми критичными процессами, с маркерами безопасности других пользователей (т.е. контроля возможности отождествления с правами другого пользователя). Этот вопрос частично рассматривался нами в первой части работы. Все работающие в системе процессы и потоки выполняются в контексте защиты того пользователя, от имени которого они так или иначе были запущены. Для идентификации контекста защиты процесса или потока используется объект, называемый маркером доступа (access token). В контекст защиты входит информация, описывающая привилегии, учетные записи и группы, сопоставленные с процессом и потоком. В процессе регистрации в системе создается начальный маркер, представляющий пользователя, который входит в систему, и сопоставляет его с процессом оболочки, применяемой для регистрации пользователя. Все программы, запускаемые пользователем, наследуют копию этого маркера. Механизмы защиты в ОС Windows используют маркер, определяя набор действий, разрешенных потоку или процессу (например, доступ к защищаемому объекту или привилегию, например, на выключение компьютера). Маркер может быть основным (идентифицирует контекст защиты процесса) или олицетворяющим (применяется для временного заимствования потоком другого контекста защиты — обычно другого пользователя). Олицетворение (impersonation) — механизм, используемый в модели защиты Windows, предоставляет возможность отдельному потоку выполняться в контексте защиты, отличном от контекста защиты процесса, его породившего, т.е. действовать от лица другого пользователя. Иллюстрация сервиса олицетворения приведена на рис.6.3.  Олицетворение, например, применяется в модели программирования клиент-сервер. При заимствовании прав сервер временно принимает профиль защиты клиента, который обращается к ресурсу. Тогда сервер может работать с ресурсом от имени клиента, а система защиты проводить проверку его прав доступа. Обычно серверу доступен более широкий круг ресурсов, чем клиенту, и при олицетворении клиент может терять часть исходных прав доступа. И, напротив, при олицетворении сервер может получить дополнительные права. Суть задачи контроля олицетворения состоит в следующем - для процесса (в нашем случае – для критичного процесса), потоки запускаемые которым, используют сервисы олицетворения задаются права олицетворения (соответственно, для всех потоков, порождаемых данным процессом, они одинаковы). Права олицетворения задаются следующей парой параметров: учетная запись пользователя, от лица которого запущен процесс, включая пользователя SYSTEM (процесс в общем случае может запускаться под различными учетными записями); учетная запись пользователя, с контекстом защиты которого разрешается олицетворяться потокам, запускаемым процессом, для которого задаются разграничения. Важным условием корректности реализации любого механизма, реализующего разграничительную политику доступа к ресурсам, в том числе, и рассматриваемого в работе, является реализация системой защиты разрешительной разграничительной политики (Все, что не разрешено (явно не прописано), то запрещено - об этом мы говорили в предыдущих частях работы), при которой задаются (явно прописываются) разрешенные виды олицетворения. Интерфейс настройки механизма контроля олицетворения, реализованный в КСЗИ “Панцирь” для ОС Windows 2000/XP/2003, приведен на рис. 6.4.  Рис. 6.4 Интерфейс настройки механизма контроля олицетворения, реализованный в КСЗИ “Панцирь” Таким образом, задача контроля доступа к ресурсам с учетом доверия к процессам или доверительного контроля доступа к ресурсам критичных процессов сводится к заданию жестких прав и контроля доступа к ресурсам для критичных процессов, в части:
Скомпрометированные процессы. Во многом задача контроля доступа к ресурсам с учетом доверия к процессам или доверительного контроля доступа к ресурсам скомпрометированных процессов, аналогична рассмотренной выше задаче контроля доступа к ресурсам с учетом доверия к процессам или доверительного контроля доступа к ресурсам критичных процессов, т.е. так же и такими же средствами сводится к заданию жестких прав и контроля доступа к ресурсам. Отличие здесь состоит лишь в том, что, если для критичных процессов соответствующие разграничения задаются изначально (в предположении, что критичный процесс может быть скомпрометирован), то в данном случае, уже после компрометации процесса, зная обнаруженную уязвимость. Знание о природе конкретной уязвимости и возможных ее последствиях позволяет устанавливать для скомпрометированного процесса не все возможные, а лишь необходимые разграничения – не такие жесткие, как для критичного процесса (в предположении, что скомпрометированный процесс одновременно не являлся и критичным), чем в общем случае упрощается задача администрирования. Процессы, априори обладающие недекларированными (документально не описанными) свойствами. Целью доверительного контроля доступа к ресурсам в данном случае является ограничение последствий от воздействия на систему процесса, априори обладающего недекларированными (документально не описанными) свойствами, что мы попытаемся осуществить в следующих предположениях - процесс нам необходим для работы и мы не можем не включить его в список разрешенных для выполнения. Сразу оговоримся, что все сказанное выше применимо и в данном случае, т.к. рассматриваемые здесь процессы естественно относятся к критичным (здесь мерой критичности процесса является априорное к нему недоверие) – необходимо осуществить максимально жесткие разграничения для процессов, обладающих недекларированными (документально не описанными) свойствами к ресурсам компьютера, использовав все возможности, рассмотренные выше для критичных процессов. Далее необходимо сделать одно из двух предположений, либо мы можем полностью определить функции исполняемого кода, либо это сделать в общем случае не представляется возможным. Это условие задается способом хранения исполняемого кода, который может храниться либо в виде отдельного файла (например, файлы с расширением bat), либо в составе документа, в частности, макросы. Подход к защите для случая, когда исполняемый код хранится в виде отдельного файла. В части возможного подхода к защите здесь сразу же приходит на ум механизм обеспечения замкнутости программной среды. Действительно, по полной аналогии с тем, как это было реализовано для процессов, здесь можно разрешить запускать только санкционированный исполняемый код. Тогда логичным будет сформировать каталог, в котором разместить файлы исполняемого кода (например, файлы с расширением bat) и только из этого каталога разрешить запуск исполняемого кода, запретив пользователям (процессам с правами пользователей) возможность модификации данного каталога. Все бы ничего, но есть одна проблема, суть которой состоит в том, что процесс виртуальной машины, при обращении на запуск скрипта, осуществляет запрос не на исполнение, а на чтение файла. Пользователю же мы должны разрешать полный доступ к какому-либо файловому объекту, как следствие, любой процесс, запущенный с пользовательскими правами, всегда сможет разместить в нем исполняемый код, затем остается выполнить его, посредством чтения его процессом виртуальной машины. В этом случае нам на помощь опять же приходит технология включения процесса в субъекты доступа, как самостоятельного субъекта. Используем данное решение в этом случае. С этой целью создадим отдельный файловый объект, например, каталог, куда поместим файлы с исполняемыми кодами (скрипты). Запретим возможность модификации этого файлового объекта пользователями, процессу же виртуальной машины разрешим доступ на чтение только к этому каталогу. Получаем следующее – виртуальная машина может осуществить чтение только санкционированных исполняемых кодов (из заданного каталога), а пользователи (соответствующие процессы) ни при каких условиях не смогут модифицировать файлы с исполняемыми кодами. Другими словами, для данной постановки задачи получили механизм защиты полностью аналогичный механизму обеспечения замкнутости программной среды – механизм обеспечения замкнутости исполняемых кодов. Подходы к защите для случаев, когда исполняемый код хранится в составе документа. Данный случай характеризуется тем, что читая документ, например, с использованием Java-машины или офисного приложения, мы в общем случае вообще не знаем, есть ли в нем исполняемый код (например, макрос), какими функциями наделен макрос и т.д., т.е. что, в конечном счете, будет делать соответствующий процесс, после прочтения документа. Однако попытаемся решить задачу защиты в общем виде и в этом случае. При этом, если речь идет о макросах, то в предположении, что макрос запущен и мы не можем определить его свойств, встает задача ограничить распространение макроса в системе (возможность заражения документов, хранящихся на компьютере), если мы говорим об использовании Java-машины, мы также будем защищать информацию от НСД на компьютере в предположении полной непредсказуемости ее действий и т.д. Принципиальным отличием постановки задачи доверительного контроля доступа в данном случае является то, что мера доверия к процессу в полной мере определяется нашим доверием к документу, к которому обращается процесс. С учетом этого, здесь можно выделить два случая, применительно к которым далее будем рассматривать предлагаемые подходы. Первый случай характеризуется тем, что меру доверия к документу невозможно как-то категорировать в принципе. Например, вы используете Java-машину при работе с ресурсам сети Интернет – какое здесь может быть доверие к документам, расположенным на сайтах общего доступа? Невозможность категорировать документы по степени доверия к ним, требует рассматривать защиту в предположении полного недоверия к документам, как следствие, полного недоверия к процессу, призванному обрабатывать эти документы. 3. Подход к защите при полном недоверии к обрабатываемым документам (как следствие, к критичному процессу). Данный случай характеризуется тем, что мы исходно предполагаем, что процесс после чтения документа выполняет несанкционированные действия, поэтому данный процесс никаким образом не должен получить возможность доступа (модификации) к документам, хранящимся на компьютере. Таким образом, к документам, хранящимся на компьютере, доступ (по крайней мере, на запись) этому процессу следует запретить. Тогда, чтобы обеспечить возможность использования соответствующего процесса (приложения), следует выделить для работы с ним отдельный файловый объект (например, каталог), и только с этим файловым объектом разрешить взаимодействовать данному критичному процессу (установить соответствующие ПРД для критичного процесса, разрешив ему доступ только к соответствующему файловому объекту). Другими словами, файловые объекты предлагается подразделять, на объекты, предназначенные для хранения данных пользователей, и объекты, предназначенные для обработки данных пользователями (в первую очередь это касается критичных процессов). Для копирования же данных из одного объекта в другой может быть использован проводник, не несущий в себе соответствующей угрозы (не критичный процесс). В этих условиях обработка данных критичным процессом может быть осуществлена по одной и двух схем, приведенных на рис.6.5 (где ОХД – объект хранения данных, ООД – объект обработки данных, КП- критичный процесс, П – проводник).  Рис. 6.5 Схемы обработки данных критичным процессом Схемы, представленные на рис.6.5, отличаются тем, что в первом случае доступ критичного процесса к объектам хранения данных пользователей запрещен, во второму случае – разрешен только на чтения (соответствующим образом задаются и права доступа для не критичного процесса-проводника, осуществляющего копирование данных между соответствующими файловыми объектам). Выбор схемы обработки определяется тем, каковы функции критичного процесса, и что мы здесь вкладываем в понятие НСД к информации. Например, если критичным процессом является почтовый клиент, то обработку данных критичным процессом следует выполнять по первой схеме, в противном случае имеем угрозу несанкционированного чтения данных пользователей из ОХД во внешнюю сеть. На примере рассмотрим возможность применения данного подхода. Пусть требуется обрабатывать документы (получать доступ к хостам внешней сети) с использованием Java-машины. Выделим отдельный каталог – ООД (соответственно, для различных пользователей это могут быть различные каталоги), только в который разрешим доступ процессам Java-машины, соответствующим образом зададим ПРД для процесса-проводника. При таком подходе (с учетом того, что процессам Java-машины, как критичным процессам установлены все необходимые разграничения для критичных процессов, рассмотренных ранее) несанкционированные возможности процессов Java-машины становятся не критичными не только по отношению к ресурсам компьютера, включая системные ресурсы, но и по отношению к данным пользователей, хранящихся на компьютере – информация пользователей. Таким образом, можем сделать вывод, что при таком подходе информация защищена от НСД критичными процессами в общем виде. 4. Подход к защите на основе категорирования доверия к обрабатываемым документам (как следствие, к критичному процессу). Данный случай предполагает, что в некоторых приложениях мы можем ввести категории доверия к обрабатываемым документам. В первую очередь, это относится к защите от макросов, где в качестве критичных процессов могут рассматриваться офисные приложения. Действительно, всегда можно разделить документы, хранящиеся и обрабатываемые на компьютере, на те, которые мы создали самостоятельно и те, которые каким-либо образом внесены из-вне, например, с дискеты, из сети и т.д. Естественно доверие к этим документам различно (конечно, в предположении, что создавая документ, вы сознательно в него не заносите вирус – этот случай естественно мы не рассматриваем). Создавая новый документ, в предположении, что офисное приложение само каким-либо образом не модифицировано (но в противодействии этому нам поможет механизм обеспечения замкнутости программной среды, описанный выше), мы можем быть уверены, что в нем вируса нет. Получая же документ из каких-либо внешних источников, мы уже не имеем к нему такого же доверия. Однако источники получения документа также могут быть различны, одно дело – мы получаем документ на носителе в рамках выполнения производственных задач (от сотрудника нашего предприятия, причем мы знаем, например, что этот документ создан лично им, и в нем не может быть макроса, либо этот макрос безвреден), и, совсем другое дело, если документ мы скачиваем по сети Интернет из неизвестных нам источников. Вот уже получаем три уровня (категории) доверия: личные документы, корпоративные документы, внешние документы. И этот ряд можно продолжить. Естественно, что процесс (в частности, офисное приложение) при чтении документа какого-либо уровня доверия приобретает уровень доверия этого документа (он с той вероятностью будет совершать несанкционированное действие после чтения документа, с которой в прочтенном приложением документе находится макрос, являющийся исполняемым кодом данного несанкционированного действия). С учетом сказанного, рассмотрим, к чему здесь сводится задача защиты данных пользователей, хранящихся на компьютере, от “заражения” вирусом (рассматриваем только задачу защиты данных пользователей в предположении, что для процессов офисных приложений, которые естественно относим к критичным, установлены соответствующие критичным процессам ПРД к ресурсам, в том числе, к системным, о чем говорилось ранее). Естественно, что задача защиты сводится к разделению документов на категории доверия и к предотвращению возможности снижения категории документа (условимся считать, что чем выше категория документа, тем выше доверие к документу). Решение данной задачи состоит в следующем:
Реализация данных правил механизмом доверительного контроля доступа, проиллюстрирована на рис.6.6, где в первом случае пользователь запускает процесс для работы с личными документами, во втором случае – с корпоративными. Проанализируем примеры, приведенные на рис. Видим, что задача предотвращения возможности снижения категории документа здесь решена корректно. Действительно, при обработке документов, их категория может только снижаться, но ни как не повышаться. Снижение же категории (уровня доверия) документа осуществляется в том случае, если одновременно необходимо обрабатывать информацию нескольких уровней доверия. Например, новый документ создается сразу из двух документов (с использованием возможностей копирования и т.д.) различного уровня доверия. При этом новый документ имеет уровень доверия, соответствующий минимальному уровню одновременно обрабатываемых документов. Это обусловливается тем, что вероятность выполнения критичным процессом несанкционированного действия после чтения документа, здесь практически полностью задается вероятностью нахождения макроса, являющегося исполняемым кодом данного несанкционированного действия, в документе наиболее низкого уровня доверия).  В качестве замечания, отметим, что рассмотренный подход к защите и подход, описанный выше, могут быть совмещены. При этом возможны различные способы (в соответствии в решаемыми задачами) объединения эти механизмов защиты. В частности, дополнительный объект обработки данных может включаться для обработки документов наиболее низкого уровня доверия, что проиллюстрировано на рис.6.7. Возвращаясь к рис.6.6, видим, что представленная здесь схема разграничений очень напоминает полномочную схему разграничений, в частности реализуемую мандатным механизмом контроля доступа, основу которого составляет назначение и обработка по определенным правилам меток безопасности, назначаемых в соответствии с иерархией конфиденциальности информации (этот механизм нами подробно рассмотрен в пятой части работы). С учетом сказанного, может быть предложен мандатный механизм контроля доступа к ресурсам на основе меток доверия, назначаемых в соответствии с иерархией доверия к обрабатываемым документам. Рассмотрим предлагаемый нами механизм защиты, основанный на использовании меток доверия.  Основу механизма составляет включение в схему управления доступом к ресурсам, так называемых, меток доверия к документам (иерархических), отображающих уровень доверия к документам и полномочия критичных процессов, основанных на принципах доверия к документам. При этом ПРД критичных процессов к файловым объектам полностью определяются метками доверия и правилами их обработки. Метки доверия являются элементами линейно упорядоченного множества M = {M1,…, Mk} служат для формализованного представления их уровня доверия. Будем считать, что чем выше уровень доверия (меньше порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}), тем меньшее значение метки безопасности Mi, i = 1, …, k им присваивается, т.е.: M1 < M2 < M3<… Таким образом, в качестве учетной информации субъектов и объектов доступа, кроме их идентификаторов – имен, объекту задаются метки доверия из множества M. Назначение метки субъектам (критичным процессам) и объектам (файловым объектам, в которых хранятся документы), принципиально различно. Если метки объектов статические – определяются тем, какого уровня доверия документы предполагается хранить в файловом объекте, то метки субъектов (критичных процессов) динамические. При каждом запуске процесса, метка процесса запрашивается у пользователя, который назначает метку процесса, исходя из того, с документами какого уровня доверия пользователь собирается работать. Разграничение доступа реализуется на основе правил, определяющих отношение линейного порядка на множестве M, где для любой пары элементов из множества M, задается один из типов отношения : {>,<,=} (на практике целесообразно осуществлять выбор подмножества M, изоморфного конечному подмножеству натуральных чисел – такой выбор делает естественным арифметическое сравнение меток доверия). Рассмотрим правила разграничения доступа, при этом введем следующие обозначения:
Важнейшим свойством механизма доверительного контроля доступа к ресурсам, основанного на использовании меток доверия, является не только упрощение задачи администрирования, за счет использования меток, но и появляющуюся возможность автоматизации сохранения уровня доверия к документам корпорации. Суть подхода к решению этой задачи состоит в следующем. Пусть метка доверия является атрибутом файлового объекта (документа), и пусть она сохраняется на внешнем носителе, либо передается по сети вместе с файловым объектом (документом). Тогда можно ввести правило записи документов (файлов) в объекты с установленными для них метками, состоящее в следующем. Файл, содержащий метку доверия, может быть записан только в объект (например, каталог), имеющий аналогичную метку доверия, файл, не имеющий метки доверия (не обрабатывался вычислительными средствами корпорации), может быть записан в объект, характеризуемый наименьшим доверием, к хранящимся в нем документам. Может быть автоматизирован и процесс назначения метки доверия критичным процессом. Это может быть сделано следующим образом. Исходно критичный процесс не имеет метки (какой-либо доступ к ресурсам ему запрещен). При первом обращении к файловому объекту запущенным пользователем критичным процессом, процессу присваивается метка доверия данного файлового объекта. Однако, далее не будем рассматривать возможные пути улучшения предлагаемого подхода, что является отдельным исследованием. Назначением данной работы являлось рассмотрение самих возможностей и принципов реализации доверительного контроля доступа к ресурсам. Возвращаясь же к проблеме антивирусной защиты, можем увидеть, что средствами защиты информации от НСД (механизмами контроля доступа к ресурсам) может эффективно решаться и наиболее сложная задача антивирусной защиты – задача противодействия макро-вирусам, к которым относятся скриптовые вирусы - программы, для исполнения которых требуется определенная среда выполнения (командный интрепретатор, виртуальная машина и т.п.), к этой же группе относятся и офисные приложения, позволяющие создавать и подключать макросы. Таким образом, результатами исследований мы подтвердили следующие два вывода, сделанные в начале работы:
Читайте далее:  Я помню, как все начиналось ,часть 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 года
|
