Приемането на отдалечен достъп през VPC изисква тестове за отказ

Приемането на отдалечен достъп е таблица с очаквани резултати, а не екранна снимка на работеща страница. За всяка група запишете какво трябва да успее и какво трябва да се провали, след което изпълнете и двете срещу отделни тестови идентичности в контролиран прозорец. Отказите са частта, която доказва границата; успешният вход доказва само, че тунелът съществува. Всичко това работи с вече избрания VPN продукт.

Използвайте отделни акаунти за тестовете и ги именувайте така, че никой да не сбърка тестова идентичност с истинско изключение.

Запишете границата като очаквани резултати

Започнете от ролите, а не от компонентите: кой има нужда от коя услуга, откъде и с каква идентичност. Вземете примерна VPC: една група се нуждае от тестова среда през HTTPS, друга — от производствена база данни, а трета и по-малка група администрира самия шлюз. Всеки ред получава очаквано разрешение и очакван отказ, включително съседната услуга и съседния акаунт, които не трябва да работят. Тази таблица е критерият за приемане и хора, които не изпълняват тестовете, могат да я прегледат.

Тествайте входа в базата данни отделно от мрежовия път. Достъпен TCP порт не трябва да прави успешен неодобрен акаунт за база данни и членството във VPN не трябва да създава облачна роля IAM или да дава административен достъп до API. Това са три независими контрола и те се провалят независимо.

Маршрутът не е оторизация

Маршрутът прави пътя възможен; той не дава разрешение. Задържането на маршрут е слаб заместител на ограничение, наложено в дестинацията, тъй като клиентът винаги може да добави свой маршрут. Групата за сигурност, разрешението за базата данни и собствената оторизация на приложението остават контролите, които решават. Когато тест неочаквано успее, погледнете първо политиката на дестинацията, а не таблицата за маршрутизация, която сте предвидили за клиента.

Ето защо тестовете за отказ са насочени към сървърната страна: тези резултати не могат да се променят чрез редактиране на клиента.

Кой източник вижда контролът всъщност?

Адресът на източника, който контролът оценява, зависи от архитектурата на шлюза. Шлюз, хостван на EC2, може да препраща маршрутизиран пул, да превежда към собствения си адрес или да представя различен адрес след NAT; управляваният Client VPN се свързва с подмрежа и следва собствения си модел. Групите за сигурност и мрежовите ACL виждат каквото пристигне след тази обработка. Проверката на правило спрямо грешно допускане за източника е често срещан начин да се изгради граница, която изглежда правилна и допуска грешен трафик.

Свържете всеки резултат с най-малкото полезно събитие: идентичност и сесия, ресурс, операция, време и решението. Извикване на API в CloudTrail, запис за поток във VPC и журнал на VPN сесия отговарят на различни въпроси и нито едно само по себе си не е одит на приложението.

Оттеглете идентичност и я тествайте отново

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

Нищо от това не заменя работата по кръпки, възстановяване или жизнен цикъл на идентификационните данни. То прави по-тясно обещание измеримо: правилните хора достигат до правилните услуги, докато близките маршрути, акаунти и повърхности за управление остават извън разрешението.

Пазете таблицата заедно с внедряването и я изпълнявайте отново, когато шлюзът се промени. Тестовете са евтини; допусканията зад тях — не.