Шифрування домену даних Dell EMC - Найпоширеніші запитання й відповіді

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

Питання: Як налаштовується шифрування (DARE) в ДД?
Відповідь: DARE Encryption можна налаштувати в ДД за допомогою наступних кроків:

1. Додати ліцензію на шифрування

2. Додайте Security Officer та увімкніть авторизації Security Officer

3. Увімкніть шифрування 

1) Додайте ліцензію на шифрування:
Отримайте файл ліцензії з дійсною
ліцензією на шифрування.Скористайтеся наведеною нижче командою, щоб оновити elicense в ДД за допомогою доступного файлу ліцензії.

Оновлення електронної ліцензії

2) Додайте співробітника безпеки та увімкніть авторизацію SO:
a) Додайте користувача з роллю "охорона" за допомогою команди: 

Користувач додає безпеку ролей SECuser

б) Увімкніть авторизацію співробітника служби безпеки в налаштуваннях за допомогою команди: 

Політика авторизації встановлена security-officer увімкнена

3. Увімкніть шифрування DARE:
Увімкніть DARE Encryption за допомогою команди:

Увімкнено шифрування Fileys

Питання: Які платформи підтримують функцію шифрування даних у стані спокою?
Відповідь: Функція шифрування даних у стані спокою підтримується в усіх системах Data Domain, за винятком систем Encryption Disablement Project (EDP).

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

Шифрування Fileys відключити

Питання: Які програми/протоколи резервного копіювання підтримуються функцією шифрування даних у стані спокою?
Відповідь: Функція DD DARE не залежить від базової програми резервного копіювання або протоколу, що використовується DD.

Qвикористання: Які алгоритми шифрування можна вибрати в системі Data Domain?
Відповідь: Програмне забезпечення DD Encryption підтримує 128 або 256-бітний алгоритм AES з використанням ланцюжка блоків шифру (CBC) або режиму лічильника Галуа (GCM). 

GCM — режим роботи криптографічних блокових шифрів із симетричним ключем. Це автентифікований алгоритм шифрування, призначений для забезпечення як аутентифікації, так і конфіденційності (конфіденційності). Як випливає з назви, GCM поєднує в собі добре відомий режим шифрування лічильника з новим режимом аутентифікації Галуа. Аспект аутентифікації GCM гарантує, що зашифровані дані були зроблені системою Data Domain і не були «введені» якимось іншим способом. Це відрізняється від CBC, де дані шифруються (аспект конфіденційності), але перевірка автентичності зашифрованих даних не проводиться.

У режимі CBC кожен блок відкритого тексту є ексклюзивним АБО з попереднім блоком текстового шифру перед шифруванням. Таким чином, кожен текстовий блок шифру залежить від усіх відкритих текстових блоків, оброблених до цього моменту. Також, щоб зробити кожне повідомлення унікальним, у першому блоці має бути використаний вектор ініціалізації. CBC гарантує приватність (конфіденційність) даних лише за допомогою шифрування. Автентифікація алгоритму або процесу шифрування не виконується.

Питання: Як ми можемо змінити алгоритм шифрування в ДД?

Відповідь: Використовуйте наведену нижче команду, якщо ви хочете встановити конкретний алгоритм шифрування в налаштуваннях.

Набір алгоритмів шифрування Fileys

Приклад:

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

Питання: Як ми забезпечуємо шифрування вже наявних даних після ввімкнення шифрування?
Відповідь: Ми можемо змусити DDFS зашифрувати вже існуючі дані за допомогою наступної команди:

# Застосовуються зміни шифрування filesys

Це робить наступний цикл прибирання значно довшим і ресурсомісткішим, ніж зазвичай.

Питання: Як відключити шифрування в ДД?
Відповідь: Відключити функцію шифрування в ДД за допомогою команди відключення шифрування: 

Шифрування Fileys відключити

Це вимикає шифрування лише для вхідного вводу/виводу. Існуючі зашифровані дані залишаються зашифрованими, доки їх не розшифрують вручну за допомогою apply-changes.

Питання: Які команди шифрування вимагають перезавантаження файлової системи DD для набуття чинності?
Відповідь: Наведені нижче команди шифрування вимагають перезавантаження файлової системи DD, щоб вони набули чинності:

Увімкнення/вимкнення шифрування fileys - Вмикає/вимикає шифрування в системі Data Domain.

Набір алгоритмів шифрування fileys - Дозволяють користувачеві вибрати криптографічний алгоритм.

Скидання алгоритму шифрування fileys - Скидає алгоритм шифрування до 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?
Відповідь: Шифрування можна налаштувати за допомогою CLI, UI або за допомогою REST API. Підтримка REST API додана в DDOS-релізі 8.0 і пізніше.

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

Питання: Чи передаються або зберігаються будь-які криптографічні ключі або паролі облікових записів у відкритому тексті або зі слабкими шифрами, наприклад, під час автентифікації сутності у файлі даних, програмах або в каталогах автентифікації?
Відповідь: Категорично ні.

Питання: Яка версія OpenSSL використовується в системі?
Відповідь: Станом на випуск DDOS 7.10, версія openssl має назву "OpenSSL 1.0.2zd-fips"

Питання: Як шифрування даних у стані спокою захищає від доступу до даних з боку користувачів і програм?
Відповідь: 

• Шифрування даних у стані спокою полягає в шифруванні даних, які знаходяться в підсистемі диска. Шифрування або дешифрування відбувається на рівні стиснення. Користувачі або програми надсилають і отримують чіткі текстові дані в систему Data Domain, але будь-які дані, що фізично знаходяться в системі Data Domain, шифруються.
• Усе шифрування відбувається під файловою системою та простором імен і є невидимим для користувачів або програм. Якщо користувач або програма вже має авторизований доступ до файлу або каталогу, дані можуть бути прочитані в рідному форматі незалежно від шифрування.
• Шифрування DD розроблено таким чином, що якщо зловмисник обійде інші засоби контролю безпеки мережі та отримає доступ до зашифрованих даних без належних криптографічних ключів, дані будуть нечитабельними та непридатними для використання цією особою. 

Питання: Чи відбудеться шифрування після дедуплікації?
Відповідь: Так, шифрування відбувається на дедуплікатах даних. Дані шифруються перед зберіганням на диску. 

Питання: Як домен даних забезпечує безпеку даних?
Відповідь: Дані захищені за допомогою функції шифрування даних у стані спокою. Крім того, при видаленні пристрою (заміна голови, блокування файлової системи) парольна фраза видаляється з системи. Ця парольна фраза використовується для шифрування ключів шифрування, тому дані додатково захищені.

Питання: Які сповіщення генеруються за допомогою шифрування?
Відповідь: Оповіщення формуються в наступних випадках:

• Якщо ключі шифрування скомпрометовані, вони присутні
• Коли таблиця ключів шифрування заповнена і в системі більше не можна додавати ключі
• Якщо не вдається експортувати автоматичний ключ
• Коли не вдається виконати автоматичне обертання клавіш
• Якщо шифрування вимкнено
• Коли системний пароль змінився

Питання: Чи існує сертифікація безпеки для DDOS? 
Відповідь: Системи домену даних відповідають стандарту FIPS 140-2. 

Питання: Де зберігається ключ шифрування?
Відповідь: Ключі шифрування постійно зберігаються в розділі колекції в системі DDOS.

Питання: Якщо хтось витягує жорсткий диск із системи Data Domain, чи можете ви розшифрувати дані з нього?
Відповідь: Ключі шифрування шифруються за допомогою системної парольної фрази, яка зберігається в головці системи. Незважаючи на те, що ключі шифрування зберігаються на диску, без системної парольної фрази ключі шифрування не можуть бути розшифровані. Таким чином, не знаючи ключа, який використовувався для шифрування даних, розшифровка неможлива з жорсткого диска.  

Питання: Які криптографічні ключі та паролі потрібні для відновлення, особливо для аварійного відновлення?
Відповідь: Ключі можна експортувати у захищений файл і зберігати поза системою. Відновлення цього файлу відбувається за допомогою інженерії. Також на момент відновлення клієнт повинен знати парольну фразу, яку він використовував під час команди експорту ключів.

Питання: Як заблокувати файлову систему перед передачею системи у віддалене місце.
Відповідь: Нижче наводиться порядок дій для неї: 

• Вимкніть файлову систему:

  sysadmin@itrdc-DD630-42# файли відключити

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

  sysadmin@itrdc-DD630-42# fileys encryption lock
  Ця команда вимагає авторизації користувачем, який має роль безпеки.
  Будь ласка, надайте облікові дані такого користувача нижче.
          Ім'я користувача: secuser
  Пароль:
  Введіть поточну парольну фразу:
  Введіть нову парольну фразу:
  Повторно введіть нову парольну фразу:
  Парольні фрази співпадають.
  Тепер файлову систему заблоковано.

• Нову парольну фразу НЕ можна втрачати або забувати. Без цієї парольної фрази файлову систему неможливо розблокувати, що означає, що дані на DDR неможливі. Щоб розблокувати систему, коли вона досягне віддаленого місця, використовуйте наведену нижче команду:

sysadmin@itrdc-DD630-42# розблокування
шифрування filesys Ця команда вимагає авторизації користувачем, який має роль безпеки.
Будь ласка, надайте облікові дані такого користувача нижче.
        Ім'я користувача: secuser
Пароль:
Введіть парольну фразу:
Парольна фраза була перевірена. Використовуйте 'fileys enable', щоб запустити файлову систему.

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

Питання: Чи має команда дезінфекції сховища якийсь зв'язок із шифруванням файлової системи?
Відповідь: Ні, шифрування файлової системи та дезінфекція сховища – це дві незалежні функції. 

Питання: Чи підтримується шифрування по дротовому зв'язку в системі EDP (проект відключення шифрування)?
Відповідь: Ми не можемо ввімкнути шифрування даних у стані спокою (DARE) або через дротове шифрування (з реплікацією або за допомогою ddboost) у системі EDP.

Системна парольна фраза 

Питання: Що таке парольна фраза системи?
Відповідь: DDOS надає можливість захистити облікові дані в системі шляхом встановлення парольної фрази на системному рівні. Парольна фраза — це зрозумілий (зрозумілий) ключ, який читається людиною, подібно до смарт-картки, який використовується для створення машинного ключа шифрування AES 256. 

Це дає дві переваги:

• Це дозволяє адміністратору змінити парольну фразу без необхідності маніпулювати ключами шифрування. Зміна парольної фрази опосередковано змінює шифрування ключів, але не впливає на дані користувача. Зміна парольної фрази не змінює базовий ключ шифрування системи Data Domain. Шифрування системного ключа домену даних змінюється, але системний ключ залишається незмінним.
• Це дозволяє поставляти фізичну систему Data Domain з ключем шифрування в системі, але без збереження парольної фрази на ній. Таким чином, у разі крадіжки коробки під час передачі, зловмисник не зможе легко відновити дані, оскільки система має лише зашифровані ключі та зашифровані дані.

Парольна фраза зберігається всередині прихованої частини системи зберігання Data Domain. Це дозволяє системі Data Domain завантажитися та продовжити обслуговування доступу до даних без втручання адміністратора.

Створення або зміна парольної фрази:

• Парольну фразу системи можна створити за допомогою командного рядка після автентифікації адміністратора в системі Data Domain.
• Парольну фразу системи можна змінити за допомогою CLI після автентифікації адміністратора та користувача ролі безпеки (наприклад, співробітника служби безпеки) у системі Data Domain (таким чином, що жоден адміністратор не може вносити зміни незалежно).

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

Питання: Як парольна фраза використовується для безпечного транспортування системи DD?
Відповідь: Процес використовує команду «fileys encryption lock», яка дозволяє користувачеві заблокувати файлову систему, змінивши парольну фразу. Користувач вводить нову парольну фразу, яка повторно шифрує ключ шифрування, але нова парольна фраза не зберігається. Ключі шифрування не можна відновити, доки файлову систему не буде розблоковано за допомогою команди «розблокування шифрування filesys».

Процес описаний у посібнику з конфігурації безпеки Confluence Lab.

Питання: Що станеться, якщо парольну фразу зміниться? Чи можна отримати доступ до даних?
Відповідь: Так, зміна парольної фрази не змінює базовий ключ шифрування системи домену даних, а лише шифрування ключа шифрування. Таким чином, це не вплине на доступ до даних.

Питання: Як ми можемо зробити запит, якщо в системі встановлено парольну фразу?
Відповідь: Якщо парольну фразу встановлено в системі, запуск команди "system passphrase set" видає помилку, яка вказує на те, що парольну фразу вже встановлено.

Питання: Що станеться, якщо парольну фразу буде втрачено або забуто?
Відповідь: Якщо клієнт втратить парольну фразу під час блокування коробки, він втратить свої дані. Не існує чорного ходу чи альтернативного способу отримати доступ до нього. Без належного процесу керування паролем це може статися випадково, і вони не зможуть відновити ключ або дані. Однак зашифрований ключ ніколи не може бути втрачений або пошкоджений завдяки інтегрованим механізмам захисту системи.

Питання: Чи є якийсь механізм для скидання забутої системної парольної фрази?
Відповідь: Системний пароль може бути скинутий примусово лише в певних сценаріях за допомогою служби підтримки клієнтів. Механізм примусового оновлення, введений в DDOS 7.2, може бути використаний для цього тільки при дотриманні конкретних умов. Більш детальна інформація наведена в статті КБ 20983, Домен даних: Як скинути втрачену системну парольну фразу в DDOS v7.2 або пізніше (для перегляду статті потрібен вхід до служби підтримки Dell)

Питання: Чи є можливість уникнути зберігання парольної фрази системи в системі DD?
Відповідь: Парольна фраза системи за замовчуванням зберігається в прихованому місці в системі Data Domain. Системним параметром "system passphrase option store-on-disk" можна скористатися для того, щоб змінити це і уникнути зберігання парольної фрази на диску.

Вбудований диспетчер ключів (EKM)

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

Опція вбудованого менеджера ключів-менеджерів <шифрування FilesYs>

Питання: Чи підтримується обертання клавіш за допомогою Вбудованого диспетчера ключів?
Відповідь:  Так, ротація ключів для кожної системи Data Domain підтримується за допомогою Embedded Key Manager. Через UI або CLI адміністратор може налаштувати період ротації ключів (щотижневий або щомісячний).

Питання: Чи стягується плата за функціональність керування вбудованими ключами?
Відповідь: За цю функцію не стягується плата. Ця функція входить до стандартної ліцензії на програмне забезпечення DD Encryption.

Питання: Чи може клієнт перейти від керування локальними ключами до керування зовнішніми ключами (EKM)?
Відповідь

• Так, зовнішні менеджери ключів можна активувати в будь-який час. Однак локальні ключі, які використовуються, залишаються в системі Data Domain. Зовнішні менеджери ключів не можуть керувати ключами EKM. Наявні дані не потребують повторного шифрування. Якщо для клієнта дані відповідності повинні бути повторно зашифровані за допомогою EKM-ключів, то це необхідно зробити вручну за допомогою apply-changes з новим RW-ключем. Знищення ключів EKM після перемикання не є обов'язковим.
  • Перемикач key-manager автоматично перемикає активний ключ на ключ від KMIP. 
  • Приклад того, як виглядає ключ KMIP MUID при перемиканні

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

Питання: Що відбувається, коли обертання клавіш вимкнено або увімкнено?
Відповідь: 

• Ротація ключів вимкнена — це функція шифрування за замовчуванням, якщо ви не ввімкнули ротацію ключів з інтерфейсу користувача або CLI. У цьому сценарії всі дані шифруються за допомогою існуючого активного ключа.
• Якщо включено обертання ключів, залежно від частоти обертання ми обертаємо клавіші, і дані шифруються останнім активним ключем.

Зовнішні менеджери ключів

Питання: Які зовнішні менеджери ключів підтримуються на DD?
Відповідь: Ми підтримуємо наступних зовнішніх ключових менеджерів:

• Gemalto KeySecure (підтримка додана в DDOS-релізі 7.2)
• Vormetric (підтримку додано в DDOS-релізі 7.3)
• CipherTrust (підтримка додана в DDOS-релізі 7.7)
• IBM GKLM (підтримку додано в DDOS-релізі 7.9)

Питання: Чи потрібна окрема ліцензія для інтеграції із зовнішнім менеджером ключів?
Відповідь: Так, для інтеграції External Key Manger з DD потрібна окрема ліцензія від відповідного постачальника.

Питання: Скільки ключових менеджерів підтримують одночасно?
Відповідь: Тільки один менеджер ключів може бути активний в будь-який момент часу в системі DD.

Питання: Де можна знайти додаткові відомості про те, як налаштувати диспетчер зовнішніх ключів KMIP?
Відповідь: Посібник з інтеграції KMIP для DDOS містить докладні відомості щодо налаштування різних менеджерів зовнішніх ключів, які підтримуються DD.

Питання: Як здійснюється керування сертифікатами для менеджерів зовнішніх ключів у DD?
Відповідь: Під час налаштування диспетчера зовнішніх ключів нам потрібно згенерувати сертифікат CA (сертифікат CA може бути самопідписаним сертифікатом або підписаним третьою стороною) та сертифікат хоста. Після завершення конфігурації на сервері менеджера зовнішніх ключів користувачі повинні імпортувати сертифікат ЦС і сертифікат хоста в систему DD. Потім налаштовуємо і включаємо зовнішній менеджер ключів. 

Питання: Що таке ЦА?
Відповідь: Центр сертифікації (CA) діє як початково довірена спільна сутність між вузлами та видає підписані сертифікати, щоб кожна сторона могла довіряти іншій. Сертифікат зазвичай виступає в якості посвідчення сервера або клієнта. 

Питання: Що таке локальний сертифікат ЦС, що таке сертифікат із підписом ЦС?
Відповідь: Сертифікат із підписом ЦС – це сертифікат, виданий і підписаний загальнодоступним довіреним центром сертифікації (ЦС). Сертифікат, підписаний ЦС, стає довіреним автоматично. Локальний ЦС може видавати підписані сертифікати, оскільки приватний ключ підпису зберігається в системі Менеджера ключів. Зовнішній ЦС не зберігає закритий ключ. Замість цього зовнішній ЦС використовується як довірена сутність для різних інтерфейсів і служб всередині системи.

Питання: Як створити запит на підпис сертифіката в ДД?
Відповідь: У системі Data Domain System згенеруйте CSR за допомогою наведеної нижче команди CLI. Таким чином, приватний ключ ніколи не потрапляє до зовнішнього менеджера ключів.

adminaccess сертифікат-підпис-запит

Питання: Чи можна перемикатися між Key Managers?
Відповідь: Перемикання між External Key Manger на Embedded Key Manager дозволено та є плавним. Але для переходу з Вбудованого диспетчера ключів до Менеджера зовнішніх ключів потрібне відповідне встановлення та налаштування сертифікатів. Перемикання між двома диспетчерами зовнішніх ключів (наприклад: Також допускаються KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust to GKLM). Також підтримується міграція ключів Key Manager (докладніше див. Довідник по інтеграції KMIP).

Питання: Що станеться, якщо підключення до зовнішнього диспетчера ключів перерветься? Чи доступні тоді мої дані?
Відповідь: Так, дані все ще доступні, коли ми не можемо підключитися до менеджера ключів, оскільки ми також зберігаємо копії ключів у системі DD. Не можна створити нові ключі або синхронізувати стани ключів, якщо немає з'єднання із зовнішнім менеджером ключів.

Питання: Чи є спосіб, за допомогою якого ми можемо уникнути зберігання ключів в DD і зберігати тільки в External Key Manager?
Відповідь: Ми завжди зберігаємо копію ключів в системі DD для цілей DIA. Цей параметр не можна змінити.

Питання: Чи впливає інтеграція з KMIP на продуктивність?
Відповідь: Ні, це не впливає на продуктивність завдяки використанню зовнішніх менеджерів ключів.

Питання: Чи можна використовувати рішення KMIP для вибраних доменів даних у середовищі?
Відповідь: Так, клієнти мають повну гнучкість у виборі відповідної методології шифрування для своїх систем Data Domain. Вони можуть продовжувати використовувати вбудований менеджер ключів Data Domain у деяких системах Data Domain, а також ротацію ключів шифрування за допомогою KMIP на інших системах Data Domain у своєму середовищі.

Питання: Чи безпечне з'єднання між доменом даних і KMIP?
Відповідь: Так, домен даних обмінюється даними через сеанси взаємної автентифікації сертифіката X509 із TLS. Користувач може використовувати Data Domain CLI для імпорту відповідного сертифіката X509 у систему Data Domain. Цей сертифікат потім використовується для встановлення захищеного каналу між DD і KMIP.

Управління життєвим циклом ключових факторів 

Питання: Які можливості керування ключами існують із параметром DD Encryption?
Відповідь: Менеджер ключів керує створенням, розповсюдженням і керуванням життєвим циклом кількох ключів шифрування. Система захисту може використовувати як вбудований менеджер ключів, так і зовнішній менеджер ключів KMIP-скарг. Одночасно може діяти лише один менеджер ключів. Коли шифрування ввімкнено в системі захисту, за замовчуванням діє диспетчер вбудованих ключів. Якщо налаштовано диспетчер зовнішніх ключів, він замінює вбудований менеджер ключів і залишається чинним, доки його не буде вимкнено вручну. Перехід з Embedded Key Manager на External Key Manager або, навпаки, призводить до додавання нового ключа в систему, і він не вимагає перезавантаження файлової системи з релізу 7.1.

Питання: Які різні ключові стани в системі Data Domain?
Різні ключові стани в системі Data Domain такі:

• Активовано-RW: У такому стані на будь-якій системі ДД є лише один ключ і використовується для зчитування та запису даних. Цей ключ також використовується процесом GC для повторного шифрування контейнерів.
• Очікується активація: У такому стані на будь-якій системі ДД є лише один ключ. Це визначило ключ, який стане Activated-RW після наступного перезавантаження файлової системи. На сьогоднішній день такий стан існує тільки на момент включення шифрування. Ключ, активований у режимі очікування, не створюється.  
• Активований-RO: Зовнішні менеджери ключів можуть мати кілька активованих ключів. Найновіший ключ знаходиться в Activated-RW, решта знаходяться в цьому стані. Ключі можуть переходити в цей стан у системі DD, коли ми не можемо синхронізувати стан із менеджером ключів.
• Деактивовано: Це використовується для зчитування існуючих даних на системі DD.
• Скомпрометовані: Коли клієнт компрометує зовнішній ключ менеджера ключів, стан буде змінено на нього після наступної синхронізації ключа.  
• Позначені для знищення: Коли клієнт позначає ключ для знищення, то стан ключа стає Позначений для знищення. Коли запущено GC, усі контейнери, зашифровані за допомогою Marked-For-Destroyed key, повторно шифруються за допомогою ключа Activated-RW.
• Знищені: Ключ у стані Marked-For-Destroyed переходить у цей стан, коли з ним не пов'язані дані.
• Знищено-скомпрометовано: Ключ у скомпрометованому стані переходить у цей стан, коли з ним не пов'язані дані.

Питання: Чи можна експортувати ключі шифрування для аварійного відновлення?
Відповідь: Ключі можна експортувати вручну за допомогою наведеної нижче команди.

"Експорт ключів шифрування Filesys"

Система DD також експортує ключі за замовчуванням при додаванні нового ключа або при видаленні будь-якого ключа з системи.

Експортовані файли присутні в /ddr/var/.security і в зашифрованому форматі. Потім цей файл слід скопіювати з DDR і зберегти в безпечному місці, яке можна використовувати в будь-яких умовах аварійного відновлення пізніше.

Примітка: Імпорт ключів для аварійного відновлення вимагає втручання служби підтримки клієнтів, оскільки процес відновлення залежить від типу аварійного стану. Ми можемо імпортувати експортований файл ключа за допомогою наступної команди.

Ключі шифрування Fileys Імпорт <імені файлу> 

Питання: Чи зберігається ключ, згенерований KMIP, у системі Data Domain?
Відповідь: Так, ключ шифрування, отриманий з KMIP, зберігається в зашифрованому вигляді в системі Data Domain.

Питання: Як зміна ключового стану в пристрої KMIP застосовується до системи Data Domain?
Відповідь: Синхронізація клавіш відбувається щодня. Якщо доступний новий ключ або стан ключа змінено, синхронізація оновлює таблицю локальних ключів. ДД щодня опівночі отримує ключові оновлення від КМІП.

Питання: Чи можна вручну синхронізувати стани ключа між ДД та КМІП?
Відповідь: Так, CLI або UI домену даних можна використовувати для ручної синхронізації ключових станів між DD і KMIP. "Синхронізація ключів шифрування Filesys" - це команда, яка використовується для цього.

Питання: Чи можна змінити час, коли ДД отримує ключові оновлення від КМІП?
Відповідь: Ні, змінити час, коли ДД отримує ключові оновлення від КМІП, неможливо.

Питання: Чи є обмеження на кількість ключів, що підтримуються системою Data Domain?
Відповідь: Починаючи з DDOS 7.8, в будь-який момент часу система Data Domain може мати в системі максимум 1024 ключа. У Activated-RW є тільки одна клавіша, а решта клавіш можуть бути в будь-якому іншому стані.

Питання: Чи можна використовувати різні ключі для різних наборів даних у системах Data Domain? Чи можна це налаштувати?
Відповідь: Ні, ми підтримуємо лише один активний ключ у системі одночасно, і всі вхідні дані шифруються за допомогою поточного активного ключа. Ключами не можна керувати з більш тонкою деталізацією, як у

М-дерев.Питання: Чи є сповіщення про досягнення максимального ліміту ключів?
Відповідь: Так, оповіщення піднімається при досягненні максимального ліміту ключів 1024.

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

Питання: Чи можемо ми побачити обсяг даних, які пов'язані з певним ключем у системі Data Domain?
Відповідь: Так, це можна побачити на ДД, але не видно на сервері КМІП. Користувач може використовувати Data Domain, CLI та інтерфейс користувача, щоб побачити обсяг даних, пов'язаних із певним ключем.

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

Питання: Чи працює старий ключ, навіть якщо проміжок часу минув, щоб новий ключ став ефективним?
Відповідь: Термін дії ключів шифрування не закінчується. Старі ключі після обертання клавіш стають ключами тільки для читання і залишаються в DDOS.

Питання: Чи видаляється ключ шифрування автоматично, якщо в системі Data Domain немає пов'язаних із ним даних?
Відповідь: Ні, ключ не видаляється автоматично. Користувач повинен явно видалити ключ за допомогою DD CLI або UI.

Питання: Чи можна видалити ключ, навіть якщо в системі Data Domain є пов'язані з ним дані?
Відповідь: Ні, якщо з ключем пов'язані будь-які дані, його не можна видалити. Потрібне повторне шифрування даних за допомогою якогось іншого ключа, щоб видалити ключ, з яким пов'язані дані.

Питання: Якщо ключ видаляється в KMIP, то чи видаляється ключ також зі списку ключів Data Domain?
Відповідь: Ні, користувач повинен самостійно видалити ключ за допомогою DD CLI або UI.

Питання: Чи в середовищі Data Domain з кількома сайтами KMIP потрібен у кожному місці?
Відповідь: Ні, не обов'язково мати KMIP на кожному сайті з Data Domain. Ми можемо вказати на один сервер KMIP. Рекомендується мати окремий клас ключів для кожної системи DD, якщо вони використовують один і той самий сервер KMIP.

Питання: Якщо ключ скомпрометовано, чи є у нас процес відновлення даних, зашифрованих старим ключем?
Відповідь: У цьому випадку клієнт повинен позначити ключ як скомпрометований на сервері KMIP. Потім виконайте "синхронізацію ключів шифрування fileys" у системі DDOS, а потім запустіть "fileys encryption apply-changes", а потім запустіть GC (fileys clean). GC run повторно шифрує всі дані, які були зашифровані скомпрометованим ключем за допомогою новішого ключа. Як тільки GC завершено, ключовий стан змінюється на скомпрометований-знищений. Пізніше вони можуть видалити цей ключ. 

Шифрування та реплікація

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

Питання: Чи повинні вихідна та цільова системи працювати під керуванням однієї версії DD OS, щоб використовувати шифрування?
Відповідь: Джерело та призначення можуть бути у різних версіях DDOS для використання DARE з реплікацією, якщо матриця сумісності реплікації має місце (див. посібник адміністратора для матриці сумісності). 

Питання: Як реплікація працює з шифруванням?
Відповідь: Це залежить від того, яка форма реплікації використовується.

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

• Якщо шифрування джерела та призначення ввімкнено: Коли дані передаються до вихідної системи, вони шифруються ключем шифрування вихідної системи. Джерело розшифровує локальні дані, повторно шифрує їх за допомогою ключа шифрування системи призначення, а потім реплікує зашифровані дані до місця призначення під час реплікації.
• Якщо шифрування джерела вимкнено, а в адресаті — шифрування: Усі дані, що надходять до джерела, не шифруються (зі зрозумілих причин). Але під час реплікації джерело шифрує дані за допомогою ключа шифрування системи призначення, а потім реплікує зашифровані дані в систему призначення. 
• Якщо шифрування джерела ввімкнуто, а в адресаті – шифрування: Усі дані, що надходять до вихідної системи, шифруються за допомогою ключа шифрування вихідної системи. Джерело розшифровує дані, а потім реплікує незашифровані дані в цільову систему Data Domain під час реплікації.
• Якщо шифрування включено на репліці після налаштування контексту реплікації, то будь-які нові сегменти, які зараз реплікуються, шифруються в джерелі для репліки. Будь-які сегменти, що знаходяться на репліці до включення шифрування, залишаються в незашифрованому стані, якщо шифрування не застосовує зміни і GC не запускається на місці призначення. 

Якщо налаштована реплікація CREPL:
При реплікації колекції як вихідні, так і цільові системи повинні використовувати однаковий DDOS-реліз. Тому шифрування має бути увімкнено або вимкнено на обох варіантах. Також не може бути розбіжностей у конфігурації шифрування. Ключі шифрування збігаються з джерелом і призначенням. 

• Якщо шифрування джерела та призначення ввімкнено: Усі дані, що надходять до вихідної системи, шифруються за допомогою ключа шифрування вихідної системи. Під час реплікації джерело надсилає зашифровані дані до цільової системи Data Domain у зашифрованому стані. Система домену даних призначення має той самий ключ, що й джерело, оскільки реплікація колекції стосується точної копії системи домену вихідних даних. Жодні дані не можуть бути записані в систему домену даних призначення за межами реплікації, оскільки місце призначення є системою, доступною лише для читання.
• Якщо шифрування вимкнено як джерело, так і місце призначення: Всі дані, що надходять у вихідну систему, не шифруються (зі зрозумілих причин). При реплікації джерело надсилає (реплікує) дані в незашифрованому стані, і вони залишаються незашифрованими в цільовій системі Data Domain. Жодні дані не можуть бути записані в систему домену даних призначення за межами реплікації, оскільки місце призначення є системою, доступною лише для читання.

Питання: Чи зберігається ключ призначення на невизначений час у системі домену вихідних даних?
Відповідь: Ключ шифрування одержувача ніколи не зберігається в системі домену вихідних даних. Він зберігається в пам'яті (зашифрованому) лише під час активного сеансу реплікації. Це стосується всіх видів реплікації, крім колекційної реплікації. У колекційній реплікації (CREPL) однаковий набір ключів шифрування присутній у джерелі та призначенні.  

Питання: Чи можна ввімкнути шифрування в системі CREPL після встановлення контексту реплікації?
Відповідь: Так, у цьому випадку шифрування має бути ввімкнено як у джерелі, так і в адресаті. Шифрування можна ввімкнути у джерелі та призначенні, вимкнувши контекст реплікації. Будь-які нові репліковані сегменти шифруються на репліці. Будь-які сегменти, що знаходяться на репліці до включення шифрування, залишаються в незашифрованому стані.

Питання: Чи можна ввімкнути DD-шифрування одночасно з функцією бездротового шифрування в опції програмного забезпечення DD Replication?
Відповідь: Так, як дротове шифрування, так і D@RE можуть бути ввімкнені одночасно для досягнення різних цілей безпеки.

Питання: Що станеться, якщо одночасно активувати опцію програмного забезпечення для шифрування DD і функцію шифрування по дроту в опції програмного забезпечення для реплікації DD?
Відповідь: Перше джерело шифрує дані за допомогою ключа шифрування призначення. Потім вже зашифровані дані шифруються вдруге через дротове шифрування під час надсилання цих даних до місця призначення. У пункті призначення після завершення дротового розшифрування дані зберігатимуться в зашифрованому форматі, який був зашифрований за допомогою ключа шифрування одержувача.

Питання: Якщо шифрування увімкнено у джерелі та адресаті, чи має парольна фраза бути однаковою на обох?
Відповідь: Якщо налаштована реплікація є реплікацією колекції (CREPL), то парольна фраза має бути такою самою. Для інших видів реплікації (таких як MREPL, MFR) парольна фраза може бути різною за джерелом та призначенням.

Питання: Якщо шифрування ввімкнено на місці призначення (питання не застосовується до CREPL), чи шифруються як репліковані дані, так і дані з якоїсь іншої точки доступу (наприклад, через локальне резервне копіювання)? Чи є спосіб розділити їх на репліці, де шифруються лише репліковані каталоги, а інший доступ не зашифрований?
Відповідь: Ні, всі дані шифруються в репліці (пункті призначення) незалежно від точки входу. Шифрування не може бути включено або відключено тільки на рівні MTree або каталогів з деталізацією. 

Питання: Як відбувається обмін ключами між джерелом і пунктом призначення під час MREPL або MFR?
Відповідь: Під час фази асоціативної реплікації цільова машина надійно передає свій поточний алгоритм шифрування та ключову інформацію джерелу. Контексти реплікації завжди аутентифікуються за допомогою спільної таємниці. Цей спільний секрет використовується для встановлення ключа «сеансу» за допомогою протоколу обміну ключами Діффі-Хеллмана. Цей ключ сеансу використовується для шифрування та розшифрування ключа шифрування системи Data Domain.

Питання: Який алгоритм шифрування використовується для функції "шифрування по дроту" Data Domain щодо шифрування реплікаційного трафіку?
Відповідь: Коли режим автентифікації реплікації встановлено на «односторонній» або «двосторонній», DHE (ефемерний Діффі-Хеллман) використовується для обміну ключами сеансу. Аутентифікація сервера відбувається за допомогою RSA. 256-бітний шифр GCM використовується для інкапсуляції реплікованих даних по дроту. Шар інкапсуляції шифрування негайно видаляється, коли він потрапляє на систему призначення. 

Один із способів вказує на те, що сертифіковано лише сертифікат призначення. Два способи вказують на те, що перевірено сертифікати джерела та призначення. Перш ніж ви зможете використовувати режим автентифікації, необхідно встановити взаємну довіру, і обидві сторони з'єднання повинні ввімкнути цю функцію для продовження шифрування.

Коли режим автентифікації реплікації встановлено на «анонімний», для обміну сеансовими ключами використовується Anonymous Diffie-Hellman (ADH), але в цьому випадку джерело та призначення не автентифікують один одного перед обміном ключами. Крім того, якщо режим аутентифікації не вказано, за замовчуванням використовується анонімний.

Питання: Чи працює обертання клавіш без перезапуску файлової системи з усіма видами реплікації?
Відповідь: Обертання клавіш без перезапуску файлової системи працює з усіма видами реплікації, крім DREPL (підтримка DREPL вже закінчилася) і дельта-реплікації (яка також відома як LBO)

Питання: За відсутності сертифікатів або пар ключів PKI, як захищений ключ шифрування одержувача під час обміну ключами?
Відповідь: Існує спільний секрет між усіма парами реплікації домену даних, який використовується для встановлення спільного ключа сеансу за допомогою обміну ключами Діффі-Хеллмана. Цей спільний ключ використовується для шифрування ключа одержувача.

Існує різниця між спільним секретом, який використовується для аутентифікації реплікації, і спільним ключем сеансу, який виділяється за допомогою протоколу обміну ключами Діффі-Хеллмана. Спільний секрет, який використовується для аутентифікації реплікації, встановлюється програмним забезпеченням Data Domain вперше, коли дві системи Data Domain хочуть встановити контекст реплікації. Він також узгоджується через обмін Діффі-Хеллмана за допомогою параметрів, вбудованих у код. Це постійно зберігається в системах для автентифікації кожного сеансу реплікації між двома системами. Ключ сеансу реплікації (ключ, який використовується для шифрування ключа призначення призначення) встановлюється за допомогою іншого обміну Діффі-Хеллмана з раніше встановленим спільним секретом, тим самим керуючи безпечним протоколом обміну ключами. Цей ключ не є постійним і існує лише під час активного контексту реплікації.

Питання: Чи обов'язково, щоб обидва домени даних реплікаційної пари використовували одне і те ж рішення зовнішнього менеджера ключів (наприклад, KMIP key manager), або одна з систем може використовувати зовнішній менеджер ключів, а інша може використовувати вбудований менеджер ключів?
Відповідь: За винятком пари реплікації колекції, не обов'язково, щоб обидві системи в парі реплікації використовували один і той же менеджер ключів.

При реплікації колекції обидві системи Data Domain повинні бути налаштовані з одним і тим же менеджером ключів. Але і в цьому випадку єдиним джерелом є синхронізація ключів з менеджером ключів, і ці ключі також надсилаються до місця призначення. З іншими типами реплікації можна використовувати різні менеджери ключів з source та destination.

Шифрування та міграція

Питання: Чи підтримується міграція даних у системах з увімкненим шифруванням?
Відповідь: Так, міграція даних підтримується в системах з увімкненим шифруванням. Конфігурація шифрування у вихідних і цільових системах має бути узгоджена як обов'язкова умова перед початком міграції даних. Також рекомендується експортувати та створити резервну копію ключів шифрування у вихідній системі для цілей DIA перед початком міграції.

Питання: Чи підтримується міграція даних як для активного, так і для хмарного рівнів міграції для систем із підтримкою шифрування?
Відповідь: Так, міграція даних підтримується як для активного, так і для хмарного рівня міграції для систем із шифруванням. Список атрибутів-передумов, що перевіряються, застосовується залежно від того, на якому рівні ввімкнено шифрування.

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

Питання: Які перевірки сумісності шифрування виконуються між джерелом і місцем призначення під час міграції?
Відповідь: Парольна фраза системи, стан шифрування та деталі конфігурації диспетчера ключів, параметри режиму системного FIPS – це деякі з параметрів шифрування, які мають бути ідентичними на системах джерела та призначення, щоб міграція була успішною. Ця база знань стаття 183040, Домен даних: Процедура міграції для систем DD з підтримкою хмари (для перегляду статті необхідно увійти в службу підтримки Dell), детально описує кроки міграції між системами з увімкненою хмарою. Ті самі налаштування застосовуються і для міграції лише на активному рівні.

Питання: Чи підтримується міграція між системами з увімкненим проектом вимкнення шифрування?
Відповідь: Міграція даних підтримується між двома системами, якщо обидві є EDP або обидві не є EDP. Міграція даних дозволяється з системи EDP до системи, яка не належить до EDP, якщо шифрування на дроті явно вимкнено. (з використанням системи MIGRATION_ENCRYPTION)

Шифрування на рівні Cloud Tier 

Питання: Чи підтримується шифрування для хмарного рівня?
Відповідь: Так, шифрування підтримується на рівні хмари. За замовчуванням шифрування вимкнено на рівні хмари. Командний запит «Cloud Enable» пропонує вибрати, чи хочемо ми ввімкнути шифрування на рівні хмари.

Питання: Чи підтримується KMIP і External Key Manager у хмарному рівні?
Відповідь: Так, KMIP і External Key Manager підтримуються на хмарному рівні, починаючи з DDOS 7.8 і вище.

Питання: При якій деталізації можна ввімкнути шифрування в хмарі?
Відповідь: Шифрування можна вмикати та вимикати на кожному хмарному блоці та кожному рівні окремо.

Питання: Чи мають хмарні блоки незалежні ключі?
Відповідь: Ні, керування ключами є спільним як для активного, так і для хмарного рівнів у DD. Ключі копіюються на відповідний пристрій/рівень/cp, коли увімкнено шифрування. Якщо шифрування ввімкнено на активній, а не на хмарі, активні ключі рівня не відображаються на хмарі та навпаки. Це стосується і хмарних блоків. (Наприклад: у CP1 увімкнено шифрування, а у CP2 не увімкнено шифрування, тоді ключі CP1 не відображаються на CP2.)   

Питання: Чи можна видалити ключі в хмарі?
Відповідь: Ні, видалення ключів із хмари не підтримується.

Питання: Де керуються ключами шифрування даних для хмарних пристроїв?
Відповідь: Ключі пов'язані з cp, і кожна хмарна одиниця є окремим CP. Копія ключів з усіх cps зберігається в активному cp.

Питання: Як відновити хмарні ключі під час аварійного відновлення? 
Відповідь: cpnameval відображається в хмарі в рамках відновлення CP, ключі шифрування будуть відновлені в cpnameval. Тепер ми повинні запустити ddr_key_util інструмент, щоб відновити ключі.

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

Питання: Чи можемо ми здійснювати переміщення даних, коли шифрування ввімкнено лише на рівні хмари?
Відповідь: Ні, ми повинні ввімкнути шифрування як у хмарі, так і на активних рівнях для переміщення даних.

Питання: Чи можемо ми ввімкнути Зовнішній менеджер ключів на хмарному рівні?
Відповідь: Так, менеджер зовнішніх ключів можна ввімкнути на рівні хмари. Ця можливість підтримується з версії 7.8 і новішої версії. Усі операції, за винятком ключа знищення або видалення, який є дійсним для активного рівня, також дійсні для хмарного рівня з точки зору зовнішнього менеджера ключів. 

Шифрування та збір сміття

Питання: Яку роль відіграє процес глобального очищення в Encryption-At-Rest; і чи впливає на продуктивність перше ввімкнення шифрування?
Відповідь: Увімкнення шифрування даних у стані спокою вперше впливає на продуктивність глобального очищення. Це пов'язано з тим, що дані, які потрібно зчитувати з існуючих контейнерів на диску та записувати в нові контейнери, можуть вимагати зчитування, розшифрування та розпакування перед повторним стисненням, шифруванням та записом назад на диск. Коли шифрування включено на DD, що містить значну кількість вже існуючих даних, і виконується команда 'fileys encryption apply-changes), то наступний глобальний цикл очищення робить спробу зашифрувати всі існуючі дані в системі. Це означає, що всі дані повинні бути прочитані, розпаковані, стиснуті, зашифровані та записані на диск. Як наслідок, перший глобальний цикл очищення після запуску «застосовуються зміни шифрування filesys» може зайняти більше часу, ніж зазвичай. Клієнти повинні переконатися, що у них достатньо вільного місця в системі DD, щоб очищення могло завершитися без заповнення системи DD (інакше резервне копіювання не вдається).

Питання: Чи впливають на продуктивність поточні цикли прийому/відновлення чистоти?
Відповідь: Так, це впливає на продуктивність, і вплив зазвичай залежить від обсягу даних, які приймаються/відновлюються між циклами чистоти.

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

Шифрування та обмін головою 

Питання: Чи може клієнт перенести диск в іншу систему Data Domain, якщо головка вийде з ладу, і отримати доступ до диска при включеному шифруванні?
Відповідь: Ключ шифрування не прив'язаний до самої головки системи Data Domain, тому ви можете перемістити диски в іншу головку системи Data Domain і ключ доступний там. На новій головці системи Data Domain файлова система заблокована, тому вам доведеться вводити парольну фразу за допомогою команди "fileys encryption unlock". 

Питання: Що робити, якщо клієнт забув парольну фразу під час операції headswap?
Відповідь: Протягом цього часу вони можуть підключити стару головку та працювати зі службою підтримки, щоб скинути парольну фразу, а потім підключитися назад до нової головки та завершити процедуру заміни голови. 

Продуктивність шифрування

Питання: Який спостережуваний вплив на споживання пам'яті при використанні шифрування?
Відповідь: Він незначний з приблизно 1 відсотком накладних витрат, пов'язаних із зберіганням деяких параметрів шифрування з даними користувача.

Питання: Який спостережуваний вплив на пропускну здатність (запис і зчитування) при використанні шифрування даних у стані спокою?
Відповідь: Вплив на пропускну здатність під час використання шифрування може відрізнятися залежно від протоколу та платформи. Загалом, наступні відсотки є консервативним зниженням продуктивності в сукупній пропускній здатності:

Режим CBC Перший
Повний: Зниження продуктивності на ~10% при інкрементальному записі
: Зниження продуктивності на ~5% при записі
Відновлює: Зниження продуктивності на 5–20% у режимі ЗЧИТУВАННЯ

GCM Перший
Повний: Зниження продуктивності на 10 - 20% при інкрементальному записі
: Зниження продуктивності на 5 -10% на записі
Відновлює: Зниження продуктивності на 5–20% на READ

Ці числа є специфічними для накладних витрат на шифрування даних у стані спокою (шифрування по дроту враховується окремо)
 

Практичні поради

Питання: Які найкращі практики щодо політики ротації ключів?
Відповідь: Політика автоматичної ротації ключів не ввімкнена за замовчуванням. Клієнт увімкнув цю функцію. Рекомендується часто змінювати ключі шифрування. Коли систему налаштовано за допомогою зовнішнього менеджера ключів KMIP, рекомендується часто змінювати ключі, щоб у майбутньому впоратися з будь-якими сценаріями компрометації ключів. Якщо KMIP налаштовано на хмарний рівень, то рекомендований інтервал обертання ключів становить 1 тиждень, а якщо KMIP налаштовано лише на активному рівні, то запропонована політика ротації ключів становить 1 місяць. Однак, залежно від швидкості проковтування, клієнт також може збільшувати або зменшувати частоту обертання клавіш. Якщо налаштовано менеджер вбудованих ключів, то рекомендується використовувати політику ротації ключів у діапазоні від 1 до 3 місяців. 

Питання: Які найкращі практики з класом ключа KMIP, якщо клієнт використовує один і той самий сервер KMIP для багатьох систем DD?
Відповідь: Рекомендується мати окремий клас ключів для кожної системи DD, якщо вони використовують один і той самий сервер KMIP. Таким чином, обертання ключів, виконане в одній системі DDOS, не впливає на стан ключа, присутнього в іншій системі DDOS.

Для отримання додаткової інформації дивіться документ DELL EMC PowerProtect серії DD Appliances: Програмне забезпечення для шифрування (delltechnologies.com)

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

шифруванняІншу документацію, пов'язану з DD Encryption (Admin Guide, Command Reference Guide та Security Config Guide) можна знайти в основних документах статті 126375, PowerProtect і Data Domain.

Посібник з інтеграції KMIP та матриця

сумісностіДивіться це відео: