Поделиться через

Рекомендации по защите жизненного цикла разработки

  • Статья

Применяется к этой рекомендации по безопасности Azure Well-Architected Framework:

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

Связанное руководство. Анализ угроз

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

Схема цикла безопасности.

DevSecOps интегрирует безопасность в процессы DevOps следующими способами:

  • Автоматизация тестирования и проверки безопасности.

  • Реализация таких средств, как конвейеры безопасности для сканирования кода и инфраструктуры в виде кода (IaC) для уязвимостей.

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

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

Определения

Термин Определение
Жизненный цикл разработки безопасного ПО (SDL) Набор методик, предоставляемых корпорацией Майкрософт, которая поддерживает требования к обеспечению безопасности и соответствию требованиям.
Жизненный цикл разработки программного обеспечения (SDLC) Многоэтапный, систематический процесс разработки программных систем.

Основные стратегии проектирования

Меры безопасности должны быть интегрированы в несколько точек в существующий жизненный цикл разработки программного обеспечения (SDLC), чтобы обеспечить:

  • Варианты проектирования не приводят к пробелам в безопасности.

  • Код приложения и конфигурация не создают уязвимости из-за эксплойтируемой реализации и неправильной методики написания кода.

  • Программное обеспечение, приобретенное через цепочку поставок, не представляет угроз безопасности.

  • Код приложения, сборка и процессы развертывания не несанкционированны.

  • Уязвимости, обнаруженные с помощью инцидентов, устраняются.

  • Неиспользуемые ресурсы будут правильно выведены из эксплуатации.

  • Требования к соответствию не скомпрометируются или не сокращаются.

  • Ведение журнала аудита реализуется в средах разработчика.

В следующих разделах приведены стратегии безопасности для часто используемых этапов SDLC.

Сбор и документирование требований к безопасности

Цель этапа требований — собрать и проанализировать функциональные и нефункциональный требования для приложения или новой функции приложения. Этот этап важен, так как он упрощает создание охранников, адаптированных к целям приложения. Защита данных и целостности приложения должна быть основным требованием на каждом этапе жизненного цикла разработки.

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

Все эти решения должны привести к хорошему определению состояния безопасности приложения. Задокументируйте требования к безопасности в согласованной спецификации и отражайте его в невыполненной работы. Это должно явно заявить о инвестициях в безопасность и компромиссах и рисках, которые бизнес готов взять на себя, если инвестиции не утверждены заинтересованными лицами бизнеса. Например, вы можете задокументировать необходимость использования брандмауэра веб-приложения (WAF) перед приложением, например Azure Front Door или Шлюз приложений Azure. Если заинтересованные лица бизнеса не готовы принять дополнительные затраты на запуск WAF, они должны принять риск того, что атаки уровня приложений могут быть направлены к приложению.

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

Перевод требований к безопасности в технические требования

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

Определение измерения безопасности системной архитектуры

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

Оценка возможностей, предоставляемых платформой

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

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

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

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

Определите шаблоны проектирования безопасности, которые должен реализовывать код приложения.

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

Дополнительные сведения см . в шаблонах проектирования облака, поддерживающих безопасность.

Безопасное хранение секретов приложений

Безопасно реализуйте использование секретов приложений и предварительных общих ключей, используемых приложением. Учетные данные и секреты приложений никогда не должны храниться в дереве исходного кода. Используйте внешние ресурсы, такие как Azure Key Vault, чтобы убедиться, что, если исходный код становится доступным для потенциального злоумышленника, доступ к ним не может быть получен. Как правило, найти способы избежать секретов. Использование управляемых удостоверений, когда это возможно, является одним из способов достижения этой цели. Дополнительные сведения см . в рекомендациях по управлению секретами приложений.

Определение планов тестирования

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

Примечание.

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

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

Дополнительные сведения см . в рекомендациях по анализу угроз.

Безопасные методики разработки и тестирования

На этапе разработки и тестирования цель состоит в том, чтобы предотвратить дефекты безопасности и изменения в коде, сборке и конвейерах развертывания.

Будьте хорошо обучены в безопасных методиках кода

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

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

Для повышения непрерывного обучения также следует выполнять внутренние проверки однорангового кода.

Использование средств тестирования безопасности

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

Используйте статическое тестирование безопасности приложений (SAST) для анализа кода для уязвимостей. Интеграция этой методологии в среду разработчика для обнаружения уязвимостей в режиме реального времени.

Используйте динамическое тестирование безопасности приложений (DAST) во время выполнения. Эта цепочка инструментов может проверить наличие ошибок в доменах безопасности и имитировать набор атак для проверки устойчивости приложения. По возможности интегрируйте это средство в конвейеры сборки.

Следуйте отраслевым стандартам для безопасных методов написания кода. Дополнительные сведения см. в разделе "Ресурсы сообщества" этой статьи.

Используйте анализаторы кода и linters, чтобы предотвратить отправку учетных данных в репозиторий исходного кода. Например, анализаторы платформы компилятора .NET (Roslyn) проверяют код приложения.

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

Используйте сочетание тестов. Общие сведения о тестировании безопасности см . в рекомендациях по тестированию безопасности.

Написание достаточного кода

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

Использование функций Azure — еще один способ предотвратить ненужный код. Одним из способов является использование управляемых служб. Дополнительные сведения см. в статье Использование вариантов PaaS (платформа как услуга).

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

Защита сред разработчика

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

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

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

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

Защита кода в конвейерах развертывания

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

Поддержка актуальной инвентаризации всех компонентов, интегрированных в приложение

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

Задачи конвейера

  • Извлечение задач в конвейере из надежных источников, таких как Azure Marketplace. Выполнение задач, написанных поставщиком конвейера. Рекомендуется выполнять задачи GitHub или GitHub Actions. Если вы используете рабочие процессы GitHub, предпочитайте задачи, созданные корпорацией Майкрософт. Кроме того, проверьте задачи, так как они выполняются в контексте безопасности конвейера.

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

Сохранение разных сред

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

Прогрессивное воздействие

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

Защита кода в рабочей среде

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

Сохранение артефактов с версиями

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

Исправления для экстренного реагирования

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

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

Примечание.

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

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

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

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

Непрерывное улучшение. Непрерывная оценка и повышение безопасности процесса разработки программного обеспечения с учетом проверок кода, отзывов, уроков и развития угроз.

Устаревшие ресурсы , устаревшие или не используемые. Это сокращает область поверхности приложения.

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

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

Упрощение функций Azure

Жизненный цикл разработки безопасности Майкрософт (SDL) рекомендует безопасные методики, которые можно применить к жизненному циклу разработки. Дополнительные сведения см. в статье о жизненном цикле разработки безопасности Майкрософт.

Defender для DevOps и средства SAST включены в состав GitHub Advanced Security или Azure DevOps. Эти средства помогут вам отслеживать оценку безопасности для вашей организации.

Следуйте рекомендациям по безопасности Azure, описанным в следующих ресурсах:

Чтобы найти учетные данные в исходном коде, попробуйте использовать такие средства, как GitHub Advanced Security и средства анализа исходного кода OWASP.

Проверьте безопасность любого кода с открытым исходным кодом в приложении. Эти бесплатные средства и ресурсы помогут вам в оценке:

Контрольный список по безопасности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список по безопасности