Прихватање удаљеног приступа преко VPC-а захтева тестове одбијања

Прихватање удаљеног приступа је табела очекиваних исхода, а не снимак екрана радне странице. За сваку групу запишите шта треба да успе и шта треба да не успе, па оба покрените на наменским тестним идентитетима у контролисаном прозору. Одбијања су део који доказује границу; успешна пријава доказује само да тунел постоји. Све то функционише са већ изабраним VPN производом.

Користите одвојене рачуне за тестове и означите их тако да нико не помеша тестни идентитет са стварним изузетком.

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

Почните од улога, а не од компоненти: коме треба која услуга, одакле и са којим идентитетом. Узмите илустративни VPC: једној групи треба тестно окружење преко HTTPS-а, другој продукциона база података, а трећа и мања група администрира сам приступник. Сваки ред добија очекивано допуштење и очекивано одбијање, укључујући суседну услугу и суседни рачун који не би требало да раде. Та табела је критеријум прихватања и људи који не изводе тестове могу је прегледати.

Тестирајте пријаву у базу података одвојено од мрежне путање. Доступан TCP порт не би требало да учини успешним неодобрени рачун базе података, а чланство у VPN-у не би требало да створи облачну IAM улогу или додели административни приступ API-ју. То су три независне контроле и оне падају независно.

Рута није ауторизација

Рута чини путању могућом; она не даје дозволу. Ускраћивање руте је слаба замена за ограничење које се спроводи на одредишту, јер клијент увек може додати сопствену руту. Сигурносна група, одобрење базе података и сопствена ауторизација апликације остају контроле које одлучују. Када тест неочекивано успе, прво погледајте политику одредишта, а не табелу рутирања коју сте намеравали да дате клијенту.

Зато тестови одбијања циљају на серверску страну: ти резултати не могу да се промене уређивањем клијента.

Који извор контрола заправо види?

Адреса извора коју контрола процењује зависи од архитектуре приступника. Приступник хостован на EC2 може да проследи рутиран базен, преведе га у сопствену адресу или после NAT-а прикаже другу адресу; управљани Client VPN повезује се са подмрежом и следи сопствени модел. Сигурносне групе и мрежни ACL-ови виде све што стигне након те обраде. Провера правила према погрешној претпоставци о извору чест је начин да се изгради граница која изгледа исправно и пропушта погрешан саобраћај.

Повежите сваки резултат са најмањим корисним догађајем: идентитет и сесија, ресурс, операција, време и одлука. Позив API-ја у CloudTrail-у, запис тока у VPC-у и дневник VPN сесије одговарају на различита питања и ниједан сам није ревизија апликације.

Повуците идентитет и поново га тестирајте

Укључите повлачење у исту табелу. Уклоните тестни идентитет, потврдите да је нова сесија одбијена, па одвојено потврдите како се третирају постојеће сесије, јер су то различита понашања са различитим власницима. Проверите шта се дешава након поновног покретања или замене приступника, да ручно додати изузетак не нестане тихо или се не врати шири. Граница која траје само до следећег постављања није граница.

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

Држите табелу уз постављање и поново је покрените када се приступник промени. Тестови су јефтини; претпоставке иза њих нису.