Jump to content
larm

Шифрование съемных носителей при иерархии KSC [В процессе]

Recommended Posts

Есть задача в организации реализовать шифрование съемных носителей. Но предчувствую, что как-то это не очень будет дружить с нашей иерархией:

 

1. Главный сервер KSC10.3.407a, два подчиненных KSC10.3.407a в удаленных филиалах, но не настолько удаленных, чтобы не привезти зашифрованную флешку в головной офис (компьютеры KES10MR3 под управлением главного сервера KSC). Прозрачно получить доступ к флешке, зашифрованной на KES10MR3 под управлением подчиненного сервера, не получается на компьютере с KES10MR3 под политиками главного сервера.

1)Т.е. нет механизмов передачи мастер-ключей шифрования или публичного ключа KSC с главного сервера на подчиненный и обратно?

2)И единственный вариант - восстановление зашифрованного устройства через отправку запросов доступа *.fdertc?

 

 

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

1) Что в данном случае публичный ключ KSC (и видимо парный закрытый ключ, который на сервере используется для расшифровки), есть ли возможность его отдельно экспортировать, как например, с резервным копированием и восстановлением сертификата KSC?

Share this post


Link to post
Есть задача в организации реализовать шифрование съемных носителей. Но предчувствую, что как-то это не очень будет дружить с нашей иерархией:

 

1. Главный сервер KSC10.3.407a, два подчиненных KSC10.3.407a в удаленных филиалах, но не настолько удаленных, чтобы не привезти зашифрованную флешку в головной офис (компьютеры KES10MR3 под управлением главного сервера KSC). Прозрачно получить доступ к флешке, зашифрованной на KES10MR3 под управлением подчиненного сервера, не получается на компьютере с KES10MR3 под политиками главного сервера.

1)Т.е. нет механизмов передачи мастер-ключей шифрования или публичного ключа KSC с главного сервера на подчиненный и обратно?

2)И единственный вариант - восстановление зашифрованного устройства через отправку запросов доступа *.fdertc?

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

1) Что в данном случае публичный ключ KSC (и видимо парный закрытый ключ, который на сервере используется для расшифровки), есть ли возможность его отдельно экспортировать, как например, с резервным копированием и восстановлением сертификата KSC?

 

Здравствуйте,

 

такой сценарий не тестировался. Но теоретически это возможно.

Имейте в виду, что новые съёмные носители, которые были зашифрованы на одном сервере, не будут расшифрованы на другом сервере, так как восстановление на втором сервере из резервной копии первого сервера было произведено ранее.

Спасибо.

 

Share this post


Link to post
Имейте в виду, что новые съёмные носители, которые были зашифрованы на одном сервере, не будут расшифрованы на другом сервере, так как восстановление на втором сервере из резервной копии первого сервера было произведено ранее.

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

post-480202-1480609900_thumb.png

 

И собственно это и возвращает нас к пункту 1 вопроса про подчиненные сервера. Невозможно главному серверу сделать подчиненным сервер из своего же бекапа. Но было бы возможным, если бы был механизм экспорта непосредственно публичного ключа KSC или просто совет про обходные пути, какие файлы подменить.

 

А ситуация номер 2 уже тоже поднималась https://forum.kaspersky.com/index.php?showtopic=337497 И собственно у меня точно такая же задача, как и у того топикстартера

 

 

Share this post


Link to post

Здравствуйте,

 

К сожалению, сценарий с подменой файлов не предусмотрен.

 

Спасибо!

Share this post


Link to post

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

 

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

Edited by larm

Share this post


Link to post

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

 

Пожалуйста, сообщите нам номер запроса.

 

Спасибо за сотрудничество!

Share this post


Link to post
INC000007042550

Здравствуйте!

 

Спасибо за информацию, ожидайте ответа в рамках инцидента.

 

Спасибо!

Share this post


Link to post

По итогам - запрос 4571 в системе пожеланий к продукту: добавить возможность экспортировать закрытый ключ шифрования. Либо реализовать это в функционале бекапа как с опцией «только сертификата Сервера администрирования»

 

И вот в контексте всего вышесказанного появилась близкая ко всему этому утилита klsetsrvcert http://support.kaspersky.ru/12604

1. Хочется пояснений, будет ли работать функционал прозрачного доступа через KSC к зашифрованным съемным носителям, если предварительно была добавлена своя сгенерированная ключевая пара PKCS#12. По идее вроде должно, раз добавляется контейнер .p12 или .pfx?

 

2. И не планируется ли развитие утилиты klsetsrvcert, позволяющей все-таки экспортировать закрытый ключ и сертификат из существующего KSC?

Edited by larm

Share this post


Link to post
По итогам - запрос 4571 в системе пожеланий к продукту: добавить возможность экспортировать закрытый ключ шифрования. Либо реализовать это в функционале бекапа как с опцией «только сертификата Сервера администрирования»

 

И вот в контексте всего вышесказанного появилась близкая ко всему этому утилита klsetsrvcert http://support.kaspersky.ru/12604

1. Хочется пояснений, будет ли работать функционал прозрачного доступа через KSC к зашифрованным съемным носителям, если предварительно была добавлена своя сгенерированная ключевая пара PKCS#12. По идее вроде должно, раз добавляется контейнер .p12 или .pfx?

 

2. И не планируется ли развитие утилиты klsetsrvcert, позволяющей все-таки экспортировать закрытый ключ и сертификат из существующего KSC?

 

Здравствуйте,

 

к сожалению такой информации нет.

Спасибо.

Share this post


Link to post

Дошли руки попробовать утилиты klsrvcertgen2 (генерируется сертификат формата .pfx) и klsetsrvcert (устанавливается сертификат PKCS#12).

В результате на сервере KSC в каталоге C:\ProgramData\KasperskyLab\adminkit\1093\cert заменяются файлы klserver.cer и klserver.prk.

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

 

Жаль, что до этих изначально неверных предположений приходится опытным путем доходить самостоятельно, потому что «к сожалению такой информации нет». Почему собственно, если это действительно нетривиальная задача не первой линии техподдержки, то не передавать дальше до инженеров, кто-то же ведет разработку по линии шифрования? Может снова переоткрыть запрос INC000007042550?

 

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

Пусть давно существуют главный KSC1 и подчиненный ему KSC2 (со своими подчиненными ПК).

1. Делается полный бэкап KSC1

2. Делается бэкап KSC2 с опцией «только сертификата Сервера администрирования»

3. С KSC2 «ручками» экспортируются все возможные задачи, политики (при необходимости)

4. Затем сервер KSC2 поднимается из бэкапа KSC1, удаляется вся структура: группы ПК, сами ПК, ненужные задачи и тд и тп.

5. Еще раз на KSC2 запускается задача восстановления из бэкапа, только теперь уже с опцией «только сертификата Сервера администрирования»(возвращаем прежний сертификат сервера администрирования). Тем самым хотя бы все ПК с агентом администрирования опять коннектятся.

6. Снова задается иерархия главный KSC1 и подчиненный ему KSC2. На KSC2 импортируются ранее сохраненные задачи, политики, ну или наследуются.

 

Некрасивое решение, нетехническое, но что делать, если руководством поставлена задача «криптопериметра»?!

Это выглядит, как кривые костыли, хотя ведь понятно, что где-то в бэкапе KSC (в каком-либо файле, записи в реестре, параметрах sql базы) есть этот мастер-ключ для шифрования FDE на съемных дисках. Но такой информации нет, сценарий не предусмотрен...

 

Share this post


Link to post
Дошли руки попробовать утилиты klsrvcertgen2 (генерируется сертификат формата .pfx) и klsetsrvcert (устанавливается сертификат PKCS#12).

В результате на сервере KSC в каталоге C:\ProgramData\KasperskyLab\adminkit\1093\cert заменяются файлы klserver.cer и klserver.prk.

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

 

Жаль, что до этих изначально неверных предположений приходится опытным путем доходить самостоятельно, потому что «к сожалению такой информации нет». Почему собственно, если это действительно нетривиальная задача не первой линии техподдержки, то не передавать дальше до инженеров, кто-то же ведет разработку по линии шифрования? Может снова переоткрыть запрос INC000007042550?

 

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

Пусть давно существуют главный KSC1 и подчиненный ему KSC2 (со своими подчиненными ПК).

1. Делается полный бэкап KSC1

2. Делается бэкап KSC2 с опцией «только сертификата Сервера администрирования»

3. С KSC2 «ручками» экспортируются все возможные задачи, политики (при необходимости)

4. Затем сервер KSC2 поднимается из бэкапа KSC1, удаляется вся структура: группы ПК, сами ПК, ненужные задачи и тд и тп.

5. Еще раз на KSC2 запускается задача восстановления из бэкапа, только теперь уже с опцией «только сертификата Сервера администрирования»(возвращаем прежний сертификат сервера администрирования). Тем самым хотя бы все ПК с агентом администрирования опять коннектятся.

6. Снова задается иерархия главный KSC1 и подчиненный ему KSC2. На KSC2 импортируются ранее сохраненные задачи, политики, ну или наследуются.

 

Некрасивое решение, нетехническое, но что делать, если руководством поставлена задача «криптопериметра»?!

Это выглядит, как кривые костыли, хотя ведь понятно, что где-то в бэкапе KSC (в каком-либо файле, записи в реестре, параметрах sql базы) есть этот мастер-ключ для шифрования FDE на съемных дисках. Но такой информации нет, сценарий не предусмотрен...

 

Извините, что не уточнили.

На данный момент остались у вас какие-то вопросы по теме ?

Спасибо.

Share this post


Link to post

Здравствуйте, конечно, самый главный вопрос так остался - в каком файле, записи в реестре, параметрах sql базы содержится мастер-ключ для FDE-шифрования съемных дисков? И экспорт-импорт его без всяких сомнительных рокировок бекапов, как выше описано.

Т.е. насколько это закрытая информация, которую совершенно невозможно получить от инженеров, разработчиков по линии шифрования?

Share this post


Link to post
Здравствуйте, конечно, самый главный вопрос так остался - в каком файле, записи в реестре, параметрах sql базы содержится мастер-ключ для FDE-шифрования съемных дисков? И экспорт-импорт его без всяких сомнительных рокировок бекапов, как выше описано.

Т.е. насколько это закрытая информация, которую совершенно невозможно получить от инженеров, разработчиков по линии шифрования?

 

Здравствуйте!

 

Такую информацию Вы можете запросить через инцидент в companyaccount.kaspersky.com

 

Спасибо!

Share this post


Link to post

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.