Dell EMC Data Domain Encryption — często zadawane pytania

Konfiguracja szyfrowania

Pytanie: Jak skonfigurowano szyfrowanie (DARE) w DD?
Odpowiedź: Szyfrowanie DARE można skonfigurować w DD, wykonując następujące czynności:

1. Dodaj licencję szyfrowania

2. Dodawanie przedstawiciela działu zabezpieczeń i włączanie autoryzacji dyrektora ds. bezpieczeństwa

3. Włącz szyfrowanie 

1) Dodaj licencję szyfrowania:
dodaj plik licencji z ważną licencją szyfrowania.
Użyj poniższego polecenia, aby zaktualizować e-licencję w DD przy użyciu dostępnego pliku licencji.

Aktualizacja e-licencji

2) Dodaj przedstawiciela działu zabezpieczeń i włącz autoryzacje SO:
a) Dodaj użytkownika z rolą "security" za pomocą polecenia: 

user add secuser role security

b) Włącz autoryzację dyrektora ds. bezpieczeństwa w konfiguracji za pomocą polecenia: 

Ustawienie zasad autoryzacji Włączony specjalista ds. bezpieczeństwa

3. Włącz szyfrowanie DARE:
Włącz szyfrowanie DARE za pomocą polecenia:

Włączenie szyfrowania filesys

Pytanie: Które platformy są obsługiwane przez funkcję szyfrowania danych w spoczynku?
Odpowiedź: Funkcja szyfrowania danych w stanie spoczynku jest obsługiwana we wszystkich systemach Data Domain z wyjątkiem systemów Encryption Disablement Project (EDP).

Pytanie: W jaki sposób użytkownik może przechowywać swoje dane w postaci zwykłego tekstu w DD?
Odpowiedź: Użytkownik może upewnić się, że dane są zapisywane w DD w postaci zwykłego tekstu i nie są szyfrowane, potwierdzając, że szyfrowanie jest wyłączone w konfiguracji.
Użytkownicy mogą wyłączyć szyfrowanie w DD za pomocą polecenia: 

Wyłączanie szyfrowania filesys

Pytanie: Które aplikacje/protokoły do tworzenia kopii zapasowych są obsługiwane przez funkcję szyfrowania danych w spoczynku?
Odpowiedź: Funkcja DD DARE jest niezależna od podstawowej aplikacji do tworzenia kopii zapasowych lub protokołu używanego przez DD.

Pytanie: Jakie algorytmy szyfrowania można wybrać w systemie Data Domain?
Odpowiedź: Oprogramowanie DD Encryption obsługuje 128- lub 256-bitowy algorytm AES przy użyciu Cipher Block Chaining (CBC) lub trybu licznika Galois (GCM). 

GCM to tryb działania kryptograficznych szyfrów blokowych z kluczem symetrycznym. Jest to uwierzytelniony algorytm szyfrowania zaprojektowany w celu zapewnienia zarówno uwierzytelniania, jak i prywatności (poufności). Jak sama nazwa wskazuje, GCM łączy w sobie dobrze znany tryb szyfrowania licznikowego z nowym trybem uwierzytelniania Galois. Aspekt uwierzytelniania GCM gwarantuje, że dane, które zostały zaszyfrowane, zostały wykonane przez system Data Domain i nie zostały "wstrzyknięte" w inny sposób. Różni się to od CBC, gdzie dane są szyfrowane (aspekt prywatności), ale nie ma kontroli autentyczności zaszyfrowanych danych.

W trybie CBC każdy blok zwykłego tekstu jest wyłączny z poprzednim blokiem tekstu szyfrowanego przed zaszyfrowaniem. W ten sposób każdy blok tekstu szyfrowanego zależy od wszystkich bloków zwykłego tekstu przetworzonych do tego momentu. Ponadto, aby każda wiadomość była unikalna, w pierwszym bloku należy użyć wektora inicjalizacji. CBC gwarantuje prywatność (poufność) danych tylko poprzez szyfrowanie. Nie jest wykonywane uwierzytelnianie algorytmu lub procesu szyfrowania.

Pytanie: Jak możemy zmienić algorytm szyfrowania w DD?

Odpowiedź: Użyj poniższego polecenia, jeśli chcesz ustawić określony algorytm szyfrowania w konfiguracji.

Zestaw algorytmu szyfrowania Filesys

Przykład:

# filesys encryption algorithm set {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Pytanie: Jak zapewnić szyfrowanie istniejących danych po włączeniu szyfrowania?
Odpowiedź: Możemy zmusić DDFS do szyfrowania już istniejących danych za pomocą poniższego polecenia:

# filesys encryption apply-changes

To sprawia, że następny cykl czyszczenia jest znacznie dłuższy i bardziej zasobożerny niż zwykle.

Pytanie: Jak wyłączyć szyfrowanie w DD?
Odpowiedź: Wyłącz funkcję szyfrowania w DD za pomocą polecenia encryption disable: 

Wyłączanie szyfrowania filesys

Wyłącza to szyfrowanie tylko dla przychodzących operacji we/wy. Istniejące zaszyfrowane dane pozostają zaszyfrowane, dopóki nie zostaną ręcznie odszyfrowane przy użyciu polecenia apply-changes.

Pytanie: Które polecenia szyfrowania wymagają ponownego uruchomienia systemu plików DD, aby zostały zastosowane?
Odpowiedź: Następujące polecenia szyfrowania wymagają ponownego uruchomienia systemu plików DD w celu zastosowania tych poleceń:

Włączanie/wyłączanie szyfrowania filesys — Włącza/wyłącza szyfrowanie w systemie Data Domain.

Zestaw algorytmów szyfrowania filesys — Umożliwia wybór algorytmu kryptograficznego.

Resetowanie algorytmu szyfrowania filesys — Resetuje algorytm szyfrowania do AES 256 w trybie CBC (domyślny).

Pytanie: Które polecenia szyfrowania wymagają wyłączenia systemu plików Data Domain w celu ich ustawienia/używania?
Odpowiedź: Następujące polecenia szyfrowania wymagają wyłączenia systemu plików Data Domain w celu ich ustawienia lub używania:

Zmiana hasła szyfrowania

Blokada/odblokowanie szyfrowania

Ogólne pytania dotyczące szyfrowania

Pytanie: Czy szyfrowanie DD jest obsługiwane we wszystkich systemach DD?
Odpowiedź: Opcja oprogramowania DD Encryption jest obsługiwana w systemach DD, jeśli nie jest to projekt wyłączenia szyfrowania (EDP), czyli systemach, które nie pozwalają na włączenie szyfrowania, sprzedawanych głównie w systemach regionu Rosji.

Pytanie: W jaki sposób wykonywana jest kryptografia w systemach DD?
Odpowiedź: Kryptografia jest wykonywana przy użyciu bibliotek OpenSSL i RSA BSafe (RSA BSafe to zatwierdzona przez FIPS 140-2 biblioteka kryptograficzna używana przez systemy DD do szyfrowania danych w spoczynku) w DDOS. 

Pytanie: Jaka wersja BSafe jest używana z systemem?
Odpowiedź: Od DDOS 7.10 używane wersje BSafe to "BSAFE Micro Edition Suite 4.4.0.0" i "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Pytanie: Jakie interfejsy użytkownika są dostępne do skonfigurowania szyfrowania w DDOS?
Odpowiedź: Szyfrowanie można skonfigurować przy użyciu interfejsu wiersza poleceń, interfejsu użytkownika lub interfejsów API REST. Dodano obsługę interfejsu API REST w wersji DDOS 8.0 i nowszej.

Pytanie: Możliwe jest selektywne szyfrowanie danych? Podoba Ci się tylko jedno drzewo MTree lub plik?
Odpowiedź: Szyfrowanie selektywne NIE jest możliwe. Szyfrowanie można włączać i wyłączać tylko w całym systemie, a nie wybiórczo. W przypadku systemów z obsługą chmury szyfrowanie można włączyć lub wyłączyć na poziomie szczegółowości warstwy chmury i jednostki chmury.  

Pytanie: Czy jakiekolwiek klucze kryptograficzne lub hasła do kont są przesyłane lub przechowywane w postaci zwykłego tekstu lub przy użyciu słabych szyfrów, na przykład podczas uwierzytelniania jednostki, w pliku danych, w programach lub w katalogach uwierzytelniania?
Odpowiedź: Absolutnie nie.

Pytanie: Jaka wersja OpenSSL jest używana z systemem?
Odpowiedź: Od wydania DDOS 7.10 wersja openssl to "OpenSSL 1.0.2zd-fips"

Pytanie: W jaki sposób szyfrowanie danych w stanie spoczynku chroni przed dostępem użytkowników i aplikacji do danych?
Odpowiedź: 

• Szyfrowanie danych w stanie spoczynku polega na szyfrowaniu danych znajdujących się w podsystemie dysku. Szyfrowanie lub odszyfrowywanie odbywa się w warstwie kompresji. Użytkownicy lub aplikacje wysyłają i odbierają dane w postaci zwykłego tekstu do systemu Data Domain, ale wszystkie dane fizycznie znajdujące się w systemie Data Domain są szyfrowane.
• Szyfrowanie odbywa się poniżej systemu plików i przestrzeni nazw i jest niewidoczne dla użytkowników lub aplikacji. Jeśli użytkownik lub aplikacja ma już autoryzowany dostęp do pliku lub katalogu, dane mogą być odczytywane w formacie natywnym niezależnie od szyfrowania.
• Szyfrowanie DD zostało zaprojektowane w taki sposób, że jeśli intruz ominie inne kontrole bezpieczeństwa sieci i uzyska dostęp do zaszyfrowanych danych, bez odpowiednich kluczy kryptograficznych, dane te są nieczytelne i bezużyteczne dla tej osoby. 

Pytanie: Czy po deduplikacji nastąpi szyfrowanie?
Odpowiedź: Tak, szyfrowanie odbywa się na deduplikowanych danych. Dane są szyfrowane przed zapisaniem na dysku. 

Pytanie: W jaki sposób Data Domain zapewnia bezpieczeństwo danych?
Odpowiedź: Dane są zabezpieczone za pomocą funkcji szyfrowania danych w spoczynku. Ponadto po usunięciu urządzenia (zamiana głowicy, blokada systemu plików) hasło jest usuwane z systemu. To hasło służy do szyfrowania kluczy szyfrowania, dzięki czemu dane są dodatkowo chronione.

Pytanie: Jakie alerty są generowane przy użyciu szyfrowania?
Odpowiedź: Alerty są generowane w następujących przypadkach:

• W przypadku naruszenia zabezpieczeń klucze szyfrowania są obecne
• Gdy tabela kluczy szyfrowania jest pełna i w systemie nie można dodać kolejnych kluczy
• W przypadku niepowodzenia automatycznego eksportowania kluczy
• Gdy automatyczna rotacja nie powiedzie się
• Gdy szyfrowanie jest wyłączone
• Po zmianie hasła systemowego

Pytanie: Czy jest jakiś certyfikat bezpieczeństwa dla DDOS? 
Odpowiedź: Systemy Data Domain są zgodne ze standardem FIPS 140-2. 

Pytanie: Gdzie jest przechowywany klucz szyfrowania?
Odpowiedź: Klucze szyfrowania są trwale przechowywane na partycji kolekcji w systemie DDOS.

Pytanie: Jeśli ktoś wyciągnie dysk twardy z systemu Data Domain, czy możesz odszyfrować z niego dane?
Odpowiedź: Klucze szyfrujące są szyfrowane przy użyciu hasła systemowego, które jest przechowywane w głowicy systemu. Mimo że klucze szyfrowania są przechowywane na dysku, bez hasła systemowego klucze szyfrowania nie mogą być odszyfrowane. Tak więc bez znajomości klucza, który użył do zaszyfrowania danych, odszyfrowanie nie jest możliwe z dysku twardego.  

Pytanie: Jakie klucze kryptograficzne i hasła są potrzebne do odzyskiwania, zwłaszcza do odtwarzania po awarii?
Odpowiedź: Klucze można eksportować w bezpiecznym pliku i przechowywać poza systemem. Odzyskiwanie tego pliku odbywa się za pomocą inżynierii. Ponadto w momencie odzyskiwania klient musi znać hasło, którego użył w momencie wykonywania polecenia eksportu kluczy.

Pytanie: Jak zablokować system plików przed przejściem systemu do lokalizacji zdalnej.
Odpowiedź: Poniżej znajduje się procedura: 

• Wyłącz system plików:

  sysadmin@itrdc-DD630-42# wyłącz filesys

• Zablokuj system plików i wprowadź nowe hasło (wymaga to uwierzytelnienia przez powyższego użytkownika zabezpieczeń):

  sysadmin@itrdc-DD630-42# blokada
  szyfrowania filesys To polecenie wymaga autoryzacji przez użytkownika z rolą "security".
  Prosimy o przedstawienie poniżej odpowiednich danych uwierzytelniających takiego użytkownika.
          Nazwa użytkownika: secuser
  Hasło:
  Wprowadź bieżące hasło:
  Wprowadź nowe hasło:
  Wprowadź ponownie nowe hasło:
  Hasła są zgodne.
  System plików jest teraz zablokowany.

• Nowe hasło NIE może zostać utracone ani zapomniane. Bez tego hasła nie można odblokować systemu plików, co oznacza, że nie można uzyskać dostępu do danych w DDR. Aby odblokować system po dotarciu do odległej lokalizacji, użyj poniższego polecenia:

sysadmin@itrdc-DD630-42# odblokowanie
szyfrowania filesys To polecenie wymaga autoryzacji przez użytkownika z rolą "security".
Prosimy o przedstawienie poniżej odpowiednich danych uwierzytelniających takiego użytkownika.
        Nazwa użytkownika: secuser
Hasło:
Wprowadź hasło:
Hasło zostało zweryfikowane. Użyj 'filesys enable', aby uruchomić system plików.

• System plików może być teraz włączony i używany w normalny sposób

Pytanie: Czy polecenie czyszczenia pamięci masowej ma jakikolwiek związek z szyfrowaniem systemu plików?
Odpowiedź: Nie, szyfrowanie systemu plików i oczyszczanie pamięci masowej to dwie niezależne funkcje. 

Pytanie: Czy szyfrowanie przewodowe jest obsługiwane w systemie EDP (encryption disablement project)?
Odpowiedź: Nie możemy włączyć szyfrowania danych w spoczynku (DARE) ani szyfrowania przewodowego (z replikacją lub ddboost) w systemie EDP.

Hasło systemowe 

Pytanie: Co to jest hasło systemowe?
Odpowiedź: DDOS umożliwia zabezpieczenie poświadczeń w systemie przez ustawienie hasła na poziomie systemu. Hasło to klucz czytelny (zrozumiały) dla człowieka, taki jak Smart Card, który służy do wygenerowania maszynowego klucza szyfrowania AES 256. 

Zapewnia dwie korzyści:

• Umożliwia administratorowi zmianę hasła bez konieczności manipulowania kluczami szyfrowania. Zmiana hasła pośrednio zmienia szyfrowanie kluczy, ale nie wpływa na dane użytkownika. Zmiana hasła nie powoduje zmiany bazowego klucza szyfrowania systemu Data Domain. Zmienia szyfrowanie klucza systemowego Data Domain, ale klucz systemowy pozostaje taki sam.
• Umożliwia to dostarczenie fizycznego systemu Data Domain z kluczem szyfrowania, ale bez przechowywania hasła. W ten sposób, jeśli skrzynka zostanie skradziona podczas transportu, atakujący nie może łatwo odzyskać danych, ponieważ system ma tylko zaszyfrowane klucze i zaszyfrowane dane.

Hasło jest przechowywane wewnętrznie w ukrytej części systemu pamięci masowej Data Domain. Umożliwia to uruchomienie systemu Data Domain i kontynuowanie obsługi dostępu do danych bez interwencji administratora.

Tworzenie lub zmiana hasła:

• Hasło systemowe można utworzyć za pomocą interfejsu wiersza polecenia po uwierzytelnieniu się administratora w systemie Data Domain.
• Hasło systemowe można zmienić za pomocą interfejsu wiersza polecenia po uwierzytelnieniu administratora i użytkownika z rolą zabezpieczeń (np. dyrektora ds. bezpieczeństwa) w systemie Data Domain (tak, że żaden pojedynczy administrator nie może wprowadzać zmian niezależnie).

Pytanie: Kiedy jest używane hasło?
Odpowiedź: Hasło systemowe jest używane jako klucz podstawowy przez różne komponenty DDOS, które obejmują szyfrowanie systemu plików, dostęp do chmury, zarządzanie certyfikatami, tokeny Boost, moduły konfiguracji systemu w środowiskach skalowalnych oraz informacje o licencjonowaniu. Oprogramowanie DDOS zapewnia mechanizmy ustawiania i modyfikowania hasła systemowego. Zapewnia również opcje kontrolujące, czy hasło systemowe ma być przechowywane na dysku, co jest szczególnie używane w celu zwiększenia bezpieczeństwa podczas transportu systemu DD. 

Pytanie: W jaki sposób hasło jest wykorzystywane do bezpiecznego transportu systemu DD?
Odpowiedź: Proces ten wykorzystuje polecenie "filesys encryption lock", które umożliwia użytkownikowi zablokowanie systemu plików poprzez zmianę hasła. Użytkownik wprowadza nowe hasło, które ponownie szyfruje klucz szyfrowania, ale nowe hasło nie jest przechowywane. Kluczy szyfrowania nie można odzyskać, dopóki system plików nie zostanie odblokowany za pomocą polecenia

"filesys encryption unlock".Proces ten jest opisany w Podręczniku konfiguracji zabezpieczeń Confluence Lab.

Pytanie: Co się stanie, jeśli hasło ulegnie zmianie? Czy nadal można uzyskać dostęp do danych?
Odpowiedź: Tak, zmiana hasła nie powoduje zmiany bazowego klucza szyfrowania systemu Data Domain, a jedynie szyfrowanie klucza szyfrowania. W związku z tym nie ma to wpływu na dostęp do danych.

Pytanie: Jak możemy zapytać, czy hasło jest ustawione w systemie?
Odpowiedź: Jeśli w systemie ustawiono hasło, uruchomienie polecenia "system passphrase set" spowoduje zwrócenie błędu wskazującego, że hasło jest już ustawione.

Pytanie: Co się stanie, jeśli hasło zostanie utracone lub zapomniane?
Odpowiedź: Jeśli klient utraci hasło, gdy skrzynka jest zablokowana, traci swoje dane. Nie ma tylnych drzwi ani alternatywnego sposobu uzyskania do niego dostępu. Bez dobrego procesu zarządzania tym hasłem może się to zdarzyć przypadkowo i nie będą w stanie odzyskać klucza lub danych. Jednak zaszyfrowany klucz nigdy nie może zostać utracony ani uszkodzony ze względu na zintegrowane mechanizmy ochrony systemu.

Pytanie: Czy istnieje jakiś mechanizm resetowania zapomnianego hasła systemowego?
Odpowiedź: Hasło systemowe można zresetować siłą tylko w niektórych sytuacjach z pomocą działu obsługi klienta. Mechanizm wymuszania aktualizacji wprowadzony w DDOS 7.2 może być użyty do tego tylko wtedy, gdy spełnione są określone warunki. Więcej szczegółów znajduje się w artykule bazy wiedzy 20983, Data Domain: Resetowanie utraconego hasła systemowego w systemie DDOS w wersji 7.2 lub nowszej (aby wyświetlić artykuł, wymagane logowanie do pomocy technicznej firmy Dell)

Pytanie: Czy istnieje możliwość uniknięcia przechowywania hasła systemowego w systemie DD?
Odpowiedź: Hasło systemowe jest domyślnie przechowywane w ukrytej lokalizacji w systemie Data Domain. Opcja systemowa "systemowa opcja hasła store-on-disk" może być użyta do zmiany tego stanu rzeczy i uniknięcia przechowywania hasła na dysku.

Wbudowany menedżer kluczy (EKM)

Polecenie najwyższego poziomu:

System# Szyfrowanie plików Opcja Embedded-Key-Manager <>

Pytanie: Czy rotacja kluczy jest obsługiwana przez wbudowany menedżer kluczy?
Odpowiedź:  Tak, wbudowany menedżer kluczy obsługuje rotacja kluczy na system Data Domain. Za pomocą interfejsu użytkownika lub interfejsu wiersza poleceń administrator może skonfigurować okres rotacji kluczy (tygodniowy lub miesięczny).

Pytanie: Czy wbudowana funkcja zarządzania kluczami jest płatna?
Odpowiedź: Korzystanie z tej funkcji jest bezpłatne. Ta funkcja jest dostępna w ramach standardowej opcji licencji na oprogramowanie DD Encryption.

Pytanie: Czy klient może przejść z lokalnego zarządzania kluczami do zewnętrznego zarządzania kluczami (EKM)?
Odpowiedź

• Tak, zewnętrzne menedżery kluczy można włączyć w dowolnym momencie. Używane klucze lokalne pozostają jednak w systemie Data Domain. Zewnętrzni menedżerowie kluczy nie mogą zarządzać kluczami EKM. Istniejące dane nie wymagają ponownego szyfrowania. Jeśli w przypadku klienta dane zgodności muszą zostać ponownie zaszyfrowane za pomocą kluczy EKM, należy to zrobić ręcznie za pomocą apply-changes z nowym kluczem RW. Niszczenie kluczy EKM po przełączniku nie jest obowiązkowe.
  • Przełącznik menedżera kluczy automatycznie przełącza aktywny klucz na klucz z protokołu KMIP. 
  • Przykład tego, jak wygląda identyfikator MUID klucza KMIP po przełączeniu

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

Pytanie: Co się stanie, gdy rotacja jest wyłączona lub włączona?
Odpowiedź: 

• Rotacja klucza wyłączona jest domyślną funkcją szyfrowania, jeśli nie włączysz rotacji klucza w interfejsie użytkownika lub interfejsie wiersza poleceń. W takim przypadku wszystkie dane są szyfrowane przy użyciu istniejącego aktywnego klucza.
• Jeśli rotacja kluczy jest włączona, w oparciu o częstotliwość rotacji obracamy klucze, a dane są szyfrowane ostatnim aktywnym kluczem.

Zewnętrzni menedżerowie kluczy

Pytanie: Jakie zewnętrzne menedżery kluczy są obsługiwane w DD?
Odpowiedź: Wspieramy następujących zewnętrznych menedżerów kluczy:

• Gemalto KeySecure (obsługa dodana w wersji 7.2 DDOS)
• Vormetric (obsługa dodana w wersji 7.3 DDOS)
• CipherTrust (obsługa dodana w wersji 7.7 DDOS)
• IBM GKLM (obsługa dodana w wersji 7.9 DDOS)

Pytanie: Czy do integracji z zewnętrznym menedżerem kluczy wymagana jest osobna licencja?
Odpowiedź: Tak, do integracji zewnętrznego Key Manager z DD wymagana jest oddzielna licencja od odpowiedniego dostawcy.

Pytanie: Ilu kluczowych menedżerów wspiera jednocześnie?
Odpowiedź: W danym momencie w systemie DD może być aktywny tylko jeden menedżer kluczy.

Pytanie: Gdzie znajdę więcej informacji na temat konfiguracji zewnętrznego menedżera kluczy KMIP?
Odpowiedź: Podręcznik integracji KMIP dla DDOS zawiera szczegółowe informacje na temat konfigurowania różnych zewnętrznych menedżerów kluczy obsługiwanych przez DD.

Pytanie: W jaki sposób zarządza się certyfikatami dla zewnętrznych menedżerów kluczy w DD?
Odpowiedź: Podczas konfigurowania zewnętrznego menedżera kluczy musimy wygenerować certyfikat CA (certyfikat CA może być certyfikatem z podpisem własnym lub podpisany przez stronę trzecią) oraz certyfikat hosta. Po zakończeniu konfiguracji na zewnętrznym serwerze zarządzania kluczami użytkownicy muszą zaimportować certyfikat CA i certyfikat hosta w systemie DD. Następnie konfigurujemy i włączamy zewnętrzny menedżer kluczy. 

Pytanie: Co to jest CA?
Odpowiedź: Urząd certyfikacji (CA) działa jako początkowo zaufana jednostka współużytkowana między elementami równorzędnymi i wystawia podpisane certyfikaty, aby umożliwić każdej ze stron zaufanie drugiej stronie. Certyfikat zazwyczaj działa jako tożsamość serwera lub klienta. 

Pytanie: Co to jest certyfikat podpisany przez lokalny urząd certyfikacji, co to jest certyfikat podpisany przez urząd certyfikacji?
Odpowiedź: Certyfikat podpisany przez instytucję certyfikującą to certyfikat, który został wystawiony i podpisany przez publicznie zaufany urząd certyfikacji (CA). Certyfikat podpisany przez instytucję certyfikującą automatycznie staje się zaufany. Lokalny urząd certyfikacji może wystawiać podpisane certyfikaty, ponieważ prywatny klucz podpisywania jest przechowywany w systemie Key Manager. Zewnętrzny urząd certyfikacji nie przechowuje klucza prywatnego. Zamiast tego zewnętrzny urząd certyfikacji jest używany jako zaufana jednostka dla różnych interfejsów i usług wewnątrz systemu.

Pytanie: Jak utworzyć prośbę o podpisanie certyfikatu w DD?
Odpowiedź: W systemie Data Domain wygeneruj CSR, używając poniższego polecenia CLI. W ten sposób klucz prywatny nigdy nie jest udostępniany zewnętrznemu menedżerowi kluczy.

adminaccess certyfikat cert-signing-request

Pytanie: Czy można przełączać się między Key Managerami?
Odpowiedź: Przełączanie między zewnętrznym Key Manager a wbudowanym menedżerem kluczy jest dozwolone i przebiega bezproblemowo. Jednak przejście z wbudowanego menedżera kluczy na zewnętrzne menedżery kluczy wymaga odpowiedniej instalacji i konfiguracji certyfikatów. Przełączanie między dwoma zewnętrznymi menedżerami kluczy (na przykład: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust do GKLM) są również dozwolone. Obsługiwana jest również migracja kluczy Key Manager (więcej informacji można znaleźć w podręczniku integracji KMIP).

Pytanie: Co się stanie, gdy połączenie zewnętrzne Key Manager zostanie przerwane? Czy moje dane są wtedy dostępne?
Odpowiedź: Tak, dane są nadal dostępne, gdy nie możemy połączyć się z menedżerem kluczy, ponieważ przechowujemy kopię kluczy również w systemie DD. Nie można tworzyć nowych kluczy lub nie można synchronizować stanów kluczy w przypadku braku łączności z zewnętrznym menedżerem kluczy.

Pytanie: Czy istnieje sposób, aby uniknąć przechowywania kluczy w DD i przechowywać je tylko w zewnętrznym menedżerze kluczy?
Odpowiedź: Zawsze przechowujemy kopię kluczy w systemie DD do celów DIA. Tego ustawienia nie można zmienić.

Pytanie: Czy integracja z KMIP ma wpływ na wydajność?
Odpowiedź: Nie, korzystanie z zewnętrznych menedżerów kluczy nie ma wpływu na wydajność.

Pytanie: Czy możliwe jest wykorzystanie rozwiązania KMIP dla wybranych domen danych w środowisku?
Odpowiedź: Tak, klienci mają pełną elastyczność w wyborze odpowiedniej metodologii szyfrowania dla swoich systemów Data Domain. Mogą nadal korzystać z wbudowanego menedżera kluczy Data Domain w niektórych systemach Data Domain oraz rotacji kluczy szyfrowania przy użyciu protokołu KMIP w innych systemach Data Domain w swoim środowisku.

Pytanie: Czy komunikacja między Data Domain a KMIP jest bezpieczna?
Odpowiedź: Tak, Data Domain komunikuje się z TLS za pośrednictwem wzajemnie uwierzytelnionych sesji certyfikatu X509. Użytkownik może użyć interfejsu wiersza poleceń Data Domain, aby zaimportować odpowiedni certyfikat X509 do systemu Data Domain. Certyfikat ten jest następnie używany do ustanowienia bezpiecznego kanału między DD i KMIP.

Zarządzanie cyklem życia kluczy 

Pytanie: Jakie możliwości zarządzania kluczami są dostępne w opcji DD Encryption?
Odpowiedź: Menedżer kluczy kontroluje generowanie, dystrybucję i zarządzanie cyklem życia wielu kluczy szyfrowania. System ochrony może korzystać z wbudowanego menedżera kluczy lub zewnętrznego menedżera kluczy ze skargą KMIP. W danym momencie może działać tylko jeden kluczowy menedżer. Jeśli szyfrowanie jest włączone w systemie ochrony, wbudowany menedżer kluczy jest włączony domyślnie. Jeśli skonfigurowano zewnętrzny menedżer kluczy, zastępuje on wbudowany menedżer kluczy i działa do momentu ręcznego wyłączenia. Przełączenie z wbudowanego menedżera kluczy na zewnętrzny menedżer kluczy lub odwrotnie powoduje dodanie nowego klucza do systemu, który nie wymaga ponownego uruchomienia systemu plików od wersji 7.1.

Pytanie: Jakie są różne stany kluczy w systemie Data Domain?
Poszczególne stany kluczy w systemie Data Domain są następujące:

• Aktywowane RW: W każdym systemie DD jest tylko jeden klucz w tym stanie i służy on do odczytu i zapisu danych. Ten klucz jest również używany przez proces GC do ponownego szyfrowania kontenerów.
• Oczekujące na aktywację: W każdym systemie DD znajduje się tylko jeden klucz w tym stanie. Zidentyfikowało to klucz, który zmieni się w Active-RW po następnym ponownym uruchomieniu systemu plików. Obecnie ten stan istnieje tylko w momencie włączenia szyfrowania. Nie jest tworzony żaden inny klucz aktywowany w oczekiwaniu na czas.  
• Aktywowany RO: Zewnętrzne menedżery kluczy mogą mieć wiele aktywowanych kluczy. Najnowszy klucz jest w Activeated-RW, pozostałe są w tym stanie. Klucze mogą przejść w ten stan w systemie DD, ale nie można zsynchronizować stanu z menedżerem kluczy.
• Dezaktywowany: Służy do odczytywania istniejących danych w systemie DD.
• Zagrożone: Gdy klient naruszy zewnętrzny klucz menedżera kluczy, stan zostanie zmieniony na ten klucz po następnej synchronizacji klucza.  
• Oznaczone do zniszczenia: Gdy klient oznaczy klucz do zniszczenia, stan klucza zmieni się na oznaczony do zniszczenia. Po uruchomieniu GC wszystkie kontenery zaszyfrowane za pomocą kluczy Marked-For-Destroyed są ponownie szyfrowane przy użyciu klucza Activated-RW.
• Zniszczone: Klucz w stanie Oznaczone do zniszczenia przechodzi w ten stan, gdy nie są z nim powiązane żadne dane.
• Zniszczone i naruszone: Klucz w stanie Compromised przechodzi w ten stan, gdy nie są z nim skojarzone żadne dane.

Pytanie: Czy klucze szyfrowania można eksportować w celu odtwarzania po awarii?
Odpowiedź: Klucze można wyeksportować ręcznie za pomocą poniższego polecenia.

"Eksport kluczy szyfrowania filesys"

System DD domyślnie eksportuje klucze, gdy zostanie dodany nowy klucz lub gdy którykolwiek klucz zostanie usunięty z systemu.

Wyeksportowane pliki znajdują się w katalogu /ddr/var/.security i są w zaszyfrowanym formacie. Plik ten należy następnie skopiować z DDR i zapisać w bezpiecznej lokalizacji, która może być później wykorzystana w warunkach odzyskiwania po awarii.

Uwaga: Importowanie kluczy do odtwarzania po awarii wymaga interwencji działu obsługi klienta, ponieważ proces przywracania zależy od typu awarii. Wyeksportowany plik klucza możemy zaimportować za pomocą następującego polecenia.

Filesys Encryption Keys Import <filename> 

Pytanie: Czy klucz wygenerowany przez KMIP jest przechowywany w systemie Data Domain?
Odpowiedź: Tak, klucz szyfrowania uzyskany z KMIP jest przechowywany w zaszyfrowany sposób w systemie Data Domain.

Pytanie: W jaki sposób zmiana stanu klucza urządzenia KMIP jest stosowana do systemu Data Domain?
Odpowiedź: Synchronizacja kluczy odbywa się codziennie. Jeśli dostępny jest nowy klucz lub stan klucza zostanie zmieniony, synchronizacja zaktualizuje tabelę kluczy lokalnych. DD otrzymuje kluczowe aktualizacje z KMIP codziennie o północy.

Pytanie: Czy można ręcznie zsynchronizować stany kluczy między DD i KMIP?
Odpowiedź: Tak, interfejs CLI lub interfejs użytkownika Data Domain może służyć do ręcznej synchronizacji stanów kluczy między DD i KMIP. Polecenie "

filesys encryption keys sync".Pytanie: Czy można zmienić godzinę, o której DD otrzymuje kluczowe aktualizacje z KMIP?
Odpowiedź: Nie, nie można zmienić godziny, o której DD otrzymuje kluczowe aktualizacje z KMIP.

Pytanie: Czy istnieje ograniczenie liczby kluczy obsługiwanych przez system Data Domain?
Odpowiedź: Począwszy od DDOS 7.8, system Data Domain w dowolnym momencie może mieć maksymalnie 1024 klucze w systemie. W Activated-RW jest tylko jeden klucz, a pozostałe klucze mogą być w dowolnym innym stanie.

Pytanie: Czy różne klucze mogą być używane dla różnych zestawów danych w systemach Data Domain? Czy można to skonfigurować?
Odpowiedź: Nie, w danym momencie w systemie obsługiwany jest tylko jeden aktywny klucz, a wszystkie przychodzące dane są szyfrowane przy użyciu aktualnie aktywnego klucza. Klucze nie mogą być kontrolowane z większą szczegółowością, jak M-drzewa.

Pytanie: Czy po osiągnięciu maksymalnego limitu kluczy jest wyświetlane powiadomienie?
Odpowiedź: Tak, alert jest zgłaszany po osiągnięciu maksymalnego limitu kluczy wynoszącego 1024.

Pytanie: Jak mogę usunąć alert o maksymalnym limicie kluczy?
Odpowiedź: Jeden z kluczy musi zostać usunięty, aby usunąć alert o maksymalnym limicie kluczy.

Pytanie: Czy możemy zobaczyć ilość danych powiązanych z określonym kluczem w systemie Data Domain?
Odpowiedź: Tak, widać to na DD, ale nie widać na serwerze KMIP. Użytkownik może użyć interfejsu wiersza polecenia Data Domain i interfejsu użytkownika, aby wyświetlić ilość danych skojarzonych z określonym kluczem.

Pytanie:  Czy w systemie DD widać wiek kluczy?
Odpowiedź: Tak, można to zobaczyć za pomocą EKM za pomocą interfejsu użytkownika.

Pytanie: Czy stary klucz działa nawet wtedy, gdy upłynął okres, aby nowy klucz zaczął obowiązywać?
Odpowiedź: Nie ma daty wygaśnięcia kluczy szyfrowania. Stare klucze po obróceniu klucza stają się kluczami tylko do odczytu i pozostają w systemie DDOS.

Pytanie: Czy klucz szyfrowania jest automatycznie usuwany, gdy w systemie Data Domain nie są z nim powiązane żadne dane?
Odpowiedź: Nie, klucz nie jest automatycznie usuwany. Użytkownik musi jawnie usunąć klucz za pomocą interfejsu wiersza polecenia lub interfejsu użytkownika DD.

Pytanie: Czy klucz można usunąć, nawet jeśli w systemie Data Domain są z nim powiązane dane?
Odpowiedź: Nie, jeśli z kluczem są powiązane jakiekolwiek dane, nie można go usunąć. Aby usunąć klucz, z którym są skojarzone dane, konieczne jest ponowne zaszyfrowanie danych przy użyciu innego klucza.

Pytanie: Jeśli klucz zostanie usunięty z modułu KMIP, to czy zostanie również usunięty z listy kluczy Data Domain?
Odpowiedź: Nie, użytkownik musi niezależnie usunąć klucz za pomocą interfejsu wiersza polecenia lub interfejsu użytkownika DD.

Pytanie: Czy w środowisku Data Domain z wieloma lokalizacjami KMIP jest wymagany w każdej lokalizacji?
Odpowiedź: Nie, nie jest konieczny posiadanie KMIP w każdej lokacji z Data Domain. Możemy wskazać jeden serwer KMIP. Zaleca się posiadanie oddzielnej klasy kluczy dla każdego systemu DD, jeśli używają tego samego serwera KMIP.

Pytanie: Czy w przypadku złamania zabezpieczeń klucza istnieje proces pobierania danych zaszyfrowanych starym kluczem?
Odpowiedź: W takim przypadku klient musi oznaczyć klucz jako zagrożony na serwerze KMIP. Następnie wykonaj polecenie "filesys encryption keys sync" w systemie DDOS, a następnie uruchom polecenie "filesys encryption apply-changes", a następnie uruchom polecenie GC (filesys clean). Uruchomienie GC ponownie szyfruje wszystkie dane, które zostały zaszyfrowane przy użyciu naruszonego klucza przy użyciu nowszego klucza. Po zakończeniu GC stan klucza zostanie zmieniony na compromised-destroyed. Później mogą usunąć ten klucz. 

Szyfrowanie i replikacja

Pytanie: Czy DD Replication jest obsługiwana i współdziałać z opcją oprogramowania DD Encryption?
Odpowiedź: Tak, DD Replication może być używany z opcją DD Encryption, umożliwiając w ten sposób replikację zaszyfrowanych danych przy użyciu różnych rodzajów replikacji. Każdy formularz replikacji działa unikatowo z szyfrowaniem i oferuje ten sam poziom bezpieczeństwa.

Pytanie: Czy na systemach źródłowych i docelowych musi być uruchomiona ta sama wersja systemu operacyjnego DD, aby można było korzystać z szyfrowania?
Odpowiedź: Źródło i miejsce docelowe mogą znajdować się w różnych wersjach DDOS, aby używać DARE z replikacją, jeśli istnieje macierz zgodności replikacji (zobacz przewodnik administratora, aby uzyskać informacje o matrycy zgodności). 

Pytanie: Jak replikacja działa z szyfrowaniem?
Odpowiedź: To zależy od używanej formy replikacji.

Jeśli skonfigurowana replikacja to MREPL lub MFR:
W przypadku korzystania z MREPL lub MFR szyfrowanie DD może być licencjonowane lub włączane niezależnie w źródle lub miejscu docelowym, w zależności od tego, co klient chce osiągnąć.

• Gdy szyfrowanie jest włączone zarówno w źródle, jak i w obiekcie docelowym: Dane pozyskane w systemie źródłowym są szyfrowane przy użyciu klucza szyfrowania systemu źródłowego. Źródło odszyfrowuje dane lokalne, ponownie szyfruje je przy użyciu klucza szyfrowania systemu docelowego, a następnie replikuje zaszyfrowane dane do miejsca docelowego podczas replikacji.
• Gdy źródło ma wyłączone szyfrowanie, a miejsce docelowe ma włączone szyfrowanie: Wszystkie dane pozyskiwane do źródła nie są szyfrowane (z oczywistego powodu). Jednak podczas replikacji źródło szyfruje dane przy użyciu klucza szyfrowania systemu docelowego, a następnie replikuje zaszyfrowane dane do systemu docelowego. 
• Gdy źródło ma włączone szyfrowanie, a cel ma wyłączone szyfrowanie: Wszystkie dane przychodzące do systemu źródłowego są szyfrowane przy użyciu klucza szyfrowania systemu źródłowego. Źródło odszyfrowuje dane, a następnie replikuje niezaszyfrowane dane do docelowego systemu Data Domain podczas replikacji.
• Jeśli szyfrowanie jest włączone w replice po skonfigurowaniu kontekstu replikacji, wszystkie nowe segmenty, które są teraz replikowane, są szyfrowane w źródle repliki. Wszystkie segmenty znajdujące się w replice przed włączeniem szyfrowania pozostają w stanie nieszyfrowanym, chyba że szyfrowanie zastosuje zmiany i GC zostanie uruchomione w miejscu docelowym. 

Jeśli skonfigurowana replikacja to CREPL:
W przypadku replikacji kolekcji w systemach źródłowych i docelowych musi być uruchomiona ta sama wersja DDOS. W związku z tym szyfrowanie musi być włączone lub wyłączone w obu przypadkach. Nie może również występować niezgodność w konfiguracji szyfrowania. Klucze szyfrowania są takie same dla kluczy źródłowych i docelowych. 

• Gdy szyfrowanie jest włączone zarówno w źródle, jak i w obiekcie docelowym: Wszystkie dane przychodzące do systemu źródłowego są szyfrowane przy użyciu klucza szyfrowania systemu źródłowego. Podczas replikacji źródło wysyła zaszyfrowane dane do docelowego systemu Data Domain w stanie zaszyfrowanym. Docelowy system Data Domain ma taki sam klucz jak źródłowy, ponieważ replikacja kolekcji dotyczy dokładnej repliki źródłowego systemu Data Domain. W docelowym systemie Data Domain poza replikacją nie można zapisać żadnych danych, ponieważ miejsce docelowe jest systemem tylko do odczytu.
• Jeśli szyfrowanie jest wyłączone zarówno dla źródła, jak i miejsca docelowego: Wszystkie dane przychodzące do systemu źródłowego nie są szyfrowane (z oczywistego powodu). Podczas replikacji źródło wysyła (replikuje) dane w stanie niezaszyfrowanym i pozostają one niezaszyfrowane w docelowym systemie Data Domain. W docelowym systemie Data Domain poza replikacją nie można zapisać żadnych danych, ponieważ miejsce docelowe jest systemem tylko do odczytu.

Pytanie: Czy klucz miejsca docelowego jest bezterminowo przechowywany w źródłowym systemie Data Domain?
Odpowiedź: Klucz szyfrowania obiektu docelowego nigdy nie jest przechowywany w źródłowym systemie Data Domain. Jest ona przechowywana w pamięci (zaszyfrowana) tylko wtedy, gdy sesja replikacji jest aktywna. Dotyczy to wszystkich rodzajów replikacji z wyjątkiem replikacji kolekcji. W replikacji kolekcji (CREPL) ten sam zestaw kluczy szyfrowania znajduje się w źródle i miejscu docelowym.  

Pytanie: Czy można włączyć szyfrowanie w systemie CREPL po ustanowieniu kontekstu replikacji?
Odpowiedź: Tak, w takim przypadku szyfrowanie musi być włączone zarówno w źródle, jak i w obiekcie docelowym. Szyfrowanie można włączyć w źródle i obiekcie docelowym, wyłączając kontekst replikacji. Wszystkie nowe replikowane segmenty są szyfrowane w replice. Wszystkie segmenty znajdujące się w replice przed włączeniem szyfrowania pozostają w stanie niezaszyfrowanym.

Pytanie: Czy szyfrowanie DD można włączyć jednocześnie z funkcją szyfrowania przewodowego w opcji oprogramowania DD Replication?
Odpowiedź: Tak, zarówno szyfrowanie przewodowe, jak i D@RE mogą być włączone jednocześnie, aby osiągnąć różne cele bezpieczeństwa.

Pytanie: Co się stanie, jeśli jednocześnie włączone zostaną zarówno opcja oprogramowania DD Encryption, jak i funkcja szyfrowania przewodowego w opcji oprogramowania DD Replication?
Odpowiedź: Pierwsze źródło szyfruje dane przy użyciu docelowego klucza szyfrowania. Następnie już zaszyfrowane dane są szyfrowane po raz drugi z powodu szyfrowania przewodowego podczas wysyłania tych danych do miejsca docelowego. W miejscu docelowym po zakończeniu odszyfrowywania przez sieć przewodową dane będą przechowywane w zaszyfrowanym formacie, który został zaszyfrowany przy użyciu klucza szyfrowania odbiorcy.

Pytanie: Jeśli szyfrowanie jest włączone w źródle i obiekcie docelowym, czy hasło musi być takie samo w obu systemach?
Odpowiedź: Jeśli skonfigurowana replikacja to replikacja kolekcji (CREPL), hasło musi być takie samo. W przypadku innych rodzajów replikacji (takich jak MREPL, MFR) hasło może być różne w źródle i miejscu docelowym.

Pytanie: Czy przy włączonym szyfrowaniu w miejscu docelowym (pytanie nie dotyczy CREPL), zarówno replikowane dane, jak i dane z innego punktu dostępu (na przykład za pośrednictwem lokalnej kopii zapasowej) są szyfrowane? Czy istnieje sposób na oddzielenie tych dwóch katalogów w replice, w którym tylko replikowane katalogi są szyfrowane, podczas gdy inny dostęp nie jest szyfrowany?
Odpowiedź: Nie, wszystkie dane są szyfrowane w replice (miejscu docelowym) niezależnie od punktu wejścia. Szyfrowania nie można włączać i wyłączać wyłącznie na poziomie MTree lub katalogu. 

Pytanie: W jaki sposób odbywa się wymiana kluczy między źródłem a miejscem docelowym podczas MREPL lub MFR?
Odpowiedź: Podczas fazy asocjacji replikacji komputer docelowy bezpiecznie przesyła bieżący algorytm szyfrowania i kluczowe informacje do źródła. Konteksty replikacji są zawsze uwierzytelniane przy użyciu wspólnego klucza tajnego. Ten wspólny klucz tajny służy do ustanowienia klucza "sesji" przy użyciu protokołu wymiany kluczy Diffiego-Hellmana. Ten klucz sesji służy do szyfrowania i odszyfrowywania klucza szyfrowania systemu Data Domain.

Pytanie: Jaki typ algorytmu szyfrowania jest używany dla funkcji "szyfrowania przez sieć" Data Domain w odniesieniu do szyfrowania ruchu replikacji?
Odpowiedź: Gdy tryb uwierzytelniania replikacji jest ustawiony na "jednokierunkowy" lub "dwukierunkowy", DHE (efemeryczny Diffie-Hellman) jest używany do wymiany kluczy sesji. Uwierzytelnianie serwera odbywa się za pomocą RSA. 256-bitowy szyfr AES GCM służy do hermetyzacji replikowanych danych przez sieć. Warstwa hermetyzacji szyfrowania jest usuwana natychmiast po wylądowaniu w systemie docelowym. 

Jeden ze sposobów wskazuje, że tylko certyfikat docelowy jest certyfikowany. Dwa sposoby wskazują, że weryfikowane są zarówno certyfikaty źródłowe, jak i docelowe. Przed użyciem trybu uwierzytelniania należy ustanowić wzajemne zaufanie, a obie strony połączenia muszą włączyć tę funkcję, aby szyfrowanie było kontynuowane.

Gdy tryb uwierzytelniania replikacji jest ustawiony na "anonimowy", anonimowy Diffie-Hellman (ADH) jest używany do wymiany kluczy sesji, ale w tym przypadku źródło i miejsce docelowe nie uwierzytelniają się nawzajem przed wymianą kluczy. Ponadto, jeśli tryb uwierzytelniania nie jest określony, jako domyślny używany jest tryb anonimowy.

Pytanie: Czy rotacja klucza bez ponownego uruchomienia systemu plików działa ze wszystkimi rodzajami replikacji?
Odpowiedź: Obracanie klucza bez ponownego uruchamiania systemu plików działa ze wszystkimi rodzajami replikacji z wyjątkiem DREPL (obsługa DREPL już się zakończyła) i replikacji delta (znanej również jako LBO)

Pytanie: W jaki sposób klucz szyfrowania miejsca docelowego jest chroniony podczas wymiany kluczy w przypadku braku certyfikatów lub par kluczy PKI?
Odpowiedź: Między wszystkimi parami replikacji Data Domain istnieje wspólny klucz tajny, który służy do ustanawiania udostępnionego klucza sesji przy użyciu wymiany kluczy Diffiego-Hellmana. Ten klucz udostępniony służy do szyfrowania klucza szyfrowania obiektu docelowego.

Istnieje różnica między wspólnym kluczem tajnym używanym do uwierzytelniania replikacji a udostępnionym kluczem sesji, który jest przydzielany przy użyciu protokołu wymiany kluczy Diffiego-Hellmana. Wspólny klucz tajny używany do uwierzytelniania replikacji jest ustanawiany przez oprogramowanie Data Domain, gdy dwa systemy Data Domain po raz pierwszy chcą ustanowić kontekst replikacji. Jest to również uzgadniane poprzez wymianę Diffiego-Hellmana przy użyciu parametrów osadzonych w kodzie. Jest on trwale przechowywany w systemach w celu uwierzytelniania każdej sesji replikacji między dwoma systemami. Klucz sesji replikacji (klucz używany do szyfrowania klucza szyfrowania miejsca docelowego) jest ustanawiany przy użyciu innej wymiany Diffiego-Hellmana z wcześniej ustanowionym wspólnym sekretem, napędzając w ten sposób protokół bezpiecznej wymiany kluczy. Ten klucz nie jest trwały i istnieje tylko wtedy, gdy kontekst replikacji jest aktywny.

Pytanie: Czy konieczne jest, aby obie domeny danych pary replikacji korzystały z tego samego zewnętrznego menedżera kluczy (np. menedżera kluczy KMIP), czy też jeden z systemów może korzystać z zewnętrznego menedżera kluczy, a inne mogą korzystać z wbudowanego menedżera kluczy?
Odpowiedź: W przypadku innych niż para replikacji kolekcji nie jest konieczne, aby oba systemy w parze replikacji używały tego samego menedżera kluczy.

W przypadku replikacji kolekcji oba systemy Data Domain muszą być skonfigurowane z tym samym menedżerem kluczy. Jednak i w tym przypadku jedynym źródłem jest synchronizacja kluczy z menedżerem kluczy, a klucze te są również wysyłane do miejsca docelowego. W przypadku innych typów replikacji można używać różnych menedżerów kluczy ze źródłem i obiektem docelowym.

Szyfrowanie i migracja

Pytanie: Czy migracja danych jest obsługiwana w systemach z włączoną funkcją szyfrowania?
Odpowiedź: Tak, migracja danych jest obsługiwana w systemach z włączonym szyfrowaniem. Przed rozpoczęciem migracji danych należy dopasować konfigurację szyfrowania w systemach źródłowych i docelowych jako wymaganie wstępne. Zaleca się również wyeksportowanie i utworzenie kopii zapasowej kluczy szyfrowania w systemie źródłowym dla celów DIA przed rozpoczęciem migracji.

Pytanie: Czy migracja danych jest obsługiwana zarówno w przypadku migracji warstwy aktywnej, jak i warstwy chmury dla systemów z obsługą szyfrowania?
Odpowiedź: Tak, migracja danych jest obsługiwana zarówno w przypadku migracji warstwy aktywnej, jak i migracji warstwy chmury w przypadku systemów z obsługą szyfrowania. Lista wstępnie sprawdzonych atrybutów jest stosowana w zależności od warstwy, w której włączono szyfrowanie.

Pytanie: Które ustawienia szyfrowania są zachowywane w ramach migracji?
Odpowiedź: Zaszyfrowane dane i klucze szyfrowania są migrowane w niezmienionej postaci, ale ustawienia, takie jak menedżer kluczy szyfrowania, hasło systemowe i inne konfiguracje szyfrowania, muszą zostać ręcznie zweryfikowane i dopasowane, aby migracja danych przebiegła pomyślnie. Wszystkie istniejące certyfikaty menedżera kluczy są również przenoszone do systemu docelowego. Po migracji

należy ponownie skonfigurować konfigurację menedżera kluczy szyfrowania w systemie docelowym.Pytanie: Jakie kontrole zgodności szyfrowania między źródłem a obiektem docelowym są wykonywane podczas migracji?
Odpowiedź: Hasło systemowe, stan szyfrowania, szczegóły konfiguracji menedżera kluczy, ustawienia trybu FIPS systemu to tylko niektóre z ustawień szyfrowania, które muszą być identyczne w systemach źródłowych i docelowych, aby migracja zakończyła się pomyślnie. Artykuł bazy wiedzy nr 183040, Data Domain: Procedura migracji systemów DD z włączoną chmurą (aby wyświetlić artykuł wymagane logowanie się do pomocy technicznej firmy Dell) zawiera szczegółowe informacje na temat kroków migracji między systemami z włączoną chmurą. Te same ustawienia dotyczą również migracji tylko warstwy aktywnej.

Pytanie: Czy migracja między systemami jest obsługiwana z włączonym ustawieniem Encryption Disablement Project?
Odpowiedź: Migracja danych jest obsługiwana między dwoma systemami, jeśli oba są EDP lub oba nie są objęte EDP. Migracja danych z systemu EDP do systemu innego niż EDP jest dozwolona, jeśli szyfrowanie przewodowe jest wyraźnie wyłączone. (za pomocą MIGRATION_ENCRYPTION sysparam)

Szyfrowanie w warstwie chmury 

Pytanie: Czy szyfrowanie jest obsługiwane w przypadku warstwy chmury?
Odpowiedź: Tak, szyfrowanie jest obsługiwane na poziomie chmury. Domyślnie szyfrowanie jest wyłączone w warstwie chmury. Wyświetla polecenie "Cloud Enable", które pozwala wybrać, czy chcemy włączyć szyfrowanie w warstwie chmury.

Pytanie: Czy KMIP i zewnętrzne menedżery kluczy są obsługiwane w warstwie chmury?
Odpowiedź: Tak, KMIP i zewnętrzne menedżery kluczy są obsługiwane w warstwie chmury od wersji DDOS 7.8 i nowszych.

Pytanie: Przy jakim stopniu szczegółowości można włączyć szyfrowanie w chmurze?
Odpowiedź: Szyfrowanie można włączać i wyłączać w każdej jednostce chmury i każdej warstwie niezależnie.

Pytanie: Czy jednostki chmurowe mają niezależne klucze?
Odpowiedź: Nie, zarządzanie kluczami jest wspólne zarówno dla warstwy aktywnej, jak i chmurowej w DD. Klucze są kopiowane do odpowiedniej jednostki/poziomu/cp po włączeniu szyfrowania. Jeśli szyfrowanie jest włączone w obszarze aktywnym, a nie w chmurze, klucze warstwy aktywnej nie są odzwierciedlane w chmurze i na odwrót. Dotyczy to również jednostek chmurowych. (Na przykład: CP1 ma włączone szyfrowanie, a CP2 nie ma włączonego szyfrowania, więc klucze CP1 nie są odzwierciedlane w CP2).   

Pytanie: Czy klucze można usunąć w chmurze?
Odpowiedź: Nie, usuwanie kluczy z chmury nie jest obsługiwane.

Pytanie: Gdzie są zarządzane klucze szyfrowania danych dla jednostek w chmurze?
Odpowiedź: Klucze są powiązane z cp, a każda jednostka chmury jest innym cp. Kopia kluczy ze wszystkich cps jest przechowywana w aktywnym cp.

Pytanie: Jak odzyskać klucze chmury podczas odzyskiwania po awarii? 
Odpowiedź: cpnameval jest dublowany w chmurze w ramach odzyskiwania CP, klucze szyfrowania zostaną odzyskane do cpnameval. Teraz musimy uruchomić ddr_key_util narzędzie, aby odzyskać klucze.

Uwaga: Odtwarzanie po awarii wymaga interwencji działu obsługi klienta.

Pytanie: Czy można wykonywać operacje przenoszenia danych, gdy szyfrowanie jest włączone tylko w warstwie chmury?
Odpowiedź: Nie, musimy włączyć szyfrowanie zarówno w warstwie chmurowej, jak i aktywnej na potrzeby przenoszenia danych.

Pytanie: Czy można włączyć zewnętrznego menedżera kluczy w warstwie chmury?
Odpowiedź: Tak, zewnętrzny menedżer kluczy można włączyć w warstwie chmury. Ta funkcja jest obsługiwana w wersji 7.8 i nowszych. Wszystkie operacje z wyjątkiem zniszczenia lub usunięcia klucza, który jest prawidłowy dla warstwy aktywnej, są również ważne dla warstwy chmurowej w zakresie zewnętrznego menedżera kluczy. 

Szyfrowanie i odśmiecanie pamięci

Pytanie: Jaką rolę odgrywa proces Global Cleaning w szyfrowaniu w spoczynku i czy włączenie szyfrowania po raz pierwszy ma wpływ na wydajność?
Odpowiedź: Włączenie szyfrowania danych w stanie spoczynku po raz pierwszy ma wpływ na wydajność globalnego czyszczenia. Dzieje się tak dlatego, że dane, które muszą być odczytane z istniejących kontenerów na dysku i zapisane w nowych kontenerach, mogą wymagać odczytu, odszyfrowania i wypakowania przed ponownym skompresowaniem, zaszyfrowaniem i zapisaniem na dysku. Jeśli szyfrowanie jest włączone na DD przechowującym znaczną ilość wcześniej istniejących danych i uruchamiane jest polecenie "filesys encryption apply-changes", kolejny globalny cykl czyszczenia próbuje zaszyfrować wszystkie istniejące dane w systemie. Oznacza to, że wszystkie dane muszą zostać odczytane, zdekompresowane, skompresowane, zaszyfrowane i zapisane na dysku. W rezultacie pierwszy globalny cykl czyszczenia po uruchomieniu 'filesys encryption apply-changes' może trwać dłużej niż zwykle. Klienci powinni upewnić się, że w systemie DD jest wystarczająca ilość wolnego miejsca, aby można było przeprowadzić czyszczenie bez zapełnienia systemu DD (w przeciwnym razie tworzenie kopii zapasowych nie powiedzie się).

Pytanie: Czy ma wpływ na wydajność trwających cykli czyszczenia/przywracania?
Odpowiedź: Tak, występuje wpływ na wydajność, który zazwyczaj zależy od ilości przyswajanych/przywracanych danych między cyklami czyszczenia.

Pytanie: Jak długo trwa szyfrowanie istniejących danych?
Skorzystaj z tego artykułu bazy wiedzy, aby oszacować czas, Data Domain: Obliczanie czasu stosowania szyfrowania w spoczynku.

Szyfrowanie i zamiana głowicy 

Pytanie: Czy klient może przenieść dysk do innego systemu Data Domain w przypadku awarii głowicy i uzyskać dostęp do dysku, gdy szyfrowanie jest włączone?
Odpowiedź: Klucz szyfrowania nie jest powiązany z samym nagłówkiem systemu Data Domain, można więc przenieść dyski do innego nagłówka systemu Data Domain i tam uzyskać dostęp do klucza. W nowym nagłówku systemu Data Domain system plików jest zablokowany, dlatego należy wprowadzić hasło za pomocą polecenia "filesys encryption unlock". 

Pytanie: Co się stanie, jeśli klient zapomni hasła w czasie operacji headswap?
Odpowiedź: W tym czasie mogą podłączyć starą głowicę i pracować z pomocą techniczną, aby zresetować hasło, a następnie połączyć się z powrotem z nową głowicą i zakończyć procedurę zamiany. 

Wydajność szyfrowania

Pytanie: Jaki jest zaobserwowany wpływ na zużycie pamięci masowej w przypadku korzystania z szyfrowania?
Odpowiedź: Jest to znikome z około 1-procentowym narzutem związanym z przechowywaniem niektórych parametrów szyfrowania z danymi użytkownika.

Pytanie: Jaki jest zaobserwowany wpływ na przepustowość (zapis i odczyt) w przypadku korzystania z szyfrowania danych w spoczynku?
Odpowiedź: Wpływ na przepływność pozyskiwania w przypadku korzystania z szyfrowania może się różnić w zależności od protokołu i platformy. Ogólnie rzecz biorąc, następujące wartości procentowe są konserwatywnymi spadkami wydajności w zagregowanej przepływności:

Tryb
CBC Najpierw zapełniony: ~10% spadek wydajności przy zapisach
przyrostowych: ~5% spadek wydajności przy operacjach WRITE:
Spadek wydajności odczytów

o 5–20% Najpierw zapełniony w trybie
GCM: Spadek wydajności operacji WRITE
o 10–20% Przyrostowe: Spadek wydajności operacji WRITE
o 5–10% Przywraca: Spadek wydajności odczytów o 5–20%

Liczby te są specyficzne dla obciążenia związanego z szyfrowaniem danych w spoczynku (szyfrowanie za pośrednictwem sieci jest rozliczane oddzielnie)
 

Najlepsze procedury

Pytanie: Jakie są najlepsze praktyki dotyczące zasad rotacji kluczy?
Odpowiedź: Zasada automatycznej rotacji kluczy jest domyślnie wyłączona. Klient ją aktywował. Zaleca się częstą rotację kluczy szyfrowania. Jeśli system jest skonfigurowany z zewnętrznym menedżerem kluczy KMIP, zaleca się częstą zmianę kluczy w celu obsługi ewentualnych scenariuszy naruszenia klucza w przyszłości. Jeśli protokół KMIP jest skonfigurowany z warstwą chmury, sugerowany interwał rotacji kluczy wynosi 1 tydzień, a jeśli KMIP jest skonfigurowany tylko w warstwie aktywnej, sugerowana zasada rotacji kluczy wynosi 1 miesiąc. Jednak w zależności od szybkości przyswajania klient może również zwiększyć lub zmniejszyć częstotliwość rotacji kluczy. Jeśli skonfigurowano wbudowany menedżer kluczy, zalecana jest zasada rotacji kluczy w dowolnym miejscu od 1 do 3 miesięcy. 

Pytanie: Jakie są najlepsze praktyki dotyczące klasy kluczy KMIP, jeśli klient używa tego samego serwera KMIP dla wielu systemów DD?
Odpowiedź: Zaleca się posiadanie oddzielnej klasy kluczy dla każdego systemu DD, jeśli używają tego samego serwera KMIP. Dzięki temu rotacja klucza w jednym systemie DDOS nie wpływa na stan klucza obecnego w innym systemie DDOS.

Więcej informacji można znaleźć w dokumencie Urządzenia DELL EMC PowerProtect z serii DD: Oprogramowanie szyfrujące (delltechnologies.com)

Szyfrowanie: Opracowanie techniczne Urządzenia PowerProtect z serii DD: Oprogramowanie

szyfrująceInną dokumentację związaną z szyfrowaniem DD (podręcznik administratora, podręcznik informacyjny dotyczący poleceń i instrukcja konfiguracji zabezpieczeń) można znaleźć w artykułach 126375, podstawowych dokumentów PowerProtect i Data Domain.

Podręcznik integracji KMIP i tabela

zgodnościObejrzyj ten film: