Обзор. Защита инженерных систем в SFI

Инициатива "Безопасное будущее" (SFI), запущенная в ноябре 2023 года как многолетняя работа по повышению безопасности процессов разработки, создания, тестирования и управления продуктами и службами корпорации Майкрософт.

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

В этой статье приведены общие сведения о компоненте SFI "Защита инженерных систем".

Перед началом работы

Основные принципы и цели

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

Цели Майкрософт и сопоставление нулевого доверия и NIST для этого компонента приведены в следующей таблице.

Цель "Столп" "Никому не доверяй" Сопоставление NIST
1. Завершение инвентаризации ресурсов программного обеспечения

Инвентаризация охватывает все перепозиции и конвейеры Azure DevOps с полными метаданными. Средство StartRight гарантирует, что 80% активов инвентаризируется в момент создания, а оставшиеся 20% регистрируются в течение 24 часов. Это позволяет быстро реагировать на инциденты и применять универсальные политики. Мы увеличили масштаб инвентаризации с более детализированным распределением прав собственности для более эффективного реагирования.		 Проверяйте явно: защита идентификационных данных. Строгая аттестация ключей, интегрированных в рабочий процесс. >
Предположим, что нарушение: защищайте ключи так, как если бы могла произойти компрометация, используя аппаратно-основанную изоляцию.		 ID.AM-02 (программные платформы и приложения в организации подлежат инвентаризации).
Поддержание полной инвентаризации всех инженерных программных активов напрямую соответствует требованию NIST отслеживать и управлять всеми компонентами программного обеспечения и компонентов платформы.
2. Нулевое доверие для доступа к исходному коду

Сокращен постоянный доступ для ролей администратора и требуется повышение прав по требованию. Приложения на основе OAuth в Azure DevOps используют аутентификацию Microsoft Entra с обеспечением условного доступа. Проверки наличия охватывают почти все изменения в рабочем коде.		 Проводите явную проверку: проверенные библиотеки по стандартам снижают вариативность и риск. Используйте согласованную проверку.

Предположение о взломе: снижает поверхность атаки для кастомных реализаций.		 PR.AA-01 (Идентификаторы аутентифицируются соизмеримо с уровнем риска).

PR. AA-02 (Доступ авторизован с помощью атрибутов на основе ролей).
Надежная проверка подлинности перед доступом к коду.

PR. AA-03 (Access управляется с помощью контекстных атрибутов).
Устройство, расположение, риск сеанса проверяется перед доступом к репозиторию.

PR. AA-04 (доступ ограничен на основе сегментации и наименьших привилегий).
Принудительное применение сегментации репозитория, ветви и среды.

PR. AA-05 (разрешения управляются, применяются и периодически проверяются).
Непрерывная проверка разрешений на доступ к коду.

PR. AA-06 (Доступ соответствует наименьшим привилегиям).
Нулевое доверие обеспечивает минимальный доступ к репозиториям кода.

PR.DS-01 (данные управляются в соответствии с корпоративными политиками).
Элементы управления для обработки конфиденциального исходного кода.

PR.DS-02 (данные защищены при хранении).
Шифрование репозитория и безопасное хранение кода.

PR.DS-10 (доступ к данным отслеживается для обнаружения несанкционированного действия).
Мониторинг исходного кода на аномалии.
3. Защита разработки кода

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

Использование наименьших привилегий: MFA укрепляет принудительное применение наименее привилегированных прав, уменьшая несанкционированный доступ.		 PR. AA-04 (Доступ ограничен с помощью сегментации и наименьших привилегий).
Проектирование пайплайна обеспечивает соблюдение правил обработки кода.

PR.PS-06 (службы и процессы проверяются на соответствие требованиям безопасности перед выполнением).
Код должен соответствовать политике и контрольным точкам безопасности конвейера перед развертыванием.
4. Стандартизация безопасных конвейеров разработки

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

Предположим, нарушение: относитесь к каждому секрету как потенциально скомпрометированному, если он не надежно охраняется.		 PR.DS-02 (данные защищены при хранении).
Безопасное хранилище для артефактов и секретов сборки.

PR.DS-10 (отслеживается доступ к данным).
Мониторинг артефактов и журналов конвейера

PR. IR-01 (процессы готовятся к эффективному реагированию на инциденты).
Конвейеры данных включают логирование, оповещение, откат и происхождение данных.

PR.PS-06 (процессы и службы проверяются на соответствие требованиям безопасности перед выполнением).
Конвейеры применяют обязательные шлюзы безопасности.
5. Защита цепочки поставок программного обеспечения

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

Предположим, нарушение. Убедитесь, что недопустимые или неправильные маркеры отклоняются.		 GV.SC-01 (устанавливается управление рисками цепочки поставок).

GV.SC-02 (определяются поставщики и зависимости).

GV.SC-03 (поставщики оцениваются с точки зрения риска).

GV.SC-04 (требования к безопасности для поставщиков устанавливаются).

GV.SC-07 (компоненты цепочки поставок контролируются с точки зрения риска).

GV.SC-09 (поставщики и компоненты проверяются в соответствии с требованиями).

ID.RA-10 (оцениваются риски от поставщиков и зависимостей).

PR.PR-06 (процессы и службы проверяются на соответствие требованиям безопасности перед выполнением).

Дальнейшие шаги

  • Last updated on