Dela via

Genomgång av säkerhetsfunktionerna i SQL Server i Linux

Gäller för:SQL Server i Linux

Om du är en Linux-användare som är nybörjare på SQL Server går följande uppgifter igenom några av säkerhetsuppgifterna. Dessa är inte unika eller specifika för Linux, men det hjälper dig att ge dig en uppfattning om områden att undersöka ytterligare. I varje exempel finns en länk till den djupgående dokumentationen för det området.

Kodexemplen i den här artikeln använder AdventureWorks2025- eller AdventureWorksDW2025-exempeldatabasen, som du kan ladda ned från startsidan Microsoft SQL Server Samples och Community Projects.

Skapa en inloggning och en databasanvändare

Ge andra åtkomst till SQL Server genom att skapa en inloggning i master databasen med hjälp av INSTRUKTIONEN SKAPA INLOGGNING . Till exempel:

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

Försiktighet

Lösenordet bör följa SQL Server-standardprincipen för lösenord. Lösenordet måste som standard vara minst åtta tecken långt och innehålla tecken från tre av följande fyra uppsättningar: versaler, gemener, bas-10 siffror och symboler. Lösenord kan vara upp till 128 tecken långa. Använd lösenord som är så långa och komplexa som möjligt.

Inloggningar kan ansluta till SQL Server och ha åtkomst (med begränsad behörighet) till master databasen. För att ansluta till en användardatabas behöver en inloggning en motsvarande identitet på databasnivå, som kallas databasanvändare. Användarna är specifika för varje databas och måste skapas separat i varje databas för att ge dem åtkomst. I följande exempel flyttas du till AdventureWorks2025 databasen och använder sedan instruktionen SKAPA ANVÄNDARE för att skapa en användare med namnet Larry som är associerad med inloggningen med namnet Larry. Även om inloggningen och användaren är relaterade (mappade till varandra) är de olika objekt. Inloggningen är ett huvudsäkerhetsobjekt på servernivå. Användaren är en aktör på databasnivå.

USE AdventureWorks2022;
GO

CREATE USER Larry;
GO
  • Ett SQL Server-administratörskonto kan ansluta till valfri databas och kan skapa fler inloggningar och användare i valfri databas.
  • När någon skapar en databas blir de databasägare, som kan ansluta till databasen. Databasägare kan skapa fler användare.

Senare kan du auktorisera andra inloggningar för att skapa fler inloggningar genom att ge dem behörigheten ALTER ANY LOGIN . I en databas kan du ge andra användare behörighet att skapa fler användare genom att ge dem behörigheten ALTER ANY USER . Till exempel:

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2022;
GO

GRANT ALTER ANY USER TO Jerry;
GO

Nu kan inloggningen Larry skapa fler inloggningar och användaren Jerry kan skapa fler användare.

Bevilja åtkomst med minsta möjliga behörighet

De första som ansluter till en användardatabas är administratörs- och databasägarkontona. Dessa användare har dock alla behörigheter som är tillgängliga för databasen. Det här är mer behörighet än de flesta användare borde ha.

När du precis har börjat kan du tilldela vissa allmänna behörighetskategorier med hjälp av de inbyggda fasta databasrollerna. Till exempel kan db_datareader fast databasroll läsa alla tabeller i databasen, men inte göra några ändringar. Bevilja medlemskap i en fast databasroll med hjälp av ALTER ROLE-instruktionen . I följande exempel lägger du till användaren Jerry i db_datareader fast databasroll.

USE AdventureWorks2022;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

En lista över de fasta databasrollerna finns i Roller på databasnivå.

När du senare är redo att konfigurera mer exakt åtkomst till dina data (rekommenderas starkt) skapar du dina egna användardefinierade databasroller med hjälp av CREATE ROLE-instruktionen . Tilldela sedan specifika detaljerade behörigheter till dina anpassade roller.

Följande instruktioner skapar till exempel en databasroll med namnet Sales, ger Sales gruppen möjlighet att se, uppdatera och ta bort rader från Orders tabellen och sedan lägga till användaren Jerry i Sales rollen.

CREATE ROLE Sales;

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

ALTER ROLE Sales ADD MEMBER Jerry;

Mer information om behörighetssystemet finns i Komma igång med behörigheter för databasmotorn.

Konfigurera säkerhet på radnivå

Med säkerhet på radnivå kan du begränsa åtkomsten till rader i en databas baserat på användaren som kör en fråga. Den här funktionen är användbar för scenarier som att se till att kunderna bara kan komma åt sina egna data eller att arbetare bara kan komma åt data som är relevanta för deras avdelning.

Följande steg går igenom hur du konfigurerar två användare med olika åtkomst på radnivå till Sales.SalesOrderHeader tabellen.

Skapa två användarkonton för att testa säkerhet på radnivå:

USE AdventureWorks2022;
GO

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

Bevilja läsbehörighet i Sales.SalesOrderHeader tabellen till båda användarna:

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

Skapa ett nytt schema och infogad tabellvärdesfunktion. Funktionen returnerar 1 när en rad i SalesPersonID kolumnen matchar ID:t för en SalesPerson inloggning eller om användaren som kör frågan är Manager-användaren.

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')

Skapa en säkerhetsprincip som lägger till funktionen som både ett filter och ett blockpredikat i tabellen:

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);

Kör följande för att hämta tabellen SalesOrderHeader för varje användare. Kontrollera att SalesPerson280 endast ser de 95 raderna från sin egen försäljning och att Manager kan se alla rader i tabellen.

EXECUTE AS USER = 'SalesPerson280';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

EXECUTE AS USER = 'Manager';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

Ändra säkerhetsprincipen för att inaktivera principen. Nu kan båda användarna komma åt alla rader.

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

Aktivera dynamisk datamaskering

Med dynamisk datamaskering kan du begränsa exponeringen av känsliga data för användare av ett program genom att helt eller delvis maskera vissa kolumner.

Använd en ALTER TABLE instruktion för att lägga till en maskeringsfunktion i EmailAddress kolumnen i Person.EmailAddress tabellen:

USE AdventureWorks2022;
GO

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

Skapa en ny användare TestUser med SELECT behörighet i tabellen och kör sedan en fråga för TestUser att visa maskerade data:

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT
    ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID,
       EmailAddress
FROM Person.EmailAddress;

REVERT;

Kontrollera att maskeringsfunktionen ändrar e-postadressen i den första posten från:

E-postadressID E-postadress
1 ken0@adventure-works.com

in

E-postadressID E-postadress
1 kXXX@XXXX.com

Aktivera transparent datakryptering

Ett hot mot databasen är risken att någon stjäl databasfilerna från hårddisken. Detta kan inträffa med ett intrång som får förhöjd åtkomst till systemet, genom åtgärder från en problemanställd eller genom stöld av den dator som innehåller filerna (till exempel en bärbar dator).

Transparent datakryptering (TDE) krypterar datafilerna när de lagras på hårddisken. Databasen master för SQL Server-databasmotorn har krypteringsnyckeln så att databasmotorn kan ändra data. Databasfilerna kan inte läsas utan åtkomst till nyckeln. Administratörer på hög nivå kan hantera, säkerhetskopiera och återskapa nyckeln så att databasen kan flyttas, men bara av valda personer. När TDE har konfigurerats tempdb krypteras även databasen automatiskt.

Eftersom databasmotorn kan läsa data skyddar TDE inte mot obehörig åtkomst av administratörer på datorn som direkt kan läsa minne eller komma åt SQL Server via ett administratörskonto.

Konfigurera TDE

  • Skapa en huvudnyckel
  • Skapa eller hämta ett certifikat som skyddas av huvudnyckeln
  • Skapa en databaskrypteringsnyckel och skydda den med certifikatet
  • Ange att databasen ska använda kryptering

För att konfigurera TDE krävs CONTROL behörighet för master databasen och CONTROL behörigheten för användardatabasen. Vanligtvis konfigurerar en administratör TDE.

I följande exempel visas kryptering och dekryptering AdventureWorks2025 av databasen med hjälp av ett certifikat som är installerat på servern med namnet 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 AdventureWorks2022;
GO

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

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION ON;

Kör följande kommando för att ta bort TDE:

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION OFF;

Krypterings- och dekrypteringsåtgärderna schemaläggs i bakgrundstrådar av SQL Server. Du kan visa status för dessa åtgärder med hjälp av katalogvyer och dynamiska hanteringsvyer i listan som visas senare i den här artikeln.

Varning

Säkerhetskopieringsfiler för databaser som har TDE aktiverat krypteras också med hjälp av databaskrypteringsnyckeln. När du återställer dessa säkerhetskopior måste därför certifikatet som skyddar databaskrypteringsnyckeln vara tillgängligt. Det innebär att förutom att säkerhetskopiera databasen måste du underhålla säkerhetskopior av servercertifikaten för att förhindra dataförlust. Dataförlust resulterar i att certifikatet inte längre är tillgängligt. Mer information finns i SQL Server-certifikat och asymmetriska nycklar.

Mer information om TDE finns i Transparent datakryptering (TDE).

Konfigurera kryptering för säkerhetskopiering

SQL Server har möjlighet att kryptera data när du skapar en säkerhetskopia. Genom att ange krypteringsalgoritmen och krypteringsnyckeln (ett certifikat eller en asymmetrisk nyckel) när du skapar en säkerhetskopia kan du skapa en krypterad säkerhetskopia.

Varning

Säkerhetskopiera alltid certifikatet eller den asymmetriska nyckeln, och helst till en annan plats än den säkerhetskopieringsfil som användes för att kryptera. Utan certifikatet eller den asymmetriska nyckeln kan du inte återställa säkerhetskopian, vilket gör säkerhetskopieringsfilen oanvändbar.

I följande exempel skapas ett certifikat och sedan skapas en säkerhetskopia som skyddas av certifikatet.

USE master;
GO

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

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

Mer information finns i Säkerhetskopieringskryptering.

Relaterat innehåll

  • Last updated on