Restriction des autorisations de base de données

accès à  votre chaîne de connexion et l’attaque
par injection de code SQL manipule les données envoyées
par l’application à  votre base de données via la
connexion. Bien que vous puissiez dissimuler la chaîne de
connexion sous plusieurs couches de cryptage, vous devez
quand même partir du postulat qu’elle peut tomber entre de
mauvaises mains. Qu’avez-vous fait pour limiter les dégâts si
cela se produit ? Vous devez configurer les comptes employés
par les utilisateurs pour accéder à  la base de données
uniquement avec les autorisations donnant accès aux procédures
stockées dont se sert l’application.

C’est à  ce stade que les rôles de base de données entrent
en scène. De nombreux développeurs préféreraient employer
simplement le compte sa pour des accès faciles au
cours du développement, mais j’espère que vous ne laissez
pas l’application de production disposer d’autorisations sa
sur votre système. Certains développeurs créent un compte
personnalisé pour les phases de développement, mais ils lui
octroient des autorisations complètes ou une large palette
d’autorisations, notamment les rôles SQL Server db_datareader
et db_datawriter. Ces rôles constituent une meilleure approche
que le recours à  un compte avec des privilèges d’administrateur,
mais dans la majorité des cas, ils n’assurent
qu’une protection limitée contre l’action dévastatrice de l’injection
de code SQL.

Lors de la configuration des autorisations de base de
données de votre application, commencez avec un rôle personnalisé.
Notez bien que je n’ai pas employé le terme
« compte ». Au fil du temps, les comptes ou le type de compte
(SQL Server ou Windows) peuvent changer, mais si vous avez
lié les autorisations de votre application à  un rôle, ces détails
n’ont aucune importance. L’utilisation d’un rôle a la signification
suivante : lorsqu’il est nécessaire de changer un
compte, il suffit d’ajouter un nouveau compte au rôle et de
supprimer l’ancien compte.

Parfois, les développeurs essaient de créer un rôle pour
les opérations de lecture et un autre pour les opérations
d’écriture sur la base de données. Cette approche simple
peut sembler pertinente, mais une meilleure approche
consiste à  créer un rôle ayant les autorisations d’accéder uniquement
aux procédures stockées de votre application. Avec
un seul rôle, si le compte est compromis (soit explicitement,
soit implicitement), vous pouvez faire en sorte que les seuls
objets à  la portée de l’intrus soient ceux auxquels l’application
peut accéder en toute légitimité. Un accès direct aux
tables de votre base de données signifie que la violation d’un
compte entraînera celle de toutes les colonnes des tables. Si
vous autorisez les accès uniquement par le biais d’une procédure
stockée, l’application sera capable d’insérer des informations
telles qu’un numéro de carte de crédit. Mais si
SQL Server n’a pas de procédure stockée pour retourner un
numéro de carte de crédit (et elle ne doit pas en avoir), les
intrus ne pourront pas obtenir cette information.