Data Domain: Często zadawane pytania na temat szyfrowania

Podsumowanie: Ten artykuł bazy wiedzy zawiera zbiór często zadawanych pytań (FAQ) na temat szyfrowania danych w spoczynku (DARE) w skonsolidowanej lokalizacji w celu ułatwienia odniesienia.

Produkty, których dotyczy problem

Ten artykuł dotyczy Ten artykuł nie dotyczy Ten artykuł nie jest powiązany z żadnym konkretnym produktem. Nie wszystkie wersje produktu zostały zidentyfikowane w tym artykule.

Sprawdź inne zasoby

Instrukcje

Konfiguracja szyfrowania

Pytanie: Jak skonfigurowano szyfrowanie danych w spoczynku (DARE) w Data Domain?

Odpowiedź: Program DARE można skonfigurować, wykonując następujące czynności:

Dodaj licencję szyfrowania.
1. Dodać plik licencji z ważną licencją szyfrowania.
2. Użyj poniższego polecenia, aby zaktualizować licencję elektroniczną w Data Domain przy użyciu dostępnego pliku licencji:
```
# elicense update
```
Dodaj przedstawiciela działu zabezpieczeń i włącz jego uprawnienia.
1. Dodaj użytkownika z rolą "security" (jeśli jeszcze nie istnieje) za pomocą polecenia:
```
# user add <username> role security
```
2. Włącz autoryzację dyrektora ds. bezpieczeństwa, logując się jako dyrektor ds. bezpieczeństwa i uruchamiając polecenie:
```
> authorization policy set security-officer enabled
```
Przełącz się z powrotem na konto administratora i włącz DARE, uruchamiając polecenie:
```
# filesys encryption enable
```

Pytanie: Które platformy są obsługiwane przez DARE?

Odpowiedź: Funkcja DARE jest obsługiwana we wszystkich systemach Data Domain z wyjątkiem systemów Encryption Disablement Project (EDP).

Pytanie: Jak przechowywać dane w postaci zwykłego tekstu w Data Domain?

Odpowiedź: Użytkownicy mogą upewnić się, że dane są zapisywane w postaci zwykłego tekstu, a nie szyfrowane w systemie Data Domain, potwierdzając, że szyfrowanie jest wyłączone w konfiguracji.

Szyfrowanie można wyłączyć w Data Domain za pomocą polecenia:

# filesys encryption disable

Pytanie: Które aplikacje i protokoły do tworzenia kopii zapasowych są obsługiwane przez DARE?

Odpowiedź: Funkcja DARE jest niezależna od bazowej aplikacji do tworzenia kopii zapasowych lub protokołu używanego przez Data Domain.

Pytanie: Jakich algorytmów szyfrowania można użyć?

Odpowiedź: Oprogramowanie szyfrujące Data Domain obsługuje 128- lub 256-bitowe algorytmy AES wykorzystujące Cipher Block Chaining (CBC) lub tryb 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 (XOR) 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żna zmienić algorytm szyfrowania?

Odpowiedź: Użyj poniższego polecenia, aby ustawić określony algorytm szyfrowania:

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

Pytanie: Jak upewnić się, że szyfrowanie jest wykonywane na istniejących danych po włączeniu szyfrowania?

Odpowiedź: Możemy zmusić system plików Data Domain do szyfrowania 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?

Odpowiedź: Wyłącz funkcję szyfrowania w Data Domain za pomocą następującego polecenia:

# filesys encryption disable

Wyłącza to tylko szyfrowanie danych przychodzących. Istniejące zaszyfrowane dane pozostają zaszyfrowane, dopóki nie zostaną ręcznie odszyfrowane za pomocą polecenia 'filesys encryption apply-changes'.

Pytanie: Które polecenia szyfrowania wymagają ponownego uruchomienia systemu plików, aby odniosły skutek?

Odpowiedź: Następujące polecenia szyfrowania wymagają ponownego uruchomienia systemu plików, aby odniosły skutek:

filesys encryption enable|disable - Umożliwia włączanie i wyłączanie szyfrowania w Data Domain.
filesys encryption algorithm set - Umożliwia użytkownikowi wybór algorytmu kryptograficznego.
filesys encryption algorithm reset - Resetuje algorytm szyfrowania do AES 256 w trybie CBC (domyślny).

Pytanie: Które polecenia szyfrowania wymagają wyłączenia systemu plików w celu ich ustawienia lub używania?

Odpowiedź: System plików Data Domain musi być wyłączony, aby można było ustawić lub korzystać z następujących poleceń szyfrowania:

encryption passphrase change
encryption lock|unlock

Ogólne pytania dotyczące szyfrowania

Pytanie: Czy rozwiązanie DARE jest obsługiwane we wszystkich systemach Data Domain?

Odpowiedź: Opcja oprogramowania DARE jest obsługiwana w systemach Data Domain, które nie są częścią projektu wyłączenia szyfrowania (EDP). Systemy, które nie pozwalają na włączenie szyfrowania i są sprzedawane w regionie Rosji.

Pytanie: W jaki sposób kryptografia jest wykonywana w systemach Data Domain?

Odpowiedź: Kryptografia jest wykonywana przy użyciu bibliotek OpenSSL i RSA BSafe. RSA BSafe to biblioteka kryptograficzna zweryfikowana pod kątem standardu FIPS 140-2.

Pytanie: Z jakiej wersji BSafe korzysta Data Domain?

Odpowiedź: W wersji DDOS 7.10 używane wersje BSafe to "BSAFE Micro Edition Suite 4.4.0.0”, jak 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ć za pomocą wiersza poleceń, interfejsu internetowego lub interfejsów API REST. Obsługa interfejsu API REST została dodana w wersji 8.0 DDOS.

Pytanie: Czy 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 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ź: Nie.

Pytanie: Z jakiej wersji OpenSSL korzysta Data Domain?

Odpowiedź: W wersji DDOS 7.10 wersja OpenSSL to "OpenSSL 1.0.2zd-fips”.

Pytanie: W jaki sposób DARE 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 Data Domain, ale wszystkie dane fizycznie znajdujące się w 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 Data Domain jest zaprojektowane w taki sposób, że jeśli intruz obejdzie inne mechanizmy kontroli bezpieczeństwa sieci i uzyska dostęp do zaszyfrowanych danych, dane te będą nieczytelne i bezużyteczne dla tej osoby bez odpowiednich kluczy kryptograficznych.

Pytanie: Czy szyfrowanie następuje po deduplikacji?

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 DARE. 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 nie można dodać kolejnych kluczy do systemu
W przypadku niepowodzenia automatycznego eksportowania kluczy
Gdy automatyczna rotacja klawiszy 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 DDOS.

Pytanie: Jeśli ktoś wyciągnie dysk twardy z Data Domain, czy może odszyfrować z niego dane?

Odpowiedź: Klucze szyfrowania są szyfrowane przy użyciu hasła systemowego, które jest przechowywane w nagłówku systemu. Mimo że klucze szyfrowania są przechowywane na dysku, nie można ich odszyfrować bez hasła systemowego. 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 wyeksportować do bezpiecznego pliku i przechowywać zewnętrznie w systemie. Odzyskiwanie tego pliku odbywa się za pomocą inżynierii. Ponadto w momencie odzyskiwania klient musi znać hasło, które zostało użyte przy użyciu polecenia eksportu kluczy.

Pytanie: W jaki sposób można zablokować system plików przed przeniesieniem go do innej lokalizacji?

Odpowiedź: Poniżej przedstawiono procedurę blokowania systemu:

Wyłącz system plików:
```
# filesys disable
```

Zablokuj system plików i wprowadź nowe hasło (wymaga to uwierzytelnienia za pomocą użytkownika zabezpieczeń):

# filesys encryption lock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
        Username: secuser
        Password:
Enter the current passphrase:
Enter new passphrase:
Re-enter new passphrase:
Passphrases matched.
The filesystem is now locked.

Nowe hasło NIE może zostać utracone ani zapomniane. Bez tego hasła nie można odblokować systemu plików, co oznacza, że dane w Data Domain są niedostępne.

Aby odblokować system po dotarciu do odległej lokalizacji, użyj poniższego polecenia:

# filesys encryption unlock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
        Username: secuser
        Password:
Enter the passphrase:
The passphrase has been verified. Use 'filesys enable' to start the filesystem.

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

Pytanie: Czy "`storage sanitize`' ma jakiś 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 over-the-wire jest obsługiwane w przypadku systemów EDP?

Odpowiedź: Szyfrowanie DARE i over-the-wire nie są obsługiwane w przypadku systemów EDP.

Hasło systemowe

Pytanie: Co to jest hasło systemowe?

Odpowiedź: DDOS może zabezpieczyć poświadczenia w systemie, ustawiając hasło na poziomie systemu. Hasło to klucz czytelny 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 pudełko zostanie skradzione podczas transportu, osoba atakująca nie może 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. Dzięki temu system Data Domain może się uruchomić i kontynuować zapewnianie 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 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 Data Domain. Oznacza to, że żaden pojedynczy administrator nie może samodzielnie wprowadzać zmian.

Pytanie: Kiedy jest używane hasło?

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

Pytanie: W jaki sposób hasło jest używane do bezpiecznego transportu domeny danych?

Odpowiedź: Proces ten wykorzystuje metodę "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ą przycisku "filesys encryption unlock' polecenie.

Proces ten opisano w przewodnikach konfiguracji zabezpieczeń Data Domain.

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 sprawdzić, czy w systemie ustawiono hasło?

Odpowiedź: Jeśli w systemie ustawiono hasło, uruchomienie "system passphrase set' zgłasza błąd wskazujący, ż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 mechanizm resetowania utraconego 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 można znaleźć w tym artykule: Data Domain: Resetowanie utraconego hasła systemowego w systemie DDOS w wersji 7.2 lub nowszej (wymagane logowanie do pomocy technicznej firmy Dell).

Pytanie: Czy istnieje możliwość uniknięcia przechowywania hasła systemowego w Data Domain?

Odpowiedź: Hasło systemowe jest domyślnie przechowywane w ukrytej lokalizacji w systemie Data Domain. Polecenie 'system passphrase option store-on-disk' można użyć do zmiany tego stanu rzeczy i uniknięcia przechowywania hasła na dysku.

Wbudowany menedżer kluczy (EKM)

Polecenie najwyższego poziomu:

# filesys encryption embedded-key-manager <option>

Pytanie: Czy EKM obsługuje rotację 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. Jest ona dostępna w ramach opcji standardowej licencji oprogramowania Data Domain Encryption.

Pytanie: Czy można przełączyć się z lokalnego na zewnętrzne zarządzanie kluczami?

Odpowiedź: Tak, zewnętrzne menedżery kluczy można włączyć w dowolnym momencie. Używane klucze lokalne pozostają jednak w Data Domain. Zewnętrzny menedżer kluczy nie może zarządzać kluczami lokalnymi. Istniejące dane nie wymagają ponownego szyfrowania. Jeśli dane zgodności muszą być ponownie zaszyfrowane za pomocą kluczy EKM, należy to zrobić ręcznie za pomocą "filesys encryption apply-changes' z nowym RW . Niszczenie kluczy EKM po przełączniku nie jest obowiązkowe.

Zmiana menedżera kluczy powoduje automatyczne przełączenie aktywnego klucza na klucz z 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 klawiszy jest wyłączona lub włączona?

Odpowiedź: Obracanie klawiszy jest domyślnie wyłączone. W takim przypadku wszystkie dane są szyfrowane przy użyciu istniejącego aktywnego klucza. Jeśli obracanie kluczy jest włączone, dane są szyfrowane przy użyciu najnowszego aktywnego klucza zgodnie ze skonfigurowaną częstotliwością rotacji.

Zewnętrzni menedżerowie kluczy

Pytanie: Jakie zewnętrzne menedżery kluczy obsługuje Data Domain?

Odpowiedź: Data Domain obsługuje następujące zewnętrzne menedżery 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 menedżera kluczy z Data Domain wymagana jest oddzielna licencja od odpowiedniego dostawcy.

Pytanie: Ilu kluczowych menedżerów można wykorzystać jednocześnie?

Odpowiedź: W danym momencie w Data Domain może być aktywny tylko jeden menedżer kluczy.

Pytanie: Gdzie można znaleźć więcej informacji na temat konfiguracji zewnętrznych menedżerów 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 Data Domain.

Pytanie: W jaki sposób zarządzane są certyfikaty dla zewnętrznych menedżerów kluczy w Data Domain?

Odpowiedź: Konfiguracja zewnętrznego menedżera kluczy wymaga wygenerowania certyfikatu CA (który może być podpisany samodzielnie lub podpisany przez inną firmę) oraz certyfikatu hosta. Po zakończeniu konfiguracji na zewnętrznym serwerze menedżera kluczy należy zaimportować certyfikat CA i certyfikat hosta do systemu Data Domain. Następnie można skonfigurować i włączyć zewnętrzny menedżer kluczy.

Pytanie: Co to jest urząd certyfikacji?

Odpowiedź: Urząd certyfikacji (CA) działa jako początkowo zaufana jednostka udostępniona 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 instytucję certyfikującą? Co to jest certyfikat podpisany przez lokalny 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ą jest automatycznie uznawany za zaufany. Lokalny urząd certyfikacji może wystawiać podpisane certyfikaty, ponieważ prywatny klucz podpisywania jest przechowywany w systemie menedżera kluczy. 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ć żądanie podpisania certyfikatu w Data Domain?

Odpowiedź: Żądanie podpisania certyfikatu (CSR) Data Domain można wygenerować za pomocą poniższego polecenia. W ten sposób klucz prywatny nigdy nie jest udostępniany zewnętrznemu menedżerowi kluczy.

# adminaccess certificate cert-signing-request

Pytanie: Czy można przełączać się między kluczowymi menedżerami?

Odpowiedź: Przełączanie z zewnętrznego menedżera kluczy na wbudowany menedżer kluczy jest dozwolone i przebiega bezproblemowo. Przełączenie się z wbudowanego menedżera kluczy na zewnętrzne menedżery kluczy wymaga jednak 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) jest również dozwolone. Obsługiwana jest również migracja kluczy (więcej informacji można znaleźć w Podręczniku integracji KMIP ).

Pytanie: Co się stanie, gdy połączenie zewnętrznego menedżera kluczy zostanie przerwane? Czy moje dane są nadal dostępne?

Odpowiedź: Tak, dane są nadal dostępne, gdy nie możemy połączyć się z menedżerem kluczy, ponieważ kopia kluczy jest również przechowywana w Data Domain. Nie można tworzyć nowych kluczy ani synchronizować stanów kluczy w przypadku braku łączności z zewnętrznym menedżerem kluczy.

Pytanie: Czy istnieje sposób przechowywania kluczy tylko w zewnętrznym menedżerze kluczy, a nie w Data Domain?

Odpowiedź: Kopia kluczy jest zawsze przechowywana w systemie Data Domain na potrzeby architektury DIA (Data Invulnerability Architecture). Tego ustawienia nie można zmienić.

Pytanie: Czy integracja z KMIP ma jakiś 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 domen danych. Mogą nadal korzystać z wbudowanego menedżera kluczy Data Domain w niektórych systemach oraz rotacji kluczy szyfrowania przy użyciu protokołu KMIP w innych systemach w ich ś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. Interfejs CLI Data Domain może służyć do importowania odpowiedniego certyfikatu X509 do systemu Data Domain. Certyfikat ten jest następnie używany do ustanowienia bezpiecznego kanału między Data Domain a KMIP.

Zarządzanie cyklem życia kluczy

Pytanie: Jakie możliwości zarządzania kluczami są dostępne w przypadku szyfrowania Data Domain?

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 zgodnego z 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 skutkuje dodaniem nowego klucza do systemu. W wersji DDOS 7.1 nie jest wymagane ponowne uruchomienie systemu plików.

Pytanie: Jakie są różne stany kluczy w Data Domain?

Poszczególne kluczowe stany w Data Domain są następujące:

Activated-RW: W danym momencie w Data Domain znajduje się tylko jeden klucz i służy on do odczytu i zapisu danych. Ten klucz jest również używany przez proces wyrzucania elementów bezużytecznych do ponownego szyfrowania kontenerów.
Pending-Activated: W danym momencie w Data Domain znajduje się tylko jeden klucz w tym stanie. W ten sposób określono klucz, który stanie się Activated-RW Po następnym ponownym uruchomieniu systemu plików. Ten stan istnieje tylko w momencie włączenia szyfrowania. Pending-activated Klucze nie są tworzone w żadnym innym czasie.
Activated-RO: Zewnętrzne menedżery kluczy mogą mieć wiele aktywowanych kluczy. Najnowszy klucz jest w Activated-RW, a pozostałe są w tym stanie. Klucze mogą przejść w ten stan w Data Domain, ale nie można zsynchronizować stanu z menedżerem kluczy.
Deactivated: Służy do odczytywania istniejących danych w systemie Data Domain.
Compromised: Gdy zewnętrzny klucz menedżera kluczy zostanie naruszony, zmieni się on na ten stan po następnej synchronizacji klucza.
Marked-For-Destroyed: Gdy klient oznaczy klucz do zniszczenia, klucz zmieni się do tego stanu. Po uruchomieniu wyrzucania elementów bezużytecznych wszystkie kontenery zaszyfrowane za pomocą Marked-For-Destroyed klucze są ponownie szyfrowane przy użyciu Activated-RW .
Destroyed: Klucz w Marked-For-Destroyed stan przechodzi w ten stan, gdy nie są z nim skojarzone żadne dane.
Destroyed-compromised: Klucz w Compromised stan 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.

# filesys encryption keys export

System Data Domain domyślnie eksportuje również klucze po dodaniu nowego klucza lub usunięciu dowolnego klucza z systemu.

Wyeksportowane pliki znajdują się w folderze /ddr/var/.security w zaszyfrowanym formacie. Plik ten można skopiować z Data Domain i przechowywać w bezpiecznej lokalizacji w celu późniejszego użycia w warunkach odtwarzania po awarii.

Uwaga: Importowanie kluczy w celu 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 Data Domain?

Odpowiedź: Tak, klucz szyfrowania uzyskany z KMIP jest przechowywany w sposób zaszyfrowany w Data Domain.

Pytanie: W jaki sposób zmiana stanu klucza w urządzeniu KMIP jest stosowana do Data Domain?

Odpowiedź: Synchronizacja kluczy odbywa się codziennie. Jeśli dostępny jest nowy klucz lub jego stan ulegnie zmianie, synchronizacja zaktualizuje tabelę kluczy lokalnych. System Data Domain codziennie o północy otrzymuje kluczowe aktualizacje z KMIP.

Pytanie: Czy można ręcznie zsynchronizować stany kluczy między Data Domain a 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 Data Domain i KMIP. Polecenie na to brzmi 'filesys encryption keys sync'.

Pytanie: Czy można zmienić godzinę, o której Data Domain otrzymuje kluczowe aktualizacje z KMIP?

Odpowiedź: Nie, nie można zmienić godziny, o której Data Domain otrzymuje aktualizacje kluczy z KMIP.

Pytanie: Czy istnieje ograniczenie liczby kluczy przechowywanych w Data Domain?

Odpowiedź: Począwszy od DDOS 7.8, system Data Domain może mieć maksymalnie 1024 klucze. W pliku jest tylko jeden klucz Activated-RW Państwa; Wszystkie 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 Data Domain?

Odpowiedź: Nie, Data Domain obsługuje w danej chwili tylko jeden aktywny klucz w systemie. Wszystkie przychodzące dane są szyfrowane przy użyciu bieżącego aktywnego klucza. Kluczami nie można sterować z drobniejszym stopniem szczegółowości (np. dla mtree).

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 usunąć alert o maksymalnym limicie kluczy?

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

Pytanie: Czy widzisz ilość danych skojarzonych z określonym kluczem w Data Domain?

Odpowiedź: Tak, widać to w Data Domain, ale nie widać tego na serwerze KMIP. Interfejs wiersza poleceń Data Domain i interfejs użytkownika umożliwiają użytkownikowi wyświetlenie ilości danych skojarzonych z określonym kluczem. Polecenie na to brzmi 'filesys encryption keys show summary'.

Pytanie: Czy widzisz wiek kluczy w Data Domain?

Odpowiedź: Tak, można to zobaczyć dla kluczy EKM za pomocą interfejsu użytkownika.

Pytanie: Czy stary klucz działa, nawet jeśli upłynął okres obowiązywania nowego klucza?

Odpowiedź: Nie ma daty wygaśnięcia kluczy szyfrowania. Stare klucze stają się dostępne tylko do odczytu po obróceniu klucza i pozostają w DDOS.

Pytanie: Czy klucze szyfrowania są automatycznie usuwane, gdy w Data Domain nie są z nimi skojarzone żadne dane?

Odpowiedź: Nie, klucz nie jest automatycznie usuwany. Użytkownik musi jawnie usunąć klucz za pomocą interfejsu wiersza polecenia lub interfejsu użytkownika Data Domain.

Pytanie: Czy klucz można usunąć, nawet jeśli w Data Domain są z nim skojarzone dane?

Odpowiedź: Nie, jeśli z kluczem są powiązane jakiekolwiek dane, nie można go usunąć. Aby usunąć klucz, z którym są powiązane dane, dane należy ponownie zaszyfrować za pomocą innego klucza.

Pytanie: Jeśli klucz zostanie usunięty z KMIP, czy klucz zostanie również usunięty z listy kluczy Data Domain?

Odpowiedź: Nie, użytkownik musi niezależnie usunąć klucz przy użyciu interfejsu wiersza polecenia lub interfejsu użytkownika Data Domain.

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. Do wszystkich z nich można wykorzystać jeden serwer KMIP. Zaleca się posiadanie oddzielnej klasy kluczy dla każdego systemu Data Domain, jeśli używają one tego samego serwera KMIP.

Pytanie: Jeśli klucz zostanie naruszony, czy istnieje proces pobierania danych zaszyfrowanych przy użyciu starego klucza?

Odpowiedź: W takim przypadku klient musi oznaczyć klucz jako zagrożony na serwerze KMIP. Następnie w Data Domain:

Uruchom 'filesys encryption keys sync'.
Uruchom 'filesys encryption apply-changes'.
Rozpocznij czyszczenie systemu plików.
1. Czyszczenie powoduje ponowne zaszyfrowanie wszystkich danych, które zostały zaszyfrowane przy użyciu naruszonego klucza przy użyciu nowszego klucza.
2. Po zakończeniu czyszczenia stary stan klucza zostanie zmieniony na: Compromised-Destroyed.
Usuń stary klucz.

Szyfrowanie i replikacja

Pytanie: Czy replikacja Data Domain jest obsługiwana i współdziałać z DARE?

Odpowiedź: Tak, replikacji Data Domain można używać z rozwiązaniem DARE. Umożliwia to replikację zaszyfrowanych danych przy użyciu różnych rodzajów replikacji. Każdy typ replikacji działa unikatowo z szyfrowaniem i oferuje ten sam poziom bezpieczeństwa.

Pytanie: Czy w systemach źródłowym i docelowym musi być uruchomiona ta sama wersja DDOS, 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 są one zgodne z replikacją (zobacz Data Domain Administration Guide aby uzyskać macierz zgodności).

Pytanie: Jak replikacja działa z szyfrowaniem?

Odpowiedź: To zależy od używanej formy replikacji.

Jeśli skonfigurowana replikacja to mtree replication (MREPL) lub Managed File Replication (MFR):

DARE 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 źródle 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.
Gdy źródło ma wyłączone szyfrowanie, a miejsce docelowe ma włączone szyfrowanie:
- Dane pozyskane w źródle nie są szyfrowane.
- 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:
- Dane pozyskane w systemie źródłowym są szyfrowane przy użyciu klucza szyfrowania systemu źródłowego.
- Źródło odszyfrowuje dane, a następnie replikuje niezaszyfrowane dane do systemu docelowego.
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 niezaszyfrowanym, chyba że zostaną zastosowane zmiany i zostanie uruchomione czyszczenie w miejscu docelowym.

Jeśli skonfigurowana replikacja to replikacja kolekcji (CREPL):

Na systemach źródłowych i docelowych musi być uruchomiona ta sama wersja DDOS.
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 systemu docelowego w stanie zaszyfrowanym.
- Miejsce docelowe ma taki sam klucz jak źródło, ponieważ replikacja kolekcji dotyczy dokładnej repliki systemu źródłowego.
- Nie można zapisać żadnych danych w obiekcie docelowym poza replikacją, ponieważ miejsce docelowe jest systemem tylko do odczytu.
Jeśli szyfrowanie jest wyłączone zarówno dla źródła, jak i miejsca docelowego:
- Dane pozyskiwane w systemie źródłowym nie są szyfrowane.
- Podczas replikacji źródło wysyła dane w stanie niezaszyfrowanym i pozostają one niezaszyfrowane w miejscu docelowym.
- Nie można zapisać żadnych danych w obiekcie docelowym poza replikacją, ponieważ miejsce docelowe jest systemem tylko do odczytu.

Pytanie: Czy klucz miejsca docelowego jest przechowywany bezterminowo w źródłowej 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 typów replikacji z wyjątkiem replikacji kolekcji. W replikacji kolekcji ten sam zestaw kluczy szyfrowania jest obecny zarówno w źródle, jak i w obiekcie docelowym.

Pytanie: Czy po ustanowieniu kontekstu replikacji kolekcji można włączyć szyfrowanie w systemie replikacji kolekcji?

Odpowiedź: Tak, w takim przypadku szyfrowanie musi być włączone zarówno w źródle, jak i w obiekcie docelowym. Aby można było skonfigurować szyfrowanie, należy wyłączyć 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 funkcję DARE można włączyć jednocześnie z funkcją szyfrowania przewodowego dla replikacji Data Domain?

Odpowiedź: Tak, zarówno szyfrowanie over-the-wire (OTW), jak i DARE mogą być włączone jednocześnie, aby osiągnąć różne cele bezpieczeństwa.

Pytanie: Co się stanie, jeśli zarówno szyfrowanie DARE, jak i OTW są włączone jednocześnie?

Odpowiedź: Źródło najpierw szyfruje dane przy użyciu docelowego klucza szyfrowania. Następnie, już zaszyfrowane dane są szyfrowane po raz drugi przez OTW podczas wysyłania tych danych do miejsca docelowego. W miejscu docelowym, po zakończeniu odszyfrowywania OTW, dane są przechowywane w zaszyfrowanym formacie, który został zaszyfrowany przy użyciu klucza szyfrowania miejsca docelowego.

Pytanie: Czy jeśli szyfrowanie jest włączone zarówno w obiekcie źródłowym, jak i docelowym, muszą one mieć to samo hasło?

Odpowiedź: Jeśli skonfigurowana replikacja to replikacja kolekcji, hasło musi być takie samo. W przypadku innych rodzajów replikacji (takich jak MREPL, MFR) systemy mogą mieć różne hasła.

Pytanie: Czy po włączeniu szyfrowania w obiekcie docelowym zarówno zreplikowane dane, jak i dane z innego punktu dostępu (np. za pośrednictwem lokalnej kopii zapasowej) są szyfrowane? Czy istnieje sposób na rozdzielenie tych dwóch katalogów w miejscu docelowym, tak aby szyfrowane były tylko zreplikowane katalogi?

Odpowiedź: Nie, wszystkie dane są szyfrowane w miejscu docelowym, niezależnie od punktu wejścia. Szyfrowanie nie może być włączane lub wyłączane tylko z poziomem szczegółowości mtree lub katalogu. Nie dotyczy to CREPL.

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 obiekt 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 Data Domain.

Pytanie: Jakiego typu algorytmu używa szyfrowanie OTW do szyfrowania ruchu replikacyjnego?

Odpowiedź: Gdy tryb uwierzytelniania replikacji jest ustawiony na "jednokierunkowy" lub "dwukierunkowy", wymiana kluczy sesji jest używana do efemerycznego trybu Diffie-Hellmana (DHE). 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.

"Jednokierunkowy" oznacza, że certyfikowany jest tylko certyfikat docelowy. "Dwukierunkowy" oznacza, że zweryfikowane są zarówno certyfikaty źródłowe, jak i docelowe. Przed użyciem tego 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. W takim przypadku źródło i miejsce docelowe nie uwierzytelniają się nawzajem przed wymianą kluczy. "Anonimowy" jest używany domyślnie, jeśli tryb uwierzytelniania nie jest określony.

Pytanie: Czy rotacja kluczy bez ponownego uruchomienia systemu plików działa ze wszystkimi typami replikacji?

Odpowiedź: Rotacja kluczy bez ponownego uruchamiania systemu plików działa ze wszystkimi typami replikacji z wyjątkiem replikacji katalogu (która nie jest już obsługiwana) i replikacji różnicowej (znanej również jako optymalizacja o niskiej przepustowości lub 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 dwie domeny 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 oba systemy w parze replikacji muszą korzystać z tego samego zewnętrznego menedżera kluczy (takiego jak menedżer kluczy KMIP), czy też jeden z systemów może korzystać z zewnętrznego menedżera kluczy, a inne z wbudowanego menedżera kluczy?

Odpowiedź: Oprócz replikacji kolekcji nie jest konieczne, aby oba systemy w parze replikacji korzystały z tego samego menedżera kluczy.

W przypadku replikacji kolekcji oba systemy Data Domain muszą być skonfigurowane z tym samym menedżerem kluczy. Jednak tylko źródło synchronizuje klucze 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ą DARE?

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 zarówno w warstwie aktywnej, jak i w warstwie chmury jest obsługiwana przy włączonej infrastrukturze DARE?

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 sprawdzonych atrybutów wymagań wstępnych 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, 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 Key Manager 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 systemu, stan szyfrowania, szczegóły konfiguracji menedżera kluczy i 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. Ten artykuł, Data Domain: Procedura migracji systemów DD z obsługą chmury (wymagane logowanie 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 warstwy aktywnej.

Pytanie: Czy migracja między systemami EDP jest obsługiwana?

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, jeśli szyfrowanie OTW jest wyraźnie wyłączone za pomocą przycisku MIGRATION_ENCRYPTION parametr systemu.

Szyfrowanie i warstwa chmury

Pytanie: Czy szyfrowanie jest obsługiwane w przypadku warstwy chmury?

Odpowiedź: Tak, szyfrowanie jest obsługiwane w przypadku warstwy chmury. Domyślnie opcja ta jest wyłączona. Znak "cloud enable' wyświetla monit o określenie, czy 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 Data Domain. Gdy szyfrowanie jest włączone, klucze są kopiowane na odpowiednią partycję jednostki, warstwy lub kolekcji. Jeśli szyfrowanie jest włączone w obszarze aktywnym, a nie w chmurze, klucze warstwy aktywnej nie są odzwierciedlane w chmurze i odwrotnie. Dotyczy to również jednostek chmurowych. Na przykład: jeśli nie ustawiono cp1 ma włączone szyfrowanie, oraz cp2 nie ma włączonego szyfrowania, to cp1 Klawisze nie są odzwierciedlane cp2.

Pytanie: Czy klucze można usunąć z chmury?

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 collection partition (CP), a każda jednostka chmury jest innym CP. Kopia kluczy ze wszystkich CP jest przechowywana na aktywnej partycji.

Pytanie: Jak odzyskać klucze w chmurze podczas odzyskiwania po awarii?

Odpowiedź: Pakiet cpnameval jest kopiowany do chmury w ramach odzyskiwania CP, a klucze szyfrowania są odzyskiwane do cpnameval. Następnie, ddr_key_util służy do odzyskiwania kluczy.

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

Pytanie: Czy ruch danych może być uruchamiany, gdy szyfrowanie jest włączone tylko dla warstwy chmury?

Odpowiedź: Nie, szyfrowanie musi być włączone zarówno w warstwie chmurowej, jak i aktywnej, aby można było uruchomić ruch danych.

Pytanie: Czy zewnętrzny menedżer kluczy może być używany z warstwą chmury?

Odpowiedź: Tak, zewnętrzny menedżer kluczy może być używany z warstwą chmury. Ta funkcja jest obsługiwana począwszy od wersji DDOS 7.8. Wszystkie operacje (z wyjątkiem zniszczenia lub usunięcia klucza używanego dla warstwy aktywnej) są również prawidłowe dla warstwy chmury w zakresie zewnętrznego menedżera kluczy.

Szyfrowanie i odśmiecanie pamięci

Pytanie: Jaką rolę odgrywa proces odśmiecania pamięci (GC) w DARE? Czy po włączeniu szyfrowania po raz pierwszy występuje wpływ na wydajność?

Odpowiedź: Włączenie narzędzia DARE po raz pierwszy ma wpływ na wydajność GC. Po uruchomieniu GC odczytuje dane z istniejących kontenerów na dysku i zapisuje je w nowych kontenerach. Po włączeniu narzędzia DARE dane te mogą wymagać odczytu, odszyfrowania i wypakowania przed ponownym skompresowaniem, zaszyfrowaniem i zapisaniem na dysku. Gdy szyfrowanie jest włączone w Data Domain przechowującej znaczną ilość wcześniej istniejących danych, a "filesys encryption apply-changes', następny cykl GC spróbuje zaszyfrować wszystkie dane znajdujące się w systemie. Oznacza to, że wszystkie dane muszą zostać odczytane, zdekompresowane, skompresowane, zaszyfrowane i zapisane na dysku. W rezultacie, pierwszy GC po uruchomieniu 'filesys encryption apply-changes' może potrwać dłużej niż zwykle. Upewnij się, że w systemie Data Domain jest wystarczająca ilość wolnego miejsca, aby można było przeprowadzić czyszczenie bez zapełnienia systemu Data Domain (w przeciwnym razie tworzenie kopii zapasowych nie powiedzie się).

Pytanie: Czy bieżące cykle czyszczenia mają wpływ na wydajność?

Odpowiedź: Tak, występuje wpływ na wydajność. Wpływ zazwyczaj zależy od ilości danych przyswajanych i przywracanych między cyklami czyszczenia.

Pytanie: Jak długo trwa szyfrowanie istniejących danych?

Skorzystaj z tego artykułu, aby oszacować czas: Data Domain: Obliczanie czasu stosowania szyfrowania w spoczynku.

Szyfrowanie i zamiana głowicy

Pytanie: Jeśli Data Domain ze skonfigurowanym DARE zostanie poddany zamianie, czy dyski będą nadal dostępne w nowej jednostce głównej?

Odpowiedź: Klucz szyfrowania nie jest powiązany z samym nagłówkiem systemu Data Domain, więc dyski można przenieść do innego nagłówka Data Domain, a klucz jest nadal dostępny w tym nagłówku. System plików jest zablokowany na nowej głowicy i należy go odblokować za pomocą polecenia "filesys encryption unlock' i hasło systemowe.

Pytanie: Co się stanie, jeśli hasło zostanie utracone w czasie operacji zamiany?

Odpowiedź: W przypadku utraty hasła podłącz starą głowicę i współpracuj z pomocą techniczną, aby zresetować hasło. Następnie podłącz z powrotem do nowej głowicy i zakończ procedurę zamiany.

Szyfrowanie i wydajność

Pytanie: Jaki jest zaobserwowany wpływ korzystania z DARE na zużycie pamięci masowej?

Odpowiedź: Wpływ na zużycie pamięci masowej jest znikomy, z około 1% narzutu związanego z przechowywaniem niektórych parametrów szyfrowania z danymi użytkownika.

Pytanie: Jaki jest zaobserwowany wpływ na przepływność (zapisy i odczyty) w przypadku korzystania z narzędzia DARE?

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 to konserwatywne spadki wydajności w zagregowanej przepływności:

Tryb CBC

Pierwsze pełne: ~10% spadek wydajności przy zapisie
Przyrostowe: ~5% spadek wydajności przy zapisie
Przywraca: Spadek wydajności odczytów o 5–20%

Tryb GCM

Pierwsze pełne: Spadek wydajności przy zapisie o 10–20%
Przyrostowe: Spadek wydajności przy zapisie o 5–10%
Przywraca: Spadek wydajności odczytów o 5–20%

Liczby te są specyficzne dla narzutu związanego z szyfrowaniem danych magazynowanych. Szyfrowanie za pośrednictwem przewodu jest rozliczane oddzielnie.

Najlepsze praktyki

Pytanie: Jakie są najlepsze praktyki dotyczące zasad rotacji kluczy?

Odpowiedź: Zasada automatycznej rotacji kluczy jest domyślnie wyłączona. 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 klucza jest cotygodniowy. Jeśli protokół KMIP jest skonfigurowany tylko dla warstwy aktywnej, sugerowana zasada rotacji kluczy to co miesiąc. Można to jednak zwiększyć lub zmniejszyć w zależności od szybkości spożycia. Jeśli wbudowany menedżer kluczy jest skonfigurowany, zalecane są zasady rotacji kluczy z okresu od 1 do 3 miesięcy.

Pytanie: Jakie są najlepsze praktyki dotyczące klasy kluczy KMIP, jeśli ten sam serwer KMIP jest używany dla wielu domen danych?

Odpowiedź: Zaleca się posiadanie oddzielnej klasy kluczy dla każdej domeny danych, jeśli korzystają one z tego samego serwera KMIP. Dzięki temu rotacja klucza w jednym systemie nie wpłynie na stan klucza w innych systemach.

Dodatkowe informacje

Inną dokumentację związaną z szyfrowaniem Data Domain (Podręcznik administratora, Podręcznik informacyjny polecenia i Przewodnik konfiguracji zabezpieczeń) można znaleźć tutaj: Dokumenty podstawowe PowerProtect i Data Domain

Obejrzyj ten film: