Элементы управления DevSecOps

DevSecOps применяет инновационную безопасность путем интеграции процессов и средств безопасности в процесс разработки DevOps.

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

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

Планирование и разработка

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

• Моделирование угроз для анализа приложения с точки зрения потенциального злоумышленника
• Подключаемые модули безопасности IDE и обработчики предварительной фиксации для упрощенной статической проверки данных в интегрированной среде разработки (IDE).
• Оценки коллегами и защищенные стандарты кодирования для обнаружения эффективных стандартов кодирования безопасности, процессов оценки коллегами и обработчиков предварительной фиксации.

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

Моделирование угроз

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

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

• То, как злоумышленники могут использовать архитектуру приложения
• Устранение уязвимостей
• Насколько важно устранить проблемы

Моделирование угроз эффективно позволяет вам «проникнуть в голову» злоумышленника. Он позволяет видеть приложение через глаза злоумышленника. Вы узнаете, как блокировать попытки, прежде чем злоумышленники смогут сделать что-либо об этом. Если у вашей команды есть пользователи в дизайне, вы можете рассматривать злоумышленника как враждебного пользователя.

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

Моделирование угроз: начать с простого

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

Следующие простые методы вопросов помогут вам приступить к работе:

• Метод простых вопросов корпорации Microsoft. Этот метод основан на постановке специальных технических вопросов, предназначенных для выявления наиболее распространенных ошибок проектирования безопасности.
• Моделирование угроз OWASP: этот метод фокусируется на запросе простых, не технических вопросов, чтобы начать процесс моделирования угроз.

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

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

Другой полезный ресурс — это руководство по моделированию угроз для разработчиков.

Подключаемые модули безопасности IDE и обработчики предварительной фиксации

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

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

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

Оценка коллегами и стандарты безопасного кодирования

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

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

Фиксация кода

Как правило, разработчики создают код, управляют им и совместно используют его в таких репозиториях, как GitHub или Azure Repos. Этот подход предоставляет центральную, управляемую версией библиотеку кода для разработчиков для упрощения совместной работы. Однако включение многих участников совместной работы в одной базе кода также рискует ввести изменения. Этот риск может привести к уязвимостям или непреднамеренно включая учетные данные или маркеры в фиксации.

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

Управление зависимостями

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

Убедитесь, что ваша команда разработчиков знает, какие компоненты следует включить в свои приложения. Они хотят скачать безопасные и актуальные версии из известных источников. И они хотят иметь процесс хранения версий в актуальном состоянии. Ваша команда может использовать такие инструменты, как проект OWASP Dependency-Check, WhiteSource и другие.

Чтобы сосредоточиться только на уязвимостях зависимостей или их жизненном цикле, недостаточно. Также важно учитывать безопасность пакетов веб-каналов. Существуют известные векторы атак, предназначенные для систем управления пакетами: typeosquatting, компрометации существующих пакетов, атак подстановки и других. Поэтому ответственное администрирование управления пакетами должно решать эти риски. Дополнительные сведения см. в разделе "Три способа снижения риска при использовании частных веб-каналов пакетов".

Статическое тестирование безопасности приложений

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

Но команда должна начинаться где-то при реализации практики сканирования статического кода. Одним из способов является внедрение статического анализа кода внутри непрерывной интеграции. Этот метод проверяет безопасность сразу после изменения кода. Одним из примеров является SonarCloud. Он упаковывает несколько статических средств тестирования безопасности приложений (SAST) для разных языков. SonarCloud оценивает и отслеживает технический долг с акцентом на поддержку. Он смотрит на качество кода и стиль и имеет специальные проверка безопасности. Но есть много других коммерческих и открытых инструментов, доступных на рынке.

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

Безопасные конвейеры

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

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

Команды DevOps должны гарантировать, что они реализуют надлежащие элементы управления безопасностью для конвейера. В зависимости от выбранной платформы существуют различные рекомендации по устранению рисков. Дополнительные сведения см. в статье Обеспечение безопасности Azure Pipelines.

Сборка и тестирование

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

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

Динамическое тестирование безопасности приложений

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

Тест на проникновение состоит из нескольких точек действия, одной из которых является динамическое тестирование безопасности приложений (DAST). DAST — это проверка безопасности веб-приложений, которая осуществляет поиск проблем, связанных с безопасностью в работающем приложении, просматривая то, как приложение реагирует на специально созданные запросы. Инструменты DAST также называются сканерами уязвимостей веб-приложений. Одним из примеров является средство с открытым исходным кодом, OWASP Zed Attack Proxy (ZAP). Он находит уязвимости в работающем веб-приложении. Существуют различные способы проверки OWASP ZAP: пассивное базовое сканирование или полная проверка в зависимости от конфигурации.

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

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

Проверка конфигурации облака и сканирование инфраструктуры

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

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

Одним из способов DevOps может привести разработчиков и операций друг с другом в поддержку преобразования существующей инфраструктуры в подход к инфраструктуре как код.

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

DevSecOps сдвигает безопасность влево и показывает, что безопасность не только о безопасности приложений, но и о безопасности инфраструктуры. Одним из способов поддержки безопасности инфраструктуры DevSecOps является включение проверки безопасности перед развертыванием инфраструктуры в облаке. Как инфраструктура стала кодом, вы затем примените те же действия безопасности к инфраструктуре, что и безопасность приложений. Существуют средства безопасности для запуска проверки безопасности инфраструктуры на основе выбранной стратегии IaC.

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

Переход к рабочей среде и применение

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

Сканирование конфигурации и инфраструктуры

Для видимости облачных подписок и конфигурации ресурсов в нескольких подписках используйте решение безопасности клиента Azure из команды AzSK.

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

тест на проникновение;

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

Многие продукты и партнеры предлагают услуги тестирования на проникновение. Корпорация Microsoft предоставляет рекомендации по тесту на проникновение в Azure.

Тестирование обычно охватывает следующие типы тестов:

• Тесты на конечных точках для обнаружения уязвимостей
• Нечеткое тестирование (поиск ошибок программы путем предоставления неправильных входных данных) конечных точек
• сканирования портов конечных точек;

Транзакционная аналитика

Средства и методы, описанные в этом руководстве, предлагают целостную модель безопасности для организаций, которые хотят двигаться в темпе и экспериментировать с новыми технологиями, направленными на внедрение инноваций. Ключевым элементом DevSecOps является управляемые данными процессы, управляемые событиями. Эти процессы помогают командам выявлять, оценивать и реагировать на потенциальные риски. Многие организации выбирают интеграцию оповещений и данных об использовании в платформу управления ИТ-службами (ITSM). Затем команда может перенести тот же структурированный рабочий процесс в события безопасности, которые они используют для других инцидентов и запросов.

Циклы обратной связи

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

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