Microsoft dispose d'un certain nombre de fonctionnalités de sécurité dans SQL Server 2017 qui sont utiles à différentes fins, en fonction de ce que vous essayez de protéger et de la ou des menaces contre lesquelles vous essayez de vous protéger. Certaines de ces fonctionnalités de sécurité peuvent avoir des implications sur les performances dont vous devez être conscient lorsque vous décidez de celles que vous souhaitez implémenter. En guise d'introduction, je vais couvrir quelques-uns des points forts de plusieurs de ces fonctionnalités de sécurité.
Chiffrement transparent de la base de données (TDE)
Le chiffrement transparent des données (TDE) est la forme de chiffrement au repos de SQL Server, ce qui signifie que vos fichiers de données, fichier journal, fichiers tempdb et vos sauvegardes complètes, différentielles et de journal SQL Server seront chiffrés lorsque vous activez TDE sur une base de données utilisateur. . Cela protège vos données contre l'accès de quelqu'un à ces bases de données ou fichiers de sauvegarde de base de données tant que cette personne n'a pas également accès à vos certificats et clés de chiffrement.
L'analyse de chiffrement TDE initiale pour une base de données utilisateur utilisera un thread CPU d'arrière-plan par fichier de données dans la base de données (si les fichiers de données sont situés sur des lecteurs logiques distincts), pour lire lentement tout le contenu du fichier de données dans la mémoire à la vitesse de environ 52 Mo/seconde par fichier de données (si les fichiers de données sont situés sur des lecteurs logiques distincts).
Les données sont ensuite cryptées avec l'algorithme de cryptage que vous avez choisi, puis réécrites dans le fichier de données à environ 55 Mo/par seconde (par fichier de données, s'ils se trouvent sur des lecteurs logiques distincts). Ces taux de lecture et d'écriture séquentielles semblent être délibérément limités et sont cohérents dans mes tests sur plusieurs systèmes avec différents types de stockage.
Le processus de chiffrement TDE initial se produit au niveau de la page, sous SQL Server, de sorte qu'il ne provoque pas de verrouillage ou ne génère pas d'activité dans le journal des transactions comme vous le verriez lors de la reconstruction d'un index. Vous pouvez mettre en pause une analyse de chiffrement TDE en activant TF 5004 global, et la réactiver en désactivant TF 5004 et en exécutant à nouveau votre commande ALTER DATABASE dbNAME SET ENCRYTION ON, sans perte de progression.
L'impact du chiffrement/déchiffrement sur le processeur est considérablement réduit sur SQL Server 2016 et versions ultérieures si vous disposez d'un processeur prenant en charge les instructions matérielles AES-NI. Dans l'espace serveur, ceux-ci ont été introduits dans la famille de produits Intel Xeon 5600 (Westmere-EP) pour les serveurs à deux sockets et la famille de produits Intel Xeon E7-4800/8800 (Westmere-EX) pour les serveurs à quatre et huit sockets. Toute nouvelle famille de produits Intel prendra également en charge AES-NI. Si vous ne savez pas si votre processeur prend en charge AES-NI, vous pouvez rechercher "AES" dans le champ d'instructions de sortie de CPU-Z, comme vous le voyez sur la figure 1.
Figure 1 :sortie CPU-Z montrant la prise en charge des instructions AES
Une fois que vous avez chiffré une base de données avec TDE, l'impact d'exécution de TDE est difficile à quantifier de manière prévisible car il dépend absolument de votre charge de travail. Si, par exemple, votre charge de travail tient entièrement dans le pool de mémoire tampon SQL Server, il n'y aura pratiquement aucune surcharge de TDE. Si, d'un autre côté, votre charge de travail consistait entièrement en balayages de table où la page est lue puis vidée presque immédiatement, cela imposerait la pénalité maximale. La pénalité maximale pour une charge de travail volatile d'E/S est généralement inférieure à 5 % avec du matériel moderne et avec SQL Server 2016 ou version ultérieure.
Le travail supplémentaire du déchiffrement TDE se produit lorsque vous lisez des données dans le pool de mémoire tampon à partir du stockage, et le travail supplémentaire du chiffrement TDE se produit lorsque vous réécrivez les données dans le stockage. S'assurer que vous n'êtes pas sous pression sur la mémoire, en ayant un pool de mémoire tampon suffisamment grand et en effectuant des réglages d'index et de requête réduira évidemment l'impact de TDE sur les performances. TDE ne crypte pas les données FILESTREAM et une base de données cryptée TDE n'utilisera pas l'initialisation de fichier instantanée pour ses fichiers de données.
Avant SQL Server 2016, TDE et la compression de sauvegarde native ne fonctionnaient pas bien ensemble. Avec SQL Server 2016 et versions ultérieures, vous pouvez utiliser TDE et la compression de sauvegarde native tant que vous spécifiez un MAXTRANSFERSIZE supérieur à 64 Ko dans la commande de sauvegarde. Il est également très important que vous soyez à jour avec vos mises à jour cumulatives, car il y a eu plusieurs correctifs importants liés à TDE pour SQL Server 2016 et SQL Server 2017. Enfin, TDE est toujours et Enterprise Edition uniquement, même après SQL Server 2016 SP1 (qui a ajouté de nombreuses fonctionnalités réservées aux entreprises à l'édition Standard).
Sécurité au niveau des lignes (RLS)
La sécurité au niveau de la ligne (RLS) limite l'accès en lecture et la plupart des accès en écriture en fonction des attributs de l'utilisateur. RLS utilise ce qu'on appelle le contrôle d'accès basé sur les prédicats. SQL Server applique les restrictions d'accès au niveau de la base de données, et elles seront appliquées chaque fois que l'accès aux données est tenté à partir de n'importe quel niveau.
RLS fonctionne en créant une fonction de prédicat qui limite les lignes auxquelles un utilisateur peut accéder, puis en utilisant une politique de sécurité et un prédicat de sécurité pour appliquer cette fonction à une table.
Il existe deux types de prédicats de sécurité, qui sont les prédicats de filtre et les prédicats de bloc. Les prédicats de filtre filtreront silencieusement les lignes disponibles pour lire les opérations (SELECT, UPDATE et DELETE), en ajoutant essentiellement une clause WHERE qui empêche les lignes filtrées de s'afficher dans le jeu de résultats. Les prédicats de filtre sont appliqués lors de la lecture des données de la table de base, et l'utilisateur ou l'application ne saura pas que les lignes sont filtrées à partir des résultats. Il est important, du point de vue des performances, d'avoir un index de magasin de lignes qui couvre votre prédicat de filtre RLS.
Bloquer explicitement les prédicats (avec un message d'erreur) bloquer les opérations d'écriture (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE et BEFORE DELETE) qui violeraient le prédicat de bloc.
Les prédicats de filtre et de bloc sont créés en tant que fonctions table en ligne. Vous devrez également utiliser l'instruction CREATE SECURITY POLICY T-SQL pour appliquer et activer la fonction de filtrage à la table de base concernée
RLS a été ajouté dans SQL Server 2016 et est disponible dans toutes les éditions de SQL Server 2016 et plus récentes. RLS ne fonctionnera pas avec Filestream, Polybase et les vues indexées. RLS peut nuire aux performances de la recherche en texte intégral et forcer les requêtes d'index columnstore à finir par utiliser le mode ligne au lieu du mode batch. Ce billet de blog Microsoft contient plus d'informations sur l'impact de RLS sur les performances. Un bon exemple d'utilisation de Query Store pour ajuster les performances RLS est ici.
Masquage dynamique des données (DDM)
Le masquage dynamique des données (DDM) peut aider à limiter l'exposition des données sensibles en les masquant aux utilisateurs non privilégiés. DDM est appliqué au niveau de la table afin que toutes les requêtes soient affectées par le masquage des données, tandis que les règles de masquage réelles sont appliquées dans les colonnes individuelles de la table.
Il existe quatre types de masques de données que vous pouvez utiliser, notamment par défaut, e-mail, chaîne personnalisée et aléatoire. Un masque par défaut fournit un masquage complet par défaut des données en fonction du type de données. Par exemple, un type de données de chaîne obtiendrait un masque de 'XXXX' au lieu des données réelles. Un masque d'e-mail renverra la première lettre de l'adresse e-mail réelle, suivie de [email protected], quel que soit le suffixe de domaine réel. Un masque de chaîne personnalisé affichera les première et dernière lettres de la chaîne, avec un remplissage personnalisé au milieu. Enfin, un masque aléatoire est utilisé pour masquer les données numériques et fournir une valeur aléatoire dans une plage définie. Les masques de données peuvent être créés dans une instruction CREATE TABLE ou avec une instruction ALTER COLUMN.
Le masquage dynamique des données ne fournit aucun masquage pour les utilisateurs privilégiés qui peuvent toujours interroger directement vos tables et voir les données non masquées. Les règles de masquage ne peuvent pas être utilisées avec des colonnes chiffrées (Always Encrypted), des colonnes calculées ou avec des données Filestream. S'il existe des index existants sur une colonne que vous souhaitez masquer, vous devrez supprimer l'index, créer le masque sur la colonne, puis recréer l'index. Il est également possible de déduire les valeurs des colonnes de données masquées en écrivant des requêtes qui permettent à l'utilisateur de deviner éventuellement une valeur pour une colonne masquée.
Le masquage dynamique des données a été introduit dans SQL Server 2016 et est disponible dans toutes les éditions de SQL Server. DDM n'est pas censé être une mesure de sécurité solide comme le chiffrement réel, mais d'un autre côté, son impact sur les performances semble assez négligeable.
