Общие сведения о шифровании данных в Azure NetApp Files
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. Продолжайте читать сведения о шифровании S МБ и NFS, ldap и реплика tion данных в Azure NetApp Files.
Шифрование SMB
Клиенты Windows S МБ с использованием версии протокола S МБ 3.x изначально поддерживают шифрование S МБ. Шифрование S МБ выполняется сквозно и шифрует всю беседу S МБ с помощью наборов шифрования AES-256-GCM/AES-128-GCM и AES-256-CCM/AES-128-CCM.
Шифрование S МБ не требуется для томов Azure NetApp Files, но может использоваться для дополнительной безопасности. Шифрование S МБ добавляет затраты на производительность. Дополнительные сведения о производительности с помощью шифрования S МБ см. в статье S МБ рекомендации по производительности Azure NetApp Files.
Требование шифрования для подключений S МБ
Azure NetApp Files предоставляет возможность принудительного шифрования для всех подключений S МБ. Применение шифрования запрещает незашифрованные подключения S МБ и использует S МБ 3 и более поздних версий для подключений S МБ. Шифрование выполняется с помощью шифрования AES и шифрует все пакеты S МБ. Для правильной работы этой функции клиенты S МБ должны поддерживать шифрование S МБ. Если клиент S МБ не поддерживает шифрование и S МБ 3, то подключения S МБ запрещены. Если этот параметр включен, все общие папки с одинаковым IP-адресом требуют шифрования, таким образом переопределяя параметр свойства общего ресурса S МБ для шифрования.
S МБ шифрование на уровне общего ресурса
Кроме того, шифрование можно задать на уровне отдельной общей папки тома Azure NetApp Files.
UNC-затвердение
В 2015 году Корпорация Майкрософт представила UNC-защита (MS15-011 и MS15-014) для устранения уязвимостей удаленного сетевого пути, которые могут разрешить удаленное выполнение кода в общих папках S МБ. Дополнительные сведения см. в разделе MS15-011 и MS15-014: защита групповой политики.
Защита от UNC предоставляет три варианта защиты путей UNC:
RequireMutualAuthentication— проверка подлинности удостоверений требуется или не требуется для блокировки атак спуфингов.RequireIntegrity— целостность проверка обязательной или не обязательной для блокировки атак на изменение.RequirePrivacy— конфиденциальность (общее шифрование пакетов S МБ) включена или отключена, чтобы предотвратить трафик.
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) — начальная проверка подлинности, целостность проверка и конфиденциальность; для доступа к экспорту NFS требуется обмен билетами Kerberos или пользователь для доступа к экспорту NFS, выполняет проверка целостности и применяет оболочку GSS к каждому пакету NFS для шифрования его содержимого.
Каждый уровень шифрования Kerberos влияет на производительность. Поскольку типы шифрования и вкусы безопасности включают более безопасные методы, производительность увеличивается. Например, работает лучше, krb5 чем krb5i, krb5i работает лучше, чем, AES-128 выполняют лучше, чем krb5pAES-256 и т. д. Дополнительные сведения о влиянии на производительность NFS Kerberos в Azure NetApp Files см. в статье о влиянии Kerberos на томах Azure NetApp Files NFSv4.1.
Примечание.
NFS Kerberos поддерживается только с NFSv4.1 в Azure NetApp Files.
На следующем изображении используется Kerberos 5 (krb5) — только исходный запрос проверки подлинности (получение входа или приобретения билета). Весь остальной трафик NFS поступает в обычный текст.
При использовании Kerberos 5i (krb5iцелостность проверка ing) трассировка показывает, что пакеты NFS не шифруются, но есть оболочка GSS/Kerberos, которая требует от клиента и сервера обеспечить целостность данных, передаваемых с помощью проверка sum.
Kerberos 5p (конфиденциальность; krb5p) обеспечивает сквозное шифрование всего трафика NFS, как показано на изображении трассировки с помощью оболочки GSS/Kerberos. Этот метод создает большую нагрузку на производительность из-за необходимости обрабатывать шифрование каждого пакета NFS.
Репликация данных
В Azure NetApp Files можно реплика целые тома между зонами или регионами в Azure, чтобы обеспечить защиту данных. Так как трафик реплика связи находится в облаке Azure, передача выполняется в защищенной сетевой инфраструктуре Azure, которая ограничена доступом для предотвращения перехвата пакетов и атак с помощью злоумышленника (перехвата или олицетворения между конечными точками связи). Кроме того, трафик реплика tion шифруется с помощью стандартов FIPS 140-2, совместимых с TLS 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 включено, обмен данными контроллера домена (например, запланированные сбросы паролей S МБ сервера) используйте самый высокий доступный тип шифрования, поддерживаемый на контроллерах домена. Azure NetApp Files поддерживает следующие типы шифрования для обмена данными контроллера домена в порядке попытки проверки подлинности: AES-256, AES-128, RC4-HMAC, DES
Примечание.
Невозможно отключить более слабые типы проверки подлинности в Azure NetApp Files (например, RC4-HMAC и DES). Вместо этого, если требуется, они должны быть отключены от контроллера домена, чтобы запросы проверки подлинности не пытались использовать их. Если rc4-HMAC отключен на контроллерах домена, шифрование AES должно быть включено в Azure NetApp Files для надлежащей функциональности.