Правилата на AWS Client VPN припаѓаат на ресурсот, а не на подмрежата

Вработените треба да достигнат до една апликација во VPC и не смеат да достигнат до слушателот на базата на податоци на истиот примерок, па некој додава втора јавна подмрежа за endpoint-от на VPN и го прогласува барањето за исполнето. Местоположбата на подмрежата го менува рутирањето и достапноста. Таа не дава и не одзема ниту еден порт. Дозволата што го изразува барањето живее на одредиштето, во безбедносната група на ресурсот, а границата на VPN ја дава рачката на која се однесува тоа правило.

Местоположбата на подмрежата е рутирање, не авторизација

Каде се наоѓа мрежното поврзување на endpoint-от одредува која табела за рутирање го носи сообраќајот на клиентите и кои зони на достапност преживуваат дефект. Тоа не кажува ништо за тоа до кој порт на кој примерок може да стигне тој сообраќај. Два клиенти поврзани со истата подмрежа сепак пристигнуваат со истиот идентитет на извор, и ресурсот не може да ги разликува по името на подмрежата.

Започнете од барањето: кој се јавува, кој ресурс, кој порт на услугата и кој правец. Потоа изберете го моделот на правило што може да ги изрази тие четири работи на одредиштето. Таквиот пристап обично целосно ја отстранува дополнителната подмрежа од дизајнот.

Групата за поврзување на Client VPN е токму таа рачка

За AWS Client VPN endpoint поврзан со подмрежа, документираниот распоред е конкретен. Применете ја предвидената безбедносна група на поврзувањата на целната мрежа на endpoint-от, потоа дозволете го потребниот сообраќај во безбедносната група на ресурсот користејќи ја таа Client VPN група како извор.

Конкретно, групата на примерокот на апликацијата го дозволува портот на апликацијата од групата за поврзување и ништо друго. Постапката за пристап до ресурс на AWS го опишува тој однос, и вреди да се задржи истата групна политика на секоја подмрежа со која се поврзува endpoint-от, бидејќи застарено поврзување со друга група тивко ја проширува границата.

Тоа правило не автентицира никого. Најавувањето е одделна контрола, а патеката до ресурсот е трета. Сите три мора да важат пред да пристигне барање. Кое ќе откаже, тоа одредува кое поправање е точно, а промената на правило е точниот одговор само за првото.

Што не може да разликува една група за поврзување

Секој клиент зад истата група за поврзување достигнува до ресурсот како ист извор на безбедносна група. Двајца корисници со различни улоги се неразличливи на тој слој, како и да е именувана или означена групата. Авторизацијата на надворешни групи во Client VPN го ограничува пристапот по префикс на одредиште за група од директориум или SAML, што е погрубо од улога на ресурс и треба да се третира како мрежна граница, а не како систем за идентитет.

Понежните разлики ѝ припаѓаат на апликацијата. Слушател на база на податоци што мора да остане затворен за повеќето вработени е подобро заштитен со тоа што воопшто не е достапен на дозволениот префикс, отколку со надеж дека членството во групата ќе остане уредно.

Преименувањето на групата не создава идентитет, а нејзиното удвојување по тим само ги умножува поврзувањата што треба да се ревидираат.

Не го копирајте тоа правило во секој дизајн на VPN

Самоуправувана EC2 VPN порта, рутиран уред за проверка и управуван Client VPN се три различни патеки на пакети. Утврдете која изворна адреса навистина достигнува до ресурсот, дали на патот се врши превод и кои референтни механизми ги поддржува услугата на таа патека.

Пренесувањето сообраќај низ посреднички уред не ја зачувува референцата на изворната безбедносна група како што тоа го прави директниот сообраќај меѓу примероци. AWS документира дека таквите дизајни може да бараат соодветни приватни изворни адреси или CIDR наместо референца на група. Постапката за управуван Client VPN не е доказ дека поврзаната група на секоја порта работи како универзален идентитетски токен за пренесените пакети.

Еден NAT скок на патот е доволен да ја скрши претпоставката, а дефектот изгледа како правило што постои, но никогаш не се совпаѓа.

Прегледајте ја ефективната граница

Прочитајте ја секоја безбедносна група поврзана со ресурсот, бидејќи правилата за дозвола се собираат и тесно правило не го поништува поширокото во друга група. Потоа проверете го мрежниот ACL, огнениот ѕид на домаќинот и сопствената авторизација на апликацијата, кои се одделни слоеви со одделни грешки.

Завршете со едно дозволено и едно намерно исклучено барање кон истиот ресурс. Парот ја докажува границата, додека една успешна врска докажува само дека нешто е отворено. Потврдете ја патеката, ефективниот извор и предвидениот порт на услугата, а не подмрежата што го содржи endpoint-от.

Редослед на работа: напишете барањето од четири дела, прикачете ја групата на поврзувањата, ограничете го правилото на ресурсот на портот, проверете едно дозволување и едно одбивање и дури потоа размислете за делење подмрежи поради рутирање.