Procédure pas à pas pour les fonctionnalités de sécurité de SQL Server sur Linux

S’applique à :SQL Server sur Linux

Si vous êtes un utilisateur de Linux nouveau dans SQL Server, les tâches suivantes vous guident tout au long des tâches de sécurité. Ces tâches ne sont pas uniques ou spécifiques à Linux, mais elles donnent une idée des domaines à explorer davantage. Chaque exemple renvoie à la documentation détaillée de ce domaine.

Les exemples de code de cet article utilisent les bases de données d'exemple AdventureWorks2025 ou AdventureWorksDW2025, que vous pouvez télécharger à partir de la page d'accueil Microsoft SQL Server Samples and Community Projects.

Créer une connexion et un utilisateur de base de données

Accordez à d’autres l’accès à SQL Server en créant une connexion dans la master base de données avec la CREATE LOGIN déclaration. Par exemple:

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

Les identifiants de connexion peuvent se connecter à SQL Server et avoir accès à la base de données master (avec des autorisations limitées). Pour se connecter à une base de données utilisateur, une connexion a besoin d’une identité correspondante au niveau de la base de données, appelé utilisateur de base de données. Les utilisateurs sont spécifiques à chaque base de données, donc vous devez les créer séparément dans chaque base de données pour accorder l’accès.

L’exemple suivant bascule vers la AdventureWorks2025 base de données, puis utilise l’instruction CREATE USER pour créer un utilisateur nommé Larry qui correspond à la connexion nommée Larry. Bien que la connexion et l’utilisateur soient liés (mappés l’un à l’autre), ce sont des objets différents. La connexion est un principal au niveau du serveur. L’utilisateur est un principal au niveau de la base de données.

USE AdventureWorks2025;
GO

CREATE USER Larry;
GO

• Un compte d’administrateur SQL Server peut se connecter à n’importe quelle base de données et peut créer des connexions et des utilisateurs supplémentaires dans n’importe quelle base de données.
• Lorsque vous créez une base de données, vous devenez le propriétaire de la base de données et pouvez vous connecter à cette base. Les propriétaires de bases de données peuvent créer davantage d’utilisateurs.

Plus tard, vous pouvez autoriser d’autres connexions pour créer un plus grand nombre de connexions en leur accordant l’autorisation ALTER ANY LOGIN. Dans une base de données, vous pouvez autoriser d’autres utilisateurs à créer davantage d’utilisateurs en leur accordant l’autorisation ALTER ANY USER. Par exemple:

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2025;
GO

GRANT ALTER ANY USER TO Jerry;
GO

Désormais, la connexion Larry peut créer plus de connexions, et l’utilisateur Jerry peut créer plus d’utilisateurs.

Accordez un accès selon le principe du moindre privilège

Les administrateurs et propriétaires de bases de données sont généralement les premiers utilisateurs à se connecter à une base de données. Tous ces comptes ont toutes les permissions sur la base de données. N’utilisez pas ces comptes pour des tâches nécessitant moins d’autorisations.

Lorsque vous débutez, vous pouvez attribuer quelques catégories générales de permissions avec les rôles de base de données fixes intégrés. Par exemple, le rôle de base de données fixe db_datareader peut lire toutes les tables de la base de données, mais ne peut pas effectuer de modifications. Accordez l’adhésion à un rôle de base de données fixe avec la déclaration ALTER ROLE . L’exemple suivant ajoute l’utilisateur Jerry au rôle db_datareader de base de données fixe.

USE AdventureWorks2025;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

Pour obtenir une liste des rôles de base de données fixes, consultez Rôles au niveau de la base de données.

Plus tard, lorsque vous serez prêt à configurer un accès plus précis à vos données (fortement recommandé), créez vos propres rôles de base de données définis par l’utilisateur avec cette CREATE ROLE instruction. Attribuez ensuite des autorisations granulaires spécifiques à vos rôles personnalisés.

Par exemple, les instructions suivantes créent un rôle de base de données nommé Sales, accordent au Sales groupe la capacité de lire, mettre à jour et supprimer des lignes de la Orders table, puis d’ajouter l’utilisateur Jerry au Sales rôle.

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;

Pour plus d'informations sur le système d'autorisations, consultez Prise en main des autorisations du moteur de base de données.

Configurer la sécurité au niveau des lignes

La sécurité au niveau des lignes vous permet de restreindre l’accès aux lignes d’une base de données en fonction de l’utilisateur qui effectue une requête. Cette fonctionnalité est utile pour des situations comme s’assurer que les clients ne peuvent accéder qu’à leurs propres données ou que les employés ne peuvent accéder qu’aux données de leur département.

Les étapes suivantes expliquent comment configurer deux utilisateurs avec un accès différent au niveau des lignes à la Sales.SalesOrderHeader table.

Créez deux comptes utilisateurs pour tester la sécurité au niveau des lignes :

USE AdventureWorks2025;
GO

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

Accordez l'accès en lecture sur la table Sales.SalesOrderHeader aux deux utilisateurs :

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

Créez un nouveau schéma et une fonction table inline. La fonction se raffiche 1 lorsqu’une ligne de la SalesPersonID colonne correspond à l’ID d’un SalesPerson identifiant, ou lorsque l’utilisateur qui lance la requête est l’utilisateur.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')

Créez une stratégie de sécurité qui ajoute cette fonction en tant que prédicat de filtre et prédicat BLOCK sur la table :

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

Exécutez les instructions suivantes pour interroger la SalesOrderHeader table en tant qu’utilisateur. Vérifiez que SalesPerson280 ne voit que les 95 lignes correspondant à ses propres ventes et que Manager peut voir toutes les lignes de la table.

EXECUTE AS USER = 'SalesPerson280';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

EXECUTE AS USER = 'Manager';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

Modifie la politique de sécurité pour la désactiver. Désormais, les deux utilisateurs peuvent accéder à toutes les lignes.

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

Activer le masquage des données dynamiques

Le masquage dynamique des données vous permet de limiter l'exposition des données sensibles aux utilisateurs d'une application en masquant totalement ou partiellement certaines colonnes.

Utilisez une instruction ALTER TABLE pour ajouter une fonction de masquage à la colonne EmailAddress de la table Person.EmailAddress :

USE AdventureWorks2025;
GO

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

Créez un nouvel utilisateur TestUser avec SELECT une permission sur la table, puis exécutez une requête pour TestUser visualiser les données masquées :

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT
    ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID,
       EmailAddress
FROM Person.EmailAddress;

REVERT;

Vérifiez que la fonction de masquage modifie l’adresse de messagerie dans le premier enregistrement de :

en

Activer le chiffrement transparent des données

Un attaquant peut voler des fichiers de base de données sur votre disque dur. Cela peut se produire si un attaquant obtient un accès élevé au système, si un employé prend les fichiers, ou si quelqu’un vole l’ordinateur qui les détient.

Transparent Data Encryption (TDE) chiffre les fichiers de données au fur et à mesure qu’ils sont stockés sur le disque dur. La master base de données du Moteur de base de données SQL Server possède la clé de chiffrement, afin que le Moteur de base de données puisse manipuler les données. Les fichiers de base de données ne peuvent pas être lus sans accès à la clé. Les administrateurs de haut niveau peuvent gérer, sauvegarder et recréer la clé, de sorte que seules certaines personnes peuvent déplacer la base de données. Lorsque vous activez TDE, SQL Server chiffre également automatiquement la tempdb base de données.

Parce que le Moteur de base de données peut lire les données, TDE ne protège pas contre les accès non autorisés par les administrateurs informatiques qui peuvent lire directement la mémoire ou accéder à SQL Server via un compte administrateur.

Configurer TDE

• Créez une clé principale.
• Créez ou obtenez un certificat protégé par la clé principale.
• Créez une clé de chiffrement de base de données et protégez-la avec le certificat
• Configurez la base de données pour qu'elle utilise le chiffrement.

La configuration de TDE requiert une autorisation CONTROL sur la base de données master une autorisation CONTROL sur la base de données utilisateur. En général, un administrateur configure TDE.

L’exemple suivant illustre le chiffrement et le déchiffrement de la AdventureWorks2025 base de données avec un certificat nommé MyServerCert installé sur le serveur.

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;

Pour supprimer TDE, exécutez la commande suivante :

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION OFF;

SQL Server planifie les opérations de chiffrement et de déchiffrement sur des threads en arrière-plan. Vous pouvez consulter l’état de ces opérations avec les vues de catalogue et les vues de gestion dynamique dans la liste qui apparaît plus loin dans cet article.

Pour plus d'informations sur TDE, consultez Chiffrement transparent des données (TDE).

Configurer le chiffrement de sauvegarde

SQL Server peut chiffrer les données tout en créant une sauvegarde. En spécifiant l'algorithme de chiffrement et le chiffreur (un certificat ou une clé asymétrique) lors de la création d'une sauvegarde, vous créez un fichier de sauvegarde chiffré.

L’exemple suivant crée un certificat, puis crée une sauvegarde protégée par le certificat.

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

Pour plus d'informations, consultez Cryptage de sauvegarde.

Contenu connexe

• Sécurité pour le moteur de base de données SQL Server et la base de données Azure SQL