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

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

  • Статья

Применимо к этой рекомендации Power Platform контрольного списка хорошо спроектированной безопасности:

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

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

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

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

Определения

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

Ключевые стратегии проектирования

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

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

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

Этап требований

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

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

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

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

Этап проектирования

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

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

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

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

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

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

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

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

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

  • Избегайте жесткого задания в коде. Избегайте жесткого задания в коде URL-адресов и ключей. Например, избегайте жесткого задания в коде действия HTTP Power Automate URL-адреса или ключа внутренней службы. Вместо этого используйте пользовательский соединитель или переменную среды для URL-адреса и Azure Key Vault для ключа API.

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

Заметка

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

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

Для получения дополнительной информации см. Рекомендации по анализу угроз.

Этап разработки и тестирования

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

Нужно быть хорошо обученным методам безопасного написания кода

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

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

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

Используйте инструменты анализа кода

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

Выполнение нечёткого тестирования

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

Пишите ровно столько кода, сколько требуется

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

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

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

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

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

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

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

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

Мы рекомендуем использовать Конвейеры для Power Platform для ваших развертываний. Расширяйте конвейеры с помощью GitHub Actions. Если вы используете рабочие процессы GitHub, отдавайте предпочтение задачам, созданным Microsoft. Кроме того, проверяйте задачи, поскольку они выполняются в контексте безопасности вашего конвейера.

Изучите использование субъектов-служб для развертывания.

Этап производства

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

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

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

Экстренные исправления

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

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

Заметка

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

Разделяйте разные среды

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

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

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

Этап обслуживания

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

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

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

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

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

SDL в Microsoft Power Platform

Power Platform построен на культуре и методологии безопасного проектирования. И культура, и методология постоянно совершенствуются с помощью ведущих в отрасли практик Microsoftжизненного цикла разработки безопасности (SDL) и моделирования угроз .

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

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

MicrosoftSDL эквивалентна модели зрелости обеспечения программного обеспечения OWASP (SAMM). Оба основаны на предположении, что безопасная структура является неотъемлемой частью безопасности веб-приложений. Для получения дополнительной информации см. 10 основных рисков OWASP: меры по снижению риска в Power Platform.

Возможности в Power Platform

Microsoft В документе Security Development Lifecycle (SDL) рекомендуются безопасные методы, которые можно применять в жизненном цикле разработки. Для получения дополнительной информации см. Microsoft Жизненный цикл разработки безопасности.

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

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

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

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

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