RU2816864C1 - Система и способ контроля доступа к данным приложений для изоляции данных одного приложения от данных другого приложения - Google Patents

Abstract

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

Description

Область техники

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

Уровень техники

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

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

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

Существуют различные подходы к реализации изолированных хранилищ данных. Первый подход к реализации изолированных хранилищ заключается использовании отдельного физического хранилища для каждого приложения. Каждое приложение находится на отдельном диске, это может быть жесткий диск (англ. hard disk drive, HDD) или твердотельный накопитель (англ. solid-state drive, SSD). Данный подход имеет несколько недостатков: во-первых, большие затраты на реализацию указанного подхода, например, если имеется тысяча приложений, то необходимо иметь и тысячу физических хранилищ, во-вторых, трудности добавления/удаления физического хранилища в существующей системе, в-третьих, аппаратное обеспечение может не поддерживать необходимое количество слотов расширения для физических хранилищ.

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

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

Вторым вариантом исполнения является избирательное управление доступом (англ. discretionary access control, DAC) - управление доступом субъектов к объектам на основе списков управления доступом или матрицы доступа. Также используются названия «дискреционное управление доступом», «контролируемое управление доступом» и «разграничительное управление доступом». Одним из преимуществ DAC является возможность гибкого управления доступом к ресурсам, устанавливая ограничения на то, кто имеет доступ к ресурсу и какие действия с ним можно выполнить. Указанная возможность достигается путем установки правил и политик. Также системы с избирательным управлением доступа разрешают пользователям полностью определять доступность своих ресурсов, что означает, что они могут случайно или преднамеренно передать доступ неавторизованным пользователям.

Третьим вариантом исполнения является мандатное управление доступом (англ. mandatory access control, MAC) - разграничение доступа субъектов к объектам, основанное на назначении метки конфиденциальности для информации, содержащейся в объектах, и выдаче официальных разрешений (допуска) субъектам на обращение к информации такого уровня конфиденциальности. Данный вариант сочетает в себе защиту и ограничение прав по отношению к компьютерным процессам, данным и системным устройствам, и для предотвращения их нежелательного использования. Недостатком данного подхода является сложность настройки, т.к. МАС используется совместно с другими моделями управления доступом, при этом могут возникать коллизии, из-за которых трудно определить, в каком слое системы безопасности произошел отказ в предоставлении доступа.

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

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

Раскрытие сущности изобретения

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

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

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

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

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

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

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

В еще одном варианте реализации системы, в которой по меньшей мере одно из приложений является недоверенным.

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

В еще одном варианте реализации системы образы дисков имеют формат расширения IMG.

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

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

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

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

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

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

В еще одно варианте реализации способа по меньшей мере одно из приложений является недоверенным.

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

В еще одно варианте реализации способа образы дисков имеют формат расширения IMG.

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

Краткое описание чертежей

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

Фиг. 1 представляет пример системы контроля доступа к данным приложений.

Фиг. 2 представляет пример способа контроля доступа к данным приложений.

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

Осуществление изобретения

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

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

Процесс (англ. process) - последовательность операций при выполнении программы или ее части вместе с используемыми данными, включает один или более потоков (англ. thread) и ассоциированные с ними системные ресурсы.

Межпроцессное взаимодействие (англ. inter-process communication, IPC) - механизм, предназначенный для обмена данными и синхронизации между различными процессами, которые работают на одной или нескольких компьютерных системах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена сообщениями (англ. message passing), синхронизации (англ. synchronization), разделяемой памяти (англ. shared memory) и удаленных вызовов процедур (англ. remote procedure calls, RPC).

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

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

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

Блочное устройство - вид файла устройств в UNIX/Linux-системах, обеспечивающий интерфейс к устройству, реальному или виртуальному, в виде файла в файловой системе.

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

Дескриптор файла (англ. file handle) - целое число без знака, с помощью которого процесс обращается к открытому файлу. Дескриптор файла создается при выполнении функции open(), pipe(), creat(), fcntl(). Процесс получает дескрипторы с помощью операций open()( и creat().

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

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

На Фиг. 1 представлена примерная схема системы контроля доступа к данным приложений (далее - система 100).

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

Система 100 для взаимодействия с приложениями включает виртуальные драйверы блочного устройства, при этом для взаимодействия с каждым приложением 130 используется определенный виртуальный драйвер блочного устройства 140 (не указано на Фиг. 1). Например, для взаимодействия с приложением 130а используется виртуальный драйвер блочного устройства 140а, а для взаимодействия с приложением 130б используется виртуальный драйвер блочного устройства 140б. Стоит отметить, что каждое приложение 130 содержит в себе локальную виртуальную файловую систему с реализацией файловой системы (на чертеже не указана) для того, чтобы взаимодействовать с определенным виртуальным драйвером блочного устройства 140 и интерпретировать получаемые данные от виртуальных драйверов блочного устройства 140.

Система 100, реализующаяся при помощи компьютерного устройства (например, такого как компьютер 20, представленный на Фиг. 3), предназначена для контроля доступа к данным приложений для изоляции данных одного приложения от данных другого приложения. Система 100 содержит по меньшей мере следующие компоненты: базу политик безопасности 110, монитор безопасности 120, виртуальные драйверы блочного устройства 140, в частности виртуальный драйвер блочного устройства 140а и виртуальный драйвер блочного устройства 140б, виртуальную файловую систему 150, драйвер хранилища данных 160, дисковое устройство 170, которое, в свою очередь, включает образы диска для каждого приложения 130, в частности образ диска 180а относится к приложению 130а, а образ диска 180б относится к приложению 130б.

В одном из вариантов реализации система 100 осуществляется на основе микроядерной архитектуры (например, Kaspersky OS).

В еще одном варианте реализации компоненты системы 100, а именно база политик безопасности 110, монитор безопасности 120, виртуальные драйверы блочного устройства 140, виртуальная файловая система 150 и драйвер хранилища данных 160, являются частью операционной системы, например, операционной системы Kaspersky OS.

База политик безопасности 110 предназначена для хранения политик безопасности. Политики безопасности, хранящиеся в базе политик безопасности 110, основаны по меньшей мере на одном из следующих принципов: базовые операции; конечный автомат; временной автомат; ролевое управление доступом; мандатный контроль целостности; регулярные выражения; дискретные события (англ. Discrete Event Systems, DES); мандатные ссылки; темпоральная логика (временная логика; англ. temporal logic). Примером политики безопасности, хранимой в базе политик безопасности 110, является политика, содержащая принцип «по умолчанию запрещено» (англ. default deny).

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

Также монитор безопасности 120 предназначен для определения запросов приложений 130 к виртуальным драйверам блочного устройства 140, открытия образов дисков 180 и получения дескрипторов на образы дисков 180 от виртуальной файловой системы 150 с последующей передачей дескрипторов в виртуальные драйверы блочного устройства 140. Для выполнения своего предназначения монитор безопасности 120 анализирует отправляемые компонентами системы 100 системные вызовы. В одном из вариантов реализации монитор безопасности 120 осуществляется с возможностью исполнения на аппаратном центральном процессоре 21 компьютерной системы 20. В еще одном варианте реализации монитор безопасности 120 является модулем ядра, а также его доверенным компонентом.

При запуске каждого приложения 130 устанавливается IPC-канал с указанным каждым приложением 130 и виртуальным драйвером блочного устройства 140, а также IPC-канал между указанным виртуальным драйвером блочного устройства 140 и виртуальной файловой системой 150 и между виртуальной файловой системой 150 и драйвером хранилища данных 160 согласно политикам безопасности. Так, при запуске приложения 130а устанавливается связь с виртуальным драйвером блочного устройства 140а, также при запуске приложения 130б устанавливается связь с виртуальным драйвером блочного устройства 140б. В свою очередь, при установлении IPC-каналов между каждым приложением 130 и соответствующим ему виртуальным драйвером блочного устройства 140, монитор безопасности 120 контролирует установление IPC-каналов между ними. Контроль установления IPC-каналов монитором безопасности 120 позволяет повысить защиту данных приложений путем определения правильной установки IPC-каналов. Например, при запуске приложения 130а установились IPC-каналы между приложением 130а и виртуальным драйвером блочного устройства 140а, виртуальным драйвером блочного устройства 140а и виртуальной файловой системой 150, а между виртуальной файловой системой 150 и драйвером хранилища данных 160 не установился IPC-канал, в таком случае монитор безопасности 120 проверяет действительно ли должен быть IPC-канал между виртуальной файловой системой 150 и драйвером хранилища данных 160. При этом монитор безопасности 120 контролирует чтобы IPC-каналы были установлены правильно, например, чтобы не установился IPC-канал между приложением 130а и виртуальным драйвером блочного устройства 140б или IPC-канал между приложением 130а и виртуальной файловой системой 150 минуя виртуальный драйвер блочного устройства 140а.

В предпочтительном варианте реализации система 100 основывается на модели безопасности «Defer to Kernel». (Secure Design Patterns, URL: https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15110.pdf (Secure Design Patterns Technical Report, CMU/SEI-2009-TR-010, ESC-TR-2009-010), стр. 6) Данная модель предполагает использование преимущества контроля разрешений на уровне ядра ОС, при этом контроль осуществляется при помощи политик безопасности. В этом случае база политик безопасности 110 содержит политики безопасности, которые разрешают взаимодействия связанных компонентов в виде чтения и записи и ограничивают взаимодействие не связанных компонентов. Например, политиками безопасности установлено, что виртуальный драйвер блочного устройства 140а может обращаться к дисковому устройству 170 через виртуальную файловую систему 150 и драйвер хранилища данных 160 на чтение и запись к образу диска 180а. В то же время виртуальному драйверу блочного устройства 140а разрешено взаимодействие только на чтение с образом диска 180б, предназначенным для приложения 130б. В случае если виртуальный драйвер блочного устройства 140а попытается взаимодействовать с образом диска 180б, предназначенным для приложения 130б не только на чтение, но и на запись, то в таком случае монитор безопасности 120 на основании установленной политики безопасности запретит совершать такое взаимодействие.

В частном варианте реализации система 100 основывается на модели безопасности «Distrustful Decomposition» (Secure Design Patterns, URL: https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15110.pdf (Secure Design Patterns Technical Report, CMU/SEI-2009-TR-010, ESC-TR-2009-010), стр. 16).

Виртуальные драйверы блочных устройств 140 предназначены для обращения через операции чтения и записи к образам дисков 180, расположенным на дисковом устройстве 170, при взаимодействии с монитором безопасности 120. В частном случае реализации виртуальные драйверы блочного устройства 140 осуществляют обращение через операции чтения или записи к образам дисков 180 только в случае запроса данных от приложений 130.

В предпочтительном варианте реализации системы 100 виртуальные драйверы блочного устройства 140 позволяют реализовать политику доступа к данным на дисковом устройстве 170 приложениям 130. Указанная политика доступа направлена на достижение целостности данных образов дисков 180. При этом виртуальный драйвер блочного устройства 140а относится к приложению 130а, а виртуальный драйвер блочного устройства 140б относится к приложению 130б.

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

В частном варианте реализации виртуальный драйвер блочного устройства 140а имеет доступ к образу диска 180а на чтение и запись и имеет доступ к другим образам дисков 180, в частности к образу диска 180б, только на чтение. Также и виртуальный драйвер блочного устройства 140б имеет доступ к образу диска 180б на чтение и запись и имеет доступ к другим образам дисков 180, в частности к образу диска 180а, только на чтение.

В другом частном варианте реализации виртуальный драйвер блочного устройства 140а имеет доступ к образу диска 180а на чтение и запись, но не имеет доступа на чтение и запись к другим образам дисков 180, в частности к образу диска 180б. Также и виртуальный драйвер блочного устройства 140б имеет доступ к образу диска 180б на чтение и запись, но не имеет доступа на чтение и запись к другим образам дисков 180, в частности к образу диска 180а.

Еще одним компонентом системы 100 является виртуальная файловая система 150, предназначенная для организации доступа для каждого виртуального драйвера блочного устройства 140 к соответствующим образам дисков 180, расположенным на дисковом устройстве 170, через драйвер хранилища данных 160. Политиками безопасности установлено, что приложениям 130 запрещено прямое взаимодействие с виртуальной файловой системой 150. Для виртуальной файловой системы 150 виртуальные драйверы блочного устройства 140 представлены как приложения, т.к. взаимодействие между виртуальной файловой системой 150 и виртуальными драйверами блочного устройства 140 осуществляется по IPC-каналу. Также виртуальная файловая система 150 осуществляет передачу дескрипторов монитору безопасности 120 на образы дисков 180.

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

Дисковым устройством 170 является машиночитаемый носитель данных, например, жесткий диск, твердотельный накопитель или флеш-память. В предпочтительном варианте реализации, образы дисков 180а и 180б находятся на одном разделе дискового устройства 170. При этом возможна реализация системы 100 с несколькими дисковыми устройствами 170. В частном варианте реализации системы 100 используются два дисковых устройства 170, каждое из которых содержит образы дисков 180 для приложений. Стоит отметить, что работа системы 100 с двумя и более дисковыми устройствами 170 не отличается от работы системы 100, в которой используется только одно дисковое устройство 170.

В предпочтительном варианте реализации образы дисков 180а и 180б имеют формат расширения.IMG (англ. disk image file). Файлы формата IMG представляют собой файлы образа диска, в которых хранятся данные приложений, идентичные тем, что хранятся на самом жестком диске. Образы дисков 180 служат для организации и хранения данных приложений 130. В свою очередь, под данными приложений выступают файловые системы, графические файлы, текстовые файлы, видеофайлы, звуковые файлы и т.д. При этом, помимо образов дисков 180 для приложений 130, на дисковом устройстве 170 могут находиться и другие файлы, не относящиеся к приложениям 130.

В другом частном варианте реализации образы дисков 180а и 180б имеют формат расширения.ISO, при этом возможен вариант реализации в котором образ диска 180а имеет формат расширения.img, а образ диска 180б имеет формат расширения.iso.

В частном варианте реализации на дисковом устройстве 170 образы дисков 180а и 180б находятся в разных разделах диска.

В частном варианте реализации системы 100 типы файловых систем для каждого из приложений 130 могут быть разными. Например, для одного приложения может использоваться тип файловой системы EXT4, а для другого приложения - файловая система VFAT, для еще одного приложения - EXT3, но не исключая варианта реализации системы, когда могут использоваться одинаковый тип файловой системы для нескольких приложений, например, EXT4.

Рассмотрим работу системы 100 на примере с двумя приложениями. Запускают приложения 130а и 130б, виртуальные драйверы блочного устройства 140а и 140б, виртуальную файловую систему 150, драйвер хранилища данных 160. Далее загружается драйвер хранилища данных 160 для выполнения операций ввода-вывода в дисковое устройство 170. Монитор безопасности 120 контролирует установление IPC-каналов между приложением 130а и виртуальным драйвером блочного устройства 140а, приложением 130б и виртуальным драйвером блочного устройства 140б, а также между виртуальными драйверами блочного устройства и виртуальной файловой системой 150 и виртуальной файловой системой 150 и драйвером хранилища данных 160.

После запуска всех компонентов системы 100 и установления IPC-каналов между ними приложения 130а и 130б отправляют запрос операции чтения или записи к виртуальным драйверам блочного устройства 140а и 140б на получение данных из образов дисков 180а и 180б. В свою очередь, монитор безопасности 120 определяет запросы приложений 130 к виртуальным драйверам блочного устройства 140а и 140б, после чего монитор безопасности 120 открывает образы дисков 180 на дисковом устройстве 170 и получает дескрипторы на открытые образы дисков 180а и 180б от виртуальной файловой системы 150. Монитор безопасности 120 передает полученные дескрипторы на открытые образы дисков 180а и 180б по IPC-каналу виртуальному драйверу блочного устройства 140а и виртуальному драйверу блочного устройства 140б. Получение дескрипторов монитором безопасности 120 и передача дескрипторов виртуальным драйверам блочного устройства 140а и 140б выполняются по IPC-каналу.

После того как монитор безопасности 120 передал дескрипторы на открытые образы дисков 180а и 180б упомянутым виртуальным драйверам блочного устройства, монитор безопасности 120 контролирует взаимодействие с открытыми образами дисков 180 и виртуальными драйверами блочного устройства 140 с учетом установленных политик безопасности. Например, в случае компрометации одного из виртуальных драйверов блочного устройства 140 в момент получения дескриптора от монитора безопасности 120 при попытке взаимодействия скомпрометированного виртуального драйвера блочного устройства 140 с каким-либо открытым образом диска 180 для выполнения операции чтения или записи, которая по умолчанию запрещена согласно политикам безопасности, монитор безопасности 120 запретит такое взаимодействие.

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

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

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

На Фиг. 2 представлен пример способа контроля доступа к данным приложений 200 (далее - способ 200). Представленный способ 200 реализуется с помощью компонентов системы 100, представленных при описании Фиг. 1.

При запуске каждого приложения 130 устанавливается IPC-канал с указанным приложением 130 и соответствующим ему виртуальным драйвером блочного устройства 140, а также IPC-канал между указанным виртуальным драйвером блочного устройства 140 и виртуальной файловой системой 150, и между виртуальной файловой системой 150 и драйвером хранилища данных 160 согласно политикам безопасности.

В частном примере реализации способа 200 приложение 130а является доверенным приложением, а приложение 130б является недоверенным приложением. Раскрытие понятий доверенное и недоверенное приложение представлено при описании Фиг. 1.

На шаге 210 определяют запуск по меньшей мере двух приложений 130, при этом для каждого приложения 130 хранят образ диска 180 на дисковом устройстве 170.

На шаге 220 при запуске каждого приложения устанавливают IPC-каналы между каждым приложением 130 и соответствующим ему виртуальным драйвером блочного устройства 140, а также каждым виртуальным драйвером блочного устройства 140 и виртуальной файловой системой 150. Так, устанавливают IPC-каналы между приложением 130а и виртуальным драйвером блочного устройства 140а, приложением 130б и виртуальным драйвером блочного устройства 140б, виртуальным драйвером блочного устройства 140а и виртуальной файловой системой 150, виртуальным драйвером блочного устройства 140б и виртуальной файловой системой 150. Далее устанавливают IPC-канал между виртуальной файловой системой 150 и драйвером хранилища данных 160, при этом драйвер хранилища данных 160 подключается к дисковому устройству 170. В свою очередь, при установлении IPC-каналов между каждым приложением 130 и соответствующим ему виртуальным драйвером блочного устройства 140 монитор безопасности 120 контролирует установление IPC-каналов между ними.

В частном варианте реализации способа 200 на дисковом устройстве 170 образы дисков, например, 180а и 180б находятся в разных разделах диска.

На шаге 230 при запросе доступа к данным каждым приложением 130 к соответствующему виртуальному драйверу блочного устройства 140 с помощью монитора безопасности 120 открывают образ диска 180, относящийся к соответствующему приложению 130 на дисковом устройстве 170. После чего получают от виртуальной файловой системы 150 дескриптор на указанный открытый образ диска 180 и передают полученный дескриптор по IPC-каналу в соответствующий виртуальный драйвер блочного устройства 140. Например, для виртуального драйвера блочного устройства 140а монитор безопасности 120 получает дескриптор на открытый образ диска 180а и, соответственно, для виртуального драйвера блочного устройства 140б монитор безопасности 120 получает дескриптор на открытый образ диска 180б. Запрос к дисковому устройству 170 осуществляют через взаимодействие с виртуальной файловой системой 150 и драйвером хранилища данных 160. На данном шаге контроль доступа к данным каждого приложения 130 осуществляют монитором безопасности 120 посредством определения от какого приложения 130 поступил запрос к образу диска 180 на основании политик безопасности. В свою очередь упомянутый контроль доступа повышает защиту от неправомерного доступа к данным приложений 130. Под неправомерным доступом понимается такой доступ к информации, который приводит к опасным последствиям, как уничтожение, блокирование, модификация и/или копирование. Одним из примеров попытки неправомерного доступа является запрос доступа к образам дисков 180а и 180б от приложения 130б для которого данные в образе диска 180а не предназначены, на основании политик безопасности монитор безопасности 120 не откроет образ диска 180а. При этом, возможен вариант, в котором приложение 130б запросит доступ к данным в образе диска 180а, но не запросит доступ к данным к своему образу диска 180б и в этом случае монитор безопасности 120 также не откроет образ диска 180а. Также в случае с приложением 130а когда приложение 130а осуществляет запрос данных из образа диска 180б, монитор безопасности 120 не откроет этот образ диска согласно политикам безопасности.

На шаге 240 при помощи виртуального драйвера блочного устройства 140 осуществляют доступ к данным открытого образа диска 180 при помощи полученного дескриптора, во время которого получают данные из образа диска 180, согласно полученному запросу от приложения 130 и передают полученные данные от виртуального драйвера блочного устройства 140 приложению 130. Запрос доступа к данным на дисковом устройстве 170 осуществляют путем операций чтения или записи. Например, виртуальный драйвер блочного устройства 140а осуществляет передачу операции чтения или записи от приложения 130а к образу диска 180а, соответственно, виртуальный драйвер блочного устройства 140б передает операцию чтения или записи от приложения 130б к образу диска 180б.

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

На шаге 250 при помощи приложения 130 осуществляют работу с полученными данными от виртуального драйвера блочного устройства 140.

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

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

Как показано на Фиг. 3, компьютерная система 20 включает в себя: центральный процессор 21, системную память 22 и системную шину 23, которая связывает разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, способную взаимодействовать с любой другой шинной архитектурой. Примерами шин являются: PCI, ISA, PCI-Express, HyperTranspor™, InfiniBand™, Serial ATA, I2C и другие подходящие соединения между компонентами компьютерной системы 20. Центральный процессор 21 содержит один или несколько процессоров, имеющих одно или несколько ядер. Центральный процессор 21 исполняет один или несколько наборов машиночитаемых инструкций, реализующих способы, представленные в настоящем документе. Системная память 22 может быть любой памятью для хранения данных и/или компьютерных программ, исполняемых центральным процессором 21. Системная память может содержать как постоянное запоминающее устройство (ПЗУ) 24, так и память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами компьютерной системы 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Компьютерная система 20 включает в себя одно или несколько устройств хранения данных, таких как одно или несколько извлекаемых запоминающих устройств 27, одно или несколько неизвлекаемых запоминающих устройств 28, или комбинации извлекаемых и неизвлекаемых устройств. Одно или несколько извлекаемых запоминающих устройств 27 и/или неизвлекаемых запоминающих устройств 28 подключены к системной шине 23 через интерфейс 32. В одном из вариантов реализации извлекаемые запоминающие устройства 27 и соответствующие машиночитаемые носители информации представляют собой энергонезависимые модули для хранения компьютерных инструкций, структур данных, программных модулей и других данных компьютерной системы 20. Системная память 22, извлекаемые запоминающие устройства 27 и неизвлекаемые запоминающие устройства 28 могут использовать различные машиночитаемые носители информации. Примеры машиночитаемых носителей информации включают в себя машинную память, такую как кэш-память, SRAM, DRAM, ОЗУ не требующую конденсатора (Z-RAM), тиристорную память (T-RAM), eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM; флэш-память или другие технологии памяти, такие как твердотельные накопители (SSD) или флэш-накопители; магнитные кассеты, магнитные ленты и магнитные диски, такие как жесткие диски или дискеты; оптические носители, такие как компакт-диски (CD-ROM) или цифровые универсальные диски (DVD); и любые другие носители, которые могут быть использованы для хранения нужных данных и к которым может получить доступ компьютерная система 20.

Системная память 22, извлекаемые запоминающие устройства 27 и неизвлекаемые запоминающие устройства 28, содержащиеся в компьютерной системе 20 используются для хранения операционной системы 35, приложений 37, других программных модулей 38 и программных данных 39. Компьютерная система 20 включает в себя периферийный интерфейс 46 для передачи данных от устройств ввода 40, таких как клавиатура, мышь, стилус, игровой контроллер, устройство голосового ввода, устройство сенсорного ввода, или других периферийных устройств, таких как принтер или сканер через один или несколько портов ввода/вывода, таких как последовательный порт, параллельный порт, универсальная последовательная шина (USB) или другой периферийный интерфейс. Устройство отображения 47, такое как один или несколько мониторов, проекторов или встроенных дисплеев, также подключено к системной шине 23 через выходной интерфейс 48, такой как видеоадаптер. Помимо устройств отображения 47, компьютерная система 20 оснащена другими периферийными устройствами вывода (на Фиг. 3 не показаны), такими как динамики и другие аудиовизуальные устройства.

Компьютерная система 20 может работать в сетевом окружении, используя сетевое соединение с одним или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 является рабочим персональным компьютером или сервером, который содержит большинство или все упомянутые компоненты, отмеченные ранее при описании сущности компьютерной системы 20, представленной на Фиг. 3. В сетевом окружении также могут присутствовать и другие устройства, например, маршрутизаторы, сетевые станции или другие сетевые узлы. Компьютерная система 20 может включать один или несколько сетевых интерфейсов 51 или сетевых адаптеров для связи с удаленными компьютерами 49 через одну или несколько сетей, таких как локальная компьютерная сеть (LAN) 50, глобальная компьютерная сеть (WAN), интранет и Интернет. Примерами сетевого интерфейса 51 являются интерфейс Ethernet, интерфейс Frame Relay, интерфейс SONET и беспроводные интерфейсы.

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

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

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

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

Claims (37)

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

• базу политик безопасности, предназначенную для хранения политик безопасности;

• монитор безопасности, предназначенный для:

а) контроля установления каналов межпроцессного взаимодействия (IPC-каналов) при запуске каждого приложения на основании политик безопасности;

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

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

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

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

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

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

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

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

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

5. Система по п. 1, в которой по меньшей мере одно из приложений является недоверенным.

6. Система по п. 1, в которой образы дисков находятся на одном разделе дискового устройства.

7. Система по п. 1, в которой образы дисков имеют формат расширения IMG.

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

9. Система по п. 1, в которой запрос доступа к данным осуществляют путем выполнения операций чтения или записи.

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

а) определяют запуск по меньшей мере двух приложений, при этом для каждого приложения хранят образ диска на дисковом устройстве;

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

в) при запросе доступа к данным каждым приложением к соответствующему виртуальному драйверу блочного устройства с помощью монитора безопасности:

• контролируют доступ посредством определения от какого приложения поступил запрос к образу диска на основании политик безопасности,

• открывают образ диска на дисковом устройстве, относящийся к соответствующему приложению,

• получают от виртуальной файловой системы дескриптор на указанный открытый образ диска,

• передают полученный дескриптор по IPC-каналу в виртуальный драйвер блочного устройства;

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

• получают данные из открытого образа диска согласно полученному запросу от приложения,

• передают полученные данные приложению;

д) осуществляют при помощи приложения работу с полученными данными от виртуального драйвера блочного устройства.

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

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

13. Способ по п. 10, в котором запрос доступа к данным осуществляют путем операций чтения или записи.

14. Способ по п. 10, в котором по меньшей мере одно из приложений является недоверенным.

15. Способ по п. 10, в котором образы дисков находятся на одном разделе диска.

16. Способ по. 10, в котором образы дисков имеют формат расширения IMG.

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