Статус: Новичок
Группы: Участники
Зарегистрирован: 19.08.2020(UTC)
Сообщений: 3
Сказал(а) «Спасибо»: 2 раз
|
Добрый день, подскажите пожалуйста, имеет ли место быть подобная схема работы с контейнерами Крипто про:
Первый сервер. Установлен Крипто-про jcp + прикладной модуль который осуществляет криптографические функции, шифрование, расшифрование запросов.
Второй сервер. Хранит закрытые ключи для первого сервера.
Сервера находится в разных сетевых сегментах и должны общаться посредством некого APi. Второй сервер выступает в роли хранилища закрытых контейнеров ключей, первый обращается ко второму за контейнерами.
Подскажите есть ли какое то +- коробочное, готовое решение для реализации подобной схемы?
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 396 раз в 366 постах
|
Добрый день.
Это очень небезопасно, так как по сути ключи будут все время пересылаться по сети, тем более между разными сетевыми сегментами. Даже с учетом шифрования ключа в контейнере пин-кодом и ВОЗМОЖНОЙ оберткой шифрования канала это все равно лишний риск. Вспомним на секунду о том, что если какому то роутеру или коммутатору не известен сетевой адрес, он может отправить пакет на все порты. Конечно если сначала запрос ключа потом ответ, то марщрут будет известен, но, тем не менее, если электричество кратковременно мигнет как раз между ними, то есть реальный шанс получить ответ на все порты и поймать ключ сниффером на неком третьем компьютере. Там уже может внезапно выяснится что пин-код 12345678 и ключ окажется как на ладони.
Другой вопрос, если криптографические операции будут там же, где ключи - так безопаснее. Для такого размещения есть решения и подходящие методы аутентификации. Например, DSS.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 30.06.2016(UTC) Сообщений: 3,486  Сказал «Спасибо»: 53 раз
Поблагодарили: 802 раз в 741 постах
|
Автор: leqs091  Добрый день, подскажите пожалуйста, имеет ли место быть подобная схема работы с контейнерами Крипто про:
Первый сервер. Установлен Крипто-про jcp + прикладной модуль который осуществляет криптографические функции, шифрование, расшифрование запросов.
Второй сервер. Хранит закрытые ключи для первого сервера.
Сервера находится в разных сетевых сегментах и должны общаться посредством некого APi. Второй сервер выступает в роли хранилища закрытых контейнеров ключей, первый обращается ко второму за контейнерами.
Подскажите есть ли какое то +- коробочное, готовое решение для реализации подобной схемы? Здравствуйте. В качестве подобного хранилища ключей может выступать КриптоПро HSM. Но доступ к таким ключам из КриптоПро JCP 2.0 невозможен, необходимо будет использовать связку (КриптоПро CSP 5.0 + КриптоПро Java CSP 5.0) при необходимости обращаться к ключам из Java. И еще один момент - для доступа к ключам в HSM необходимо использовать ключ доступа к HSM для связи по двустороннему ГОСТ TLS. Поэтому хранение ключей и их использование на одном и том же сервере (как было предложено выше) кажется лучшим выбором. |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 19.08.2020(UTC)
Сообщений: 3
Сказал(а) «Спасибо»: 2 раз
|
Автор: Александр Лавник Автор: leqs091 Добрый день, подскажите пожалуйста, имеет ли место быть подобная схема работы с контейнерами Крипто про:
Первый сервер. Установлен Крипто-про jcp + прикладной модуль который осуществляет криптографические функции, шифрование, расшифрование запросов.
Второй сервер. Хранит закрытые ключи для первого сервера.
Сервера находится в разных сетевых сегментах и должны общаться посредством некого APi. Второй сервер выступает в роли хранилища закрытых контейнеров ключей, первый обращается ко второму за контейнерами.
Подскажите есть ли какое то +- коробочное, готовое решение для реализации подобной схемы? Здравствуйте. В качестве подобного хранилища ключей может выступать КриптоПро HSM. Но доступ к таким ключам из КриптоПро JCP 2.0 невозможен, необходимо будет использовать связку (КриптоПро CSP 5.0 + КриптоПро Java CSP 5.0) при необходимости обращаться к ключам из Java. И еще один момент - для доступа к ключам в HSM необходимо использовать ключ доступа к HSM для связи по двустороннему ГОСТ TLS. Поэтому хранение ключей и их использование на одном и том же сервере (как было предложено выше) кажется лучшим выбором. 1. Получается в подобной схеме необходимо обязательное использование Крипто про HSM, для хранения ключей. 2. для возможности обращения к данному HSM необходимо настроить связку с ГОСТ TLS между сервером с прикладным ПО и HSM, например поднять на данном сервер nginx, что влечет за собой еще покупку лицензии для модуля nginx с поддержкой ГОСТ TLS. 3.На сервере должно быть установлено ПО КриптоПро CSP 5.0, КриптоПро Java CSP 5.0, КриптоПро JCP 2.0. и всё это поддерживается для Linux?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 30.06.2016(UTC) Сообщений: 3,486 Сказал «Спасибо»: 53 раз
Поблагодарили: 802 раз в 741 постах
|
Автор: leqs091 Автор: Александр Лавник Автор: leqs091 Добрый день, подскажите пожалуйста, имеет ли место быть подобная схема работы с контейнерами Крипто про:
Первый сервер. Установлен Крипто-про jcp + прикладной модуль который осуществляет криптографические функции, шифрование, расшифрование запросов.
Второй сервер. Хранит закрытые ключи для первого сервера.
Сервера находится в разных сетевых сегментах и должны общаться посредством некого APi. Второй сервер выступает в роли хранилища закрытых контейнеров ключей, первый обращается ко второму за контейнерами.
Подскажите есть ли какое то +- коробочное, готовое решение для реализации подобной схемы? Здравствуйте. В качестве подобного хранилища ключей может выступать КриптоПро HSM. Но доступ к таким ключам из КриптоПро JCP 2.0 невозможен, необходимо будет использовать связку (КриптоПро CSP 5.0 + КриптоПро Java CSP 5.0) при необходимости обращаться к ключам из Java. И еще один момент - для доступа к ключам в HSM необходимо использовать ключ доступа к HSM для связи по двустороннему ГОСТ TLS. Поэтому хранение ключей и их использование на одном и том же сервере (как было предложено выше) кажется лучшим выбором. 1. Получается в подобной схеме необходимо обязательное использование Крипто про HSM, для хранения ключей. 2. для возможности обращения к данному HSM необходимо настроить связку с ГОСТ TLS между сервером с прикладным ПО и HSM, например поднять на данном сервер nginx, что влечет за собой еще покупку лицензии для модуля nginx с поддержкой ГОСТ TLS. 3.На сервере должно быть установлено ПО КриптоПро CSP 5.0, КриптоПро Java CSP 5.0, КриптоПро JCP 2.0. и всё это поддерживается для Linux? 1. У нас такое решение, у другого разработчика, возможно, есть какие-то другие варианты. 2. Двуcторонний ГОСТ TLS для подключения к HSM на Windows организуется с помощью ПО HSM клиент. На *nix для этого используется stunnel. HSM - это железный модуль, установить его на свое оборудование нельзя. 3. На сервере должны быть установлены КриптоПро CSP 5.0 и КриптоПро Java CSP 5.0. Библиотеки КриптоПро JCP 2.0 устанавливаются вместе с КриптоПро Java CSP 5.0. КриптоПро CSP 5.0 и КриптоПро Java CSP 5.0 поддерживаются на Linux. Еще раз повторюсь - вместо использования HSM можно хранить и использовать ключи на одном сервере. |
|
 1 пользователь поблагодарил Александр Лавник за этот пост.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 19.08.2020(UTC)
Сообщений: 3
Сказал(а) «Спасибо»: 2 раз
|
Автор: Александр Лавник Автор: leqs091 Автор: Александр Лавник Автор: leqs091 Добрый день, подскажите пожалуйста, имеет ли место быть подобная схема работы с контейнерами Крипто про:
Первый сервер. Установлен Крипто-про jcp + прикладной модуль который осуществляет криптографические функции, шифрование, расшифрование запросов.
Второй сервер. Хранит закрытые ключи для первого сервера.
Сервера находится в разных сетевых сегментах и должны общаться посредством некого APi. Второй сервер выступает в роли хранилища закрытых контейнеров ключей, первый обращается ко второму за контейнерами.
Подскажите есть ли какое то +- коробочное, готовое решение для реализации подобной схемы? Здравствуйте. В качестве подобного хранилища ключей может выступать КриптоПро HSM. Но доступ к таким ключам из КриптоПро JCP 2.0 невозможен, необходимо будет использовать связку (КриптоПро CSP 5.0 + КриптоПро Java CSP 5.0) при необходимости обращаться к ключам из Java. И еще один момент - для доступа к ключам в HSM необходимо использовать ключ доступа к HSM для связи по двустороннему ГОСТ TLS. Поэтому хранение ключей и их использование на одном и том же сервере (как было предложено выше) кажется лучшим выбором. 1. Получается в подобной схеме необходимо обязательное использование Крипто про HSM, для хранения ключей. 2. для возможности обращения к данному HSM необходимо настроить связку с ГОСТ TLS между сервером с прикладным ПО и HSM, например поднять на данном сервер nginx, что влечет за собой еще покупку лицензии для модуля nginx с поддержкой ГОСТ TLS. 3.На сервере должно быть установлено ПО КриптоПро CSP 5.0, КриптоПро Java CSP 5.0, КриптоПро JCP 2.0. и всё это поддерживается для Linux? 1. У нас такое решение, у другого разработчика, возможно, есть какие-то другие варианты. 2. Двуcторонний ГОСТ TLS для подключения к HSM на Windows организуется с помощью ПО HSM клиент. На *nix для этого используется stunnel. HSM - это железный модуль, установить его на свое оборудование нельзя. 3. На сервере должны быть установлены КриптоПро CSP 5.0 и КриптоПро Java CSP 5.0. Библиотеки КриптоПро JCP 2.0 устанавливаются вместе с КриптоПро Java CSP 5.0. КриптоПро CSP 5.0 и КриптоПро Java CSP 5.0 поддерживаются на Linux. Еще раз повторюсь - вместо использования HSM можно хранить и использовать ключи на одном сервере. 2. про stunnel спасибо за уточнение, то что HSM это железка, я знаю, возможно по тексту неправильно выразился :) Спасибо за подробные ответы.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
