Share via

zabezpieczenia bazy danych SQL Server dla oprogramowania SAP na platformie Azure

  • Artykuł

Ten artykuł jest częścią serii artykułów "Sap extend and innovate security: Best practices" (Rozszerzanie i wprowadzanie innowacji w oprogramowaniu SAP: najlepsze rozwiązania).

Ten artykuł zawiera zagadnienia dotyczące zabezpieczeń i zalecenia dotyczące oprogramowania SAP na platformie Azure działającego w bazie danych SQL Server.

Zabezpieczanie danych magazynowanych

SQL Server Transparent Data Encryption (TDE) szyfruje pliki danych i dzienników dla baz danych użytkowników i SQL Server systemowych baz danych. Po zaszyfrowaniu kopii danych i plików dziennika ani plików kopii zapasowej nie można przywrócić ani używać ich bez skojarzonych certyfikatów. Ten proces jest nazywany zabezpieczaniem danych magazynowanych. Jest to przezroczysta technologia systemu SAP, dlatego jest obsługiwana przez 1380493 sap — SQL Server TDE. Aby uzyskać informacje na temat procedury TDE, zobacz SQL Server szyfrowanie.

Wszystkie strony danych, które są odczytywane lub zapisywane na dysku, muszą być szyfrowane lub odszyfrowywane, więc funkcja TDE ma karę za procesor CPU. Po zastosowaniu funkcji TDE do bazy danych użytkownika użycie procesora CPU wzrasta w zakresie od 3% do 8%. W przypadku aplikacji, które intensywnie korzystają z bazy danych TempDB SQL Server lub przeprowadzania dużych skanów w dużych tabelach, ma to większy wpływ. Gdy co najmniej jedna baza danych użytkownika w wystąpieniu SQL Server jest szyfrowana za pomocą funkcji TDE, systemowe bazy danych, takie jak TempDB, również są szyfrowane. Sap Business Warehouse (SAP BW) to przykład aplikacji tego typu.

Uwaga

Jeśli klucze szyfrowania lub certyfikaty zostaną utracone, dane w zaszyfrowanej bazie danych zostaną utracone. Ważne jest, aby ustanowić obszerne procesy i kroki zabezpieczania kopii zapasowych certyfikatów.

Pomyślna implementacja funkcji TDE wymaga dobrych i dokładnych procesów testowania oraz dobrze zaprojektowanych procesów do obsługi certyfikatów i kopii zapasowych certyfikatów.

Nieobsługiwane funkcje SQL Server

SQL Server oferuje również inne funkcje ochrony danych. Te metody umożliwiają częściowe szyfrowanie lub maskowanie na poziomie szczegółowości kolumny bazy danych:

Na podstawie ograniczeń tych trzech metod i zmian, które wymagają w wielu obszarach składników SAP NetWeaver, te funkcje nie są obsługiwane przez oprogramowanie SAP.

Replikacja w czasie rzeczywistym między bazą danych z włączoną funkcją TDE w systemie SQL Server a platformą SAP HANA nie jest obsługiwana. Aby uzyskać więcej informacji, zobacz Uwaga dotycząca systemu operacyjnego SAP 2812637 — replikacja w czasie rzeczywistym nie jest obsługiwana w przypadku bazy danych programu MSSQL Server z włączoną funkcją TDE.

Szyfrowanie kopii zapasowej

Szyfrowanie kopii zapasowej jest wykonywane podczas szyfrowania pliku kopii zapasowej. Szyfruje ona wszystkie strony danych w pliku kopii zapasowej i tworzy certyfikat lub klucz asymetryczny wymagany do przywrócenia pliku kopii zapasowej, co uniemożliwia nieautoryzowane przywracanie.

Jeśli baza danych nie jest szyfrowana przy użyciu funkcji TDE przed wykonaniem zaszyfrowanej kopii zapasowej, nadal nie jest szyfrowana po przywróceniu. Zaszyfrowane są tylko pliki kopii zapasowej. Plik bazy danych i jego zawartość nie są zmieniane.

Szyfrowanie kopii zapasowej można używać z funkcją TDE, ale nie jest korzystne, ponieważ dane są już szyfrowane w plikach bazy danych i w plikach kopii zapasowych. W przypadku używania szyfrowania kopii zapasowych i funkcji TDE razem zaszyfrowana baza danych z certyfikatem TDE lub stronami danych zaszyfrowanych kluczami jest ponownie szyfrowana przy użyciu certyfikatu lub klucza kopii zapasowej. Ta metoda przedłuża proces tworzenia kopii zapasowej i dodaje dodatkowe obciążenie procesora CPU do systemu podczas wykonywania procesu tworzenia kopii zapasowej.

Zabezpieczanie systemu SQL Server i SAP

Wzmacnianie zabezpieczeń na poziomie serwera i systemu operacyjnego jest niezbędne dla bezpiecznego działającego systemu.

Przestrzegaj poniższych zaleceń, aby zabezpieczyć SQL Server i system SAP. Aby uzyskać więcej informacji, zobacz uwaga systemu operacyjnego SAP 2417205.

SQL Server opiera się na implementacji protokołu TLS (Transport Layer Security) w systemie Windows i protokołu SSL (Secure Sockets Layer) za pośrednictwem dostawcy obsługi zabezpieczeń SCHANNEL (SSP).

Protokół SSL można wyłączyć, ponieważ protokół TLS jest powszechnie używany i obsługiwany. Większość SQL Server i obsługi produktów SAP używają protokołu TLS 1.2.

Większość ustawień zabezpieczeń dostawcy SSP SCHANNEL można kontrolować za pomocą zmian rejestru w odpowiedniej gałęzi SCHANNEL. Za pomocą tych ustawień możesz kontrolować:

  • Które protokoły, takie jak SSL i TLS, są włączone dla klienta i serwera w oknie dialogowym.
  • Szyfry, na przykład RC2, RC4, Triple DES i AES, które są włączone, oraz kolejność ich włączania.
  • Algorytmy wyznaczania wartości skrótu, na przykład MD5 i SHA.
  • Algorytmy wymiany kluczy, na przykład Diffie-Hellman i ECDH.

Różne kombinacje tych części, takie jak protokół, szyfr i algorytm wymiany kluczy, są reprezentowane w zestawach szyfrowania. Wyłączenie jednej z tych części, na przykład protokołu SSL 2.0, wszystkie zestawy szyfrowania zawierające tę część są bezużyteczne dla systemu.

Uwaga

Po połączeniu wielu zmian klient, na przykład system SAP, a serwer, na przykład SQL Server, może nie być w stanie użyć zestawu szyfrowania do komunikacji, a system SAP może nie uruchomić.

W edytorze lokalnych zasad grupy można również kontrolować priorytet i dostępność zestawów szyfrowania w systemie.

  1. Przejdź do pozycji Konfiguracja komputera lokalnego Konfiguracja komputera > Szablony administracyjne Ustawienia > konfiguracji protokołu SSL sieci>.>
  2. Zdefiniuj niestandardową kolejność zestawu szyfrowania SSL.

Zrzut ekranu przedstawiający konfigurację protokołu SSL.

Ta kolejność listy definiuje priorytet używany przez system zestawów szyfrowania. Jeśli usuniesz pakiet szyfrowania z listy, nie będzie już można jej używać w systemie. Ustawienie zasad grupy ma priorytet nad ustawieniem rejestru SCHANNEL. Dział zabezpieczeń zwykle kontroluje to ustawienie na podstawie zasad grupy. Jednak grupa administracyjna sap Basis lub SQL Server bazy danych obsługuje wynikowe problemy z połączeniem.

Rozważ użycie narzędzia SAP, SCoTT, aby analizować problemy z wyłączonymi protokołami lub zestawami szyfrowania. Narzędzie może analizować problemy z połączeniem między systemem SAP, takim jak ABAP i Java, i SQL Server, które działają w systemie Linux lub Windows. Aby uzyskać więcej informacji, zobacz uwagi sap 2846170.

Authentication

Poniżej przedstawiono kilka zagadnień dotyczących uwierzytelniania za pomocą oprogramowania SAP na platformie Azure.

  • Oprogramowanie SAP NetWeaver na SQL Server ma określone wymagania dotyczące kont startowych SAP i SQL Server, uwierzytelniania w wystąpieniu SQL Server, bazie danych SAP i dostępie do bazy danych DBA. Aby uzyskać więcej informacji, zobacz uwagi sap 1645041 — SQL Server logowania i ich użycie w środowiskach SAP.

  • System SAP ABAP NetWeaver nie wymaga SQL Server logowania, ponieważ wszystkie połączenia używają uwierzytelniania systemu Windows. Na przykład dla użytkownika SAPService<SID> lub <SID>administratormożna wyłączyć funkcję uwierzytelniania SQL Server.

  • System SAP JAVA NetWeaver wymaga funkcji uwierzytelniania SQL Server, ponieważ używa SQL Server logowania, takiego jak SAP<SID>DB, dla połączenia.

  • W przypadku oprogramowania SAP w SQL Server można wyłączyć konto administratora systemu SQL Server, ponieważ systemy SAP w systemie SQL Server nie korzystają z konta. Przed wyłączeniem oryginalnego konta administratora systemu upewnij się, że inny użytkownik z uprawnieniami administratora systemu może uzyskać dostęp do serwera.

  • System wysokiej dostępności, który korzysta z SQL Server AlwaysOn, ma określone wymagania dotyczące logowań, użytkowników i zadań. Wszystkie serwery połączone z systemem muszą mieć dokładnie te same nazwy logowania i użytkowników, aby system SAP mógł nawiązać połączenie nawet w przypadku przejścia w tryb failover do innego węzła. Wszystkie zadania SQL Server związane z oprogramowaniem SAP muszą mieć tego samego właściciela we wszystkich węzłach AlwaysOn. Aby uzyskać więcej informacji, zobacz Synchronizowanie identyfikatorów logowania, zadań i obiektów SAP.

  • Wstrzyknięcie kodu SQL polega na tym, że złośliwy kod scala się z instrukcjami SQL uruchamianymi w SQL Server. Gdy raport jest uruchamiany w systemie SAP, generuje ogólne instrukcje SQL z kodu ABAP raportu. Instrukcje są wysyłane do i przekształcane przez warstwę bazy danych SAP dla SQL Server.

    Ta warstwa bazy danych jest zintegrowana z procesem roboczym sap i nie jest dostępna z zewnątrz. Po przekształceniu w instrukcje specyficzne dla SQL Server są one wysyłane do bazy danych i uruchamiane. Wynik jest zwracany do raportu wywołującego. Te instrukcje można manipulować tylko między warstwą bazy danych systemu SAP a wystąpieniem SQL Server, które jest nazywane atakiem typu man-in-the-middle.

    W systemie SAP użyj szyfrowanych połączeń między procesem roboczym a bazą danych SQL Server, aby zapobiec tym atakom. Transakcja DBACockpit ma podstawowe okno poleceń SQL do uruchamiania podstawowych instrukcji SQL. Aby uzyskać więcej informacji, zobacz uwaga SAP 1027512 — MSSQL: kokpit DBA dla wersji 7.00 i nowszej.

Inspekcja

Następne kroki