Являются ли сертификаты полезными для протокола Intranet?

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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