Пристап од 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: одлучете каде идентитетот станува политика
Некој мора да претвори автентифицирана сесија во улога што порталот може да ја спроведе. Поддржаните опции вклучуваат групна политика што ја доставува автентикацискиот backend, доверливи атрибути на сесијата или одделни базени на адреси по улога. Сите три работат; ознаката што ја праќа клиентот не. Изберете го механизмот што го документира вашиот портал, а не оној што го опишува објава на форум.
Доделувањето адреса што само изгледа како да припаѓа на 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'Негативен случај што се поврзува е наод, а не случајност, и неговото место е во матрицата како неуспешна ќелија додека правилото не се поправи. Чувајте ги тест-командите до табелата за следниот рецензент да ги пушти повторно наместо да го гради расудувањето одново.
Готовата табела го надживува порталот за кој е напишана. Правилата се менуваат со фирмверот и добавувачот, додека редот што вели дека изведувач стигнува до една проектна услуга останува вистинит додека таа работа не се смени.