Рекомендации по API безопасности

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

Жизненный цикл разработки безопасности

Жизненный цикл разработки безопасности (SDL) — это процесс, который предусматривает выполнение ряда действий, направленных на безопасность, на каждом этапе разработки программного обеспечения. К этим действиям и конечным предложениям относятся:

• Разработка моделей угроз
• Использование средств сканирования кода
• Проведение проверок кода и тестирования безопасности

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

Модели угроз

Анализ модели угроз поможет вам обнаружить потенциальные точки атаки в коде. Дополнительные сведения об анализе модели угроз см. в статье Говард, Майкл и LeBlanc, Дэвид [2003], Записывающий безопасный код, 2d ed., ISBN 0-7356-1722-8, Microsoft Press, Redmond, Вашингтон. (Этот ресурс может быть недоступен на некоторых языках и странах.)

Пакеты обновления и обновления безопасности

Среды сборки и тестирования должны зеркально отображать те же уровни пакетов обновления и обновлений безопасности целевой пользовательской базы. Мы рекомендуем установить последние пакеты обновления и обновления системы безопасности для любой платформы или приложения Microsoft, которая входит в среду сборки и тестирования, и поощрять пользователей выполнять то же самое для готовой среды приложения. Дополнительные сведения о пакетах обновлениях и обновлениях системы безопасности см. в разделе Update Windows и Microsoft Security.

Авторизация

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

Рекомендации по шифрованию

При реализации криптографии в приложениях Windows:

• Используйте API шифрования: следующее поколение (CNG) для всех новых разработок. CryptoAPI поддерживается только для обратной совместимости.
• Проектируйте с учетом криптографической гибкости и планируйте переход к постквантовой криптографии. Не разбрасывайте жёстко заданные идентификаторы алгоритмов и размеры ключей по всему коду — вынесите их в одно место, чтобы алгоритмы можно было заменять без переписывания кода. Платформа переходит на постквантовые стандарты NIST: ML-KEM (FIPS 203) для установления ключей и ML-DSA (FIPS 204) для цифровых подписей, поэтому уже сейчас отдавайте предпочтение криптографически гибким решениям — особенно для данных, которые должны сохранять конфиденциальность длительное время, — чтобы противостоять атакам типа «собери сейчас — расшифруй позже».
• Предпочитайте аутентифицированное шифрование (AEAD). Используйте AES-GCM, чтобы шифрование также обнаружило изменение. Если необходимо использовать неаутентифицированный режим, например CBC, используйте его вместе с отдельным механизмом контроля целостности (encrypt-then-MAC) — одна лишь конфиденциальность не защищает от модификации.
• Никогда не используйте повторно nonce (IV) с тем же ключом в AES-GCM. Повторное использование nonce в GCM имеет катастрофические последствия: оно может раскрыть ключ аутентификации и позволить подделывать сообщения. Создайте уникальный nonce для каждой операции шифрования — например, используйте инкрементируемый счётчик или новое случайное 96-битное значение.
• Никогда не используйте режим шифра блоков ECB. ECB шифрует блоки независимо, что приводит к раскрытию паттернов в открытом тексте.
• Никогда не прописывайте криптографические ключи жёстко в исходном коде. Используйте DPAPI для защиты локальных ключей или поставщика хранилища ключей CNG для постоянных ключей.
• Очищайте память от секретов после завершения работы с ними. Перезаписывайте ключевой материал, пароли и другие чувствительные буферы с помощью SecureZeroMemory. В отличие от memset, компилятор не выполняет его оптимизацию.
• Используйте длину ключей 256 бит для AES, 2048+ битов для RSA (3072+ предпочтительный) и 256+ битов для ECDSA.
• Используйте SHA-256 или более сильный для хэширования. Не используйте MD5 или SHA-1 в целях безопасности.
• Всегда проверяйте возвращаемые значения из криптографических функций. Сбой вызова шифрования, произошедший без явного уведомления об ошибке, может привести к тому, что данные будут сохранены в открытом виде.
• Создание случайных чисел с помощью BCryptGenRandom (CNG) — не rand() или других не криптографических PRNG. Передайте BCRYPT_USE_SYSTEM_PREFERRED_RNG, чтобы использовать генератор, выбранный системой по умолчанию, не управляя дескриптором алгоритма.

Дополнительные сведения

Дополнительные сведения о лучших практиках см. в следующих разделах.

Тема	Описание
Запуск с особыми привилегиями	Описывает последствия для безопасности привилегий.
Предотвращение переполнения буфера	Предоставляет сведения о предотвращении переполнения буфера.
Control Flow Guard (CFG)	Описывает уязвимости повреждения памяти.
Создание DACL	В этой статье показано, как создать список управления доступом (DACL) с помощью языка определения дескриптора безопасности (SDDL).
Обработка паролей	Обсуждается последствия использования паролей.
Dynamic контроль доступа расширяемость разработчика	Базовая ориентация на некоторые точки расширяемости разработчика для новых решений Динамической контроль доступа.