Szyfrowanie za pomocą klastra AlwaysOn

Question

Mam bazę danych przeniesioną ze starej instancji SQL Server 2008R2 do klastra AlwaysOn programu SQL Server 2012. Istnieje kilka pól w bazie danych, które są szyfrowane za pomocą SQL Servers wbudowanych funkcji szyfrowania (klucz główny, cert, klucz symetryczny).

Uruchomiłem następujące polecenia w mojej instancji QA AO (te same kroki, które zostały uruchomić na starym serwerze):

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'password' 

CREATE CERTIFICATE myCert 
    WITH SUBJECT = 'password' 

CREATE SYMMETRIC KEY myKeyName  
    WITH ALGORITHM = TRIPLE_DES 
    ENCRYPTION BY CERTIFICATE myCert 

Dodatkowo musiałem uruchomić następujące polecenia, aby prawidłowo odszyfrować dane:

OPEN MASTER KEY DECRYPTION BY PASSWORD = 'password' 
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY 

Kiedy uruchomić tego polecenia I wtedy zobaczyć wszystkie dane odszyfrowanych:

OPEN SYMMETRIC KEY myKeyName 
DECRYPTION BY CERTIFICATE myCert 
select TOP 1000 userid, CONVERT(nVARCHAR(255),DECRYPTBYKEY(password)) from users 
CLOSE SYMMETRIC KEY myKeyName 

Jak dotąd tak dobrze. Jeśli jednak uruchomię te same kroki w klastrze produkcyjnym AO, to zapytanie:

select TOP 1000 userid, CONVERT(nVARCHAR(255),DECRYPTBYKEY(password)) from users 

zwraca NULL dla hasła. Aby to nieco bardziej szalony zrobić, to stwierdzenie (uruchamiane w kontekście środowiska QA) odszyfrowuje wszystko z obu baz danych tylko dobrze:

OPEN SYMMETRIC KEY myKeyName 
DECRYPTION BY CERTIFICATE myCert 

SELECT TOP 1000 
    userid, 
    CONVERT(nVARCHAR(255),DECRYPTBYKEY(password)) 
FROM users 

SELECT TOP 1000 
    userid, 
    CONVERT(nVARCHAR(255),DECRYPTBYKEY(password)) 
FROM PRODUCTIONAO.prod_database.dbo.users 

CLOSE SYMMETRIC KEY myKeyName 

Nie jestem pewien, dlaczego to będzie działać na moim instancji QA, ale nie w mojej instancji produkcji. Każda pomoc będzie bardzo ceniona!

Answer 1

Po utworzeniu klucza głównego bazy danych serwer zapisuje 2 wersje klucza. Jedna wersja jest szyfrowana przez główny klucz usługi i domyślnie jest używana przez serwer. Druga wersja jest szyfrowana hasłem dostarczanym do serwera podczas tworzenia klucza głównego bazy danych. Ta wersja zazwyczaj nie jest używana. Kiedy przenosisz bazę danych do innego środowiska (produkcja w twoim przypadku), nowy serwer ma inny główny klucz usługi. Ponieważ to nie klucz usługi został użyty do zaszyfrowania klucza głównego bazy danych, nie można go również użyć do otwarcia klucza głównego bazy danych. Tutaj powinieneś użyć wersji zaszyfrowanej hasłem. Należy otworzyć klucz główny, używając hasła, a następnie zaszyfrować je przy użyciu nowego klucza usługi i zamknąć. Po wykonaniu tego klucz główny bazy danych może działać z kluczem usługi głównej, więc nie trzeba tego robić ponownie.

kroki/code:

otwarty mistrz klucz deszyfrowania hasłem =

klucz alter mistrz 'WriteYouOriginalPasswordHere' dodać szyfrowanie przez mistrza usług kluczowego

blisko Master Key

Answer 2

Powodem Twoja ostatnia działanie kwerendy wynika z faktu, że używasz klucza/certyfikatu instancji QA do deszyfrowania danych produkcyjnych. W QA można automatycznego odszyfrowania cert z klucza głównego bazy danych (DMK) ponieważ jest zaszyfrowany za pomocą klucza głównego usługa QA (SMK), jak następuje:

 
Service Master Key (QA) 
    Database Master Key (QA) 
    Certificate (QA) 
     Symmetric Key (QA) 
     Data (Prod) 

w prod, masz inny SMK więc jedynym opcja otwarcia DMK odbywa się za pomocą hasła.Wydaje się, że prowadził następujące w środowisku QA, ale nie w prod:

/* Add service master key encryption to the database master key */ 
OPEN MASTER KEY DECRYPTION BY PASSWORD = 'password' 
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY 

Spróbuj tego w prod:

OPEN MASTER KEY DECRYPTION BY PASSWORD = 'password' 
OPEN SYMMETRIC KEY myKeyName 
DECRYPTION BY CERTIFICATE myCert 
select TOP 1000 userid, CONVERT(nVARCHAR(255),DECRYPTBYKEY(password)) from users 
CLOSE SYMMETRIC KEY myKeyName 

Jeśli to zwraca dane, trzeba dodać szyfrowanie SMK do DMK w produkcji (pierwszy scenariusz). Inną opcją jest utworzenie kopii zapasowej SMK z instancji źródłowej i przywrócenie jej na serwerze wtórnym. Mogę to tylko polecić w przypadkach użycia HA, gdzie instancje są partnerami typu fail-over i oba znajdują się w tym samym środowisku. Udostępnianie SMK pomiędzy QA i prod jest złą praktyką.