Procedura dettagliata per le funzionalità di sicurezza di SQL Server in Linux
Si applica a: SQL Server - Linux
Le attività seguenti illustrano alcune delle attività di sicurezza per gli utenti Linux che non hanno familiarità con SQL Server. Queste attività non sono univoche o specifiche di Linux, ma offrono un'idea delle aree da approfondire. In ogni esempio viene fornito un collegamento alla documentazione dettagliata dell'area.
Gli esempi di codice Transact-SQL in questo articolo utilizzano il database campione AdventureWorks2022
o AdventureWorksDW2022
, che è possibile scaricare dalla home page di Esempi di Microsoft SQL Server e progetti collettivi.
Creare un account di accesso e un utente del database
Per concedere ad altri l'accesso a SQL Server, creare un account di accesso nel database master
usando l'istruzione CREATE LOGIN. Ad esempio:
CREATE LOGIN Larry
WITH PASSWORD = '<password>';
Attenzione
La password deve seguire i criteri password predefiniti di SQL Server. Per impostazione predefinita, la password deve essere composta da almeno otto caratteri e contenere caratteri di tre delle quattro categorie seguenti: lettere maiuscole, lettere minuscole, cifre in base 10 e simboli. Le password possono contenere fino a 128 caratteri. Usare password il più possibile lunghe e complesse.
Gli account di accesso possono connettersi a SQL Server e avere accesso (con autorizzazioni limitate) al database master
. Per connettersi a un database utente, un account di accesso deve avere un'identità corrispondente a livello di database, denominata utente del database. Gli utenti sono specifici di ogni database e devono essere creati separatamente in ogni database per concedere loro l'accesso. L'esempio seguente consente di passare al database AdventureWorks2022
e quindi usa l'istruzione CREATE USER per creare un utente denominato Larry associato all'account di accesso denominato Larry
. Nonostante l'account di accesso e l'utente siano correlati (associati l'uno all'altro), sono oggetti diversi. L'account di accesso è un'entità a livello di server. L'utente è un'entità a livello di database.
USE AdventureWorks2022;
GO
CREATE USER Larry;
GO
- Un account amministratore di SQL Server può connettersi a qualsiasi database e può creare altri account di accesso e altri utenti in qualsiasi database.
- Quando un utente crea un database, diventa il proprietario del database, che può connettersi a tale database. I proprietari dei database possono creare altri utenti.
In seguito è possibile autorizzare gli altri account di accesso a creare ulteriori account di accesso concedendo loro l'autorizzazione ALTER ANY LOGIN
. In un database è possibile autorizzare altri utenti a creare ulteriori utenti concedendo loro l'autorizzazione ALTER ANY USER
. Ad esempio:
GRANT ALTER ANY LOGIN TO Larry;
GO
USE AdventureWorks2022;
GO
GRANT ALTER ANY USER TO Jerry;
GO
A questo punto, l'account di accesso Larry può creare altri account di accesso e l'utente Jerry
può creare altri utenti.
Concedere l'accesso con privilegi minimi
Le prime persone a connettersi a un database utente sono gli account dell'amministratore e del proprietario del database. Tuttavia, questi utenti hanno tutte le autorizzazioni disponibili per il database. Si tratta di un'autorizzazione più elevata di quella della maggior parte degli utenti.
All'inizio, è possibile assegnare alcune categorie generali di autorizzazioni usando i ruoli predefiniti del database predefiniti. Il ruolo predefinito del database db_datareader, ad esempio, può leggere tutte le tabelle del database, ma non apportare modifiche. Per concedere l'appartenenza a un ruolo predefinito del database, usare l'istruzione ALTER ROLE. L'esempio seguente aggiunge l'utente Jerry
al ruolo predefinito del database db_datareader.
USE AdventureWorks2022;
GO
ALTER ROLE db_datareader ADD MEMBER Jerry;
Per un elenco dei ruoli predefiniti del database, vedere Ruoli a livello di database.
In seguito, quando si è pronti per configurare un accesso più preciso ai dati (scelta consigliata), creare ruoli del database definiti dall'utente usando l'istruzione CREATE ROLE. Assegnare quindi autorizzazioni granulari specifiche ai ruoli personalizzati.
Le istruzioni seguenti, ad esempio, creano un ruolo del database denominato Sales
, concede al gruppo Sales
la possibilità di visualizzare, aggiornare ed eliminare righe dalla tabella Orders
e quindi aggiunge l'utente Jerry
al ruolo Sales
.
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;
Per altre informazioni sul sistema di autorizzazioni, vedere Introduzione alle autorizzazioni di motore di database.
Configurare la sicurezza a livello di riga
La sicurezza a livello di riga consente di limitare l'accesso alle righe in un database in base all'utente che esegue una query. Questa funzionalità è utile per situazioni in cui, ad esempio, si deve garantire che i clienti possano accedere solo ai propri dati o che i ruoli di lavoro possano accedere solo ai dati pertinenti al proprio reparto.
I passaggi seguenti illustrano come configurare due utenti con accesso a livello di riga diverso alla tabella Sales.SalesOrderHeader
.
Creare due account utente per testare la sicurezza a livello di riga:
USE AdventureWorks2022;
GO
CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;
Concedere l'accesso in lettura alla tabella Sales.SalesOrderHeader
a entrambi gli utenti:
GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;
Creare un nuovo schema e una funzione con valori di tabella inline. La funzione restituisce 1 quando una riga della colonna SalesPersonID
corrisponde all'ID di un accesso SalesPerson
o se l'utente che esegue la query o se l'utente che esegue la query è l'utente gestore.
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')
Creare un criterio di sicurezza aggiungendo la funzione sia come predicato di filtro e predicato di blocco nella tabella:
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);
Eseguire una query sulla tabella SalesOrderHeader
come ogni utente usando il comando riportato di seguito. Verificare che SalesPerson280
veda solo le 95 righe relative alle proprie vendite e che Manager
possa visualizzare tutte le righe della tabella.
EXECUTE AS USER = 'SalesPerson280';
SELECT *
FROM Sales.SalesOrderHeader;
REVERT;
EXECUTE AS USER = 'Manager';
SELECT *
FROM Sales.SalesOrderHeader;
REVERT;
Modificare i criteri di sicurezza per disabilitarli. Ora entrambi gli utenti possono accedere a tutte le righe.
ALTER SECURITY POLICY SalesFilter
WITH (STATE = OFF);
Abilitare il Dynamic Data Masking
La maschera dati dinamica consente di limitare l'esposizione dei dati sensibili agli utenti di un'applicazione mascherando completamente o parzialmente determinate colonne.
Usare un'istruzione ALTER TABLE
per aggiungere una funzione di mascheramento alla colonna EmailAddress
della tabella Person.EmailAddress
:
USE AdventureWorks2022;
GO
ALTER TABLE Person.EmailAddress
ALTER COLUMN EmailAddress
ADD MASKED WITH (FUNCTION = 'email()');
Creare un nuovo utente TestUser
con autorizzazione SELECT
per la tabella, quindi eseguire una query come TestUser
per visualizzare i dati mascherati:
CREATE USER TestUser WITHOUT LOGIN;
GRANT SELECT
ON Person.EmailAddress TO TestUser;
EXECUTE AS USER = 'TestUser';
SELECT EmailAddressID,
EmailAddress
FROM Person.EmailAddress;
REVERT;
Verificare che la funzione di mascheramento cambi l'indirizzo di posta elettronica nel primo record da:
EmailAddressID | EmailAddress |
---|---|
1 | ken0@adventure-works.com |
into
EmailAddressID | EmailAddress |
---|---|
1 | kXXX@XXXX.com |
Abilitare Transparent Data Encryption
Una minaccia per il database è il rischio che qualcuno rubi i file di database dal disco rigido. Questo problema può verificarsi con un'intrusione che ottiene l'accesso con privilegi elevati al sistema, sfruttando le azioni di un dipendente problematico o con il furto del computer che contiene i file, ad esempio un portatile.
Transparent Data Encryption (TDE) crittografa i file di dati archiviati nel disco rigido. Il database master
del motore di database di SQL Server ha la chiave di crittografia, in modo che il motore di database possa modificare i dati. Non è possibile leggere i file di database senza accedere alla chiave. Gli amministratori di livello elevato possono gestire la chiave, eseguirne il backup e ricrearla, in modo che il database possa essere spostato, ma solo da utenti selezionati. Quando si configura Transparent Data Encryption, anche il database tempdb
viene crittografato automaticamente.
Poiché il motore di database è in grado di leggere i dati, TDE non protegge dall'accesso non autorizzato da parte degli amministratori del computer che possono leggere direttamente la memoria o accedere a SQL Server usando un account amministratore.
Configurare Transparent Data Encryption
- Creare una chiave master
- Creare o ottenere un certificato protetto dalla chiave master
- Creare una chiave di crittografia del database e proteggerla mediante il certificato
- Impostare il database per l'uso della crittografia
La configurazione di TDE richiede CONTROL
l'autorizzazione per il master
database e CONTROL
l'autorizzazione per il database utente. In genere, un amministratore configura Transparent Data Encryption.
L'esempio seguente illustra come crittografare e decrittografare il database AdventureWorks2022
usando un certificato installato nel server denominato 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;
Per rimuovere TDE, usare il comando seguente.
ALTER DATABASE AdventureWorks2022
SET ENCRYPTION OFF;
Le operazioni di crittografia e decrittografia sono pianificate sui thread di background da SQL Server. Per visualizzare lo stato di queste operazioni, è possibile usare le viste del catalogo e le viste a gestione dinamica nell'elenco illustrato di seguito in questo articolo.
Avviso
I file di backup dei database in cui è abilitata la funzionalità TDE vengono crittografati anche tramite la chiave di crittografia del database. Di conseguenza, quando questi backup vengono ripristinati, è necessario disporre del certificato che protegge la chiave di crittografia del database. Pertanto, oltre ad eseguire il backup del database, assicurarsi di conservare un backup dei certificati server per impedire la perdita di dati. Se il certificato non è più disponibile, si verificherà la perdita di dati. Per altre informazioni, vedere SQL Server Certificates and Asymmetric Keys.
Per altre informazioni su TDE, vedere Transparent Data Encryption (TDE).
Configurare la crittografia di backup
SQL Server permette di crittografare i dati durante la creazione di un backup. Specificando l'algoritmo di crittografia e il componente di crittografia (certificato o chiave asimmetrica) durante la creazione di un backup, è possibile creare un file di backup crittografato.
Avviso
Eseguire sempre il backup del certificato o della chiave asimmetrica e preferibilmente in un percorso diverso dal file di backup utilizzato per la crittografia. Senza il certificato o la chiave asimmetrica, non è possibile ripristinare il backup, rendendo il file di backup inutilizzabile.
Nell'esempio seguente viene creato un certificato, quindi un backup protetto dal certificato.
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
Per altre informazioni, vedere Crittografia del backup.