Общие сведения о разработке и операциях в области безопасности
Как корпорация Майкрософт реализует методики безопасной разработки?
Жизненный цикл разработки защищенных приложений (Майкрософт) (SDL) — это процесс обеспечения безопасности, ориентированный на разработку и эксплуатацию безопасного программного обеспечения. SDL предоставляет детальные измеримые требования к безопасности для разработчиков и инженеров в корпорации Майкрософт, чтобы уменьшить количество и серьезность уязвимостей в наших продуктах и службах. Все группы разработчиков программного обеспечения Майкрософт должны следовать требованиям SDL, и мы постоянно обновляем SDL, чтобы отразить изменение ландшафта угроз, отраслевые рекомендации и нормативные стандарты для соответствия требованиям.
Как SDL майкрософт повышает безопасность приложений?
Процесс SDL в Корпорации Майкрософт можно рассматривать в виде пяти этапов разработки: требований, проектирования, реализации, проверки и выпуска. Он начинается с определения требований к программному обеспечению с учетом безопасности. Мы задаем вопросы, связанные с безопасностью, о том, что должно выполнять приложение. Например, нужно ли приложению собирать конфиденциальные данные? Будет ли приложение выполнять конфиденциальные или важные задачи? Требуется ли приложению принимать входные данные из ненадежных источников?
После определения требований, связанных с безопасностью, мы разрабатываем наше программное обеспечение для внедрения функций безопасности, соответствующих этим требованиям. Наши разработчики реализуют требования к SDL и дизайну в коде, который мы проверяем с помощью ручного анализа кода, автоматизированного средства безопасности и тестирования на проникновение. Наконец, перед выпуском кода новые функции и существенные изменения проходят окончательную проверку безопасности и конфиденциальности, чтобы убедиться, что выполнены все требования.
Дополнительные сведения о SDL см. в статье Жизненный цикл разработки системы безопасности Майкрософт.
Как корпорация Майкрософт тестирует исходный код на наличие распространенных уязвимостей?
Для поддержки наших разработчиков в реализации требований безопасности во время разработки кода и после выпуска корпорация Майкрософт предоставляет набор средств безопасной разработки для автоматической проверки исходных кодов на наличие недостатков и уязвимостей безопасности. Корпорация Майкрософт определяет и публикует список утвержденных средств для использования нашими разработчиками, таких как компиляторы и среды разработки, а также встроенные проверки безопасности, которые автоматически выполняются в конвейерах сборки Майкрософт.
Прежде чем код можно будет включить в ветвь выпуска, SDL требует ручной проверки кода отдельным рецензентом. Проверяющие кода проверяют наличие ошибок кодирования и проверяют, соответствуют ли изменения кода требованиям к SDL и проекту, проходят функциональные тесты и тесты безопасности и работают надежно. Они также проверяют связанную документацию, конфигурации и зависимости, чтобы убедиться, что изменения кода задокументированы должным образом и не вызовут непредвиденных побочных эффектов. Если проверяющий обнаруживает проблемы во время проверки кода, он может попросить отправителя повторно отправить код с предложенными изменениями и дополнительным тестированием. Проверяющие кода также могут принять решение полностью заблокировать регистрацию кода, который не соответствует требованиям. После того как рецензент признал код удовлетворительным, рецензент предоставляет утверждение, которое требуется для того, чтобы код смог перейти к следующему этапу развертывания.
Помимо безопасных средств разработки и проверки кода вручную, корпорация Майкрософт применяет требования SDL с помощью автоматизированных средств безопасности. Многие из этих средств встроены в конвейер фиксации и автоматически анализируют код на наличие ошибок безопасности по мере его возврата и компиляции новых сборок. Примеры включают статический анализ кода для распространенных ошибок безопасности и сканеры учетных данных, которые анализируют код на наличие внедренных секретов. Проблемы, обнаруженные автоматизированными средствами безопасности, должны быть устранены, прежде чем новые сборки смогут пройти проверку безопасности и будут утверждены для выпуска.
Как корпорация Майкрософт управляет программным обеспечением с открытым кодом?
Корпорация Майкрософт приняла высокоуровневую стратегию управления безопасностью с открытым кодом, в которой используются средства и рабочие процессы, предназначенные для:
- понимать, какие компоненты с открытым исходным кодом используются в наших продуктах и службах;
- отслеживать, где и как используются эти компоненты;
- определять наличие уязвимостей у таких компонентов,
- реагировать должным образом при обнаружении уязвимостей, влияющих на работу этих компонентов.
Разработчики Майкрософт несут ответственность за безопасность всего программного обеспечения с открытым исходным кодом, использующегося в продуктах и службах Майкрософт. Чтобы обеспечить эту безопасность в большом масштабе, корпорация Майкрософт создала необходимые возможности в инженерных системах с помощью управления компонентами (CG), которая автоматизирует обнаружение с открытым кодом, рабочие процессы юридических требований и оповещение об уязвимых компонентах. Автоматизированные средства CG проверяют сборки в Корпорации Майкрософт на наличие компонентов с открытым кодом и связанных уязвимостей системы безопасности или юридических обязательств. Обнаруженные компоненты регистрируются и направляются соответствующим отделам для проверки с точки зрения коммерческой эффективности и безопасности. В ходе проверки оцениваются все юридические обязательства и уязвимости для системы безопасности, связанные с использованием компонентов с открытым исходным кодом, и проблемы устраняются до того, как эти компоненты будут приняты для развертывания.
Связанные внешние правила & сертификации
Веб-службы Майкрософт регулярно проверяются на соответствие внешним нормативным требованиям и сертификациям. Сведения о проверке элементов управления, связанных с разработкой и эксплуатацией безопасности, см. в следующей таблице.
Azure и Dynamics 365
| Внешний аудит | Section | Дата последнего отчета |
|---|---|---|
| ISO 27001/27002 Заявление о применимости Сертификат |
A.12.1.2. Элементы управления изменениями A.14.2. Безопасность в процессах разработки и поддержки |
6 ноября 2023 г. |
| ISO 27017 Заявление о применимости Сертификат |
A.12.1.2. Элементы управления изменениями A.14.2. Безопасность в процессах разработки и поддержки |
6 ноября 2023 г. |
| SOC 1; SOC 2; SOC 3 |
SDL-1: методология жизненного цикла разработки безопасности (SDL) SDL-2: требования к управлению безопасностью, описанные в выпусках SDL-4: разделение тестовых и рабочих сред SDL-6: проверка вредоносных программ в сборках исходного кода SDL7: полугодовой обзор SDL |
Пятница, 20 мая 2024 г. |
Microsoft 365
| Внешний аудит | Section | Дата последнего отчета |
|---|---|---|
| FedRAMP (Office 365) | SA-3: жизненный цикл разработки системы | 31 июля 2023 г. |
| ISO 27001/27002/27017 Заявление о применимости Сертификация (27001/27002) Сертификация (27017) |
A.12.1.2. Элементы управления изменениями A.14.2. Безопасность в процессах разработки и поддержки |
Март 2024 г. |
| SOC 1; SOC 2; |
CA-03: управление рисками CA-18: управление изменениями CA-19: мониторинг изменений CA-21: тестирование изменений CA-38: базовые конфигурации CA-46: проверка безопасности |
23 января 2024 г. |
Ресурсы
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по