TDE w bazach OpenEdge

Ostatni artykuł dotyczył podstawowych informacji związanych z zastosowania FIPS w OpenEdge. Zanim napiszę trochę więcej na ten temat, postanowiłem skupić się na innym rozwiązaniu – Transparent Data Encryption (TDE). Po pierwsze, kilku z Was prosiło mnie o to już wcześniej, a po drugie, ta wiedza przyda się przy włączaniu FIPS w bazach danych.

Bezpieczeństwo danych od wielu lat pozostaje jednym z najważniejszych wyzwań dla organizacji rozwijających systemy biznesowe. Rosnące wymagania regulacyjne m.in. RODO (GDPR), PCI DSS czy HIPAA, coraz bardziej zaawansowane cyberataki oraz potrzeba ochrony danych przed nieautoryzowanym dostępem sprawiają, że szyfrowanie danych „w spoczynku” (data at rest) stało się standardem, a nie opcjonalnym dodatkiem.

W środowiskiem Progress OpenEdge odpowiedzią na te potrzeby jest Transparent Data Encryption (TDE). Choć funkcjonalność ta została wprowadzona już kilka lat temu, wciąż pozostaje jednym z najważniejszych elementów strategii bezpieczeństwa platformy. Co więcej, kolejne wersje OpenEdge przynoszą jej dalszy rozwój – od silniejszych mechanizmów kryptograficznych, przez usprawnione zarządzanie kluczami, aż po lepsze wsparcie dla współczesnych wymagań związanych z bezpieczeństwem i zgodnością z przepisami.

Czym jest Transparent Data Encryption?

Transparent Data Encryption (TDE) to mechanizm szyfrujący dane przechowywane w bazie danych w sposób całkowicie transparentny dla aplikacji. Oznacza to, że aplikacja korzystająca z bazy OpenEdge nie wymaga żadnych zmian w kodzie – dane są automatycznie szyfrowane podczas zapisu na dysk oraz odszyfrowywane podczas odczytu.

Najważniejszym celem TDE jest ochrona danych przechowywanych na nośnikach fizycznych. Nawet jeśli ktoś uzyska dostęp do plików bazy danych, kopii zapasowej lub binarnych zrzutów danych, ich zawartość pozostanie bezużyteczna bez odpowiednich kluczy szyfrujących. Mechanizm ten nie zastępuje kontroli dostępu ani uwierzytelniania użytkowników – stanowi dodatkową warstwę ochrony, zabezpieczając dane przed ich fizycznym przejęciem.

Jedną z największych zalet OpenEdge TDE jest to, że szyfrowanie zostało zaimplementowane bezpośrednio w silniku bazy danych. Administrator definiuje politykę szyfrowania oraz zarządza kluczami, natomiast aplikacja nadal działa tak samo jak wcześniej. Dzięki temu wdrożenie TDE jest znacznie prostsze niż implementowanie własnych mechanizmów kryptograficznych na poziomie kodu aplikacji.

W praktyce OpenEdge TDE chroni dane zapisane w tabelach, indeksach, obszarach bazy danych, plikach AI i BI oraz kopiach zapasowych i binarnych dumpach. Mechanizm wykorzystuje standardowe algorytmy kryptograficzne oraz oddzielny magazyn kluczy (Key Store), w którym przechowywany jest główny klucz bazy danych (Database Master Key). Na jego podstawie generowane są unikalne klucze dla poszczególnych zaszyfrowanych obiektów, co znacząco zwiększa poziom bezpieczeństwa całego rozwiązania.

Co może być zaszyfrowane:
– Obszary typu I (Type I Storage Areas) – szyfrowany jest cały obszar typu I.
– Tabele, indeksy oraz obiekty LOB w obszarach typu II (Type II Storage Areas).
– Pliki Before Image (BI) – są szyfrowane domyślnie.
– Pliki After Image (AI) – są szyfrowane domyślnie.
– Kopie zapasowe tworzone za pomocą narzędzia probkup – są zawsze szyfrowane.
– Pliki Binary Dump – domyślnie nie są szyfrowane.

Pierwszym krokiem podczas wdrażania Transparent Data Encryption jest utworzenie w bazie danych dedykowanego obszaru p nazwie: “Encryption Policy Area”, który będzie przechowywał informacje o zdefiniowanych politykach szyfrowania.

Obszar ten nie będzie zawierać zaszyfrowanych danych ani kluczy szyfrujących. Jego zadaniem jest przechowywanie metadanych opisujących, które obiekty bazy danych mają przypisaną politykę szyfrowania. Dla każdego obiektu, takiego jak obszar bazy danych, tabela, indeks czy LOB, tworzony jest jeden rekord zawierający informacje o przypisanej polityce.
Ze względu na to, że przechowywane są wyłącznie metadane, rozmiar obszaru jest bardzo niewielki. Nawet w dużych bazach danych zwykle nie przekracza on kilku megabajtów.

Warto pamiętać, że Encryption Policy Area musi zostać utworzony jako obszar składowania typu II (ze specjalnym tokenem “e” w pliku struktury). Jest to wymaganie mechanizmu TDE i bez spełnienia tego warunku nie będzie możliwe definiowanie polityk szyfrowania dla obiektów bazy danych.

Utworzymy więc plik add.st i dodamy do bazy mytde (kopia sports2000) obszar “Encryption Policy Area” a także własny obszar “NewCust” typu II (z clustrem 8) żeby pokazać jak można szyfrować dane dla poszczególnych obiektów.

# add.st
d "NewCust":13,32;8 . f 320
d "NewCust":13,32;8 .
#
e "Encryption Policy Area":80,32;8 .

Dodajemy obszary poleceniem: prostrct add mytde add.st

(UWAGA! komendy związane z zabezpieczeniami uruchamiamy jako jako Administrator systemu.)

Kolejnym krokiem jest włączenie obsługi szyfrowania w bazie danych. W tym celu należy wykonać polecenie:
proutil mytde -C enableencryption
Podczas wykonywania polecenia system poprosi o dwukrotne podanie hasła (passphrase), które będzie wykorzystywane do zabezpieczenia kluczy szyfrujących bazy danych.

Teraz przenoszę tablice customer i order do obszaru NewCust – muszę podać zdefiniowane wcześniej passphrase.

Baza jest zatem gotowa do szyfrowania. Włączam szyfrowanie dla tabeli customer:
proutil mytde -C epolicy manage table encrypt Customer -Passphrase

Jeszcze jedna uwaga. Po włączeniu Transparent Data Encryption baza danych domyślnie działa w trybie manual. Oznacza to, że podczas wykonywania operacji administracyjnych należy użyć parametru -Passphrase, a następnie podać hasło zdefiniowane podczas wykonywania polecenia proutil db -C enableencryption. Jest to dodatkowy mechanizm zabezpieczający, który uniemożliwia wykonywanie operacji na zaszyfrowanej bazie bez wcześniejszego uwierzytelnienia. Bazę można skonfigurować także w trybie auto, ale o tym nie będę tu pisał.
Możemy sprawdzić teraz czy szyfrowanie rzeczywiście jest włączone. Pierwsze polecenie (epolicy view) informuje, że jest.

Drugie polecenie (epolicy scan) informuje dodatkowo, że zaszyfrowane jest 7 z 48 bloków bazy.
Pozostałe będą szyfrowane na bieżąco, chyba że chcemy zasyfrować od razu całą tabelę.
Możemy to zrobić wykonując polecenie:
proutil mytde -C epolicy manage table update Customer -Passphrase

Jeśli powtórzę komendę skanowania, to widać że wszystkie bloki tabeli sa już zaszyfrowane.
Warto dodać, że skanowanie i podgląd szyfrowania (scan area, view area) można uruchomić także dla obszaru, ale wyłącznie jeśli to jest obszar typu I. Dla obszaru typu II pojawi się błąd.

Jeśli nie podajemy numeru szyfru to zostanie użyty szyfr 1. Wszystkie dostępne mamy w poniższym zestawieniu:

  • 0 – NULL (brak szyfrowania)
  • 1 – AES_CBC_128 (domyślny)
  • 2 – AES_CBC_192
  • 3 – AES_CBC_256
  • 4 – DES_CBC_56
  • 5 – DES3_CBC_168

Dwa ostatnie szyfry są słabe. Spróbujmy zaszyfrować tabelę Order szyfrem DES_CBC_56.
proutil mytde -C epolicy manage table encrypt Order -Cipher 4 -Passphrase

Chociaż dokumentacja nadal wymienia algorytmy DES_CBC_56 i DES3_CBC_168 jako obsługiwane, OpenEdge 13 traktuje je jako algorytmy przestarzałe (deprecated). Mogą występować w starszych bazach danych, jednak nie można ich użyć do tworzenia nowych polityk szyfrowania. Progress zaleca stosowanie wyłącznie algorytmów z rodziny AES.

Do zarządzania szyfrowaniem tabel można użyć także komend SQL lub narzędzia Data Administration. W tym ostatnim wchodzimy w Admin -> Security -> Encryption Policies -> Edit Encryption Policy. Wybieramy tabelę i OK.

To na razie tyle. Dość spory materiał do przetestowania, a i to nie jest oczywiście wszystko. Powodzenia!

Administracja