Полезны ли сертификаты для интрасети SSL?

мне было поручено разработать интерфейс интрасети для программного обеспечения командной строки, и теперь я изучаю варианты безопасности. Наше приложение командной строки завершено, но я еще не начал писать веб-интерфейс. Я не знаю точно, каковы требования безопасности для потенциальных клиентов, хотя я считаю ssh обычно приемлемо для интерфейса командной строки. Имея это в виду, я прошу помочь разработать меню и связанные с ними плюсы/минусы. Когда-нибудь мы, возможно, решим выпустить наш веб-интерфейс в интернет, поэтому я готов рассмотреть больше безопасности, чем в настоящее время необходимо, если это легко и/или бесплатно.

Я много читал, и мой предварительный вывод заключается в том, что безопасность SSL без сертификата-лучший подход, не потому, что меньшая безопасность неприемлема, а потому, что SSL является стандартом и потому, что это не кажется сложным для настройки. Мне, не эксперту по безопасности, не нужно объяснять, почему меньше безопасность приемлема для не экспертов по безопасности. Я мог бы обновить свое приложение, чтобы использовать сертификат в будущем, если это необходимо.

вот список связанных с SSL вариантов безопасности, отсортированных по моему восприятию уровня безопасности с моими комментариями. Какой уровень защиты нужен?

  1. нет SSL. это может быть приемлемо, если наши клиенты не беспокоятся о том, что их сотрудники видят/изменяют данные друг друга. Их сотрудники могут захотеть поделиться результаты друг с другом в любом случае, и я мог бы использовать управление доступом на основе IP и/или пароли для безопасности.

  2. выполнить SSL без сертификата. это шифрует сообщение, которое по крайней мере защищает данные от чтения неавторизованными сотрудниками. Используя пароль, это тот же уровень безопасности, что и ssh в командной строке, верно? Мне не нужно беспокоиться об атаках "человек в середине" в интранете, верно? А вот подход будет, если было множество предупреждающих сообщений браузера.

  3. сделайте SSL с самозаверяющим сертификатом. что это дает мне, что ни один сертификат не дает мне? Если DNS может быть изменен ненадлежащим образом, то клиент, то мое приложение является наименьшей из их проблем. Адрес другой способ, если DNS может измениться, то я думаю ssh тоже будет уязвимым.

  4. сделайте SSL с локальным центром сертификации. в OpenSSL позвольте мне создать свой собственный центр сертификации. Что это дает мне, чего не дает самозаверяющий сертификат? Я предполагаю, что в локальной сети менее важно, чтобы сервер был проверен.

  5. сделайте SSL с внешним центром сертификации. есть ли когда-нибудь причина идти по этому маршруту для интрасети? Я нашел несколько "сертификатов интрасети" для продажи в интернете, но неясно, что они предлагают, я не могу сделать сам.

для ссылка, эта страница может быть полезна для сравнения сертификатов:

http://httpd.apache.org/docs/trunk/ssl/ssl_faq.html#aboutcerts

[обновление]

здесь статья обсуждает риски и правила получения внутреннего сертификата из ЦС.

2 ответов


да, сертификаты по-прежнему полезны для интрасети SSL.

существует важное различие между SSH и SSL-без-сертификата: при первом подключении к серверу с SSH ваш SSH хранит отпечаток сервера. Если вы затем попытаетесь подключиться к тому, что клиент SSH считает той же машиной, но возвращает другой отпечаток пальца, он предупреждает Вас, что может быть кто-то перехватывает ваши сообщения.

протокол SSL-без-а-сертификат, на другие рука, не хранит отпечаток пальца сервера. Ваши сообщения будут зашифрованы, но если кто-то перехватывает DNS-сервер, как вы упомянули, или, как Rushyo Примечания, делает отравление ARP или что-то подобное, они могли бы выполнить атаку человека в середине. SSH, как упоминалось ранее ,будет (предположим, вы подключились к правильному серверу некоторое время в прошлом) заметить, что отпечаток пальца изменился и предупредить вас.

самоподписанный сертификат будет сопоставим по безопасности с SSH. Человек в среднем может создать собственный самозаверяющий сертификат, но пока ваши приложения настроены только на прием это самозаверяющий сертификат, вы должны получить предупреждение, подобное тому, что даст вам SSH.

локальный центр сертификации обеспечивает безопасность, аналогичную самозаверяющим сертификатам, но может быть более масштабируемой. Если у вас несколько серверов, каждый может иметь свой собственный сертификат, но клиенту нужен только тот, кто на высшем уровне, чтобы доверять им всем. Если сервер скомпрометирован, вы можете отозвать его сертификат, а не изменять сертификат каждого сервера.

Я не считаю, что внешний центр сертификации имеет какие-либо преимущества, кроме, возможно, меньше конфигурации, если ваши машины уже имеют доверенный центр сертификации.

наконец, я недостаточно знаю о двухфакторной аутентификации, чтобы оценить ее, но для большинства приложений SSL должна быть достаточной.

отказ от ответственности: я не эксперт по безопасности.


  1. сделайте SSL с внешним центром сертификации. Есть ли когда-нибудь причина идти по этому маршруту для интранета? Я нашел несколько "сертификатов интрасети" для продажи в интернете, но неясно, что они предлагают, я не могу сделать сам.

преимущество в том, что вам не нужно учиться настраивать собственный центр сертификации, если вам нужно управлять приличным количеством сертификатов и/или машин. Такому сертификату уже доверяли бы все браузеры без необходимости установки собственных сертификатов в доверенное хранилище.

, это на самом деле менее безопасно, потому что кто-то может приобрести сертификат для другой интрасети и использовать его в вашей сети. По этой причине, поставщики SSL больше не предлагают эту услугу. Дополнительные сведения см. В разделе: https://www.godaddy.com/help/phasing-out-intranet-names-and-ip-addresses-in-ssls-6935

если у вас только очень маленький затем я бы рекомендовал использовать самозаверяющий сертификат, а затем просто добавить каждый самозаверяющий сертификат в доверенное хранилище каждого компьютера.

однако быстро становится непрактичным устанавливать новый сертификат на каждом компьютере в интрасети всякий раз, когда вы хотите добавить новый компьютер. На этом этапе необходимо настроить собственный центр сертификации, чтобы установить только один сертификат CA в доверенном хранилище каждого компьютера.