Principe de fonctionnement des pare-feu SQL

les paquets du
réseau, à  vos règles de contrôle d’accès.
Ces règles limitent quel client base
de données, application, et utilisateur
de base de données peuvent effectuer
quelles commandes sur quels objets
base de données. Les pare-feu SQL
peuvent distinguer les requêtes autorisées
et non autorisées parce qu’ils dissèquent
les protocoles Net-Library et
TDS (Tabular Data Stream) et utilisent
des analyseurs syntaxiques sophistiqués
pour recréer le T-SQL. Ces processus
vérifient l’autorisation (ou son
absence) d’un utilisateur pour accéder
à  un objet base de données spécifique,
quand il entre dans la session à  partir
d’une certaine application déployée à 
une certaine adresse IP.
La figure 3 montre les principales
activités qu’un pare-feu SQL doit mener
pour effectuer une autorisation de
requête complète. Le premier travail
du pare-feu SQL consiste à  analyser le
flux TCP/IP pour suivre toute la session
client. Le pare-feu doit défragmenter
ces paquets pour compenser la fragmentation
qui s’est produite au niveau
du réseau. Ensuite, le pare-feu extrait
les paquets Net-Library du flux TCP/IP.
Ensuite, le pare-feu extrait les TDS
PDU (Protocol Data Units), une étape
qui à  nouveau peut comporter de la
défragmentation, parce que les requêtes
SQL peuvent impliquer de
longues commandes qui pourraient ne
pas contenir dans un seul paquet Net-
Library ou TCP/IP. Le mécanisme « disséqueur
» est un composant qui reçoit
les paquets défragmentés et extrait la
chaîne SQL. Cette chaîne constitue
l’entrée dans l’analyseur. Dans le cas
d’un flux SQL Server, la chaîne est l’entrée
dans l’analyseur T-SQL qui peut
traiter toute la grammaire T-SQL et
doit supporter de multiples releases
SQL Server. A noter que comme différentes
releases SQL Server incluent
des structures T-SQL légèrement différentes,
tout pare-feu SQL construit
dans l’entreprise doit comporter un
analyseur élaboré capable de prendre
en charge ces différentes structures.
Ainsi, même si vous déployez seulement
SQL Server 2000, votre pare-feu
SQL doit comporter un analyseur qui
supporte SQL Server 7.0 parce qu’un
client pourrait utiliser un driver SQL
Server 7.0, lequel génère du trafic qui
utilise les commandes T-SQL de SQL
Server 7.0. En revanche, si votre entreprise
utilise de multiples plates-formes
de bases de données, il vous faudra
peut-être plusieurs parsers différents :
par exemple, pour traiter les dialectes
T-SQL Server SQL Server et PL/SQL
Oracle.
L’analyseur donne en sortie un
arbre « parse » complet (une collection
de noeuds, chacun représentant un élément
du SQL comme un opérateur,
une fonction ou une valeur), qui
reflète toute la grammaire SQL. Pour
savoir si le SQL est entièrement conforme
à  votre stratégie de sécurité, le
pare-feu SQL compare cet arbre d’analyse
avec les règles que vous avez
établies. Par exemple, votre règle pourrait
laisser les utilisateurs exécuter
des opérations SELECT mais pas des
opérations UPDATE. Généralement,
la stratégie permet de définir des
permissions en fonction de l’émetteur de la requête (utilisateur de la base de
données), à  quel contenu il essaie d’accéder
(objet), où se trouve l’objet
(base de données et schéma ainsi
source IP et réseau), comment l’objet
est utilisé (commande SQL), quand la
requête est effectuée (heure du jour)
et même, dans des cas plus poussés,
pourquoi il y a requête.
Dans l’exemple sp_update_company_
customers, un pare-feu SQL
pourrait facilement décréter qu’un argument
transmis à  la base de données
sp_update_company_customers ne
peut pas inclure la commande DROP.
De plus, un pare-feu SQL peut limiter
ou empêcher l’utilisation de toute
commande DDL (Data Definition
Language) parce que les serveurs d’applications
de production (contrairement
aux serveurs de développement)
n’envoient généralement pas de commandes
DDL à  la base de données. Si
un serveur d’applications de production
tente cette opération atypique, ce
peut être le signe d’une attaque par injection
SQL ou qu’un assaillant a compromis
le serveur d’applications pour
modifier la base de données. Un parefeu
SQL peut même appliquer une
règle de sécurité qui empêche les paramètres
d’une procédure stockée
d’inclure toute autre commande que
SELECT. De sorte que certains utilisateurs
ou scénario ne peuvent que lire
le contenu de la base de données. Le
pare-feu peut même aller plus loin : il
peut limiter l’utilisation de la commande
SELECT par table. En fait, les
pare-feu SQL peuvent contrer toutes
les attaques d’injection SQL et empêcher
l’accès aux données de la part
d’applications et de sources illégitimes.