Продукционна и sandbox среда: защо отделният URL адрес е само началото

Изолация на среди, реалистично тестване и инженерните решения зад по-безопасното внедряване на уебсайтове и приложения.

Настройването на sandbox среда може да изглежда лесно.

Създавате второ внедряване, задавате му различен URL адрес, свързвате тестова база данни и започвате да тествате.

Но какво се случва, когато тестова регистрация изпрати имейл до реален клиент? Или когато планирана задача в sandbox средата промени записи в действаща бизнес система?

Уебсайтът може да работи отделно, докато част от действията му продължават да засягат продукционната среда.

Отделният URL адрес обозначава средата. Той не определя всичко, до което тя има достъп или което може да променя.

Затова създаването на полезна sandbox среда изисква повече от дублиране на уебсайта. Необходими са решения за данните, идентификационните данни за достъп, интеграциите, правата и начина, по който промените достигат до продукционната среда.

Какво представляват продукционната, sandbox и предпродукционната среда?

Една среда обединява приложението, неговата конфигурация и услугите, от които зависи.

Това може да включва бази данни, файлово хранилище, удостоверяване, доставяне на имейли, доставчици на платежни услуги и фонови обработващи процеси.

Екипите използват различно наименованията на средите. За тази статия са полезни следните разграничения:

Малък проект може да използва една среда както за sandbox тестове, така и за предпродукционна проверка. По-голяма система може да има нужда от няколко среди с различно предназначение.

Терминологията е по-маловажна от ясното съгласие какво съдържа всяка среда, кой има достъп до нея и какви действия може да извършва.

Проблемът с отделния URL адрес

Да разгледаме уебсайт с два адреса:

• www.example.com
• sandbox.example.com

Sandbox средата има собствено внедряване на приложението и собствена база данни.

На пръв поглед разделението изглежда пълно.

Конфигурацията ѝ обаче все още съдържа продукционните данни за достъп до имейл услугата, местоположение в продукционното файлово хранилище и webhook към действащата CRM система на компанията.

Разработчик изпраща тестово запитване.

Запитването се записва в sandbox базата данни, но приложението също така:

1. Изпраща имейл до реален получател.
2. Качва прикачен файл в продукционното хранилище.
3. Създава потенциален клиент в продукционната CRM система.

Приложението е изпълнило зададената конфигурация. Границите между средите са били непълни.

Изолацията трябва да обхваща целия работен процес, включително действията извън самото приложение.

Какво трябва да бъде разделено?

Подходящото ниво на разделение зависи от рисковете и сложността на системата.

Отделни облачни акаунти или проекти могат да осигурят по-силни административни граници, но не са единственият възможен подход. По-малки системи могат да използват споделена инфраструктура с внимателно ограничени ресурси и права.

Важният въпрос е дали тестовите действия могат да достигнат продукционни ресурси.

Отделната база данни не помага, ако фонов процес в sandbox средата получава съобщения от продукционна опашка.

По същия начин отделна папка за файлове осигурява слаба защита, ако служебната идентичност на sandbox средата може да изтрива файлове в целия продукционен акаунт за съхранение.

Правата трябва да налагат предвидените граници. Самите правила за именуване не могат да го направят.

Външни интеграции: когато тестовите действия стават реални

Външните интеграции заслужават особено внимание, защото последствията от тях може да са трудни за отмяна.

Изтриването на тестов запис не оттегля изпратен имейл, не премахва известие от нечий телефон и не отменя автоматично промяна в друга система.

Имейли и известия

При много тестове услуга за прихващане на имейли позволява на разработчиците да преглеждат съобщенията, без те да бъдат доставяни до външни получатели.

Когато е необходимо да се тества доставянето, получателите могат да бъдат ограничени до контролирани адреси. Приложението трябва също да генерира връзки, които водят към правилната среда.

Имейл за възстановяване на парола от sandbox средата, който сочи към продукционния уебсайт, е конфигурационна грешка, дори ако съобщението стига само до тестер.

Плащания

Тестването на плащания трябва да използва документираните тестови възможности на доставчика.

Например Stripe поддържа sandbox трансакции, които симулират плащания без движение на средства, като използват тестови данни за достъп и документирани тестови стойности. Неговите указания разграничават тези операции от реалните плащания. Документация на Stripe за тестване ↗ (отваря се в нов раздел или прозорец)

Останалата част от работния процес също изисква внимание. Симулирано успешно плащане не трябва да задейства реално изпълнение на поръчка, да издава действителна фактура или да активира продукционен абонамент.

Webhook интеграции и фонови задачи

Тестово събитие може да има реални последствия, ако достигне действаща приемаща система.

Преглеждайте заедно адресите на webhook интеграциите, данните за достъп, тайните за проверка, планираните задачи и поведението при повторни опити.

Изключването на планирани задачи може да е подходящо при изследователско тестване. Преди внедряване обаче тези задачи трябва да бъдат проверени в контролирана среда. В противен случай важна част от приложението остава нетествана.

Реалистично тестване без достъп до продукционната среда

Sandbox средата трябва да е достатъчно сходна с продукционната, за да бъдат полезни резултатите от тестовете.

Ако продукционното приложение използва различна система за управление на бази данни, процес на удостоверяване или метод за внедряване, успешните sandbox тестове може да пропуснат важни несъвместимости.

Указанията на Twelve-Factor App за сходство между средите за разработка и продукция подчертават този проблем, особено при поддържащи услуги като бази данни, опашки и кешове. Сходство между средите за разработка и продукция ↗ (отваря се в нов раздел или прозорец)

Това не означава копиране на всяка характеристика на продукционната среда.

Sandbox средата може да работи с по-малко ресурси, синтетични записи и симулирани външни услуги. Екипът трябва да разбира кои разлики могат да повлияят върху тестваното поведение.

Например:

• Малък набор от данни може да скрие бавни заявки.
• Симулиран отговор за плащане може да скрие проблеми с времето за обработка и повторните опити.
• Различна конфигурация за удостоверяване може да скрие грешки в адресите за обратно пренасочване или правата.
• Изключен обработващ процес може да скрие грешки в асинхронната обработка.

Всяка съзнателно допусната разлика ограничава това, което един успешен тест доказва.

Конфигурация: сходно приложение, различни ресурси

Поддържането на отделен код на приложението за продукционната и sandbox средата може да доведе до разминаването им.

Когато е практично, използвайте един и същ пакет на приложението с конфигурация, подадена за всяко внедряване. Връзките към бази данни, крайните точки на услуги, данните за достъп и публичните URL адреси могат да се различават, без да се променя кодът на самото приложение.

Това следва разделението между кода и конфигурацията за конкретното внедряване, описано в Twelve-Factor App. Указания за конфигурация ↗ (отваря се в нов раздел или прозорец)

Конфигурацията също трябва да се валидира.

Sandbox средата не трябва мълчаливо да преминава към продукционни данни за достъп, когато липсва тестова настройка. В зависимост от компонента тя трябва да откаже стартиране или изрично да изключи засегнатата интеграция.

Където е възможно, продукционните тайни трябва да са недостъпни за приложенията и процесите в sandbox средата. Ограничаването на достъпа намалява зависимостта от това някой да забележи грешна настройка. Указанията на OWASP разглеждат минималните необходими права и контролирания достъп през целия жизнен цикъл на тайните. Ръководство на OWASP за управление на тайни ↗ (отваря се в нов раздел или прозорец)

Тестовите данни са част от проектирането

Копирането на продукционната база данни може да изглежда като най-лесния начин за създаване на реалистични тестове.

То обаче може да прехвърли клиентска информация, хешове на пароли, активни токени, частни документи и реални данни за контакт в среда с различни условия за достъп.

Синтетичните данни често са по-добра отправна точка.

Полезните тестови данни трябва да включват повече от няколко успешни примера:

• Профили с различни права.
• Изтекли и отнети сесии.
• Неуспешни и чакащи трансакции.
• Големи записи и необичайни входни данни.
• Дублирани изпращания и повторно обработвани събития.
• Различни езици и набори от символи.

Ако са необходими данни, извлечени от продукционната среда, определете какво се копира, как се преобразуват чувствителните полета, кой има достъп до резултата и колко дълго се съхранява той.

Промяната само на имената и имейл адресите не премахва непременно чувствителната информация от свободните текстови полета, прикачените файлове или свързаните записи.

Достъп, разпознаваемост и индексиране от търсачки

Хората трябва да могат да разпознават коя среда използват.

Постоянен банер за sandbox средата, различимо оформление на административния интерфейс и обозначения на средата в логовете и сигналите могат да намалят объркването.

Тези обозначения допълват контрола на достъпа. Те не го заменят.

Частните тестови среди трябва да изискват подходящо удостоверяване или мрежови ограничения.

Индексирането от търсачки е отделен въпрос. Google поддържа директиви noindex, но роботът му трябва да има достъп до страницата, за да ги прочете. Блокирането на обхождането чрез robots.txt може да попречи на Google да види директивата и URL адресът все пак може да се появи в резултатите. Google Search Central: блокиране на индексирането с noindex ↗ (отваря се в нов раздел или прозорец)

Нито един от двата механизма не пречи на човек да отвори иначе достъпна страница.

Публичните демонстрационни sandbox среди може умишлено да допускат посетители. В такъв случай техните данни, права, механизми за нулиране и външни ефекти се нуждаят от граници, подходящи за публична употреба.

Практични препоръки за разработчици

1. Определете предназначението на средата

Решете дали тя служи за експерименти, клиентски демонстрации, интеграционно тестване или проверка на версия преди внедряване. Посочете ограниченията ѝ.

2. Проследете целите работни процеси

Проследете едно действие от браузъра през базите данни, обработващите процеси, хранилищата, известията и външните услуги. Определете всяко място, където то може да доведе до промяна.

3. Наложете граници между ресурсите

Използвайте отделни ресурси и служебни идентичности с ограничени права, когато е подходящо. Проверете, че sandbox данните за достъп не позволяват достъп до продукционни данни.

4. Тествайте както функционалността, така и изолацията

Проверете, че регистрацията работи и че не може да изпрати имейл до непредвиден получател, да записва в продукционно хранилище или да публикува събитие за продукционен обработващ процес.

5. Поддържайте повторяемо внедряване

Използвайте едни и същи пакети и процедури за внедряване в различните среди. Указанията на Microsoft за внедряване подчертават тази последователност като част от надеждното публикуване на версии. Указания за внедряване и тестване ↗ (отваря се в нов раздел или прозорец)

6. Планирайте продукционното внедряване

Валидирайте специфичните продукционни настройки, наблюдавайте основните работни процеси след внедряването и определете стъпки за възстановяване.

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

Често задавани въпроси

Едно и също ли са sandbox и предпродукционната среда?

Не непременно. Sandbox средата обикновено служи за експерименти, а предпродукционната среда обикновено проверява версия, подготвена за внедряване. Един проект може да съчетава тези цели, ако границите и ограниченията са ясни.

Нуждае ли се всеки уебсайт от всички тези среди?

Не. Статичен информационен уебсайт има различни нужди от приложение, което обработва профили, плащания и планирани задачи. Настройката трябва да отчита какво може да се обърка и какви са последствията от неуспех.

Могат ли продукционната и sandbox средата да споделят инфраструктура?

Да, но споделената инфраструктура води до споделени рискове. Достъпът до ресурси, капацитетът, правата и административните граници трябва да бъдат внимателно проектирани.

Гарантира ли успешният sandbox тест успех в продукционната среда?

Не. Той дава доказателства за поведението при тестваните условия. Продукционната конфигурация, трафикът, данните и поведението на външните услуги все още могат да се различават.

Изграждане на увереност преди продукционното внедряване

Полезната sandbox среда дава на екипа възможност да изследва грешки, да наблюдава поведението и да проверява промени, преди клиентите да се сблъскат с тях.

Стойността ѝ зависи от две неща: колко ефективно ограничава тестовите действия и колко точно представя поведението, което е важно.

Отделният URL адрес е полезна отправна точка. Увереността идва от знанието до кои ресурси средата може да достигне, какви ефекти може да предизвика и какво действително доказват тестовете ѝ.