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

Стратегии архитектуры для защиты жизненного цикла разработки

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

SE:02 Выравнивайте жизненный цикл безопасной разработки (SDL) на протяжении всего жизненного цикла разработки программного обеспечения (SDLC), чтобы обеспечить конфиденциальность, целостность и доступность программного обеспечения, а также внедрить менталитет безопасности.

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

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

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

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

Терминология

Срок Definition
Общие уязвимости и экспозиции (CVE) Общедоступная база данных известных уязвимостей и уязвимостей системы безопасности в программном обеспечении и оборудовании.
Глубинная защита Стратегия безопасности, которая использует несколько уровней защиты для защиты систем, поэтому если один слой завершается сбоем, другие продолжают обеспечивать безопасность.
DevSecOps Подход, который интегрирует методики безопасности в процесс DevOps, подчеркивая совместную работу между командами разработки, безопасности и операций на протяжении всего жизненного цикла программного обеспечения.
Динамическое тестирование безопасности приложений (DAST) Тестирование безопасности, которое анализирует приложения во время выполнения для выявления уязвимостей путем имитации сценариев атак в реальном мире.
Манажируемая идентичность Функция Azure, предоставляющая приложениям автоматически управляемую идентификацию в Microsoft Entra ID, устраняя необходимость хранения учетных данных в программном коде.
Прогрессивное воздействие Стратегия развертывания, которая постепенно выпускает изменения подмножествам пользователей, чтобы свести к минимуму риск и устранить потенциальные проблемы.
Жизненный цикл разработки безопасности (SDL) Набор методик, предоставляемых корпорацией Майкрософт, которая поддерживает требования к обеспечению безопасности и соответствию требованиям.
Жизненный цикл разработки программного обеспечения (SDLC) Многоэтапный, систематический процесс разработки программных систем.
Статическое тестирование безопасности приложений (SAST) Тестирование безопасности, которое анализирует исходный код, байт-код или двоичные файлы без выполнения программы для выявления потенциальных уязвимостей.
ШАГ Методология моделирования угроз, которая классифицирует угрозы на шесть типов: спуфинг, изменение данных, подтверждение, раскрытие информации, отказ в обслуживании и повышение привилегий.
Безопасность цепочки поставок Защита всей цепочки поставок программного обеспечения, включая сторонние компоненты, средства разработки и процессы от компрометации или изменения.
Моделирование угроз Структурированный процесс для выявления, оценки и устранения потенциальных угроз безопасности в системе на раннем этапе разработки.

Подумайте о безопасности с одного дня

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

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

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

Выбор вариантов технологии, поддерживающих безопасность

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

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

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

Сделать моделирование угроз дисциплиной проектирования

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

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

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

См. Средство моделирования угроз Майкрософт.

Создание опыта безопасного написания кода

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

Использование тестирования безопасности в качестве стратегического элемента управления

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

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

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

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

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

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

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

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

Укреплять среды разработчика

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

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

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

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

Разработчики должны следовать утвержденным средствам разработчика и использовать установки, управляемые централизованно. Среды разработки, такие как GitHub Codespaces и Microsoft Dev Box, могут обеспечить безопасность, предоставляя изолированные, централизованно управляемые рабочие области.

Тесты также должны выполняться в управляемой среде только с минимальными разрешениями.

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

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

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

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

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

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

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on