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

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

ВВЕДЕНИЕ.

При реализации эффективной защиты конфиденциальных данных средства защиты информации от НСД и средства защиты данных (криптографическая защита и гарантированное удаление остаточной информации) должны рассматриваться как взаимодополняющие друг друга средства. Ошибочным будет утверждение, что можно обойтись лишь одной группой средств. Если мы попытаемся решить задачи защиты за счет хранения данных только в зашифрованном виде (ориентируясь исключительно на криптографические средства защиты), то неминуемо столкнемся с проблемой возможного несанкционированного доступа к информации во время ее обработки, когда она представлена в незашифрованном виде (например, информация в таком виде вводится с клавиатуры, отображается на экране монитора и т.д). Не обеспечим при этом и решение задачи защиты от несанкционированной модификации или уничтожения данных. Невозможно также без средств защиты от НСД гарантировать работоспособность и корректность функционирования средства шифрования, защиту ключевой информации и т.д. Если же мы попытаемся решить задачу защиты исключительно средствами защиты от НСД, то неминуемо столкнемся с проблемами сохранения данных на внешних накопителях (естественно, что никакие организационные меры не могут гарантированно обеспечить противодействие их несанкционированному прочтению). В рамках же существующей тенденции миниатюризации вычислительных средств (в корпоративных сетях все чаще используются ноутбуки) аналогичная задача защиты становится актуальной уже не только применительно к внешним накопителям, но и к вычислительному средству (к компьютеру) в целом. Да и кто поручится за то, что в системном средстве отсутствует критичная уязвимость, позволяющая преодолеть механизмы защиты от НСД, в этом случае остается только один способ защиты – шифрование данных. Обособленно в этом ряду находится задача гарантированного удаления остаточной информации (формально она относится к задаче защиты информации от НСД, однако, в широком смысле, остаточные данные – это не есть защищаемые информационные объекты). Актуальность данной задачи обусловливается тем, что при удалении файлового объекта (либо при записи в объект информации меньшего объема, чем исходный объем располагаемой в нем информации – при модификации файлового объекта) штатными средствами ОС (в том числе и ОС семейства Windows) собственно информация на диске остается (не удаляется) - осуществляется удаление (модификация) объекта из пространства имен файловой системы. Данная информация называется остаточной. Поэтому имеет место угроза получения прямого доступа к диску (заметим, не к файловому объекту, которого после удаления на диске не существует) - к остаточной информации на диске, что является функцией некоторых утилит. Иногда высказывается мнение, что ОС семейства Windows (естественно, технологии NT) реализует гарантированное удаление остаточной информации. Однако это не так – ОС обеспечивают лишь очистку (запись "0") в выделяемую системой область памяти на диске, при создании файла, с последующим размещением файла в этой области, т.е. ни о какой гарантированной очистке остаточной информации (при удалении или при модификации файла) здесь говорить в принципе не приходится.

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

Сразу в порядке замечания отметим, что авторы, представляющие коллектив разработчиков средств защиты информации, никогда не описывают в своих работах некие гипотетические (не апробированные на практике) решения. Все решения, о которых пойдет в статье речь, реализованы и апробированы в Комплексной системе защиты информации (КСЗИ) "Панцирь-К" для ОС Windows 2000/XP/2003.

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

• Что должно служить сущностью "объект доступа", другими словами, что должен представлять собой объект (или набор объектов), при сохранении в который данные должны шифроваться и/или гарантированно удаляться (естественно, что речь идет об автоматическом "прозрачном" для пользователя шифровании данных "на лету" при их сохранении в объект (и соответствующем расшифровании), реализуемого системным драйвером (аналогично и гарантированного удаления). Подходы, предполагающие реализацию шифрования и/или гарантированного удаления вручную пользователем, а уж тем более вопросы реализации этих функций на прикладном уровне (из конкретных приложений) рассматривать не будем, ведь мы же говорим об эффективных средствах защиты для корпоративных приложений, ориентированных на противодействие как внутренним, так и внешним ИТ-угрозам);
• Что должно служить сущностью "субъект доступа", другими словами, следует ли при принятии решения о шифровании (расшифровании) и/или гарантированного удаления данных при запросе доступа к объекту в принципе учитывать, и если да, то каким образом учитывать то, какой пользователь и каким процессом обращается к объекту. Другими словами, следует управлять тем, какие пользователи сохраняют данные в зашифрованном виде (соответственно их информация гарантированно удаляется) либо тем, в какие объекты данные сохраняются в шифрованном виде (соответственно, в каких объектах данные гарантированно удаляются);
• Что должно служить сущностью "право шифрования". Дело в том, что при построении СЗИ от НСД возможны два подхода к реализации разграничительной политики доступа к ресурсам: посредством назначения атрибутов, присваиваемых объектам (здесь можно говорить об атрибутах "шифрование" и "гарантированное удаление") или посредством назначения прав доступа к объектам для пользователей. Этот вопрос тесно связан с предыдущим;
• Как обеспечить коллективный доступ пользователей к зашифрованным данным. Это одна из ключевых задач для корпоративных приложений, состоящая в том, что данные должны располагаться на общем ресурсе (как правило, разделенные в сети файловые объекты), при этом к этим данным должно предоставляться право доступа нескольким пользователям, например, удаленно к файловому серверу с рабочих станций корпоративной сети. Соответственно, следует говорить и о гарантированном удалении данных в коллективно используемых ресурсах. Важным здесь является вопрос, учитывать ли какие-либо идентификационные данные пользователя (если да, то каким образом) при генерации ключа шифрования.

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

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

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

Несмотря на кажущуюся очевидность данных требований, на практике широко распространены средства с весьма ограниченными возможностями задания объектов защиты. Например, только локальный диск (так называемый, "файловый сейф") либо только локальные файловые объекты могут назначаться для шифрования данных. Другой пример: совсем уж странное решение реализуется в некоторых СЗИ от НСД в части гарантированного удаления остаточной информации – если активизируется этот режим, то гарантированно удаляются данные во всех файловых объектах (а как же совершенно не оправданное в этом случае дополнительное влияние на загрузку вычислительного ресурса?). Естественно, что подобные средства более просты в практической реализации, однако, следствием реализации подобных решений является их невысокая потребительская стоимость в корпоративных приложениях.

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

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

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

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

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

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

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

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

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

2. Вопросы реализации ключевой политики для корпоративных приложений.

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

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

- Ключ шифрования не должен храниться вместе с зашифрованными им данными;
- Ключ шифрования должен принадлежать пользователю для его ввода при доступе к зашифрованным данным;

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

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

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

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

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

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

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

На наш взгляд, возможность использования двух и более ключей для формирования ключа шифрования, гарантирующая, что криптостойкость хранения данных не снижается, состоит в следующем. Будем использовать два ключа шифрования – основной и дополнительный (дополнительных может быть несколько). Основной ключ – это ключ, который непосредственно используется для шифрования данных. Зашифруем этот ключ дополнительным ключом (естественно, что эта процедура реализуется автоматически). При этом дополнительный ключ отдадим пользователю (например, он может храниться на Flash-устройстве либо на ином носителе, также можно его формировать посредством ввода парольной фразы, из которой ключ будет автоматически сгенерирован). Основной ключ в зашифрованном виде расположим в недоступном пользователю месте (об этом далее), но обязательно в файловом объекте, т.к. он является объектом дополнительной защиты данных. Рассмотрим, как при этом будет выглядеть процедура шифрования (аналогично и расшифрования). Пользователь "представляет" (например, размещает носитель в разъеме) свой ключ (дополнительный), который загружается в оперативную память – при этом разрешается доступ процессу средства защиты к основному ключу, который автоматически расшифровывается и загружается в оперативную память. При загрузке основного ключа в память автоматически разрешается доступ к объектам, которые зашифрованы основным ключом. Далее при записи данных в объект они будут автоматически шифроваться (соответственно, расшифровываться при чтении) основным ключом. Что мы получаем в итоге. Для пользователя данная процедура абсолютно "прозрачна" (он и не знает, что используется несколько ключей). Если же им будут похищены данные, то при наличии только дополнительного ключа (который также может быть похищен пользователем), их будет не расшифровать. Очевидно, что то, насколько эффективна ключевая политика в части противодействия внутренним ИТ-угрозам, определяется тем, насколько защищен основной ключ от возможности его хищения и раскрытия пользователем. Следовательно, именно способом хранения основного ключа и должны различаться альтернативные ключевые политики.

Локальные политики хранения и ввода ключевой информации

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

Сетевая политика хранения и ввода ключевой информации

• Возможность реализации данной ключевой политики основывается на том, что объектом шифрования может являться разделенный ресурс, как на жестком диске, так и на внешнем накопителе, например, на Flash-устройстве. Эта возможность может быть использована при реализации ключевой политики следующим образом. Выделим некий общий ресурс для хранения основных ключей шифрования, например, пусть это будет компьютер администратора безопасности. Используем данный компьютер для реализации ключевого сервера (разделим необходимое количество файловых объектов в этом компьютере по числу основных ключей шифрования, используемых в корпоративной сети; для каждого ключа – свой объект). При этом можем разделить эти объекты как на жестком диске сервера, так и на Flash-устройстве (устаналивать которое в систему будет функцией администратор). Таким образом, отличительной особенностью данной политики является то, что основной ключ, собственно шифрующий данный, т.е. вводимый из файла (соответственно, из файла на внешнем носителе, например, располагаемого на Flash-устройстве), располагается на удаленном компьютере, и на этом компьютере разделен в сети. Дополнительные ключи, шифрующие основные ключи, вводятся пользователями на своих компьютерах, для автоматического чтения с сервера основных ключей шифрования. Так как основные ключи шифруются/расшифровываются дополнительными ключами собственно на рабочих станциях (не на ключевом сервере), то основные ключи хранятся на сервере (либо на внешнем носителе, с которого вводятся администратором на сервере) в зашифрованном виде, и в зашифрованном же виде передаются по сети.

Что мы при этом имеем? Администратору нет необходимости физически присутсвовать на каждом защищаемом компьютере для ввода второго ключа – ему достаточно просто включить сервер (или разместить в нем Flash-устройство с ключевой информацией, в зависимости от реализации). При этом хищение инсайдером компьютера не позволит раскрыть данные при наличии дополнительного ключа и средства защиты.

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

3. Вопросы корректности реализации средства защиты.

Поскольку пассматриваемое средство защиты должно быть реализовано в виде системного драйвера (как фильтр файловой системы), то одной из проблемм корректности реализации (впрочем, так же, как и для механизмов контроля доступа к ресурсам из состава СЗИ от НСД) здесь является проблема корректности идентификации защищаемого объекта (файлового объекта). Напомним, в чем здесь состоит проблема.В NTFS файловый объект может быть идентифицирован различными способами:

• Файловые объекты, задаваемые длинными именами, характеризуются той отличительной особенностью, что к ним можно обращаться, как по длинному, так и по короткому имени, например к каталогу "\Program files\" можно обратиться по короткому имени "\Progra~1\";
• Файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться), например, короткое имя для каталога "C:\Documents and Settings\USER1\Главное меню" выглядит как "C:\Docume~1\USER1\5D29~1\". К этим объектам также можно обратиться, как по длинному, так и по короткому имени;
• Файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.

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

Кстати говоря, заметим, что к системе может быть примонтирована не только NTFS, но и широко применяемые на практике DFS, FAT и др. Там свои особенности, поэтому, наверное, нет смысла ориентироваться только на один тип файловой системы.

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

В NTFS все данные, хранящиеся на томе, содержатся в файлах. Главная таблица файлов (MFT) занимает центральное место в структуре NTFS-тома. MFT реализована как массив записей о файлах, где каждая запись представляет собой совокупность пар атрибутов и их значений. Размер каждой записи фиксирован и равен 1 Кб. Если размер файла достаточно мал, чтобы поместиться в теле записи, то данные такого файла хранятся непосредственно в MFT.

В процессе работы системы, NTFS ведет запись в файл метаданных – файл журнала с именем $LogFile. NTFS использует его для регистрации всех операций, влияющих на структуру тома NTFS, как то: создание файла, удаление файла, расширение файла, урезание файла, установка файловой информации, переименование файла и изменение прав доступа к файлу. Информация, описывающая подобные транзакции, включает в себя копии записей из MFT и в дальнейшем используется для повтора или отмены изменений. Соответственно, если данные файла содержатся в записи MFT, то при каждом изменении, данные файла будут (в числе прочего) скопированы в файл журнала.

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

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

4. Дополнительные возможности средства защиты.

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

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

К стеганографическим методам защиты, например, можно отнести следующее:

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

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

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

В заключение еще раз отметим, что все сформулированные в работе требования не носят некий абстактный гипотетический характер. Все они в полном объеме выполнены при реализации Комплексной системы защиты информации (КСЗИ) "Панцирь-К" для ОС Windows 2000/XP/2003 (разработка ЗАО "НПП "Информационные технологии в бизнесе", сертификат ФСТЭК №1144 от 17.01.2006), а все реализующие их технические решения апробированы.