Книга: Безопасность веб-приложений. Исчерпывающий гид для начинающих разработчиков
Назад: Редактирование кода на сервере в реальном времени
Дальше: Глава 7. Программы безопасности приложений

Ранбуки

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

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

Непрерывная интеграция, непрерывная поставка, непрерывное развертывание

Непрерывная интеграция и непрерывная поставка, также известная как CI/CD, фактически представляют собой три различные концепции в рамках одной системы, что можно увидеть на рис. 6.1.



Рис. 6.1. Непрерывная поставка и непрерывная интеграция (CI/CD)





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

Непрерывная поставка отвечает за очень быстрый выпуск изменений. Система всегда должна быть готова к автоматическому развертыванию (которое включает в себя все элементы непрерывной интеграции с добавлением тестирования). Непрерывная поставка требует использования автоматизированного инструмента, обычно называемого конвейером. Автоматизация ускоряет процесс, исключает человеческий фактор и позволяет добавлять автоматизированные тесты, что повышает качество кода. Такое программное обеспечение часто называют конвейером CI/CD или конвейером DevOps, а каждый новый выпуск – сборкой.

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

Конвейеры CI/CD являются наиболее известной особенностью методологии DevOps, а цели их применения совпадают с нашими: снижение количества ошибок (безопасности), вызванных человеческим фактором, более быстрая обратная связь (по вопросам безопасности), возможность быстрого внедрения исправления ошибок (безопасности), автоматизация тестирования (безопасности) и снижение риска злонамеренной эксплуатации уязвимостей за счет регулярного выпуска множества мелких изменений вместо крупных, но редких патчей.

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

Вот несколько идей для начала работы с конвейером CI/CD.

• Сканирование только что загруженного кода на предмет наличия в нем элементов, похожих на секреты. Данное тестирование проводится быстро, потому что в его ходе проверяется только дельта (измененный или новый код), а обнаружение секрета принесет огромную пользу организации и предотвратит катастрофу, связанную с обеспечением безопасности. В идеале при обнаружении секрета загрузка кода должна быть остановлена. Если блокировка невозможна, необходимо запустить процедуру управления инцидентами безопасности и немедленно удалить секрет.

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

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

Упражнения

1. Если бы вы могли выбрать только один вид тестирования для своего приложения, какой бы вы выбрали и почему?

2. Как вы думаете, какой вид тестирования будет самым быстрым? Почему?

3. Как вы думаете, какой вид тестирования будет самым медленным? Почему?

4. Какие типы уязвимостей вы бы искали при регрессионном тестировании? Назовите как минимум два типа и объясните свой выбор.

5. Сеть вашей компании спроектирована с учетом принципа нулевого уровня доверия? Если вы не знаете ответа, ваше домашнее задание – выяснить это.

6. Поддерживает ли ваша компания использование конвейера CI/CD? Если вы не знаете ответа, ваше домашнее задание – выяснить это.

7. Следует ли в среде CI/CD применять инструмент статического тестирования безопасности приложений (SAST) и проводить полное сканирование всего кода при каждой новой сборке? Почему?

8. Почему очень важно помещать все новые изменения в репозиторий кода?

9. Зачем мы тестируем точки интеграции между различными системами? Это лучше, чем полное тестирование каждой системы?

10. Почему мы тестируем базы данных, даже если они находятся в закрытом доступе?

11. Почему мы тестируем API, даже если они находятся в закрытом доступе? (Возможно, вопрос с подвохом.)

12. Когда имеет смысл проводить тестирование на проникновение, а не оценку безопасности системы? Поясните свой ответ.

Назад: Редактирование кода на сервере в реальном времени
Дальше: Глава 7. Программы безопасности приложений