SQL Server 2008
Sécurité
Rick Byham
Vue d'ensemble:
- Améliorations du chiffrement
- Améliorations de l'authentification
- Audit de sécurité
- Gestion basée sur les stratégies
SQL Server 2008 apporte de nombreuses améliorations et de nouvelles fonctionnalités conçues pour améliorer la sécurité globale de votre environnement de base de données. Il ajoute le chiffrement par clé et des fonctionnalités d'authentification, et introduit un nouveau système d'audit pour
vous aider à créer des rapports sur le comportement des utilisateurs et à vous conformer aux exigences réglementaires.
Dans cet article, je vous présenterai les modifications les plus importantes en matière de sécurité que vous trouverez dans SQL Server® 2008. L'une des premières choses que vous remarquerez, c'est que l'outil Configuration de la surface d'exposition de SQL Server 2005 a disparu. Les options de protocole qui étaient exposées par cet outil sont maintenant disponibles dans l'outil Gestionnaire de configuration. Cependant, les fonctionnalités d'activation et de désactivation se trouvent désormais dans le nouvel environnement de gestion basées sur les stratégies de SQL Server 2008.
Améliorations du chiffrement
Il y a deux améliorations majeures dans le domaine du chiffrement. Premièrement, SQL Server peut désormais utiliser des clés de chiffrement stockées sur un module de sécurité matériel externe de fournisseur tiers. Deuxièmement, les données stockées dans SQL Server peuvent être chiffrées suivant une méthode transparente pour les applications qui se connectent à la base de données. Cela signifie que les administrateurs de base de données peuvent facilement chiffrer toutes les données stockées dans une base de données entière sans devoir modifier le code d'application existant.
La première amélioration est rendue possible grâce à la nouvelle fonctionnalité de Gestion des clés extensible (EKM), disponible dans les éditions Enterprise, Developer et Evaluation de SQL Server 2008. La Gestion des clés extensible permet aux fournisseurs tiers de solutions de gestion de clés d'entreprise et de modules de sécurité matériels d'inscrire leurs périphériques auprès de SQL Server. Une fois ces périphériques inscrits, les utilisateurs peuvent utiliser les clés de chiffrement stockées sur ces modules.
Ces fournisseurs peuvent même exposer des fonctionnalités de chiffrement avancées (telles que le vieillissement des clés et la rotation des clés) dans ces modules. Dans certaines configurations, ceci permet la protection des données contre les administrateurs de bases de données qui ne sont pas membres du groupe sysadmin. Les instructions cryptographiques T-SQL peuvent ensuite chiffrer et déchiffrer les données à l'aide des clés stockées sur le périphérique EKM externe.
Une autre nouvelle fonctionnalité, le chiffrement de données transparent, vous permet de chiffrer les fichiers de bases de données sans devoir modifier aucune de vos applications. Il exécute le chiffrement et le déchiffrement E/S des données et des fichiers journaux en temps réel. Le chiffrement utilise une clé de chiffrement de base de données (DEK), qui est stockée dans l'enregistrement de démarrage de la base de données pour être disponible pendant la récupération. La clé DEK est sécurisée avec un certificat stocké dans la base de données principale du serveur. Le diagramme de la figure 1 illustre l'architecture qui active le chiffrement de données transparent.
Figure 1** Architecture du chiffrement de données transparent **(Cliquer sur l'image pour l'agrandir)
Cela est utile pour protéger les données au repos. Bien que vous puissiez prendre quelques précautions pour sécuriser votre base de données, par exemple en chiffrant les ressources confidentielles et en plaçant un pare-feu autour des serveurs de bases de données, le support physique sur lequel la base de données est stockée (même les bandes de sauvegarde) offrent une vulnérabilité différente. Un utilisateur malveillant pourrait voler ce support et potentiellement accéder aux données stockées.
Cependant, le chiffrement de données transparent, vous permet de chiffrer des données sensibles dans la base de données et de protéger les clés qui sont utilisées pour chiffrer les données avec un certificat. Ceci peut aider votre organisation à se conformer aux nombreuses lois, réglementations et directives sectorielles concernant la protection appropriée des données.
Le chiffrement de données transparent permet aux développeurs de logiciels de chiffrer les données à l'aide des algorithmes de chiffrement AES (Advanced Encryption Standard) et 3DES (Triple Data Encryption Standard). Le chiffrement du fichier de base de données est exécuté au niveau de la page, les pages étant chiffrées avant d'être écrites sur disque puis déchiffrées lors de leur lecture dans la mémoire. Les fichiers de sauvegarde des bases de données où le chiffrement de données transparent est activé sont également chiffrés à l'aide de la clé de chiffrement de base de données.
Pour restaurer une base de données chiffrée, vous devez avoir accès au certificat ou à la clé asymétrique qui a été utilisée pour chiffrer la base de données. Sans le certificat ou la clé asymétrique, la base de données ne peut pas être restaurée. Veillez par conséquent à conserver les clés tant que vous pouvez avoir besoin d'accéder aux sauvegardes apparentées.
Améliorations de l'authentification
Comme vous le savez probablement, Kerberos est un protocole d'authentification réseau utilisé pour fournir une méthode hautement sécurisée d'authentification mutuelle des entités client et serveur (ou des entités de sécurité) sur un réseau. Kerberos permet aux utilisateurs d'atténuer les failles de sécurité, telles que les attaques par leurre et les attaques d'intercepteur. Comparé à l'authentification Windows® NTLM, Kerberos est plus sécurisé, plus robuste et offre de meilleures performances.
Pour authentifier une connexion utilisant mutuellement Kerberos, les noms principaux de service (SPN) d'une instance SQL Server doivent être inscrits auprès d'Active Directory®, et un pilote de client doit fournir un SPN inscrit lors de la connexion. Dans SQL Server 2008, l'authentification Kerberos a été étendue à tous les protocoles réseau, notamment TCP, le Canal nommé, la mémoire partagée et l'adaptateur d'interface virtuel (VIA). Par défaut, le pilote client déduit automatiquement un SPN correct pour une instance SQL Server auquel il se connecte. Vous pouvez également spécifier explicitement un SPN dans le paramètre de chaîne de connexion pour améliorer la sécurité, le contrôle et la résolution des problèmes.
Internet Information Services (IIS) ne fournit plus l'accès à ASP.NET, au Gestionnaire de rapports, ou au service Web Report Server. Dans SQL Server 2008, Reporting Services gère toutes requêtes d'authentification via un nouveau sous-système d'authentification qui prend en charge l'authentification Windows et personnalisée.
Reporting Services héberge maintenant les technologies Microsoft® .NET Framework et ASP.NET intégrées dans le CLR (common language runtime) de SQL Server, et utilise également les fonctionnalités HTTP.SYS du système d'exploitation. Report Server inclut un écouteur HTTP qui accepte les requêtes qui sont dirigées vers une URL et un port que vous définissez pendant la configuration de serveur. Les réservations et l'inscription d'URL sont maintenant gérées directement par le serveur via HTTP.SYS.
Audit de sécurité
SQL Server Audit est une nouvelle fonctionnalité qui vous permettra de créer des audits personnalisés des événements du moteur de base de données. Cette fonctionnalité utilise des événements étendus pour enregistrer des informations pour les audits et fournit les outils et processus dont vous avez besoin pour activer, stocker et afficher des audits sur différents objets serveur et de base de données.
SQL Server Audit est également plus rapide que SQL Server Trace, et SQL Server Management Studio facilite la création et le contrôle des journaux d'audit. Vous pouvez maintenant auditer à un niveau plus granulaire en capturant les instructions SELECT, INSERT, UPDATE, DELETE, REFERENCES et EXECUTE pour les utilisateurs individuels. De plus, SQL Server Audit est totalement scriptable avec les instructions T-SQL CREATE SERVER AUDIT et CREATE SERVER AUDIT SPECIFICATION et leurs instructions ALTER et DROP apparentées.
Pour configurer la fonctionnalité d'audit, vous créez un audit et spécifiez l'emplacement où les événements audités seront enregistrés. Les audits peuvent être enregistrés dans le journal de sécurité Windows, le journal des applications Windows ou dans un fichier à un emplacement que vous spécifiez. Vous nommez l'audit et configurez ses caractéristiques, par exemple le chemin d'accès au fichier d'audit et sa taille maximale. Vous pouvez également sélectionner de fermer SQL Server si l'audit échoue. Et si vous avez besoin d'enregistrer les événements audités à plusieurs emplacements, il vous suffit de créer plusieurs audits.
L'étape suivante consiste à créer une ou plusieurs spécifications d'audits. Une spécification d'audit de serveur recueille des informations sur l'instance de SQL Server et inclut des objets définis du serveur, tels que les connexions et l'appartenance au rôle de serveur. Elle inclut également des informations de base de données qui sont gérées dans la base de données principale, telles que le droit d'accès à une base de données. Lorsque vous définissez une spécification d'audit, vous indiquez quel audit recevra les événements contrôlés. Vous pouvez définir plusieurs audits de serveur et plusieurs spécifications d'audit de serveur, mais chaque audit de serveur ne peut contenir qu'une seule spécification d'audit de serveur activée à la fois.
Vous pouvez également créer des spécifications d'audit de base de données qui contrôlent les événements d'une seule base de données. Vous pouvez ajouter plusieurs spécifications d'audit de base de données à un audit, mais un audit de serveur ne peut activer qu'une spécification d'audit de base de données à la fois par base de données.
Les événements d'actions d'audit de SQL Server utilisés pour les spécifications d'audit de serveur sont regroupés dans des collections d'événements d'actions d'audit apparentés. Celles-ci sont exposées en tant que groupes d'actions d'audit. Lorsque vous ajoutez un groupe à la spécification d'audit, vous contrôlez tous les événements inclus dans ce groupe. Par exemple, il existe un groupe d'actions d'audit appelé DBCC_GROUP qui expose les commandes DBCC. Cependant, les commandes DBCC ne sont pas disponibles pour les audits individuels.
Il existe 35 groupes d'actions d'audit disponibles pour le serveur, dont certains sont apparentés les uns aux autres. Citons par exemple les groupes SUCCESSFUL_LOGIN_GROUP, FAILED_LOGIN_GROUP et LOGOUT_GROUP. Vous pouvez également utiliser le type d'action d'audit appelé AUDIT_ CHANGE_GROUP pour auditer le processus d'audit.
Les spécifications d'audit de base de données peuvent également spécifier des groupes d'événements d'actions d'audit rassemblés dans les groupes d'actions d'audit au niveau de la base de données. Outre les groupes d'actions d'audit, la spécification d'audit de base de données peut inclure les événements d'actions d'audit individuels pour auditer les instructions de langage de manipulation de données. Ces événements peuvent être configurés pour contrôler toute la base de données ou uniquement certains objets de base de données spécifiques. L'action d'audit SELECT, par exemple, peut être utilisée pour auditer les requêtes SELECT pour une table unique ou un schéma entier. Ces événements peuvent également être configurés pour surveiller les actions d'utilisateurs ou rôles spécifiques, tels que tous les db_writers.
Vous pouvez utiliser l'action d'audit SELECT, par exemple, pour auditer les requêtes SELECT pour une seule table de l'utilisateur Marie, le rôle de base de données FINANCE_DEPT ou le rôle de base de données public. Cela offre assurément énormément de contrôle et de flexibilité pour créer les audits que vous souhaitez.
Création de rapports de dépendance
La création de rapports de dépendance a été améliorée avec une nouvelle vue de catalogue et de nouvelles fonctions système. Si vous utilisez sys.sql_expression_dependencies, sys.dm_sql_referencing_entities et sys.dm_sql_referenced_entities, vous pouvez créer des rapports sur les dépendances SQL entre serveurs, entre bases de données et de bases de données pour les objets liés au schéma et non liés au schéma.
Nouveaux rôles de bases de données
Des modifications ont été apportées aux rôles de bases de données inclus dans la base de données msdb. Le rôle db_dtsadmin a été renommé db_ssisadmin, le rôle db_dtsltduser a été renommé db_ssisltduser et le rôle db_dtsoperator a été renommé db_ssisoperator. Pour prendre en charge la compatibilité descendante, les anciens rôles sont ajoutés en tant que membres des nouveaux rôles lorsque les serveurs sont mis à niveau.
Outre ces modifications, de nouveaux rôles de bases de données ont été ajoutés pour prendre en charge les nouvelles fonctionnalités SQL Server 2008. En particulier, la base de données msdb inclut de nouveaux rôles pour les groupes de serveur (ServerGroupAdministratorRole et ServerGroupReaderRole), la gestion basée sur les stratégies (PolicyAdministratorRole) et le collecteur de données (dc_admin, dc_operator et dc_proxy). La base de données du magasin de données de gestion inclut également de nouveaux rôles pour le collecteur de données (mdw_admin, mdw_writer et mdw_reader).
Sécurité FILESTREAM
SQL Server inclut désormais la prise en charge du stockage FILESTREAM, qui permet aux applications de SQL Server de stocker des données non structurées, telles que les documents et les images, dans le système de fichiers. Cela signifie que les applications client peuvent bénéficier des API de flux et des performances du système de fichiers tout en conservant la cohérence transactionnelle entre les données non structurées et les données structurées correspondantes.
Les données FILESTREAM doivent être stockées dans les groupes de fichiers FILESTREAM. Il s'agit d'un groupe de fichiers spécial qui contient des répertoires de système de fichiers au lieu des véritables fichiers. Ces répertoires, appelés conteneurs de données, fournissent l'interface entre le stockage du moteur de base de données et le stockage du système de fichiers.
En termes de sécurité, les données FILESTREAM sont sécurisées comme toutes les autres données, c'est-à-dire que des autorisations sont accordées au niveau des tables ou des colonnes. Le seul compte auquel des autorisations NTFS sont accordées pour le conteneur FILESTREAM est le compte sous lequel le compte de service SQL Server s'exécute. Lorsqu'une base de données est ouverte, SQL Server limite l'accès aux conteneurs de données FILESTREAM, sauf lorsque l'accès est effectué à l'aide des transactions T-SQL et des API OpenSqlFilestream.
Gestion basée sur les stratégies
La gestion basée sur les stratégies de SQL Server 2008 fournit un nouveau système pour gérer SQL Server. Vous pouvez créer des stratégies pour tester et créer des rapports sur de nombreux aspects de SQL Server, et les stratégies peuvent être appliquées sur une seule base de données, une seule instance de SQL Server ou tous les serveurs SQL que vous gérez.
Avec la gestion basée sur les stratégies, vous pouvez tester les options de configuration de SQL Server et un grand nombre des paramètres de sécurité. Et pour certains paramètres de sécurité, vous pouvez créer des stratégies qui détectent les serveurs de base de données qui sont non conformes puis prennent des mesures pour les obliger à être conformes.
Dans SQL Server 2008, un certain nombre de fonctionnalités qui ne sont pas essentielles sont désactivées par défaut pour diminuer votre exposition à une attaque possible. La gestion basée sur les stratégies permet d'activer de façon sélective toutes les fonctionnalités supplémentaires que vous souhaitez. Vous pouvez ensuite évaluer votre configuration de façon planifiée, en obtenant des alertes si les paramètres de configuration ne correspondent pas à la stratégie.
La gestion basée sur les stratégies regroupe les propriétés apparentées et les expose dans des composants appelés facettes. Par exemple, la facette Configuration de la surface d'exposition contient des propriétés pour les requêtes à distance ad hoc, l'intégration du CLR, la messagerie de base de données, l'automatisation OLE, la connexion administrateur dédiée distante, SQL Mail, l'Assistant Web et xp_cmdshell. Vous pouvez créer une stratégie qui active l'Intégration du CLR mais désactive toutes les autres fonctionnalités. Votre stratégie peut inclure des instructions de condition complexes, telles que la désactivation de la messagerie de base de données sur toutes les instances de SQL Server à moins qu'elles soient nommées Customer_Response.
Une fois que vous avez créé la stratégie, vous pouvez évaluer la stratégie sur tous vos serveurs pour générer un rapport qui vous indique les serveurs qui ne sont pas conformes. Appuyez sur le bouton Configurer pour configurer toutes les instances non conformes avec les paramètres de stratégie. Vous devez également planifier la stratégie afin qu'elle s'exécute périodiquement pour contrôler l'état de vos serveurs. Les facettes Configuration de la surface d'exposition sont fournies pour le moteur de base de données, Analysis Services et Reporting Services.
Notez, cependant, que cette gestion basée sur les stratégies n'est pas destinée à être un mécanisme d'application de la sécurité. Dans la plupart des cas, un utilisateur avec des privilèges suffisants peut émettre des instructions qui violent une stratégie ou contourner la stratégie et exécuter des actions de reconfiguration qui peuvent violer votre stratégie de sécurité. La gestion basée sur les stratégies de SQL Server 2008 doit simplement être considérée comme une aide à la surveillance de vos paramètres de sécurité SQL Server.
Les facettes varient au niveau de leur capacité à appliquer les paramètres, selon que leurs instructions DDL apparentées peuvent ou non s'exécuter dans les modes de non validation automatique. Une facette peut parfois forcer un paramètre de configuration sur une instance du moteur de base de données, mais un administrateur peut toujours reconfigurer les paramètres. Certaines facettes peuvent être appliquées par un déclencheur de serveur ; cela peut empêcher des utilisateurs de privilèges inférieurs de modifier le paramètre et réduire le risque qu'un administrateur modifie accidentellement les paramètres. Dans ce cas, l'administrateur doit temporairement désactiver la stratégie avant de modifier les paramètres. Les autres facettes peuvent seulement générer un rapport sur l'état d'une propriété mais ne peuvent pas la modifier. C'est le cas avec une stratégie qui vérifie la longueur d'une clé symétrique ou asymétrique (comme illustré à la figure 2).
Figure 2** Facette pour les clés asymétriques **(Cliquer sur l'image pour l'agrandir)
Il existe des facettes pour la plupart des types d'objets de base de données, et bon nombre d'entre elles ont utilisations liées à la sécurité. Par exemple, la facette de connexion peut déterminer si la stratégie de mot de passe est appliquée pour chaque connexion et la facette de procédure stockée peut détecter si toutes procédures sont chiffrées. Les autres facettes testent les propriétés des utilisateurs, les schémas, les fournisseurs cryptographiques, la conformité des critères communs et l'audit C2.
Windows Server 2008
SQL Server 2008 est entièrement testé avec Windows Server® 2008, qui est fourni avec le pare-feu activé. C'est un bon moment pour revoir la façon de configurer les paramètres de pare-feu. Par ailleurs, Windows Server 2008 fournit également le contrôle d'accès d'utilisateur, que vous avez peut-être découvert avec Windows Vista®. Celui-ci limite les privilèges que vous recevez automatiquement en tant qu'utilisateur administratif. Ces fonctionnalités affecteront toutes les versions de SQL Server.
En conclusion
La sécurité continue d'être un domaine d'amélioration intentionnelle pour SQL Server. Les améliorations de chiffrement et d'authentification fournissent de nouvelles fonctionnalités, et le nouveau système d'audit et la gestion basée sur les stratégies de SQL Server 2008 vous donnent de nouveaux outils pour contrôler l'état de conformité de la sécurité.
Rick Byham a rejoint Microsoft en 1995. Il a d'abord travaillé comme Ingénieur de support SQL Server au sein de la division Customer Support Services, puis a rejoint l'équipe SQL Server auprès de la division Microsoft Learning. Il a intégré l'équipe SQL Server Books Online en tant que rédacteur technique en 2003 où il est actuellement responsable de la documentation sur la sécurité. Vous pouvez contacter Rick à l'adresse rick.byham@microsoft.com.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.