Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:SQL Server op Linux
Als u een Linux-gebruiker bent die niet bekend is met SQL Server, worden enkele van de beveiligingstaken door de volgende taken begeleid. Deze taken zijn niet uniek of specifiek voor Linux, maar ze geven je een idee van gebieden die verder onderzocht moeten worden. Elk voorbeeld verwijst naar de diepgaande documentatie voor dat gebied.
De codevoorbeelden in dit artikel gebruiken de AdventureWorks2025 of AdventureWorksDW2025 voorbeelddatabase die u kunt downloaden van de startpagina van Microsoft SQL Server Samples en Community Projects .
Een aanmelding en een databasegebruiker maken
Geef anderen toegang tot SQL Server door een login aan te maken in de master database met de CREATE LOGIN instructie. Voorbeeld:
CREATE LOGIN Larry
WITH PASSWORD = '<password>';
Caution
Uw wachtwoord moet het SQL Server standaardbeleid voor password volgen. Standaard moet het wachtwoord ten minste acht tekens lang zijn en tekens bevatten uit drie van de volgende vier sets: hoofdletters, kleine letters, basis-10 cijfers en symbolen. Wachtwoorden mogen maximaal 128 tekens lang zijn. Gebruik wachtwoorden die zo lang en complex mogelijk zijn.
Gebruikersaccounts kunnen verbinding maken met SQL Server en toegang hebben (met beperkte machtigingen) tot de master database. Als u verbinding wilt maken met een gebruikersdatabase, moet een aanmelding een bijbehorende identiteit hebben op databaseniveau, een databasegebruiker genoemd. Gebruikers zijn specifiek voor elke database, dus je moet ze apart aanmaken in elke database om toegang te krijgen.
Het volgende voorbeeld schakelt over naar de AdventureWorks2025 database en gebruikt vervolgens de CREATE USER instructie om een gebruiker te maken met de naam Larry die overeenkomt met de loginnaam Larry. Hoewel de login en de gebruiker aan elkaar gekoppeld zijn (aan elkaar gekoppeld), zijn het verschillende objecten. De login is een principal op het niveau van de server. De gebruiker is een principal op databaseniveau.
USE AdventureWorks2025;
GO
CREATE USER Larry;
GO
- Een SQL Server-beheerdersaccount kan verbinding maken met elke database en meer aanmeldingen en gebruikers in elke database maken.
- Wanneer je een database aanmaakt, word je de eigenaar van de database en kun je verbinding maken met die database. Database-eigenaren kunnen meer gebruikers maken.
Later kunt u andere aanmeldingen autoriseren om meer aanmeldingen te maken door hen de ALTER ANY LOGIN machtiging te geven. In een database kunt u andere gebruikers machtigen om meer gebruikers te maken door hen de ALTER ANY USER machtiging te geven. Voorbeeld:
GRANT ALTER ANY LOGIN TO Larry;
GO
USE AdventureWorks2025;
GO
GRANT ALTER ANY USER TO Jerry;
GO
Nu kan de login Larry meer inlogs aanmaken, en de gebruiker Jerry kan meer gebruikers aanmaken.
Toegang verlenen met minimale bevoegdheden
Beheerders en database-eigenaren zijn meestal de eerste gebruikers die verbinding maken met een gebruikersdatabase. Deze accounts hebben alle rechten in de database. Gebruik deze accounts niet voor taken die minder rechten vereisen.
Als je net begint, kun je enkele algemene categorieën permissies toewijzen met de ingebouwde vaste databaserollen. Bijvoorbeeld, de db_datareader vaste databaserol kan alle tabellen in de database lezen, maar geen wijzigingen aanbrengen. Verleen lidmaatschap in een vaste databaserol met de ALTER ROLE verklaring. Het volgende voorbeeld voegt de gebruiker Jerry toe aan de db_datareader vaste databaserol.
USE AdventureWorks2025;
GO
ALTER ROLE db_datareader ADD MEMBER Jerry;
Zie Rollen op databaseniveau voor een lijst met de vaste databaserollen.
Later, wanneer je klaar bent om preciezere toegang tot je data te configureren (sterk aanbevolen), maak je je eigen door gebruikers gedefinieerde databaserollen aan met de CREATE ROLE statement. Wijs vervolgens specifieke gedetailleerde machtigingen toe aan uw aangepaste rollen.
Bijvoorbeeld, de volgende statements creëren een databaserol genaamd Sales, geven de Sales groep de mogelijkheid om rijen uit de Orders tabel te lezen, bij te werken en te verwijderen, en voegen vervolgens de gebruiker Jerry toe aan de Sales rol.
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;
Zie Aan de slag met database-enginemachtigingen voor meer informatie over het machtigingssysteem.
Beveiliging op rijniveau configureren
Beveiliging op rijniveau stelt je in staat om de toegang tot rijen in een database te beperken op basis van de gebruiker die een query uitvoert. Deze functie is nuttig voor scenario's zoals het waarborgen dat klanten alleen toegang hebben tot hun eigen data of dat werknemers alleen toegang hebben tot gegevens voor hun afdeling.
De volgende stappen laten zien hoe je twee gebruikers met verschillende rij-niveau toegang tot de Sales.SalesOrderHeader tabel opzet.
Maak twee gebruikersaccounts aan om de beveiliging op rijniveau te testen:
USE AdventureWorks2025;
GO
CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;
Verleen leestoegang op de Sales.SalesOrderHeader-tabel aan beide gebruikers:
GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;
Maak een nieuw schema en een inline-tabelwaardefunctie. De functie keert terug 1 wanneer een rij in de SalesPersonID kolom overeenkomt met de ID van een SalesPerson login, of wanneer de gebruiker die de query uitvoert de gebruiker zelf Manager is.
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')
Maak een beveiligingsbeleid voor het toevoegen van de functie als filter en een blokpredicaat in de tabel:
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);
Voer de volgende statements uit om de SalesOrderHeader tabel als elke gebruiker te bevragen.
SalesPerson280 Controleer of alleen de 95 rijen van hun eigen verkoop worden weergegeven en of alle Manager rijen in de tabel kunnen worden weergegeven.
EXECUTE AS USER = 'SalesPerson280';
SELECT *
FROM Sales.SalesOrderHeader;
REVERT;
EXECUTE AS USER = 'Manager';
SELECT *
FROM Sales.SalesOrderHeader;
REVERT;
Pas het beveiligingsbeleid aan om het uit te schakelen. Nu hebben beide gebruikers toegang tot alle rijen.
ALTER SECURITY POLICY SalesFilter
WITH (STATE = OFF);
Dynamische gegevensmaskering inschakelen
Met dynamische gegevensmaskering kunt u de blootstelling van gevoelige gegevens aan gebruikers van een toepassing beperken door bepaalde kolommen volledig of gedeeltelijk te maskeren.
Gebruik een ALTER TABLE instructie om een maskeringsfunctie toe te voegen aan de EmailAddress kolom in de Person.EmailAddress tabel:
USE AdventureWorks2025;
GO
ALTER TABLE Person.EmailAddress
ALTER COLUMN EmailAddress
ADD MASKED WITH (FUNCTION = 'email()');
Maak een nieuwe gebruiker TestUser aan met SELECT rechten op de tabel, en voer vervolgens een query uit om TestUser de gemaskeerde data te bekijken:
CREATE USER TestUser WITHOUT LOGIN;
GRANT SELECT
ON Person.EmailAddress TO TestUser;
EXECUTE AS USER = 'TestUser';
SELECT EmailAddressID,
EmailAddress
FROM Person.EmailAddress;
REVERT;
Controleer of de maskeringsfunctie het e-mailadres in de eerste record wijzigt van:
| E-mailadresID | E-mailadres |
|---|---|
| 1 | ken0@adventure-works.com |
in
| E-mailadresID | E-mailadres |
|---|---|
| 1 | kXXX@XXXX.com |
Transparante gegevensversleuteling inschakelen
Een aanvaller kan databasebestanden van je harde schijf stelen. Dit kan gebeuren als een aanvaller verhoogde toegang tot het systeem krijgt, als een medewerker de bestanden meeneemt, of als iemand de computer steelt waarop de bestanden staan.
Met Transparent Data Encryption (TDE) worden de gegevensbestanden versleuteld terwijl ze op de harde schijf worden opgeslagen. De master database van de SQL Server Database Engine heeft de encryptiesleutel, zodat de Database Engine de gegevens kan manipuleren. De databasebestanden kunnen niet worden gelezen zonder toegang tot de sleutel. Beheerders op hoog niveau kunnen de sleutel beheren, back-uppen en opnieuw aanmaken, zodat alleen geselecteerde personen de database kunnen verplaatsen. Wanneer je TDE inschakelt, versleutelt SQL Server ook automatisch de tempdb database.
Omdat de Database Engine de gegevens kan lezen, beschermt TDE niet tegen ongeautoriseerde toegang door computerbeheerders die direct geheugen kunnen lezen of SQL Server via een beheerdersaccount kunnen benaderen.
TDE configureren
- Een hoofdsleutel maken
- Een certificaat maken of verkrijgen dat is beveiligd met de hoofdsleutel
- Maak een database-encryptiesleutel aan en bescherm deze met het certificaat
- De database instellen voor het gebruik van versleuteling
Voor het configureren van TDE zijn CONTROL-machtigingen vereist voor de master-database en CONTROL-machtigingen voor de gebruikersdatabase. Doorgaans configureert een beheerder TDE.
Het volgende voorbeeld illustreert het versleutelen en ontsleutelen van de AdventureWorks2025 database met een certificaat genaamd geïnstalleerd MyServerCert op de server.
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;
Als u TDE wilt verwijderen, voert u de volgende opdracht uit:
ALTER DATABASE AdventureWorks2025
SET ENCRYPTION OFF;
SQL Server plant de encryptie- en ontsleutelingsoperaties op achtergrondthreads. Je kunt de status van deze bewerkingen bekijken met de catalogusweergaven en dynamische beheerweergaven in de lijst die later in dit artikel verschijnt.
Warning
De database-encryptiesleutel versleutelt ook back-upbestanden van databases die TDE hebben ingeschakeld. Als u deze back-ups herstelt, moet het certificaat dat de databaseversleutelingssleutel beveiligt, beschikbaar zijn. Naast het back-uppen van de database moet je ook de servercertificaten back-uppen om dataverlies te voorkomen. Gegevensverlies als het certificaat niet langer beschikbaar is. Zie SQL Server-certificaten en asymmetrische sleutels voor meer informatie.
Zie TDE (Transparent Data Encryption) voor meer informatie over TDE.
Back-upversleuteling configureren
SQL Server kan data versleutelen tijdens het maken van een back-up. Door het versleutelingsalgoritmen en de versleuteler (een certificaat of asymmetrische sleutel) op te geven bij het maken van een back-up, kunt u een versleuteld back-upbestand maken.
Warning
Maak altijd een back-up van het certificaat of de asymmetrische sleutel, en bij voorkeur naar een andere locatie dan het back-upbestand dat het versleutelt. Zonder het certificaat of de asymmetrische sleutel kunt u de back-up niet herstellen, waardoor het back-upbestand onbruikbaar wordt.
In het volgende voorbeeld wordt een certificaat gemaakt en wordt vervolgens een back-up gemaakt die wordt beveiligd door het certificaat.
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
Zie Back-upversleuteling voor meer informatie.