Достъп от 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'Негативен случай, който се свързва, е находка, а не случайност, и мястото му е в матрицата като провалена клетка, докато правилото не се поправи. Дръжте тестовите команди до таблицата, за да ги пусне следващият рецензент, вместо да изгражда разсъждението наново.
Готовата таблица живее по-дълго от шлюза, за който е написана. Правилата се менят с фърмуера и доставчика, докато редът, който казва, че изпълнител достига до една проектна услуга, остава верен, докато тази работа не се промени.