SQL Server et la sécurité
46
LA SÉCURITÉ DANS SQL SERVER ET LES NOUVEAUTÉS DE LA VERSION 2012
-
Upload
david-barbarin -
Category
Technology
-
view
239 -
download
1
Transcript of SQL Server et la sécurité
LA SÉCURITÉ DANS SQL SERVER ET LES NOUVEAUTÉS DE LA VERSION 2012
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/
SOMMAIRE
•SQL Server et son environnement
•Sécuriser une instance SQL Server
•Sécurité des sauvegardes
•Audits
4
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
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
SQL SERVER ET SON ENVIRONNEMENT
8
SQL SERVER ET SON ENVIRONNEMENT
9
Réseau
Stockage
Windows
SQL Server
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
10
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
11
SQL SERVER ET SON ENVIRONNEMENT
• Cartes HBAo 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’écritureo EMC, PowerPath et clé RSA. + gestion des certificats par
RKMo Impact sur les performances
12
SQL SERVER ET SON ENVIRONNEMENT
• SQL Server cohabite avant tout avec un système d’exploitation !!!
• Droits nécessaires au compte de service SQL Servero Log on as service (SeServiceLogonRight)o Replace a process-level token
(SeAssignPrimaryTokenPrivilege)o Adjust memory quotas for a process
(SeIncreaseQuotaPrivilege)
13
SQL SERVER ET SON ENVIRONNEMENT• ACL sur les dossiers et fichiers qui concernent SQL ServeroWindows 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 Servero Seul le compte de service SQL Server (et les administrateurs
systèmes) doivent avoir accès aux fichiers de bases de donnéeso 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
14
SQL SERVER ET SON ENVIRONNEMENT• Le changement de compte de service doit se faire via l’outil de gestion de configuration SQL Servero Modification des ACL sur les dossiers et fichiers de
l’instanceo Modification des ACL des clés de registres
15
SECURISER UNE INSTANCE SQLSERVER
16
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 AUTORITY\SYSTEM
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 BUILTIN\Administrators. 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>)
17
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
18
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
22
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é oAvec le contrôle du ou des comptes de connexion qui peuvent
se connecteroEn forçant la connexion via un compte d’application spécifique
23
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)
oNe pas utiliser l’option «Store passwords using reversible encryption» pour les comptes Windows
25
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 passeo Ancienneté minimale des mots de passeo Longueur des mots de passe
26
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 2000o Recherche des mots de passe à usage courant
27
SECURISER UNE INSTANCE SQLSERVER
• Compte super utilisateur SAo 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.
28
SECURISER UNE INSTANCE SQLSERVER
• Rôles de serveurs
29
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
SECURISER UNE INSTANCE SQLSERVER
• Rôles de bases de données
30
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
SECURISER UNE INSTANCE SQLSERVER• Rôles de serveurso Les permissions associées aux rôles prédéfinis ne peuvent être
changéeso 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éeso 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
31
SECURISER UNE INSTANCE SQLSERVER
• Utilisation de l’instruction DENY
o DENY ne fait pas partie de la norme SQLo 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é
32
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 distinctso 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 Windowso 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é.
33
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 !!
34
SECURISER UNE INSTANCE SQLSERVER• Contained databases avec SQL Server 2012o Indépendance des bases de données vis-à-vis des instances qui les
hébergento 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
35
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
…
37
SECURITE DES SAUVEGARDES
• Utilisation de l’option MEDIAPASSWORD pendant une sauvegardeo 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 oOutils 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
38
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
resteo La seule mise en place des audits ne vaut rien si les
données ne sont pas revues et utiliséeso 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 Directiveo HIPAAo Sarbanes-Oxleyo Payment Card Industry Data Security Standard
40
AUDITS
• C2 audit modeo Méthode la plus ancienne qui existe avec SQL Servero Audit les tentatives d’accès aux objets (peut consommer une quantité
importante d’espace disqueo Si le moteur ne peut plus écrire dans le fichier de log l’instance est
automatiquement arrêtée.
• Common Criteria Complianceo 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
41
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’audito Contrôle du nombre de fichiers qui seront créés pour les auditso Ajout d’un prédicat directement dans les objets d’auditso Ajout d’informations additionnelles lorsque cela est possibleo Reprise automatique d’écriture dans les journaux d’audits en cas de rupture
de liaison entre SQL Server et les fichiers sur disqueo 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
42
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
Servero Audit périodique avec application des règles du
standard sur l’ensemble des instances SQL Server.
44
Merci à nos Sponsors
Rencontrez les dans l’espace partenaires
