JSS2011 - SQL Server et la sécurité

1. LA SÉCURITÉ DANS SQL SERVER ET LES
NOUVEAUTÉS DE LA VERSION 2012

2. Rejoignez la Communauté

3. SPEAKER
David BARBARIN
 Travaille avec SQL Server depuis 2003.
 Consultant et formateur SQL Server.
 Senior Consultant SQL Server @ Pragmantic SA.
 SQL Server MVP.
 http://www.pragmantic.com/
 http://blog.developpez.com/mikedavem/
 http://mikedavem.developpez.com/

4. SOMMAIRE
•SQL Server et son environnement
•Sécuriser une instance SQL Server
•Sécurité des sauvegardes
•Audits
4

5. POURQUOI SECURISER UN SERVEUR
DE BASES DE DONNEES ?
•Hébergement des données d’entreprises
(Finance, clients, contacts, ventes, employés …)
•Peut avoir un impact business important
•Compliance avec les standards de sécurité et
de régulation de en plus en plus omniprésente
5

6. SQL SLAMMER LE DEBUT D’UNE PRISE DE
CONSCIENCE DE LA SECURITE
• Ver qui réside en mémoire et qui exploite une faille dans le protocole de
résolution de nom de SQL Server (UDP 1434)
• Utilise l’ensemble de la bande passante pour scanner le réseau et se répliquer
sur d’autres serveurs
• Premier patch disponible en juillet 2002
• Outils de déploiement des patchs de sécurité limité
• Trop de serveurs SQL exposés sans firewall
• Pic d’activité : scan de 55 millions de serveurs / sec. Ce nombre est doubé
toutes les 8.5 sec
• 75 000 hôtes infectés en 10 minutes
6

7. SQL SLAMMER LE DEBUT D’UNE PRISE DE
CONSCIENCE DE LA SECURITE
7

8. SQL SERVER ET SON
ENVIRONNEMENT
8

9. SQL SERVER ET SON ENVIRONNEMENT
9
Réseau
Stockage
Windows
SQL
Server

10. SQL SERVER ET SON ENVIRONNEMENT
• Utilisation d’un firewall
• Architecture des réseaux
• Choix d’un VPN ou d’une ligne dédiée
• Chiffrement de la connexion (SSL, TLS, IPSEC)
• Contrôle d’accès aux bornes wifi
• Désactivation des ports des switchs non utilisés
• Contrôle des accès physiques au datacenter
• Outsourcing (garantie des sociétés externes sur la
protection des données)
• Utilisation illicite d’un poste utilisateur non verrouillé
• Social Engineering
1

11. SQL SERVER ET SON ENVIRONNEMENT
• Auditer la sécurité de son réseau est indispensable
• Comment ?
oTest d’intrusion interne depuis l’extérieur ou l’intérieur du réseau
oAppel à des entreprises spécialisées
oProcessus d’amélioration continue
1

12. SQL SERVER ET SON ENVIRONNEMENT
• Cartes HBA
o L’ensemble des IO est chiffré (lecture et écriture)
o La charge de travail se focalise essentiellement au niveau de la
CPU des cartes HBA
o Impact sur les performances IO en cas de charge de travail
importante (Possibilité de multiplier les cartes HBA)
o Peu de vendeurs implémentent le chiffrement à ce niveau
(Emulex)
• MPIO
o Chiffrement des données au niveau du flux d’écriture
o EMC, PowerPath et clé RSA. + gestion des certificats par RKM
o Impact sur les performances
1

13. SQL SERVER ET SON ENVIRONNEMENT
• SQL Server cohabite avant tout avec un système
d’exploitation !!!
• Droits nécessaires au compte de service SQL Server
o Log on as service (SeServiceLogonRight)
o Replace a process-level token (SeAssignPrimaryTokenPrivilege)
o Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
1

14. SQL SERVER ET SON ENVIRONNEMENT
• ACL sur les dossiers et fichiers qui concernent SQL Server
o Windows 2008 et UAC : il n’est pas possible de créer des fichiers à la
racine d’un lecteur logique ou d’un mount point si le compte ne
possède pas les privilèges administrateur
• Considérations NTFS sur les ressources SQL Server
o Seul le compte de service SQL Server (et les administrateurs
systèmes) doivent avoir accès aux fichiers de bases de données
o Eviter si possible les groupes locaux ou active directory. Activer le
monitoring des modifications intervenants sur les groupes (ajout,
suppression d’un membre …)
o Les clés de registre appartenant à une instance ne doivent pouvoir
être accéder en écriture que par le compte de service concerné
Avec SQL Server 2012 la vue sys.dm_server_registry permet de
connaitre rapidement les clés de registres associée à une instance
1

15. SQL SERVER ET SON ENVIRONNEMENT
• Le changement de compte de service doit se faire via
l’outil de gestion de configuration SQL Server
o Modification des ACL sur les dossiers et fichiers de l’instance
o Modification des ACL des clés de registres
1

16. SECURISER UNE INSTANCE
SQLSERVER
1

17. SECURISER UNE INSTANCE SQLSERVER
• Le compte local prédéfini LOCAL SYSTEM doit être évité
autant que possible
o Avec SQL Server 2012 le compte local NT AUTORITYSYSTEM
n’est plus ajouté en tant que membre du rôle sysadmin
pendant l’installation
• Les comptes de services ne doivent pas faire parti du
groupe local BUILTINAdministrators.
o Depuis SQL Server 2008 ce compte n’est plus membre du
rôle de serveur sysadmin par défaut
• Jusqu’à SQL Server 2005 un même compte utilisateur ne devait
pas être utilisé par plusieurs instances SQL Server ni pour
d’autres comptes de services liés à SQL Server (utilisation du
groupe prédéfini (SQLServerMSSQLServerUser$<instance>)
1

18. SECURISER UNE INSTANCE SQLSERVER
• Depuis SQL Server 2008 isolation des ressources par
l’utilisation des SID des comptes de services SQL Server
• Avec SQL Server 2012 il est possible d’utiliser
directement les comptes virtuels ou les comptes
managés en tant que compte de services
1

19. SECURISER UNE INSTANCE SQLSERVER
1

20. SECURISER UNE INSTANCE SQLSERVER
2

21. SECURISER UNE INSTANCE SQLSERVER
2

22. SECURISER UNE INSTANCE SQLSERVER
• Réduction de la surface d’attaque en réduisant le
nombre de services au strict nécessaire
• Avec SQL Server 2000 la plupart des composants
étaient dépendants du moteur. Avec les releases
postérieures l’architecture est devenu plus modulaire
• SQL Browser désactivé par défaut lorsqu’une seule
instance existe. Ce service doit être désactivé lorsqu’il
n’est pas nécessaire pour réduire la surface d’attaque
2

23. SECURISER UNE INSTANCE SQLSERVER
• SQL Server écoute et permet les connexions au travers des
points de terminaisons (Endpoints)
o TSQL Local Machine (SHARED MEMORY)
o TSQL Named Pipes (NAMED PIPES)
o TSQL Default TCP (TCP)
o TSQL Default VIA (VIA)
o Dedicated Admin Connection (TCP)
• Fournit une couche additionnelle de sécurité
o Avec le contrôle du ou des comptes de connexion qui peuvent se
connecter
o En forçant la connexion via un compte d’application spécifique
2

24. SECURISER UNE INSTANCE SQLSERVER
2

25. SECURISER UNE INSTANCE SQLSERVER
• Politique de sécurité des mots de passe
o Avec SQL Server 2000 possibilité d’installer une instance avec le
compte super utilisateur sa sans mot de passe
o Algorithme de chiffrement du mot passe connu (David LitchField)
o Le compte super utilisateur sa est la première cible des attaques par
brute de force
o Depuis 2005 possibilité d’aligner la politique de sécurité des mots
de passe des logins de type SQL avec Windows (CHECK_POLICY et
CHECK_EXPIRATION)
o Ne pas utiliser l’option «Store passwords using reversible encryption»
pour les comptes Windows
2

26. SECURISER UNE INSTANCE SQLSERVER
• Qu’est-ce qu’un mot de passe sécurisé ?
o Mot de passe composé d’au moins un des 3 critères suivants :
– 8 caractères minimum
– Lettres minuscules
– Lettres majuscules
– Nombres
– Caractères spéciaux
• Ne pas utiliser un mot de passe à usage courant
• La combinaison des règles précédentes rendent un mot de passe
difficile à casser aux attaques brute de force
• SQL Server reconnaît 5 règles de mots de passe basées sur Windows :
o Forcer l’historique des mots de passe
o Ancienneté maximale des mots de passe
o Ancienneté minimale des mots de passe
o Longueur des mots de passe
2

27. SECURISER UNE INSTANCE SQLSERVER
• SQL Server ne stocke pas une version chiffrée du mot de
passe mais un hash.
• SHA1 est utilisé par SQL Server depuis SQL Server 2000
• Avec SQL Server 2000 une version du mot de passe en
majuscule était hachée ce qui limite le champ des possibilités
pour une attaque brute de force
• Depuis SQL Server 2005 seuls les membres du rôle sysadmin
peuvent voir le hash des logins dans le catalogue système
• Utilisation de PWDCOMPARE()
o Identification des mots de passe vide sur SQL Server 2000
o Recherche des mots de passe à usage courant
2

28. SECURISER UNE INSTANCE SQLSERVER
• Compte super utilisateur SA
o Doit être désactivé ou éventuellement renommé si possible
– Permet de réduire considérablement la surface d’attaque
– L’attaquant doit chercher un utilisateur potentiel avant de lancer une
combinaison de mot de passe
• Compte invité (GUEST)
o Ce compte doit être désactivé sur les bases de données
utilisateurs.
2

29. SECURISER UNE INSTANCE SQLSERVER
• Rôles de serveurs
2
Rôles de serveurs Permissions
sysadmin Possède tous les droits sur le serveur
serveradmin Peut changer la configuration du serveur
setupadmin Peut configurer la réplication et les serveurs
liés
securityadmin Peut gérer les logins et audits associés
processadmin Peut gérer les process qui existent sur
l’instance SQL Server
bulkadmin Peut utiliser la commande BULK INSERT
diskadmin Peut gérer les fichiers sur disque
dbcreator Peut créer et gérer les bases de données
public Par défaut possède les privilèges VIEW ANY
DATABASE et CONNECT

30. SECURISER UNE INSTANCE SQLSERVER
• Rôles de bases de données
3
Rôles de bases de données Permissions
db_owner Peut effectuer n’importe quelle opération de
maintenance et de configuration sur la BDD
db_accessadmin Gère les accès à la base de données
db_securityadmin Gère les permissions et les appartenances aux rôles de
bases de données
db_ddladmin Peut exécuter des instructions de type DDL
db_backupoperator Peut sauvegarder la base de données
db_datareader Peut lire toutes les données de toutes les tables
utilisateurs
db_datawriter Peut ajouter, supprimer ou modifier les données dans
les tables utilisateurs
db_denydatareader Ne peut pas lire les données des tables utilisateurs
db_denydatawriter Ne peut ni ajouter, ni supprimer ou modifier les
données dans les tables utilisateurs

31. SECURISER UNE INSTANCE SQLSERVER
• Rôles de serveurs
o Les permissions associées aux rôles prédéfinis ne peuvent être
changées
o Le rôle de serveur public possède par défaut les permissions VIEW
ANY DATABASE et CONNECT
Depuis SQL Server 2012 il est possible de créer ses propres rôles de
niveau serveur
• Rôles de bases de données
o Le super utilisateur sa et les membres du rôle de serveur sysadmin
sont mappés au compte utilisateur dbo
• Donner certaines permissions à un principal n’est pas la
même chose que de l’ajouter en tant que membre à un rôle
3

32. SECURISER UNE INSTANCE SQLSERVER
• Utilisation de l’instruction DENY
o DENY ne fait pas partie de la norme SQL
o DENY surpasse l’instruction GRANT (sauf dans le cas d’une
permission niveau colonne)
o L’utilisation de l’instruction DENY cache en général un problème
de design au niveau de la sécurité
3

33. SECURISER UNE INSTANCE SQLSERVER
• Utilisation des schémas
o Plus de dépendance des objets vis-à-vis des utilisateurs
o Un schéma peut appartenir à n’importe quel principal
o Isolation de la sécurité au travers de conteneurs distincts
o Configuration de la sécurité directement au travers des schémas
• Problème de création de schémas non désirés
o Un login fait parti d’un groupe Windows
o La création d’objets se fait sans préciser le schéma propriétaire
o Avec SQL Server 2012 c’est le schéma par défaut dbo qui sera affecté
pendant la création d’un objet si aucun schéma explicite n’est
précisé.
3

34. SECURISER UNE INSTANCE SQLSERVER
• TRUSTWORTHY indique à l’instance SQL Server que la
base de données est approuvée ainsi que son contenu
• Par défaut cette option est à OFF
• Permet une protection contre certains modules
malveillants à base de CLR ou qui s’exécutent en tant
qu’utilisateur à privilège élevé.
• Attention à l’activation de cette option !!
3

35. SECURISER UNE INSTANCE SQLSERVER
• Contained databases avec SQL Server 2012
o Indépendance des bases de données vis-à-vis des instances qui les
hébergent
o Les utilisateurs se connectent directement via des utilisateurs de bases de
données et non plus par l’intermédiaire des logins au niveau instance
o Change la manière de gérer la sécurité pour les administrateurs de bases de
données
o Problème de duplication des logins
o Un membre du rôle db_owner ou ayant la permission CONTROL DATABASE
peut activer une base comme étant contained.
o Option auto_close activée peut gérer des DENIAL OF SERVICE à cause du
coup supplémentaire lié à l’ouverture et la fermeture de la base de données
3

36. SECURITE DES SAUVEGARDES
3

37. SECURITER DES SAUVEGARDES
• Tolérance de panne != Sécurisation des sauvegardes
• L’effort de sécurisation d’une instance SQL Server peut être réduit à
néant si une stratégie de sécurité des sauvegardes n’est pas
également mise en place
• La réécriture d’une sauvegarde sur un même support peut être
problématique dans d’échec. Aucune sauvegarde valide ne pourra
être utilisée lors d’une restauration
• Stockage des sauvegardes hors site
o Qui est impliqué dans le processus ? (Employés, entreprise externe etc…)
o De quelle manière sont transportés les sauvegardes ?
o Quelles garanties puis-je avoir si mes sauvegardes sont stockées par une
entreprise tiers ?
o Perte de sauvegarde, restitution des sauvegardes au mauvais propriétaire …
3

38. SECURITE DES SAUVEGARDES
• Utilisation de l’option MEDIAPASSWORD pendant une
sauvegarde
o Avec SQL Server 2000, le seul moyen pour protéger une sauvegarde.
o Depuis cette option n’est plus un moyen sûr de protéger une
sauvegarde
• Le chiffrement des sauvegardes restent à ce jour la meilleure
alternative
• Chiffrer ses sauvegardes
o Outils tiers de sauvegarde comme Litespeed for SQL Server, Red
Gate SQL HyperBack ou Red Gate SQL Backup etc …
o Outils tiers de sauvegarde de médiathèque comme HP Data
Protector, Symantec NetBacku etc …
o Depuis SQL Server 2008 la possibilité d’utiliser Transparent Data
Encryption
3

39. AUDITS
3

40. AUDITS
• Les audits font partis intégrante de la sécurité
o Il faut pouvoir vérifier que la sécurité mise en place le reste
o La seule mise en place des audits ne vaut rien si les données ne
sont pas revues et utilisées
o La sécurisation des fichiers et données d’audit est également très
importante
• Nécessité de prise en charge des standards existants :
o European Union Data Protection Directive
o HIPAA
o Sarbanes-Oxley
o Payment Card Industry Data Security Standard
4

41. AUDITS
• C2 audit mode
o Méthode la plus ancienne qui existe avec SQL Server
o Audit les tentatives d’accès aux objets (peut consommer une quantité
importante d’espace disque
o Si le moteur ne peut plus écrire dans le fichier de log l’instance est
automatiquement arrêtée.
• Common Criteria Compliance
o Exige que la mémoire soit réécrite avant la réallocation de l’espace à un autre
processus (RIP)
o Activation des audits des login (SUCCESS, FAILED, nombre de tentative de
login entre la dernière connexion connue et la connexion courante)
o Modification du comportement des GRANT / DENY au niveau colonne.
• Profiler + triggers + audit des logins avec SQL Server 2005 + trace
par défaut
4

42. AUDITS
• SQL Server audits depuis SQL Server 2008.
• Cet outil permet de capturer des événements d’audits en ayant le
moins d’impact possible sur le système car il utilise les XE avec le
package privé secAudit. (cf présentation de David Baffaleuf)
• SQL Server 2012 propose également des améliorations sur cette
fonctionnalité
o Ajout de l’action FAIL_OPERATION en ca d’échec d’écriture dans les journaux
d’audit
o Contrôle du nombre de fichiers qui seront créés pour les audits
o Ajout d’un prédicat directement dans les objets d’audits
o Ajout d’informations additionnelles lorsque cela est possible
o Reprise automatique d’écriture dans les journaux d’audits en cas de rupture
de liaison entre SQL Server et les fichiers sur disque
o Audits de serveurs supportés sur l’ensemble de la gamme des éditions SQL
Server 2012. Les audits de bases de données ne sont supportés que sur les
éditions Enterprise, DataCenter, Evaluation et Developer
4

43. AUDITS
4

44. AUDITS
• Utilisation de la gestion basée sur les règles depuis SQL
Server 2008
o Création d’un véritable standard de sécurité
o Traduction des règles de sécurité en police sur SQL Server
o Audit périodique avec application des règles du standard sur
l’ensemble des instances SQL Server.
4

45. DEMO
Q & A

46. Merci à nos Sponsors
Rencontrez les dans l’espace partenaires