Джин Ким - Руководство по DevOps

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

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

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

Такие инструменты, как GauntIt, специально были созданы для работы в конвейере развертывания. Они проводят автоматические тесты безопасности для приложений, зависимостей приложений, для среды и так далее. Примечательно, что GauntIt даже помещает все свои тесты в тестовые скрипты на языке Gherkin, широко используемом разработчиками для модульного и функционального тестирования. Благодаря такому подходу тесты оказываются в уже знакомой им среде разработки. Кроме того, их можно легко запускать в конвейере развертывания при каждом подтверждении изменений кода, например при статическом анализе кода, проверке на наличие уязвимых зависимостей или при динамическом тестировании.

Рис. 43. Автоматизированное тестирование в системе Jenkins (источник: Джеймс Уикет и Гарет Рашгров, “Battle-tested code without the battle,” презентация на конференции Velocity 2014, выложенная на сайте Speakerdeck.com, 24 июня 2014 г., https://speakerdeck.com/garethr/battle-tested-code-without-the-battle)

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

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

С другой стороны, хорошие тестировщики, инженеры службы безопасности и специалисты по фрод-мошенничеству [161]часто заостряют внимание на грустных путях (sad path), когда что-то идет не так, особенно если это касается ошибок, связанных с защитой данных (такие виды типичных для защиты данных событий часто в шутку называют плохими путями , или bad path).

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

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

• Статический анализ: это тестирование не в среде исполнения: идеальная среда — конвейер развертывания. Обычно инструмент статического анализа проверяет код программы на все возможные способы выполнения кода и ищет недочеты, лазейки и потенциально вредоносный код (иногда этот процесс называют «тестированием изнутри наружу»). Примеры инструментов статического анализа — Brakeman, Code Climate и поиск запрещенных функций (как, например, «exec()»).

• Динамический анализ: в противоположность статическому тестированию динамический анализ состоит из тестов, проводимых во время работы программы. Динамические тесты проверяют системную память, поведение функций, время ответа и общую работоспособность системы. Этот метод (иногда называемый «тестированием снаружи внутрь») имеет много общего с тем, как злоумышленники взаимодействуют с приложением. Примерами инструментов могут быть Arachni и OWASP ZAP (Zed Attack Proxy) [162]. Некоторые типы тестирования на проникновение (pentesting) можно проводить автоматически, их можно включить в динамический анализ с помощью таких инструментов, как Nmap и Metasploit. В идеале автоматизированное динамическое тестирование должно проводиться во время фазы автоматического функционального тестирования в конвейере развертывания или даже уже во время эксплуатации сервиса. Чтобы проконтролировать соблюдение требований безопасности, можно настроить инструменты вроде OWASP ZAP, так чтобы они атаковали наши сервисы через прокси-сервер, а затем изучать сетевой трафик в специальной тестовой программе.