Все ли серверы должны использовать протокол HTTPS или только общедоступные серверы?

Это вопрос личного мнения, и он также имеет отношение к нормативным вопросам (если вы с ними столкнетесь).

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

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

TL; DR вы должны зашифровать трафик если только он не на том же хосте.

Вы не можете доверять своей сети. Вредоносные программы в вашей собственной сети могут перехватывать / изменять HTTP-запросы.

Это не теоретические атаки, а пример из реальной жизни:

• Маршрутизаторы (возможно, взломанные) внутри сети некоторых сайтов, которые вводят рекламу: https://www.blackhat.com/docs/us-16/materials/us-16-Nakible-TCP-Injection-Attacks-in-the-Wild-A-Large-Scale-Study-wp.pdf

• Индийская сеть, перехватывающая между облачным сервисом и серверной частью: https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know-it-90935f7f6d98#.hymc3785e

• Теперь знаменитый «SSL добавлен и удален здесь :-)» от АНБ

Нужно ли «множеству других серверов» работать по HTTPS или, учитывая, что к ним нельзя получить доступ извне, можно ли вместо этого безопасно работать по HTTP?

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

На самом деле это скорее вопрос мнения, но ответ зависит от обстоятельств. Что ты пытаешься сделать? Какие данные вы шифруете? От каких угроз вы пытаетесь защищаться? Есть ли у вас юридическое требование (например, PCI-DSS, HIPAA и т. Д.), В котором говорится, что вам нужно шифровать данные при передаче? Если данные являются конфиденциальными и вы обеспокоены тем, что они могут быть использованы не по назначению при передаче внутри вашей сети, я предлагаю вместе с руководством решить проблему. Итак, в конце концов, что вы пытаетесь защитить и почему вы пытаетесь это защитить?

В свое время люди полагали, что внутренние сети безопасны, как дома. Однажды у меня возник спор с руководителем, который был потрясен тем, что на моих внутренних серверах были установлены встроенные брандмауэры. «Если вы не можете доверять своей внутренней сети, кому вы можете доверять?» Я указал, что у нас есть студенческие ноутбуки во внутренней сети, и что между студенческими ноутбуками и моими серверами не было межсетевого экрана. Он, будучи новичком в академических кругах, казалось, из-за этой информации расколол свою вселенную.

Внутренние сети больше не считаются безопасными, даже если в вашей сети нет студенческих ноутбуков. См. Ответ Тома для некоторых примеров.

Тем не менее, да, это зависит от того, какая информация передается, от каких-либо проблем с соблюдением законодательства и т. Д. Вы можете решить, что вам все равно, если кто-то обнюхивает, скажем, данные о погоде. Тем не менее, возможно, что даже если отправленные данные не являются конфиденциальными сейчас, кто-то может решить добавить в ваше приложение функции позже, являются чувствительный, поэтому я бы рекомендовал более сильную паранойю (включая HTTPS).

Сегодня со специализированными инструкциями ЦП для ускорения шифрования и новыми транспортными протоколами, которые вообще не работают или работают с пониженной производительностью по незашифрованному каналу (HTTP / 2, gRPC и т. Д.), Возможно, лучший вопрос: есть ли какие-либо Причина, по которой вам нужно понизить сетевую ссылку до HTTP? Если нет конкретной причины, то оставайтесь с HTTPS.

Единственная причина отключить шифрование, о которой я могу думать, - это производительность. Однако в вашем случае внутренние серверы связаны через HTTP, что означает, что они уже несут затраты на производительность работы веб-сервера, поддержки протокола HTTP и кодирования данных в HTTP / JSON и т.д. Отключение шифрования освободит, возможно, 100 КБ ОЗУ и принесет вам несколько микросекунд на КБ передаваемых данных, что не окажет видимого влияния на общую производительность. С другой стороны, вам придется уделять значительно больше внимания безопасности, поскольку теперь вы используете HTTP в своей интрасети. Фактически, вполне возможно, что более строгая конфигурация брандмауэра замедлит работу больше, чем отключение шифрования ускорит ее, что приведет к ухудшению производительности, воспринимаемой конечными пользователями.

Это как поставить спойлер на трактор: теоретически вы почти ничего не получите, а практически - много неудобств.