Construisez vos propres systèmes de sécurité automatisés

Les contrôles de configuration constituent la cheville ouvrière des tests de sécurité des bases de données et ils sont vitaux pour protéger ces dernières contre des intrusions extérieures ou des falsifications internes à l’entreprise. Un contrôle de configuration consiste, pour l’essentiel, à s’assurer qu’une option de sécurité spécifique a été définie correctement, par exemple l’activation d’un firewall ou d’une configuration de ports spéciale, ou encore la suppression de bibliothèques réseau non vitales. Ce contrôle englobe également les stratégies de sauvegarde et de protection des fichiers, les modes d’authentification, les comptes Invité, ainsi que les autorisations du rôle public. La majorité des administrateurs de base de données (DBA) effectuent les contrôles de sécurité manuellement, mais en écrivant les étapes requises sous forme de script, vous pouvez automatiser facilement de nombreux contrôles de routine touchant à la sécurité.

Par exemple, pour savoir si votre serveur de base de données exécute le tout dernier Service Pack, vous pouvez exécuter le code T-SQL illustré à la figure 1 (en insérant votre propre numéro de version). (Certains éléments du code des listings sont écrits sur plusieurs lignes par manque de place.) De même, pour déterminer si un service superflu a été désactivé, vous pourriez exécuter le code du listing 2, lequel vérifie si le service MSDTC (Microsoft Distributed Transaction Coordinator) est en cours d’exécution.

Même si les scripts servant à automatiser les tests de sécurité sont rarement plus complexes que les exemples de code précédents, ces derniers ne sont pas des tests entièrement automatisés. Pour parvenir à cette automatisation totale, un test de sécurité inclut les éléments suivants :

• un plan de test clairement défini pour chaque contrôle de sécurité, avec un résultat escompté (par ex., toute version SQL Server supérieure ou égale à 8.00.2039), afin de pouvoir déterminer si une option de configuration est définie correctement, et des conditions préalables requises par le test (par ex., le serveur est en cours d’exécution, la base de données gère tous les paramètres testés, le test possède obligatoirement les autorisations nécessaires sur le script de test et les cibles des tests) ;

• des rapports de test documentant les résultats de chaque contrôle ;

• un rapport de bogue distinct, généré lorsqu’un paramètre de configuration viole une stratégie de sécurité.

Ne perdez pas votre temps à tester un paramètre de configuration si votre organisation n’a pas d’exigence ou de politique de sécurité le concernant. Par ailleurs, si vous pensez qu’un paramètre de sécurité spécifique doit être testé, même s’il n’est pas documenté, vous devez d’abord rapporter dès que possible un bogue au niveau de votre plan de sécurité et/ou des règles métiers de l’entreprise. Si le paramètre constitue un point de contrôle de sécurité critique, il faut en informer votre analyste métier ou le planificateur de la sécurité afin qu’il révise en conséquence la stratégie de sécurité de l’entreprise.