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 AdventureWorksDW2025, AdventureWorksLT2025 lub AdventureWorks2025, którą można pobrać z repozytorium GitHub Azure Data SQL Samples Repository.

Tworzenie nazwy logowania i użytkownika bazy danych

Udziel innym dostępu do SQL Server, tworząc login w bazie danych master za pomocą instrukcji CREATE LOGIN. Przykład:

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

Logowania mogą łączyć się z programem SQL Server i mieć dostęp (z ograniczonymi uprawnieniami) do master bazy danych. Aby połączyć się z bazą użytkownika, login musi mieć odpowiadający mu identyfikator na poziomie bazy danych, nazywany 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 się do bazy danych AdventureWorks2025, a następnie używa instrukcji CREATE USER do utworzenia użytkownika o nazwie Sasha, mapowanego na login o nazwie Sasha. 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 Sasha;
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 Sasha;
GO

USE AdventureWorks2025;
GO

GRANT ALTER ANY USER TO Sasha;
GO

Teraz logowanie Sasha może generować więcej logowań, a użytkownik Sasha 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. Przypisywanie członkostwa w stałej roli bazy danych za pomocą instrukcji ALTER ROLE. Poniższy przykład dodaje użytkownika Sasha do roli db_datareader stałej bazy danych.

USE AdventureWorks2025;
GO

ALTER ROLE db_datareader ADD MEMBER Sasha;

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

Później, gdy będziesz gotowy skonfigurować bardziej precyzyjny dostęp do swoich danych (co jest zdecydowanie zalecane), utwórz własne, zdefiniowane przez użytkownika role bazy danych za pomocą instrukcji CREATE ROLE. 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 Sasha 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 Sasha;

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ższe kroki opisują konfigurowanie dwóch użytkowników z różnym dostępem do tabeli Sales.SalesOrderHeader na poziomie wierszy.

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 1, gdy wiersz w kolumnie SalesPersonID jest zgodny z identyfikatorem użytkownika SalesPerson lub gdy użytkownik uruchamiający zapytanie jest użytkownikiem 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 wykonać zapytanie do tabeli SalesOrderHeader jako każdy z użytkowników. 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:

do

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 odszyfrowywanie bazy danych AdventureWorks2025 za pomocą certyfikatu o nazwie MyServerCert, zainstalowanego na serwerze.

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. Stan tych operacji można wyświetlić w widokach katalogowych i dynamicznych widokach zarządzania wymienionych na liście zamieszczonej w dalszej części tego artykułu.

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.

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

• Zabezpieczenia silnika bazy danych SQL Server i Azure SQL Database