Доступ ад 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'
Адмоўны выпадак, які злучаецца, — гэта знаходка, а не выпадковасць, і яго месца ў матрыцы як праваленай ячэйкі, пакуль правіла не выпраўленае. Трымайце каманды тэсту побач з табліцай, каб наступны рэцэнзент перазапусціў іх замест таго, каб будаваць разважанне нанова.
Гатовая табліца жыве даўжэй за шлюз, для якога яна напісаная. Правілы змяняюцца разам з прашыўкай і пастаўшчыком, а радок, які кажа, што падрадчык даходзіць да аднаго сэрвісу праекта, застаецца праўдзівым, пакуль гэтая праца не зменіцца.