Extension de upCheckSecurityConfiguration

A partir de là, vous avez toute latitude pour exécuter et mettre à jour votre suite de test comme bon vous semble.

Supposons que vous souhaitiez auditer votre configuration au début et à la fin de chaque jour ouvré, ou encore que vous souhaitiez lancer votre procédure d’audit à chaque événement suspect, par exemple en cas de tentative de connexion illégale. Il suffit d’inclure les contrôles de sécurité voulus dans la procédure stockée upCheckSecurityConfiguration, puis de créer une tâche de l’Agent SQL (ou alerte) qui se déclenche au moment opportun. En fait, pendant que vous y êtes, pourquoi ne pas créer une procédure distincte pour chaque audit de sécurité à exécuter, ces différents audits étant conçus spécialement pour chaque contrôle de sécurité requis ? Quelle que soit la stratégie adoptée, il vous faudra adapter upCheckSecurityConfiguration en fonction de vos besoins particuliers.

Pour illustrer une approche possible en la matière, j’ai étendu upCheckSecurityConfiguration afin d’inclure 15 paramètres de sécurité couramment audités de la liste de contrôle de sécurité de Microsoft. Le listing 1 illustre les trois premiers contrôles de la procédure stockée. Vous pouvez télécharger la procédure stockée upCheckSecurity- Configuration complète, ainsi que les autres exemples de code de cet article à l’adresse https://www.itpro.fr (Club Abonnés).

Le côté intéressant de upCheckSecurityConfiguration est que tous vos tests sont centralisés. Si vous devez modifier un de vos contrôles ou ajouter un nouveau test de sécurité, il suffit de modifier la procédure stockée, puis de la recompiler. Il est difficile de faire plus simple. Si vous ne possédez pas encore de base de données de test, je vous suggère d’en créer une pour héberger upCheckSecurityConfiguration, ses tables associées et le déclencheur trgLogBug. Il faudra également réfléchir aux personnes qui disposeront d’un accès à ces ressources et définir les privilèges en conséquence.