Общие сведения о шифровании данных в Azure NetApp Files

Статья
2025-05-03

Azure NetApp Files шифрует данные с помощью двух различных методов:

Шифрование неактивных данных: данные шифруются на месте с помощью стандартов FIPS 140-2.
Шифрование при передаче: данные шифруются через передачу или по проводной связи, так как они передаются между клиентом и сервером.

Общие сведения о шифровании неактивных данных

Данные, находящиеся в состоянии покоя в Azure NetApp Files, можно зашифровать двумя способами.

Одиночное шифрование использует программное шифрование для томов Azure NetApp Files.
Двойное шифрование добавляет шифрование на уровне физического устройства хранилища.

Azure NetApp Files использует стандартный CryptoMod для создания ключей шифрования AES-256. CryptoMod указан в списке проверенных модулей CMVP FIPS 140-2; Дополнительные сведения см. в разделе FIPS 140-2 Cert #4144. Ключи шифрования связаны с томами и могут быть ключами, управляемыми платформой Майкрософт, или ключами, управляемыми клиентом.

Общие сведения о шифровании данных в транзитном режиме

Помимо защиты неактивных данных, Azure NetApp Files может защитить данные при передаче между конечными точками. Используемый метод шифрования зависит от протокола или компонента. DNS не шифруется во время передачи в файлах Azure NetApp. Продолжайте читать сведения о шифровании SMB и NFS, LDAP и репликации данных в Azure NetApp Files.

Шифрование SMB

Клиенты Windows SMB, использующие версию протокола SMB3.x, изначально поддерживают шифрование SMB. Шифрование SMB выполняется комплексно и шифрует всю беседу SMB с помощью наборов шифрования AES-256-GCM/AES-128-GCM и AES-256-CCM/AES-128-CCM.

Шифрование SMB не требуется для томов Azure NetApp Files, но может использоваться для дополнительной безопасности. Шифрование SMB добавляет затраты на производительность. Дополнительные сведения о рекомендациях по производительности с шифрованием SMB см. в рекомендациях по производительности SMB для Azure NetApp Files.

Требование шифрования для подключений SMB

Azure NetApp Files предоставляет возможность принудительного шифрования для всех подключений SMB. Принудительное применение шифрования запрещает незашифрованное взаимодействие SMB и использует SMB3 и более поздние версии для соединений SMB. Шифрование выполняется с помощью шифрования AES и шифрует все пакеты SMB. Для правильной работы этой функции клиенты SMB должны поддерживать шифрование SMB. Если клиент SMB не поддерживает шифрование и SMB3, то подключения SMB запрещены. Если этот параметр включен, все общие папки с одинаковым IP-адресом требуют шифрования, таким образом переопределяя параметр свойства общего ресурса SMB для шифрования.

В качестве альтернативы шифрование можно задать на уровне индивидуальной доли тома Azure NetApp Files.

UNC-затвердение

В 2015 году Корпорация Майкрософт представила UNC-защита (MS15-011 и MS15-014) для устранения уязвимостей удаленного сетевого пути, которые могут разрешить удаленное выполнение кода в общих папках SMB. Дополнительные сведения см. в разделе MS15-011 и MS15-014: защита групповой политики.

Защита от UNC предоставляет три варианта защиты путей UNC:

RequireMutualAuthentication — проверка подлинности удостоверений требуется или не требуется для блокировки атак спуфингов.
RequireIntegrity — проверка целостности требуется или может не требоваться, чтобы предотвратить атаки на изменение.
RequirePrivacy — конфиденциальность (общее шифрование пакетов SMB) включена или отключена, чтобы предотвратить сниффинг трафика.

Azure NetApp Files поддерживает все три формы UNC-защиты.

NFS Kerberos

Azure NetApp Files также предоставляет возможность шифровать обмен данными протокола NFSv4.1 с использованием проверки подлинности Kerberos и наборов шифрования AES-256-GCM/AES-128-GCM и AES-256-CCM/AES-128-CCM.

С помощью NFS Kerberos Azure NetApp Files поддерживает три различных варианта безопасности:

Kerberos 5 (krb5) — только начальная проверка подлинности; требуется обмен билетами Kerberos или вход пользователя для доступа к экспорту NFS. Пакеты NFS не шифруются.
Kerberos 5i (krb5i) — начальная проверка подлинности и целостности; требуются обмен билетами Kerberos и вход пользователя для доступа к экспорту NFS, а также добавление проверок целостности к каждому пакету NFS, чтобы предотвратить атаки типа "человек в середине" (MITM).
Kerberos 5p (krb5p) — первоначальная проверка подлинности, затем проверка целостности и обеспечение конфиденциальности; требуется обмен билетами Kerberos или вход пользователя для доступа к экспорту NFS, выполняет проверки целостности и применяет оболочку GSS к каждому пакету NFS для шифрования его содержимого.

Каждый уровень шифрования Kerberos влияет на производительность. Поскольку типы шифрования и варианты безопасности включают более безопасные методы, воздействие на производительность увеличивается. ** Например, krb5 работает лучше, чем krb5i, krb5i работает лучше, чем krb5p, AES-128 работают лучше, чем AES-256 и так далее. Для получения дополнительной информации о влиянии Kerberos на производительность в NFS томах Azure NetApp Files, см. статью Влияние Kerberos на тома NFSv4.1 в Azure NetApp Files.

Замечание

NFS Kerberos поддерживается только с NFSv4.1 в Azure NetApp Files.

На следующем изображении используется Kerberos 5 (krb5); только исходный запрос проверки подлинности (вход в систему/получение билета) зашифрован. Весь остальной трафик NFS поступает в открытом тексте.

При использовании Kerberos 5i (krb5i; проверка целостности) трассировка показывает, что пакеты NFS не шифруются, но к пакету добавляется оболочка GSS/Kerberos, которая требует от клиента и сервера обеспечить целостность передаваемых данных с помощью контрольной суммы.

Kerberos 5p (конфиденциальность; krb5p) обеспечивает сквозное шифрование всего трафика NFS, как показано на изображении трассировки с помощью оболочки GSS/Kerberos. Этот метод создает большую нагрузку на производительность из-за необходимости обрабатывать шифрование каждого пакета NFS.

Репликация данных

В Azure NetApp Files можно реплицировать все тома в зонах или регионах в Azure, чтобы обеспечить защиту данных. Так как трафик репликации находится в облаке Azure, передача выполняется в защищенной сетевой инфраструктуре Azure, которая ограничена доступом для предотвращения перехвата пакетов и атак типа 'человек посередине' (прослушивание или олицетворение между конечными точками связи). Кроме того, трафик репликации шифруется с помощью стандартов TLS 1.2, совместимых с FIPS 1.2. Дополнительные сведения см. в часто задаваемых вопросых по безопасности.

Шифрование LDAP

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

Чтобы защитить обмен данными LDAP от перехвата и чтения, трафик LDAP может использовать шифрование на уровне передачи данных с использованием AES и TLS 1.2 посредством подписания LDAP и LDAP по протоколу TLS соответственно. Дополнительные сведения о настройке этих параметров см. в статье "Создание подключений Active Directory и управление ими".

Подписание LDAP

Аутентификация LDAP определяется подключениями к серверам Microsoft Active Directory, которые содержат идентификационные данные UNIX для пользователей и групп. Эта функция обеспечивает проверку целостности для простой проверки подлинности и уровня безопасности (SASL) LDAP привязывается к серверам AD, на котором размещаются подключения LDAP. Подписывание не требует настройки сертификатов безопасности, так как оно использует GSS-API связи со службами Центра распространения ключей Kerberos (KDC) Active Directory. Подпись LDAP проверяет только целостность пакета LDAP; Он не шифрует полезные данные пакета.

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

Windows Active Directory также позволяет использовать подписывание и печать LDAP (сквозное шифрование пакетов LDAP). Azure NetApp Files не поддерживает эту функцию.

Привязка канала LDAP

Из-за уязвимости безопасности, обнаруженной в контроллерах домена Windows Active Directory, параметр по умолчанию был изменен для серверов Windows. Дополнительные сведения см. в ADV190023 рекомендаций по безопасности Майкрософт.

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

Azure NetApp Files по умолчанию поддерживает привязку канала LDAP оппортунистически, что означает, что привязка канала LDAP используется при поддержке клиента. Если привязка канала не поддерживается или не отправляется, связь все равно разрешена, а привязка канала не будет применена.

LDAP по протоколу SSL (порт 636)

Трафик LDAP в Azure NetApp Files передается через порт 389 во всех случаях. Этот порт нельзя изменить. Протокол LDAP по протоколу SSL (LDAPS) не поддерживается и считается устаревшим большинством поставщиков серверов LDAP (RFC 1777 был опубликован в 1995 году). Если вы хотите использовать шифрование LDAP с Azure NetApp Files, используйте протокол LDAP по протоколу TLS.

LDAP через StartTLS

Ldap over StartTLS появился с RFC 2830 в 2000 году и был объединен в стандарт LDAPv3 с RFC 4511 в 2006 году. После того как StartTLS стал стандартом, поставщики LDAP начали ссылаться на LDAPS как устаревшие.

Ldap over StartTLS использует порт 389 для подключения LDAP. После завершения первоначального подключения LDAP выполняется обмен данными OID StartTLS и сравнение сертификатов; затем весь трафик LDAP шифруется с помощью TLS. Запись пакетов, показанная ниже, показывает привязку LDAP, подтверждение StartTLS и последующий трафик LDAP, зашифрованный TLS.

Существует два основных различия между LDAPS и StartTLS:

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

Вопросы безопасности протокола LDAP при использовании StartTLS

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

Убедитесь, что StartTLS включен и настроены сертификаты.
Для внутренних сред можно использовать самозаверяемые сертификаты, но для внешнего LDAP используйте центр сертификации. Дополнительные сведения о сертификатах см. статью "Разница между самозаверенным SSL и Удостоверяющим центром".
Запретить запросы LDAP и привязки, которые не используют StartTLS. По умолчанию Active Directory отключает анонимные привязки.

Безопасное подключение к Active Directory

Подключения Active Directory с томами Azure NetApp Files можно настроить, чтобы сначала попробовать самый надежный доступный тип шифрования Kerberos: AES-256. Если шифрование AES включено, обмен данными контроллера домена (например, запланированные сбросы паролей сервера SMB) использует самый высокий доступный тип шифрования, поддерживаемый на контроллерах домена. Azure NetApp Files поддерживает следующие типы шифрования для обмена данными контроллера домена в порядке попытки проверки подлинности: AES-256, AES-128, RC4-HMAC, DES