Dell EMC Data Domain Encryption — часто задаваемые вопросы

Конфигурация шифрования

Вопрос. Как настроить шифрование (DARE) в DD?
Ответ: Шифрование DARE можно настроить в DD, выполнив следующие действия:

1. Добавить лицензию на шифрование

2. Добавление сотрудника службы безопасности и включение авторизации сотрудника службы безопасности

3. Включить шифрование 

1) Добавить лицензию на шифрование:
добавьте файл лицензии с действительной лицензией на шифрование.
Используйте следующую команду, чтобы обновить электронную лицензию в DD с помощью доступного файла лицензии.

Обновление электронной лицензии

2) Добавьте сотрудника службы безопасности и включите авторизацию SO:
a) Добавьте пользователя с ролью «security» с помощью команды: 

Пользователь добавляет роль secuser

б) Включите авторизацию сотрудника службы безопасности в программе настройки с помощью команды: 

Набор политик авторизации — сотрудник службы безопасности включен

3. Включите шифрование DARE:
Включите DARE Encryption с помощью команды:

Включение шифрования FilesYS

Вопрос. Какие платформы поддерживаются функцией шифрования данных в состоянии покоя?
Ответ: Функция шифрования данных в состоянии покоя поддерживается во всех системах Data Domain, за исключением систем Encryption Disablement Project (EDP).

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

Отключение шифрования FilesYS

Вопрос. Какие приложения/протоколы резервного копирования поддерживаются функцией шифрования данных в состоянии покоя?
Ответ: Функция DD DARE не зависит ни от базового приложения резервного копирования, ни от протокола, используемого DD.

Вопрос: Какие алгоритмы шифрования можно выбрать в системе Data Domain?
Ответ: Программное обеспечение DD Encryption поддерживает 128- или 256-разрядный алгоритм AES с использованием технологии Cipher Block Chaining (CBC) или режима счетчика Галуа (GCM). 

GCM — это режим работы для криптографических блочных шифров с симметричным ключом. Это алгоритм шифрования с аутентификацией, предназначенный для обеспечения как аутентификации, так и конфиденциальности (конфиденциальности). Как следует из названия, GCM сочетает в себе хорошо известный режим шифрования счетчиков с новым режимом аутентификации Галуа. Аспект аутентификации в GCM гарантирует, что данные, которые были зашифрованы, были зашифрованы системой Data Domain, а не были «внедрены» каким-либо другим способом. Это отличается от CBC, где данные шифруются (аспект конфиденциальности), но не проверяются на подлинность зашифрованных данных.

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

Вопрос: Как изменить алгоритм шифрования в DD?

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

Набор алгоритмов шифрования FilesYS

Пример.

# Набор алгоритмов шифрования Filesys {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Вопрос. Как обеспечить шифрование уже существующих данных после включения шифрования?
Ответ: Можно принудительно выполнить шифрование уже существующих данных в DDFS с помощью следующей команды:

# Filesys Encryption применяется — изменения

Это делает следующий цикл очистки значительно длиннее и более ресурсоемким, чем обычно.

Вопрос: Как отключить шифрование в DD?
Ответ: Отключите функцию шифрования в DD с помощью команды encryption disable: 

Отключение шифрования FilesYS

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

Вопрос: Какие команды шифрования требуют перезапуска файловой системы DD, чтобы они вступили в силу?
Ответ: Чтобы следующие команды шифрования вступили в силу, требуется перезапуск файловой системы DD:

Включение/отключение шифрования файловых систем - Включает или отключает шифрование в системе Data Domain.

Набор алгоритмов шифрования FilesYS — Позволяет пользователю выбрать криптографический алгоритм.

Сброс алгоритма шифрования FilesYS — Выполняет сброс алгоритма шифрования до AES 256 в режиме CBC (по умолчанию).

Вопрос: Какие команды шифрования необходимо отключить для настройки/использования файловой системы Data Domain?
Ответ: Для установки или использования следующих команд шифрования необходимо отключить файловую систему Data Domain:

Изменение парольной фразы шифрования

Блокировка/разблокировка шифрования

Общие вопросы по шифрованию

Вопрос. Поддерживается ли шифрование DD во всех системах DD?
Ответ: Программный вариант DD Encryption поддерживается в системах DD, если они не являются проектами по отключению шифрования (EDP), т. е. системами, которые не позволяют включить шифрование, в основном продаются в регионах России.

Вопрос: Как выполняется криптография в системах DD?
Ответ: Криптография выполняется с использованием библиотек OpenSSL и RSA BSafe (RSA BSafe — криптографическая библиотека, проверенная на соответствие стандарту FIPS 140-2, используемая системами DD для шифрования данных в состоянии покоя) в DDOS. 

Вопрос. Какая версия BSafe используется в системе?
Ответ: Начиная с DDOS 7.10, используемыми версиями BSafe являются «BSAFE Micro Edition Suite 4.4.0.0» и «BSAFE Crypto-C Micro Edition: 4.1.4.0"

Вопрос: Какие пользовательские интерфейсы доступны для настройки шифрования в DDOS?
Ответ: Шифрование можно настроить с помощью интерфейса командной строки, пользовательского интерфейса или REST API. Поддержка API-интерфейса REST, добавленного в DDOS версии 8.0 и более поздних.

Вопрос: Возможно ли выборочное шифрование данных? Нравится только одно MTree или файл?
Ответ: Выборочное шифрование НЕВОЗМОЖНО. Шифрование можно включать или отключать только в масштабе всей системы, но не выборочно. Для систем с поддержкой облака шифрование можно включать или отключать с детализацией на уровне облака и облачного устройства.  

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

Вопрос: Какая версия OpenSSL используется в системе?
Ответ: В выпуске DDOS 7.10 версия OpenSSL — «OpenSSL 1.0.2zd-fips»

Вопрос: Как шифрование неактивных данных защищает от доступа пользователей и приложений к данным?
Ответ: 

• Шифрование неиспользуемых данных шифрует данные, которые находятся в подсистеме диска. Шифрование или дешифрование выполняется на уровне сжатия. Пользователи или приложения отправляют и получают данные в виде открытого текста в систему Data Domain, но все данные, физически находящиеся в системе Data Domain, зашифрованы.
• Все операции шифрования выполняются за пределами файловой системы и пространства имен и остаются невидимыми для пользователей или приложений. Если пользователь или приложение уже имеет авторизованный доступ к файлу или каталогу, данные могут быть прочитаны в исходном формате независимо от шифрования.
• DD Encryption разработан таким образом, что если злоумышленник обойдет другие элементы управления сетевой безопасностью и получит доступ к зашифрованным данным без надлежащих криптографических ключей, данные будут нечитаемы и недоступны для использования этим человеком. 

Вопрос. Будет ли выполнено шифрование после дедупликации?
Ответ: Да, шифрование выполняется для дедуплицированных данных. Данные шифруются перед сохранением на диске. 

Вопрос. Как Data Domain обеспечивает безопасность данных?
Ответ: Безопасность данных обеспечивается с помощью шифрования неиспользуемых данных. Кроме того, при удалении устройства (замена головы, блокировка файловой системы) фраза-пароль удаляется из системы. Эта парольная фраза используется для шифрования ключей шифрования, поэтому данные дополнительно защищены.

Вопрос: Какие оповещения создаются с шифрованием?
Ответ: Оповещения создаются в следующих случаях:

• При наличии скомпрометированных ключей шифрования
• Если таблица ключей шифрования заполнена и в системе больше нельзя добавить ключи
• При сбое автоматического экспорта ключей
• При сбое автоматической смены ключей
• Если шифрование отключено
• При изменении фразы-пароля в системе

Вопрос. Существует ли сертификат безопасности для DDOS? 
Ответ. Системы Data Domain соответствуют стандарту FIPS 140-2. 

Вопрос. Где хранится ключ шифрования?
Ответ: Ключи шифрования хранятся постоянно в разделе коллекции в системе DDOS.

Вопрос: Если кто-то извлечет жесткий диск из системы Data Domain, сможете ли вы расшифровать данные с него?
Ответ: Ключи шифрования шифруются с помощью системной парольной фразы, которая хранится в системном заголовке. Несмотря на то, что ключи шифрования хранятся на диске, без системной парольной фразы ключи шифрования не могут быть расшифрованы. Таким образом, без знания ключа, который используется для шифрования данных, расшифровка с жесткого диска невозможна.  

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

Вопрос: Блокировка файловой системы перед ее перемещением в удаленное расположение.
Ответ: Ниже приведена процедура для этого: 

• Отключите файловую систему:

  Отключение файлов sysadmin@itrdc-DD630-42#

• Заблокируйте файловую систему и введите новую парольную фразу (для этого требуется аутентификация указанного выше пользователя системы безопасности):

  Блокировка
  шифрования sysadmin@itrdc-DD630-42# Filesys Для выполнения этой команды требуется авторизация пользователя с ролью «security».
  Укажите учетные данные для такого пользователя ниже.
          Имя пользователя: secuser
  Пароль:
  Введите текущую парольную фразу:
  Введите новую парольную фразу:
  Повторно введите новую парольную фразу:
  Фразы-пароли совпадают.
  Теперь файловая система заблокирована.

• Новую парольную фразу НЕЛЬЗЯ потерять или забыть. Без этой парольной фразы файловую систему невозможно разблокировать, а это значит, что доступ к данным на DDR невозможен. Чтобы разблокировать систему при достижении удаленного расположения, используйте следующую команду:

Разблокировка шифрования sysadmin@itrdc-DD630-42# Filesys
Для выполнения этой команды требуется авторизация пользователем с ролью «security».
Укажите учетные данные для такого пользователя ниже.
        Имя пользователя: secuser
Пароль:
Введите парольную фразу:Фраза-пароль
проверена. Используйте команду «filesys enable» для запуска файловой системы.

• Теперь файловую систему можно включить и использовать в обычном режиме

Вопрос. Имеет ли команда очистки хранилища какое-либо отношение к шифрованию файловой системы?
Ответ: Нет, шифрование файловой системы и уничтожение данных хранилища — это две независимые функции. 

Вопрос. Поддерживается ли шифрование по сети в системе EDP (encryption disablement project)?
Ответ: В системе EDP невозможно включить шифрование данных в состоянии покоя (DARE) или шифрование по сети (с репликацией или ddboost).

Фраза-пароль системы 

Вопрос. Что такое системная парольная фраза?
Ответ: В DDOS предусмотрена возможность защиты учетных данных в системе путем задания парольной фразы на уровне системы. Фраза-пароль — это легко читаемый (понятный) ключ, например смарт-карта, которая используется для создания машинного ключа шифрования AES 256. 

Это дает два преимущества:

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

Фраза-пароль хранится внутри компании в скрытой части системы хранения Data Domain. Это позволяет системе Data Domain загрузиться и продолжить обслуживание доступа к данным без вмешательства администратора.

Создание или изменение фразы-пароля:

• Системную фразу-пароль можно создать с помощью интерфейса командной строки после того, как администратор выполнит аутентификацию в системе Data Domain.
• Системную парольную фразу можно изменить с помощью интерфейса командной строки после того, как администратор и пользователь с ролью безопасности (например, сотрудник службы безопасности) пройдут аутентификацию в системе Data Domain (таким образом, ни один администратор не сможет вносить изменения независимо друг от друга).

Вопрос. Когда используется парольная фраза?
Ответ: Системная парольная фраза используется в качестве первичного ключа различными компонентами DDOS, в том числе шифрованием файловой системы, доступом к облаку, управлением сертификатами, токенами Boost, модулями конфигурации системы в горизонтально масштабируемых средах и информацией о лицензировании. Программное обеспечение DDOS предоставляет механизмы для установки и изменения этой системной парольной фразы. Кроме того, здесь можно управлять хранением системной парольной фразы на диске, что особенно удобно для повышения безопасности при транспортировке системы DD. 

Вопрос. Как парольная фраза используется для безопасной транспортировки системы DD?
Ответ: В процессе используется команда «filesys encryption lock», которая позволяет пользователю заблокировать файловую систему, изменив парольную фразу. Пользователь вводит новую парольную фразу, которая повторно шифрует ключ шифрования, но новая парольная фраза не сохраняется. Ключи шифрования невозможно восстановить, пока файловая система не будет разблокирована с помощью команды «filesys encryption unlock».

Этот процесс описан в Руководстве по настройке безопасности Confluence Lab.

Вопрос: Что произойдет, если фраза-пароль изменится? Возможен ли доступ к данным?
Ответ: Да, изменение парольной фразы не приводит к изменению базового ключа шифрования системы Data Domain, а только к шифрованию ключа шифрования. Таким образом, доступ к данным не затрагивается.

Вопрос: Как узнать, установлена ли в системе фраза-пароль?
Ответ: Если в системе установлена фраза-пароль, команда «system passphrase set» выдает ошибку, указывающую на то, что фраза-пароль уже установлена.

Вопрос: Что произойдет, если парольная фраза будет утеряна или забыта?
Ответ: Если клиент потеряет парольную фразу, пока ящик заблокирован, он потеряет свои данные. Нет черного хода или альтернативного способа получить к нему доступ. Без надлежащего процесса управления парольной фразой это может произойти случайно, и злоумышленник не сможет восстановить ключ или данные. Тем не менее, зашифрованный ключ никогда не может быть утерян или поврежден благодаря встроенным механизмам защиты системы.

Вопрос: Существует ли механизм сброса забытой системной парольной фразы?
Ответ: Парольную фразу системы можно принудительно сбросить только в определенных ситуациях при помощи службы поддержки клиентов. Механизм принудительного обновления, представленный в DDOS 7.2, может быть использован для этого только при соблюдении определенных условий. Дополнительные сведения см. в статье базы знаний 20983, Data Domain: Как сбросить утерянную системную парольную фразу в DDOS 7.2 или более поздней версии (для просмотра статьи требуется вход в службу поддержки Dell)

Question. Можно ли избежать сохранения системной парольной фразы в системе DD?
Ответ: Системная парольная фраза по умолчанию хранится в скрытом месте в системе Data Domain. Системный параметр «system passphrase option store-on-disk» можно использовать для изменения этого параметра и избежать сохранения парольной фразы на диске.

Встроенный диспетчер ключей (EKM)

Команда верхнего уровня:

Параметр встроенного управления ключами <шифрования System# Filesys>

Вопрос. Поддерживается ли ротация ключей с помощью встроенного диспетчера ключей?
Ответ:  Да, с помощью встроенного диспетчера ключей поддерживается ротация ключей для каждой системы Data Domain. С помощью пользовательского интерфейса или интерфейса командной строки администратор может настроить период ротации ключей (еженедельно или ежемесячно).

Вопрос: Взимается ли плата за встроенные функции управления ключами?
Ответ: Плата за эту функцию не взимается. Данная функция входит в стандартную лицензию на программное обеспечение DD Encryption.

Вопрос: Может ли заказчик перейти от локального управления ключами к внешнему управлению ключами (EKM)?
Ответ

• Да, внешних диспетчеров ключей можно включить в любое время. Однако используемые локальные ключи остаются в системе Data Domain. Внешние диспетчеры ключей не могут управлять ключами EKM. Существующие данные не требуют повторного шифрования. Если для заказчика данные комплаенса необходимо повторно шифровать с помощью ключей EKM, то это необходимо сделать вручную с помощью apply-changes с новым ключом чтения для чтения. Уничтожение ключей EKM после переключения не является обязательным.
  • key-manager автоматически переключает активный ключ на ключ из KMIP. 
  • Пример того, как выглядит MUID-идентификатор ключа KMIP при переключении

    Key-ID     Key MUID                                                                    State                     Key Manger Type
    1               be1                                                                    Deactivated               DataDomain
    
    2               49664EE855DF71CB7DC08309414C2B4C76ECB112C8D10368C37966E4E2E38A68       Activated-RW              KeySecure

Вопрос. Что происходит, если функция ротации клавиш отключена или включена?
Ответ: 

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

Внешние диспетчеры ключей

Вопрос. Какие внешние диспетчеры ключей поддерживаются в DD?
Ответ: Мы предоставляем поддержку указанным ниже внешним диспетчерам ключей:

• Gemalto KeySecure (поддержка добавлена в выпуске DDOS 7.2)
• Vormetric (поддержка добавлена в выпуске DDOS 7.3)
• CipherTrust (поддержка добавлена в выпуске DDOS 7.7)
• IBM GKLM (поддержка добавлена в выпуске DDOS 7.9)

Вопрос. Нужна ли отдельная лицензия для интеграции с внешним менеджером ключей?
Ответ: Да, для интеграции External Key Manager с DD требуется отдельная лицензия от соответствующего поставщика.

Вопрос: Сколько ключевых менеджеров поддерживают одновременно?
Ответ: В любой момент времени в системе DD может быть активен только один диспетчер ключей.

Вопрос: Где можно найти дополнительную информацию о настройке внешнего диспетчера ключей KMIP?
Ответ: Руководство по интеграции KMIP для DDOS содержит подробную информацию о настройке различных внешних диспетчеров ключей, поддерживаемых DD.

Вопрос: Как осуществляется управление сертификатами для внешних диспетчеров ключей в DD?
Ответ: При настройке внешнего диспетчера ключей необходимо сгенерировать сертификат CA (сертификат CA может быть самозаверяющим сертификатом или подписанным третьей стороной) и сертификат хоста. После выполнения настройки на внешнем сервере диспетчера ключей пользователям необходимо импортировать сертификат CA и сертификат хоста в систему DD. Затем настраиваем и включаем внешний менеджер ключей. 

Вопрос. Что такое CA?
Ответ: Источник сертификатов (CA) выступает в качестве изначально доверенного общего объекта для одноранговых узлов и выдает подписанные сертификаты, чтобы каждая сторона могла доверять другой. Сертификат обычно выступает в качестве удостоверения сервера или клиента. 

Вопрос. Что такое сертификат, подписанный локальным источником сертификатов, что такое сертификат, подписанный центром сертификации?
Ответ: Сертификат, подписанный CA, — это сертификат, который был выпущен и подписан общедоступным доверенным центром сертификации (CA). Сертификат, подписанный источником сертификатов, автоматически считается доверенным. Локальный CA может выдавать подписанные сертификаты, так как закрытый ключ подписи хранится в системе диспетчера ключей. Внешний источник сертификатов не хранит закрытый ключ. Вместо этого внешний CA используется в качестве доверенного объекта для различных интерфейсов и служб внутри системы.

Вопрос: Как создать запрос на подпись сертификата в DD?
Ответ: В системе Data Domain создайте CSR с помощью приведенной ниже команды CLI. Таким образом, закрытый ключ никогда не будет передан внешнему диспетчеру ключей.

Запрос на подписание сертификата adminAccess

Вопрос. Можно ли переключаться между ключевыми менеджерами?
Ответ: Беспроблемное переключение между внешним диспетчером ключей и встроенным диспетчером ключей разрешено. Однако для перехода со встроенного диспетчера ключей на внешние диспетчеры ключей требуется установка и настройка соответствующих сертификатов. Переключение между двумя внешними диспетчерами ключей (например: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust to GKLM). Также поддерживается перенос ключей диспетчера ключей (подробнее см. в руководстве по интеграции KMIP).

Вопрос: Что происходит при отключении подключения к внешнему диспетчеру ключей? Доступны ли мои данные?
Ответ: Да, данные по-прежнему доступны, когда мы не можем подключиться к менеджеру ключей, поскольку мы также храним копии ключей в системе DD. Невозможно создать новые ключи или синхронизировать состояния ключей при отсутствии подключения к внешнему диспетчеру ключей.

Вопрос: Можно ли как-то избежать хранения ключей в DD и хранить их только во внешнем диспетчере ключей?
Ответ: Мы всегда храним копии ключей в системе DD для целей DIA. Эту настройку нельзя изменить.

Вопрос: Влияет ли интеграция с KMIP на производительность?
Ответ: Нет, использование внешних диспетчеров ключей не влияет на производительность.

Вопрос: Можно ли использовать решение KMIP для выбранных доменов Data Domain в среде?
Ответ: Да, заказчики могут выбирать подходящую методологию шифрования для своих систем Data Domain. Они могут продолжать использовать встроенный диспетчер ключей Data Domain в некоторых системах Data Domain и ротацию ключей шифрования с помощью KMIP в других системах Data Domain в своей среде.

Вопрос: Безопасна ли связь между Data Domain и KMIP?
Ответ: Да, Data Domain обменивается данными с TLS в рамках сеансов взаимной аутентификации с сертификатом X509. Пользователь может использовать интерфейс командной строки Data Domain для импорта соответствующего сертификата X509 в систему Data Domain. Затем этот сертификат используется для установления защищенного канала между DD и KMIP.

Управление жизненным циклом ключей 

Вопрос. Какие возможности управления ключами доступны в DD Encryption?
Ответ: Диспетчер ключей управляет созданием, распространением и жизненным циклом нескольких ключей шифрования. В системе защиты может использоваться встроенный диспетчер ключей или внешний менеджер ключей, вызывающий жалобы KMIP. Одновременно может быть задействован только один диспетчер ключей. Если в системе защиты включено шифрование, встроенный диспетчер ключей действует по умолчанию. Если настроен внешний диспетчер ключей, он заменяет встроенный диспетчер ключей и действует до тех пор, пока не будет отключен вручную. Переключение со встроенного диспетчера ключей на внешний диспетчер ключей или наоборот приводит к добавлению нового ключа и не требует перезапуска файловой системы начиная с версии 7.1.

Вопрос: Каковы различные ключевые состояния в системе Data Domain?
Ниже перечислены различные состояния ключа в системе Data Domain.

• Activated-RW: В любом состоянии DD есть только один ключ, который используется для чтения и записи данных. Этот ключ также используется процессом GC для повторного шифрования контейнеров.
• Ожидание-активация: В любой системе DD есть только один ключ в этом состоянии. Таким образом определен ключ, который станет Activated-RW после следующего перезапуска файловой системы. В настоящее время это состояние существует только в момент включения шифрования. Другой ключ, ожидающий активации, не создается.  
• Activated-RO: Внешние диспетчеры ключей могут иметь несколько активированных ключей. Самый последний ключ находится в Activated-RW, остальные находятся в этом состоянии. Ключи могут перейти в это состояние в системе DD, когда не удается синхронизировать состояние с диспетчером ключей.
• Отключить: Используется для чтения существующих данных в системе DD.
• Скомпрометированы: Если заказчик скомпрометирует внешний ключ диспетчера ключей, его состояние изменится после следующей синхронизации ключа.  
• Помечено для уничтожения: Когда пользователь помечает ключ для уничтожения, ключ переходит в состояние «Помечено для уничтожения». При запуске GC все контейнеры, зашифрованные с помощью ключей Marked-For-Destroyed, повторно шифруются с помощью ключа Activated-RW.
• Разрушенный: Ключ в состоянии «Помечено для уничтожения» переходит в это состояние, когда с ним не связаны никакие данные.
• Уничтожено-скомпрометировано: Ключ в состоянии «Скомпрометировано» переходит в это состояние, когда с ним не связаны никакие данные.

Вопрос. Можно ли экспортировать ключи шифрования для аварийного восстановления?
Ответ: Ключи можно экспортировать вручную с помощью следующей команды.

«Экспорт ключей шифрования FilesYs»

Система DD также экспортирует ключи по умолчанию при добавлении нового ключа или при удалении любого ключа из системы.

Экспортированные файлы находятся в /ddr/var/.security в зашифрованном формате. Затем этот файл следует скопировать из DDR и сохранить в безопасном месте, которое впоследствии можно будет использовать при любом состоянии аварийного восстановления.

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

Ключи шифрования FilesYS Импорт <имени файла> 

Вопрос. Хранится ли ключ, сгенерированный KMIP, в системе Data Domain?
Ответ: Да, ключ шифрования, полученный с помощью KMIP, хранится в системе Data Domain в зашифрованном виде.

Вопрос: Как изменение состояния ключа в устройстве KMIP применяется к системе Data Domain?
Ответ: Синхронизация клавиш выполняется ежедневно. Если доступен новый ключ или состояние ключа изменяется, синхронизация обновляет локальную таблицу ключей. DD получает ключевые обновления от KMIP каждый день в полночь.

Вопрос: Можно ли вручную синхронизировать состояния ключей между DD и KMIP?
Ответ: Да, интерфейс командной строки или пользовательский интерфейс Data Domain можно использовать для ручной синхронизации состояний ключей между DD и KMIP. Для этого используется команда «filesys encryption keys sync».

Вопрос: Можно ли изменить время, в которое DD получает обновления ключей от KMIP?
Ответ: Нет, невозможно изменить время, в которое DD получает обновления ключей от KMIP.

Вопрос: Существует ли ограничение на количество ключей, поддерживаемых системой Data Domain?
Ответ: Начиная с DDOS 7.8, в системе Data Domain одновременно может быть не более 1024 ключей. Активированный доступный для чтения только один ключ, остальные ключи могут находиться в любом другом состоянии.

Вопрос: Можно ли использовать разные ключи для разных наборов данных в системах Data Domain? Можно ли это настроить?
Ответ: Нет, в системе одновременно поддерживается только один активный ключ, а все входящие данные шифруются с помощью текущего активного ключа. Клавишами нельзя управлять с более высокой степенью детализации, как M-деревьями.

Вопрос: Есть ли уведомление о достижении максимально допустимого количества ключей?
Ответ: Да, оповещение создается при достижении максимального предела количества ключей — 1024.

Вопрос: Как удалить оповещение о максимальном количестве ключей?
Ответ: Чтобы снять оповещение о максимально допустимом количестве ключей, необходимо удалить один из ключей.

Вопрос. Можно ли просмотреть объем данных, связанных с определенным ключом в системе Data Domain?
Ответ: Да, это отображается в DD, но не может быть видно на сервере KMIP. Пользователь может использовать интерфейс командной строки Data Domain и пользовательский интерфейс для просмотра объема данных, связанных с определенным ключом.

Вопрос:  Можно ли увидеть возраст ключей в системе DD?
Ответ: Да, это можно увидеть с помощью ключей EKM с помощью пользовательского интерфейса.

Вопрос: Работает ли старый ключ, даже если по истечении периода времени новый ключ вступил в силу?
Ответ: Срок действия ключей шифрования не ограничен. Старые ключи становятся доступными только для чтения после ротации ключей и остаются в DDOS.

Вопрос: Удаляется ли ключ шифрования автоматически, если в системе Data Domain нет связанных с ним данных?
Ответ: Нет, ключ не удаляется автоматически. Пользователь должен явным образом удалить ключ с помощью интерфейса командной строки DD или интерфейса пользователя.

Вопрос: Можно ли удалить ключ, даже если с ним связаны данные в системе Data Domain?
Ответ: Нет, если с ключом связаны какие-либо данные, его нельзя удалить. Для удаления ключа, связанного с данными, требуется повторное шифрование данных с использованием какого-либо другого ключа.

Вопрос: Если ключ удален в протоколе KMIP, удаляется ли он также из списка ключей Data Domain?
Ответ: Нет, пользователь должен самостоятельно удалить ключ с помощью интерфейса командной строки или интерфейса пользователя DD.

Вопрос: В среде Data Domain с несколькими площадками требуется ли KMIP в каждом расположении?
Ответ: Нет, нет необходимости иметь KMIP на каждой площадке, где есть Data Domain. Можно указать на один сервер KMIP. Рекомендуется иметь отдельный класс ключей для каждой системы DD, если они используют один и тот же сервер KMIP.

Вопрос: Если ключ скомпрометирован, есть ли у нас процесс получения данных, зашифрованных с помощью старого ключа?
Ответ: В этом случае заказчик должен пометить ключ как скомпрометированный на сервере KMIP. Затем выполните «filesys encryption keys sync» в системе DDOS, затем запустите «filesys encryption apply-changes», а затем запустите GC (filesys clean). Запуск GC повторно шифрует все данные, которые были зашифрованы с помощью скомпрометированного ключа, с использованием более нового ключа. После завершения сборки мусора состояние ключа меняется на «скомпрометировано-уничтожено». Позже этот ключ можно удалить. 

Шифрование и репликация

Вопрос. Поддерживается ли DD Replication и совместима ли она с программным вариантом DD Encryption?
Ответ: Да, DD Replication можно использовать с DD Encryption, что обеспечивает репликацию зашифрованных данных с использованием всех видов репликации. Каждая форма репликации работает уникально с шифрованием и обеспечивает одинаковый уровень безопасности.

Вопрос: Для использования шифрования в исходной и целевой системах должна использоваться одна и та же версия DD OS?
Ответ: Исходная и целевая системы могут иметь разную версию DDOS, чтобы использовать DARE с репликацией при наличии таблицы совместимости репликации (см. таблицу совместимости в руководстве администратора). 

Вопрос. Как репликация работает с шифрованием?
Ответ: Это зависит от используемой формы репликации.

Если настроена репликация MREPL или MFR:
Если используются MREPL или MFR, DD Encryption можно лицензировать или включать в исходной или целевой системах независимо друг от друга в зависимости от потребностей заказчика.

• Если и на исходной, и на целевой системах включено шифрование: При поступлении данных в исходную систему они шифруются с помощью ключа шифрования исходной системы. Исходный ресурс расшифровывает локальные данные, повторно шифрует их с помощью ключа шифрования целевой системы, а затем реплицирует зашифрованные данные в целевую систему при репликации.
• Если в исходной системе отключено шифрование, а в целевом ресурсе включено шифрование: Все данные, поступающие в исходную систему, не шифруются (по очевидной причине). Однако при репликации исходная система шифрует данные с помощью ключа шифрования целевой системы, а затем реплицирует зашифрованные данные в целевую систему. 
• Если в исходной системе включено шифрование, а в целевой системе выключено: Все данные, поступающие в исходную систему, шифруются с помощью ключа шифрования исходной системы. Исходный ресурс расшифровывает данные, а затем реплицирует незашифрованные данные в целевую систему Data Domain при репликации.
• Если шифрование включено на реплике после настройки контекста репликации, то все новые реплицируемые сегменты шифруются в исходной системе реплики. Все сегменты, находящиеся на реплике до включения шифрования, остаются в незашифрованном состоянии, если шифрование не применяет изменения и GC не запускается в целевой системе. 

Если настроена репликация CREPL:
При репликации коллекции исходная и целевая системы должны работать под управлением одного и того же выпуска DDOS. Поэтому шифрование должно быть либо включено, либо отключено в обоих режимах. Также не может быть несоответствия в конфигурации шифрования. Ключи шифрования одинаковы для исходного и целевого ресурсов. 

• Если и на исходной, и на целевой системах включено шифрование: Все данные, поступающие в исходную систему, шифруются с помощью ключа шифрования исходной системы. При репликации исходная система отправляет зашифрованные данные в целевую систему Data Domain в зашифрованном состоянии. Целевая система Data Domain имеет тот же ключ, что и исходная, так как репликация коллекции предполагает точную репликацию исходной системы Data Domain. Никакие данные не могут быть записаны в целевую систему Data Domain вне репликации, так как целевая система доступна только для чтения.
• Если шифрование отключено и на исходном, и на целевом ресурсах: Все данные, поступающие в исходную систему, не шифруются (по очевидной причине). При репликации исходная система отправляет (реплицирует) данные в незашифрованном виде, и они остаются незашифрованными в целевой системе Data Domain. Никакие данные не могут быть записаны в целевую систему Data Domain вне репликации, так как целевая система доступна только для чтения.

Вопрос. Хранится ли ключ целевого ресурса в исходной системе Data Domain неограниченное время?
Ответ: Ключ шифрования целевого ресурса никогда не хранится в исходной системе Data Domain. Они хранятся в памяти (в зашифрованном виде) только во время активной сессии репликации. Это относится ко всем видам репликации, за исключением репликации коллекции. При репликации коллекции (CREPL) в исходной и целевой системах присутствует один и тот же набор ключей шифрования.  

Вопрос. Можно ли включить шифрование в системе CREPL после установки контекста репликации?
Ответ: Да, в этом случае шифрование должно быть включено как в исходной, так и в целевой системах. Шифрование можно включить в исходной и целевой системах, отключив контекст репликации. Все новые реплицируемые сегменты шифруются в реплике. Все сегменты, находившиеся на реплике до включения шифрования, остаются в незашифрованном состоянии.

Вопрос: Можно ли включить шифрование DD одновременно с функцией шифрования по сети в программном варианте DD Replication?
Ответ: Да, шифрование по сети и шифрование D@RE могут быть включены одновременно для достижения различных целей безопасности.

Вопрос: Что произойдет, если программный параметр DD Encryption и функция шифрования по проводам в программном параметре DD Replication включены одновременно?
Ответ: Первый исходный ресурс шифрует данные с помощью ключа шифрования назначения. Затем уже зашифрованные данные шифруются во второй раз из-за шифрования по сети при отправке этих данных по назначению. В пункте назначения после завершения расшифровки по сети данные будут храниться в зашифрованном формате, который был зашифрован с помощью ключа шифрования адресата.

Вопрос: Если шифрование включено в исходной и целевой системах, должна ли фраза-пароль быть одинаковой на обоих ресурсах?
Ответ: Если настроена репликация коллекции (CREPL), фраза-пароль должна быть такой же. Для других типов репликации (например, MREPL, MFR) фраза-пароль в исходной и целевой системах может отличаться.

Вопрос: Если в целевой системе включено шифрование (вопрос не применим к CREPL), шифруются ли реплицированные данные и данные из какой-либо другой точки доступа (например, через локальную резервную копию)? Можно ли разделить эти два каталога в реплике, при котором шифруются только реплицированные каталоги, а остальные данные доступа не шифруются?
Ответ: Нет, все данные шифруются в реплике (месте назначения) независимо от точки входа. Шифрование нельзя включить или отключить только на уровне MTree или каталога. 

Вопрос. Как осуществляется обмен ключами между исходной и целевой системами во время MREPL или MFR?
Ответ: На этапе связывания репликации целевой компьютер безопасно передает исходному ресурсу сведения о текущем алгоритме шифрования и ключе. Для контекстов репликации аутентификация всегда выполняется с использованием общего секретного ключа. Этот общий секрет используется для установки «сессионного» ключа с использованием протокола обмена ключами Диффи-Хеллмана. Этот сессионный ключ используется для шифрования и расшифровки ключа шифрования системы Data Domain.

Вопрос: Какой тип алгоритма шифрования используется для функции Data Domain «шифрование по сети» в отношении шифрования трафика репликации?
Ответ: Если для режима аутентификации репликации установлено значение «односторонняя» или «двусторонняя», для обмена ключами сеанса используется DHE (эфемерный Диффи-Хеллман). Аутентификация сервера происходит с помощью RSA. 256-разрядный шифр GCM AES используется для инкапсуляции реплицированных данных по сети. Уровень инкапсуляции шифрования немедленно удаляется при попадании в целевую систему. 

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

Если для режима аутентификации репликации установлено значение «Анонимный», для обмена ключами между сеансами используется метод Диффи-Хеллмана (Anonymous), но в этом случае исходная и целевая системы не проверяют подлинность друг друга перед обменом ключами. Кроме того, если режим аутентификации не указан, по умолчанию используется значение «анонимный».

Вопрос: Работает ли ротация ключей без перезапуска файловой системы со всеми видами репликации?
Ответ: Ротация ключей без перезапуска файловой системы работает со всеми видами репликации, кроме DREPL (поддержка DREPL уже закончилась) и разностной репликации (которая также известна как LBO)Вопрос

: Как в отсутствие сертификатов или пар ключей PKI обеспечивается защита ключа шифрования системы назначения во время обмена ключами?
Ответ: Существует общий секрет для всех пар репликации Data Domain, который используется для создания общего ключа сеанса с помощью обмена ключами Диффи — Хеллмана. Этот общий ключ используется для шифрования ключа шифрования системы назначения.

Существует разница между общим секретом, используемым для проверки подлинности репликации, и общим ключом сеанса, который выделяется с помощью протокола обмена ключами Диффи — Хеллмана. Общий секрет, используемый для проверки подлинности репликации, устанавливается программным обеспечением Data Domain при первом использовании контекста репликации двумя системами Data Domain. Он также согласовывается через обмен Диффи-Хеллманом с использованием параметров, встроенных в код. Эти данные постоянно сохраняются в системах для аутентификации каждой сессии репликации между двумя системами. Ключ сессии репликации (ключ, используемый для шифрования ключа шифрования системы назначения) устанавливается с помощью другого обмена данными Диффи-Хеллмана с ранее установленным общим секретом, что приводит в действие протокол безопасного обмена ключами. Этот ключ не является постоянным и доступен только пока активен контекст репликации.

Вопрос: Обязательно ли для обоих доменов Data Domain пары репликации использовать одно и то же внешнее решение (например, диспетчер ключей KMIP) или одна из систем может использовать внешний диспетчер ключей, а другая — встроенный диспетчер ключей?
Ответ: В отличие от пары репликации коллекции, обеим системам, входящим в пару репликации, не обязательно использовать один и тот же диспетчер ключей.

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

Шифрование и перенос

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

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

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

Вопрос: Какие проверки совместимости шифрования выполняются в исходной и целевой системах во время переноса?
Ответ: Системный пароль, состояние шифрования и сведения о конфигурации диспетчера ключей, параметры режима FIPS — вот некоторые параметры шифрования, которые должны быть идентичными в исходной и целевой системах для успешного переноса. В этой статье базы знаний 183040 Data Domain: Процедура миграции систем DD с поддержкой облака (для просмотра статьи требуется вход в службу поддержки Dell) содержит подробные инструкции по миграции между системами с включенным облаком. Те же настройки применяются и для миграции только активного уровня.

Вопрос: Поддерживается ли перенос между системами с включенным параметром Encryption Disablement Project?
Ответ: Миграция данных между двумя системами поддерживается, если обе системы являются EDP или обе не являются EDP. Миграция данных из системы EDP в систему, не являющуюся системой EDP, допускается, если шифрование по сети явно отключено. (с помощью MIGRATION_ENCRYPTION sysparam)

Шифрование на Cloud Tier 

Вопрос. Поддерживается ли шифрование для уровня облака?
Ответ: Да, шифрование поддерживается на уровне облака. По умолчанию шифрование на уровне облака отключено. Команда «Cloud Enable» позволяет выбрать, следует ли включить шифрование на уровне облака.

Вопрос: Поддерживается ли протокол KMIP и внешние диспетчеры ключей на уровне облака?
Ответ: Да, KMIP и внешние диспетчеры ключей поддерживаются на уровне облака, начиная с DDOS 7.8.

Вопрос: С какой степенью детализации можно включить шифрование в облаке?
Ответ: Шифрование можно включать и отключать на каждом облачном устройстве и на каждом уровне независимо друг от друга.

Вопрос: Есть ли у облачных модулей независимые ключи?
Ответ: Нет, управление ключами является общим как для активного, так и для облачного уровней в DD. Если шифрование включено, ключи копируются на соответствующий модуль/уровень/контрольную точку. Если шифрование включено в активном, а не в облаке, ключи активного уровня не отражаются в облаке и наоборот. Это относится и к облачным модулям. (Например, если для CP1 включено шифрование, а для CP2 не включено шифрование, то ключи CP1 не отражаются на CP2.)   

Вопрос. Можно ли удалить ключи в облаке?
Ответ: Нет, удаление ключей из облака не поддерживается.

Вопрос: Где осуществляется управление ключами шифрования данных для облачных устройств?
Ответ: Ключи связаны с cp, а каждая облачная единица имеет отдельный cp. Копия ключей из всех cps хранится в активном cp.

Вопрос: Как восстановить облачные ключи во время аварийного восстановления? 
Ответ. В процессе восстановления CP файлы cpnameval зеркалируются в облако, поэтому ключи шифрования будут восстановлены в cpnameval. Теперь необходимо запустить инструмент ddr_key_util чтобы восстановить ключи.

Примечание. Для аварийного восстановления требуется участие службы поддержки клиентов.

Вопрос: Можно ли выполнять перемещение данных, если шифрование включено только на уровне облака?
Ответ: Нет, для перемещения данных необходимо включить шифрование на облачном и активном уровнях.

Вопрос: Можно ли включить внешний диспетчер ключей на уровне облака?
Ответ: Да, на уровне облака можно включить внешний диспетчер ключей. Эта функция поддерживается начиная с версии 7.8. Все операции, кроме удаления ключа, допустимого для активного уровня, также действительны для уровня облака с точки зрения внешнего диспетчера ключей. 

Шифрование и чистка памяти

Вопрос. Какую роль играет процесс глобальной очистки в шифровании в состоянии покоя и влияет ли это на производительность при первом включении шифрования?
Ответ: Включение шифрования неиспользуемых данных в первый раз влияет на производительность глобальной очистки. Это связано с тем, что данные, которые необходимо считывать из существующих контейнеров на диске и записывать в новые контейнеры, может потребоваться прочитать, расшифровать и распаковать перед повторным сжатием, шифрованием и записью на диск. Если шифрование включено на DD, где хранится значительный объем ранее существовавших данных, и выполняется команда «filesys encryption apply-changes», последующий цикл глобальной очистки пытается зашифровать все существующие данные в системе. Это означает, что все данные должны быть прочитаны, распакованы, сжаты, зашифрованы и записаны на диск. В результате первый цикл глобальной очистки после выполнения «filesys encryption apply-changes» может занять больше времени, чем обычно. Заказчики должны убедиться, что в системе DD достаточно свободного места для выполнения очистки без заполнения системы DD (в противном случае произойдет ошибка резервного копирования).

Вопрос: Влияет ли на производительность текущие циклы очистки данных/восстановления?
Ответ: Да, влияние на производительность есть, и это влияние обычно зависит от объема данных, которые принимаются/восстанавливаются между циклами очистки.

Вопрос: Сколько времени занимает шифрование существующих данных?
Для оценки времени используйте эту статью базы знаний Data Domain: Вычисление времени применения шифрования в состоянии покоя.

Шифрование и замена головокружения 

Вопрос. Может ли заказчик переместить диск в другую систему Data Domain в случае сбоя головки и получить доступ к диску при включенном шифровании?
Ответ: Ключ шифрования не привязан к самому системному головке Data Domain, поэтому вы можете переместить диски на другой системный головку Data Domain, и ключ будет доступен там. На новом системном заголовке Data Domain файловая система заблокирована, поэтому необходимо ввести парольную фразу с командой «filesys encryption unlock». 

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

Производительность шифрования

Вопрос. Каково наблюдаемое влияние использования шифрования на потребление ресурсов хранилища?
Ответ: Это ничтожно мало, примерно 1% накладных расходов, связанных с хранением некоторых параметров шифрования с пользовательскими данными.

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

Режим CBC First
Full: Снижение производительности на ~10% при операциях
записи с инкрементным действием: Снижение производительности на ~5% при операциях
записи Восстановление: Снижение производительности на 5–20% при операциях

чтения Режим
GCM First Full. Снижение производительности на 10–20% при операциях
записи с инкрементным действием: Снижение производительности на 5–10% при операциях
записи Восстановление: Снижение производительности при операциях чтения на 5–20%

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

Рекомендации

Вопрос. Каковы передовые практики в отношении политики ротации ключей?
Ответ: Политика автоматической смены ключей по умолчанию не включена. Заказчик включил его. Рекомендуется часто менять ключи шифрования. Если в системе настроен внешний диспетчер ключей KMIP, рекомендуется часто менять ключи для дальнейшей обработки сценариев компрометации ключей. Если для KMIP настроен уровень облака, рекомендуемый интервал ротации ключей составляет 1 неделю, а если для KMIP настроен только активный уровень, то рекомендуемая политика смены ключей составляет 1 месяц. Однако в зависимости от скорости приема ключа пользователь может также увеличить или уменьшить частоту смены ключей. Если настроен встроенный диспетчер ключей, рекомендуется использовать политику ротации ключей в диапазоне от 1 до 3 месяцев. 

Вопрос. Каковы передовые подходы к использованию класса ключей KMIP, если заказчик использует один и тот же сервер KMIP для нескольких систем DD?
Ответ: Рекомендуется иметь отдельный класс ключей для каждой системы DD, если они используют один и тот же сервер KMIP. Таким образом, ротация ключей, выполненная в одной системе DDOS, не влияет на состояние ключа в другой системе DDOS.

Дополнительные сведения см. в документе Устройства Dell EMC PowerProtect серии DD. Программное обеспечение для шифрования (delltechnologies.com)

Шифрование: Технический документ по устройствам PowerProtect серии DD: Программное

обеспечение для шифрованияПрочую документацию, связанную с DD Encryption (руководство администратора, справочное руководство по командам и руководство по настройке безопасности), можно найти в статье 126375 Основные документы PowerProtect и Data Domain.

Руководство по интеграции KMIP и таблица

совместимостиПосмотрите следующее видео.