Przewodnik dotyczący funkcji zabezpieczeń programu SQL Server w systemie Linux

Dotyczy:Program SQL Server w systemie Linux

Jeśli jesteś użytkownikiem systemu Linux, który jest nowym użytkownikiem programu SQL Server, następujące zadania przeprowadzą Cię przez niektóre zadania zabezpieczeń. Te zadania nie są unikalne ani specyficzne dla Linuksa, ale dają wyobrażenie o obszarach do dalszego zgłębiania. Każdy przykład łączy się z dogłębną dokumentacją dotyczącą tego obszaru.

Przykłady kodu w tym artykule korzystają z przykładowej bazy danych AdventureWorks2025 lub AdventureWorksDW2025, którą można pobrać ze strony głównej Przykładów programu Microsoft SQL Server i projektów społeczności.

Tworzenie nazwy logowania i użytkownika bazy danych

Udostępnij innym dostęp do SQL Server, tworząc logowanie w bazie master danych za pomocą CREATE LOGIN tego wyroku. Przykład:

CREATE LOGIN Larry
    WITH PASSWORD = '<password>';

Caution

Hasło powinno być zgodne z domyślnymi zasadami haseł programu SQL Server. Domyślnie hasło musi mieć długość co najmniej ośmiu znaków i zawierać znaki z trzech z następujących czterech zestawów: wielkie litery, małe litery, cyfry podstawowe-10 i symbole. Hasła mogą mieć długość maksymalnie 128 znaków. Używaj haseł, które są tak długie i złożone, jak to możliwe.

Logowania mogą łączyć się z programem SQL Server i mieć dostęp (z ograniczonymi uprawnieniami) do master bazy danych. Aby nawiązać połączenie z bazą danych użytkownika, wymaga się, by nazwa logowania miała odpowiednią tożsamość na poziomie bazy danych, zwanej użytkownikiem bazy danych. Użytkownicy są specyficzni dla każdej bazy danych, więc musisz tworzyć ich osobno w każdej bazie, aby uzyskać dostęp.

Poniższy przykład przełącza AdventureWorks2025 się do bazy danych, a następnie używa CREATE USER instrukcji do utworzenia użytkownika o nazwie Larry przypisanej do logowania o nazwie Larry. Chociaż logowanie i użytkownik są powiązane (przypisane do siebie), to różne obiekty. Identyfikator logowania jest podmiotem zabezpieczeń na poziomie serwera. Użytkownik jest głównym na poziomie bazy danych.

USE AdventureWorks2025;
GO

CREATE USER Larry;
GO
  • Konto administratora programu SQL Server może łączyć się z dowolną bazą danych i tworzyć więcej identyfikatorów logowania i użytkowników w dowolnej bazie danych.
  • Gdy tworzysz bazę danych, stajesz się właścicielem i możesz się z nią połączyć. Właściciele baz danych mogą tworzyć więcej użytkowników.

Później możesz autoryzować inne loginy, aby utworzyć więcej loginów, udzielając im uprawnienia ALTER ANY LOGIN. Wewnątrz bazy danych możesz autoryzować innych użytkowników do tworzenia większej ALTER ANY USER liczby użytkowników, udzielając im uprawnień. Przykład:

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2025;
GO

GRANT ALTER ANY USER TO Jerry;
GO

Teraz logowanie Larry może generować więcej logowań, a użytkownik Jerry może tworzyć więcej użytkowników.

Udzielanie dostępu z najmniejszymi uprawnieniami

Administratorzy i właściciele baz danych są zazwyczaj pierwszymi użytkownikami, którzy łączą się z bazą użytkowników. Te konta mają wszystkie uprawnienia w bazie danych. Nie używaj tych kont do zadań, które wymagają mniejszej liczby uprawnień.

Gdy dopiero zaczynasz, możesz przypisać ogólne kategorie uprawnień za pomocą wbudowanych ról stałej bazy danych. Na przykład rola db_datareader stałej bazy danych może odczytywać wszystkie tabele w bazie, ale nie może dokonywać zmian. Nadanie członkostwa w stałej roli bazy danych wraz z oświadczeniem ALTER ROLE . Poniższy przykład dodaje użytkownika Jerry do roli db_datareader stałej bazy danych.

USE AdventureWorks2025;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

Aby uzyskać listę stałych ról bazy danych, zobacz Role na poziomie bazy danych.

Później, gdy będziesz gotowy na bardziej precyzyjny dostęp do danych (co jest bardzo zalecane), stwórz własne role bazy danych zdefiniowane przez użytkownika z tym CREATE ROLE wykatem. Następnie przypisz szczegółowe, precyzyjne uprawnienia do ról niestandardowych.

Na przykład następujące instrukcje tworzą rolę bazodaną o nazwie Sales, dają grupie Sales możliwość czytania, aktualizacji i usuwania wierszy z tabeli Orders , a następnie dodania użytkownika Jerry do roli Sales .

CREATE ROLE Sales;

GRANT SELECT ON OBJECT::Orders TO Sales;
GRANT UPDATE ON OBJECT::Orders TO Sales;
GRANT DELETE ON OBJECT::Orders TO Sales;

ALTER ROLE Sales ADD MEMBER Jerry;

Aby uzyskać więcej informacji na temat systemu uprawnień, zobacz Wprowadzenie do uprawnień silnika bazy danych.

Konfigurowanie zabezpieczeń na poziomie wiersza

Bezpieczeństwo na poziomie wiersza pozwala ograniczyć dostęp do wierszy w bazie danych na podstawie użytkownika, który wykonuje zapytanie. Ta funkcja jest przydatna w sytuacjach takich jak zapewnienie, że klienci mogą uzyskać dostęp tylko do własnych danych lub że pracownicy będą mogli korzystać tylko z danych dla swojego działu.

Poniżej znajdują się kroki dotyczące konfiguracji dwóch użytkowników z różnym dostępem do Sales.SalesOrderHeader stołu na poziomie rzędów.

Stwórz dwa konta użytkowników, aby przetestować bezpieczeństwo na poziomie wiersza:

USE AdventureWorks2025;
GO

CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;

Udziel dostępu do odczytu w tabeli Sales.SalesOrderHeader wszystkim użytkownikom.

GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;

Utwórz nowy schemat i wbudowaną funkcję tabelaryczną. Funkcja zwraca się 1 , gdy wiersz w kolumnie SalesPersonID odpowiada identyfikatorowi SalesPerson logowania lub gdy użytkownik wykonujący zapytanie jest użytkownikiem samym Manager .

CREATE SCHEMA Security;
GO

CREATE FUNCTION Security.fn_securitypredicate
(@SalesPersonID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
    SELECT 1 AS fn_securitypredicate_result
    WHERE ('SalesPerson' + CAST (@SalesPersonId AS VARCHAR (16)) = USER_NAME())
          OR (USER_NAME() = 'Manager')

Utwórz zasadę zabezpieczeń, dodając funkcję zarówno jako filtr, jak i predykat blokujący w tabeli.

CREATE SECURITY POLICY SalesFilter
    ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader,
    ADD BLOCK PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader
    WITH (STATE = ON);

Wykonaj następujące instrukcje, aby zapytać tabelę SalesOrderHeader jako każdy użytkownik. Sprawdź, czy SalesPerson280 widzi tylko 95 wierszy z własnej sprzedaży i czy Manager widzi wszystkie wiersze w tabeli.

EXECUTE AS USER = 'SalesPerson280';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

EXECUTE AS USER = 'Manager';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

Zmień politykę bezpieczeństwa, aby ją wyłączyć. Teraz obaj użytkownicy mogą uzyskiwać dostęp do wszystkich wierszy.

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

Włączanie dynamicznego maskowania danych

Dynamiczne maskowanie danych umożliwia ograniczenie ujawnienia poufnych danych użytkownikom aplikacji przez całkowite lub częściowe maskowanie niektórych kolumn.

Użyj instrukcji ALTER TABLE , aby dodać funkcję maskowania do EmailAddress kolumny w Person.EmailAddress tabeli:

USE AdventureWorks2025;
GO

ALTER TABLE Person.EmailAddress
    ALTER COLUMN EmailAddress
        ADD MASKED WITH (FUNCTION = 'email()');

Utworzenie nowego użytkownika TestUser z SELECT uprawnieniami do tabeli, a następnie wykonanie zapytania TestUser o podgląd zamaskowanych danych:

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT
    ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID,
       EmailAddress
FROM Person.EmailAddress;

REVERT;

Sprawdź, czy funkcja maskowania zmienia adres e-mail w pierwszym rekordzie z:

EmailAddressID Adres e-mail
1 ken0@adventure-works.com

do

EmailAddressID Adres e-mail
1 kXXX@XXXX.com

Włączanie przezroczystego szyfrowania danych

Atakujący może ukraść pliki bazy danych z Twojego dysku twardego. Może się to zdarzyć, gdy atakujący uzyska podwyższony dostęp do systemu, gdy pracownik przejmie pliki lub jeśli ktoś ukradnie komputer, w którym pliki się znajdują.

Funkcja Transparent Data Encryption (TDE) szyfruje pliki danych, ponieważ są przechowywane na dysku twardym. Baza master danych SQL Server Database Engine posiada klucz szyfrujący, dzięki czemu Database Engine może manipulować danymi. Nie można odczytać plików bazy danych bez dostępu do klucza. Administratorzy wysokiego szczebla mogą zarządzać, tworzyć kopie zapasowe i odtwarzać klucz, tak aby tylko wybrane osoby mogły przenosić bazę danych. Po włączeniu TDE, SQL Server automatycznie szyfruje bazę tempdb danych.

Ponieważ Database Engine może odczytywać dane, TDE nie chroni przed nieautoryzowanym dostępem administratorów komputerów, którzy mogą bezpośrednio odczytywać pamięć lub uzyskać dostęp do SQL Server przez konto administratora.

Konfigurowanie TDE

  • Utwórz klucz główny
  • Tworzenie lub uzyskiwanie certyfikatu chronionego przez klucz główny
  • Stwórz klucz szyfrujący bazę danych i chroń go certyfikatem
  • Ustawianie bazy danych do używania szyfrowania

Konfigurowanie TDE wymaga posiadania CONTROL uprawnień do master bazy danych oraz CONTROL uprawnień do bazy danych użytkownika. Zazwyczaj administrator konfiguruje funkcję TDE.

Poniższy przykład ilustruje szyfrowanie i odszyfrowanie bazy AdventureWorks2025 danych przy zainstalowanym na serwerze certyfikatu MyServerCert .

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My Database Encryption Key Certificate';
GO

USE AdventureWorks2025;
GO

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION ON;

Aby usunąć funkcję TDE, uruchom następujące polecenie:

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION OFF;

SQL Server planuje operacje szyfrowania i deszyfrowania na wątkach w tle. Status tych operacji możesz zobaczyć w widokach katalogowych i dynamicznych w liście znajdującej się później w tym artykule.

Warning

Klucz szyfrowania bazy danych szyfruje także pliki kopii zapasowych baz danych, które mają włączone TDE. W związku z tym po przywróceniu tych kopii zapasowych certyfikat chroniący klucz szyfrowania bazy danych musi być dostępny. Oprócz tworzenia kopii zapasowych bazy danych, musisz też zrobić kopie zapasowe certyfikatów serwera, aby zapobiec utracie danych. Utrata danych następuje, jeśli certyfikat nie jest już dostępny. Aby uzyskać więcej informacji, zobacz certyfikaty programu SQL Server i klucze asymetryczne.

Aby uzyskać więcej informacji na temat technologii TDE, zobacz Transparent Data Encryption (TDE).

Konfigurowanie szyfrowania kopii zapasowych

SQL Server może szyfrować dane podczas tworzenia kopii zapasowej. Określając algorytm szyfrowania i szyfrujący (certyfikat lub klucz asymetryczny) podczas tworzenia kopii zapasowej, można utworzyć zaszyfrowany plik kopii zapasowej.

Warning

Zawsze rób kopię zapasową certyfikatu lub klucza asymetrycznego, najlepiej w innym miejscu niż plik kopii zapasowej, którą szyfruje. Bez certyfikatu lub klucza asymetrycznego nie można przywrócić kopii zapasowej, co spowoduje, że plik kopii zapasowej będzie bezużyteczny.

Poniższy przykład tworzy certyfikat, a następnie tworzy kopię zapasową chronioną przez certyfikat.

USE master;
GO

CREATE CERTIFICATE BackupEncryptCert
    WITH SUBJECT = 'Database backups';
GO

BACKUP DATABASE [AdventureWorks2025]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2025.bak'
WITH COMPRESSION,
    ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
    STATS = 10;
GO

Aby uzyskać więcej informacji, zobacz Szyfrowanie kopii zapasowych.

Treści powiązane

  • Last updated on