Чи всі сервери повинні використовувати протокол HTTPS або просто загальнодоступні сервери?

У мене веб-сервер на передньому кінці працює над HTTPS - це відкрите обличчя - тобто порт відкритий.

У мене також є сервер API бекенда, на якому мій веб-сервер робить запити API - це відкрите обличчя і вимагає автентифікації - порт відкритий.

Ці 2 сервери працюють через HTTPS.

За сервером API - безліч інших серверів. Сервер API повертає проксі-сервери до цих серверів. Порти для цих інших серверів не відкриті для вхідного трафіку. З ними можна спілкуватися лише через сервер API.

Моє запитання ... Чи потрібно "багато інших серверів" переходити через HTTPS або, враховуючи, що до них не можна отримати доступ іззовні, вони можуть безпечно працювати через HTTP?

Я думав, що це буде звичайним питанням, але я не міг знайти відповіді на нього. Спасибі. Якщо це дупа, будь ласка, вкажіть мене на правильну відповідь.

Це питання думки, а також стосується регуляторних питань (якщо ви стикаєтесь з ними).

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

Як правило, я б запропонував використовувати внутрішній сервер CA (якщо такий є) або підписати самоврядування (якщо немає внутрішнього ЦЗ) задніми серверами. Ми встановимо термін придатності приємно і далеко в майбутнє, щоб уникнути зайвих змін.

TL; DR ви повинні зашифрувати трафік, якщо він не знаходиться на одному хості.

Ви не можете довіряти своїй мережі. Зловмисне програмне забезпечення у вашій власній мережі може перехоплювати / змінювати запити http.

Це не теоретичні атаки, а приклад із реального життя:

• Маршрутизатори (ймовірно зламані) всередині мережі деяких веб-сайтів, які вводять рекламу: https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-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 у своїй інтрамережі. Насправді можливо, що більш сувора конфігурація брандмауера сповільнить роботу більше, ніж відключення шифрування прискорить їх, в результаті чого кінцеві користувачі сприймуть більш низьку продуктивність.

Це буде як поставити спойлер на трактор: ви отримуєте майже нічого теоретично, і багато незручностей практично.