GDOI: чому сервер ключів не перебуває на шляху ваших даних

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

Два види стану безпеки

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

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

Стежте за обмінами, а не за схемою

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

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

Три записи, які варто зберігати

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

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

Інтерфейс, підключення служби, шлях обробки

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

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

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

Доступність керування й пересилання даних — окремі перевірки

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

Потім перевірте пересилання окремо, без контролера. Дві перевірки, два результати й значно коротша суперечка про те, яка половина зламана.