SQL Server ? Fort heureusement, il existe des mesures permettant de réduire sensiblement les risques. Vous pouvez prévenir (ou au moins limiter) de nombreuses attaques SQL simplement en vérifiant initialement que vos bases de données et serveurs sont sécurisés comme il se doit.
La configuration de tous les ports d’écoute est-elle appropriée ? Avez-vous désactivé l’ensemble des bibliothèques réseau superflues ? Avez-vous pensé à supprimer les anciens fichiers de configuration SQL Server ? Et la liste ne s’arrête pas là.
Admettons-le, il faut du temps pour sécuriser tous les points de contrôle jusqu’au dernier et pour conserver une longueur d’avance sur les personnes malintentionnées. Chaque jour apporte son lot de nouvelles vulnérabilités concernant la sécurité, d’où la nécessité d’ajouter de nouveaux contrôles et d’effectuer une surveillance fréquente pour rester à l’abri des mauvaises surprises.
Dans ces circonstances, il serait épatant de pouvoir automatiser quelque peu toutes ces tâches d’audit longues et fastidieuses. C’est désormais possible si vous appliquez les techniques simples exposées dans cet article et si vous adaptez le code fourni à votre situation spécifique.
Automatisez vos audits de sécurité
Dans l’article « Construisez vos propres systèmes de sécurité automatisés », disponible sur le site http://www.itpro.fr Club Abonnés, SQL Server Magazine octobre 2006), vous avez pu découvrir comment tester une configuration de base de données afin de détecter les vulnérabilités touchant à la sécurité. La première étape consiste à créer une liste des stratégies de sécurité et à inspecter votre SGBDR à la recherche de violations possibles de celles-ci, de vulnérabilités de la conception et d’autres défauts de la sécurité exploitables par un pirate informatique.
Dans cet article, vous avez découvert un tableau répertoriant une liste des paramètres de sécurité à auditer. Ces paramètres, et bien d’autre encore, sont disponibles dans la rubrique « SQL Server 2000 SP3 Security Features and Best Practices: Security Best Practices Checklist », à cette adresse. Bien évidemment, vous allez ajuster vos tests en fonction de ces points de contrôle en accordant la priorité absolue à votre domaine de responsabilité.
La liste de contrôle de sécurité vous aide dans ce processus de personnalisation en classant ses points de contrôle par catégories. Si votre travail consiste à installer des bases de données, vous allez probablement mettre l’accent sur les exigences de sécurité liées aux catégories de préinstallation, d’installation et de post-installation dans la section administrateur de la liste de contrôle (Administrator Checklist). Si vous développez des applications, vous allez vous intéresser tout naturellement aux exigences liées au développement, notamment au cryptage des données et aux rôles de base de données.
Quelles que soient les vulnérabilités ciblées, votre préoccupation concerne la disponibilité d’audits reproductibles et faciles à mettre à jour. Après tout, quel est l’intérêt d’un test de sécurité s’il n’est exécuté qu’une seule fois ou s’il est incapable d’évoluer avec les nouvelles stratégies d’attaque ? L’automatisation constitue la clé d’audits de sécurité actualisés et reproductibles.
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental
Les articles les plus consultés
- Intelligence Artificielle : DeepKube sécurise en profondeur les données des entreprises
- Dark Web : où sont vos données dérobées ?
- Stockage autonome, Evolutivité & Gestion intelligente, Pure Storage offre de nouvelles perspectives aux entreprises
- La blockchain en pratique
- 10 grandes tendances Business Intelligence
