Article
03/31/2012

Liste de vérification : limitation de l'accès aux données

Cette liste de vérification vous permet de vérifier la manière dont l'accès aux informations est limité dans votre organisation. Utilisez cette liste de vérification pour auditer périodiquement la manière dont les utilisateurs accèdent aux informations stockées dans le moteur de base de données SQL Server.

Accès à l'instance de SQL Server

Ces éléments concernent l'instance entière du moteur de base de données.

...	Description
	Avez-vous accordé l'accès via des groupes Windows pour la plupart des connexions ? Conseil Configurer l'accès au moteur de base de données à l'aide des groupes Windows permet d'administrer et de maintenir l'accès plus facilement. Pour plus d'informations sur les connexions, consultez Entités de sécurité (moteur de base de données).
	Avez-vous supprimé du moteur de base de données des connexions inutiles ou obsolètes ? Conseil Cela demande peut-être une révision manuelle périodique. Autoriser l'accès essentiellement via des groupes Windows permet de simplifier cette tâche.
	Avez-vous implémenté le principe des privilèges minimaux ? Conseil Il est recommandé de n'accorder des autorisations aux principaux (connexions, utilisateurs et rôles) que pour les objets de base de données auxquels ils doivent accéder pour accomplir leur travail. N'autorisez pas les utilisateurs habituels à se connecter à l'aide d'un compte administrateur, tel que sa. N'autorisez pas votre page Web, application personnalisée ou package SSIS à se connecter à l'aide d'un compte administrateur.
	Avez-vous accordé l'autorisation VIEW DEFINITION de manière sélective au niveau schéma, base de données ou serveur, pour consulter des métadonnées système sans conférer d'autorisations supplémentaires ? Conseil Pour plus d'informations, consultez GRANT (Transact-SQL).
	Avez-vous remplacé des serveurs distants par des serveurs liés ? Conseil Pour plus d'informations, consultez Configuration des serveurs distants et Liaison des serveurs.
	Si l'authentification directe à un serveur lié est nécessaire, avez-vous limité la délégation ? Conseil Pour plus d'informations, consultez sp_addlinkedsrvlogin (Transact-SQL).
	Avez-vous désactivé les requêtes ad hoc via des serveurs (sauf si elles sont nécessaires) ? Conseil Pour plus d'informations, consultez Option Requêtes distribuées appropriées.

Gestion de l'identité de l'utilisateur

Ces éléments concernent les paramètres de chaque base de données.

...	Description
	Le compte d'utilisateur invité est-il désactivé dans chaque base de données, sauf s'il est requis pour les utilisateurs anonymes ? Conseil Désactivez les comptes à l'aide de SQL Server Management Studio ou Transact-SQL.
	Les utilisateurs ont-ils uniquement accès aux bases de données nécessaires ? Conseil Cela demande peut-être une révision manuelle périodique. Un accès autorisé essentiellement via des rôles SQL Server permet de simplifier cette tâche. Pour plus d'informations, consultez Rôles de niveau serveur.
	L'accès via des rôles SQL Server a-t-il été accordé à la plupart des utilisateurs ? Conseil Configurer l'accès à l'aide des rôles serveur et des rôles de base de données permet de maintenir l'accès plus facilement. Pour plus d'informations sur les rôles, consultez Rôles au niveau de la base de données.
	SQL Server Agent utilise-t-il des informations d'identification pour exécuter des étapes du travail qui requièrent des privilèges spécifiques, plutôt que d'ajuster les privilèges du compte de service SQL Server Agent ? Conseil Pour plus d'informations, consultez Informations d'identification (moteur de base de données).
	Si un utilisateur de l'Agent SQL Server doit exécuter un travail qui requiert des informations d'identification Windows différentes, lui avez-vous affecté un compte proxy possédant juste assez d'autorisations pour accomplir cette tâche ? Conseil Pour plus d'informations, consultez Procédure : créer un proxy (SQL Server Management Studio).
	Encapsulez-vous l'accès aux objets de base de données dans des modules tels que des procédures stockées, des fonctions, des déclencheurs ou des assemblys ? Conseil : limiter l'accès à des modules prédéfinis rend l'exécution de code arbitraire par un utilisateur malveillant plus difficile. Pour plus d'informations, consultez Fonctionnement des procédures stockées.
	Avez-vous défini un contexte d'exécution de manière explicite dans les modules au lieu d'utiliser le contexte par défaut ? Conseil Pour plus d'informations, consultez Utilisation de EXECUTE AS dans des modules.
	Les modules sont-ils signés pour bloquer toute falsification ? Conseil Pour plus d'informations, consultez Signature de module (moteur de base de données).
	Utilisez-vous USER WITHOUT LOGIN à la place des rôles d'application ? Conseil Pour plus d'informations, consultez Meilleures pratiques de sécurité de SQL Server 2005 - Tâches opérationnelles et administratives (en anglais).
	Utilisez-vous EXECUTE AS à la place de SETUSER ? Conseil Pour plus d'informations, consultez EXECUTE AS ou SETUSER.
	Avez-vous remplacé les rôles d'application par EXECUTE AS ? Conseil Utilisez EXECUTE AS … WITH NO REVERT lorsque cela est possible. Utilisez l'option EXECUTE AS … WITH COOKIE lors de l'imbrication de modifications d'identité. Pour plus d'informations, consultez EXECUTE AS (Transact-SQL).

Accès aux objets

Ces éléments concernent l'accès aux objets de base de données.

...	Description
	Le rôle serveur public et les rôles de base de données possèdent-ils peu d'autorisations (s'ils en ont) ? Conseil Toutes les connexions et tous les utilisateurs sont membres des rôles publics qui ne peuvent pas être modifiés. Ces rôles doivent avoir des autorisations très limitées.
	Les objets de base de données semblables sont-ils regroupés dans le même schéma ? Conseil Créez des schémas en fonction des besoins de l'entreprise. Utilisez ces schémas personnalisés à la place du schéma dbo. Pour plus d'informations, consultez Schémas (moteur de base de données).
	Gérez-vous la sécurité des objets de base de données en définissant la propriété et les autorisations au niveau du schéma ? Conseil Pour plus d'informations, consultez GRANT - Autorisations sur un schéma (Transact-SQL).
	Les schémas ont-ils des propriétaires distincts au lieu de tous appartenir à dbo ? Conseil Lorsque tous les schémas ont le même propriétaire, le chaînage des propriétés risque d'ignorer des vérifications d'autorisations nécessaires. Pour plus d'informations, consultez Chaînes de propriétés.
	Utilisez-vous la signature du code pour le code de procédures si des privilèges supplémentaires sont requis pour la procédure ? Conseil Pour plus d'informations, consultez Signature de module (moteur de base de données).
	L'option de base de données TRUSTWORTHY a-t-elle la valeur OFF ? Conseil Si cette option a la valeur ON, les modules de base de données (tels que des procédures stockées ou des fonctions définies par l'utilisateur) utilisant un contexte d'emprunt d'identité ont accès à des ressources extérieures à la base de données. Utilisez l'instruction ALTER DATABASE pour modifier le paramètre TRUSTWORTHY. Pour plus d'informations, consultez Propriété de base de données TRUSTWORTHY.
	Les modules prennent-ils des mesures pour empêcher l'injection de code SQL ? Conseil : pour plus d'informations, consultez Injection SQL.
	Si l'accès ad hoc à la base de données est autorisé (au lieu d'encapsuler l'accès dans des modules), les applications prennent-elles des mesures pour empêcher l'injection de code SQL ? Conseil Pour plus d'informations, consultez les liens suivants. Procédure : se protéger contre l'injection de code SQL dans ASP.NET (page éventuellement en anglais) Analyseur de code source Microsoft pour l'injection de code SQL (page éventuellement en anglais) L'outil Analyseur de code source Microsoft pour l'injection SQL est disponible pour rechercher les vulnérabilités d'injection SQL dans un code ASP Nouvelles attaques par troncature SQL, comment les éviter Bloquez les attaques par injection de code SQL avant qu'elles ne vous bloquent (page éventuellement en anglais)

Audit de l'accès

...	Description
	L'audit est-il spécifique au scénario ? Conseil Équilibrez le besoin d'audit avec la charge que représente la génération de données supplémentaires. SQL Server Audit permet d'activer l'audit dans une base de données unique et pour des opérations DML sur des objets spécifiques. Pour plus d'informations, consultez Fonctionnement de SQL Server Audit.
	L'audit de connexion est-il configuré pour conserver un enregistrement des échecs de connexion ? Conseil Configurez l'audit de connexion à l'aide des Propriétés du serveur (page Sécurité) dans Management Studio.
	Auditez-vous à la fois les connexions ayant réussi et les connexions ayant échoué si vous stockez des données très sensibles ? Conseil Pour plus d'informations, consultez Classe d'événements Audit Login et Classe d'événements Audit Login Failed.
	Auditez-vous les événements DDL, DML et les événements spécifiques au serveur à l'aide de SQL Server Audit ou des événements de trace ? Conseil Pour plus d'informations, consultez Fonctionnement de SQL Server Audit, Présentation des notifications d'événements, Événements DDL et Événements de trace utilisables avec les notifications d'événements.
	Utilisez-vous WMI pour être alerté des événements d'urgence ? Conseil Pour plus d'informations, consultez Fournisseur WMI pour les concepts des événements de serveur.
	Activez-vous l'audit C2 ou la conformité des critères communs uniquement en cas de besoin ? Conseil Ciblez votre configuration en fonction de vos besoins. N'activez l'audit C2 ou la conformité des critères communs que si nécessaire pour votre entreprise. Consultez Certification Critères communs.