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

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

Data - Par Dan Sawyer - Publié le 24 juin 2010
email

Il était une époque où la sécurité des SQL Server n’aurait l’idée de donner le feu vert à une base de données sans contrôler au préalable ses vulnérabilités concernant la sécurité, par exemple la présence de mots de passe faibles ou de firewalls perméables. Mais comment savoir si vous avez vérifié tous les paramètres de sécurité essentiels ? Ainsi, si vous omettez de verrouiller vos dossiers d’installation ou de désactiver le compte Invité (Guest) de votre serveur, vous serez à la fête !

La réponse à la question ci-dessus consiste à élaborer un plan structuré de test de la sécurité, afin de contrôler différents paramètres de configuration requis par votre entreprise et de générer les rapports consignant les résultats des tests. Cet article présente, dans un premier temps, les aspects constitutifs d’une approche de test de la sécurité, puis fournit des exemples de code TSQL utilisables afin d’automatiser certaines parties de votre processus de test de la configuration et de génération des rapports correspondants. Mais commençons par le commencement.

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.

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Data - Par Dan Sawyer - Publié le 24 juin 2010