Функции безопасности приложений и DevSecOps

Цель безопасности приложений и DevSecOps — интегрировать гарантии безопасности в процессы разработки и пользовательские бизнес-приложения.

Модернизация

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

Такая модернизации устаревших моделей разработки предоставляет как возможности, так и требования для модернизации системы безопасности приложений и процессов разработки. Синтез системы безопасности с процессами DevOps часто называют DevSecOps. Он ведет к следующим изменениям.

• Система безопасности интегрируется, при этом утверждение по-прежнему выполняется. Высокий темп изменений в разработке приложений приводит к устареванию классических равноудаленных подходов типа "проверка и отчетность". Эти устаревшие подходы не соответствуют выпускам, если не приостанавливать разработку и не создавать задержки вывода на рынок, что также сопровождается недозагруженностью разработчиков и ростом невыполненной работы по решению проблем.
  • Сдвиг влево для интеграции системы безопасности на более ранних этапах процессов разработки приложений, так как устранение проблем на ранних этапах является более дешевым, быстрым и эффективным. Если ждать, пока торт испечется, изменить форму будет все труднее.
  • Интеграция платформенной функциональности. Рекомендации по обеспечению безопасности необходимо тесно интегрировать во избежание нездоровых разногласий в процессах разработки и процессах непрерывной интеграции и непрерывного развертывания (CI/CD). Дополнительные сведения о подходе GitHub см. в разделе Совместная защита программного обеспечения.
  • Высокий уровень безопасности. Система безопасности должна предоставлять высококачественные выводы и рекомендации, которые позволят разработчикам быстро устранять проблемы и не тратить время на ложноположительные результаты.
  • Смешанная культура. Роли безопасности, разработки и эксплуатации должны вкладывать ключевые элементы в общую культуру, общие ценности, общие цели и обязанности.
• Гибкая система безопасности. Подход к системе безопасности типа "для отправки все должно быть идеально" следует заменить на гибкий подход, который начинается с установления минимальных средств безопасности для приложений (и процессов их разработки), уровень которых постоянно и постепенно повышается.
• Внедряйте облачную инфраструктуру и функции безопасности для оптимизации процессов разработки при интеграции системы безопасности.
• Управление рисками в цепочке поставок. Используйте подход "Никому не доверяй" при работе с ПО с открытым кодом (OSS) и сторонними компонентами, чтобы проверить их целостность и гарантировать применение исправлений ошибок и обновлений к этим компонентам.
• Непрерывное обучение. При быстром выпуске служб для разработчиков, иногда называемых "платформа как услуга" (PaaS), и изменении структуры приложений участники команды по разработке, операциям и безопасности будут постоянно изучать новые технологии.
• Применяйте программный подход к безопасности приложений для непрерывного совершенствования гибкого подхода.

Дополнительные сведения см. в разделе Жизненный цикл разработки средств безопасности Microsoft.

Состав команды и основные направления для взаимодействия

Функции безопасности приложений и DevSecOps идеально выполняют разработчики и команды по операциям, осведомленные о безопасности (при поддержке специалистов по вопросам безопасности).

Эта функция обычно взаимодействует с другими функциями и экспертами, в том числе:

• Архитектура и операции безопасности
• Безопасность инфраструктуры
• Обмен данными (обучение и средства)
• Безопасность людей
• Удостоверения и ключи
• Команды по управлению соответствием и рисками
• Основные руководители компании или их представители

Дальнейшие действия

Изучите функцию безопасности данных.