Я хочу сохранить конфиденциальность нашего ключа SSL для нашего веб-сайта. Он хранится на 2 USB-накопителях, один в сейфе, а другой я храню. И тогда я единственный, кто применяет его к веб-серверу, чтобы он был полностью безопасным.
Кроме...
По крайней мере, в IIS вы можете экспортировать ключ. Таким образом, любой администратор может получить копию ключа. Есть ли способ обойти это? Или по определению все админы имеют полный доступ ко всем ключам?
Обновить: У меня есть системные администраторы, которым я полностью доверяю. К этому привело то, что один из них уволился (у них был час езды до нашей компании, 5 минут до новой). Хотя я доверяю этому человеку, точно так же, как мы отключаем его учетную запись Active Directory, когда кто-то уходит, я подумал, что у нас должен быть способ гарантировать, что они не сохранят возможность использовать наш SSL.
И что мне показалось самым простым, так это то, что я единственный, у кого он есть. Срок действия нашего сертификата истекает в январе, так что пришло время изменить практику, если мы могли. Судя по ответам, мы не можем.
Таким образом, возникает новый вопрос: когда кто-то, у кого есть доступ к сертификату, уходит, является ли стандартной практикой получение нового сертификата и аннулирование существующего. Или, если человек, который ушел, заслуживает доверия, то мы продолжим с сертификатом, который у нас есть?
Человек с административным (или часто даже физическим) доступом к серверу сможет извлечь закрытый ключ. Будь то экспорт, анализ памяти или другие подобные уловки.
Ваши администраторы имеют доступ к закрытым ключам ваших веб-серверов. Примите это как факт и работайте над этим. Если ваши системные администраторы не заслуживают доверия, вам могут понадобиться более качественные системные администраторы или, по крайней мере, меньшее количество системных администраторов с доступом к веб-серверам. Если это вопрос паранойи безопасности менеджмента, то может быть более глубокая проблема, касающаяся их способности доверять системному администратору.
Это не означает, что вы должны просто позволить всем иметь доступ к закрытому ключу. Перед предоставлением доступа всегда должна быть потребность в доступе. Имея это в виду, собираетесь ли вы принять крайние меры, чтобы убедиться, что системный администратор с полным контролем над веб-сайтом не может экспортировать закрытый ключ, но по-прежнему может манипулировать самим веб-сайтом любым количеством практически не отслеживаемых способов? Мы вернулись к доверию, и я думаю, что это суть проблемы, которую необходимо решить.
Когда вы импортируете ключ, у вас есть возможность пометить его как неэкспортируемый. Это предотвратит использование IIS или сертификата MMC для его экспорта. По крайней мере, немного усложняет задачу.
Однако, если у них есть учетная запись администратора на машине или физический доступ к ней, они все равно смогут получить ключ другими способами.
Здесь может помочь «промежуточный центр сертификации».
«Корневой центр сертификации» в этом примере ниже принадлежит компании SSL, а не вам.
У вас нет прямого управления ключами, созданными корневым ЦС, поэтому, если ключ, подписанный корневым ЦС, будет скомпрометирован, вам придется пройти через них, чтобы отозвать его.
Но:
Root CA (SSL company)
|
+-Intermediate CA (You)
|
+-Server Key for site
Если вы поместите другой ЦС посередине и ваш купленный сертификат SSL подписал свой собственный сертификат ЦС вместо прямой подписи сертификата сервера, вы можете сохранить контроль над сертификатами сервера ниже и выдавать сертификаты отзыва или делать что-то еще, если что-то ниже него скомпрометировано .
Вы храните закрытый ключ промежуточного ЦС при себе, и администраторам не нужно его видеть.
Вы также можете сделать это:
Root CA (SSL company)
|
+-Intermediate CA (You)
|
+-Server Key 1 for site
+-Server Key 2 for site
+-Server Key 3 for site
Вы можете подготовиться к компрометации и заранее сгенерировать сертификаты, чтобы быстро переключиться в случае отзыва отдельного ключа. Администраторы не получают ключи для 2 или 3 до компрометации 1. Вы можете разместить на своем сайте уведомление об этой схеме, и это также сообщит вашим администраторам, что вы готовы в случае компромисса, и об этом забавном деле с их конец не разрушит ваш сайт.
Есть много статей, в которых предлагается хранить закрытые ключи где-нибудь, кроме сервера, но эти закрытые ключи предназначены для сертификаты подписи кода. Представьте, что у вас есть ключи на автономном компьютере, доступ к которому есть только у вас, написано какое-то программное обеспечение, вы получаете закрытый ключ с автономного сервера, подписываете код, а затем вам больше не нужен закрытый ключ, пока вам не понадобится его подписать. код снова.
Лучшим решением всегда было и будет хранить ключ в автономном режиме. Как вы это сделаете, полностью зависит от вас (есть несколько методов), просто не забудьте держать его в надежном месте в офисном сейфе или в другом месте, которое кому-то будет непросто положить в карман.
Подробнее на: https://www.thesslstore.com/blog/heres-what-happens-when-your-private-key-gets-compromised/
Напротив, сертификаты SSL предназначены для веб-сайтов, чтобы обеспечить связь по протоколу HTTPS: закрытый ключ требуется во время каждого рукопожатия веб-сервером. Следовательно, хранить его в автономном режиме не получится.