СИСТЕМА КОНТРОЛЯ ДОСТУПА К ФАЙЛАМ НА ОСНОВЕ ИХ АВТОМАТИЧЕСКОЙ РАЗМЕТКИ

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

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

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

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

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

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

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

В настоящее время известны различные системы контроля доступа к файлам.

Так, например, в заявке ЕПВ N 0192243 (кл. G06F 12/14, 1986) описан способ защиты системных файлов, в котором информация, определяющая права доступа системных пользователей, остается все время в безопасном процессоре.

В патенте №2134931 (кл. H04L 9/32, G06F 12/14) описан способ обеспечения доступа к объектам в операционной системе, основанный на назначении меток безопасности субъектам и объектам доступа, при этом для каждого объекта операционной системы заранее формируют и затем запоминают в памяти сигнал метки объекта, т.е. права доступа к объектам, назначаемые в виде меток безопасности, опять же должны присваиваться администраторам статичным объектам (папкам). В разграничительной политике доступа присутствуют две сущности - субъект и объект доступа, метки безопасности должны присваиваться администратором и субъектам, и объектам доступа.

Наиболее близкой по техническому решению и выбранной авторами за прототип является система контроля доступа к файлам, реализуемая в ОС Microsoft Windows с файловой системой NTFS, использующая для хранения прав доступа к файлам (ACL) атрибутов файлов (в частности, Security Descriptor - этот атрибут содержит информацию о защите файла: список прав доступа ACL и поле аудита, которое определяет, какого рода операции над этим файлом нужно регистрировать) [М. Руссинович, Д. Соломон. Внутреннее устройство Microsoft Windows. - СПб.: Питер, 2005 - 992 с. (глава 8, рис.8.5. Пример проверки прав доступа)].

Система представлена на Фиг.1. Система контроля доступа к файлам содержит решающий блок 1, блок хранения атрибутов файлов 2, причем первый вход решающего блока соединен с первым входом системы 3, второй вход - с выходом блока хранения атрибутов файлов 2, первый выход - с первым входом блока хранения атрибутов файлов 2, второй выход - с выходом системы 4, второй вход блока хранения атрибутов файлов 2 соединен со вторым входом системы 5.

Работает система следующим образом. Администратором или «Владельцем» (пользователем, создавшим файл) со второго входа системы 5 (со входа задания атрибутов доступа к файлам) в блок хранения атрибутов файлов 2 устанавливаются атрибуты (права) доступа к файлам (к объектам) субъектов, в которых для каждого файла указывается, какие субъекты имеют право доступа и какие им разрешены права доступа к файлу (чтение, запись, исполнение, переименование, удаление и т.д.). При запросе доступа, содержащего в своем составе имя субъекта (имя пользователя (учетной записи) и имя процесса, запрашивающих доступ, а также запрашиваемые права доступа - чтение, запись и т.д.) к файлу, запрос доступа с первого входа системы 3 (со входа запроса доступа к файлу) поступает на решающий блок 1. Для обработки запроса доступа решающий блок с первого выхода запрашивает у блока хранения атрибутов файлов 2 атрибуты файла, к которому запрошен доступ, получает их на второй вход и сравнивает запрошенные права доступа к файлу с разрешенными правами доступа к файлу, указанными в атрибутах файла. В результате сравнения решающий блок выдает на выход системы 4 (на управляющий выход разрешения/запрета доступа) управляющий сигнал, разрешающий (если запрос не противоречит разрешениям) или отклоняющий запрошенный у системы с первого входа системы 3 доступ.

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

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

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

Новым в предлагаемом изобретении является снабжение системы контроля доступа к файлам блоком автоматической разметки файлов и блоком хранения правил доступа к файлам и их связей.

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

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

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

- предлагаемое техническое решение обладает изобретательским уровнем, т.к. оно явным образом не следует из уровня техники;

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

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

Предлагаемое изобретение поясняется чертежом, представленным на Фиг.2.

Заявляемая система контроля доступа к файлам на основе их автоматической разметки содержит: решающий блок 1, блок автоматической разметки файлов 2, блок хранения правил доступа к файлам 3, блок хранения атрибутов файлов 4, причем первый вход решающего блока 1 соединен с первым входом системы 5, с первым входом блока автоматической разметки файлов 2, второй вход которого соединен с третьим входом системы 8, первый выход - с первым входом блока хранения атрибутов файлов 4, выход которого соединен с третьим входом блока автоматической разметки файлов 2, второй выход которого - со вторым входом блока хранения атрибутов файлов 4, третий выход блока автоматической разметки файлов 2 соединен с первым входом блока хранения правил доступа к файлам 3, второй вход которого - со вторым входом системы 7, третий вход - с первым выходом решающего блока 1, второй вход которого - с выходом блока хранения правил доступа к файлам 3, второй выход решающего блока 1 - с выходом системы 6.

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

Пример 1. Дискреционный (избирательный) контроль доступа к создаваемым файлам. Здесь разграничивается доступ именно к файлам, создаваемым в процессе работы системы. Разграничительная политика состоит в задании прав доступа субъектов к файлам, созданным другими субъектами.

1.1. Разграничения по пользователям (для учетных записей). Со входа 8 в блок 2 администратором задается то, что доступ к файлам, созданным какими субъектами (под какими учетными записями), следует контролировать (разграничивать), например пусть это User1 и User2 (пусть всего на компьютере заведено 4 пользователя - User1, User2, User3, User4). Все создаваемые этими пользователями (User1 и User2) файлы будут автоматически размечаться системой при создании - в атрибуты создаваемых ими файлов блоком 2 автоматически при создании будет записываться учетная информация пользователя (SID или имя), создавшего файл. Если этими пользователями модифицируются ранее созданные файлы (еще не размеченные), либо файлы, созданные пользователями User3, User4 (доступ к ним не контролируется - эти файлы не размечаются), они также будут размечаться блоком 2 аналогичным образом. Со входа 7 в блок 3 администратором задаются правила доступа к размеченным (созданным) файлам, например, в виде таблицы (или матрицы) доступа, см. Табл.1. Как видим, сущность «объект» исключена из разграничительной политики доступа, все разграничения к создаваемым файлам задаются между субъектами доступа, в рассматриваемом примере, пользователями, см. Табл. 1.

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

В Табл.2 двумя правилами полностью изолирована работа пользователя User1. Только он сможет получить доступ к создаваемым им файлам. Никакой иной пользователь (что задается маской «*») не имеет права доступа к файлам, созданным пользователем User1.

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

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

Как видим из Табл.2, оба заданных правила относятся к правилам, относящимся к файлам, созданным пользователем User1. В этом случае оба этих правила будут по запросу решающего блока 1 переданы ему на второй вход блоком 3.

На первый вход решающего блока поступает запрос доступа (запрос содержит имя пользователя, имя процесса и затребованное право доступа - запись, чтение и т.д.), на второй вход - правила доступа к файлу, к которому запрашивается доступа. Решающий блок 1 по более точному описателю субъектов в полях таблицы (матрицы) доступа - в столбцах: «Пользователь, создавший файл (эти файлы автоматически размечаются)» и «Пользователь, имеющий право доступа к (созданному) размеченному файлу», см. Табл.1, переданных ему правил, выбирает правило, наиболее точно относящееся к запросу. Например, см. Табл.2, если запрос осуществляемый пользователем User1, будет к файлу, созданному пользователем User1, то решающим блоком будет выбрано первое правило (первое правило по описателю субъектов более точно соответствует запросу доступа), если же к подобному файлу запрашивает доступ пользователь User2, то будет выбрано второе правило.

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

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

1.2. Разграничения по процессам.

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

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

Пусть, например, используется браузер Internet Explorer, исполняемый файл которого имеет следующее полнопутевое имя: E:\Program Files\Internet Explorer\iexplore.exe.

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

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

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

Как видим, все актуальнейшие современные задачи защиты, перечисленные выше, решаются в полном объеме.

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

Относительно простоты администрирования - вся разграничительная политика задается тремя строками в таблице (матрице) доступа, см. Табл.3. 1.3. Разграничения по пользователям и процессам.

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

Пример разграничительной политики доступа при данном способе определения субъекта доступа приведен в Табл.4.

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

Пример 2. Мандатный (полномочный) контроль доступа к создаваемым файлам.

Под мандатным контролем доступа в общем случае понимается способ обработки запросов доступа к файловым объектам, основанный на формальном сравнении, в соответствии с заданными правилами, меток безопасности (мандатов), назначаемых субъектам и объектам доступа (в общем случае группам субъектов и объектов). Метки безопасности, как правило, являются элементами линейно упорядоченного множества М={M1, …, Mk} и служат для формализованного представления каких-либо свойств субъектов и объектов.

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

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

Будем считать, что чем выше полномочия субъекта и уровень конфиденциальности объекта, тем меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С={С1, …, Ск} и О={O1, …, Ok}), тем меньшее значение метки безопасности Mi, i=1, …, k им присваивается, т.е.: M1 меньше М2 меньше М3 меньше ... меньше Мk.

Таким образом, в качестве учетной информации субъектов и объектов доступа, кроме их идентификаторов - имен, каждому субъекту и объекту задаются метки безопасности из множества М.

Введем следующие обозначения:

- Ms - метка безопасности субъекта (группы субъектов) доступа;

- Мо - метка безопасности объекта (группы объектов) доступа.

На практике для мандатного контроля доступа, применяемого с целью защиты от нарушения конфиденциальности информации, широко используются следующие правила контроля доступа:

1. Субъект C имеет доступ к объекту O в режиме "Чтения" в случае, если выполняется условие: Мс не больше Мо.

2. Субъект C имеет доступ к объекту O в режиме "Записи" в случае, если выполняется условие: Мс равно Мо.

3. В остальных случаях доступ субъекта C к объекту O запрещен.

Однако возможны и иные правила, например правила полной изоляции обработки информации различных уровней конфиденциальности либо при исполнении пользователями в КС различных ролей (неиерархические метки):

1. Субъект C имеет доступ к объекту O в режиме "Чтения", «Запись» в случае, если выполняется условие: Мс равно Мо.

2. В остальных случаях доступ субъекта C к объекту O запрещен.

Как видим, здесь также разграничиваются права доступа субъектов к объектам, при этом метки безопасности должны присваиваться как субъектам, так и объектам доступа.

Отличительной особенностью реализуемого в заявленном техническом решении метода контроля доступа является исключение сущности «объект доступа» из разграничительной политики. Разграничения осуществляются исключительно между субъектами доступа, а не опосредованно, через объект.

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

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

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

1. Субъект C имеет доступ к объекту O в режиме "Чтения" в случае, если выполняется условие: Мс не больше Мсо.

2. Субъект C имеет доступ к объекту O в режиме "Записи" в случае, если выполняется условие: Мс равно Мсо.

Система, по сути, работает в данном случае так же как и в рассмотренном ранее примере 1.1. Рассмотрим лишь отличия, которые состоят в следующем. Со входа 7 в блоке 3 задаются соответствия меток безопасности субъектам доступа (назначаются метки безопасности Мс субъектам, причем только тем субъектам, доступ к созданным файлам которыми должен контролироваться). Кроме того, в блоке 3 задаются правила сравнения меток Мс и Мсо, на отношении: больше, меньше, равно. В блок 2 со входа 8 задаются субъекты доступа, доступ к созданным файлам которыми должен контролироваться, и соответствующие им метки безопасности (метки безопасности Мс). В атрибуты файла при создании файла или при модификации неразмеченного ранее файла блоком 2 заносится метка Мс, которая при этом становится меткой Мсо размеченного файла. При обращении к размеченному файлу блоком 2 считывается из атрибутов файла, хранящихся в блоке 4, метка файла Мсо, к которому запрошен доступ, либо информация о том, что файл не размечен (метка отсутствует). Метка субъекта, запросившего доступ, Мс, метка файла, к которому запрошен доступ, Мсо поступают из блока 2 в блок 3, откуда транслируются вместе с заданным правилом сравнения меток в решающий блок 1. Решающий блок 1 проводит сравнение меток в соответствии с заданным правилом, на основании чего выдает на выход 6 соответствующий управляющий сигнал разрешения/запрета запрошенного доступа.

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

1. Простота администрирования. Администратору достаточно назначить метки безопасности (мандаты) лишь субъектам доступа (как правило, пользователям), и то только тем пользователям, доступ к созданным которыми файлам будет контролироваться, и назначить правила сравнения меток на отношении: больше, меньше, равно. И все! Никаких меток никаким объектам назначать не требуется, что на практике является крайне сложной задачей, поскольку назначать метки безопасности требуется всем объектам, в том числе и системным, которые не укладываются в схему категорирования обрабатываемой в КС информации.

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

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

Пример 3. Защита от запуска на защищаемой КС вредоносных программ.

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

При реализации дискреционного контроля доступа, см. пример 1.1 (аналогично можно реализовать и в рамках примера 1.2), таблица (матрица) доступа для решения этой задачи будет простейшей, см. Табл.5.

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

Для данного примера может быть упрощена учетная информация, автоматически записываемая в атрибуты файла при его создании - достаточно лишь указать признак того, что он создаваемый (был создан в процессе функционирования КС), который должен записываться (и соответственно, считываться) блоком 2 в/из блок 4 при создании файла.

Правило же, которое записывается в блок 2 - это запрет исполнения созданного (размеченного при создании/модификации неразмеченного ранее) файла.

Вот и все, а какая актуальнейшая задача защиты решается, при этом практически не требуется какого-либо администрирования системы.

Пример 4. Защита от несанкционированной модификации исполняемых объектов.

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

Рассмотрим это на примере защиты от несанкционированной модификации исполняемых файлов (ОС и приложений).

Идея защиты состоит в том, что исполняемый файл не должен модифицироваться в процессе работы системы (кстати сказать, на несанкционированную модификацию исполняемых файлов, в первую очередь системных, направлена масса существующих атак, в том числе и связанных с ошибками в интернет-браузерах). Это и есть то правило контроля доступа, которое записывается в блок 3. В блок 2 записывается правило разметки - автоматически размечаются те файлы, к которым запрашивается доступ на исполнение (размечаются, как исполняемые). Решение состоит в следующем. При обращении к файлу на исполнение (исполняемый файл идентифицируется именно из запроса, поступающего на вход 5 системы, что предотвращает ложные срабатывания), файл размечается (если ранее не был размечен) - в его атрибуты из блока 2 в блок 4 заносится признак исполняемого. Здесь опять же в качестве учетной информации можно ограничиться лишь записью в атрибуты файла признака исполняемого. При последующих обращениях к размеченному файлу, в соответствии с правилом, записанным в блок 3, блоком 1 будет предотвращена возможность его модификации (включая удаление и переименование).

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

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

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

Изобретение является промышленно применимым в части возможности технической реализации включенных в систему блока автоматической разметки файлов и блока хранения правил доступа к файлам.

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

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

Данное решение апробировано заявителем при построении опытного образца средства защиты информации.

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

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

В NTFS реализована и документирована (описанная штатная возможность ОС) поддержка альтернативных потоков данных (Alternate Data Streams) - была добавлена в NTFS для совместимости с файловой системой HFS от Macintosh, которая использовала поток ресурсов для хранения иконок и другой информации о файле. Использование альтернативных потоков позволяет хранить данные о файле скрытно от пользователя и не доступными обычными средствами. Проводник и другие приложения работают со стандартным потоком (файлом) и не могут читать данные из альтернативных потоков.

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

Создадим файл: C:\>echo Just a plan text file>sample.txt

Далее, используя двоеточие в качестве оператора, создадим альтернативный поток:

C:\>echo You can′t see me>sample.txt:secret.txt

Для просмотра содержимого можно использовать следующие команды:

С:\more<sample.txt-.secret.txt

или

С:\notepad sample.txt:secret.txt

Если все сделано правильно, то увидим текст: You can′t see me, при открытии из проводника данный текст виден не будет.

Альтернативный поток позволяет записывать в него неограниченное количество информации, при этом он «жестко» связан с базовым файлом (к которому прикрепляется поток) - может быть удален и будет удален только при удалении файла.

Замечание. Альтернативные потоки данных можно прикрепить не только к файлу, но и к папке.

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

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

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

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