Mettre en oeuvre les pare-feu SQL

contenu ne sont pas encore banalisés,
leur tarif n’est pas bien publié et est généralement
personnalisé pour chaque
client. Attendez-vous quand même à 
payer entre 10 000 dollars et 200 000
dollars en fonction du nombre de
bases de données et de réseaux à  protéger.
(Pour plus de détails sur la quête
des produits disponibles, voir l’encadré
« Quelques pare-feu SQL.)
S’agissant de composants supplémentaires
du réseau, les pare-feu SQL
Server nécessitent mise en place, administration
et maintenance. Il faut
aussi définir les stratégies de sécurité
qu’appliquera le pare-feu. Comme les
pare-feu de contenu traitent des éléments
qui se situent au niveau application
plutôt qu’au niveau réseau, il faut
prévoir un long temps d’implémentation
– entre 1 et 4 mois – principalement
pour définir les stratégies de sécurité
d’après les modèles d’accès aux
applications. Pendant la mise en place,
il faudra impliquer de multiples
groupes, dont les équipes responsables
de la sécurité, des données, et
des applications. Selon la méthodologie
retenue, la mise en place peut se
faire par application ou de manière générique.
Les stratégies par application
incluent des règles propres aux tables
et aux procédures des applications que
vous sécurisez, tandis qu’une stratégie
de sécurité générique suit les
meilleures pratiques générales : limiter
l’accès d’un utilisateur à  une application,
un petit nombre d’adresses IP, par
exemple. Les contrôles spécifiques aux
applications offrent plus de sécurité
que les contrôles génériques mais ils
peuvent facilement allonger le temps
d’implémentation, selon le nombre
d’applications à  protéger.
Les pare-feu de contenu se glissent
généralement entre l’application et la
base de données. Par conséquent,
toute communication entre l’application
et la base de données passe par le
pare-feu. Ce pare-feu crée bien sûr un
niveau de sécurité supplémentaire
mais aussi un nouveau point de défaillance.
Par conséquent, pour des systèmes
critiques, il faut au moins deux
pare-feu de contenu pour créer une
configuration redondante. En outre,
les pare-feu imposent une latence inhérente
(aussi petite soit-elle) – qui allonge
le temps de réponse de bout en
bout. Enfin, à  chaque mise à  niveau importante
(par exemple, quand les
bases de données passent à  la prochaine
release SQL Server), il faut aussi
mettre à  niveau les composants d’analyse
parce que les principales releases
s’accompagnent presque toujours
d’un changement des protocoles sousjacents,
de la grammaire SQL, ou des
deux.