Réunion du GUSS : Sécurité, PowerShell et langages de scripts font leur show !

Début octobre s’est tenue la dernière réunion du GUSS (Groupe des utilisateurs de SQL Server) à Paris. Cette rencontre trimestrielle, qui est toujours l’occasion d’échange d’informations techniques, a rencontré un vif succès. D’autant que le GUSS a aujourd’hui bien d’autres projets en tête comme la tenue de tables rondes et la diffusion de webcasts. A suivre donc de très près …

Cette réunion a débuté par un exposé sur les solutions d’audit de sécurité pour SQL Server, animé par Christian Robert, MVP SQL Server et secrétaire du GUSS.
Aujourd’hui, les défis de la sécurité sont nombreux et il convient de bien les identifier et de composer avec eux : restreindre les accès au serveur, maîtriser l’identité des utilisateurs connectés, appliquer une stratégie de sécurité globale, identifier les accès aux données, gérer les données mobiles, déterminer la confidentialité des données, sensibiliser les utilisateurs.
Quel comportement faut-il réellement adopter ?
Côté matériel ! Il s’agit de mettre en place des contrôle d’accès au serveur (salle blanche sécurisée), contrôler les données mobiles, et sécuriser les sauvegardes, export de données.
Côté logiciel ! il faut sécuriser Windows (appliquer des correctifs, donner des privilèges minimaux SQL Server), installer un firewall sur le serveur de base de données, sans oublier un antivirus.
Et côté utilisateur, sensibiliser reste le maître mot ! Il convient également de s’assurer de l’identité de l’utilisateur, d’identifier les accès aux données et de séparer les rôles.
Les niveaux de sécurité sous Windows sont privilégiés à savoir les firewall, antivirus, Ipsec, authentification via Kerberos, comptes de services et Group Policy Object.

La sécurité optimale SQL Server se réalise d’abord au niveau du serveur et se compose de plusieurs éléments qu’il ne faut pas négliger. Du type de connexion (TCP/IP, canaux nommés…) aux comptes de connexion au serveur en passant pas le rôle, les permissions de niveau serveur jusqu’aux  credentials/ proxy, et la Surface Area Configuration (SAC), le programme est vaste.
Qu’en est-il au niveau base de données ? Des utilisateurs de base de données aux rôles de bases de données en passant par le chiffrage transparent de bases de données et le chiffrage via EFS (Encrypted File System), tout y est.
Au niveau des objets, la réponse est simple. Il faut prendre en compte les droits d’accès ou d’exécution, le chaînage de propriétés, la signature de code ou de données, le chiffrage des données.
Si l’audit s’installe en force, pourquoi auditer ? En raison d’impératifs légaux (loi Sarbanes-Oxley…) du suivi des comptes membres des rôles sysadmin, de la prévention plutôt que de la restriction ! Mais comment auditer ? Les données d’audit doivent être situées hors du serveur audité et le processus doit être le plus transparent possible pour le serveur de bases de données. Les avantages s’appliquent ainsi à tous les comptes.
Revenons un instant sur les principales méthodes. Quelles sont-elles ? L’utilisation de Trigger DMC, la mise en place de trace avec SQL Trace, l’outil de lecture du journal de transaction