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

Служителите трябва да достигат до едно приложение във VPC и не трябва да достигат до слушателя на базата данни на същия инстанс, затова някой добавя втора публична подмрежа за endpoint на VPN и обявява изискването за изпълнено. Разположението на подмрежата променя маршрутизацията и наличността. То не дава и не отнема нито един порт. Разрешението, което изразява изискването, живее в дестинацията, в групата за сигурност на ресурса, а границата на VPN предоставя дръжката, към която се отнася това правило.

Разположението на подмрежата е маршрутизация, не оторизация

Къде се намира мрежовото свързване на endpoint определя коя таблица на маршрутизация носи трафика на клиентите и кои зони за наличност оцеляват при отказ. То не казва нищо за това кой порт на кой инстанс може да достигне този трафик. Два клиента, свързани с една и съща подмрежа, пристигат с една и съща идентичност на източника и ресурсът не може да ги различи по име на подмрежа.

Започнете вместо това от изискването: кой се обажда, кой ресурс, кой порт на услугата и коя посока. След това изберете модела на правило, който може да изрази тези четири неща в дестинацията. Тази рамка обикновено премахва изцяло допълнителната подмрежа от дизайна.

Групата за свързване на Client VPN е дръжката

За свързан с подмрежа endpoint на AWS Client VPN документираната подредба е конкретна. Приложете предвидената група за сигурност към свързванията на целевата мрежа на endpoint, след което разрешете необходимия трафик в групата за сигурност на ресурса, използвайки тази група на Client VPN като източник.

Конкретно, групата на инстанса на приложението разрешава порта на приложението от групата за свързване и нищо друго. Процедурата за достъп до ресурс на AWS описва тази връзка и си струва да се поддържа една и съща групова политика във всяка подмрежа, с която endpoint се свързва, защото остаряло свързване с различна група тихо разширява границата.

Това правило не удостоверява никого. Влизането е отделна контрола, а маршрутът до ресурса е трета. И трите трябва да са налице, преди заявката да пристигне. Кое от тях се проваля определя коя поправка е правилна, а промяната на правило е правилният отговор само за първото.

Какво не може да различи една група за свързване

Всеки клиент зад една и съща група за свързване достига до ресурса като един и същ източник на група за сигурност. Двама потребители с различни роли са неразличими на този слой, независимо как е именувана или маркирана групата. Оторизацията на външни групи в Client VPN ограничава достъпа по префикс на дестинация за група от директория или SAML, което е по-грубо от роля на ресурс и трябва да се третира като мрежова граница, а не като система за идентичност.

По-фините разграничения принадлежат на приложението. Слушател на база данни, който трябва да остане затворен за повечето служители, е по-добре защитен, като изобщо не е достъпен на разрешения префикс, отколкото като се надяваме членството в групата да остане подредено.

Преименуването на групата не създава идентичност, а дублирането ѝ за всеки екип само умножава свързванията за одит.

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

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

Препречването на трафик през междинно устройство не запазва референция към група за сигурност на източника така, както прави директният трафик между инстанси. AWS документира, че такива дизайни може да се нуждаят от подходящи частни адреси на източника или CIDR вместо референция към група. Процедурата за управляван Client VPN не е доказателство, че прикачената група на всеки шлюз работи като универсален токен за идентичност за препратени пакети.

Един NAT скок по пътя е достатъчен да счупи предположението и отказът изглежда като правило, което присъства, но никога не съвпада.

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

Прочетете всяка група за сигурност, прикачена към ресурса, защото правилата за разрешаване се комбинират и тясно правило не отменя по-широко в друга група. След това проверете мрежовия ACL, защитната стена на хоста и собствената оторизация на приложението, които са отделни слоеве с отделни грешки.

Завършете с една разрешена заявка и една умишлено изключена заявка към същия ресурс. Двойката доказва границата, докато едно успешно свързване доказва само, че нещо е отворено. Потвърдете маршрута, ефективния източник и предвидения порт на услугата, а не подмрежата, която съдържа endpoint.

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