Sécurité

Problèmes de sécurité de SQL Server courants et solutions

Paul S. Randal

À une vue d'ensemble :

• Physique et sécurité de réseau
• Attaque de surface, comptes de service et moindre privilège
• L'authentification, autorisation et SQL injection
• La récupération après incident et l'audit

Contenu

Sécurité physique
Sécurité réseau
Attaque Minimization en surface
Comptes de service
Restriction de l'utilisation des privilèges d'administrateur
L'authentification
Autorisation
Injection SQL
Récupération après incident
L'audit
Résumé

Toute personne qui a été autour de l'industrie informatique sait que sécurité est un sujet à chaud. Après tout, les données d'une société sont une des immobilisations plus précieux que lui et protection des données est critique. Comme j'a été planification que écrire pour ce problème de sécurité, J'AI essayé déterminer quelle fonctionnalité de sécurité doit ont un article entier dédié à elle. Mais puis J'AI commencé à penser sur les numéros burgeoning de « DBAs involontaire » (les informatique qui par inadvertance nécessaires des responsables une instance de SQL Server) et la réponse très nous avons dû le Pourboires supérieure pour la maintenance de base de données réellearticle de ce problème 2008 août. Il me vu que ce que DOIS-je faire est de rédiger un article qui couvre les problèmes de sécurité SQL Server, une sorte d'introduction à une meilleure sécurité pour vos instances de SQL Server.

Un article qui décrit tous les problèmes de sécurité que devez vous recherchez à serait un magazine ensemble en soi, donc je canvassed mon Bonhomme MVP SQL Server (et ma femme) pour la saisie en tant que J'AI doit inclure. J'AI lettrées à fournir les zones de sécurité 10 supérieur je pense que vous devez préoccuper si vous n'êtes pas un administrateur de sécurité savvy base de données et soudain vous responsable une instance de SQL Server et associées application. (N'oubliez pas que cela est en aucun cas une liste exhaustive.) Pour chaque problème, j'ai donné une brève vue d'ensemble du problème, conseils sur la façon réduire et un lien vers des informations plus.

Tous les liens à la documentation en ligne sont pour les versions de SQL Server 2008, mais chaque page Web est reliée à la version de SQL Server 2005 ainsi. Habillage de l'article, je fournis des liens vers les blancs principales et des sections documentation en ligne pour la sécurité pour SQL Server 2005 et SQL Server 2008.

Sécurité physique

Il est impératif que vous n'est pas simplement envisager la sécurité SQL Server proprement dit, mais tous les calques qui doivent être parcourus pour accéder à SQL Server en premier lieu. Pour ce concept de sécurité en couche, souvent appelé « defense en profondeur, » n'est pas sécurisée uniquement une couche, mais envisagez la totalité du système.

Le compte premier plus évident est la sécurité physique de l'ordinateur qui exécute SQL Server, cette couche, cependant, est souvent négligée ou est l'objet de complacency. Je ne suis pas référence simplement pour que l'ordinateur peut être volé ou non, mais également l'accès physique à éléments tels que le système de stockage hébergeant les fichiers de base de données, les bandes de sauvegarde et les serveurs hébergeant des copies redondantes de la base de données. Uniquement aux personnes disposant d'un besoin réel pour toucher physiquement ces objets doivent avoir accès à leur ; toute personne doit accéder temporaire doit être accompagné et surveillé.

Un compte moins évidente est la sécurité des ordinateurs de bureau des personnes qui ont accès privilégié haute à SQL Server. Si une personne a accès sysadmin SQL Server, mais ils partent leur bureau Windows déverrouillée, puis tout la sécurité dans le monde n'est pas va empêcher quelqu'un remonter au-delà du système sans assistance de potentiellement accéder aux données sensibles. Un problème plus insidieux serait si quelqu'un ai past et modifié des données — par exemple, un employé dishonest qui connaît le schéma de la base de données ressources humaines et essaie de modifier undetectably un salaire.

Il existe un très intéressant TechNet blanc (notamment un jeu de diapositives et émissions Web), intitulé » Sécurité physique chez Microsoft« qui décrit comment Microsoft gère la sécurité physique de ses serveurs de.

Sécurité réseau

Bien que vos serveurs peuvent être inaccessibles physiquement, ils vous probablement connectés à un réseau quelconque. Cela peut être simplement une ISOLÉ société LAN avec aucun en dehors des connexions ou il peut s'agir d'une connexion directe à Internet. Quel que soit le le cas, il existe certaines choses que vous devez à prendre en compte :

• Assurez-vous que le serveur Windows a configuré la sécurité réseau correcte.
• Choisir les protocoles de réseau pour autoriser et désactivez ceux qui ne sont pas nécessaires.
• Assurez-vous est un pare-feu paramétrage (tels que le pare-feu Windows) et configurer pour autoriser l'accès à SQL Server (comme illustré dans La figure 1 ).
• Décider chiffrer les connexions à SQL Server et de configurer correctement.
• Si Kerberos est utilisé, enregistrer un nom de serveur principal. Kerberos est un mécanisme d'authentification qui underpins l'authentification Windows (que je décrirai plus loin dans cet article), mais il est mal compris. Une explication claire et concis et fournie par Rob Greene, un ingénieur au support technique, dans le billet de blog » Kerberos pour l'administrateur occupé." Je vous recommande d'extrait.
• Décider d'utiliser le service de navigateur de SQL Server pour aider les clients rechercher des instances SQL Server installés et décider si vous souhaitez masquer certaines instances. Masquer une instance signifie que les applications clientes et les utilisateurs doivent connaître les détails de connexion de l'instance de SQL Server, mais elle empêche des personnes de trawling du réseau pour rechercher des instances de SQL Server.

Figure 1, le pare-feu Windows configurer afin d'autoriser l'accès TCP à SQL Server

Toutes ces tâches (et bien plus encore) sont expliqués dans SQL Server 2008 Books Online, commençant à la rubrique Configuration du serveur réseau. Il existe également une section bonne sur Configuration du réseau client.

Attaque Minimization en surface

Les autres services et fonctionnalités qui sont activées, plus attaques zone en surface ou en surface existe pour les pirates à des attaques. SQL Server 2005 a pris la désactivée par défaut stratégie — fonctionnalités avec les implications de sécurité sont désactivées par défaut et sont activées uniquement par le DBA lorsque cela est nécessaire. (Ce processus d'activation et désactivation des services est couramment appelé configuration de surface.)

Un exemple de prime d'une fonctionnalité que vous souhaiterez peut-être désactivé est xp_cmdshell, offre un moyen d'exécuter des commandes sur le système de Windows à partir de dans le contexte d'une instance SQL Server ordinateur hôte. Si un compromet intrus élevés l'instance de SQL Server et le compte de service SQL Server des privilèges Windows, xp_cmdshell peuvent servir pour accéder à du système Windows trop.

Il existe une grande variété de méthodes de configuration de surface. SQL Server 2005 et SQL Server 2008 prise en charge le Gestionnaire de configuration SQL Server des services de configuration et protocoles réseau. Les deux prennent également en charge la procédure sp_configure stockée de configuration des fonctionnalités de moteur de base de données et les options. Par exemple, ce code va désactiver la fonctionnalité xp_cmdshell :

-- To allow advanced options to be changed
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for -- advanced options
RECONFIGURE;
GO
-- To disable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 0;
GO
-- To update the currently configured value for this -- feature
RECONFIGURE;
GO

Les méthodes graphiques de la configuration des options de moteur de base de données et fonctionnalités sont très différents entre les deux versions. SQL Server 2005 a introduit l'outil SAC (Surface Area Configuration) SQL Server. Cela permet de facilement apporter des modifications. la figure 2 , présente par exemple, comment vous pouvez désactiver xp_cmdshell à l'aide de SAC.

La figure 2 désactivation xp_cmdshell à l'aide de SAC de SQL Server 2005

Dans SQL Server 2008, SAC a été entièrement supprimée et la fonctionnalité est remplacée par la fonctionnalité Gestion en fonction de stratégies. Vous trouverez plus d'informations sur ce dans la rubrique documentation en ligne de SQL Server 2008 » Administration de serveurs en utilisant la gestion en fonction de stratégies." figure 3 illustre la création d'une condition pour vérifier que xp_cmdshell est désactivée. Une fois configuré, les stratégies peuvent cibler les instances de SQL Server 2005 et SQL Server 2008 et peuvent même être « appliqués, » vous permettant essentiellement modifier le paramètre d'un simple clic.

La figure 3 Création d'une condition de gestion en fonction de stratégies dans SQL Server 2008

Comptes de service

SQL Server s'exécute en tant qu'un ou plusieurs services sur Windows et chaque service doit disposer d'un compte Windows qui est utilisé pour exécuter le service. Le compte doit avoir accès à diverses ressources sur le système Windows (telles que le réseau et les répertoires système de fichiers différents). La meilleure pratique consiste pour le compte pour les moins possibles privilèges requis pour permettre de SQL Server pour fonctionner correctement. Cela fait partie de ce que l'on appelle le principe de moindre privilège, les états qui un système peut être effectuée plus sécurisé en accordant un utilisateur ou traitement uniquement les privilèges requis et rien plus.

En tant que tel, un compte de service SQL Server doit être pas un compte avec des privilèges haute (tels que système local ou administrateur local) car si SQL Server est compromis, il y a le potentiel du système Windows pour également être compromise. Les services de s'exécuter en général sous un compte intégré appelé service réseau, mais si SQL Server nécessite l'accès aux autres ressources du domaine, un nouveau compte d'utilisateur de domaine doit être créé avec les privilèges minimum et le ressource accès requis. La rubrique documentation en ligne de SQL Server 2008 » Configuration des comptes de service Windows« Fournit une liste complète des comptes de service, les privilèges requis et les ressources. Notez que si vous devez modifiez un compte de service (ou rien concernant), vous devez toujours utiliser le Gestionnaire de configuration SQL Server pour vous assurer que toutes les modifications de configuration nécessaires sont effectuées correctement.

Restriction de l'utilisation des privilèges d'administrateur

La connexion de l'exposition l'association de sécurité plus ou le rôle de serveur fixe sysadmin a, le potentiel plus existe pour une violation de la sécurité, ou un accident. Il existe quelques méthodes recommandées à suivre.

Réduire le nombre de personnes qui ont accès au compte administrateur système et limiter ainsi, les membres du rôle sysadmin (et autres rôles privilégiés) uniquement aux personnes qui réellement besoin des privilèges sysadmin ont les. Ne pas donner hors le mot de passe SA à quiconque souhaite accès temporaire à SQL Server ou à un utilisateur SQL qui souhaite effectuer une tâche rapide. Dans ces situations, créer une nouvelle connexion SQL et accorder le privilège est nécessaire.

Il est préférable pour que les personnes en tant que membres du rôle sysadmin au lieu d'utiliser le compte administrateur système. Ainsi, vous pouvez supprimer de session d'un utilisateur sans avoir à modifier le mot de passe du compte administrateur système. Si reprendre un ancien serveur et vous ne savez pas qui avaient accès avant, modifier le mot de passe SA si donc vous vous trouvez dans le contrôle.

Un problème provokes débat est si vous souhaitez supprimer le groupe BUILTIN/Administrateurs de Windows à partir du rôle sysadmin (il est ajouté par défaut). Doit un administrateur Windows pouvoir interroger la base de données RH ? Ou votre société approuve tous les administrateurs pour que l'intégrité et honesty ? Si vous souhaitez supprimer, passez avec précaution. Cela est particulièrement vrai dans un environnement en clusters peut où si vous ne suivez la procédure correcte, votre serveur SQL ne pas démarrer. Pour plus d'informations sur d'autres problèmes clusters, consultez l'article Base de connaissances » Tâches de serveur en cluster SQL, Don'ts et avertissements de base."

Pour ceux qui ont accès sysadmin, encourager les ne pas connecter avec des privilèges élevés, sauf si c'est absolument nécessaire, chacun de ces noms d'utilisateurs deux accès, un privilège et un ne donnez pas. À l'aide du compte sans privilège par défaut permet de réduire le risque d'erreurs coûteuses et également réduit la probabilité qu'un déverrouillées Windows Terminal Server aura une fenêtre avec des privilèges sysadmin ouvrir sur elle. N'oubliez pas : défense en profondeur !

Le dernier point que je vous apportez ici est pour éviter les applications nécessitant des privilèges sysadmin. Malheureusement, cette est une pratique courante et inévitable incorrecte avec certaines applications, mais vous devez éviter cet exercice pratique dans les applications maison et se plaindre à des développeurs d'applications qui requièrent des privilèges sysadmin.

L'authentification

Il existe deux modes d'authentification disponibles : l'authentification Windows et en mode mixte (qui est l'authentification Windows combinée avec l'authentification SQL Server).

L'authentification Windows utilise les comptes réseau/domaine pour valider le compte Windows utilisé pour se connecter à SQL Server. Si cette option est sélectionnée lors de l'installation, le compte SA est créé avec un mot de passe généré de façon aléatoire mais efficace désactivé. Immédiatement après l'installation, vous devez modifiez le mot de passe SA pour indiquer un mot de passe fort et sécurisée mais continuer à laissez le compte désactivé, sauf si c'est absolument nécessaire.

L'authentification SQL Server repose sur chaque utilisateur ayant un compte de SQL Server et un mot de passe stockées dans SQL Server définis. Et, bien entendu, cela signifie que le compte SA est activé et doit avoir un mot de passe défini. Avec l'authentification SQL Server, les utilisateurs ont au moins deux noms d'utilisateur et mots de passe (un pour le réseau) et l'autre pour SQL Server. Il est généralement recommandé uniquement utiliser l'authentification Windows dans la mesure du possible, comme c'est une solution plus sécurisée. La rubrique documentation en ligne » Choisir un mode d'authentification« explique ceci plus en détail, ainsi que comment faire pour modifier le mode d'authentification.

Si l'authentification SQL est utilisée, puis tous les utilisateurs doivent ont un mot de passe fort : une qui est assez complexe pour être résistantes à en cours deviner par un programme recherche un mot de passe. Ceci est particulièrement important pour les comptes avec privilèges haute, telles que l'association de sécurité et les membres du rôle sysadmin. (Une les plus courantes d'encore pire pratiques auparavant un mot de passe administrateur système vide. Heureusement, en tant que de SQL Server 2000 SP3, qui n'est pas possible.)

Mots de passe doivent également être modifiées régulièrement et votre société doit publier des stratégies d'entreprise pour aider les employés utilisez mot de passe sécurisé et fort meilleures pratiques. Pour obtenir une vue d'ensemble des meilleures pratiques pour créer et la protection de mot de passe fort, consultez l'article » Mots de passe forts : Comment faire pour créer et utiliser les." Vous pouvez incorporer ces stratégies dans une stratégie d'entreprise.

Si SQL Server 2005 ou SQL Server 2008 s'exécute sur Windows Server 2003 ou version ultérieure, il peut rendre utiliser le Windows mécanismes de stratégie de mot de passe pour appliquer des stratégies de complexité et la date d'expiration. La section documentation en ligne de SQL Server 2008 appelée" Stratégie de mot de passe« dispose des informations sur la prise en charge pour les mots de passe forts et différentes stratégies de mot de passe dans SQL Server.

Autorisation

Comme je L'AI avons déjà mentionné, un des principes de protection des systèmes est d'utiliser le principe du moindre privilège. Lorsque cela s'applique directement à des privilèges au niveau de l'administrateur, elle s'applique également à des autorisations aux utilisateurs de base de données ordinaire. Un utilisateur dans une base de données doit (probablement) pas pouvoir accéder aux données dans une autre base de données. Le propriétaire d'un ensemble de tables ne doit pas pouvoir endommager des tableaux d'une autre personne. Les utilisateurs doivent uniquement être en mesure d'accéder aux données qu'ils sont supposés pour accéder à et même qu'ils doivent uniquement en peuvent effectuer des actions requises sur les données (par exemple, SELECT, mais pas mise à jour ou suppression).

Tout ceci peut être effectuée dans SQL Server par un système complet, hiérarchique autorisations où les utilisateurs ou rôles (appelés entités) ont accordées ou refusées certaines autorisations spécifiques de certaines ressources (appelés securables) comme un objet, le schéma ou la base de données. Une vue d'ensemble de la hiérarchie d'autorisations SQL Server est illustrée dans la figure 4 . Ceci implique également de suivre le principe du moindre privilège. Par exemple, ne pas faire tout de base de données aux développeurs de membres du rôle db_owner. Restreindre les autorisations pour le rôle public et uniquement accorder des autorisations au niveau le plus bas (utilisateur ou rôle) pour limiter l'accès direct. Une étude complète des méthodes recommandées pour les autorisations n'abordée dans cet article, mais la documentation en ligne de SQL Server 2008 inclut une section appelée" Identité et contrôle d'accès (moteur de base de données)« qui propose des downs d'extraction dans les concepts.

La figure 4, le serveur SQL autorisations hiérarchie

Pour autoriser des autorisations plus précises et la meilleure séparation des rôles au sein d'une base de données, SQL Server 2005 a introduit séparation utilisateur-schéma, où schémas sont indépendantes des utilisateurs de base de données et sont des conteneurs uniquement des objets. Cela permet de nombreuses modifications comportementales, notamment plus de précision pour la gestion des autorisations affinées. (Nom quatre suit le format server.database.schema.object dans SQL Server 2005 et SQL Server 2008, le format était précédemment server.database.owner.object.)

Par exemple, un schéma peut être créé avec les développeurs de base de données attribués des autorisations de contrôle. Ils peuvent CREATE, ALTER et DROP les objets dans les schémas qu'ils contrôlent mais ils disposent sans autorisations implicites pour les autres schémas dans la base de données et leur inutiles droits db_owner pour base de données de développement. En outre, séparation utilisateur-schéma permet aux utilisateurs de base de données d'être supprimée sans devoir recode tous les objets connexes ou l'application avec un nouveau nom d'utilisateur, les objets sont membres d'un schéma et ils sont plus liés aux créateur de l'objet.

Il est recommandé d'utiliser des schémas pour le propriétaire de l'objet en raison du toutes ces raisons. Vous pouvez trouver plus d'informations dans la documentation en ligne de SQL Server 2008 dans la rubrique" Séparation utilisateur-schéma."

Une autre façon d'empêcher les utilisateurs de faire les choses qu'ils ne vous pas censé pour faire consiste à interdire l'accès direct aux tables de base. Cela est possible en fournissant des procédures stockées et fonctions qui sont utilisées pour encapsuler, contrôle et isoler les opérations comme les mises à jour et suppressions et en fournissant des affichages qui contrôlé et optimale sélectionne.

Injection SQL

Une des méthodes courantes de l'accès non autorisé aux données consiste à utiliser une attaque par injection SQL. Injection SQL peut prendre plusieurs formulaires, mais l'approche principal tire parti du code qui utilise des chaînes dynamique construits et injecte code inattendu dans la construction. Par exemple, l'attaque d'injection de suivant tire parti de logique mal écrite pour valider l'entrée utilisateur pour amener SQL Server à accepter l'entrée en incluant les caractères d'échappement dans la chaîne d'entrée. Bien que contrived, cet exemple met en évidence ce qui peut se produire lorsque code génère dynamiquement chaînes à l'aide entrée qui n'est pas validée soigneusement :

DECLARE @password VARCHAR (20);
DECLARE @input    VARCHAR (20);
DECLARE @ExecStr  VARCHAR (1000);

SELECT @password = 'SecretSecret';

-- assume application gets input 'OR''='
SELECT @input = '''OR''''=''';

SELECT @ExecStr = 'IF ''' + @password + ''' LIKE ''' + @input + ''' PRINT ''Password Accepted''';

EXEC (@ExecStr);
GO

Si vous exécutez ce code, il imprimera la phrase « mot de passe accepté » même si l'entrée utilisateur clairement ne correspond pas à la chaîne de mot de passe. L'entrée de l'utilisateur contenait une séquence d'échappement modifié la logique de Transact-SQL, car l'entrée n'a pas correctement analysé et activée.

Injection SQL ne doit pas être un problème d'une application well-written et il existe quelques astuces spécifiques (comme l'utilisation de QUOTENAME pour identificateurs délimités). Mais si vous héritez d'une ancienne application (ou peut-être un projet homebrew qui est devenue une application d'entreprise), vous devrez tester spécifiquement pour voir si elle est vulnérable aux attaques par injection SQL. Il existe une grande variété de techniques disponibles pour atténuer les attaques de type injection SQL. Documentation en ligne de SQL Server 2008 possède à une section complète, commençant à la rubrique bien nommée" Injection SQL."

Récupération après incident

Combien vous devez soucier de cela dépend de quels sont vos besoins de perte de temps d'arrêt et de données. (Si vous n'avez pas déjà défini ces exigences, vous devez!) Problèmes de sécurité peuvent se produire à plusieurs niveaux. Il existe des problèmes quand la récupération après incident implique de basculement vers un autre serveur SQL Server ou la nécessité de restaurer une base de données contenant des données chiffrées.

Dans le premier cas, problèmes se produisent lorsque les noms d'accès nécessaires pour accéder à la base de données n'ont pas été dupliqués sur le serveur de basculement, par exemple, lorsque l'aide Envoi de journaux ou de la base de données de mise en miroir. Si la base de données échoue à l'instance miroir et l'application tente de se connecter en utilisant une connexion spécifique qui n'existe pas sur le serveur miroir, l'application reçoit la Erreur 18456 » connexion a échoué ». Les noms d'accès font partie de l'écosystème d'application et doivent être définis sur l'instance hébergeant la base de données. Article de la base de connaissances 918992 » Comment faire pour transférer les noms d'accès et les mots de passe entre instances de SQL Server 2005» Explique comment effectuer ceci, et je discuter dépannage Erreur 18456 dans un instant.

Dans le second cas, des problèmes se produire lorsque la sauvegarde de base de données contient des données chiffrées et la chiffrement (ou touches) utilisé pour chiffrer les données non sauvegardés ou ne sont pas disponibles dans l'instance de SQL Server où la base de données est restaurée. Le meilleur des cas ici, sont que seulement certaines données de la base de données est chiffrée et donc uniquement ce sous-ensemble de données est inaccessible. Le scénario de cas pire est que l'intégralité de la base de données a été chiffré à l'aide TDE (transparent Data Encryption) dans SQL Server 2008. Dans ce cas, si le certificat serveur utilisé pour protéger la clé de chiffrement de base de données n'a pas été sauvegardé ou n'est pas disponible, impossible de restaurer l'intégralité de la base de données et les erreurs suivantes seront renvoyées :

Msg 33111, Level 16, State 3, Line 1
Cannot find server certificate with thumbprint
'0xFBFF1103AF133C22231AE2DD1D0CC6777366AAF1'.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Bien entendu, qui est le point TDE — que quelqu'un se produit sur une sauvegarde capter de la base de données chiffrée ne peut pas restaurer et accéder aux données sensibles. Mais si les données sont bien et que vous devez pour y accéder, puis vous devez avoir le certificat de serveur disponible ou les données sont perdues.

Chiffrement est un sujet en lui-même énorme et a couverture complète dans SQL Server 2008 Books Online, commençant par la « Chiffrement de SQL Server« section. Vous pouvez également visualiser me montrer TDE et restaurer avec succès sur une seconde instance dans un screencast vidéo accompagnement disponible à .com/conseils.

L'audit

Une des plus importantes choses que vous devez faire pour améliorer la sécurité d'un système consiste à implémenter l'audit. Vous savez qui de faire ce que. Cela peut même être obligatoire, selon la nature de votre entreprise.

Au minimum, les connexions à la fois a échoué et réussies doit d'audit afin que vous pouvez indiquer si, par exemple, cinq tentatives de connexion a échoué ont été suivis d'une réussite. Vous savez lorsqu'une personne tente d'interrompre dans votre instance de SQL Server (et avec la connexion). la figure 5 montre configuration de connexion l'audit dans la boîte de dialogue Propriétés du serveur de SQL Server 2005 Management Studio. Échecs des connexions sont vérifiées comme message 18456 dans le journal des erreurs et l'état d'erreur fournit la raison de l'échec. La description meilleure que je trouve des différents états, ainsi que d'une longue discussion sur le dépannage, est dans un billet de Il-Sung Lee sur le blog SQL protocoles intitulé" Messages d'erreur présentation « connexion a échoué » (Erreur 18456) dans SQL Server 2005."

La figure 5 Confi guring login d'audit dans SQL Server 2005 Management Studio

Audit complet de toutes les actions est difficile de SQL Server 2005 (et également abordée cet article). Il implique plusieurs déclencheurs et SQL Trace. Dans SQL Server 2008, l'audit a été considérablement simplifiée avec l'introduction d'une nouvelle fonctionnalité : vérification de serveur SQL. Cela est abordée dans un très détaillé et récent blanc intitulé » L'audit dans SQL Server 2008." Dans le screencast vidéo associé, J'AI montrent SQL Server vérification. Vous pouvez obtenir de détails sur les autres outils d'audit dans la documentation en ligne SQL Server 2008 » Audit (moteur de base de données)« section.

Résumé

C'est de nombreuses rubriques et beaucoup de liens, mais c'était le point de cet article. Je souhaitais que fournir une vue d'ensemble de rubriques importantes de la sécurité que vous devez prendre en compte lorsque vous êtes un administrateur de base qui n'est pas utilisé pour gérer avec la sécurité.

Il existe des outils qui vous permettent de vérifier votre système pour des vulnérabilités de sécurité courantes. Le premier est l'utilitaire Microsoft Baseline Security Analyzer (MBSA) qui vérifiera Windows, réseau, système de fichiers et même des problèmes de sécurité SQL Server 2000 et SQL Server 2005. La version la plus récente est Microsoft Baseline Security Analyzer (MBSA) 2.1. À nouveau pour SQL Server 2000 et SQL Server 2005 uniquement, il existe un Server–specific SQL outil appelé le Best Practices Analyzer(BPA). Cela utilise une liste prédéfinie de règles pour vérifier votre configuration de SQL Server et que vous signale des problèmes (par exemple, un mot de SA passe vide).

Aucune de ces outils ne fonctionne avec SQL Server 2008. En fait, BPA ne sera pas publiée pour SQL Server 2008 tout et a été remplacé, ainsi qu'avec l'outil Configuration du réseau SQL Server 2005 surface courte durée, par la nouvelle fonctionnalité Gestion des stratégies-basée sur que J'AI expliqué précédemment. Partie de la raison de ce remplacement est que BPA et SAC étaient outils en lecture seule pour vous aider à identifier les problèmes, il ne peuvent pas résoudre des problèmes. Gestion en fonction de stratégie offre de nombreuses options de correction et il peut même être utilisé pour les serveurs SQL Server 2000 et SQL Server 2005 cibles.

Bien entendu, vous devez toujours utiliser Windows Update pour vous assurer que nouveaux correctifs de sécurité ainsi service packs que ceux-ci et qu'ils contiennent sont téléchargés pour pouvoir installer à un moment approprié, ceci est le meilleur moyen de rester à jour avec les dernières mises à jour. Installer ces sans prendre le temps d'arrêt est abordée dans cet article, mais quelques idées ont été présentées dans la Colonne de questions et réponses SQL décembre 2006.

Si vous essayez de trouver des ressources Microsoft générales sur la sécurité, il y a plusieurs destinations sont affiche dans votre moteur de recherche préféré. Pour vous enregistrer certains en cliquant sur temps autour, je vous suggère deux clés blancs que vous est conseillé de lire.

" SQL Server 2005 sécurité Utilisation Practices–Operational et tâches d'administration« et » SQL Server 2008 : présentation de la sécurité pour les administrateurs de base de données."

Pour SQL Server 2005, le point d'entrée dans la section relative à la sécurité de la documentation en ligne est la rubrique" Considérations de sécurité pour les bases de données et applications de base de données." Pour SQL Server 2008, le point d'entrée documentation en ligne équivalent est la « Sécurité et protection (moteur de base de données)."

Agissant takeaways à partir de cet article sont, je veux vous permet de réaliser qu'il existe certaines étapes que vous devez Aller à pour vérifier les données que vous stockez dans SQL Server sont aussi sécurisées que qu'il soit nécessaire. Ceci est particulièrement important lorsque vous héritez d'une instance de SQL Server que quelqu'un a été gérez. C'est simplement comme acheter une maison d'une personne, vous devez demander à Si l'alarme fonctionne, si le jardin est clôturé dans et qui a des copies de l'aide des touches. L'exécution dans la liste que je avez donné dans cet article est un bon début, mais assurez-vous qu'aller plus loin dans les zones qui vous intéressent. Et comme toujours, si vous avez des commentaires ou des questions, déplacer m'une ligne à Paul@SQLskills.com.

Paul s Randal est le directeur de gestion SQLskills.com et MVP SQL Server. Il a travaillé dans l'équipe SQL Server Storage Engine chez Microsoft de 1999 à 2007. Paul écrit DBCC CHECKDB/réparation pour SQL Server 2005 et était responsable pour le moteur de stockage base pendant le développement de SQL Server 2008. Paul est un expert de la récupération après incident, haute disponibilité et la maintenance de base de données et un présentateur standard à des conférences dans le monde entier. Blogs il à SQLskills.com/blogs/paul.