Тестирование интеграций

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

Сначала следует убедиться, что между соединениями существует контроль безопасности (как минимум всегда должна быть аутентификация, затем авторизация), после чего проверить, правильно ли он настроен.

Во-вторых, если это возможно, необходимо подключиться ко второй системе и «пообщаться» с ней. Если ею является API, то можно вызвать его и следовать советам, данным в предыдущем разделе. Бессерверное приложение можно вызвать через логическое приложение (при его наличии) или собственноручно, а затем отправить ему различные значения и основательно поэкспериментировать с ним.

ПРИМЕЧАНИЕ. Логические приложения – это триггеры, вызывающие бессерверные приложения. Они срабатывают при наступлении определенных событий. Например, при превышении квоты ресурсов для API, при многократных попытках входа в систему за 24 часа либо при «слишком быстром» входе в систему (быстрее, чем это способен сделать человек).

Имеющиеся логические приложения можно запускать самостоятельно (если это возможно), чтобы убедиться в их правильной и бесперебойной работе. Необходимо проверить отсутствие ложных срабатываний.

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

СОВЕТ. При тестировании логических приложений следует всегда спрашивать себя, кажутся ли значения триггеров подходящими. Возможно, 100 попыток входа в систему за 5 секунд – слишком большое значение настройки логического приложения? Может ли человек войти в систему 10 раз за 5 секунд? Скорее всего, нет. Следовательно, хороший тестировщик предположит, что настройку безопасности можно улучшить, снизив порог до 10 попыток входов. Любой совет по блокировке ботов будет иметь высокую ценность. Вас наняли за ваше экспертное мнение, так предоставьте же его заказчику.

Тестирование сети

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

Если в компании используется зонирование (межсетевые экраны между различными областями сети, предполагающие доверие внутри каждой зоны), необходимо подтвердить правильную работу архитектуры приложения в том случае, если приложение находится в одной зоне, API – в другой, а база данных – в третьей. Разговор с командами эксплуатационного и сетевого отделов о потребностях приложения приведет к менее болезненному развертыванию в будущем.

Если компания применяет в своей сети модель нулевого доверия, необходимо убедиться в том, что все компоненты приложения следуют этой политике и соответствующим руководящим принципам.

Все необязательные для работы приложения порты должны быть закрыты. API, бессерверные приложения, вызовы баз данных и тому подобные компоненты должны выполняться только через сервисную учетную запись, выделенную для системы (ни в коем случае не через общую или личную). Списки доступа должны включать только необходимые сервисные и административные учетные записи. Остальные учетные записи должны быть заблокированы, а попытки подключения через них – зафиксированы с отправлением уведомления.

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

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

Развертывание

Развертывание находится в одной главе с тестированием, потому что предоставляет большое количество возможностей для него. Эти два этапа жизненного цикла разработки системы тесно связаны между собой.

Развертывание означает «акт выпуска системы в среду» (обычно в эксплуатационную). Вместо слова «развертывание» часто используются такие термины, как «релиз», «выпуск», «публикация», «запуск», но все они подразумевают одно и то же: все элементы помещаются в нужное место, включаются – и приложение выводится в мир.

ПРЕДУПРЕЖДЕНИЕ О ПРЕДВЗЯТОСТИ

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

Существует несколько различных способов развертывания приложения. Давайте рассмотрим их.