Насколько мне следует беспокоиться о незащищенном HTTP-протоколе в «частной» сети?

Насколько мне следует беспокоиться о незащищенном HTTP-протоколе в «частной» сети?

Поэтому я присоединился к новой команде, которая разрабатывает и управляет сервисом, доступным в Интернете. Он нацелен на использование B2B, а не на потребителя, хотя любой может зарегистрироваться для получения учетной записи низкого уровня, чтобы проверить его (вы ничего не добьетесь, если разработчики ваших потенциальных клиентов не смогут сыграть до того, как костюмы подпишут сделку!).

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

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

Это мой первый опыт управления общественной службой, до сих пор я работал в мире «упаковки», где мы продаем программное обеспечение, но наши клиенты устанавливают и запускают его. Поэтому я не чувствую, насколько это плохо. Я собираюсь поднять этот вопрос и попытаться исправить его, но я хотел, чтобы это управлялось сообществом с большим опытом управления производственными службами, чтобы откалибровать, насколько громко я должен кричать. Это действительно ужасно и нам следует все бросить, пока это не исправят, или это нехорошо, но на самом деле не так уж и редко встречается в реальности?

Пишу как гость, так как не хочу давать никаких подсказок о том, чья это услуга :)

решение1

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

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

SSL (включая HTTPS) на проводе предоставляет две услуги: шифрование и аутентификацию. Шифрование не обеспечивает защиты от этой модели угроз: при условии, что внутренняя сеть переключена, злоумышленник может видеть только трафик к и от скомпрометированного сервера. Поскольку это конечная точка SSL, он(а) сможет прочитать весь этот трафикв любом случаеАутентификация дает небольшое преимущество, но это всего лишь след: даже если они не использовали обычные самоподписанные сертификаты (которые, как правило, сводят на нет аутентификацию), вы можете быть достаточно уверены, что действительно общаетесь с внутренними серверами, поскольку вы контролируете внутреннюю сеть, а модель угроз не предусматривает проникновение в сетевую инфраструктуру.

Короче говоря: вы пишете, что "Если один из серверов будет скомпрометирован, его доступ к внутренней сети означает, что остальные станут легкой добычей.". Это верно,но это не менее верно, потому что внутренние перекрестные помехи зашифрованы.

Когда вы прокомментируете Райану выше, что "доступ из офиса к размещенной частной локальной сети осуществляется через VPN, а операции на производственной службе выполняются с выделенных ноутбуков Linux, а не с основных машин разработчиков", я вижу компанию, которая на самом деледумаяо моделях угроз и ответах, а не размахивать криптографией как каким-то блестящим защитным одеялом и предполагать, что теперь они в безопасности, потому что криптография. Похоже, они усердно работают над тем, чтобы защитить те части, которые выигрывают от безопасности, и не парятся о тех частях, которые не выигрывают.

решение2

У меня был долгий разговор об этом с моим другом. Все сводится к тому, что вы делаете, и как выглядит ваша сеть.

В целом: Это плохо.

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

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

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

Связанный контент