Szyfrowanie procedury

Szyfrowanie procedury ukrywa jej definicję przed odczytem przez WITH ENCRYPTION, kosztem utrudnionej diagnostyki.

Na czym polega szyfrowanie procedury w SQL Server

Szyfrowanie procedury w Microsoft SQL Server polega na ukryciu tekstu jej definicji w metadanych bazy danych. Mechanizm uruchamia się podczas tworzenia albo modyfikowania procedury składowanej przez dodanie klauzuli WITH ENCRYPTION do instrukcji CREATE PROCEDURE lub ALTER PROCEDURE. Przykładowo procedura może zostać zdefiniowana jako CREATE PROCEDURE dbo.PobierzTowary WITH ENCRYPTION AS SELECT .... Szyfrowany jest tekst modułu, czyli zapis instrukcji T-SQL składających się na procedurę, a nie sam wynik jej działania.

Po zapisaniu takiej procedury SQL Server nadal przechowuje informacje potrzebne do jej wykonania. Silnik zna parametry, instrukcje i zależności niezbędne do kompilacji oraz realizacji wywołania, lecz standardowe zapytania metadanych nie udostępniają już treści źródłowej w zwykłej postaci. Szyfrowanie nie zmienia więc sposobu wywoływania procedury. Nadal można użyć instrukcji EXEC, przekazać wymagane parametry i otrzymać rezultat, o ile użytkownik posiada odpowiednie uprawnienia do wykonania procedury oraz dostępu do wykorzystywanych obiektów.

Wpływ klauzuli WITH ENCRYPTION na metadane

Definicję procedury można zwykle odczytać z widoków katalogowych, takich jak sys.sql_modules, albo za pomocą funkcji OBJECT_DEFINITION. Dla modułu utworzonego z WITH ENCRYPTION tekst definicji nie jest dostępny w standardowym odczycie. Oznacza to, że zapytanie diagnostyczne zwracające definicję może otrzymać wartość NULL albo nie dostarczyć użytecznego tekstu procedury, mimo że obiekt istnieje i może być wykonywany.

Ukryciu podlega kod modułu, ale nie wszystkie informacje o obiekcie. W katalogu bazy nadal mogą być widoczne między innymi nazwa procedury, schemat, typ obiektu oraz część właściwości związanych z jego istnieniem. Możliwe jest także obserwowanie wywołań, błędów wykonania i niektórych informacji o planie zapytania, zależnie od konfiguracji, uprawnień oraz sposobu monitorowania. Nie należy utożsamiać szyfrowania definicji z pełnym szyfrowaniem danych, szyfrowaniem połączenia ani z mechanizmem Transparent Data Encryption. Są to odrębne funkcje SQL Server, dotyczące innych warstw działania systemu.

Diagnostyka kodu, zależności i wdrażanie zmian

Największym praktycznym skutkiem szyfrowania procedury jest ograniczenie diagnostyki. Osoba analizująca błąd może widzieć nazwę procedury i komunikat zwrócony przez silnik, ale nie odczyta jej instrukcji przez standardowe narzędzia katalogowe. Utrudnia to ustalenie, czy problem wynika z warunku WHERE, połączenia tabel, konwersji typów, obsługi wartości NULL, parametrów wejściowych albo instrukcji modyfikujących dane. Sam fakt, że procedura kończy się błędem, nie pozwala odtworzyć jej logiki bez dostępu do zachowanej wersji źródłowej.

Przed wdrożeniem procedury z WITH ENCRYPTION należy zachować niezaszyfrowany skrypt w kontrolowanym repozytorium kodu lub innym zatwierdzonym miejscu przechowywania. Skrypt powinien obejmować pełną instrukcję CREATE PROCEDURE albo ALTER PROCEDURE, definicję parametrów oraz niezbędne elementy logiki. Jest to istotne również przy aktualizacji, ponieważ zmiana procedury wymaga ponownego wykonania instrukcji definiującej moduł. Bez kopii źródłowej późniejsze poprawienie literówki, zmiana zapytania lub odtworzenie obiektu po awarii może być znacznie trudniejsze.

Weryfikacja takiej procedury powinna obejmować wywołania z poprawnymi i granicznymi wartościami parametrów, sprawdzenie komunikatów błędów oraz porównanie wyników przed i po wdrożeniu. Narzędzia automatycznej analizy kodu, generowania dokumentacji i śledzenia zależności również mają ograniczony dostęp do treści zaszyfrowanego modułu. Z tego powodu szyfrowanie powinno być decyzją dotyczącą cyklu życia kodu, a nie przypadkowym dodatkiem do definicji procedury.

Granice ochrony i bezpieczna obsługa procedury

WITH ENCRYPTION chroni przede wszystkim przed zwykłym odczytem tekstu definicji przez użytkowników korzystających z katalogów systemowych. Nie zastępuje kontroli uprawnień, uwierzytelniania, rejestrowania operacji ani zasad bezpiecznego wdrażania zmian. Uprawnienia do wykonania procedury i uprawnienia do odczytu jej definicji są odrębnymi zagadnieniami. Procedura może być możliwa do uruchomienia, a jednocześnie jej kod może nie być dostępny w standardowych zapytaniach metadanych.

Przy analizie problemu należy najpierw ustalić dokładną nazwę obiektu, schemat, parametry i moment wystąpienia błędu. Następnie warto sprawdzić logi aplikacji, komunikaty SQL Server, dane wejściowe oraz rezultat wywołania. Jeżeli definicja jest zaszyfrowana, do porównania należy wykorzystać autoryzowany skrypt źródłowy przechowywany poza bazą. Próby odtwarzania kodu na podstawie samych wyników zapytań mogą prowadzić do błędnych wniosków, ponieważ ten sam rezultat może powstawać z wielu różnych implementacji T-SQL.

W przypadku środowiska, w którym procedura jest elementem aplikacji działającej na komputerze lub laptopie, diagnostyka powinna rozdzielać problem lokalnego systemu, połączenia z bazą i samego modułu SQL Server. Pozwala to uniknąć przypisywania awarii sprzętowi wtedy, gdy rzeczywistą przyczyną jest błąd procedury, brak uprawnienia albo niezgodny parametr. Dokumentacja niezaszyfrowanej wersji kodu, kontrola zmian i test odtworzeniowy są ważniejsze dla ciągłości utrzymania niż samo ukrycie tekstu definicji.