Безопасная разработка. Методология DevSecOps

Вопрос безопасности всегда стоит довольно остро. Существует огромное количество инструментов и подходов, для того чтобы ответить на вопрос: «А в безопасности ли мое приложение и инфраструктура?» Тему безопасности инфраструктуры мы детально не раскрываем, так как она обеспечивается в облаке целым рядом факторов и инструментов. А вот про безопасность приложений поговорим.

После того как вы выстроили разработку и механизмы доставки кода в продакшен-окружения, необходимо задуматься о встраивании процессов и применении инструментов, которые помогут вам ответить на вопрос безопасности. Так в термине DevOps появляется Security — DevSecOps.

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

1. Develop — разработчики пишут код.
2. Build — код собирают.
3. Deploy — на этом шаге к артефакту, который появился на предыдущем этапе, добавляются конфигурационные файлы.
4. Operate — запущенное приложение (артефакт + конфигурационные файлы) в продакшен-окружении.

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

Develop

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

• Ошибка разработчика. Указание чувствительной информации вроде пароля от БД непосредственно в коде.
• Использование зависимостей с уязвимостями. В мире разработки регулярно переиспользуют существующие фреймворки и библиотеки, в том числе публичные. Однако они могут содержать критические дыры в безопасности.
• Использование языков программирования старых версий. Часто разработчики не уделяют достаточно внимания версии своего ЯП. А старые версии могут содержать серьезные уязвимости, которые могут стать существенной угрозой для вашего приложения.

Build

Поверхность атаки — это термин, который используется в информационной безопасности для определения сервисов и компонентов системы как потенциально уязвимых. Наилучшей практикой является уменьшение поверхности атаки, то есть сокращение сервисов, которые доступны по сети для злоумышленника. Таким образом, нет смысла смотреть на весь продукт. Необходимо лишь определить те компоненты, которые доступны для атаки: API, Web Interface.

Deploy

Ошибка команды и внесение в конфигурационные файлы чувствительной информации.

Operate

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