Вы находитесь в разделе Типовых решений систем безопасности
Защита персональных данныхНазначение и состав системы Система предназначена для защиты конфиденциальных данных, обрабатываемых на автономных компьютерах и на компьютерах в составе корпоративной сети; сохраняемых на локальных и удаленных (разделенных в сети) жестких дисках и внешних устройствах, передаваемых по сети при доступе к удаленным (разделенным) ресурсам. Система реализована программно, содержит в своем составе системный драйвер и интерфейсный модуль. Все возможности защиты, предоставляемые СЗД, реализованы собственными средствами СЗД (не использованы встроенные механизмы ОС). 2. Основные механизмы защиты данных СЗД реализует шифрование данных на лету, автоматическое гарантированное удаление остаточной информации, разграничение прав доступа к защищаемым объектам, скрытие защищаемых объектов файловой системы. 3. Основное отличительное свойство системы Защищаемыми объектами являются любые (назначаемые администратором) файловые объекты – логические диски, каталоги, подкаталоги, файлы (для задания объектов может использоваться механизм масок), как на жестком диске, так и на внешних носителях, как локальные, так и удаленные (разделенные в сети). 4. Возможности основных механизмов защиты:
Базовые требования к реализации системы защиты данных Для формирования данных требований необходимо определиться с ответами на следующие вопросы:
Рассмотрим эти вопросы по порядку, при этом будем учитывать, во-первых, что обе процедуры, и шифрование, и гарантированное удаление весьма ресурсоемки и оказывают влияние на загрузку вычислительного ресурса (даже при их реализации на уровне системного драйвера, в случае же реализации их на уровне приложения загрузка вычислительного ресурса возрастает в разы), во-вторых, на одном вычислительном средстве в корпоративных приложениях, как правило, обрабатывается как открытая, так и конфиденциальная информация (причем, подчас, конфиденциальная информация также может категорироваться), т.е. далеко не все данные следует дополнительно защищать средствами шифрования и гарантированного удаления. Различные по категории конфиденциальности данные должны храниться в различных файловых объектах (только в этом случае могут быть реализованы различные режимы их обработки), причем, как на жестком диске, так и на внешних накопителях, причем как на локальных, так и на разделенных в сети (при этом не обеспечить коллективный доступ к данным – без возможности разделения файловых объектов в сети) . Основным объектом реализации разграничительной политики доступа к ресурсам является “папка”. Что касается внешних накопителей (например, Flash-устройств), то подчас на них разрешается записывать информацию только в зашифрованном виде, т.е. в этом случае объектом шифрования должен служить диск (однако, может разрешаться в зависимости от типа информации на одном внешнем накопителе сохранять данные, как в открытом, так и в шифрованном виде, тогда объектом шифрования вновь становится папка, например, каталог на накопителе). Папка является и обязательным объектом шифрования при использовании разделяемого ресурса (например, жесткого диска на сервере) при реализации коллективного доступа к данным в корпоративной сети. В некоторых конкретных случаях может потребоваться шифрование и отдельного файла, в частности, вся база данных может располагаться в отдельном файле. Не смотря на частность данных случаев, их возможность – объектом шифрования является файл, также должна быть реализована в средстве защиты. Требование к реализации. Объектами криптографической защиты и гарантированного удаления остаточной информации для корпоративных приложений должны являться объекты любого уровня иерархии (диск, папка (каталог, подкаталог), файл) на жестком диске и на внешних накопителях, причем как на локальных, так и на разделенных в сети. При этом средством защиты должна предоставляться возможность задания любого набора объектов (например, несколько каталогов на выбор, включая разделенные в сети) в качестве объектов криптографической защиты и гарантированного удаления остаточной информации Несмотря на кажущуюся очевидность данных требований, на практике широко распространены средства с весьма ограниченными возможностями задания объектов защиты, например, только локальный диск (так называемый, файловый сейф), либо только локальные файловые объекты могут назначаться для шифрования данных, или, например, совсем уж странное решение реализуется в некоторых средствах защиты в части гарантированного удаления остаточной информации – если активизируется этот режим, то гарантированно удаляются данные во всех файловых объектах (а как же совершенно не оправданное в этом случае дополнительное влияние на загрузку вычислительного ресурса?). Естественно, что подобные средства более просты в практической реализации, однако, следствием реализации подобных решений является их невысокая потребительская стоимость в корпоративных приложениях. Перейдем к рассмотрению следующих двух очень важных взаимосвязанных вопросов. Следует ли учитывать каким-либо образом сущность пользователь при построении схемы защиты, следовательно, дополнительная защита должна являться привилегией пользователя (рассматриваться как его право), либо объекта (рассматриваться, как дополнительный атрибут файлового объекта). Заметим, что права доступа к объектам в корпоративных приложениях следует рассматривать, как принадлежность пользователя, а не как атрибут файлового объекта (именно такой подход реализован в КСЗИ Панцирь-К для ОС Windows 2000/XP/200 . В данном же случае, все наоборот. Особенностью корпоративных приложений является то, что один и тот же пользователь должен обрабатывать на одном компьютере, как открытую, так и конфиденциальную информацию (если только открытую, то отсутствует потребность в дополнительной защите данных, а только конфиденциальную – на практике, как правило, не бывает). Следовательно, если дополнительную защиту данных рассматривать, как привилегию пользователя (т.е. для учетной записи устанавливать соответствующий режим сохранения и удаления (модификации) данных), то в корпоративных приложениях это будет означать, что все данные (как открытые, так и конфиденциальные) пользователя следует шифровать и гарантированно удалять. Это бессмысленно! Следовательно, шифрование и гарантированное удаление необходимо рассмаривать не как привилегию пользователя (учетной записи), а как свойство объекта, которое определяется соответствующими дополнительными атрибутами: шифрование и гарантированное удаление, присваиваемыми объектам – при сохранении данных в этот объект они автоматически шифруются, при удалении (модификации) объекта данные гарантированно удаляются. Требование к реализации. Возможность дополнительной защиты данных методами шифрования и гарантированного удаления необходимо рассмаривать как свойство объекта, которое определяется соответствующими дополнительными атрибутами: шифрование и гарантированное удаление, устанавливаемыми для дополнительно защищаемого объекта. Теперь о коллективном доступе к ресурсам. Это очень важная функциональная возможность. Без ее практической реализации невозможно обеспечить не только общие для пользователей файловые хранилища, но и принципиально организовать обмен защищаемыми данными через файловую систему, причем не только в сети, но и локально, на одном компьютере. Коллективный доступ к ресурсам априори возможен лишь в том случае, когда такая сущность, как ключ шифрования едина (ключ одинаковый) для пользователей, имеющих право доступа к коллективно используемому ресурсу. С учетом сказанного можем сделать два очень важных вывода, во-первых, средство защиты должно обеспечивать возможность задания различных ключей шифрования для различных дополнительно защищаемых объектов (в том числе и на одном компьютере) – в пределе, для каждого объекта свой ключ шифрования, во-вторых, ключ шифрования ни коим образом не должен генерироваться на основе идентификационных данных (идентификатор и пароль) пользователей, т.к. в противном случае, эти данные должны совпадать для учетных записей, под которыми разрешен доступ к коллективно используемым объектам (что недопустимо). Заметим, что несмотря на данное, казалось бы, очевидное требование, подобные решения, реализованные на практике, существуют. Требование к реализации. Средство защиты должно обеспечивать возможность задания различных ключей шифрования для различных дополнительно защищаемых объектов (в том числе и на одном компьютере) – в пределе, для каждого объекта свой ключ шифрования, при этом ключ шифрования ни коим образом не должен генерироваться на основе идентификационных данных (идентификатор и пароль) пользователей. В порядке замечания отметим, что с целью снижения ресурсоемкости средства защиты, с учетом того, что на одном компьютере может обрабатываться конфиденциальная информация различных категорий, как следствие, требующая различной дополнительной защищенности, целесообразно предусмотреть возможность шифровать данные различных категорий (различные объекты) с использованием различных алгоритмов шифрования (в частности, с использованием различных длин ключа шифрования), соответственно, гарантированно удалять данные различных категорий с использованием различных правил (в частности, с возможностью задания для различных объектов различного числа проходов очистки – записи маскирующей информации, и различных способов задания маскирующей информации – маскирующая информация – это те данные, которые записываются поверх исходных данных при уничтожении, либо при модификации объекта, другими словами, эти те данные, которые остаются на носителе в качестве остаточной информации). Теперь остановимся еще на одном важном вопросе реализации коллективного доступа, в данном случае, удаленного доступа к разделенным в сети дополнительно защищаемым объектам. Упрощенно, имеем следующую структуру системы. На рабочих станциях пользователями осуществляется обработка данных, которые сохраняются в разделенный между пользователями объект, располагаемый на отдельном компьютере (файловом сервере). Возникает вопрос, где осуществлять процедуру шифрования данных – на рабочих станциях, перед их сохранением на сервере, либо собственно на сервере? Наверное, ответ на этот вопрос очевиден – на рабочих станциях. Это объясняется тем, что при таком решении данные передаются по каналу связи в зашифрованном виде (в противном случае, в открытом). Требование к реализации. При реализации коллективного доступа к разделенным в сети дополнительно защищаемым объектам шифрование данных должно осуществляться на рабочих станциях, на которых пользователями осуществляется обработка данных. В порядке замечания отметим, что такое решение возможно лишь в том случае, если средством защиты выполняется требование к реализации, состоящее в том, что объектами криптографической защиты и гарантированного удаления остаточной информации для корпоративных приложений должны являться объекты любого уровня иерархии (диск, папка (каталог, подкаталог), файл) на жестком диске и на внешних накопителях, причем как на локальных, так и на разделенных в сети (см. выше). Все эти требования реализованы в СЗД Панцирь для ОС Windows 2000/XP/2003, что и дает право говорить нам об эффективности данного средства защиты. Интерфейсы. Администрирование Главное окно интерфейса СЗД Панцирь для ОС Windows 2000/XP/2003 представлено на рис.1.  Рис.1 Для работы с объектами (объекты могут задаваться как полнопутевыми именами, так и масками, при этом под маску может подпадать как диск целиком, так и любые съёмные носители) необходимо создать группы, в которые включаются объекты. Для каждой группы объектов задается свой ключ кодирования (все объекты в группе будут кодироваться одним ключом), определяется владелец группы. В части администрирования механизмов Защита данных в СЗД выделяются три типа пользователей:
Пользователь Администратор обладает всеми правами по установке и настройке СЗД: обладает привилегиями по созданию, удалению группы файловых объектов и по заданию ключа кодирования (идентификатора) группы объектов, по заданию и изменению пользователя Владелец группы, возможностью экспорт ключа - создание резервной копии ключа; обладает всеми правами Владельца группы. Пользователь Владелец группы назначается Администратором при создании группы. Привилегиями Владельца группы является добавление объектов в группу (удаление объектов из группы), изменение режимов защиты (в частности, режим только разграничение доступа, режим – кодирование и разграничение доступа и др.); кодирование, декодирование объектов. Владелец группы не имеет полномочий на создание новой группы и на задание ключа кодирования для создаваемой группы; обладает всеми правами Непривилегированного пользователя Непривилегированный пользователь (или пользователь) в части администрирования СЗД обладает возможностью (после идентификации) задания для защищаемого объекта режима чтения без декодирования (в этом режиме запись данных в объект СЗД запрещается). Данный режим необходим для работы с внешними устройствами (например, для ввода с дискеты незакодированных данных) и для реализации обмена файлами в кодированном (зашифрованном) виде по сети, см. рис.2.  Рис.2 Замечание. Для различных групп могут использоваться различные алгоритмы кодирования. Это обусловлено тем, что различные алгоритмы оказывают различное влияние на загрузку вычислительного ресурса, поэтому выбирать алгоритм кодирования для группы, с учетом ресурсоемкости его реализации, следует с учетом уровня конфиденциальности информации, хранящейся в объектах данной группы, см. рис.3  Рис.3 Для решения задач администрирования любым типом пользователя, из программного интерфейса, см. рис.4, запускается окно интерфейса, представленное на рис. В зависимости от прав пользователя (администратор, владелец группы, непривилегированный пользователь), открывающего интерфейс, пользователю будут разрешены конкретные функции администрирования.  Рис.4 Важнейшим вопросом реализации средства защиты является реализуемая в системе ключевая политика, определяющая вопросы хранения и ввода ключей шифрования. СЗД предоставляет весьма широкие возможности реализации ключевой политики. В основу положены альтернативные способы хранения и ввода ключа - из файла (в том числе, с устройств ввода, таких как дискета, CD-ROM диск, устройство Flash-памяти), парольной фразой, с электронного ключа Aladdin eToken R2 и ruToken, со смарт карты, в режиме простой идентификации и в режиме с дополнительной идентификацией, в этом случае доступ к ключевой информации, хранящейся на электронном ключе, дополнительно защищен паролем. Ключ, в зависимости от заданного режима защиты, служит как непосредственно ключом шифрования, так и идентифицирующим признаком группы объектов (разграничение прав доступа реализуется на основе идентификации групп объектов – чтобы получить доступ к объектам, относящихся к группе, необходимо осуществить идентификацию по ключевой информации). Администрирование состоит в создании группы, указании ее владельца, в выборе алгоритма кодирования (шифрования) для группы, см. рис.3, в генерировании и сохранении ключа кодирования (шифрования) для группы объектов, в назначении объектов, входящих в группу. Для добавления объекта (объектов) в группу, нужно воспользоваться кнопкой Добавить (см. рис. , либо в меню Группа выбрать подменю Добавить, после чего выбрать какой объект (объекты) следует добавить в группу (объект можно задать полнопутевым адресом файла, папки, диска – локального, лиюл разделенного в сети, на жестком диске, либо на внешнем накопителе, воспользовавшись опцией Обзор, также можно воспользоваться механизмом масок). При создании группы, см. рис.3, могут быть установлены дополнительные возможности по разграничению прав доступа к объектам группы:
Достаточно важной является возможность СЗД, состоящая в разрешении доступа к объектам группы только процессам СЗД, см. рис. Эта опция должна использоваться в случае, если в сети реализуется ключевой сервер (сервер, в разделяемых в сети файлах которого создаются ключи шифрования). В этом случае доступ к ключам (которые передаются по сети в зашифрованном виде) пользователь с удаленной машины сможет получить только процессом СЗД, что необходимо для защиты ключевой информации от хищения. При реализации сетевой ключевой политики, пользователь не имеет ключа шифрования, своим ключом, идентифицировавшись с его помощью, он может получить доступ к ключу на сервере, который процессом СЗД будет загружен в оперативную память пользователя, после чего, пользователь сможет работать с данными на этой машине. По аналогии реализована и настройка механизма гарантированного удаления остаточной информации. При выборе соответствующей закладки Гарантированное удаление, см. рис.1, открывается окно настройки этого механизма защиты, см. рис.5. Заметим, что режим гарантированного удаления может быть установлен и для любой (в пределе для всех) группы, объекты в которых шифруются и/или к которым разграничивается доступ по ключевой информации, см. рис.3 Дополнительные параметры.  Рис.5 Для задания объекта гарантированного удаления в общем случае необходимо внести его полнопутевой адрес в поле Объекты гарантированного удаления. Для этого можно воспользоваться кнопкой Добавить, см. рис.5, после чего выбрать нужный объект, используя опцию Обзор (где предлагается ввести полнопутевой адрес объекта или маску), либо правой кнопкой мыши вызвать меню работы с объектами см. рис.6, и, выбрав вкладку Новый путь, ввести полнопутевой адрес объекта. С помощью этого меню можно также редактировать адрес объекта, удалить объект из списка гарантированно очищаемых, кроме того, можно гарантированно очистить выделенный объект вручную.  Рис.6 Для настройки параметров гарантированной очистки: задания шаблона (данные, которые будут записываться СЗД на место удаляемой информации), выбора количества проходов очистки (сколько раз шаблон будет записываться поверх удаляемой информации), следует воспользоваться вкладкой Свойства, см. рис.5, при этом откроется интерфейс настройки параметров гарантированного удаления, см. рис. 7, в котором необходимо произвести настройку соответствующих параметров.  Рис.7 Пример практического использования СЗД Рассмотрим следующий пример практического использования СЗД – защита корпоративной бухгалтерской информации (данное решение было апробировано). Пусть на предприятии используется бухгалтерская программа 1С Предприятие V 8. Это сетевое приложение, позволяющее хранить базу на сервере и удаленно с ней работать (реализуется коллективный доступ) одновременно нескольким сотрудникам на различных рабочих станциях в сети. Решение по защите конфиденциальных данных при этом состоит в следующем. На каждуй рабочую станцию устанавливается СЗД (если на сервере также предполагается работа с базой локально, то СЗД устанавливается и на сервер). Настройка СЗД приведена на рис.8.  Рис.8 каталог с базой (созданный на сервере (машина ITB5, см. рис. и разделенный в сети) на каждой рабочей станции внесен в группу защищаемых объектов. Для данной группы на каждой рабочей станции создан ключ шифрования – он одинаков для всех станций (только при этом возможене коллективный доступ к базе), что подволяет сделать опция экспорта и импорта ключа, см. рис.9, – на одной станции ключ создается – экспортируется в файл (например, на внешний накопитель), затем экспортируется из данного файла на других станциях.  Рис.9 Заметим, что подобная опция важна и в том случае, когда для генерирования ключей шифрования должен использоваться аппаратный генератор. При реализации опции экспорта ключа в файл и импорта ключа из файла, может использоваться один подобный генератор (одна плата) для всех защищаемых вычислительных средств. Ключи шифрования записываются на соответствующие носители, которые раздаются сотрудникам, которым необходим доступ к бухгалтерской базе. Соответствующим образом разграничивается доступ к базе (с рабочей станции он становится возможен только после вводла ключевой информации), при необходимости, скрывается сам факт ее присутствия, см. рис.3. Что мы в результате всего этого получаем. Реализован коллективный доступ к базе, все пользователи могут с нею работать, причем одновременно. База хранится на сервере в зашифрованном виде, в зашифрованном же виде передается по каналу между рабочей станцией и сервером (расшифрование средствами СЗД осуществляется непосредственно на рабочей станции). Доступ к базе с рабочей станции может получить только санкционированный пользователь – сотрудник, имеющий носитель с ключевой информиацией. Если доступ к защищаемому компьютеру получит несанкционированый сотрудник, он не получит доступа к базе (для этого необходимо идентифицироваться по ключевой информации), папка с базой даже не отобразится при уделенном просмотре файловых объектов на сервере. В заключение отметим, что в качестве примера (не более того) рассмотрено лишь одно из возможных приложений СЗД Панцирь для ОС Windows 2000/XP/200 Подобных приложений СЗД (практических задач защиты в автоматизированной системе обработки информации предприятия) существует множество. В работе же мы привели пример реального практического внедрения СЗД, проиллюстрировавшего высокую ее эффективность, применительно к решению задачи защиты персональных данных. Читайте далее:  6. предпочтения участников рынка безопасности 2007 года Некоторые мысли после выставки mips 2008 Security 50 – лучшие в мире 50 компаний в области безопасности по объему продаж 01 - 03 февраля 2008 года 1.4. действия сил охраны 25 - 29 февраля 2008 года 07 - 13 апреля 2008 года ,рынок it, 21 - 27 апреля 2008 года ,рынок it, Адаптер sb-1 для монтажа видеокамер на столбах 01- 04 мая 2008 года ,рынок it, 12 - 18 мая 2008 года ,рынок безопасности, 26 - 31 мая 2008 года ,рынок безопасности, Техническое задание на создание интегрированной системы безопасности объекта Шараж-монтаж Заземление в системах промышленной автоматизации ,часть 1,
|
