Полномочное (мандатное) разграничение доступа
Полномочное разграничение доступа штатными средствами ОС не реализовано, те или иные реализации данного подхода включены в состав сертифицированных СЗИ НСД.
Принцип полномочного разграничения доступа состоит в том, что сотрудникам присваивается уровень допуска к конфиденциальной информации, ресурсам АС присваивается уровень конфиденциальности, после чего система препятствует попыткам доступа к ресурсам, уровень конфиденциальности которых превышает уровень допуска сотрудника, а при открытии конфиденциальных ресурсов - попыткам переноса данных в ресурс с более низким уровнем конфиденциальности (контроль потоков данных).
Проблема в том, что требования РД ФСТЭК России (выпущенных в начале 1990-х годов) предусматривают контроль потоков данных на уровне ОС, применительно к запуску любого ПО и только в отношении файловых операций. Соблюдение этих требований в современных условиях порождает ряд проблем.
Во-первых, современные приложения открывают, как правило, не один файл, а несколько: файлы конфигурации, файлы со вспомогательными данными и т.п. При этом приложения могут быть построены таким образом, что для их корректной работы эти вспомогательные файлы должны быть доступны на запись. В условиях, когда функционирует полномочный доступ в режиме контроля потоков, система блокирует запись данных в такого рода файлы, что модулем самодиагностики и контроля исключений данного приложения может быть расценено как аварийная ситуация. Как минимум, требуется дополнительная нетривиальная настройка приложений, чтобы они могли относительно корректно работать в таких условиях.
Во-вторых, в настоящее время минимальной логической единицей хранения информации является не обязательно файл. Это может быть запись в базе данных, письмо в почтовом ящике корпоративной почтовой системы, и т.п. В этом случае разграничение доступа реализуется уже не ОС, а соответствующим серверным приложением, в которое не всегда технически возможно встроить дополнительные модули, реализующие полномочное разграничение доступа, во всяком случае, среди сертифицированных СЗИ НСД подобных модулей нет.
В-третьих, контроль потоков на уровне файловых операций позволяет блокировать
запись данных в не конфиденциальные файлы, и не в состоянии блокировать несанкционированный перенос данных другими способами, например с использованием прикладных интернет-протоколов, таких как FTP или HTTP.
В случаях, когда проявляются описанные проблемы, более целесообразно реализовывать
полномочный доступ не только и не столько средствами дополнительных СЗИ НСД, а
средствами системы электронного документооборота организации, заложив в
реализуемые бизнес-процессы контроль потоков уже на этапе проектирования системы.
Другой подход - заложить в функционирование приложений элементы системы управления правами (Digital Rights Management, DRM): в этом случае служебный заголовок файла (или записи в БД, или письма) содержит информацию о том, каким субъектам какие действия разрешены в отношении содержащихся в файле (записи, письме) данных. Эта информация, равно как и защищаемое содержание, зашифрована, и для получения доступа к ключам необходимо обратиться на сервер управления правами, функционирующий в составе АС. Для корректного функционирования системы управления правами, ее поддержка должна быть встроена в прикладное ПО.
Подобное решение предлагает компания Microsoft: сервер Microsoft DRM функционирует на платформе Windows Server 2003 или Windows Server 2008 (в последнем случае он включен в состав дистрибутива для лицензии Enterprise), клиентская часть устанавливается на Windows 2000 (все версии) или входит в состав Windows Vista (Business или Ultimate) и Windows Server 2008 (все версии кроме Core Edition), Windows XP Professional и Windows Server 2003 (все версии), в качестве прикладного ПО выступает Office 2003 или Office 2007. Проблема в том, что любые решения в области DRM обязательно используют криптографию, следовательно, для их внедрения в России необходимо, чтобы это ПО могло использовать сертифицированные криптографические средства (криптопровайдеры), а решений со встроенным сертифицированным криптопровайдером пока что не существует, остается надеяться на их появление.
Дата добавления: 2018-03-01; просмотров: 1205;