Приёмка удалённого доступа к VPC требует тестов на отказ

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

Используйте для тестов отдельные учётные записи и помечайте их так, чтобы никто не спутал тестовую учётную запись с настоящим исключением.

Запишите границу как ожидаемые результаты

Начните с ролей, а не с компонентов: кому нужен какой сервис, откуда и с какой учётной записью. Возьмите показательный VPC: одной группе нужна тестовая среда по HTTPS, другой нужна продукционная база данных, а третья, меньшая группа администрирует сам шлюз. Каждая строка получает ожидаемое разрешение и ожидаемый отказ, включая соседний сервис и соседнюю учётную запись, которые не должны работать. Эта таблица и есть критерий приёмки, и люди, которые не запускают тесты, могут её проверить.

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

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

Маршрут делает путь возможным; он не даёт разрешения. Сокрытие маршрута — слабая замена ограничению, которое применяется на стороне назначения, поскольку клиент всегда может добавить собственный маршрут. Группа безопасности, разрешение базы данных и собственная авторизация приложения остаются элементами управления, которые решают. Когда тест неожиданно проходит, смотрите сначала на политику назначения, а не на таблицу маршрутизации, которую вы предназначали клиенту.

Именно поэтому тесты на отказ нацелены на сторону сервера: эти результаты нельзя изменить, отредактировав клиент.

Какой источник элемент управления видит на самом деле?

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

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

Отзовите учётную запись и проверьте её снова

Включите отзыв в ту же таблицу. Удалите тестовую учётную запись, убедитесь, что новый сеанс отклоняется, а затем отдельно убедитесь, как обращаются с существующими сеансами, потому что это разное поведение с разными владельцами. Проверьте, что происходит после перезапуска или замены шлюза, чтобы добавленное вручную исключение не исчезло молча и не вернулось более широким. Граница, которая держится только до следующего развёртывания, — не граница.

Ничто из этого не заменяет работу по исправлениям, восстановлению или жизненному циклу учётных данных. Это делает измеримым более узкое обещание: нужные люди попадают к нужным сервисам, а соседние маршруты, учётные записи и поверхности управления остаются вне предоставления.

Храните таблицу вместе с развёртыванием и запускайте её снова при изменении шлюза. Тесты дешёвы; допущения за ними — нет.