Приймання віддаленого доступу до VPC потребує тестів на відмову

Приймання віддаленого доступу — це таблиця очікуваних результатів, а не скриншот робочої сторінки. Для кожної групи запишіть, що має вийти і що має не вийти, а потім виконайте обидва сценарії з виділеними тестовими обліковими записами в контрольованому вікні. Відмови — це та частина, яка доводить межу; успішний вхід доводить лише те, що тунель існує. Усе це працює з уже обраним продуктом VPN.

Використовуйте для тестів окремі облікові записи та позначайте їх так, щоб ніхто не сплутав тестовий обліковий запис із справжнім винятком.

Запишіть межу як очікувані результати

Почніть із ролей, а не з компонентів: кому потрібен який сервіс, звідки і з яким обліковим записом. Візьміть показовий VPC: одній групі потрібне тестове середовище через HTTPS, іншій потрібна продукційна база даних, а третя, менша група адмініструє сам шлюз. Кожен рядок отримує очікуваний дозвіл і очікувану відмову, включно із сусіднім сервісом і сусіднім обліковим записом, які не повинні працювати. Ця таблиця і є критерієм приймання, і люди, які не запускають тести, можуть її переглянути.

Перевіряйте вхід до бази даних окремо від мережевого шляху. Доступний порт TCP не повинен робити успішним не затверджений обліковий запис бази даних, а членство у VPN не повинно створювати хмарну роль IAM чи надавати адміністративний доступ до API. Це три незалежні засоби контролю, і вони відмовляють незалежно.

Маршрут — це не авторизація

Маршрут робить шлях можливим; він не дає дозволу. Приховування маршруту — слабка заміна обмеженню, яке застосовується на стороні призначення, оскільки клієнт завжди може додати власний маршрут. Група безпеки, дозвіл бази даних і власна авторизація застосунку залишаються засобами контролю, які вирішують. Коли тест несподівано проходить, дивіться спершу на політику призначення, а не на таблицю маршрутизації, яку ви призначали клієнтові.

Саме тому тести на відмову націлені на бік сервера: ці результати не можна змінити, редагуючи клієнт.

Яке джерело засіб контролю насправді бачить?

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

Зіставте кожен результат із найменшою корисною подією: обліковий запис і сеанс, ресурс, операція, час і рішення. Виклик API у CloudTrail, запис потоку VPC і журнал сеансу VPN відповідають на різні питання, і жоден із них сам по собі не є аудитом застосунку.

Відкличте обліковий запис і перевірте його знову

Включіть відкликання до тієї самої таблиці. Видаліть тестовий обліковий запис, переконайтеся, що новий сеанс відхиляється, а потім окремо переконайтеся, як поводяться з наявними сеансами, бо це різна поведінка з різними власниками. Перевірте, що відбувається після перезапуску або заміни шлюзу, щоб доданий вручну виняток не зник тихо і не повернувся ширшим. Межа, яка тримається лише до наступного розгортання, — не межа.

Ніщо з цього не замінює роботу з виправленнями, відновленням або життєвим циклом облікових даних. Це робить вимірюваною вужчу обіцянку: потрібні люди потрапляють до потрібних сервісів, а сусідні маршрути, облікові записи та поверхні керування залишаються поза наданням.

Тримайте таблицю разом із розгортанням і запускайте її знову, коли шлюз змінюється. Тести дешеві; припущення за ними — ні.