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

Обновлено: 30.06.2024

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

Требование

Все, кто хранит защищенные данные на портативных устройствах (таких как ноутбуки и смартфоны) или съемных и легко переносимых носителях (таких как USB-накопители или компакт-диски/DVD-диски), должны использовать общепринятые технологии шифрования.

Описание риска

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

Дополнительные ресурсы

План восстановления данных

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

Защищенные данные резервируются на других съемных носителях, соответствующих требованиям, изложенным в этом документе, или
Защищенные данные резервируются в UCBackup с шифрованием.

Инструмент управления паролями

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

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

НЕ размещайте базу данных управления паролями на веб-сайтах или в службах обмена файлами

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

Включите многофакторную аутентификацию (MFA), если инструмент управления паролями ее поддерживает. Следующие параметры MFA следует предпочесть любым вариантам MFA на основе SMS (текстовое сообщение) или на основе телефона, поскольку они более уязвимы для обхода. .

Приложения OTP на основе времени, такие как Google Authenticator, Authy или Duo

Физический ключ безопасности U2F, например YubiKey

Примером инструмента для управления паролями является LastPass(внешняя ссылка) , который доступен бесплатно в операционных системах Windows, Linux и Mac OS X.

Эта статья поможет вам устранить проблемы, которые могут возникнуть при использовании политики Microsoft Intune для управления автоматическим шифрованием BitLocker на устройствах. Портал Intune указывает, не удалось ли BitLocker зашифровать одно или несколько управляемых устройств.

Чтобы сузить круг причин проблемы, просмотрите журналы событий, как описано в разделе Устранение неполадок BitLocker. Сосредоточьтесь на журналах управления и операций в папке Applications and Services logs\Microsoft\Windows\BitLocker-API. В следующих разделах содержится дополнительная информация о том, как разрешить указанные события и сообщения об ошибках:

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

Сведения о том, как убедиться, что политики Intune правильно применяют BitLocker, см. в разделе Проверка правильности работы BitLocker.

Идентификатор события 853: Ошибка: на этом компьютере не найдено совместимое устройство безопасности Trusted Platform Module (TPM)

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

Причина

Устройство, которое вы пытаетесь защитить, может не иметь чипа TPM, или BIOS устройства может быть настроен на отключение TPM.

Разрешение

Чтобы решить эту проблему, проверьте следующее:

TPM включен в BIOS устройства.
Состояние TPM в консоли управления TPM выглядит следующим образом:
- Готово (TPM 2.0)
- Инициализировано (TPM 1.2)
Дополнительную информацию см. в разделе Устранение неполадок TPM.

Идентификатор события 853: Ошибка: BitLocker Drive Encryption обнаружил загрузочный носитель (CD или DVD) на компьютере

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

Причина

Во время подготовки BitLocker Drive Encryption записывает конфигурацию устройства, чтобы установить базовый уровень. Если впоследствии конфигурация устройства изменится (например, если вы извлечете носитель), автоматически запустится режим восстановления BitLocker.

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

Разрешение

Извлеките загрузочный носитель и перезагрузите устройство. После перезагрузки устройства проверьте состояние шифрования.

Идентификатор события 854: WinRE не настроен

Информация о событии выглядит следующим образом:

Не удалось включить тихое шифрование. WinRe не настроен.

Ошибка: этот компьютер не может поддерживать шифрование устройства, так как WinRE настроен неправильно.

Причина

Среда восстановления Windows (WinRE) — это минимальная операционная система Windows, основанная на среде предустановки Windows (Windows PE). WinRE включает в себя несколько инструментов, которые администратор может использовать для восстановления или сброса Windows и диагностики проблем с Windows.Если устройство не может запустить обычную операционную систему Windows, оно пытается запустить WinRE.

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

Если WinRE недоступна на устройстве, подготовка останавливается.

Разрешение

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

Шаг 1. Проверьте конфигурацию разделов диска

Процедуры, описанные в этом разделе, зависят от разделов диска по умолчанию, которые Windows настраивает во время установки. Windows 11 и Windows 10 автоматически создают раздел восстановления, содержащий файл Winre.wim. Конфигурация раздела выглядит следующим образом.

Чтобы проверить конфигурацию разделов диска, откройте окно командной строки с повышенными привилегиями и выполните следующие команды:

Если статус любого из томов неисправен или раздел восстановления отсутствует, возможно, вам придется переустановить Windows. Прежде чем сделать это, проверьте конфигурацию образа Windows, который вы используете для подготовки. Убедитесь, что образ использует правильную конфигурацию диска. Конфигурация образа должна выглядеть следующим образом (этот пример взят из Microsoft Endpoint Configuration Manager).

Если статус Windows RE не включен, выполните следующую команду, чтобы включить его:

Шаг 3. Проверьте конфигурацию загрузчика Windows

Если состояние раздела исправно, но команда reactc /enable приводит к ошибке, убедитесь, что загрузчик Windows содержит GUID последовательности восстановления. Для этого выполните следующую команду в окне командной строки с повышенными привилегиями:

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

В выходных данных найдите раздел «Загрузчик Windows», который содержит идентификатор строки = . В этом разделе найдите атрибут recoverysequence. Значение этого атрибута должно быть значением GUID, а не строкой нулей.

Идентификатор события 851: обратитесь к производителю за инструкциями по обновлению BIOS

Информация о событии выглядит следующим образом:

Не удалось включить автоматическое шифрование.

Ошибка: шифрование диска BitLocker не может быть включено на диске операционной системы. Обратитесь к производителю компьютера за инструкциями по обновлению BIOS.

Причина

Устройство должно иметь унифицированный расширяемый интерфейс встроенного ПО (UEFI) BIOS. Шифрование диска Silent BitLocker не поддерживает устаревшую версию BIOS.

Разрешение

Чтобы проверить режим BIOS, используйте приложение "Сведения о системе". Для этого выполните следующие действия:

Выберите «Пуск» и введите msinfo32 в поле поиска.

Убедитесь, что для параметра BIOS Mode установлено значение UEFI, а не Legacy.

Если для параметра «Режим BIOS» установлено значение «Устаревший», вам необходимо переключить BIOS в режим UEFI или EFI. Действия для этого зависят от устройства.

Если устройство поддерживает только устаревший режим, вы не можете использовать Intune для управления шифрованием устройства BitLocker на устройстве.

Сообщение об ошибке: не удалось прочитать переменную UEFI «SecureBoot»

Появляется сообщение об ошибке следующего вида:

Ошибка: BitLocker не может использовать безопасную загрузку для обеспечения целостности, поскольку не удалось прочитать переменную UEFI «SecureBoot». Требуемая привилегия не принадлежит клиенту.

Причина

Регистр конфигурации платформы (PCR) — это ячейка памяти в TPM. В частности, PCR 7 измеряет состояние безопасной загрузки. Для автоматического шифрования диска BitLocker необходимо, чтобы безопасная загрузка была включена.

Разрешение

Эту проблему можно решить, проверив профиль проверки PCR доверенного платформенного модуля и состояние безопасной загрузки. Для этого выполните следующие действия:

Шаг 1. Проверка профиля проверки PCR модуля TPM

Чтобы убедиться, что PCR 7 используется, откройте окно командной строки с повышенными привилегиями и выполните следующую команду:

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

Если профиль проверки PCR не включает 7 (например, значения включают 0, 2, 4 и 11, но не 7), то безопасная загрузка не включена.

2. Проверьте состояние безопасной загрузки

Чтобы проверить состояние безопасной загрузки, используйте приложение "Информация о системе". Для этого выполните следующие действия:

Выберите «Пуск» и введите msinfo32 в поле поиска.

Убедитесь, что для параметра Состояние безопасной загрузки установлено значение Вкл., как показано ниже:

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

Вы также можете использовать командлет Confirm-SecureBootUEFI для проверки состояния безопасной загрузки. Для этого откройте окно PowerShell с повышенными привилегиями и выполните следующую команду:

Если компьютер поддерживает безопасную загрузку и включена безопасная загрузка, этот командлет возвращает значение "True".

Если компьютер поддерживает безопасную загрузку, а безопасная загрузка отключена, этот командлет возвращает значение "False".

Если компьютер не поддерживает безопасную загрузку или является компьютером с BIOS (не UEFI), этот командлет возвращает «Командлет не поддерживается на этой платформе».

Идентификатор события 846, 778 и 851: ошибка 0x80072f9a

В этом случае вы развертываете политику Intune для шифрования устройства Windows 11, Windows 10 версии 1809 и хранения пароля восстановления в Azure Active Directory (Azure AD). В рамках настройки политики вы выбрали параметр Разрешить обычным пользователям включать шифрование во время присоединения к Azure AD.

Развертывание политики завершается с ошибкой и генерирует следующие события (отображаемые в средстве просмотра событий в папке Applications and Services Logs\Microsoft\Windows\BitLocker API):

Идентификатор события: 846

Событие: не удалось выполнить резервное копирование данных восстановления BitLocker Drive Encryption для тома C: в Azure AD.

TraceId: Error: Unknown HResult Error код: 0x80072f9a

Идентификатор события: 778

Событие: том BitLocker C: был возвращен в незащищенное состояние.

Идентификатор события: 851

Событие: не удалось включить автоматическое шифрование.

Ошибка: неизвестный код ошибки HResult: 0x80072f9a.

Эти события относятся к коду ошибки 0x80072f9a.

Причина

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

Эта проблема затрагивает Windows 11 и Windows 10 версии 1809.

Разрешение

Чтобы решить эту проблему, установите обновление от 21 мая 2019 г.

Сообщение об ошибке: существуют конфликтующие настройки групповой политики для параметров восстановления на дисках операционной системы

Вы получаете сообщение, похожее на следующее:

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

Разрешение

Чтобы решить эту проблему, проверьте параметры объекта групповой политики (GPO) на наличие конфликтов. Дополнительные рекомендации см. в следующем разделе "Просмотр конфигурации политики BitLocker".

Дополнительные сведения о объектах групповой политики и BitLocker см. в справочнике по групповой политике BitLocker.

Проверьте конфигурацию политики BitLocker

Сведения о том, как использовать политику вместе с BitLocker и Intune, см. в следующих ресурсах:

Intune предлагает следующие типы принудительного применения BitLocker:
- Автоматически (применяется, когда устройство присоединяется к Azure AD в процессе подготовки. Этот параметр доступен в Windows 10 версии 1703 и более поздних или Windows 11.)
- Тихая (политика защиты конечной точки. Этот параметр доступен в Windows 10 версии 1803 и более поздних или Windows 11.)
- Интерактивный (политика конечной точки для версий Windows старше Windows 10 версии 1803 или Windows 11.)
Если ваше устройство работает под управлением Windows 10 версии 1703 или более поздней или Windows 11, поддерживает Modern Standby (также известное как Instant Go) и совместимо с HSTI, присоединение устройства к Azure AD запускает автоматическое шифрование устройства. Для принудительного шифрования устройства не требуется отдельная политика защиты конечных точек.

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

Ссылки OMA-URI для этих настроек следующие:

OMA-URI: ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption
Тип значения: целое
Значение: 1 (1 = требуется, 0 = не настроено)

OMA-URI: ./Device/Vendor/MSFT/BitLocker/AllowWarningForOtherDiskEncryption
Тип значения: целое
Значение: 0 (0 = заблокировано, 1 = разрешено)

Из-за обновления CSP политики BitLocker, если на устройстве используется Windows 10 версии 1809 или более поздней или Windows 11, вы можете использовать политику защиты конечной точки для принудительного автоматического шифрования устройства BitLocker, даже если устройство не совместимо с HSTI. .

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

Если устройство не поддерживает Modern Standby, но совместимо с HSTI и использует более раннюю версию Windows, чем Windows 10, версию 1803 или Windows 11, политика защиты конечных точек с параметрами, описанными в эта статья доставляет конфигурацию политики на устройство. Однако затем Windows уведомляет пользователя о необходимости вручную включить шифрование диска BitLocker. Для этого пользователь выбирает уведомление. Это действие запускает мастер шифрования диска BitLocker.

Выпуск Intune 1901 содержит параметры, которые можно использовать для настройки автоматического шифрования устройств для устройств Autopilot для обычных пользователей. Каждое устройство должно соответствовать следующим требованиям:
- Соответствие стандарту HSTI
- Поддержка современного режима ожидания
- Используйте Windows 10 версии 1803 или более поздней или Windows 11.
Ссылки OMA-URI для этих настроек следующие:
- OMA-URI: ./Device/Vendor/MSFT/BitLocker/AllowStandardUserEncryption
  Тип значения: целое число Значение: 1
Этот узел работает вместе с узлами RequireDeviceEncryption и AllowWarningForOtherDiskEncryption. По этой причине, если для параметра RequireDeviceEncryption задано значение 1, для параметра AllowStandardUserEncryption — значение 1, а для параметра AllowWarningForOtherDiskEncryption — значение 0, Intune может применять автоматическое шифрование BitLocker для устройств Autopilot со стандартными профилями пользователей.

Проверка правильности работы BitLocker

Во время обычных операций BitLocker Drive Encryption создает такие события, как Event ID 796 и Event ID 845.

Вы также можете определить, загружен ли пароль восстановления BitLocker в Azure AD, проверив сведения об устройстве в разделе "Устройства Azure AD".

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

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

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

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

Cradlepoint и Extreme Networks объединят маршрутизаторы 5G первой компании с сетевой структурой второй для создания беспроводной глобальной сети 5G.

Израильский стартап OneLayer запустился незаметно с начальным финансированием в размере 8,2 млн долларов США и программной платформой для защиты Интернета вещей.

Российско-украинская война, которая затрагивает все, от инфляции до доступности чипов, оставила половину корпоративных технических лидеров.

ИТ-руководители начали год с ветерком в спину, опираясь на инвестиции, сделанные во время пандемии, и вновь сосредоточившись на .

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

Компании, привлекающие украинских программистов, работают над переводом сотрудников, желающих переехать. Технологические компании в долгосрочной перспективе могут .

ИТ-администраторам, рассматривающим возможность перехода на Windows 11, следует узнать, как функции версии Enterprise могут помочь их .

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

Администраторам настольных компьютеров следует обратить внимание на собственные функции безопасности и архитектуру Windows 10, чтобы установить базовый уровень настольных компьютеров.

Чтобы добиться высокой доступности и отказоустойчивости в AWS, ИТ-администраторы должны сначала понять различия между двумя моделями.

Amazon ECS и EKS похожи, но их различий достаточно, чтобы выделить их для пользователей AWS. Узнайте, что лучше всего подходит для вашего .

Новые дополнения к системам хранения, такие как гибкие блочные тома и высокая доступность для ZFS, делают облачную платформу Oracle более конкурентоспособной.

Университет сотрудничает с Oracle в проведении исследований по наблюдению за цветущими фруктовыми деревьями весной

Оператор мобильной связи добился самого значительного прироста клиентов с потребительскими контрактами с 2012 года и увеличения EBITDA на 10 % с постепенным увеличением.

Внедрение систем EPR в организациях NHS поможет активизировать усилия по цифровой трансформации и является ключом к достижению результатов.

Безопасность практически любого интернет-соединения зависит от шифрования SSL/TLS. Что определяет уровень защиты для этих соединений, так это выбор набора шифров. Итак, что такое набор шифров?

Что такое набор шифров?

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

Зачем нужны комплекты шифров?
- Алгоритм обмена ключами, определяющий способ обмена симметричными ключами.
- Алгоритм аутентификации или цифровой подписи, который определяет, как будет реализована аутентификация сервера и аутентификация клиента (если требуется).
- Шифр массового шифрования, используемый для шифрования данных.
- Функция хеширования/MAC, которая определяет, как будут выполняться проверки целостности данных.
Эти шифры требуются в различных точках соединения для аутентификации, генерации и обмена ключами, а также контрольной суммы для обеспечения целостности. Чтобы определить, какие конкретные алгоритмы использовать, клиент и веб-сервер начинают с взаимного выбора набора шифров, который будет использоваться.

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

Как это работает?

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

Решение о том, какой набор шифров будет использоваться, зависит от веб-сервера. Согласованный набор шифров представляет собой комбинацию:
- Алгоритмы обмена ключами, такие как RSA, DH, ECDH, DHE, ECDHE или PSK.
- Алгоритм аутентификации/цифровой подписи, такой как RSA, ECDSA или DSA
- Алгоритмы массового шифрования, такие как AES, CHACHA20, Camellia или ARIA.
- Алгоритмы кода аутентификации сообщения, такие как SHA-256 и POLY1305
Возвращаясь к нашей парадигме набора шифров, давайте посмотрим, какую информацию предоставляет набор шифров.

Почему наборы шифров важны?

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

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

Поддерживаемые наборы шифров в TLS 1.2

Прежде чем обсуждать, сколько существует различных наборов шифров, давайте вспомним, что все протоколы TLS до TLS 1.2 (т. е. TLS 1.0 и TLS 1.1) устарели по различным причинам безопасности. В настоящее время единственными приемлемыми протоколами TLS являются TLS 1.2 и TLS 1.3.

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

Из всех наборов шифров, поддерживаемых в TLS 1.2, рекомендуется использовать те, которые используют эфемерный алгоритм Диффи-Хеллмана. Итак, рекомендуемые наборы шифров сводятся к следующему:
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
Выявление слабых шифров

С введением TLS 1.3 многое изменилось для повышения безопасности протокола. Начнем с того, что старые небезопасные шифры устарели, в том числе:
- RC4
- ДПО
- MD5
- ША-1
- Слабые эллиптические кривые
- Обмен ключами RSA
- Статический алгоритм Диффи-Хеллмана (DH, ECDH)
- Блочные шифры (CBC)
- Шифры, отличные от AEAD
Поддержка наборов шифров в TLS 1.3

Кроме того, наборы шифров TLS 1.3 теперь намного короче, чем соответствующие наборы шифров TLS 1.2. В комплектах шифров не указан тип сертификата — RSA или ECDSA — и механизм обмена ключами — DHE или ECDHE. Таким образом, количество переговоров, необходимых для определения параметров шифрования, было сокращено с четырех до двух. Наборы шифров в TLS 1.3 выглядят следующим образом:

Клиент инициирует рукопожатие, зная, что для процесса обмена ключами будет использоваться эфемерный алгоритм Диффи-Хеллмана, и может отправить свою часть общего ключа во время сообщения Client Hello. Преимущество этого заключается в том, что рукопожатие TLS 1.3 сокращается до одного кругового обхода, когда сервер отвечает всей необходимой информацией для двух сторон, чтобы получить ключ сеанса и начать безопасное общение.

Поддерживаемые наборы шифров в TLS 1.3 сократились до пяти и включают следующие:
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256
Выбор наборов шифров

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

Mozilla рекомендует три различных конфигурации наборов шифров для веб-серверов, использующих протокол TLS.
- Современная. Эта конфигурация предназначена для современных клиентов, поддерживающих TLS 1.3, без обратной совместимости. Конфигурация Modern обеспечивает чрезвычайно высокий уровень безопасности.
- Промежуточный: это рекомендуемая конфигурация для сервера общего назначения, которому не требуется совместимость с устаревшими клиентами, такими как Windows XP или старые версии OpenSSL. Он очень безопасен и совместим практически со всеми клиентами, выпущенными за последние пять (или более) лет.
- Старые: к службам обращались очень старые клиенты или библиотеки, такие как Internet Explorer 8 (Windows XP), Java 6 или OpenSSL 0.9.8, и их следует использовать в крайнем случае.
Заключение

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

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

Читайте также: