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

  • Статья

Применяется к этой рекомендации по безопасности 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) во время выполнения. Эта цепочка инструментов может проверка для ошибок в доменах безопасности и имитировать набор атак для проверки устойчивости безопасности приложения. По возможности интегрируйте это средство в конвейеры сборки.

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

Используйте анализаторы кода и анализаторы кода, чтобы предотвратить отправку учетных данных в репозиторий исходного кода. Например, .NET Compiler Platform анализаторы (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.

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

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

См. полный набор рекомендаций.

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