Все ли серверы должны использовать протокол HTTPS или только общедоступные серверы?
У меня есть интерфейсный веб-сервер, работающий по HTTPS - это общедоступный, т.е. порт открыт.
У меня также есть внутренний сервер API, на который мой веб-сервер отправляет запросы API - он общедоступен и требует аутентификации - порт открыт.
Эти 2 сервера работают через HTTPS.
За сервером API находится множество других серверов. Сервер API обратный прокси к этим серверам. Порты для этих других серверов не открыты для входящего трафика. С ними можно разговаривать только через сервер API.
Мой вопрос ... Нужно ли «многим другим серверам» работать через HTTPS или, учитывая, что к ним нельзя получить внешний доступ, могут ли они вместо этого безопасно работать через HTTP?
Я думал, что это будет частый вопрос, но не смог найти на него ответа. Спасибо. Если это обман, пожалуйста, дайте мне правильный ответ.
Это вопрос личного мнения, и он также имеет отношение к нормативным вопросам (если вы столкнетесь с ними).
Даже если в настоящее время в этом нет необходимости, я сторонник того, чтобы HTTPS оставался включенным между любыми межсетевыми экранами / балансировщиками нагрузки / интерфейсными серверами уровня приложений и внутренними серверами. Это на одну поверхность меньше для атаки. Я заключил контракт с местами, которые нужно было преобразовать по мере того, как стала передаваться более конфиденциальная информация - лучше начать с них.
Обычно я предлагаю использовать внутренний CA (если он доступен) или самоподписанный (если нет внутреннего CA) внутренние серверы. Мы бы установили дату истечения срока действия на будущее, чтобы избежать ненужных изменений.
TL; DR , вам следует зашифровать трафик , если он не находится на том же хосте.
Вы не можете доверять своему сеть. Вредоносные программы в вашей собственной сети могут перехватывать / изменять http-запросы.
Это не теоретические атаки, а реальный пример:
Маршрутизаторы (возможно, взломанные) внутри сети некоторых веб-сайтов, размещающих рекламу: https: // www .blackhat.com / docs / us-16 / materials / us-16-Nakably-TCP-Injection-Attacks-in-the-Wild-A-Large-Scale-Study-wp.pdf
Индийская сеть, перехватывающая между облачными технологиями и бэкэнд: (скрыто) теперь известный «SSL добавлен и удален здесь :-)» от АНБ
Нужно ли «многим другим серверам» работать через HTTPS или, учитывая, что к ним нельзя получить внешний доступ, можно ли вместо этого безопасно работать через HTTP?
Это действительно зависит от того, что вы пытаются достичь. Поймите, что цель использования HTTPS - защитить данные при передаче между двумя точками. Если вас беспокоит, что данные перехватываются внутри вашей сети, возможно, об этом следует позаботиться в первую очередь. Если вам необходимо защитить данные, передаваемые внутри вашей сети, вы говорите, что либо у вас есть озабоченность по поводу безопасности данных, проходящих через ваши системы внутри вашей сети, либо у вас есть причина, связанная с соблюдением требований, для шифрования данных в пути.
Это скорее вопрос общественного мнения, но ответ зависит от обстоятельств. Что ты пытаешься сделать? Какие данные вы шифруете? От каких угроз вы пытаетесь защищаться? Есть ли у вас юридическое требование (например, PCI-DSS, HIPAA и т. Д.), В котором говорится, что вам нужно шифровать данные при передаче? Если данные являются конфиденциальными и вы обеспокоены тем, что они могут быть использованы не по назначению при передаче внутри вашей сети, я бы предложил вместе с руководством решить проблему. Итак, в конце концов, что вы пытаетесь защитить и почему вы пытаетесь это защитить?
В свое время люди полагали, что внутренние сети безопасны, как дома. Однажды у меня возник спор с руководителем, который был потрясен тем, что на моих внутренних серверах были установлены встроенные брандмауэры. «Если вы не можете доверять своей внутренней сети, кому вы можете доверять?» Я указал, что у нас есть студенческие ноутбуки во внутренней сети, и что между студенческими ноутбуками и моими серверами не было межсетевого экрана. Он, будучи новичком в академических кругах, казалось, из-за этой информации расколол свою вселенную.
Внутренние сети больше не считаются безопасными, даже если в вашей сети нет студенческих ноутбуков. См. Ответ Тома для некоторых примеров.
Тем не менее, да, это зависит от того, какая информация передается, от каких-либо проблем с соблюдением законодательства и т. Д. Вы можете решить, что вам все равно, если кто-то обнюхивает, скажем, данные о погоде. Тем не менее, возможно, что даже если отправленные данные не являются конфиденциальными сейчас , кто-то может позже добавить в ваше приложение функции, которые являются чувствительными, поэтому я бы рекомендовал более серьезную паранойю ( включая HTTPS).
Сегодня со специализированными инструкциями ЦП для ускорения шифрования и новыми транспортными протоколами, которые вообще не работают или работают с пониженной производительностью по незашифрованному каналу (HTTP / 2, gRPC и т. Д.) , возможно, лучший вопрос: есть ли причина, по которой вам нужно понизить сетевую ссылку до HTTP? Если нет конкретной причины, то оставайтесь с HTTPS.
Единственная причина для отключения шифрования я могу думать о производительности. Однако в вашем случае внутренние серверы взаимодействуют через HTTP, что означает, что они уже несут затраты на производительность работы веб-сервера,поддержка протокола HTTP и кодирования данных в HTTP / JSON / что угодно. Отключение шифрования освободит, возможно, 100 КБ ОЗУ и принесет вам несколько микросекунд на КБ передаваемых данных, что не окажет видимого влияния на общую производительность. С другой стороны, вам придется уделять гораздо больше внимания безопасности, поскольку теперь вы используете HTTP в своей интрасети. Фактически, вполне возможно, что более строгая конфигурация брандмауэра замедлит работу больше, чем отключение шифрования ускорило ее, что приведет к ухудшению производительности, воспринимаемой конечными пользователями.
Это будет похоже на установку спойлера на трактор: вы получите почти теоретически ничего, а на практике много неудобств.