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

Почніть з аудиторії, а не з URL

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

Якщо ніхто не може назвати аудиторію, вважайте це першою знахідкою, а не прогалиною в документації.

Пройдіть крізь вхідні двері та поверхні за ними

Розв’яжіть імена, перш ніж довіряти наданому вам URL, потім запитайте адміністративні шляхи напряму.

dig +short staging.example.com
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/admin

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

Перевірте, що середовище вміє, а не лише що воно показує

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

aws sts get-caller-identity

Цей виклик повідомляє обліковий запис і принципала, які середовище фактично використовує, і це відправна точка для кожного наступного питання про права. Звідти перевірте, чи може ідентичність надсилати пошту, рухати гроші, читати продакшн-секрети або писати продакшн-дані. Замініть спільні продакшн-облікові дані обмеженими staging-ідентичностями і віддавайте перевагу пісочницям постачальника там, де вони є. Тестовий обліковий запис, який може списати з реальної картки, — це продакшн-система з іншим ім’ям хоста.

Зберігайте межу після завершення огляду

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

Прийміть проєкт із дозволеним робочим процесом і з відмовленим. Якщо обидва поводяться як задокументовано, межа існує; якщо перевірено лише щасливий шлях, це надія.

Схожі статті