Централізуйте доступ партнерів через VPN, не об'єднуючи самих партнерів

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

Почніть з договору, який кожен партнер уже підписав

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

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

Маршрутизуйте за контекстом, а не лише за призначенням

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

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

Там, де відповідь так, контекст маршрутизації стає тим, що ви документуєте й тестуєте, бо в traceroute він не видно.

Вирішіть, що вводить працівник і що журналює партнер

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

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

Явно забороніть транзит між партнерами

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

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

Ведіть це як спільну послугу, а не як більший ноутбук

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

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

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