Шифрований транзит не дає доступу до оператора

Два схвалені шлюзи переносять трафік мережі з меншою довірою через обмежену транспортну мережу. Шифрування корисного навантаження робить його нечитабельним для звичайних спостерігачів транзиту, і саме цю частину люди проєктують першою, а потім перестають про неї думати. Чого шифрування не робить — воно не визначає, до яких ресурсів може звертатися сторона з меншою довірою. Проєкту потрібні дві межі: одна навколо розмови, що переноситься, і одна навколо доступу до самого оператора.

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

Визначте обидві межі, перш ніж торкатися конфігурації

Перша межа — це розмова: які пари шлюзів можуть установити тунель і який внутрішній трафік допускається через нього. Друга — оператор: яких адрес і сервісів хости з меншою довірою можуть досягти поза тунелем. Команди зазвичай будують першу, а другу успадковують від будь-якої наявної маршрутизації, і так обмежений проєкт тихо стає широким. Це успадкування — звичайна першопричина, коли перевірка виявляє хост з меншою довірою, що розмовляє з чимось, чого ніхто не схвалив.

Запишіть обидві як списки адрес, портів і напрямків. Якщо список неможливо записати, межа ще не визначена.

Крок 1: обмежте зовнішній тунель

На інтерфейсі, зверненому до оператора, дозвольте лише те, що потрібно тунелю: IKE на UDP 500 і 4500 між двома адресами шлюзів і ESP там, де не використовується обхід NAT. Відхиляйте все інше, що надходить на цей інтерфейс, включно з протоколами керування. Специфікація ESP описує служби захисту; вона нічого не каже про те, якими власними сервісами оператора можуть користуватися шлюзи. Виразіть це як явний список дозволів, щоб нещодавно опублікований сервіс оператора не став доступним за замовчуванням.

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

Перевірте це з боку з меншою довірою, а не з консолі шлюзу. Хост там має не мати змоги досягти DNS-сервера оператора ще до підняття тунелю.

Крок 2: вирішіть, що доставляє дальній шлюз

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

Схема, що зупиняється на успішному розшифруванні, пропустила найважливіше рішення.

Крок 3: збережіть володіння за кожним шаром

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

Призначте власника кожному шару. Шари без власника — ті, що дрейфують.

Крок 4: перевірте, а потім передайте це органу

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

Для регульованих або таємних середовищ віднесіть проєкт до відповідального органу безпеки й використайте його схвалену архітектуру розділення. Конфігурація VPN і концептуальне пояснення не створюють акредитації. Цей крок — не паперова робота; він вирішує, чи проєкт узагалі може існувати.