Управление ключами как основа безопасности данных
Безопасность криптографических протоколов, используемых для защиты данных в покое, в движении,
и доверие платформы критически зависит от безопасности криптографических ключей. рост
сложность программных и аппаратных атак, облачное использование и нормативные
требования требуют, чтобы закрытые ключи не подвергались
весь их жизненный цикл: генерация, хранение и время выполнения.
Регулируемые вертикальные отрасли, такие как банковское дело, здравоохранение и электронная коммерция
требуют пароли клиентов, ключи и персональные идентификационные номера (PIN-коды)
обеспечиваются через сертифицированные корпорацией ключевые устройства управления под названием Hardware
модули безопасности (HSM). HSM развертываются предприятиями либо в автономном режиме
конфигураций или поставщиков облачных услуг в качестве предложения услуг. Предлагая
железная защита для управления ключами и криптографические услуги, традиционный HSM
приборы имеют недостаток соотношения высокой цены и производительности и требуют
специально созданного оборудования, что затрудняет их масштабирование как виртуальной сети
функции (VNF).сервер
Текущее использование HSM ограничено несколькими ключевыми IT-нишами из-за их очень высокой
соотношение цена / производительность. Облачная миграция корпоративных приложений вместе с
нормативные требования, требуют, чтобы криптографические ключи арендаторов были невидимы для
облачный оператор, помимо того, что он невосприимчив к атакам SW. Пока облачные операторы
предоставлять HSM в качестве дополнительной услуги, увеличивая пропускную способность HSM до облачной шкалы
могут быть чрезмерно дорогими. Во многих случаях криптографические ключи определяют
последние части инфраструктуры, которые не могли быть перенесены в облако для обеспечения безопасности
и причины соблюдения. На этом фоне поставщики HSM и Cloud Service
Поставщики (CSP) также ищут способы виртуализации функций HSM без
угрожающей безопасности.
Примеры использования управления ключами
Веб-серверы идентифицируются закрывающим ключом подписи, таким как RSA или ECDSA
ключи, открытый ключ которых зарегистрирован в центре сертификации. Проверка веб-клиентов
удостоверение (сертификат) сервера, сначала проверив открытый ключ (вместе с
другие общедоступные параметры, такие как IP-адрес и срок действия) с сертификатом
прежде чем доверять подписям, которые создаются веб-сервером. От
кража секретного ключа, злоумышленник может олицетворять оригинальный веб-сервер,
что приводит к потере бизнеса, репутации и доверию к исходному веб-серверу и его
владеющий бизнесом.
Базы данных поддерживают хорошо известную функцию безопасности, называемую Transparent Data
Шифрование (TDE) для шифрования содержимого базы данных в целом. Поддержка TDE
посредством трехуровневой иерархии ключей, включающей: главный ключ обслуживания (SMK), который является
симметричный ключ. Асимметричный ключ сертификата (CK) и Симметричный ключ шифрования данных
(ДЭК). В типичной рабочей последовательности SMK хранится на удаленном ключевом сервере
или HSM, в то время как DEK прикрепляется к базе данных в зашифрованном формате.
DEK восстанавливается при запуске базы данных и размещается вместе с данными.
Хранение DEK на сервере может сделать его уязвимым для программных атак.
Файловые системы шифрования данных, такие как eCryptfs, обладают способностью шифровать
отдельные файлы с использованием симметричных клавиш. Каждый файл связан с другим
симметричный ключ, с симметричным ключом, обернутым еще одним специфичным для использования
асимметричный закрытый ключ. Этот главный ключ или ключ шифрования ключа (KEK) сохраняется
либо HSM, Secure Token или TPM. Когда файл открывается первым, завернутый
симметричный ключ, прикрепленный к файлу, сначала извлекается путем запроса аппаратного ключа
сервер развернуть ключ
