Комплексирование средств или решений?

Комплексирование средств или решений?

Д.т.н., проф. А.Ю.Щеглов
(ЗАО "НПП "Информационные технологии в бизнесе")

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

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

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

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

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

Реализация криптографической защиты виртуальных каналов связи корпоративной сети.
Выше мы говорили, что основными требованиями к реализации криптографической защиты виртуальных каналов корпоративной сети являются: "прозрачное" автоматическое (принудительное для пользователя) шифрование виртуальных каналов корпоративной сети, централизованное генерирование ключей шифрования администратором (пользователь должен быть исключен из схемы администрирования и управления VPN), отсутствие ключа шифрования виртуальных каналов связи у пользователя и, соответственно, невозможность доступа пользователя к ключам шифрования.
Важным условием эффективности защиты является необходимость частой смены ключей шифрования виртуальных каналов. Это, с учетом необходимости централизованного генерирования ключей для всех субъектов/объектов (определяемых идентификаторами) корпоративной сети, существенно усложняет задачу администрирования VPN.
Подход к реализации ключевой политики, реализованный в ПО "Корпоративная VPN "Панцирь" для ОС Windows 2000/XP/2003", состоит в следующем.
Каждый субъект/объект VPN характеризуется парой признаков: идентификатор и ключ шифрования взаимодействия с сервером VPN. Данная пара генерируется администратором при создании субъекта/объекта. Если субъектом/объектом VPN выступает компьютер, то идентификатор и ключ шифрования взаимодействия с сервером VPN устанавливаются на компьютере администратором при установке клиентской части (в процессе эксплуатации по усмотрению администратора данные параметры могут быть изменены). Если же субъектом/объектом VPN выступает пользователь, то сгенерированная администратором пара признаков идентификатор и ключ шифрования взаимодействия с сервером VPN выдаются пользователю администратором на внешнем носителе (Flash-устройство, электронный ключ, смарт-карта).
До момента идентификации субъекта/объекта клиентской частью VPN на сервере, на компьютере не хранится какой-либо информации о ключах шифрования виртуальных каналов. Ключи шифрования виртуальных каналов генерируются сервером при идентификации субъектов/объектов VPN автоматически, т.е. даже администратор безопасности не обладает ключевой информацией. Осуществляется это следующим образом. При идентификации субъекта/объекта VPN на сервере, для идентифицируемого субъекта/объекта сервером автоматически генерируются ключи шифрования (каждая пара взаимодействующих субъектов/объектов VPN имеет свой ключ шифрования) с другими субъектами/объектами VPN. Данная информация (ключи шифрования данного компьютера с другими активными компьютерами в составе VPN) сервером в зашифрованном виде передается на идентифицированный компьютер (идентифицированному пользователю), где хранится в оперативной памяти – эта информация не доступна пользователю. Одновременно на все остальные активные (идентифицированные ранее) компьютеры из состава VPN сервером выдаются сгенерированные ключи шифрования для взаимодействия с вновь идентифицированным субъектом/объектом. Таким образом, в каждый момент времени в оперативной памяти идентифицированного компьютера в составе VPN хранится таблица с ключами шифрования трафика с другими активными (идентифицированными) компьютерами в составе VPN (для каждой пары этот ключ свой). Данная таблица пополняется после идентификации каждого последующего субъекта/объекта. Смена ключа шифрования осуществляется сервером автоматически при каждой последующей идентификации субъекта/объекта.
Таким образом, вся процедура генерации ключевых пар полностью автоматизирована, не требует участия администратора безопасности, ключи шифрования виртуальных каналов VPN не доступны не только пользователям корпоративной сети, но и администратору.
Разграничение же доступа между субъектами/объектами в составе VPN (о чем упоминалось ранее) реализуется тем, что при идентификации субъекта/объекта ему передаются ключи шифрования виртуальных каналов только с теми активными субъектами/объектами, с которыми администратором разрешено взаимодействие данному субъекту/объекту. Клиентская же часть VPN, установленная на компьютере в составе VPN, позволит осуществлять с него взаимодействие только с теми активными субъектами/объектами, для взаимодействия с которыми получены соответствующие ключи шифрования с сервера VPN.
Теперь рассмотрим вопросы администрирования и построения интерфейсов.
Рассмотрим, в чем состоят задачи администрирования VPN, ведь, как отмечали ранее, множество функций администратора VPN нам удалось автоматизировать.
В своем составе ПО "Корпоративная VPN "Панцирь" для ОС Windows 2000/XP/2003" содержит: клиентские части, устанавливаемые на компьютеры, включаемые в состав VPN, серверные части (основная и резервная), устанавливаемые на выделенные компьютеры, АРМ администратора безопасности, может устанавливаться как на отдельном компьютере, так и на сервере VPN.
Теперь об администрировании.
На сервере необходимо создать базу субъектов/объектов VPN. Это реализуется из интерфейса серверной части, приведенного на рис.1. Для каждого созданного субъекта необходимо указать доверенный он (тогда ему разрешается взаимодействие с внешней сетью) или нет, также для задания системного субъекта существует сущность "резервный сервер". Для созданных субъектов сервером VPN автоматически генерируются его идентификатор и ключ шифрования взаимодействия с сервером VPN, которые необходимо сохранить на внешнем носителе (либо на Flash-устройстве, если субъектом выступает компьютер, либо на одном из выбранных носителей – электронный ключ или карта (может быть также и Flash-устройство), если субъектом выступает пользователь). Данное устройство будет использоваться пользователь для его идентификации с целью получения доступа к виртуальным каналам VPN. Данное устройство впоследствии администратору необходимо будет передать соответствующему сотруднику предприятия (пользователю). Кроме того, необходимо настроить системные параметры сервера (рис.1), задать алгоритм шифрования виртуальных каналов в VPN (рис.2), задать способ хранения и ввода идентифицирующих субъект данных (рис.3).

Рис.1. Настройка сервера VPN

Рис.2. Задание алгоритма шифрования в VPN на сервере

Рис.3. Задание способа хранения и ввода идентифицирующих субъекта данных

После того как субъекты/объекты доступа созданы, может быть задана разграничительная политика доступа в составе VPN, что реализуется на сервере из интерфейса, приведенного на рис.4.

Рис.4. Задание разграничительной политики в составе VPN

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

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

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

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

1. Объектами криптографической защиты должны являться объекты любого уровня иерархии (диск, папка (каталог, подкаталог), файл) на жестком диске и на внешних накопителях, причем как на локальных, так и на разделенных в сети. При этом средством защиты должна предоставляться возможность задания администратором любого набора объектов (например, несколько каталогов на выбор, включая разделенные в сети) в качестве объектов криптографической защиты.
2. Шифрование/дешифрование данных для заданных администратором объектов должно осуществляться автоматически, без какого-либо управления со стороны пользователя ("под принуждением" для пользователя).
3. Ключ шифрования должен создаваться только администратором и предоставляться им пользователю. Ключ шифрования, предоставляемый пользователю, должен обеспечивать возможность дешифрования данных только на конкретном компьютере (возможно, только при условии нахождении данного компьютера в составе ЛВС предприятия – сетевая ключевая политика). Одновременное наличие у пользователя носителя с данными, ключа шифрования и средства криптографической защиты не должно позволять расшифровать эти данные, иначе, как на своем рабочем месте.
4. Средство защиты должно обеспечивать возможность задания различных ключей шифрования для различных защищаемых объектов (в том числе и на одном компьютере) – в пределе, для каждого объекта свой ключ шифрования, при этом ключ шифрования никоим образом не должен генерироваться на основе идентификационных данных (идентификатор и пароль) пользователей. Т.к. это, с одной стороны, снижает криптостойкость, в части противодействия атакам со стороны инсайдеров (санкционированных пользователей), с другой стороны, не обеспечивает реализации коллективного доступа к шифруемым базам данных.
5. Пользователь должен обладать идентифицирующим его признаком, например, хранящимся на электронном ключе, смарт-карте и т.д. При этом средство защиты должно обеспечивать возможность доступа к зашифрованным файловым объектам только после введения в систему идентификационных признаков пользователя.
   Что же мы получим после реализации данных требований в комплексе с построением VPN? Данные шифруются как при хранении (на жестком диске и внешних накопителях), так и при передаче их по сети. При этом ни сторонний сотрудник предприятия, ни собственно санкционированный пользователь не может раскрыть их конфиденциальность. Получить же доступ к виртуальным каналам корпоративной сети и к конфиденциальным данным может только санкционированный пользователь, предъявив свой идентификатор, который может храниться на электронном ключе, смарт-карте и т.д.
   Теперь кратко рассмотрим, как реализуются сформулированные выше требования к криптографической защите данных "Системой защиты данных (СЗД) "Панцирь" для ОС Windows 2000/XP/2003".

1. Назначение и состав системы.
   Система предназначена для защиты конфиденциальных и персональных  данных, обрабатываемых на автономных компьютерах и на компьютерах в составе корпоративной сети; сохраняемых на локальных и удаленных (разделенных в сети) жестких дисках и внешних устройствах, передаваемых по сети при доступе к удаленным (разделенным) ресурсам. Система реализована программно, содержит в своем составе системный драйвер и интерфейсный модуль. Все возможности защиты, предоставляемые СЗД, реализованы собственными средствами СЗД (не использованы встроенные механизмы ОС).
2. Основные механизмы защиты данных.
   СЗД реализует шифрование данных "на лету", автоматическое гарантированное удаление остаточной информации, разграничение прав доступа к защищаемым объектам, скрытие защищаемых объектов файловой системы.
3. Основное отличительное свойство системы.
   Защищаемыми объектами являются любые (назначаемые администратором) файловые объекты – логические диски, каталоги, подкаталоги, файлы (для задания объектов может использоваться механизм масок), как на жестком диске, так и на внешних носителях, как локальные, так и удаленные (разделенные в сети).
4. Возможности основных механизмов защиты:

• Шифрование данных "на лету". В СЗД реализовано автоматическое "на лету" ("прозрачное" для пользователя) шифрование/дешифрование данных при их сохранении в локальный или удаленный файловый объект на жестком диске или на внешнем носителе. При сохранении в удаленный файловый объект, данные по каналу передаются в зашифрованном виде виде. Поддерживаются файловые системы NTFS, FAT32 или FAT16, алгоритмы кодирования: XOR, GOST, DES, AES. Обеспечивается подключение криптопровайдера "Signal-COM CSP" (сертифицирован ФАПСИ по требованиям безопасности информации к классам "КС1" и "КC2" - сертификаты соответствия №СФ/114-0604, №.СФ/124-0605 от 21.04.03), разработчик ЗАО "Сигнал‑КОМ", иСКЗИ "КриптоПро CSP версия 3.0" (сертифицирован ФСБ РФ по требованиям безопасности информации к классам "КС1" и "КC2" - сертификат соответствия № СФ/124-0810 от 12.09.05), разработчик ООО "КриптоПро", при этом СЗД обеспечивает шифрование и дешифрование "на лету" данных в соответствии с российским криптографическим алгоритмом ГОСТ 28147-89. Поддерживаются различные политики генерации, ввода и хранения ключевой информации. Ключ присваивается объекту "группа", в который включаются  защищаемые файловые объекты. Число создаваемых групп и файловых объектов в группе на одном компьютере не ограничено. Ключ может задаваться  парольной фразой (не менее 6 символов), из которой затем генерируется автоматически (для идентификации группы парольная фраза вводится с консоли). Также ключ может задаваться полностью:  вручную (из файла), системой автоматически,  генерироваться посредством движений мыши. Для хранения ключевой информации может использоваться электронный ключ e-Token (Aladdin eToken R2) или ruToken, смарт карта (Aladdin eToken PRO Smart Card 32K), либо файловый объект (локальный, либо удаленный – в сети может быть реализован ключевой сервер, причем вся ключевая информация передается по каналу в закодированном виде), задаваемый его полнопутевым именем, что позволяет хранить ключевую информацию на внешних носителях, в частности, на устройстве Flash-памяти, причем на одном устройстве может храниться необходимое количество ключей, устройство при этом может использоваться по своему прямому назначению. Для идентификации группы (для получения доступа к файловому объекту в группе), системе необходимо единожды считать значение ключа в оперативную память, после чего, ключ может быть удален из системы.
• Гарантированное удаление остаточной информации. В СЗД реализовано автоматическое  ("прозрачное" для пользователя) гарантированное удаление данных в файловом объекте  (локальном или удаленном, на жестком диске или на внешнем носителе), при его удалении или модификации штатными средствами ОС. Для защищаемых файловых объектов система позволяет задавать число "проходов очистки" и вид маскирующей информации, записываемой в файловый объект, перед удалением в нем данных штатными средствами ОС. Защищаемыми объектами являются любые (назначаемые администратором) файловые объекты – логические диски, каталоги, подкаталоги, файлы (для задания объектов может использоваться механизм масок), как на жестком диске, так и на внешних носителях, как локальные, так и удаленные (разделенные в сети).
• Разграничение прав доступа к защищаемым объектам. В СЗД реализовано разграничение прав доступа к защищаемым файловым объектам на основе идентификации групп объектов по ключам (посредством парольного слова, либо ключевой информации на внешнем носителе). Ключ присваивается объекту "группа", в который включаются  защищаемые файловые объекты (локальные или удаленные, на жестком диске или на внешнем носителе), права доступа к которым разграничиваются. Какой-либо доступ к защищаемому файловому объекту разрешается только после идентификации группы, в которую включен объект – т.е. только псле введения ключевой информации (либо с клавиатуры, либо путем подключения соответствующего устройства). Разграничивать права доступа можно к файловым объектам, в которых данные сохраняются, как в зашифрованном, так и в обычном виде. Защищаемыми объектами являются любые (назначаемые администратором) файловые объекты – логические диски, каталоги, подкаталоги, файлы (для задания объектов может использоваться механизм масок), как на жестком диске, так и на внешних носителях, как локальные, так и удаленные (разделенные в сети).
• Скрытие защищаемых объектов файловой системы. В дополнение к разграничению прав доступа к файловым объектам в СЗД реализованы следующие возможности:

• скрытие защищаемого файлового объекта (объект остается “не видимым” для пользователей);
• скремблирование имени файлового объекта при его предоставлении по запросу доступа;
• кодирование имени файлового объекта на диске.

Отображение имени (или реального имени) файлового объекта возможно только после идентификации группы, в которую включен объект. Защищаемыми объектами являются любые (назначаемые администратором) файловые объекты – логические диски, каталоги, подкаталоги, файлы (для задания объектов может использоваться механизм масок), как на жестком диске, так и на внешних носителях, как локальные, так и удаленные (разделенные в сети).Рассмотрим администрирование системы и интерфейсы.
Главное окно интерфейса СЗД "Панцирь" для ОС Windows 2000/XP/2003 представлено на рис.5.

Рис.5. Главное окно интерфейса СЗД "Панцирь" для ОС Windows 2000/XP/2003

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

• Пользователь "Администратор";
• Пользователь "Владелец группы";
• Непривилегированный пользователь.

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

Рис.6. Окно задания алгоритма шифрования для группы

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

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

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

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

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

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

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

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

Замечание. Может быть задана комбинация данных режимов.

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

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

Комплексность решения при использовании рассмотренных в работе продуктов семейства "Панцирь" обеспечивалась:

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

Но эти ли частные решения являются основой комплексирования при создании технических средств? Конечно же, нет!

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