Прифаќањето на далечински пристап преку VPC бара тестови за одбивање

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

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

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

Започнете од улогите, а не од компонентите: кому му треба која услуга, од каде и со кој идентитет. Земете илустративен VPC: една група има потреба од тест-околина преку HTTPS, друга има потреба од продукциска база на податоци, а трета и помала група го администрира самиот портал. Секој ред добива очекувано одобрување и очекувано одбивање, вклучувајќи ја соседната услуга и соседната сметка што не треба да работат. Таа табела е критериумот за прифаќање и луѓето што не ги извршуваат тестовите можат да ја прегледаат.

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

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

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

Затоа тестовите за одбивање се насочени кон серверската страна: тие резултати не можат да се променат со уредување на клиентот.

Кој извор контролата навистина го гледа?

Изворната адреса што ја оценува контролата зависи од архитектурата на порталот. Порталот хостиран на EC2 може да проследи рутиран базен, да го преведе во сопствената адреса или по NAT да прикаже друга адреса; управуваниот Client VPN се поврзува со подмрежа и го следи својот модел. Безбедносните групи и мрежните ACL гледаат што пристигнува по таа обработка. Проверката на правило според погрешна претпоставка за изворот е чест начин да се изгради граница што изгледа точна и пропушта погрешен сообраќај.

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

Повлечете идентитет и тестирајте го повторно

Вклучете го повлекувањето во истата табела. Отстранете тест-идентитет, потврдете дека новата сесија е одбиена, а потоа одделно потврдете како се третираат постојните сесии, бидејќи тоа се различни однесувања со различни сопственици. Проверете што се случува по рестартирање или замена на порталот, за да не исчезне тивко рачно додаден исклучок или да се врати поширок. Граница што трае само до следното распоредување не е граница.

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

Чувајте ја табелата со распоредувањето и извршете ја повторно кога порталот ќе се промени. Тестовите се евтини; претпоставките зад нив не се.