Month: July 2026

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

FIPS 140-3 w OpenEdge 13

Wraz z premierą Progress OpenEdge 13, twórcy oprogramowania i administratorzy systemów otrzymali potężne narzędzie do walki o cyberbezpieczeństwo. Wersja ta wprowadza pierwsze produkcyjne wdrożenie standardu kryptograficznego FIPS 140-3 dla kluczowych komponentów systemu. FIPS 140-3 jest najnowszym standardem rządu USA, który definiuje wymagania bezpieczeństwa dla modułów kryptograficznych. W OpenEdge 13 aktywacja FIPS mode sprawia, że środowisko wykonawcze (AVM), bazy danych RDBMS oraz serwery aplikacyjne PASOE wymuszają stosowanie wyłącznie zwalidowanych przez NIST* bibliotek oraz silnych algorytmów do szyfrowania i zarządzania kluczami.

Jeśli pracujesz w branży finansowej, medycznej lub rządowej, wdrożenie trybu FIPS (Federal Information Processing Standards) staje się fundamentem zgodności regulacyjnej. Jak zatem podejść do tego tematu jako administrator?

Po pierwsze, do uruchomienia trybu FIPS wymagany jest pakiet licencyjny Progress OpenEdge Advanced Security (OEAS). Upewnijmy się, że posiadamy go w instalacji.
Poza tym, przeprowadzając audyt certyfikatów SSL/TLS pod kątem zgodności z FIPS, musimy pamiętać, że tryb ten bezwzględnie odrzuci słabą kryptografię. Wszystkie asymetryczne klucze certyfikatów oparte na algorytmie RSA, używane w komunikacji sieciowej lub do ochrony kluczy szyfrujących bazy danych (TDE), muszą mieć długość minimum 2048 bitów. W przypadku stosowania nowoczesnych certyfikatów z użyciem krzywych eliptycznych (ECC/ECDSA) wymagana jest długość klucza wynosząca minimum 256 bitów.

Tryb
FIPS włączamy w środowisku OpenEdge za pomocą narzędzia ESAM/POLMAN.
Przypomnijmy, że ESAM (Embedded Security Architecture Module) to wewnętrzny system bezpieczeństwa wprowadzony w OpenEdge 12.6. Monitoruje procesy Progressa i blokuje uruchamianie plików z nieautoryzowanych ścieżek. Stanowi fundament pod bezpieczną architekturę i wymuszanie trybu FIPS.
POLMAN (Policy Manager) to narzędzie wiersza poleceń do zarządzania systemem ESAM. Służy do tworzenia, edycji i podpisywania polityk bezpieczeństwa platformy. Za jego pomocą administratorzy aktywują i konfigurują zgodność środowiska z normami FIPS.

Warto więc na poczatku sprawdzić czy ESAM jest poprawnie zainstalowany. Ponieważ miałem wcześniej zainstalowane w Windows niższe wersje OE od 12.6 do 12.8, to po ich wyinstalowaniu pozostały katalogi/pliki ESAM:
C:\Windows\System32\openedge.d
C:\Windows\System32\openedge
Skorzystałem z rozwiązania z bazy wiedzy (nr 000297865) żeby je usunąć jako administrator. Uwaga! możemy tak zrobić tylko jeśli nie mamy już zainstalowanych tych wersji. Ta operacja nie jest niezbędna ale warto wyczyścić struktrurę ESAM jeśli odnosi się do wyinstalowanych już wersji.

Po zainstalowaniu OE 13, sprawdziłem w logach, że ESAM został poprawnie zainstalowany jednak uruchamiając komendę C:\Windows\System32\openedge.d\bin>valdlc -dlc C:\OpenEdge130 okazało się, że walidacja katalogu DLC kończy się niepowodzeniem. To dość częsty przypadek. Możemy jednak zarejestrować ten katalog ręcznie poleceniem:
C:\Windows\System32\openedge.d\sbin>setdlc.bat -esamregisterDLC C:\OpenEdge130

Sprawdzamy jeszcze raz walidację:
C:\Windows\System32\openedge.d\bin>valdlc -dlc C:\OpenEdge130

Aby aktywować FIPS trzeba uruchomić terminal OpenEdge proenv z uprawnieniami administratora.
Najpierw warto wyświetlić aktualny status polityki globalnej ESAM oraz sprawdzić, czy tryb FIPS jest już aktywny, wpisujemy polecenie:
proenv>polman get -policy urn:esam:fips140:can-run-without
Walidacja kończy się teraz sukcesem.

Tryb FIPS włącza się komendą:
polman set -policy urn:esam:fips140:can-run-without -value no

Po wprowadzeniu zmiany, ponownie zweryfikuj stan polityki w ESAM, aby upewnić się, że flaga została poprawnie zapisana:
proenv>polman get -policy urn:esam:fips140:can-run-without
Wyłączamy FIPS poleceniem:
polman set -policy urn:esam:fips140:can-run-without -value yes
i ponownie testujemy.
Obie komendy przedstawione są poniżej.

Wdrożenie trybu FIPS po stronie infrastruktury to właściwie mniej niż połowa sukcesu. Administrator musi ściśle współpracować z programistami, ponieważ FIPS blokuje starsze funkcje w kodzie ABL.
Na przykłąd użycie funkcji ENCODE() zakończy się błędem ponieważ tradycyjna metoda tworzenia skrótów haseł nie spełnia wymogów standardu. Deweloperzy muszą zastąpić ją nowszą funkcją GENERATE-PASSWORD-HASH. Podobnie funkcja MD5-DIGEST() czy SHA1-DIGEST().
Przed włączeniem FIPS warto dokładnie zapoznać się z dokumentacją i sprawdzić kod źródłowy – część problemów pojawia się dopiero podczas runtime’u, a nie podczas kompilacji.
Testowanie warunkowe: Programiści mogą zabezpieczyć kod przed błędami kryptograficznymi, sprawdzając stan środowiska za pomocą systemowego atrybutu: SECURITY-POLICY:FIPS-MODE.
Poniżej mamy prosty kod do wykrywania trybu FIPS.

//test_fips.p
IF SECURITY-POLICY:FIPS-MODE THEN DO:
	MESSAGE "Success: FIPS 140-3 is on!" 
    	VIEW-AS ALERT-BOX INFORMATION.
END.
ELSE DO:
	MESSAGE "Warning: FIPS is not working!" 
    	VIEW-AS ALERT-BOX WARNING.
END.


Wdrożenie FIPS 140-3 w Progress OpenEdge 13 to kamień milowy w zabezpieczaniu danych przedsiębiorstwa. Choć wymaga przygotowania infrastruktury i audytu kodu, to widzimy, że centralne wymuszenie restrykcyjnych reguł bezpieczeństwa jest dość proste.

Na koniec jeszcze jedna ważna kwestia – pamiętajmy o tym, że OpenEdge nie działa w próżni. Jeśli włączymy FIPS w OpenEdge, ale nasz system operacyjny (Windows Server lub Linux) będzie skonfigurowany niezgodnie z tym standardem, środowisko nie osiągnie pełnej zgodności.

Poniżej podaję przykładową instrukcję konfiguracji systemu operacyjnego.
Windows Server – w menu komend uruchom gpedit.msc aby otworzyć Edytor lokalnych zasad grupy.
W lewym panelu przejdź kolejno do ścieżki: Konfiguracja komputera -> Ustawienia systemu Windows -> Ustawienia zabezpieczeń -> Zasady lokalne -> Opcje zabezpieczeń.
W prawym panelu znajdź i kliknij dwukrotnie zasadę: Kryptografia systemu: Użyj zgodnych algorytmów FIPS do szyfrowania, haszowania i podpisywania. Zmień ustawienie na Włączone, kliknij Zastosuj, a następnie OK.
Otwórz wiersz poleceń (cmd) jako administrator i wymuś aktualizację zasad komendą: gpupdate /force

Linux – zaloguj się na serwer jako użytkownik z uprawnieniami root lub użyj sudo. Sprawdź obecny status za pomocą polecenia: fips-mode-setup –check
Jeśli tryb FIPS jest wyłączony, aktywuj go systemowo wpisując: fips-mode-setup –enable
Uruchom ponownie serwer (komendą reboot), aby system operacyjny przełączył jądro (kernel) oraz systemowe biblioteki w restrykcyjny tryb FIPS 140-3. Po restarcie upewnij się, że system działa poprawnie, powtarzając pierwszą komendę: fips-mode-setup –check.

Powyższe informacje na temat konfiguracji systemu operacyjnego przedstawiłem opcjonlanie. Przykładowe włączenie FIPS w OpenEdge 13 przeprowadziłem bez zmian systemowych.
Ciąg dalszy nastąpi.

* NIST to skrót od National Institute of Standards and Technology (Narodowy Instytut Standardów i Technologii).Jest to amerykańska agencja rządowa, która podlega pod Departament Handlu USA. To właśnie NIST tworzy i publikuje standardy z serii FIPS (w tym opisywany FIPS 140-3). Definiują one, jakie algorytmy kryptograficzne i moduły bezpieczeństwa są bezpieczne i dopuszczone do użytku w instytucjach rządowych oraz branżach regulowanych.

Administracja, Development