La sécurité de SQL Server s’appuie sur trois composantes de base : les logins, l’ajout des utilisateurs de base de données et l’octroi de permissions. Chaque composante joue un rôle différent dans la sécurité de SQL Server. Un login est nécessaire pour qu’un utilisateur puisse se connecter au système SQL
Sécurité de SQL Server
Server. Si vous utilisez Integrated Security, ce login est le nom d’utilisateur Windows de l’utilisateur.
Sinon, l’administrateur doit manuellement ajouter un login à SQL Server. Le login connecte l’utilisateur au serveur mais pas à une base de données. Pour qu’un utilisateur puisse se connecter à une base de données, il faut d’abord créer un compte utilisateur base de données pour cette personne et l’ajouter à la base de données. Un administrateur doit créer un jeu d’utilisateurs de base de données valide pour chaque base de données. De la même manière, le fait que l’utilisateur accède à la base de données ne signifie pas qu’il peut aussi accéder aux objets qu’elle contient. Pour permettre à l’utilisateur d’accéder à ces objets, l’administrateur doit lui accorder des permissions sur les objets base de données spécifiques. Autrement dit, le login vous connecte au serveur, le compte utilisateur base de données vous connecte à la base de données, et l’octroi de permissions vous permet d’accéder aux objets présents dans la base de données.
Les rôles de SQL Server 2000 et de SQL Server 7.0 – qui sont similaires aux groupes Windows – simplifient la gestion en vous permettant de constituer des groupes d’utilisateurs similaires. L’établissement des logins est la première étape pour connecter vos utilisateurs au serveur. Si vous utilisez l’authentification Windows, vous n’avez rien à faire pour ajouter des logins. Quand un utilisateur tente de se connecter à la base de données, SQL Server authentifie l’utilisateur vis-à-vis d’un Windows DC (domain controller) avant que SQL Server ne laisse l’utilisateur accéder au serveur. Cependant, vous devez accorder à l’utilisateur la permission d’accéder au serveur en exécutant la procédure stockée sp_grantlogin. Vous pouvez aussi utiliser des groupes Windows pour accorder à des groupes d’utilisateurs la permission de se connecter (log in) à SQL Server.
Pour accorder à tous les membres d’un groupe l’accès à SQL Server, il vous faut exécuter la procédure stockée sp_grantlogin et spécifier le nom du groupe. Si vous utilisez l’authentification SQL Server, il vous faut créer un login SQL Server, soit en exécutant la procédure stockée sp_addlogin, soit au moyen de Enterprise Manager. Dans ce dernier cas, naviguez jusqu’au noeud Server, Security, Logins. Faites un clic droit sur Logins et sélectionnez New Login dans le menu surgissant. Dans la boîte de dialogue New Login, entrez le nom du login, le mot de passe, le langage par défaut et la base de données.
La mise en place d’un login serveur permet à l’utilisateur de se connecter au serveur, mais pas d’accéder à la base de données. Pour qu’un login serveur permette d’accéder à une certaine base de données, il faut créer un utilisateur de base de données, soit par une instruction T-SQL, soit au moyen de Enterprise Manager. Pour ajouter un nouvel utilisateur de base de données en utilisant TSQL, on utilise la procédure stockée sp_adduser.
Premièrement, exécutez la commande use database pour établir le bon contexte de base de données. Ensuite, exécutez la procédure stockée sp_adduser en spécifiant un nom de login existant comme premier paramètre. Pour ajouter un utilisateur de base de données par l’intermédiaire de Enterprise Manager, étendez d’abord le noeud de serveur désiré puis naviguez jusqu’à la base de données à laquelle vous voulez que l’utilisateur accède. Etendez le noeud base de données, faites un clic droit sur le noeud User et choisissez l’option New User dans le menu surgissant.
Après avoir ajouté l’utilisateur de la base de données, vous pouvez lui accorder la permission d’accès aux différents objets base de données (tables, vues, par exemple). SQL Server permet trois types principaux de permissions : Grant (accorder), Deny (refuser) et Revoke (révoquer). Grant permet à un utilisateur d’accéder à un objet et Deny interdit l’utilisation de l’objet. Deny a priorité sur Grant. Quant à la permission Revoke, elle annule celle qui prévaut actuellement.
Autrement dit, elle révoque une permission précédemment accordée (grant) ou refusée (deny). Pour chaque objet base de données, vous pouvez accorder ou refuser des permissions sur diverses actions. Les mots-clés T-SQL servant à définir des permissions Grant ou Deny pour chaque objet sont SELECT, INSERT, UPDATE, DELETE, EXEC et DRI.
Vous pouvez gérer les permissions soit en utilisant les instructions T-SQL GRANT, DENY ou REVOKE, soit par Enterprise Manager. Dans Enterprise Manager, étendez le noeud User de la base de données qui vous intéresse. Puis, dans le panneau de détails, faites un clic droit sur un utilisateur de base de données particulier, puis sélectionnez l’option Manage Permissions dans le menu surgissant. Une matrice s’affiche avec la liste de tous les objets base de données à gauche de l’écran et toutes les instructions auxquelles ces permissions s’appliquent, à droite. Pour accorder une permission, cliquez une fois pour afficher une marque verte à l’endroit approprié dans la matrice. Pour refuser une permission, cliquez deux fois pour afficher un X rouge dans la matrice.
Téléchargez cette ressource
Sécuriser Microsoft 365 avec une approche Zero-Trust
Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Fuites de données : la France, 2ème pays le plus touché au monde début 2026
- Nomios accélère sur la cybersécurité industrielle avec un SOC renforcé et une Factory OT immersive
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Reprendre le contrôle de son SI : la clé d’un numérique à la fois souverain et responsable
Articles les + lus
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
