#linux #security #encryption #digital-signature
#linux #Безопасность #шифрование #цифровая подпись
Вопрос:
Я разрабатываю клиент-серверное приложение, которое требует, чтобы некоторые файлы были подписаны с использованием закрытого ключа перед отправкой клиенту. Затем клиент проверяет подпись, используя открытый ключ. Следовательно, закрытый ключ должен постоянно находиться на сервере и быть доступен для чтения серверному приложению.
Проблема в том, что мне было интересно, где хранить мой закрытый ключ, который более защищен от утечки в случае взлома сервера.
Должен ли я хранить его в базе данных или мне следует сохранить его в виде файла и использовать разрешение на доступ к файлу для управления?
Спасибо.
Комментарии:
1. Этот вопрос лучше задать сайту IT security SE (sec.se ).
Ответ №1:
Вариант вариант — использовать двоичный файл setuid, который запускается от имени другого пользователя, для подписи сертификата.
Этот другой пользователь имел бы доступ на чтение к ключу, но «Обычный» пользователь сервера приложений не имел бы доступа на чтение. Поэтому, если кто-то взломает учетную запись сервера приложений, он сможет подписывать только произвольные сертификаты, а не красть закрытый ключ CA.
Другой возможностью было бы иметь некоторый механизм RPC для передачи запроса подписи другому процессу, запущенному от имени другого пользователя, возможно, на другом хосте. Или другой виртуальной машине на том же хосте (но не внутри компьютера сервера приложений).
Любой из этих подходов просто уменьшает влияние компромисса, но это все равно плохо.
Ответ №2:
Если ключ хранится на самом сервере, то в случае взлома этого сервера он будет найден. Хранение в базе данных / файлах вряд ли предотвратит это — большинство взломов сервера происходят через службы, которыми он управляет.
Одним из вариантов является хранение закрытых ключей в отдельном аппаратном модуле, называемом аппаратным модулем безопасности, или HSM. HSM генерирует подписи по запросу, но не раскрывает закрытый ключ серверу. Если сервер взломан, они могут заставить его подписывать файлы на время своего доступа, но не могут получить сам ключ и должны сохранить доступ к серверу для продолжения генерации подписей. Для нечастых приложений смарт-карта может служить простым HSM.
Комментарии:
1. Спасибо за предложение. Однако аппаратный модуль недоступен. Считаете ли вы, что создание другого сервера генератора подписей, работающего с использованием другой учетной записи, повысит безопасность?
2. * «.. если этот сервер скомпрометирован, он будет найден …» — не обязательно верно. Если Apache скомпрометирован и работает под собственной учетной записью, то закрытые ключи в
/etc(например, SSH-ключи хоста и закрытые ключи, связанные с сертификатами PKI), скорее всего, не будут скомпрометированы.3.
most breaks in to a server happen through the services it operatesНу, конечно. Но эти службы должны использовать разделение привилегий / работать под своими собственными учетными записями. Кроме того, не все уязвимости предоставляют злоумышленнику корневую оболочку. Ваш совет «используйте HSM или не утруждайте себя попытками» довольно недальновиден, особенно если все, что может найти злоумышленник, — это vuln обхода произвольного каталога. HSM полезны, но разрешения file DB по-прежнему важны.