Доступ із VPN до VLAN: спочатку матриця, потім правила
Ролі з одного боку, сервіси з іншого. П'ять перевірок перетворюють розпливчастий проєкт доступу з VPN до VLAN на таблицю, яку власник міжмережевого екрана може впровадити.
Почніть із матриці, а не із синтаксису міжмережевого екрана. Таблицю, де ролі з одного боку, а сервіси з іншого, може переглянути власник застосунку, обговорити власник безпеки й упровадити той, хто тримає шлюз. Цей огляд дешевший за налагодження правил, про які ніхто не домовився.
Година написання економить потім тиждень археології правил. Проєкт говорить про те, хто до якого сервісу доходить, і саме ця частина переживає перенумерацію.
Крок 1: назвіть ролі до мереж
Почніть з людей, а не з комутатора. Запишіть кожну групу, яка підключається віддалено, і одне речення про те, чим ця група займається, наприклад працівники складу, які читають рівні запасів, або підрядник, який підтримує одну інтеграцію. Якщо дві групи отримали б однаковий доступ, для цієї мети вони одна роль.
Зупиніться тут, якщо роль існує лише через організаційну схему. Роль без власної потреби в сервісі стає рядком однакових клітинок, а однакові рядки підштовхують когось згодом видати цілу підмережу заради зручності. Діліть за тим, що роблять люди, а не за тим, хто підписує їхні витрати. Шість ролей зазвичай забагато для малого офісу, а три часто правильні.
Крок 2: перетворіть кожну клітинку на твердження про сервіс
Клітинка з написом «Застосунки» не перевіряється. Клітинка з написом «HTTPS до хоста ERP на 443, із пулу працівників» перевіряється. Замініть кожну назву мережі на призначення, протокол і порт, потім додайте залежність, без якої сервіс не працює, наприклад внутрішній резолвер або постачальник ідентичності.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Стовпець напрямку ловить найдорожчі помилки. Дозвіл працівникам відкривати застосунок не означає дозволу серверам застосунків відкривати з'єднання назад до ноутбуків працівників, а правило зі станом, яке дозволяє перший напрямок, часто читають як дозвіл другого.
Крок 3: вирішіть, де ідентичність стає політикою
Хтось має перетворити автентифіковану сесію на роль, яку шлюз може забезпечити. Підтримувані варіанти включають групову політику від бекенду автентифікації, довірені атрибути сесії або окремі пули адрес для кожної ролі. Усі три працюють; мітка, яку надсилає клієнт, ні. Виберіть механізм, який документує ваш шлюз, а не той, який описує повідомлення на форумі.
Призначення адреси, яка лише виглядає як така, що належить VLAN, — та сама невідповідь в іншому костюмі. Посібник Netgate з правил міжмережевого екрана OpenVPN робить розділення ясним: дозволити тунелю піднятися — інше рішення, ніж дозволити трафіку пройти крізь нього.
Запишіть, який механізм ви обрали і де він налаштований. Коли роль змінюється, ця нотатка — різниця між однією правкою і пошуком у трьох інтерфейсах. Вона також каже аудитору, куди дивитися насамперед.
Крок 4: стежте за адресою джерела, яку бачить призначення
Політика переспрямування має відповідати реальному джерелу на межі. Якщо шлюз транслює VPN-клієнтів у власну адресу, кожен нижчий міжмережевий екран бачить одне джерело і втрачає здатність вирішувати за роллю. Якщо він зберігає адресу клієнта, зворотний шлях має існувати для цього пулу.
Перевірте обидва напрямки, перш ніж писати остаточні правила, потім запишіть спостережене джерело біля кожної клітинки. Запустіть ту саму перевірку з двох різних ролей і порівняйте результат. Якщо обидві показують адресу шлюзу, розрізнення ролей уже втрачено. Матриця, яка припускає збережені адреси, поки шлюз виконує трансляцію джерела, падає на першому нижчому ACL.
Крок 5: перевірте кожну клітинку перед випуском
Перетворіть кожну дозволену клітинку на одну представницьку операцію, а кожну заборонену клітинку на негативний випадок. Запустіть обидві з клієнта в реальній ролі, а не з консолі шлюзу, бо консоль обходить шлях, який ви перевіряєте.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Негативний випадок, який підключається, — це знахідка, а не випадковість, і його місце в матриці як невдалої клітинки, доки правило не виправлено. Тримайте тестові команди біля таблиці, щоб наступний рецензент запустив їх знову, а не вибудовував міркування заново.
Готова таблиця живе довше за шлюз, для якого написана. Правила змінюються разом із прошивкою та постачальником, а рядок про те, що підрядник доходить до одного проєкту, залишається правдивим, доки ця робота не зміниться.