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

Механизм безопасности. Шифрование | Устранение рисков

  • Статья
Продукт или служба Статья
Веб-приложение
База данных
Устройство IoT
Облачный шлюз Интернета вещей
Мобильный клиент Dynamics CRM
Клиент Outlook для Dynamics CRM
Сервер удостоверений

Используйте только утвержденные симметричные блочные шифры и длину ключей

Title Сведения
Компонент Веб-приложение
Этап SDL Сборка
Применимые технологии Универсальный шаблон
Атрибуты Недоступно
Справочные материалы Недоступно
Шаги

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

  • Для нового кода приемлемы AES-128, AES-192 и AES-256.
  • Для обеспечения обратной совместимости с существующим кодом можно использовать алгоритм 3DES с тремя ключами.
  • Для продуктов, использующих симметричные блочные шифры:
    • для нового кода требуется алгоритм AES;
    • для обеспечения обратной совместимости с существующим кодом приемлем алгоритм 3DES с тремя ключами;
    • все другие алгоритмы блочного шифрования, в том числе RC2, DES, 3DES с двумя ключами, DESX и Skipjack, могут использоваться только для расшифровки старых данных и должны быть заменены для целей шифрования.
  • Для алгоритмов симметричного блочного шифрования минимальная длина ключа составляет 128 бит. Для нового кода рекомендуется использовать только алгоритм блочного шифрования AES (допустимы AES-128, AES-192 и AES-256).
  • Алгоритм 3DES с тремя ключами допустим, если он уже используется в имеющемся коде. Рекомендуется перейти на использование AES. DES, DESX, RC2 и Skipjack больше не считаются безопасными. Эти алгоритмы могут использоваться, только чтобы расшифровывать имеющиеся данные для обеспечения обратной совместимости, после чего данные необходимо повторно зашифровать с помощью рекомендуемого алгоритма блочного шифрования.

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

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

Разрешенные алгоритмы .NET для управляемого шифрования (в порядке предпочтения):

  • AesCng (совместим со стандартом FIPS);
  • AuthenticatedAesCng (совместим со стандартом FIPS);
  • AESCryptoServiceProvider (совместим со стандартом FIPS);
  • AESManaged (не совместим со стандартом FIPS).

Обратите внимание, что ни один из этих алгоритмов нельзя указать с помощью методов SymmetricAlgorithm.Create или CryptoConfig.CreateFromName без внесения изменений в файл machine.config. Кроме того, алгоритм AES в версиях .NET до .NET 3.5 называется RijndaelManaged, а AesCng и AuthenticatedAesCng доступны через CodePlex и требуют наличия сертификатов CNG в базовой операционной системе

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

Title Сведения
Компонент Веб-приложение
Этап SDL Сборка
Применимые технологии Универсальный шаблон
Атрибуты Недоступно
Справочные материалы Недоступно
Шаги Все симметричные блочные шифры необходимо применять в утвержденном режиме симметричного шифрования. Единственные утвержденные режимы — CBC и CTS. В частности, следует избегать режима электронной кодовой книги (ECB). Его должна утвердить комиссия по шифрованию организации. Использование других режимов шифрования, например OFB, CFB, CTR, CCM и GCM, также должна утвердить комиссия. Повторное использование того же вектора инициализации с блочными шифрами в режимах потокового шифрования, например CTR, может привести к раскрытию зашифрованных данных. Все симметричные блочные шифры также должны использоваться с соответствующим вектором инициализации. Соответствующий вектор инициализации обычно является надежно зашифрованным случайным числом. Он не может быть представлен постоянным значением.

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

Title Сведения
Компонент Веб-приложение
Этап SDL Сборка
Применимые технологии Универсальный шаблон
Атрибуты Недоступно
Справочные материалы Недоступно
Шаги

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

  • RSA — может использоваться для шифрования, обмена ключами и подписывания. Этот алгоритм шифрования должен использовать только такие схемы дополнения, как OAEP и RSA-KEM. Существующий код может использовать схему дополнения PKCS #1 версии 1.5 только для обеспечения совместимости. Использование дополнения нулями явно запрещено. Для нового кода требуемая длина ключей — > 2048 бит. Существующий код может поддерживать ключи длиной < 2048 бит только для обеспечения обратной совместимости после утверждения корпоративной комиссией по шифрованию. Ключи длиной < 1024 бит можно использовать только для расшифровки и проверки старых данных. Их необходимо заменять для операций шифрования и подписывания.
  • ECDSA — может использоваться только для подписывания. Для нового кода требуется ECDSA с ключами длиной >= 256 бит. Подписи на основе ECDSA должны использовать одну из трех утвержденных NIST кривых (P-256, P-384 или P521). Кривые нужно тщательно проанализировать. Их можно использовать только после утверждения комиссией по шифрованию организации.
  • ECDH — можно использовать только для обмена ключами. Для нового кода требуется ECDH с ключами длиной >= 256 бит. При обмене ключами по алгоритму ECDH нужно использовать одну из трех утвержденных NIST кривых (P-256, P-384 или P521). Кривые нужно тщательно проанализировать. Их можно использовать только после утверждения комиссией по шифрованию организации.
  • DSA — может использоваться после анализа и утверждения комиссией по шифрованию организации. Обратитесь к специалисту по безопасности, чтобы запланировать рассмотрение комиссией. Если использование DSA утверждено, учтите, что необходимо запретить использование ключей длиной менее 2048 бит. Начиная с Windows 8 CNG поддерживает длину ключей от 2048 бит.
  • Алгоритм Диффи — Хелмана — может использоваться только для управления ключами сеансов. Для нового кода требуемая длина ключей — >= 2048 бит. Существующий код может поддерживать ключи длиной < 2048 бит только для обеспечения обратной совместимости после утверждения корпоративной комиссией по шифрованию. Ключи длиной < 1024 бит использовать нельзя.

    Используйте утвержденные генераторы случайных чисел

    Title Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Недоступно
    Шаги

    Продукт должны использовать утвержденные генераторы случайных чисел. Поэтому в таком коде нельзя использовать такие псевдослучайные функции, как функция среды выполнения C rand, класс .NET Framework System.Random или системные функции, например GetTickCount. Запрещено также использовать алгоритм генератора случайных чисел на основе двух эллиптических кривых (DUAL_EC_DRBG).

    • CNG — BCryptGenRandom (рекомендуется использовать флаг BCRYPT_USE_SYSTEM_PREFERRED_RNG, только если вызывающий объект не будет выполняться на уровне IRQL выше 0 [то есть PASSIVE_LEVEL]).
    • CAPI — cryptGenRandom.
    • Win32 и 64 — RtlGenRandom (в новых реализациях следует использовать BCryptGenRandom или CryptGenRandom) * rand_s * SystemPrng (для режима ядра).
    • .NET — RNGCryptoServiceProvider или RNGCng.
    • Приложения Магазина Windows — Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom или .GenerateRandomNumber.
    • Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
    • Apple OS X ( 10.7)-< — для получения случайных чисел используйте /dev/random
    • Java (в том числе код Google Java для Android) — класс java.security.SecureRandom. Обратите внимание, что для Android 4.3 (Jelly Bean) разработчики должны следовать решению для Android и обновлять свои приложения таким образом, чтобы явно инициализировать PRNG с использованием энтропии для /dev/urandom или /dev/random.

    Не используйте симметричные потоковые шифры

    Title Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Недоступно
    Шаги Не используйте симметричные потоковые шифры, такие как RC4. Вместо них продукты должны использовать блочные шифры, в частности алгоритм AES с длиной ключа не менее 128 бит.

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

    Title Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Недоступно
    Шаги

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

    Код проверки подлинности сообщений (MAC) — это сведения, присоединенные к сообщению, которые позволяют его получателю проверить подлинность отправителя и целостность сообщения с помощью секретного ключа. Вы можете использовать MAC на основе хэша (HMAC) или MAC на основе блочных шифров, если базовые алгоритмы шифрования с использованием хэша или симметричные алгоритмы шифрования также утверждены. В настоящее время сюда относятся функции HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 и HMAC-SHA512) и алгоритмы MAC на основе блочных шифров CMAC/OMAC1 и OMAC2 (на основе AES).

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

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

    Title Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Недоступно
    Шаги

    Продукты должны использовать семейство алгоритмов хэширования SHA-2 (SHA256, SHA384 и SHA512). Если требуется хэш меньшей длины, например выходные данные длиной 128 бит, чтобы вместить структуру данных, разработанную для MD5-хэша небольшой длины, группы разработки продуктов могут усечь один из хэшей SHA2 (обычно SHA256). Обратите внимание, что SHA384 — это усеченная версия SHA512. Усечение криптографических хэшей до менее 128 бит в целях безопасности не допускается. Новый код не должен использовать хэш-алгоритмы MD2, MD4, MD5, SHA-0, SHA-1 или RIPEMD. Конфликты хэшей подходят для этих алгоритмов с точки зрения вычислений, благодаря чему они эффективно устраняются.

    Разрешенные хэш-алгоритмы .NET для управляемого шифрования (в порядке предпочтения):

    • SHA512Cng (совместим со стандартом FIPS);
    • SHA384Cng (совместим со стандартом FIPS);
    • SHA256Cng (совместим со стандартом FIPS);
    • SHA512Managed (несовместим со стандартом FIPS) — в вызовах методов HashAlgorithm.Create или CryptoConfig.CreateFromName используйте имя алгоритма SHA512;
    • SHA384Managed (несовместим со стандартом FIPS) — в вызовах методов HashAlgorithm.Create или CryptoConfig.CreateFromName используйте имя алгоритма SHA384;
    • SHA256Managed (несовместим со стандартом FIPS) — в вызовах методов HashAlgorithm.Create или CryptoConfig.CreateFromName используйте имя алгоритма SHA256;
    • SHA512CryptoServiceProvider (совместим со стандартом FIPS);
    • SHA256CryptoServiceProvider (совместим со стандартом FIPS);
    • SHA384CryptoServiceProvider (совместим со стандартом FIPS).

    Используйте надежные алгоритмы шифрования для шифрования данных в базе данных

    Title Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Выбор алгоритма шифрования
    Шаги Алгоритмы шифрования определяют преобразования данных, которые не могут с легкостью отменить неавторизованные пользователи. SQL Server позволяет администраторам и разработчикам выбирать из нескольких алгоритмов, в том числе DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-разрядный RC4, DESX, AES-128, AES-192 и AES-256.

    Пакеты служб SSIS должны быть зашифрованы и содержать цифровую подпись

    Title Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Определение источника пакетов с помощью цифровых подписей, Предотвращение угроз и уязвимости для безопасности (службы Integration Services)
    Шаги Источник пакета — это человек или организация, создавшие пакет. Запуск пакета, источник которого неизвестен или не является надежным, может быть опасен. Для предотвращения несанкционированного доступа к пакетам служб SSIS следует использовать цифровые подписи. Кроме того, для обеспечения конфиденциальности пакетов служб SSIS они должны быть зашифрованы во время хранения и передачи.

    Добавьте цифровую подпись к критически важным защищаемым объектам базы данных

    Title Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы ADD SIGNATURE (Transact-SQL)
    Шаги Для проверки целостности критически важных защищаемых объектов базы данных следует использовать цифровые подписи. Защищаемые объекты базы данных, например хранимые процедуры, функции, сборки или триггеры, могут иметь цифровую подпись. Это может быть эффективно, к примеру, в таком случае: независимый поставщик программного обеспечения должен предоставить поддержку программного обеспечения одному из клиентов. Прежде чем предоставлять поддержку, поставщик программного обеспечения может проверить, не был ли защищаемый объект базы данных в составе программного обеспечения случайно или злонамеренно изменен. Если защищаемый объект имеет цифровую подпись, независимый поставщик может проверить целостность на основе этой подписи.

    Используйте расширенное управление ключами SQL Server для защиты ключей шифрования

    Title Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Расширенное управление ключами (Extensible Key Management), Расширенное управление ключами с помощью хранилища ключей Azure (SQL Server)
    Шаги Расширенное управление ключами SQL Server позволяет хранить ключи шифрования, защищающие файлы базы данных, на внешних устройствах, таких как смарт-карты, USB-устройства или модули расширенного управления ключами и аппаратные модули безопасности. Предусмотрена также защита данных от администраторов базы данных (за исключением членов группы sysadmin). Данные могут быть зашифрованы при помощи ключей шифрования, доступ к которым имеет только пользователь базы данных на внешнем модуле расширенного управления ключами или аппаратного модуля безопасности.

    Используйте функцию Always Encrypted, если ключи шифрования не следует раскрывать для ядра СУБД

    Title Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии SQL Azure, локальные
    Атрибуты SQL версии 12, MsSQL2016
    Справочные материалы Always Encrypted (ядро СУБД)
    Шаги Always Encrypted — это функция, предназначенная для защиты конфиденциальных данных, таких как номера кредитных карта или национальные или региональные идентификационные номера (например, номера социального страхования США), хранящиеся в базе данных Azure SQL или SQL Server базах данных. Always Encrypted позволяет клиентам шифровать конфиденциальные данные в приложениях, не раскрывая ключи шифрования в ядре СУБД (база данных SQL или SQL Server). Таким образом, Always Encrypted разделяет пользователей на владельцев данных (которые могут просматривать их) и управляющих данными (но без доступа к ним).

    Безопасно храните ключи шифрования на устройстве Интернета вещей

    Title Сведения
    Компонент Устройства Интернета вещей
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты ОС устройства, Windows 10 IoT Core, подключение устройств, пакет SDK для устройств Azure IoT
    Справочные материалы Доверенный платформенный модуль в Windows 10 IoT Core, настройка доверенного платформенного модуля в Windows 10 IoT Core, доверенный платформенный модуль пакета SDK для устройств Azure IoT
    Шаги Храните симметричные ключи или закрытые ключи сертификатов в хранилище с аппаратной защитой, например в доверенном платформенном модуле (TPM) или на смарт-карте. Windows 10 IoT Базовая поддерживает использование доверенного платформенного модуля. Список совместимых доверенных платформенных модулей см. в статье Дискретный доверенный платформенный модуль (dTPM). Рекомендуется использовать дискретный доверенный платформенный модуль или доверенный платформенный модуль, интегрированный во встроенное ПО. Доверенный платформенный модуль в виде ПО следует использовать только для целей разработки и тестирования. Как только TPM будет доступен и в нем будут подготовлены ключи, необходимо написать код, который создает маркер, без жесткого кодирования важной информации.

    Пример

    TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM 
string hubUri = myDevice.GetHostName(); 
string deviceId = myDevice.GetDeviceId(); 
string sasToken = myDevice.GetSASToken(); 

var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);

    Как можно увидеть, что первичный ключ устройства отсутствует в коде. Вместо этого он хранится в слоте 0 в доверенном платформенном модуле. Устройство TPM создает кратковременный маркер SAS, который затем используется для подключения к Центру Интернета вещей.

    Используйте случайный симметричный ключ достаточной длины для проверки подлинности в Центре Интернета вещей

    Title Сведения
    Компонент Облачный шлюз Интернета вещей
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Выбор шлюза: Центр Интернета вещей Azure
    Справочные материалы Недоступно
    Шаги Центр Интернета вещей содержит реестр удостоверений устройств и во время подготовки устройства автоматически создает случайный симметричный ключ. Рекомендуется использовать эту функцию реестра удостоверений Центра Интернета вещей для создания ключей для проверки подлинности. Центр Интернета вещей также позволяет задавать ключ при создании устройства. Если ключ создан вне Центра Интернета вещей во время подготовки устройства, рекомендуется создать случайный симметричный ключ длиной по крайней мере 256 бит.

    Убедитесь, что настроена политика управления устройствами, которая требует использования ПИН-кода и позволяет выполнять удаленную очистку

    Title Сведения
    Компонент Мобильный клиент Dynamics CRM
    Этап SDL Развертывание
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Недоступно
    Шаги Убедитесь, что настроена политика управления устройствами, которая требует использования ПИН-кода и позволяет выполнять удаленную очистку

    Убедитесь, что настроена политика управления устройствами, которая требует использования ПИН-кода, пароля или автоматической блокировки и шифрует все данные (например, с помощью BitLocker)

    Title Сведения
    Компонент Клиент Outlook для Dynamics CRM
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Недоступно
    Шаги Убедитесь, что настроена политика управления устройствами, которая требует использования ПИН-кода, пароля или автоматической блокировки и шифрует все данные (например, с помощью BitLocker)

    Настройте отзыв ключей подписи при использовании сервера удостоверений

    Title Сведения
    Компонент Сервер удостоверений
    Этап SDL Развертывание
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Сервер удостоверений: ключи, подписи и шифрование
    Шаги Настройте отзыв ключей подписи при использовании сервера удостоверений. Ссылка выше позволяет перейти в раздел, где объясняется, как это спланировать, избегая простоев для приложений, использующих сервер удостоверений.

    На сервере удостоверений необходимо использовать надежно зашифрованный идентификатор и секрет клиента

    Title Сведения
    Компонент Сервер удостоверений
    Этап SDL Сборка
    Применимые технологии Универсальный шаблон
    Атрибуты Недоступно
    Справочные материалы Недоступно
    Шаги

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

    • Создайте в качестве идентификатора клиента случайный идентификатор GUID.
    • Создайте в качестве секрета случайный 256-разрядный ключ шифрования.