Новые принципы контроля доступа к создаваемым файловым объектам
Ожидает приглашения
В эффективной защите, в том числе, в реализации контроля доступа, если мы рассматриваем задачу защиты информации от несанкционированного доступа, в первую очередь, нуждаются создаваемые файловые объекты, к ним, в первую очередь, и должна реализовываться разграничительная политика доступа. Однако, на момент задания разграничительной политики доступа администратором, этих объектов еще попросту нет. Возникает резонный вопрос – как назначить к ним правила доступа?
Классификация объектов доступа
Введем принципиально важную классификацию объектов доступа, применительно к рассматриваемым вопросам реализации контроля доступа. Будем их подразделять на статичные и создаваемые в процессе работы системы.
Определение. Под статичными объектами доступа будем понимать объекты, присутствующие в системе на момент реализации администратором разграничительной политики доступа субъектов к объектам.
Статичные файловые объекты – это, прежде всего, системные объекты — исполняемые файлы и файлы настроек ОС и приложений.
Определение. Под создаваемыми в процессе функционирования системы (или далее, под создаваемыми) объектами доступа будем понимать объекты, отсутствующие в системе на момент реализации администратором разграничительной политики доступа субъектов к объектам, создаваемым пользователями впоследствии, уже в процессе функционирования системы.
Создаваемые же файловые объекты – это объекты создаваемые пользователями непосредственно во время их работы на компьютере и предназначенные, в первую очередь, для хранения обрабатываемой информации, в том числе, конфиденциальной.
Принципы контроля доступа к создаваемым объектам
Основное противоречие при реализации контроля доступа к создаваемым объектам состоит в том, что в разграничительной политике доступа присутствуют и сущность субъект, и сущность объект – разграничиваются права доступа субъектов к объектам. Однако на момент назначения администратором разграничений, создаваемые в процессе работы пользователей файлы, доступ к которым и должен контролироваться, в первую очередь, т.к. в них записывается обрабатываемая на компьютере информация, в том числе, конфиденциальная, т.к. они предназначены для хранения обрабатываемой на компьютере информации, еще отсутствуют. К чему тогда разграничивать доступ субъектов, если объекты отсутствуют?
Рассмотрим существующий подход к реализации контроля доступа к создаваемым объектам (на примере файлов), состоящий в следующем. Поскольку на момент задания разграничительной политики доступа создаваемых в процессе работы пользователей файлов еще не существует в системе, администратором заранее создаются хранилища (своего рода «контейнеры») для последующего хранения создаваемых в процессе работы пользователей файлов. Т.е. администратором создаются папки (контейнеры), к которым и разграничивается доступ. Объект доступа «файл» в общем случае при этом исчезает из разграничительной политики доступа. Разграничительной политикой для созданных папок-контейнеров, пользователи «принуждаются» создавать свои файлы только в определенных папках. Созданные файлы наследуют разграничения, установленные для папок. По средством же реализации разграничительной политики доступа к папкам-контейнерам для пользователей разграничивается доступ и к созданным в процессе функционирования системы файлам.
Естественно, что подобный подход (а именно он сегодня и используется на практике) не только весьма не логичен (если речь не идет о системных объектах), но и обусловливает принципиальное усложнение реализации разграничительной политики доступа, а в ряде случае, и к невозможности ее корректной реализации. Достаточно задуматься о том, какие действия потребуется выполнить администратору, чтобы, например, изолировать обработку информации десятком приложений – для каждого субъекта потребуется создавать свою папку, далее разграничивать к созданным папкам права доступа. Соответственно придется разграничивать доступ и к иным папкам, в частности, к системным. А не разделяемые системой и приложениями папки – их потребуется разделить отдельным механизмом защиты, при этом опять же создать соответствующие дополнительные папки, и т.д. Все это приводит не только к многократному усложнению задачи администрирования, как следствие, к ошибкам администрирования (что представляет собою весьма актуальную в данном случае угрозу администрирования), но и к невозможности гарантированно построить корректную разграничительную политику доступа к файловым объектам в общем случае. Возможность же корректной реализации в данном случае (ввиду наличия системных объектов) мандатного контроля доступа вообще ставится под сомнение.
Определение. Под контролем доступа к создаваемым объектам понимается контроль доступа, основанный на исключении сущности «объект доступа» из разграничительной политики доступа (объект доступа не используется при задании правил доступа), за счет реализации в системе автоматической разметки создаваемых объектов, используемой для последующего контроля к ним доступа.
Принципы контроля доступа к создаваемым файловым объектам основаны на исключении сущности «объект доступа» из разграничительной политики доступа к файловым объектам, как таковой (ввиду ее отсутствия на момент задания прав доступа администратором), и состоят они в следующем:
1. Сущность «объект» исключается из схемы контроля доступа, при реализации разграничительной политики используются две сущности: идентификатор (учетная информация) субъекта, создавшего объект, и идентификатор субъекта, запрашивающего доступ к созданному объекту.
2. Правила доступа устанавливаются между сущностями: «субъект доступа (учетная информация), запрашивающий доступ к объекту» и «субъект доступа (учетная информация), создавший этот объект».
3. При создании субъектом нового объекта, этим объектом наследуется учетная информация субъекта доступа, создавшего этот объект.
4. При запросе доступа к любому объекту, диспетчер доступа анализирует наличие, а при наличии, содержимое унаследованной объектом учетной информации создавшего его субъекта доступа. При наличии, анализирует заданные правила доступа, в результате чего предоставляет запрошенный субъектом доступ, либо отказывает в нем. При отсутствии – анализирует правило доступа к неразмеченным (не унаследовавшим учетную информацию субъекта) объектам.
Замечание. В общем случае данные принципы контроля доступа, предполагающие автоматическую разметку объектов при их создании – наследование объектом учетной информация субъекта доступа, могут реализовываться не только в отношении создаваемых объектов. Автоматически размечаться по определенным правилам могут и статичные объекты, например, системные файлы, что позволяет решать достаточно важные задачи защиты системных объектов, например, могут автоматически размечаться исполняемые файлы (при их запуске) с предотвращением задаваемыми правилами доступа возможности их удаления или модификации.
В двух словах остановимся на тему того, где хранить унаследованную файлом (в качестве объекта доступа рассматриваем файл) учетную информацию субъекта доступа, создавшего этот файл. Возможны различные варианты, каждый из которых имеет свои ограничения по использованию.
Вариант хранения подобной информации в отдельной таблице (в отдельном файле) не стоит рассматривать по двум причинам. Во-первых, подобная таблица очень быстро разрастется, и ее анализ диспетчером при каждом запросе доступа приведет к существенному влиянию на загрузку вычислительного ресурса. Во-вторых, при утере подобной таблицы, восстановление разграничительной политики доступа станет крайне трудоемкой работой.
Другой вариант – это хранение учетной информации в дополнительных (резервных) атрибутах. Подобную возможность предоставляет, например, файловая система NTFS – возможность использования альтернативных потоков. Однако, при сохранении подобным образом размеченного файла в файловой системе, не предоставляющей рассмотренной возможности, например, FAT, учетная информация, унаследованная файлом, будет утеряна.
Достаточно интересен вариант сохранения учетной информации непосредственно в файле. Интересен он своей общностью – учетная информация будет передаваться (принадлежать файлу) при любом способе передачи файла (сохранение в любой файловой системе, по сети и т.д.). Это позволит реализовать разграничительную политику доступа не на одном отдельном компьютере, а единую разграничительную политику доступа в рамках всей распределенной информационной системы, т.к. любым способом перенесенный файл с одного компьютера на другой, унаследует при переносе информации учетную информацию создавшего его субъекта, как следствие, доступ к нему может быть разграничен на любом компьютере. Особенно это интересно при реализации в информационной системе мандатного (сессионного) метода контроля доступа. Однако данный способ имеет и существенный недостаток. В случае его реализации, файл при сохранении искажается – модифицируется диспетчером доступа, который записывает непосредственно в файл учетную информацию (в том числе, метку безопасности) создавшего файл субъекта. Как следствие, на компьютере, на котором не установлено средство защиты, реализующее метод контроля доступа к создаваемым файловым объектам (например, при обработке открытой информации, файлы могут обрабатываться, как на защищенных, так и на незащищенных, в том числе, на домашних компьютерах), подобный файл будет прочитан в искаженном виде (модифицированный диспетчером доступа при записи). Таким образом, данный способ разметки файлов предполагает возможность их обработки только на защищенных компьютерах.
Заметим, что данный недостаток отсутствует при сохранении учетной информации в дополнительных (резервных) атрибутах, т.к. система, не использующая эти атрибуты, не будет их запрашивать.
Можем сделать следующий вывод. В случае, когда контроль доступа к создаваемым объектам реализуется в рамках построения процессной модели контроля доступа – для разделения прав доступа к создаваемым объектам на одном и том же компьютере между различными процессами (приложениями) без необходимости их дополнительной криптографической защиты, целесообразно хранение учетной информации субъекта доступа в дополнительных (резервных) атрибутах, в случае же, когда используется криптографическая защита создаваемых объектов, а, в первую очередь, в такой защите нуждаются файлы, создаваемые на внешних накопителях и/или передаваемые по сети, уже имеет смысл реализация хранения учетной информации субъекта доступа непосредственно в файле.
Отметим, что существенным достоинством в обоих случаях является непосредственная привязка учетной информации субъекта, создавшего объект, к объекту – хранится либо в атрибутах объекта, либо непосредственно в объекте, что снимает проблему корректности идентификации объекта доступа при анализе запроса доступа имеющую место для методов контроля доступа субъектов к статичным объектам при хранении правил доступа (матрицы доступа) в отдельном объекте.
Список литературы.
1. Щеглов К.А., Щеглов А.Ю. Принцип и метод дискреционного контроля доступа к создаваемым файловым объектам // Вопросы защиты информации. — 2012. — Вып. 96. — № 1. — С. 30-38.
2. Щеглов К.А., Щеглов А.Ю. Принцип и метод мандатного контроля доступа к создаваемым файловым объектам // Вопросы защиты информации. — 2012. — Вып. 96. — № 1. — С. 40-44.
3. Щеглов К.А., Щеглов А.Ю. Принцип и методы контроля доступа к создаваемым файловым объектам // Вестник компьютерных и информационных технологий. — 2012. — № 7. — С. 43-47.
4. Щеглов К.А., Щеглов А.Ю. Система защиты от запуска вредоносных пргограмм // Вестник компьютерных и информационных технологий. — 2013. — № 5. — С. 38-43.
Классификация объектов доступа
Введем принципиально важную классификацию объектов доступа, применительно к рассматриваемым вопросам реализации контроля доступа. Будем их подразделять на статичные и создаваемые в процессе работы системы.
Определение. Под статичными объектами доступа будем понимать объекты, присутствующие в системе на момент реализации администратором разграничительной политики доступа субъектов к объектам.
Статичные файловые объекты – это, прежде всего, системные объекты — исполняемые файлы и файлы настроек ОС и приложений.
Определение. Под создаваемыми в процессе функционирования системы (или далее, под создаваемыми) объектами доступа будем понимать объекты, отсутствующие в системе на момент реализации администратором разграничительной политики доступа субъектов к объектам, создаваемым пользователями впоследствии, уже в процессе функционирования системы.
Создаваемые же файловые объекты – это объекты создаваемые пользователями непосредственно во время их работы на компьютере и предназначенные, в первую очередь, для хранения обрабатываемой информации, в том числе, конфиденциальной.
Принципы контроля доступа к создаваемым объектам
Основное противоречие при реализации контроля доступа к создаваемым объектам состоит в том, что в разграничительной политике доступа присутствуют и сущность субъект, и сущность объект – разграничиваются права доступа субъектов к объектам. Однако на момент назначения администратором разграничений, создаваемые в процессе работы пользователей файлы, доступ к которым и должен контролироваться, в первую очередь, т.к. в них записывается обрабатываемая на компьютере информация, в том числе, конфиденциальная, т.к. они предназначены для хранения обрабатываемой на компьютере информации, еще отсутствуют. К чему тогда разграничивать доступ субъектов, если объекты отсутствуют?
Рассмотрим существующий подход к реализации контроля доступа к создаваемым объектам (на примере файлов), состоящий в следующем. Поскольку на момент задания разграничительной политики доступа создаваемых в процессе работы пользователей файлов еще не существует в системе, администратором заранее создаются хранилища (своего рода «контейнеры») для последующего хранения создаваемых в процессе работы пользователей файлов. Т.е. администратором создаются папки (контейнеры), к которым и разграничивается доступ. Объект доступа «файл» в общем случае при этом исчезает из разграничительной политики доступа. Разграничительной политикой для созданных папок-контейнеров, пользователи «принуждаются» создавать свои файлы только в определенных папках. Созданные файлы наследуют разграничения, установленные для папок. По средством же реализации разграничительной политики доступа к папкам-контейнерам для пользователей разграничивается доступ и к созданным в процессе функционирования системы файлам.
Естественно, что подобный подход (а именно он сегодня и используется на практике) не только весьма не логичен (если речь не идет о системных объектах), но и обусловливает принципиальное усложнение реализации разграничительной политики доступа, а в ряде случае, и к невозможности ее корректной реализации. Достаточно задуматься о том, какие действия потребуется выполнить администратору, чтобы, например, изолировать обработку информации десятком приложений – для каждого субъекта потребуется создавать свою папку, далее разграничивать к созданным папкам права доступа. Соответственно придется разграничивать доступ и к иным папкам, в частности, к системным. А не разделяемые системой и приложениями папки – их потребуется разделить отдельным механизмом защиты, при этом опять же создать соответствующие дополнительные папки, и т.д. Все это приводит не только к многократному усложнению задачи администрирования, как следствие, к ошибкам администрирования (что представляет собою весьма актуальную в данном случае угрозу администрирования), но и к невозможности гарантированно построить корректную разграничительную политику доступа к файловым объектам в общем случае. Возможность же корректной реализации в данном случае (ввиду наличия системных объектов) мандатного контроля доступа вообще ставится под сомнение.
Определение. Под контролем доступа к создаваемым объектам понимается контроль доступа, основанный на исключении сущности «объект доступа» из разграничительной политики доступа (объект доступа не используется при задании правил доступа), за счет реализации в системе автоматической разметки создаваемых объектов, используемой для последующего контроля к ним доступа.
Принципы контроля доступа к создаваемым файловым объектам основаны на исключении сущности «объект доступа» из разграничительной политики доступа к файловым объектам, как таковой (ввиду ее отсутствия на момент задания прав доступа администратором), и состоят они в следующем:
1. Сущность «объект» исключается из схемы контроля доступа, при реализации разграничительной политики используются две сущности: идентификатор (учетная информация) субъекта, создавшего объект, и идентификатор субъекта, запрашивающего доступ к созданному объекту.
2. Правила доступа устанавливаются между сущностями: «субъект доступа (учетная информация), запрашивающий доступ к объекту» и «субъект доступа (учетная информация), создавший этот объект».
3. При создании субъектом нового объекта, этим объектом наследуется учетная информация субъекта доступа, создавшего этот объект.
4. При запросе доступа к любому объекту, диспетчер доступа анализирует наличие, а при наличии, содержимое унаследованной объектом учетной информации создавшего его субъекта доступа. При наличии, анализирует заданные правила доступа, в результате чего предоставляет запрошенный субъектом доступ, либо отказывает в нем. При отсутствии – анализирует правило доступа к неразмеченным (не унаследовавшим учетную информацию субъекта) объектам.
Замечание. В общем случае данные принципы контроля доступа, предполагающие автоматическую разметку объектов при их создании – наследование объектом учетной информация субъекта доступа, могут реализовываться не только в отношении создаваемых объектов. Автоматически размечаться по определенным правилам могут и статичные объекты, например, системные файлы, что позволяет решать достаточно важные задачи защиты системных объектов, например, могут автоматически размечаться исполняемые файлы (при их запуске) с предотвращением задаваемыми правилами доступа возможности их удаления или модификации.
В двух словах остановимся на тему того, где хранить унаследованную файлом (в качестве объекта доступа рассматриваем файл) учетную информацию субъекта доступа, создавшего этот файл. Возможны различные варианты, каждый из которых имеет свои ограничения по использованию.
Вариант хранения подобной информации в отдельной таблице (в отдельном файле) не стоит рассматривать по двум причинам. Во-первых, подобная таблица очень быстро разрастется, и ее анализ диспетчером при каждом запросе доступа приведет к существенному влиянию на загрузку вычислительного ресурса. Во-вторых, при утере подобной таблицы, восстановление разграничительной политики доступа станет крайне трудоемкой работой.
Другой вариант – это хранение учетной информации в дополнительных (резервных) атрибутах. Подобную возможность предоставляет, например, файловая система NTFS – возможность использования альтернативных потоков. Однако, при сохранении подобным образом размеченного файла в файловой системе, не предоставляющей рассмотренной возможности, например, FAT, учетная информация, унаследованная файлом, будет утеряна.
Достаточно интересен вариант сохранения учетной информации непосредственно в файле. Интересен он своей общностью – учетная информация будет передаваться (принадлежать файлу) при любом способе передачи файла (сохранение в любой файловой системе, по сети и т.д.). Это позволит реализовать разграничительную политику доступа не на одном отдельном компьютере, а единую разграничительную политику доступа в рамках всей распределенной информационной системы, т.к. любым способом перенесенный файл с одного компьютера на другой, унаследует при переносе информации учетную информацию создавшего его субъекта, как следствие, доступ к нему может быть разграничен на любом компьютере. Особенно это интересно при реализации в информационной системе мандатного (сессионного) метода контроля доступа. Однако данный способ имеет и существенный недостаток. В случае его реализации, файл при сохранении искажается – модифицируется диспетчером доступа, который записывает непосредственно в файл учетную информацию (в том числе, метку безопасности) создавшего файл субъекта. Как следствие, на компьютере, на котором не установлено средство защиты, реализующее метод контроля доступа к создаваемым файловым объектам (например, при обработке открытой информации, файлы могут обрабатываться, как на защищенных, так и на незащищенных, в том числе, на домашних компьютерах), подобный файл будет прочитан в искаженном виде (модифицированный диспетчером доступа при записи). Таким образом, данный способ разметки файлов предполагает возможность их обработки только на защищенных компьютерах.
Заметим, что данный недостаток отсутствует при сохранении учетной информации в дополнительных (резервных) атрибутах, т.к. система, не использующая эти атрибуты, не будет их запрашивать.
Можем сделать следующий вывод. В случае, когда контроль доступа к создаваемым объектам реализуется в рамках построения процессной модели контроля доступа – для разделения прав доступа к создаваемым объектам на одном и том же компьютере между различными процессами (приложениями) без необходимости их дополнительной криптографической защиты, целесообразно хранение учетной информации субъекта доступа в дополнительных (резервных) атрибутах, в случае же, когда используется криптографическая защита создаваемых объектов, а, в первую очередь, в такой защите нуждаются файлы, создаваемые на внешних накопителях и/или передаваемые по сети, уже имеет смысл реализация хранения учетной информации субъекта доступа непосредственно в файле.
Отметим, что существенным достоинством в обоих случаях является непосредственная привязка учетной информации субъекта, создавшего объект, к объекту – хранится либо в атрибутах объекта, либо непосредственно в объекте, что снимает проблему корректности идентификации объекта доступа при анализе запроса доступа имеющую место для методов контроля доступа субъектов к статичным объектам при хранении правил доступа (матрицы доступа) в отдельном объекте.
Список литературы.
1. Щеглов К.А., Щеглов А.Ю. Принцип и метод дискреционного контроля доступа к создаваемым файловым объектам // Вопросы защиты информации. — 2012. — Вып. 96. — № 1. — С. 30-38.
2. Щеглов К.А., Щеглов А.Ю. Принцип и метод мандатного контроля доступа к создаваемым файловым объектам // Вопросы защиты информации. — 2012. — Вып. 96. — № 1. — С. 40-44.
3. Щеглов К.А., Щеглов А.Ю. Принцип и методы контроля доступа к создаваемым файловым объектам // Вестник компьютерных и информационных технологий. — 2012. — № 7. — С. 43-47.
4. Щеглов К.А., Щеглов А.Ю. Система защиты от запуска вредоносных пргограмм // Вестник компьютерных и информационных технологий. — 2013. — № 5. — С. 38-43.