Правила 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.

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