Защита закрытого ключа сертификата SSL с помощью nginx
Я исследовал, как защитить приватные ключи для сертификатов SSL, используя nginx в качестве веб-сервера, но не смог найти много удовлетворительных ответов.
В частности, для клиента, который хочет, чтобы я развернул веб-сайт в их собственном поддомене, они опасаются, что кто-то может получить доступ к закрытому ключу сертификата их поддомена и, следовательно, настроить законно выглядящий небезопасный веб-сайт. Они попросили меня использовать какое-то программное хранилище для защиты их закрытого ключа.
Эта статья из блога nginx, а также эта описывают некоторые решения, но в итоге они оба полагаются на тот же принцип: закрытый ключ защищен парольной фразой, которую мы будем извлекать либо из локального, либо из удаленного местоположения, и для этой процедуры «извлечения» требуется пароль / токен ... который хранится локально.
Следовательно, я не понимаете, как на самом деле секретный ключ становится более безопасным - это немного похоже на то, что вы запираете ваш входной ключ в ящике для ключей вместо того, чтобы оставлять его под ковриком ... и затем оставляете ключ ящика для ключей под ковриком. что-то? Есть ли лучший способ защитить закрытый ключ с помощью nginx?
Есть одно решение, но оно действительно не устраняет необходимость доверять вашему серверу. Если ваш Клиент желает поместить свою запись на ваш сервер, он должен как-то вам доверять. Есть одно решение, которое может защитить вашего клиента.
Они указывают субдомен на брандмауэр веб-приложений , например Cloudflare . Они создают вам сертификат Origin (тот, который находится на вашем сервере) и отправляют вам сертификат и ключ через надежный протокол связи, например GPG.
Они указывают этот субдомен на IP-адрес вашего сервера.
Они не предоставляют вам доступ к своей учетной записи Cloudflare.
Удерживая все это. Они контролируют сертификат Edge. Они контролируют сертификат происхождения. Они всегда могут его отозвать. Они контролируют свои владения. Единственное, что ваш Клиент не контролирует, это, конечно, ваш сервер. ;)
Конечно, все настройки безопасности, представленные @Halfgaar, все еще актуальны.
————————————————————-
Если вы хотите укрепить доверие, вы можете показать аудиты со своего сервера. Присутствуют журналы аудита. Докажите, что безопасность ваших серверов соответствует таким стандартам, как NISM или STIGS .
Основываясь на вашем последнем комментарии, я вижу несколько вариантов:
- Вы показываете, что у вас хорошая безопасность SSH, которая может включать доступ из белого списка IP, вход без пароля и т.д.
- Вы показываете, что файл закрытого ключа доступен для чтения только пользователю root и хранится вне корня документа, например, как обычно где-то в
/ etc / ssl. Взлом размещенного веб-сайта гораздо более распространен, чем взлом всего сервера, и таким образом обеспечивается защита от такого чтения. - По поводу вышеизложенного: осторожно при запуске докер-контейнеров; они обычно запускаются от имени пользователя root и, на мой взгляд, представляют собой проблему безопасности. Контейнеры Docker могут работать без root (экспериментально), но образы должны быть созданы специально для этого. Большинство изображений, которые вы получаете в другом месте, зависят от того, что вы root. Все, что в нем работает под root, может сломать тюрьму. (Изменить: это действительно требует некоторых нюансов после переоценки. Я должен сказать, может сломать тюрьму. Это зависит от безопасности некоторых дополнительных механизмов, о которых вам в противном случае не нужно было бы беспокоиться.)
- Если они действительно обеспокоены, им следует настроить обратный прокси-сервер для вашего сервера, и они смогут выполнять завершение SSL на своей стороне.
А насчет предоставления вам сертификата SSL: им не обязательно. Вы можете просто настроить Letsencrypt. Дополнительным бонусом является то, что эти сертификаты недолговечны.
Все прикрыто комментариями и ответами, я бы просто
как и складывать, одного лишь кражи сертификатов недостаточно. В злоумышленник также должен указать действительный домен, для которого сертификат был проверен.В случае фишинговых атак сайт может выглядеть так же, но
домен может быть другим, и сертификаты не будут работать с другой домен.Пока DNS не укажет правильный IP и DNS не будет подделан или запутался, кража SSL-сертификатов бесполезна.
В этой ситуации, когда клиент несколько сомневается, вы можете использовать шифрование сертификатов с меньшим периодом
срока действия (90 дней). И должны регулярно обновляться.Получение и продление сертификатов Let's encrypt требуется домен проверка каждый раз. Так что кража сертификатов будет не очень полезна для долгое время.